Essa apresentação eu utilizei na empresa onde trabalho, para apresentar a equipe de desenvolvimento, os conceitos da reunião em pé (Stand up meeting ou daily), muito utilizada na gestão de projetos ágeis.
Essa apresentação eu utilizei na empresa onde trabalho, para apresentar a equipe de desenvolvimento, os conceitos da reunião em pé (Stand up meeting ou daily), muito utilizada na gestão de projetos ágeis.
Kanban é uma palavra de origem japonesa, cujo significado é “cartão visual”. Sua popularidade vem do Sistema Toyota de Produção, cujo mecanismo básico de operação consiste justamente nos cartões visuais. O principal objetivo é minimizar o tempo necessário para uma idéia se transformar em um ativo de software em produção (Fonte: Adaptworks).
Antes de montar meu primeiro quadro Kanban, pesquisei na Internet imagens de quadros para que eu encontrasse algum que fosse o mais adequado para a empresa. Encontrei vários e salvei todos no meu computador.
Após as primeiras sprints a própria equipe percebeu que seria interessante modificar o quadro, além disso, cada equipe tem uma dinâmica e uma necessidade diferente, com isso, temos quadros adaptados para cada necessidade.
Acho extremamente importante as reuniões de planejamento das sprints (onde a equipe “monta” o kanban), e elas são muito mais produtivas pois a equipe se “obriga” a conversar e detalhar um item e muitas vezes esse compartilhamento permite que um mostre para o outro algo que não tinha sido visto. Outro item importante é o planning poker que ajuda muito nesse planejamento. Abaixo separei algumas imagens de quadros que encontrei na Internet e que acho interessantes.
[nggallery id=1 template=carousel images=7]
Confesso que uma das partes mais interessantes do gerenciamento de projetos com métodos ágeis é quando o time tem que estimar as tarefas. Acho que o planning poker “obriga” o time a discutir mais e a obter um entendimento maior acerca do que deve ser feito.
Resolvi pesquisar na Internet como funcionava o planning poker pois ainda tinha algumas dúvidas quando via o time “jogando”. Achei o artigo abaixo e resolvi traduzir. Para mim foi o melhor texto que encontrei e explica passo a passo com deve ser feito.
A estimativa é uma das atividades principais no Scrum e outros processos ágeis. Isso significa que o processo de associar um tamanho a uma história ex: quanto tempo isso irá levar, ou quanto de trabalho existe para implementar, ou quanto isso é caro ou se você pretende colocar isso.
No scrum a estimativa é uma atividade da equipe. Todo o time participa do processo de estimativa para cada história (ou tarefa).
Planning Poker® (as vezes chamado Scrum poker) é uma simples porém poderosa ferramenta que faz o time estimar rapidamente, com mais probabilidade de acerto e além disso é uma forma mais divertida para se estimar.
Estimando sem o planning poker
Temos a seguir um problema com estimativas feitas pelo time. Vamos dizer que nós estamos realizando a reunião de planejamento de uma sprrint (sprint planning meeting) e o product owner (o “dono do projeto”) diz: Ok, pessoal quanto tempo isso vai levar?
Então, o time começa a pensar quanto tempo esse item vai levar para ser feito (nesse caso em homem/dias)….
O SR. A acredita que sabe exatamente o que precisa ser feito, então ele acha que vai levar 3 dias. Sr. B e C são mais pessimistas. Sr. D e E estão mais distraídos, Então Sr. A diz: “3 dias”.
Isso deixa B e C confusos. Eles começam a ficar na dúvida com relação as próprias estimativas. Sr. E acorda e não sabe realmente o que está sendo estimado. Sr. D continua cochilando.
O product owner pergunta para o resto do time suas estimativas.
Como você pode ver, o resto do time for muito influenciado por A, apenas por que A falou antes. Isso é muito arriscado! B e C pensam que isso levará mais do que 3 dias, suas dúvidas deveriam estar sanadas.
Estimando com o Planning Poker
Agora imagine que cada membro do time está segurando um bolo de cartas, contendo as seguintes cartas:
Vamos voltar a estimativa. O Product Owner diz:
Mais uma vez, o time começa a pensar sobre quanto tempo a tarefa irá levar para ficar pronta.
Nesse time ninguém diz nada. Ao invés disso, todos tem que apresentar a carta com a face para baixo, contendo sua estimativa. Todo mundo tem que apresentar uma carta, então Sr. D e E acordam. Sr. D admite que estava dormindo e pergunta do que se trata a tarefa. É difícil de ser distrair quando a estimativa é feita dessa forma.
Quando todos já tiverem feito suas estimativas, então as cartão serão viradas ao mesmo tempo revelando o que cada um estimou.
Opa! Grande divergência aqui. O time em particular o Sr. A e o Sr. C, precisam conversar sobre a tarefa e o por que de suas estimativas serão tão diferentes. Depois de alguma conversa, Sr. A percebe que tinha esquecido algum item importante que deveria ser incluído nessa tarefa. Sr. C percebe que com o design que o Sr. A apresentou, a tarefa deveria ser menor que 20.
Depois da conversa (3 minutos no total) eles fazem outro round de estimativa para a mesma tarefa.
Convergência! Ok, não é uma total convergência. Mas eles concordam que uma estimativa de 5 deveria estar próximo do suficiente. E aí vem a próxima tarefa.
Por que essa séria estranha de números?
Os números mais altos tem menor granularidade. Por quê? Por que não tem 21 por exemplo?
Uma estimativa alta (> 20 por exemplo) normalmente significa que a história não está entendida em detalhes. Será perda de tempo para o time discutir se a a história é 19, 20, 22.5. É simplesmente uma grande história e o 20 refletirá isso. Se você precisa entrar em detalhes, quebre a história em menores. Histórias menores podem ser estimadas em maiores detalhes.
Cartas especiais
Traduzido de: http://www.crisp.se/planningpoker/