LuizTools

Burndown Chart: como manter o prazo do projeto em dia

Atualizado em 25/03/2019!

No Scrum chamamos as ferramentas usadas em conjunto com os processos de artefatos. E dentre os fantásticos artefatos usados pelas Metodologias Ágeis o Burndown Chart é um de meus favoritos. Ele soma a simplicidade de um gráfico bidimensional, do tipo que vemos no Ensino Médio, com o poder da Gestão à Vista da Administração tradicional. Não obstante, apesar de não ser um artefato oficial do Scrum, se alinha muito aos três pilares do framework ágil: transparência, inspeção e adaptação, e neste post vamos entender o porquê e como usar esta ferramenta.

Depois de ler o artigo, se quiser conhecer mais sobre meu trabalho com métodos ágeis, dá uma olhada neste meu livro aqui.

O que é?

O Burndown Chart é uma ferramenta de acompanhamento do pipeline de desenvolvimento. Ele pode ser tão macro a ponto de englobar todo o ciclo de vida de um produto (chamado também de Release Burndown) ou tão micro a ponto de englobar apenas o progresso de desenvolvimento de uma Sprint (um mês geralmente), sendo incomum menos que isso.

De qualquer forma, o Burndown Chart sempre será um cartaz de qualquer tamanho que deve estar sempre visível ao time (transparência, lembra?) onde o eixo y (vertical) representa o montante de trabalho a ser realizado (que pode ser o total de Pontos de Função ou custos do Planning Poker) e o eixo x (horizontal) o tempo que temos para trabalhar (geralmente a duração da Sprint). Traça-se uma linha diagonal entre o topo o eixo y até o final do eixo x, como uma hipotenusa de um triângulo de ângulo reto (90 graus). Essa é a linha ideal.

Como funciona?

