Planning Poker: como estimar tempo de desenvolvimento de software

Meu baralho de Scrum Poker
Meu baralho de Scrum Poker

No mundo do desenvolvimento de software, poucas coisas são tão difíceis quanto estimar o tempo de desenvolvimento de um projeto. Existe inúmeras técnicas, métodos, ferramentas e abordagens, mas em sua maioria, elas falham ao serem unilaterais: o gerente do projeto estima quanto tempo cada tarefa vai levar (usando seu método favorito), soma as tarefas e diz ao time que eles tem de desenvolver o “Google” nos próximos 30 dias. Quem nunca passou por esse tipo de situação?

O Planning Poker (Pôker de Planejamento), ao contrário, conduz o time a encontrar métricas que funcionem para todos e a construir o escopo do que será feito na próxima fase de desenvolvimento de maneira colaborativa. Ok, o gerente ainda tem um papel essencial aqui: o de priorizar o que deve ser feito primeiro, mas não é ele quem decide quanto tempo o time vai levar para realizar seu intento. Apenas o time pode decidir isso. Soa estranho? Mas não deveria…

Invenção oriunda do mundo dos Métodos Ágeis de desenvolvimento de software (como o Scrum), o Planning Poker parte do pressuposto que somente os responsáveis por executar uma tarefa podem dizer quanto tempo ela vai levar para ser desenvolvida. E ninguém mais. Isso por duas razões básicas:

  • O Planning Poker incentiva a colaboração e, dessa maneira, os prazos estimados serão lapidados por todos do time ao longo do processo (como verá mais adiante), ajudando a mitigar erros de estimativas de gerentes otimistas ou de programadores pessimistas.
  • Uma vez que todos colaboram no processo de estimativa, existe um sentimento de comprometimento compartilhado com o projeto. Se o time não entregar no prazo, a culpa pelo atraso é inteiramente deles, uma vez que o prazo não foi dado pela gerência.

Quem não gosta da técnica tende a argumentar que o Planning Poker é uma arma na mão de equipes preguiçosas, que a palavra final não deveria ser dos desenvolvedores que podem querer “jogar” as métricas para o alto para ganhar mais tempo. Mas aí eu pergunto: o culpado é o Planning Pôker? Ou é o seu time preguiçoso? Não culpe a ferramenta pela pela imperícia do usuário…

 

Poker?

O Poker no nome vem por conta de as estimativas serem feitas com um baralho. Não um barulho comum, mas um que usa a Sequência de Fibonacci (ou um cálculo próximo dela). Pra quem não conhece, a Sequência de Fibonacci é mais uma invenção (ou seria melhor dizer “formalização”?) feita por um matemático italiano para descrever o comportamento do crescimento de uma população de coelhos. Daí para ser usada em estimativas de projetos é um pulo (com o perdão da referência), uma vez que o crescimento dos números (e consequentemente do prazo) vai se tornando exponencial conforme a complexidade do software aumenta e nos leva para o desconhecido.

Na Sequência, que começa com os números inteiros 0 e 1, cada número é resultado da soma dos dois números anteriores, ou seja, temos 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…No baralho de Planning Poker essa escala foi simplificada, mas a ideia é essa mesmo. Conforme a complexidade e o tamanho de um software aumentam, não há como dizer com precisão quanto tempo vai levar para desenvolvê-lo. E antes de torcer o nariz para o que estou dizendo, vai por mim, estou há 10 anos nesse ramo. Já vi um bocado de projetos estourarem prazo pela gerência não querer entender que não dá para estimar o desconhecido com precisão.

Mas voltando ao baralho, a escala usada nos gera as seguintes cartas:

0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?

Algumas variações também incluem uma carta para o infinito, e outra para o café, algumas vezes removendo a carta 100. Vou explicar cada uma mais adiante.

Cada jogador (i.e. desenvolvedor do time) deve ter um desses baralhos no dia em que for feita a estimativa do tempo que o projeto irá levar.

 

Como funciona?

