Blog ScrumHalf - Scrum e Gestão Ágil - Brasil
  • HOME
  • SCRUM
  • WEBINAR SCRUM
  • TREINAMENTOS
    • Agenda Treinamento
    • Treinamento Scrum
  • SCRUMHALF

Mantenha o Foco no Scrum – 2 dicas interessantes!

Postado em 11 de Abril de 2012 por Igor Araujo, Desenvolvedor Java Pleno da empresa Match Latam

Focus Light - copyright digitalart

Oi Pessoal! No post de hoje falarei sobre a forma como as equipes devem se organizar para a implementação das histórias em uma Sprint. Uma vez que o Sprint Backlog está montado e priorizado a equipe já pode começar os trabalhos de implementação das histórias selecionadas. Porém, como a equipe deve se dividir para a execução dos trabalhos? Cada membro deve “atacar” uma história diferente? Paralelizar é uma boa estratégia?

Em geral, existe uma tendência a pensarmos que paralelizando as implementações das histórias estamos ganhando tempo e sendo mais eficiente, o que não é verdade. Na metodologia ágil, ao adotar a estratégia de várias linhas de trabalho em paralelo, a equipe corre um grande risco de chegar ao final da Sprint com muitas histórias parcialmente implementadas, o que é indesejável. Ao final de cada Sprint a equipe deve possuir o maior número de histórias prontas, pois somente estas agregam valor ao produto.

 

 

 

 

 

O gráfico de burndown pode ser utilizado como uma ferramenta interessante para que a equipe perceba como ela está em relação ao objetivo final da Sprint. Nos casos em que a equipe ataca várias histórias em paralelo, o gráfico de burndown tende a ficar parecido com o da figura abaixo, que mostra que a equipe está bem distante (linha azul) do que deveria (linha tracejada vermelha) e correndo sério risco de terminar a Sprint sem incrementos “entregáveis” ao produto, como no gráfico abaixo:

Burndown histórias paralelas - copyright GPE

Portanto é importante que a equipe busque “atacar” e finalizar uma história de cada vez, começando pelas mais prioritárias. Desta forma, o risco de chegar ao final da Sprint com poucas ou nenhuma história pronta é bem menor.

Neste post destaco duas estratégias que nossa equipe adota para organizar a divisão dos trabalhos e evitar os “meio-prontos”:

Pair Programming

O pair programming é uma técnica de desenvolvimento ágil de software em que dois programadores trabalham juntos em uma mesma estação de trabalho. Enquanto um programador mexe no código, o outro observa o que está sendo feito. Os dois programadores discutem e reveem o que foi feito a fim de prever problemas futuros e chegar à melhor solução. Os dois programadores também podem trocar de papel entre si, revezando entre quem mexe no código e quem observa.

Acredito que com o pair programming as melhores soluções podem ser atingidas mais rapidamente. Assim, ao adotar o pair programming na implementação de uma história, aloca-se mais esforço em um mesmo item de trabalho para que este seja logo concluído. Ou seja, os esforços que poderiam estar sendo utilizados em duas frentes de trabalho, passam a estar focados em uma mesma tarefa, buscando sempre finalizar as tarefas iniciadas.

Divisão adequada das tarefas no planejamento 2

A segunda estratégia trata da divisão das tarefas no Planejamento 2. Uma vez definido o Sprint Backlog, a equipe parte para o planejamento 2, onde cada história é dividida em tarefas menores. Esta estratégia tem por objetivo uma divisão das tarefas de forma que cada membro da equipe possa trabalhar em uma tarefa diferente na mesma história. Vejam que é diferente do pair programming, pois as tarefas são executadas individualmente, porém fazem parte da mesma história. O que se pretende com esta estratégia é organizar o trabalho de forma que todos os esforços da equipe possam ser alocados em tarefas da mesma história, para que esta seja logo concluída.

É bom lembrar que a escolha destas estratégias depende de cada história. Depende do quão divisível ela é. Nem sempre é possível dividir uma história em tantas tarefas quanto a quantidade de membros da equipe. Além disso, para certas tarefas o uso do pair programming pode não trazer grandes benefícios fazendo com que a equipe aloque mais esforço que o necessário para a execução de tarefas simples, que poderiam ser facilmente executadas por 1 membro. Portanto a escolha da estratégia deve estar alinhada ao perfil da equipe e ao nível de complexidade das histórias, para que se possa chegar ao final da Sprint com a maior quantidade possível de histórias prontas.


