BT

Queime as estórias não as tarefas

por Chris Sims , traduzido por Douglas Masson em 27 Jan 2009 |

Desenvolvedores geralmente quebram a estória do usuário em tarefas para facilitar o trabalho de distribuição e implementação em torno da equipe e permitir um acompanhamento dos processos em um nível fino de granularidade. Infelizmente, a estória pode explodir em uma lista de tarefas não triviais tão grandes que a estória não é entregue no fim da iteração. Ron Jeffries sugere: fazer estórias como uma unidade, não quebrar em tarefas.

Para que isto funcione, as estórias precisam ser pequenas o suficiente para que a equipe possa entender e estimá-la bem. Uma abordagem para decomposição da estória é listar os critérios de aceitação, e então olhar para cada um deles e encontrar aqueles que podem ser suas próprias estorias. Se aquele critério de aceitação em particular acrescenta algum valor ao produto, é um visível para o usuário, é indepentende e é testável, então é um bom candidato para se tornar a sua própria estória.

Várias equipes tem os especialistas que focam em áreas especificas do produto ou das tecnologias subjacentes, tornando difícil dar uma estória completa para um indivíduo. Uma solução a longo prazo é cruzar os desenvolvedores de forma que possam trabalhar em várias partes do sistema e com todas as tecnologias necessárias. Isto cria uma equipe que é versátil e reduz a perda do risco organizacional 'a única pessoa' que é competente para trabalhar em uma determinada área do sistema. Uma forma de ter o trabalho feito agora, enquanto se move nesta direção, é utilizar a programação em par. A pessoa que 'possui' a implementação da estória em par com as pessoas que tem a competência necessária, a fim de entregar a estória completa.

Ron recomenda: "Queime as estórias, não as tarefas". Quando monitorando (queima) a nível de tarefas, os desenvolvedores podem 'fazer sua parte' finalizando muitas tarefas, sem qualquer funcionalidade do usuário ser entregue. Se a equipe apenas monitora o término das estórias, então os desenvolvedores apenas recebem o calor de finalizar algo quando a estória está completa. Isto encoraja uma noção mais valiosa do 'feito.'

Você concorda com a abordagem do Ron? Deixe um comentário e compartilhe a sua opinião.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Queime as histórias, não as tarefas by Alexandre Odoni

Concordo em partes: Tudo depende do nível de conhecimento da equipe na hora de estimar as histórias. Se a equipe compreender a complexidade da história, pode sem nenhum problema quebrá-la em n tarefas que não haverá problema. Agora, se a equipe não tiver um bom conhecimento, tudo fica mais difícil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

1 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.