Primeiramente existe um tema de casa que deve ser feito pelo gerente do projeto e/ou pelo analista de sistemas, dependendo de como isso está organizado na sua empresa. Obviamente o Planning Poker funciona melhor caso a empresa já esteja adotando métodos ágeis no desenvolvimento de seus projetos e, no caso do Scrum, o Scrum Master deve sentar com o Product Owner antes da Sprint Planning para elucidar as tarefas e ver quais são as prioridades para a próxima Sprint.

Uma vez que o Product Backlog está organizado, o Scrum Master (que não joga Poker) senta junto com o time com o topo do Product Backlog priorizado e quebrado em tarefas. A dinâmica funciona da seguinte maneira, para cada uma das tarefas (que podem ser cards, caso esteja usando Kanban) executamos essas ações:

1) O Scrum Master lê a tarefa em voz alta e responde dúvidas dos desenvolvedores, cada qual com seu baralho de Planning Poker em mãos. O ideal é que ele comece com a tarefa mais fácil de todas, para que possamos usar ela como referência depois, para estimar as demais.

2) Cada desenvolvedor escolhe uma carta do seu baralho, em segredo, baseado no quão complexo acha a tarefa. Aqui vale uma explicação sobre as cartas numéricas (os valores em horas são apenas para ter uma ideia):

  • Carta 0: a tarefa não precisa ser feita por algum motivo (talvez já esteja pronta)
  • Carta 1: a tarefa é muito, mas muito simples, provavelmente menos de 1h de desenvolvimento de qualquer da equipe
  • Carta 2: a tarefa é simples, provavelmente leve menos de um turno de trabalho, como uma manhã por exemplo.
  • Carta 3: a tarefa é simples, mas trabalhosa e não deve ser subestimada ocupando pelo menos um turno de trabalho, como uma tarde (geralmente é mais longa que uma manhã).
  • Carta 5: a tarefa é de complexidade mediana, provavelmente tomando um dia de trabalho de um desenvolvedor, se não tiver impedimentos
  • Carta 8: a tarefa é complexa, vai demandar algum estudo ou muito desenvolvimento, provavelmente tomando alguns dias da semana, com 2 ou 3 no máximo.
  • Carta 13: a tarefa é muito complexa, vai demandar estudo moderado ou é apenas muito longa de desenvolver, levando em média uma semana de um desenvolvedor (5 dias úteis)
  • Carta 20 em diante: a tarefa é complexa demais e não vale a pena ser estimada. Sugere-se quebrar a tarefa em tarefas menores, que possam ser estimadas com mais exatidão
  • Carta Interrogação (?): não entendi a tarefa sr. Scrum Master, pode lê-la de novo e dar mais detalhes?
  • Carta Infinito (quando houver, caso contrário, use a 100): não temos como fazer esta tarefa sr. Scrum Master, ela é longa demais e não cabe em qualquer pipeline de desenvolvimento. Sugiro quebrarmos ela em tarefas menores ou dizer ao Product Owner que não tem como fazermos (mais raro).
  • Carta Café (ou Cerveja em algumas empresas): estou cansado de tanto estimar, que tal tomarmos um café e depois voltamos?

3) Depois que todos escolhem suas cartas em segredo, revelam-se as escolhas sendo que o Scrum Master é o facilitador dessa dinâmica. Compara-se os resultados e:

  • Se todos forem iguais, anota-se o número obtido junto à tarefa e reinicia-se a dinâmica com a próxima tarefa a ser estimada.
  • Se houverem divergências, o desenvolvedor que escolheu a carta com menor valor justifica sua posição. Depois o desenvolvedor que escolheu a maior carta justifica sua posição. O Scrum Master também é convidado a explicar melhor esta tarefa. Todos jogam novamente.
  • O ideal é sempre chegar em um consenso, mas dependendo do tamanho do time isso não será possível. Assim, considera-se que se a distância entre o maior e o menor valor jogados não passar de duas cartas, assume-se uma média (Fonte: livro do Jeff Sutherland).

4) Depois que todas as tarefas prioritárias foram estimadas (ou ao menos que o feeling lhe diga que já passaram tempo demais estimando tarefas) o time de desenvolvimento, baseado nas prioridades, seleciona quais tarefas ele se compromete a executar nessa Sprint (obviamente de acordo com o tamanho da Sprint que varia de 15 dias a 1 mês usualmente).

