Exemplo, digamos que uma historia requer uma funcionalidade complexa que pode demorar mais de uma semana para ser analisada, desenvolvida e entreque, mas existem outras diversas historias que são bem menores. Como gerir isto nas reuniões de sprint e diárias?
6
respostas
respostas
Um projeto pode ter iteracoes de tamanhos distintos
Uma prática para resolver isso, é dividir a entrega da funcionalidade maior em alguns sprints mas em cada sprint adicionar funcionalidades menor.
Por exemplo, vamos supor que o time consiga entregar 20 pontos e a funcionalidade maior tenha sido estimada em 25 pontos, em geral evitamos fazer um sprint apenas com uma historia, entao poderiamos quebrar a entrega da funcionalidade em 2 ou 3 sprints e adicionar funcionalidades menor aos sprints. Dessa forma na entrega do primeiro sprint apresentariamos as historias menores e dariamos um report de como anda o desenvolvimento da historia maior. Nas dailys não mudariamos nada, apenas teria que ter mais cuidado para conseguir manter o controle da historia maior, ou seja evitar que o status da historia maior seja sempre iterativo e nao repetitivo.
Respondendo a pergunta considerando um pouco mais o Scrum, tenho os seguintes itens:
- O tempo de duração do Sprint pode ser alterado, porém não para acomodar uma tarefa maior apenas para o próximo Sprint. Esta alteração se dá como adaptação do processo como um todo.
- Ons itens do Product Backlog são idealmente quebrados ao ponto de poderem ser feitos em um único Sprint.
- Todo Incremento deve ser funcional e mediante decisão do Product Owner, pode ser enviado para produção.
- Daily Scrum não é uma reunião para prestar contas de onde você está em termos de desenvolvimento, portanto nada mudaria mesmo com uma tarefa maior.
Paulo, boa noite.
Na sua citação, o item 3 diz que "Todo Incremento deve ser funcional e ...".
Minha dúvida é: os requisitos não funcionais não poderiam também ser incrementos se validado o devido valor agregado ao cliente pela equipe?
. . .
Quando digo deve ser funcional eu não estava me referindo aos tipos de requisitos funcionais e não funcionais, quis dizer que o Increment deve estar em condições de uso atendendo a Definition of Done. Mas você está certa na sua indagação. Apesar dos requisitos não funcionais serem normalmente colocados na DoD, eles também podem estar presentes no Product Backlog.
Paulo, bom dia.
Correto. Compreendido. Você quis diz requisito em conformidade. Agradeço por postar e aprender o significado de DoD: Definition of Done.