Scrum é um framework (e não metodologia) interativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.
O product backlog é o coração do Scrum. É aqui que tudo começa. O product backlog é basicamente uma lista de requisitos, estórias, Coisas que o cliente deseja, descritas utilizando a terminologia do cliente. Nós as chamamos de estórias, ou algumas vezes apenas de itens do backlog. Nossas estórias incluem os seguintes campos:
* ID – Uma identificação única, apenas um número com autoincremento. Isso é para evitar que percamos o controle sobre as estórias quando nós mudamos seus nomes.
* Nome – Um nome curto e descritivo para a estória. Por exemplo, “Ver o histórico de transações”. Suficientemente claro para que os desenvolvedores e o product owner entendam mais ou menos sobre o que estamos falando, e claro o bastante para distingui-la das demais estórias. Normalmente de 2 a 10 palavras.
* Importância – a pontuação de importância dessa estória para o product owner. Por exemplo 10. Ou 150. Mais pontos = mais importante. Eu tento evitar o termo “prioridade” já que prioridade 1 é tipicamente interpretado como “prioridade mais alta”, o que fica feio se mais tarde você decidir que algo é ainda
mais importante. Qual pontuação de prioridade esse item deveria receber? Prioridade 0? Prioridade -1?
* Estimativa inicial – As estimativas iniciais da equipe sobre quanto tempo é necessário para implementar aquela estória, se comparada a outras estórias. A unidade é pontos por estória e geralmente corresponde mais ou menos a “relação homem/dias” ideal.
1. Pergunte à equipe “se vocês puderem ter o número ideal de pessoas para esta estória (nem muitas, nem
poucas, normalmnte duas), e se trancarem em uma sala cheia de comida e trabalharem sem distúrbio algum, após quantos dias vocês apresentarão uma implementação pronta, demonstrável e testada? Se a resposta for “com 3 pessoas trancados em uma sala levará aproximadamente 4 dias” então a estimativa inicial é de 12 pontos por estória.
* ID – Uma identificação única, apenas um número com autoincremento. Isso é para evitar que percamos o controle sobre as estórias quando nós mudamos seus nomes.
* Nome – Um nome curto e descritivo para a estória. Por exemplo, “Ver o histórico de transações”. Suficientemente claro para que os desenvolvedores e o product owner entendam mais ou menos sobre o que estamos falando, e claro o bastante para distingui-la das demais estórias. Normalmente de 2 a 10 palavras.
* Importância – a pontuação de importância dessa estória para o product owner. Por exemplo 10. Ou 150. Mais pontos = mais importante. Eu tento evitar o termo “prioridade” já que prioridade 1 é tipicamente interpretado como “prioridade mais alta”, o que fica feio se mais tarde você decidir que algo é ainda
mais importante. Qual pontuação de prioridade esse item deveria receber? Prioridade 0? Prioridade -1?
* Estimativa inicial – As estimativas iniciais da equipe sobre quanto tempo é necessário para implementar aquela estória, se comparada a outras estórias. A unidade é pontos por estória e geralmente corresponde mais ou menos a “relação homem/dias” ideal.
1. Pergunte à equipe “se vocês puderem ter o número ideal de pessoas para esta estória (nem muitas, nem
poucas, normalmnte duas), e se trancarem em uma sala cheia de comida e trabalharem sem distúrbio algum, após quantos dias vocês apresentarão uma implementação pronta, demonstrável e testada? Se a resposta for “com 3 pessoas trancados em uma sala levará aproximadamente 4 dias” então a estimativa inicial é de 12 pontos por estória.
2. O importante não é ter estimativas absolutamente precisas (por exemplo, dizer que uma estória com 2 pontos deverá gastar 2 dias), mas sim obter estimativas relativas corretas (por exemplo, dizer que uma estória com 2 pontos gastará cerca da metade de uma estória com 4 pontos).
* Como demonstrar – Uma descrição em alto nível de como a estória será demonstrada na apresentação do sprint. Isso é simplesmente uma simples especificação de teste. “Faça isso, então faça aquilo e então isso deverá acontecer.” o Se você pratica TDD (desenvolvimento orientado a testes) essa descrição pode ser usada como pseudocódigo para o seu código de teste de aceitação.
* Como demonstrar – Uma descrição em alto nível de como a estória será demonstrada na apresentação do sprint. Isso é simplesmente uma simples especificação de teste. “Faça isso, então faça aquilo e então isso deverá acontecer.” o Se você pratica TDD (desenvolvimento orientado a testes) essa descrição pode ser usada como pseudocódigo para o seu código de teste de aceitação.
* Notas – quaisquer outras informaçòes, esclarecimentos, referências a outras fontes de informação, etc. Normalmente agil bem breve.
Como todos os demais aterfatos, coloque no repositório de versionamento.
Enjoy!
No comments:
Post a Comment