E é isso. Simples, não?!

Mas e o tempo?

Note que não existe um cálculo mágico para converter os pontos do Planning Poker em horas de trabalho, mas que depois de duas ou três sprints é comum o time encontrar um consenso e descobrir a sua velocidade, sendo que o Scrum Master deve auxiliar nesse processo de descoberta. Os tempos estimados que menciono junto às cartas são apenas uma ideia de valores que funcionam para os times de desenvolvimento com os quais trabalhei. No fundo, os números do Planning Poker são uma medida relacional, conforme mencionei na etapa 1, geralmente sendo usadas as tarefas mais fáceis para estimar as mais difíceis. Perguntas como: “A tarefa x é mais difícil que a y, que estimamos em z?” norteiam as jogadas pois é mais fácil estimar empiricamente, baseados em nosso conhecimento prévio, do que pensando no futuro.

Um ponto importante que vale ressaltar é que as métricas são coletivas, ou seja, a responsabilidade é de todos e não apenas do desenvolvedor que provavelmente irá pegar a tarefa pra si. Assim, não vale jogar qualquer carta apenas porque você acha que não terá de botar a mão naquela tarefa. Afinal, se o time falhar em entregar no prazo, a culpa será de todos, pois foi o time que estimou as tarefas.

E por fim, é válido comentar novamente que o Planning Poker funciona melhor no mundo agile, principalmente quando usado em conjunto de um Kanban e de um Burndown Chart. Geralmente ao término da Sprint Planning o Scrum Master organiza as tarefas do Sprint Backlog em cards no Kanban (se ainda não o fez) e constrói o Burndown Chart baseado no número de pontos da soma das tarefas desta sprint versus o tempo da Sprint. Pretendo falar destas duas ferramentas em outros posts aqui no blog em breve, pois elas são muito importantes para os pilares de inspeção e adaptação do Scrum, que mencionei neste post.

Ah, e se você buscar por Planning Poker no Google Imagens, irá encontrar diversas imagens prontas para impressão e uso na sua empresa, semelhante as que usei para ilustrar o post.

* 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!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Como criar Retrospectivas de Sprint que funcionam?

O Scrum é um framework ágil de gerenciamento de projetos que envolvem produtos complexos, geralmente usado em equipes de software, embora existam diversas adaptações para outros tipos de times. Costuma-se dizer que o Scrum é simples de entender, mas difícil de aplicar e embora esse paradoxo soe confuso, é exatamente isso. Em partes isso se deve à total necessidade de se aplicar seus três pilares: transparência, inspeção e adaptação, e em partes devido à sua simplicidade de definir poucas reuniões e poucos artefatos, muitas vezes lhe deixando sem ideias de como facilitar (enquanto Scrum Master) reuniões como a Retrospectiva da Sprint (Sprint Retrospective).

Neste post quero dar uma boa ideia nesse sentido, de como conduzir uma Retrospectiva de Sprint que realmente funcione segundo os pilares do Scrum.

Depois de ler e se quiser saber mais sobre o meu trabalho com Scrum, dê uma olhada no livro que escrevi.

Sprint Retrospective

O que é?

A Retrospectiva da Sprint, segundo o próprio Scrum Guide, é:

A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

Ou seja, de todas time-boxes do Scrum, certamente a Sprint Retrospective é a mais alinhada com os pilares da Inspeção e Adaptação, pois esse é o seu cerne. Já vi muitas equipes não realizarem as retrospectivas e portanto não evoluírem seus processos de gerenciamento e desenvolvimento de software. As pessoas tendem a ignorar que o maior motivo de termos tantos softwares inúteis ou mal acabados é por falta de comunicação, seja com o cliente, com o chefe ou entre os desenvolvedores. E a retrospectiva é justamente uma oportunidade formal da equipe se comunicar e se aprimorar enquanto time ágil.