Todos os dias o gerente do projeto, ou Scrum Master no caso de times scrum, deve atualizar o Burndown Chart traçando um ponto no plano cartesiano (eixo x vs. eixo y) e ligando ao ponto do dia anterior como uma reta, criando um gráfico descendente (pelo menos esse é o objetivo. Comparando com a linha ideal sabemos se vamos cumprir ou não o prazo do projeto: se nossa linha de desenvolvimento estiver abaixo da linha ideal, atingiremos o prazo, caso a linha esteja acima da ideal, fracassaremos.

Obviamente o dia-a-dia pode fazer com que consigamos compensar dias menos produtivos e buscar novamente a linha ideal. Ou o contrário, podemos cair na armadilha de acreditar que um ou dois dias abaixo da linha ideal vai nos garantir uma entrega no prazo e descobrir alguma tarefa que não havia sido prevista e que trancará todo o pipeline. A chave para o sucesso no uso da ferramenta é mantê-la atualizada todos os dias, preferencialmente antes da Reunião Diária sugerida pelo Scrum, para que seja usada como insumo para os desenvolvedores decidirem o que farão hoje.

Note que, como citado nos comentários, não é obrigatório que apenas o Scrum Master ou GP o atualize diariamente. Esta tarefa pode ser delegada a qualquer membro do time, desde que seja de ciência do mesmo.

Considerações Adicionais

Como deve ter notado, cria-se o Burndown Chart após a Sprint Planning, com base no montante de pontos calculados no Planning Poker (ou Pontos de Caso de Uso em times mais tradicionais). Já sua atualização se dá através da observação dos cartões de um kanban, seja ele físico ou digital, conforme expliquei no post anterior desta série sobre Agile.

Além disso, conforme mencionado no post sobre Planning Poker, é comum que os times tenham de rodar duas ou três iterações/Sprints para que descubram a “velocidade do time”. Essa métrica é mais facilmente descoberta através da observação dos últimos Burndown Charts das sprints passadas. Basta olhar quanto pontos foi possível desenvolver nas últimas sprints para ter uma ideia da velocidade do time e estimar melhor na próxima sprint.

Burndown Chart Virtual

É meio que chover no molhado pois provavelmente você já usou alguma ferramenta de criação de gráficos como Excel ou Google Sheets e o Burndown Chart nada mais é do que um gráfico qualquer, mas alinhado com o progresso do time de desenvolvimento.

Como já mencionei anteriormente, nada supera a visibilidade de um artefato físico como um gráfico colado na parede e um kanban enorme que é visível de qualquer ponto da sala. No entanto, para aqueles que insistirem em ter um Burndown Chart visual, a única dica que dou é que o link dele esteja disponível à todos, bem como seus outros artefatos virtuais como kanbans no Trello e tudo mais.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Como fazer upload de arquivos para o Google Drive em Node.js

Com meu curso de Node.js e MongoDB chegando aos quase 200 inscritos na data em que escrevo este tutorial, muitas ideias tem me sido enviadas com relação a temas para posts e novas aulas no curso. Recentemente, um aluno estava tentando fazer algo que me chamou a atenção: uma API em Node.js que recebesse um arquivo e o enviasse para o Google Drive.

Assim, no artigo de hoje quero mostrar como você pode criar uma integração do Node.js com o Google Drive facilmente. Vamos enviar imagens, mas você pode facilmente adaptar o código para enviar outro tipo de arquivo.

Vamos lá!

Google Drive

Obviamente para que você consiga acompanhar este tutorial você deve ter uma conta no Google Drive. Se você possui um Gmail, automaticamente possui uma pois seus emails são armazenados na mesma que, em seu nível gratuito, fornece 15GB de armazenamento na nuvem. Por cerca de R$70/ano você faz um upgrade para 100GB o que lhe permite salvar muita coisa de maneira rápida e segura.

Caso não possua uma, crie em drive.google.com

Surpreendentemente, existe todo um suporte do Google à tecnologia Node.js, que você confere neste painel do Google Drive APIs. Acesse o painel e clique no botão “Enable Drive API” para que seja possível se integrar com a sua conta do GDrive, conforme a imagem abaixo.

Ao ativar a API, você receberá um Client ID e um Client Secret, que serão necessários para a autenticação na aplicação Node.js.Guarde-os consigo, pois eu não vou fornecer os meus, hehehe. Também lhe é oferecido um arquivo de credenciais (credentials.json), baixe e salve-o na pasta do projeto que vamos criar a seguir.

Criando o projeto em Node

Crie uma pasta na sua máquina chamada gdrive-node e navegue até ela via terminal. Crie um gdrive-auth.js vazio e rode um ‘npm init’ para criar uma aplicação. Depois instale a biblioteca do GDrive usando o comando abaixo:

npm install googleapis@27 --save

1	npm install googleapis@27 --save

Lembre-se de ter o seu arquivo credentials.json dentro da pasta do projeto, pois agora vamos carregá-lo na nossa aplicação. Abra o gdrive-auth.js e inclua o seguinte código, adaptado da documentação do Google Drive APIs:

//index.js
const fs = require('fs');
const readline = require('readline');
const {google} = require('googleapis');

// If modifying these scopes, delete token.json.
const SCOPES = ['https://www.googleapis.com/auth/drive.metadata.readonly'];
// The file token.json stores the user's access and refresh tokens, and is
// created automatically when the authorization flow completes for the first
// time.
const TOKEN_PATH = 'token.json';

function callGDriveApi(callback){
    // Load client secrets from a local file.
    fs.readFile('credentials.json', (err, content) => {
    if (err) return console.log('Error loading client secret file:', err);
    // Authorize a client with credentials, then call the Google Drive API.
        if(callback)
            authorize(JSON.parse(content), callback);
        else
            authorize(JSON.parse(content), listFiles);//default
    });
}

/**
 * Create an OAuth2 client with the given credentials, and then execute the
 * given callback function.
 * @param {Object} credentials The authorization client credentials.
 * @param {function} callback The callback to call with the authorized client.
 */
function authorize(credentials, callback) {
  const {client_secret, client_id, redirect_uris} = credentials.installed;
  const oAuth2Client = new google.auth.OAuth2(
      client_id, client_secret, redirect_uris[0]);

  // Check if we have previously stored a token.
  fs.readFile(TOKEN_PATH, (err, token) => {
    if (err) return getAccessToken(oAuth2Client, callback);
    oAuth2Client.setCredentials(JSON.parse(token));
    callback(oAuth2Client);
  });
}

/**
 * Get and store new token after prompting for user authorization, and then
 * execute the given callback with the authorized OAuth2 client.
 * @param {google.auth.OAuth2} oAuth2Client The OAuth2 client to get token for.
 * @param {getEventsCallback} callback The callback for the authorized client.
 */
function getAccessToken(oAuth2Client, callback) {
  const authUrl = oAuth2Client.generateAuthUrl({
    access_type: 'offline',
    scope: SCOPES,
  });
  console.log('Authorize this app by visiting this url:', authUrl);
  const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout,
  });
  rl.question('Enter the code from that page here: ', (code) => {
    rl.close();
    oAuth2Client.getToken(code, (err, token) => {
      if (err) return console.error('Error retrieving access token', err);
      oAuth2Client.setCredentials(token);
      // Store the token to disk for later program executions
      fs.writeFile(TOKEN_PATH, JSON.stringify(token), (err) => {
        if (err) return console.error(err);
        console.log('Token stored to', TOKEN_PATH);
      });
      callback(oAuth2Client);
    });
  });
}

