O Desafio do Sprint Planning 2 no Scrum

Uma boa sprint começa com um bom planejamento!

Para quem não está familiarizado com o scrum, no fluxo normal  nós temos dois passos que iniciam a execução da sprint chamados “Sprint Planning 1” e “Sprint Planning 2” (representados na imagem acima pelos dois primeiros blocos de fundo verde).   No Sprint Planning 1, é onde acontece a escolha de quais itens de backlog (IBL) serão feitas na sprint. Nesta reunião é muito importante a presença do product owner pois ele é um dos principais responsáveis pelo roadmap do produto/projeto sendo desenvolvido, na grande maioria das vezes ele que tem o conhecimento do negócio e que tem a visão mais acertada de onde quer que o produto/projeto chegue. Essa escolha das IBL’s é feita de pelo time todo, ou seja, todo o time tem que concordar que terão condições de implementar aquelas estórias escolhidas. Uma vez escolhidas as estórias que serão feitas na sprint, chega o momento da Sprint Planning 2

Na reunião de “Sprint Planning 2” todo o time concentra seus esforços em quebrar aquelas IBL’s (estórias) em unidades menores de trabalho que são as conhecidas Tasks, representadas por post-its, e que estão eternizadas na imagem de uma parede cheia de post-its (nada contra, mas tenho pena das árvores 😛 vamos começar o movimento #RecyclePostIts). Bom, é nesse momento que acontece a explosão de tarefas, a sprint começa sem ter nenhuma tarefa a ser feita e na sprint planning 2 as tarefas são levantadas. A importância dessa fase do scrum é a seguinte: O que você levantar como tarefa aqui vai guiar seu desenvolvimento da sprint toda (e é claro que você pode lembrar/criar mais atividades no decorrer da sprint, mas essa visão inicial ajuda muito e já pode antecipar alguns problemas que poderiam acontecer).

É aí que aparece a pergunta: Mas como eu quebro as estórias em tarefas?  Qual a granularidade? E é justamente para tentar responder essas perguntas que eu vou tentar listar algumas dicas ou instruções de como quebrar as tarefas.

  • 1) Granularidade grossa: Uma das primeiras recomendações para a quebra de tarefas é sempre criar tarefas que possam ser feitas em 1 dia de trabalho (ou menos), caso contrário é melhor quebrar ainda mais a tarefa com o objetivo que ela caiba em 1 dia de trabalho. O objetivo desta dica é facilitar o gerenciamento das tarefas, e também poder visualizar o trabalho diário no burndown, que nesse caso vai se mover dia a dia, ao invés de ficar parado uns dias e depois se mover.
  • 2) Granularidade fina: O ideal para começar é tentar lembrar de cada detalhe, e transformar cada detalhe em uma tasks (lembrando que para que isso aconteça é preciso uma análise detalhada da estória a ser desenvolvida, levando em consideração todos os pontos possíveis: criação de classes, design, design gráfico, prototipação, testes, etc, etc, etc). Cada detalhe então vai virar uma task e isso facilita a vida de quem desenvolver a estória pois as tarefas já são quase que um guia e a finalização das tasks da estória simbolizaria que não falta mais NADA para aquela estória. Ex.: Se você sempre acaba a estória e vê que a equipe não fez uma validação javascript em um formulário, então na próxima sprint você já inclui a validação como uma tarefa (pois-it) a parte.
  • 3) Refinamento Contínuo: A idéia aqui é sempre adequar a quebra de tarefas a relidade da equipe. Como no exemplo citado no ponto 2, cada sprint servirá por base para refinar e definir melhor o nível de quebra de tarefas das próximas sprints. Se a granularidade foi muito fina, junta mais coisa em um tasks só (que façam sentido estar junto obviamente). Caso a granularidade tenha sido muito grossa, tenta detalhar mais cada uma e separar os detalhes em tasks individuais.

Bom, acredito que com essas coisas em mente vamos conseguir planejar melhor nossas sprints, e consequentemente finalizá-las melhor também! Você tem alguma dica a respeito da separação de tarefas no sprint planning? Deixa tua dica aqui como comentário 🙂 valeu!

Anúncios

Scrum Boards fora da parede

Times Ágeis Distribuídos? Parece uma coisa meio paradoxal, uma vez que metodologias ágeis pregam o time junto, unido, um ao lado do outro, de forma a reduzir ruídos de comunicação e até de forma a minimizar uma documentação extensiva (uma vez que estão todos juntinhos e sincronizados).

Sou a favor dessa proximidade física do time e entendo os benefícios, no entanto não podemos virar as costas para o movimento home-office ou mesmo para times distribuídos. Diversas empresas, como IBM, já adotaram home-office, e isso faz parte do dia-a-dia do desenvolvimento de software. Não é preciso nem comentar a respeito do desenvolvimento open-source, onde é praticamente todo distribuído, e ainda assim temos diversos casos de aplicações seguras, de qualidade e que são utilizadas em larga escala,  que foram desenvolvidas de forma distribuída.

Hoje em dia (e já a um bom tempo) temos diversas ferramentas que possibilitam esse desenvolvimento distribuído. Temos ferramentas para comunicação (email, msn, skype, etc…) , ferramentas para controle de versão/compartilhamento de arquivos/desenvolvimento paralelo  (svn, git, cvs, etc…), temos ferramentas de controle de bugs (mantis, trac, jira, etc…), e com o advento do scrum, hoje em dia também já temos ferramentas de scrum board (aquele quadrinho na parede cheio de post-it) on-line, que podem ser acessados pela web.

Como agora eu vou precisar trabalhar num time que utiliza scrum, e vou estar distante do resto do time, comecei a dar uma olhada em algumas ferramentas free de scrum board para começar a testar alguma.

Fiz uma pesquisa básica no velho google e achei algumas opções, mas procurei filtrar as que fosse de graça 😛 As opções que eu selecionei são as seguintes: Project Cards (esse aqui é integrado no eclipse, então não é bom pra gerentes e o povo que não usa eclipse) , FireScrum (bem legal, feito em flex, conheço a turma que trabalhou nele, disponibiliza um dashboard como o da figura ao lado) e SeeNowDo que eu vou falar um pouco mais adiante.

Bom, dentre esses o que me chamou mais a atenção foi o SeeNowDo, pelo simples motivo que oferecia tudo aquilo que eu procurava, gratuito, e rápido de utilizar. Ele oferece o dashboard do scrum (como cores diferentes para post-its de categorias diferentes), permite gerenciar múltiplos projetos, cadastro de sprints/estórias/tasks de forma simples e intuitiva, disponibiliza também o burndown chart das tasks cadastradas, e permite a transição das tarefas entre as colunas do quadro(TO DO/DOING/DONE) via drag and drop.

Ah, só tem um probleminha, você tem que utilizar a base de dados deles, pois não é possível fazer um download e instalar no ambiente da sua empresa/projeto. Então se houver alguma questão de confidencialidade no seu projeto, não é muito legal armazenar todas as atividades do projeto numa base on-line.

É isso, vou continuar minha pesquisa e ver se encontro outras ferramentas legais para scrum boards.

PS. Vale lembrar que tirar os post-its da parede e colocar numa ferramenta dessas é uma atitude também Verde (ecologica).

Menos post-its = menos papel = menos árvores derrubadas.