Principalmente os programadores, profissionais das ciências exatas, não gostam da ideia de “perder tempo” falando sobre os problemas do time ou pensando em processos, quando poderiam estar programando, que é o que gostam de fazer. Esse pensamento imaturo persistiu na minha mente durante alguns anos no início da minha carreira até que eu percebi que o software pelo software não adianta de nada. Que o que fazia (programar) era apenas um meio, e não o fim. Se meu software não solucionasse o problema do cliente, ele era apenas um monte de lixo, por mais tempo e esforço que eu tivesse colocado em seu desenvolvimento.

Parar e refletir sobre os objetivos e sobre os processos necessários para chegar lá é vital para a eficiência (e muitas vezes para eficácia também) do time.

sprint_retrospective1

Como facilitar esta reunião?

Como todas reuniões, o Scrum Master deve ser o facilitador desta reunião de até 3h para Sprints de um mês. Ele deve convocar o time, explicar o motivo da reunião e apenas auxiliar o andamento da mesma e o respeito ao tempo limite. Somente o time de desenvolvimento (segundo a ótica do Scrum, todos que não são PO ou Scrum Master são desenvolvedores) que realmente “participa” da reunião. A dinâmica abaixo é um exemplo de como ela pode ser conduzida, uma vez que o Scrum Guide apenas dá linhas gerais, sem um exemplo prático.

Escolha uma sala da empresa com quadro branco com canetas marcadoras (também chamados de “caneta para quadro branco” ou “pincéis atômicos”) ou na ausência desse recurso, um mural que possa ser riscado já serve. Vamos precisar também de post-its (se tiver 3 cores diferentes, melhor) e canetas esferográficas comuns. Na ausência de post-its, recorte pequenos cartões do tamanho de um cartão de visita que já resolve. Um bom número é 3 cartões/post-its por pessoa do time de desenvolvimento.

Divida o quadro/mural em três colunas: BOM, MELHORAR e AÇÕES.

Na coluna BOM devemos colocar cartões com aquilo que foi executado e que deu certo, que a equipe deveria manter na próxima sprint como uma boa prática.

Na coluna MELHORAR devemos colocar cartões com aquilo que foi executado de maneira ruim e que pode melhorar na próxima sprint.

Para cada coisa que precisa melhorar, deve existir um registro na coluna AÇÕES com uma ação concreta e factível para o mesmo. Tem que ser algo que possa de fato ser colocado em prática, preferencialmente que alguém da equipe se comprometa pessoalmente de que não irá acontecer na próxima sprint.

As regras de preenchimento são: apenas um fala por vez, e somente aquele que estiver portando um token, que geralmente é um marcador de quadro branco ou caneta, previamente escolhida. Quando a pessoa fala (o que não deve demorar mais de 1 minuto por pessoa) o que deseja, ela escreve em um cartão/post-it de forma resumida e gruda no quadro/mural na na coluna que tem a ver com sua contribuição. A próxima pede o token para poder começar a falar até que todos tenham falado ao menos uma vez.

Ao término da retrospectiva o Scrum Master coleta os dados e garante a cobrança dos indivíduos sobre as considerações para que não retornem a aparecer na próxima Sprint (principalmente as coisas que podem melhorar). É comum guardar os cartões para cobrança posterior ou ao menos uma foto do quadro completo, que permita zoom depois para ler os cartões.

retro

Ações Concretas

Talvez o ponto mais crítico da retrospectiva seja as ações definidas para melhorar o processo. Como Scrum Master, é seu dever garantir que os itens que “devem melhorar” não retornem na próxima retrospectiva, caso contrário o pilar da “adaptação” do Scrum não estará sendo aplicado e o processo, que deveria ser vivo, ficará estagnado. Via de regra, para cada item que está na coluna “MELHORAR” deve ter um item na coluna “AÇÕES” para resolver o problema. E aqui que mora o problema: as ações devem ser concretas.

O que diferencia uma ação concreta de uma abstrata?

