Vamos responder a uma pergunta realizada.
Tenho um projeto muito grande, como posso organizar este projeto no Scrum de maneira que eu não tenha uma grande Sprint de analise de sistemas e uma serie de Sprint de execução dos Itens de Backlog.
Bom vamos lá....
1 – Eu vou partir da hipótese que o Product Owner sabe o que ele deseja, isto é, ele sabe os assuntos a serem tratados no projeto, mas ele não tem todos as informações a nível detalhado de cada assunto.
2 – Devemos organizar o nosso Backlog, é uma boa pratica já organizar os requisitos por “Releases”, isto é, “Versões” e dentro de cada Release organizar os requisitos por Sprint's. Devemos lembrar que esta organização é para termos uma visão de tempo que as funcionalidades vão ser desenvolvidas e entregues, mas o Product Owner pode a qualquer momento reorganizar a prioridade do Backlog. O Product Owner não pode apenas mudar uma Sprint que já está em execução.
3 – Já temos o Backlog organizado por Sprint's e Releases, mas devemos lembrar que Scrum não define nenhuma forma de engenharia de software, ele apenas é uma forma de trabalho (Framework). Mas para um projeto de software é importante termos uma organização destes requisitos por grupo de assunto e identificarmos como um grupo se relaciona a outro. Uma boa técnica é um modelo de Domínio, cartão CRC, Modelo de Dados em Alto Nível, etc.
Com este trabalho de agrupamento e mapeamento de relacionamento entre os grupos de assuntos, o nosso desenvolvimento de software vai sofre alterações? A resposta é sim, mas o impacto é bem menor e bem menos traumático do que um trabalho sem a visão de grupos de assuntos. Outro ponto importante é que cada assunto vai ser refinado e a cada refinamento nos temos alteração no nosso sistema.
4 – Com isso passamos a ter um Backlog com requisitos definidos em alto nível e passamos a realizar o entendimento do requisito por Sprint.
Abraço a todos,
Abu
Postagens
Nenhum comentário:
Postar um comentário