E você, como faz a divisão dos trabalhos em uma Sprint? Deixe seu comentário aqui para discussões!

Posts relacionados

  • Pair Programming – Programação em ParPair Programming – Programação em Par
  • Programação em Par – Na práticaProgramação em Par – Na prática
  • <!--:pt-->Tratando as interrupções que afetam a Equipe Scrum<!--:-->Tratando as interrupções que afetam a Equipe Scrum
  • <!--:pt-->Otimizando o tempo gasto ao estimar histórias<!--:-->Otimizando o tempo gasto ao estimar histórias
  • 5 Dicas Para Uma Reunião Dar Certo5 Dicas Para Uma Reunião Dar Certo
  • Importância Reunião DiáriaImportância Reunião Diária
Sovrn

Publicado em Dificuldades na Adoção do Scrum, Scrum, Técnicas ágeis | Tags: Foco, Pair Programming, paralelismo, WIP, Work In Progess |
« Versões Scrum e Cronogramas Macros de Projetos
A História fica pronta para a equipe ou a equipe pronta para a história? »

Deixe um comentário Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Posts mais lidos

  • User Stories – O que são? Como Usar? posted on outubro 10, 2011
  • Burndown chart – Mede o progresso da sprint e dá indicativos do processo de trabalho da equipe posted on Janeiro 9, 2012
  • 10 Fatores Para Você Descobrir O Que Te Motiva posted on setembro 11, 2013
  • O que é Sprint? – FAQ Scrum posted on Fevereiro 15, 2012
  • Critérios de Aceitação das User Stories posted on outubro 17, 2011

Idioma:

  • Português
  • English

Arquivo

  • ► 2018 (1)
    • Fevereiro (1)
  • ► 2017 (2)
    • Maio (1)
    • Abril (1)
  • ► 2015 (7)
    • Maio (1)
    • Fevereiro (3)
    • Janeiro (3)
  • ► 2014 (43)
    • dezembro (3)
    • novembro (3)
    • outubro (3)
    • setembro (3)
    • agosto (4)
    • julho (2)
    • junho (3)
    • Maio (6)
    • Abril (4)
    • Março (3)
    • Fevereiro (4)
    • Janeiro (5)
  • ► 2013 (49)
    • dezembro (2)
    • novembro (2)
    • outubro (5)
    • setembro (3)
    • agosto (4)
    • julho (5)
    • junho (4)
    • Maio (4)
    • Abril (4)
    • Março (3)
    • Fevereiro (3)
    • Janeiro (10)
  • ► 2012 (117)
    • dezembro (4)
    • novembro (7)
    • outubro (8)
    • setembro (8)
    • agosto (10)
    • julho (11)
    • junho (11)
    • Maio (12)
    • Abril (11)
    • Março (11)
    • Fevereiro (12)
    • Janeiro (12)
  • ► 2011 (103)
    • dezembro (9)
    • novembro (11)
    • outubro (13)
    • setembro (13)
    • agosto (5)
    • julho (6)
    • junho (4)
    • Maio (6)
    • Abril (7)
    • Março (9)
    • Fevereiro (12)
    • Janeiro (8)
  • ► 2010 (1)
    • dezembro (1)

Categorias

  • Dificuldades na Adoção do Scrum (24)
  • Eventos (13)
  • Gestão Ágil (105)
  • Gestão Tradicional de Projetos (15)
  • Kanban (1)
  • Manifesto Ágil (22)
  • Métricas (4)
  • Retrospectiva (9)
  • Scrum (217)
    • FAQ SCRUM (12)
    • Projetos (53)
  • ScrumHalf (27)
  • Técnicas ágeis (62)

CyberChimps WordPress Themes

© O'Katana - Blog ScrumHalf - Gerência de Projetos Ágeis e Scrum - Brasil

Obrigado!

Muito obrigado pelo seu feedback! Faremos o possível para continuar oferecendo o melhor para os nossos leitores.

Close