Imagine que algo que deve melhorar é a comunicação com o PO, que representa o cliente da equipe. Que algumas features tiveram de ter retrabalho porque não atenderam às necessidades do cliente, sendo que trazer essas necessidades pro time é responsabilidade do PO que não esteve presente. Isso certamente deve melhorar para que a qualidade das entregas igualmente melhore. Assim, para esse item que deve melhorar devemos ter uma ação concreta para que não ocorra novamente. Certamente alguém irá sugerir “conversar mais com o PO”, mas note como isso é vago, em contraponto, uma ação concreta seria “marcar uma reunião semanal com o PO para alinhar a execução das features” e mais do que isso “definir que todas segundas-feiras às 11h teremos uma reunião de 30 minutos com o PO para mostrar como estão sendo desenvolvidas as features que estão em DOING no Kanban“. Percebe a diferença?

É difícil chegar nesse nível de ação concreta, mas é o que devemos buscar. Cabe ao Scrum Master tensionar a reunião para que as ações tenham esse nível de qualidade para que de fato elas sejam postas em práticas e o processo seja melhorado. Perguntas como: “Como? Quando? Quem?” devem ser instigadas até que a ação seja refinada neste nível de detalhe.

No entanto, um alerta: jamais defina ações, que por mais precisas que sejam e por mais boa intenção que tenham, sejam inexequíveis, isto é, não tenham como ser executadas. Quando uma ação é definida, o time inteiro está se comprometendo com ela e caso a ação seja impossível de ser realizada, haverá frustração quando os mesmos problemas voltarem a acontecer. Então defina ações que resolvam o problema e que sejam concretas, precisas, mas jamais inexequíveis.

Usando o mesmo exemplo anterior, do PO ausente, de nada adianta definir que as reuniões ocorrerão todas as segundas às 11h se o PO não pode nesse horário. Nesse caso, uma ação concreta mais facilmente executável seria “conversar hoje, logo após esta reunião, com o PO para definir um dia e horário semanal que ele possa estar presente na equipe para discutirmos o andamento das tarefas”. Mas note que ainda é uma ação precisa: hoje falaremos com ele, hoje marcaremos um dia e hora semanal na agenda dele para conversar com a gente.

E aí, mais confiante de aplicar Scrum na sua empresa?

* 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!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Treinamento Scrum em um post

Conheço e aplico métodos ágeis há pelo menos 6 anos, principalmente o framework empírico Scrum. Durante o final da minha faculdade a empresa onde trabalhava, RedeHost, necessitava urgente de uma reorganização dos seus processos de desenvolvimento de software e queriam que eu me tornasse um de seus líderes de desenvolvimento. Obviamente agarrei a oportunidade, que foi muito importante para minha carreira, e isso me rendeu uma ida à São Paulo participar da segunda turma de um treinamento latino-americano oficial da Scrum.org para desenvolvedores Scrum. O treinamento de uma semana foi incrível e me capacitou para tirar duas certificações na área de gerenciamento de projetos com métodos ágeis e passei a atuar como facilitador do framework Scrum na empresa, em treinamos e em consultorias (como esta).

No post de hoje resumo o famoso Scrum Guide, o livro de apenas 19 páginas que detalha tudo o que você precisa saber sobre o Scrum antes de passar a aplicá-lo em seu time de produto. No fim do post você encontra os slides do treinamento que aplico, disponíveis no Slideshare. Caso queira saber mais sobre o meu trabalho com Scrum, dê uma olhada em meu livro.

rugby-scrum

O que é Scrum?

A definição formal, cunhada pelos criadores Ken Schwaber e Jeff Sutherland, diz que:

Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

Entenda um framework como uma caixa de ferramentas. Scrum não é algo pronto que resolve todos seus problemas, mas sim um conjunto de processos que norteiam o desenvolvimento de produtos complexos.

Apesar de leve e simples de entender, Scrum é extremamente difícil de dominar, uma vez que envolve rigidez em sua aplicação. Implementações de Scrum que não seguem as regras previstas em seu manual são o que chamamos de Scrum flácido, e tendem a não alcançar o potencial máximo da metodologia.

Mas por que confiar e seguir cegamente este framework? Scrum é um processo empírico, baseado pura e simplesmente nas experiências passadas de seus criadores que desde o início da década de 90 aplicam Scrum em projetos de software com sucesso, já sendo uma das metodologias ágeis mais usadas no mundo. E uma vez que você se torna adepto do Scrum, o empirismo passa a fazer com que você respeite o processo cada vez mais e adicione novos processos e artefatos complementares baseados nas SUAS experiências com o mesmo.

