Disseminando conhecimento e inovação em desenvolvimento de software corporativo
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Postado por Mark Levison , traduzido por Lucas Souza em 22 Set 2010
De acordo com o Scrum Guide, os tradicionais gráficos de Burndown do Sprint medem:
A quantidade de trabalho restante para um Sprint é a somatória do trabalho restante para todo o Sprint Backlog. Mantenha o controle destas somatórias diariamente e use-as para criar um gráfico que mostre o trabalho restante ao longo do tempo. ...Duração não é considerada no Scrum. Trabalho restante e data são as únicas variáveis de interesse.
Tradicionalmente as pessoas foram ensinadas a medir o trabalho restante em horas. Como Mark Woyna aponta quando controlamos as horas das tarefas é possível queimar muitas horas sem completar alguma história. Neste caso o burndown está escondendo o real progresso do time. Ele chega a sugerir que muitos times controlam pontos de histórias concluídas. Adam Sroka considera que este problema acontece geralmente porque o time começou trabalhando em muitas coisas ao mesmo tempo.
Este relato observa que controlar as horas das tarefas nos encoraja a completar tarefas apenas se elas são relevantes para o complemento de uma história, encorajando clientes a não estimar tarefas em horas e a não usar o gráfico de burndown. Em vez disso, nós observamos o andamento das histórias e tarefas através do quadro de sprint da equipe.
Johanna Rothman avalia: Histórias completas, histórias restantes e o total de histórias, tanto considerando o nível do sprint ou do release.
Aslak Hellesøy recomenda Diagramas de Fluxo Cumulativos sobre Burndowns, observando que eles fornecem mais informações.
Você utiliza gráficos de Burndown do Sprint? Se não, o que você usa para substituí-lo?
Os papéis de Desenvolvedor e de Analista de teste foram distanciados no modelo tradicional de desenvolvimento e, agora, as práticas ágeis buscam aproximá-los em prol de software em funcionamento.
Apresentamos aqui os principais conceitos vistos no workshop de Ash Maurya sobre a aplicabilidade prática do Lean Canvas
Na quarta parte da série sobre equipes de alto desempenho veremos como identificar os acontecimentos em uma equipe que sai da fase de Conflitos e entra na fase de Normatização.
Ash Maurya, um dos maiores especialistas em Lean Startup falou com exclusividade ao InfoQ Brasil sobre a aplicabilidade do Lean e como seus conceitos contribuem com empreendimentos e equipes ágeis.
Conheça um guia prático, proposto por Esther Derby, para diagnosticar a eficácia de equipes, usando mapas mentais como referência, além de entender o perigo de equipes disfuncionais,
Esther Derby aposta os riscos em se transformar estimativas em um cronograma; e Allan Kelly apresenta pesquisas indicando ser impossível prever o tempo para se realizar uma atividade.
Martin Odersky, criador do Scala, discute o futuro da linguagem, trata da questão de quebra de compatibilidade binária e faz comparações com F# e Java.
Anil Gaur da Oracle fala sobre o cronograma para o Java EE 7, APIs para computação em nuvem, ferramentas e suporte a PaaS.
Nenhum comentário
Acompanhar Discussão Responder