/**
 * Lists the names and IDs of up to 10 files.
 * @param {google.auth.OAuth2} auth An authorized OAuth2 client.
 */
function listFiles(auth) {
  const drive = google.drive({version: 'v3', auth});
  drive.files.list({
    pageSize: 10,
    fields: 'nextPageToken, files(id, name)',
  }, (err, res) => {
    if (err) return console.log('The API returned an error: ' + err);
    const files = res.data.files;
    if (files.length) {
      console.log('Files:');
      files.map((file) => {
        console.log(`${file.name} (${file.id})`);
      });
    } else {
      console.log('No files found.');
    }
  });
}

callGDriveApi();

module.exports = callGDriveApi;

100

//index.js

const fs = require('fs');

const readline = require('readline');

const {google} = require('googleapis');

// If modifying these scopes, delete token.json.

const SCOPES = ['https://www.googleapis.com/auth/drive.metadata.readonly'];

// The file token.json stores the user's access and refresh tokens, and is

// created automatically when the authorization flow completes for the first

// time.

const TOKEN_PATH = 'token.json';

function callGDriveApi(callback){

// Load client secrets from a local file.

fs.readFile('credentials.json', (err, content) => {

if (err) return console.log('Error loading client secret file:', err);

// Authorize a client with credentials, then call the Google Drive API.

if(callback)

authorize(JSON.parse(content), callback);

else

authorize(JSON.parse(content), listFiles);//default

});

}