Os Pilares

O Scrum se baseia em três pilares de sustentação, suas ideologias:

Transparência: aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados.

Inspeção: os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas.

Adaptação: se um ou mais aspectos de um processo desviou para fora dos limites aceitáveis ou produto não será inaceitável, o processo ou o material sendo produzido deve ser ajustado.

Sobre estes pilares o framework Scrum divide-se em papéis, eventos e artefatos.

Papéis

Os papéis dentro do time Scrum são:

Product Owner

É o responsável pelo ROI (retorne sobre o investimento) do projeto, é responsável por gerenciar e priorizar o Product Backlog (veja mais abaixo) e para que o Scrum funcione e ele consiga trabalhar, toda a organização deve respeitar as suas decisões. No mundo mais tradicional da gestão de projetos, o P.O. seria o Gerente de Produto (Product Manager).

O P.O. é membro do time scrum e deve estar presente e disponível para solucionar dúvidas do time em relação ao produto e ao backlog. Se esse papel for assumido por alguém da empresa do cliente, esta pessoa idealmente dever ter um canal de comunicação ininterrupto com o time de desenvolvimento, para que ele possa avançar sem atrasos.

Desenvolvedores

São os responsáveis por desenvolver o produto. O time de desenvolvedores (que não precisa e não deve ser composto apenas por desenvolvedores) é auto-gerenciável, multifuncional e compartilham a responsabilidade pelo sucesso ou fracasso do projeto.

O time de desenvolvimento é quem decide o quanto consegue entregar a cada iteração, para que haja comprometimento com a entrega.

Scrum Master

É o responsável por aplicar e garantir a adoção do Scrum dentro da equipe e até mesmo dentro da organização onde estão inseridos. Cabe ao Scrum Master, que é um líder-servidor, liderar o time para que os objetivos do Product Owner sejam alcançados e para que o time de desenvolvimento consiga avançar sem impedimentos, removendo-os quando necessário.

Todos os eventos Scrum são facilitados pelo Scrum Master da equipe, que idealmente não deve ter outra função paralela no time Scrum.

Eventos

O Scrum chama seus eventos de time-boxes, uma vez que são eventos de duração fechada. Um evento pode ser encerrado em tempo menor do que o previsto, mas nunca maior, e o Scrum Master deve garantir isso enquanto facilitador dos eventos. Permitir a extrapolação cria um sentimento inconsciente de impunidade e faz com a equipe não respeite os objetivos e o planejamento da Sprint. Por sua vez, falhas constantes em entregar os objetivos de uma Sprint forçarão o time de desenvolvimento em serem mais eficientes no planejamento, focarem mais nos objetivos e se comprometerem de maneira mais coerente com as entregas.

Sprint

As sprints são time-boxes de 1 mês ou menos e são o coração do Scrum. Durante o período da Sprint um incremento utilizável do produto é criado. Mas nem só de desenvolvimento vive a Sprint, fazendo parte da mesma também o planejamento, as reuniões diárias, a revisão e a retrospectiva.

Sprint Planning

Time-boxe de 8h para uma sprint de um mês, ou menos tempo de acordo com o tamanho da Sprint. Nesta reunião é onde o Product Owner é ouvido em relação às prioridades e os objetivos desta Sprint. É nela também onde o time irá deliberar sobre o que conseguem fazer nesta sprint em relação às necessidades do P.O., formalizando o Sprint Backlog, ou lista de coisas que serão feitas no próximo mês.

É comum o uso de artefatos externos ao Scrum nesta fase, como o Planning Poker, usado para estimar o custo de tarefas a serem realizadas. O ideal é que independente da técnica usada para estimar (pontos de função, por exemplo), que cada tarefa não ocupe um membro do time por mais de um dia. Se isso acontecer, veja como pode quebrar a tarefa grande em tarefas menores.

planningpoker