/**

* Create an OAuth2 client with the given credentials, and then execute the

* given callback function.

* @param {Object} credentials The authorization client credentials.

* @param {function} callback The callback to call with the authorized client.

function authorize(credentials, callback) {

const {client_secret, client_id, redirect_uris} = credentials.installed;

const oAuth2Client = new google.auth.OAuth2(

client_id, client_secret, redirect_uris[0]);

// Check if we have previously stored a token.

fs.readFile(TOKEN_PATH, (err, token) => {

if (err) return getAccessToken(oAuth2Client, callback);

oAuth2Client.setCredentials(JSON.parse(token));

callback(oAuth2Client);

});

}

/**

* Get and store new token after prompting for user authorization, and then

* execute the given callback with the authorized OAuth2 client.

* @param {google.auth.OAuth2} oAuth2Client The OAuth2 client to get token for.

* @param {getEventsCallback} callback The callback for the authorized client.

function getAccessToken(oAuth2Client, callback) {

const authUrl = oAuth2Client.generateAuthUrl({

access_type: 'offline',

scope: SCOPES,

});

console.log('Authorize this app by visiting this url:', authUrl);

const rl = readline.createInterface({

input: process.stdin,

output: process.stdout,

});

rl.question('Enter the code from that page here: ', (code) => {

rl.close();

oAuth2Client.getToken(code, (err, token) => {

if (err) return console.error('Error retrieving access token', err);

oAuth2Client.setCredentials(token);

// Store the token to disk for later program executions

fs.writeFile(TOKEN_PATH, JSON.stringify(token), (err) => {

if (err) return console.error(err);

console.log('Token stored to', TOKEN_PATH);

});

callback(oAuth2Client);

});

}

/**

* Lists the names and IDs of up to 10 files.

* @param {google.auth.OAuth2} auth An authorized OAuth2 client.

function listFiles(auth) {

const drive = google.drive({version: 'v3', auth});

drive.files.list({

pageSize: 10,

fields: 'nextPageToken, files(id, name)',

}, (err, res) => {

if (err) return console.log('The API returned an error: ' + err);

const files = res.data.files;

if (files.length) {

console.log('Files:');

files.map((file) => {

console.log(`${file.name} (${file.id})`);

});

} else {

console.log('No files found.');

}

});

}

callGDriveApi();

module.exports = callGDriveApi;

Basicamente o que temos aqui é o código que implementa a autenticação OAuth offline. Ou seja, a sua aplicação vai solicitar um token para a sua conta do Google Drive, que vai ser utilizada pela sua aplicação. Mais tarde usaremos este módulo para chamar a API do GDrive.

Ao executar esse código pela primeira vez no console (node gdrive-auth) você receberá uma URL que deve ser acessada. Copie a URL e ao acessar a página no navegador, você verá a sua conta do Google e ela vai lhe questionar se você quer conceder acesso à essa aplicação Node (Quickstart). Fornecendo a permissão você receberá o token que deve ser informado no terminal novamente, para que seja gravado.

Se tudo ocorrer bem, um teste deve ser realizado automaticamente listando os 10 últimos arquivos adicionados na sua conta do GDrive. Com isso temos um projeto configurado e autenticado para acessar as APIs do Google Drive (essa autenticação é feita apenas uma vez, para obter o arquivo token.json, que fica na raiz da sua aplicação).

Atenção: o escopo da permissão que solicitamos é para gerenciar pastas e arquivos enviados pela própria aplicação. Sendo assim, no primeiro teste não será listado nenhum arquivo pois a aplicação não criou nada ainda. Nos testes subsequentes, no console serão listados os arquivos que já fizemos upload.

Se precisar mudar o escopo de permissão (na variável SCOPES), certifique-se também de excluir o arquivo token.json para que o processo de autenticação reinicie corretamente e ele seja criado com as permissões corretas.

Enviando uma imagem

Agora vamos criar outro módulo no nosso projeto, em um arquivo gdrive.js, com o seguinte conteúdo, adaptado também da documentação oficial:

const fs = require("fs");
const {google} = require('googleapis');

function imageUpload(fileName, filePath, callback){
    require("./gdrive-auth")((auth) => {
        const fileMetadata = {
            name: fileName
        };

        const media = {
            mimeType: "image/jpeg",
            body: fs.createReadStream(filePath)
        }
        
        const drive = google.drive({version: 'v3', auth});
        drive.files.create({
            resource: fileMetadata,
            media: media,
            fields: 'id'
          }, function (err, file) {
            if (err) {
              // Handle error
              console.error(err);
            } else {
              callback(file.data.id);
            }
          });
    });
}

module.exports = { imageUpload };

const fs = require("fs");

const {google} = require('googleapis');

function imageUpload(fileName, filePath, callback){

require("./gdrive-auth")((auth) => {

const fileMetadata = {

name: fileName

};

const media = {

mimeType: "image/jpeg",

body: fs.createReadStream(filePath)

}

const drive = google.drive({version: 'v3', auth});

drive.files.create({

resource: fileMetadata,

media: media,

fields: 'id'

}, function (err, file) {

if (err) {

// Handle error

console.error(err);

} else {

callback(file.data.id);

}

});

}

module.exports = { imageUpload };

Neste módulo nós usamos o módulo anterior, de autenticação, e depois enviamos uma imagem passada como argumento para o GDrive criar ela idêntica na nuvem. O argumento fileName é apenas o nome da imagem enquanto que o filePath é o caminho relativo ou literal. Após a criação, será executado um callback com o ID do arquivo no GDrive que acabamos de criar.

Caso queira fazer upload de outros arquivos que não sejam imagens JPG, basta trocar o mime-type.

Agora que temos um módulo de autenticação e um de upload de imagem, vamos criar um index.js para realizar alguns testes:

//index.js
const gdrive = require("./gdrive");
gdrive.imageUpload("imagem.jpg", "./imagem.jpg", (id) => {
    console.log(id);
});

//index.js

const gdrive = require("./gdrive");

gdrive.imageUpload("imagem.jpg", "./imagem.jpg", (id) => {

console.log(id);

});

Aqui estou considerando que você tem um arquivo chamado imagem.jpg dentro da pasta do projeto, no mesmo nível dos módulos. Rode essa aplicação com “node index” e você deve encontrar o novo arquivo na sua conta do GDrive, na raiz do mesmo.

Agora, com as adaptações certas, você pode usar esse módulo em uma web API Express ou mesmo com algum outro framework do Node, para compor uma solução de verdade.

Espero que tenha gostado!

Curtiu o tutorial? Para mais conteúdos bacanas em texto e videoaulas, conheça o meu curso de Node.js e MongoDB clicando no banner abaixo.

Gerenciando Product Backlog usando o Azure DevOps (TFS)

Atualizado em 18/03/19 após a mudança do Visual Studio Online para Azure DevOps!

Quando começamos a estudar o Scrum Guide logo nos deparamos com o artefato Product Backlog. O framework prescreve que o Product Owner deve manter este artefato com todos os itens necessários ao produto/projeto a ser desenvolvido, de maneira priorizada, atualizada e visível.

No entanto, algo que o framework não prescreve é como fazer isso e a ideia do post de hoje é justamente essa, mostrar uma ideia de como organizar o seu Product Backlog usando a ferramenta Azure DevOps, a versão mais recente do antigo Team Foundation Server da Microsoft (TFS), em sua versão SaaS. Não vou falar aqui de priorização de backlog, coisa que já falei em outros posts, mas de como usar esta ferramenta web para fazê-lo e explicando alguns conceitos importantes que podem ser aplicados independente da ferramenta que você venha a utilizar.

Azure DevOps

Em idos de 2008 a empresa que eu trabalhava à época, RedeHost, adquiriu licença para instalarmos em um servidor nosso o Team Foundation Server, uma suíte para gerenciamento do ciclo de vida de aplicações (ALM – Application Lifecycle Management). Nela podíamos gerenciar desde as tarefas de um projeto, o versionamento de seu código, automatizar o seu build, issue tracker, etc.

Em 2010 a Microsoft lançou o preview do TFS na nuvem, em versão SaaS, onde era possível ter acesso à mesma suíte sem necessitar de um servidor local e sem se preocupar com a escala do SQL Server, que era um requisito que incomodava bastante nosso pessoal de infra. De lá pra cá a ferramenta web mudou bastante e, embora não seja uma ferramenta perfeita, é muito útil para gerenciar todo tipo de projeto, independente da tecnologia utilizada, uma vez que oferece suporte a versionamento com Git, diversos plugins, uma API rica e muito mais.

Note que mesmo que você não tenha interesse algum nestas features de Integração Contínua (CI – Continuous Integration), você ainda pode usar a ferramenta para Task Management.

Para poder prosseguir neste tutorial, crie uma conta gratuita definindo uma URL para você. A minha é luiztools.visualstudio.com e tenho essa conta há muitos anos, desde a época do preview. Enquanto você tiver até 5 usuários cadastrados na sua conta, você não terá de pagar nada à Microsoft, o que é excelente para pequenos times de desenvolvimento.

Criando um novo projeto

Na tela inicial da ferramenta você tem um botão New Project no canto direito. Use ele e defina um nome para o projeto. Se você tem apenas um time que toca diversos projetos, pode ser interessante colocar o nome do time aqui, ao invés do nome do projeto atual deles, para fins de histórico.

Na seção Advanced da criação do projeto você tem outras opções que incluem a tecnologia de versionamento (que eu deixo para você decidir) e o template de Work Items dentre os possíveis:

CMM: fundamentado no CMMI;
Agile: fundamentado no antigo MSF for Agile da Microsoft;
Scrum: fundamentado no Scrum;
Basic: não conheço;

Usaremos o Scrum neste tutorial e enquanto o primeiro eu nunca usei, os dois últimos são praticamente idênticos, mudando alguns estados e a nomenclatura de alguns Work Items (User Stories do Agile viram Product Backlog Items no Scrum, por exemplo).

Uma vez com o projeto criado, acesse o menu lateral Boards > Backlogs. É aqui que concentramos os nossos esforços neste artigo.

Organizando o Product Backlog

Nesta área nós temos acesso a um modelo de gerenciamento de backlog prescrito pela ferramenta, uma vez que o framework Scrum não toma partido do método A ou B de gerenciamento de backlog.

Existem diversos níveis de backlog que auxiliam o Product Owner (principalmente) a se organizar. Para ver todos os níveis, use o pequeno ícone de Settings na extrema direita da tela (uma engrenagem), logo acima das colunas do backlog. Dentro das configurações, na aba Backlogs, marque as três opções: Epics, Features e Product Backlog Items.

Os três níveis de Backlog são Epics, Features e Product Backlog Items, à saber:

Epics: épicos são histórias de usuário muito grandes e pouco detalhadas, geralmente levando várias sprints para ser concluído (pense na grandeza de meses de trabalho). Você pode criar épicos pensando em marcos/milestones/grandes versões do seu produto/projeto, como “MVP do Produto X” ou como grandes entregas do seu time, como “Entrega de Março”. Ou ainda falando de um módulo específico, que seja muito grande.
Features: funcionalidades são incrementos de software dentro de um épico, simbolizando partes coerentes do produto que geram valor ao usuário de uma maneira completa. Dentro de um épico como “MVP do Produto X”, cada funcionalidade que não deve faltar ao MVP é uma feature dentro do épico. O mesmo vale para o épico “Entrega de Março”, onde cada feature é um dos pedaços desta entrega.
Product Backlog Items: os famosos itens de backlog do produto são citados no Scrum Guide como sendo a unidade de trabalho do Product Backlog. Um PBI gera valor ao usuário por si só e entregar um ou mais deles pronto (DONE) atinge ao grau máximo de sucesso de uma sprint, o chamando “incremento de software potencialmente entregável”. Embora o Scrum não prescreva uma fórmula para escrever esses itens, o mais comum é que se use o formato de User Stories aqui.

O formato recomendado de escrita é partir do Work Item Type menos granular (Epic) até o mais granular (Product Backlog Item), usando o próprio recurso de “Add Feature”que fica à disposição à esquerda do Epic e “Add Product Backlog Item” que fica à esquerda das Features, sempre com um ícone de adição (+). Sendo assim, acesse o nível Epic do seu Product Backlog e comece criando os seus épicos com apenas títulos. Mais tarde você pode adicionar mais detalhes a cada um deles (mas não muito, eles são apenas visões) clicando no título dos mesmos.

Após adicionar os seus épicos, adicione features dentro de cada um deles, de acordo com o que você sabe hoje sobre os épicos. Faça isso na mesma visão organizacional de Epics, para ir vendo os desdobramentos e hierarquia dos mesmos. Para este exercício, pegue um projeto real do seu time ou então um problema fictício como um cadastro de cliente. O épico seria fazer a v1 do cadastro, sendo que as features poderiam ser “Adicionar novo cliente”, “Excluir cliente”, etc.

Conforme você for adicionando as features dentro do épico você já pode ir quebrando seus Product Backlog Items (PBIs). Se você atendeu à minha sugestão de usar User Stories, pense em todos as histórias de usuário que puder lembrar para cada uma das features. Algumas features simples talvez tenham apenas uma história, enquanto outras mais complicadas podem ter várias. Não esqueça de, além de escrever o título e descrição da história (usando o formato padrão da User Story), escreva também os critérios de aceite no campo adequado (Acceptance Criteria).

É importante ter em mente que o Product Owner tem total liberdade neste momento. Crie, edite e exclua seus Work Items livremente. É comum escrevermos algumas histórias que mais tarde descobrimos serem épicos. É comum épicos serem quebrados em mais épicos para que o sistema não vire um mero waterfall-iterativo. Questões relacionadas a prioridades de itens podem ser feitas usando o campo Priority ou a própria ordenação visual (drag-n-drop com o mouse). Embora o time tenha acesso ao Product Backlog como um todo, não é a partir dele que eles se orientarão no dia-a-dia, como falarei mais adiante.

Organizando as sprints

A visão de backlog que usamos até o momento são de foco do Product Owner. O Time de Desenvolvimento trabalha usando a visão da sprint atual (current sprint) dentro do Visual Studio Online. A visão das sprints fica em Boards > Sprint no menu lateral, sendo que você tem um menu para filtrar as sprints na direita da tela (current é a atual).

Durante a Sprint Planning o Product Owner explica quais são as prioridades do Product Backlog. Sobre cada história prioritária, o time deve detalhar quais as tarefas serão necessárias para que seja possível estimar o esforço (campo Effort) de entrega daquele Product Backlog Item.

Uma técnica muito comum utilizada para estas estimativas é a de Planning Poker, já citada aqui no blog. Caso o Time de Desenvolvimento julgue útil, eles podem “quebrar” os Product Backlog Items em Tasks dentro da própria ferramenta usando o botão de + (Add Task) à esquerda do PBI, na mesma visão que o Product Owner usa para gerenciar o backlog.

Existe um campo Work Remaining dentro das Tasks que permite adicionar a estimativa de tempo para realização de cada tarefa. Se você optar por quebrar e/ou estimar as tarefas é uma decisão do time, mas essa atividade é auxiliar para descobrir o esforço da história. Entende-se que somente a entrega completa da história agrega valor ao cliente e consequentemente nos permite dar uma sprint como bem sucedida.

Após descobrir o esforço de cada um dos PBIs prioritários do P.O., o time decide qual o volume de PBIs que cabem na sprint usando o somatório de seus campos Effort. Se esse time já rodou sprints anteriores usando a mecânica de pontos eles já devem ter algum histórico de velocidade. Caso contrário terão de chutar mesmo, posteriormente analisando na Sprint Retrospective o quão próximo estavam da realidade.

Uma vez definido o escopo da próxima sprint, cada uma das Tasks e PBIs que farão parte da mesma devem ter seu campo Iteration ajustado para a sprint correta, como mostra a imagem abaixo.

Iteration - Sprint 1 — Iteration – Sprint 1

O Time de Desenvolvimento irá trabalhar somente olhando o backlog da sprint que, via de regra, não deve ser mudado durante o desenvolvimento da mesma sem o consentimento do time. Na aba Board o time tem um taskboard (tipo Kanban) que apesar de não ser tão bom de usar quanto o Trello, é bem útil e completamente personalizável, o que pode ser assunto para outro post.

Boas Práticas

Algumas boas práticas para quem está começando a usar o Visual Studio Online agora e até mesmo está começando com Scrum:

Como Product Owner, refine o seu backlog quase que diariamente, detalhando as histórias mais importantes, consultando o time sobre o impacto de cada uma delas, consultando os stakeholders, analisando o mercado, etc. O seu backlog sempre deve estar atualizado, priorizado e visível quando uma Sprint Planning for começar.
Cada história pode estar associada a um membro do time (campo Assigned To). Converse com seu time para que ninguém associe mais de uma história a si mesmo para evitar problemas.
Como Product Owner, use os três níveis de backlog, isso ajuda a deixar tudo mais organizado e ao time entender para onde o projeto está caminhando.
Priorize visualmente o seu backlog, deixando o que é mais prioritário no topo. Apesar de existir um campo Priority, ele é facilmente negligenciado por não ser muito visual.
Use o padrão de User Stories em seus PBIs para focar na entrega de valor para o usuário final e facilitar o entendimento dos requisitos por parte do Time de Desenvolvimento.
Estime em Story Points as suas histórias e não em horas. Isso tem uma série de benefícios mas principalmente descola alguns conceitos de chão de fábrica como produtividade em horas.
use Tags (tem um campo pra isso) nos seus PBIs para facilitar consultas, relatórios e dashboards mais tarde (aba Queries e Dashboards). Use a imaginação, tags podem ser qualquer coisa.
não se preocupe em usar tudo que a ferramenta oferece, aprenda o básico que faz sentido pra você e depois vá usando o restante conforme for necessitando. Uso o TFS desde 2008 e até hoje tem coisas lá que nunca precisei.

Espero que tenham gostado do post e até a próxima!

Neste artigo ensino como manter um bom nível de qualidade e detalhamento do backlog.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!