Outro artefato muito popular também é o kanban (especialmente usando Trello), um board onde temos colunas com cards, onde em cada card temos uma tarefa a ser realizada, previamente estimada. Cada coluna representa um estágio do ciclo de desenvolvimento de uma tarefa, tais como: TODO (para fazer), DOING (fazendo), Testing (testando) e DONE (pronto).

kanban-board-e60650d1-1

Daily Scrum

Time-boxe de 15 min que deve acontecer diariamente, sempre no mesmo local e horário para gerar consistência e evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e que popularmente é feita em pé (para evitar prolongamentos e distrações), cada membro do time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo.

A reunião diária é o método mais eficaz de alinhamento dos membros do time que tive a oportunidade de experimentar. Ela permite a descoberta rápida de problemas e desvios de curso e suas respectivas correções, por isso deve ser respeitada.

burndown-chart-formula

Artefatos passíveis de serem usados nessas reuniões incluem um Burndown Chart, que nada mais é do que um gráfico de features a serem desenvolvidas (eixo y, vertical) versus tempo da Sprint (eixo x, horizontal). O gráfico começa no alto do eixo y (ou seja, faltam todas features) e no ponto 0 do eixo x (ou seja, ainda tem todo o tempo da sprint sobrando) e deve ser atualizado diariamente com o progresso do time. Um Burndown Chart sempre visível garante o dia inteiro, todos os dias, que todos sabem o quanto falta para terminarem a sprint, e caso estejam longe do seu objetivo, de resolverem os problemas. A ideia aqui não é analisar o Burndown Chart na reunião diária, que é curta e deve se manter assim, mas apenas acompanhar rapidamente, também de maneira diária, o progresso do time.

Esse evento é um dos que representam o pilar de inspeção do Scrum.

Sprint Review

Time-box de 4h para sprints de 1 mês onde o incremento do produto, que está pronto pra uso, é apresentado ao Product Owner para apreciação. Também é na review (que deve ser facilitada pelo Scrum Master) que o Product Owner apresentará os números, gráficos e tudo o mais que for importante à equipe saber sobre o produto. Novas prioridades, movimentos do mercado, etc, tudo focado em manter os objetivos coerentes ao longo das sprints.

Essa é o evento que melhor representa o pilar de inspeção do Scrum.

Sprint Retrospective

Time-box e 3h para sprints de 1 mês onde o time de desenvolvedores e o Scrum Master (que atua apenas como facilitador) falam sobre os resultados obtidos na Sprint que passou e as lições tiradas a partir daí, para melhorar o processo, fortemente arraigado ao pilar de adaptação. Trato em mais detalhes desta importante reunião neste post.

Artefatos

O Scrum determina alguns poucos artefatos:

Product Backlog

Lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. Gerenciado única e exclusivamente pelo Product Owner, que o faz a todo momento, o product backlog deve ser mantido longe do time de desenvolvimento, para evitar dispersão.

Muitas empresas tem usado a ferramenta Trello para seus products backlogs. Já usei muito, mas atualmente uso só o Visual Studio Online.

project-management-trello

Sprint Backlog

Uma versão reduzida de backlog apenas com os itens que devem ser desenvolvidos nesta Sprint, retirados do backlog original. Também pode ser organizada em formato de kanban no Trello, mas em um board separado do Product Backlog.

Cabe ao time de desenvolvimento montar o Sprint Backlog com base nas prioridades do Product Owner e é sua responsabilidade dar cabo de todos itens até o fim da sprint, servindo o Scrum Master como um facilitador para que nada interrompa o ciclo de desenvolvimento.

Conclusões

É isso. O Scrum Guide tem apenas 19 páginas e esse post umas 2000 palavras. O Scrum é pequeno, mas difícil de ser posto em prática porque exige muita disciplina. Nos treinamentos que ministro aplico sempre um exercício prático aos alunos para enriquecer a experiência e vivenciar na prática, mesmo que por poucas horas, como funciona o ciclo de desenvolvimento de um produto usando Scrum. Não encontrei uma boa maneira de colocar o exercício aqui, mas se puder filmar da próxima vez que aplicar o treinamento, vou incluir o vídeo aqui.

Boa sorte aplicando o Scrum em sua empresa!

* 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!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis