Resumo captulo 13 Livro Suceeding with agile (Mike COHN) O Backlog do produto O Product Backlog uma lista de todas

s as funcionalidades desejadas que no foram ainda incorporadas ao produto. Ela mantida pelo Product Owner com a devida ordem de prioridades. Diferente de outros documentos tradicionais de requisitos, um Product Backlog altamente dinmico, itens so adicionados, removidos e repriorizados a cada ciclo do projeto quanto mais aprendido sobre o prioduto. Existem trs mudanas necessrias nas organizaes para trabalhar-se efetivamente com o Product Backlog: 1 mudana do escrita (documentao) dos requisitos para conversas sobre eles; 2 realizar o detalhamento progressivamente melhor que document-lo por completo no incio; 3 especificao por exemplos deve ser preferida a documentao de funcionalidades do priduto. Com relao a primeira mudana o autor enfatiza que escrever documentos podem conduzir a suspenso do julgamento, isto , se algum escreveu um requisito porque estava absolutamente certa dele no, e talvez no cabe mais question-lo mesmo que a percepo mude durante o desenrolar do projeto. O uso de documentao escrita no aprofunda o entendimento como seria em uma conversao. E a escrita de documentos diminui a responsabilidade do time inteiro em buscar o sucesso do produto, faz com que as pessoas ocupem-se em fazer o que est escrito. O uso de User Histories recomendado pelo autor como os requisitos do Backlog, e constituem-se de um breve texto que informa o tipo de de usurio que escreveu a histria, o seu desejo ou objetivo e a razo para esse objetivo, algo no formato: Como um <tipo do usurio>, eu quero <algum objetivo> para que <alguma razo>. Portanto a User History no precisa ter todos os detalhes do desejo do usurio e deve caber em um simples carto ou post it quer dizer vai possuir poucas linhas, seu objetivo principal comprometer o time e o product owner sobre aquele requisito. O importante ambos estejam dispostos a esclarecer dvidas sobre o requisito a qualquer fase do desenvolvimento. O autor no probe o uso de ferramentas para o controle do backlog porm alerta que o uso de ferramentas pode levar a alguns perigos: Escrever descries de funcionalidades extremamente longas; Ter somente um sub-grupo do time trabalhando em entender as necessidades dos usurios; Resistir a necessidade de dividir histrias que possam ser desenvolvidas em um ciclo do projeto; Manter as histrias que no so mais necessrias porque difcil de elimin-las da ferramenta. Outro ponto abordado uso de Use Cases ao invs das User histories pode ser perigoso quando os casos de uso so grandes demais para caberem em um ciclo de desenvolvimento de duas semanas, aqui pode-se discordar do autor, uma vez que a histrias podem representar uma funcionalidade que exige bastante tempo de desenvolvimento. Talvez seria melhor preocupar-se em descrever casos de uso ou histrias de usurios que caibam dentro de um ciclo de desenvolvimento. Muitas vezes desenvolvedores podem ter dificuldade em escrever histrias de usurios devido a no existir um usurio diretamente relacionado, a sugesto neste caso seria o uso da sintaxe de Feature-Driven Development: <action> <result> <object>

Com relao a segunda mudana necessria, refinar progressivamente os requisitos, o autor comea alertando a dificuldade em conseguir obter todos os requisitos desde o incio do projeto, antes que o sistema inicie a sua construo e os desenvolvedores possam ver a forma em que o projeto est tomando, porque muitos requisitos emergem desta observao do projeto em construo. Este problema bem endereado pela metodologia SCRUM, porque ao preocupar-se que ao fim de cada ciclo de projeto (sprint) exista um cdigo funcionando faz com que requisitos emergentes sejam descobertos. Abrindo-se um parnteses, pode-se citar algumas experincias vivenciadas em que ao terminar-se uma Uer History, neste caso um cdigo que executa uma determinada ao restrita dentro do projeto, pode-se deparar com vrias vulnerabilidades e necessidades para cobrir aes mais amplas dentro do projeto, muito disto somente determinado durante a fase de teste, por isso a necessidade do cdigo funcionando. Voltando ao autor, ele cita que requisitos emergentes so tratados como falha de planejamento que devem ser gerenciados atravs de buffers no plano ou por significante energia no gerenciamento de risco. O SCRUM enderea este problema de forma mais natural contando com que requisitos emergem ao longo do projeto. Assim melhor do que procurar escrever documentos de requisitos e completos no incio do projeto que descrevam todos os detalhes de como o sistema deve ser construdo, melhor descrever as caractersticas do sistema quando elas estiverem sendo trabalhadas. Um aspecto importante sobre o Product Backlog sua forma de iceberg, isto , em geral os requisitos bem entendidos e capazes de serem implementados dentro dos sprints situam-se no topo do backlog. Por outro lado requisitos complexos, mal entendidos ou com tamanho indeterminados so deixados para depois, como se fossem o gelo abaixo do nvel d'gua de um iceberg. Aqui o autor alerta da necessidade o time ir gastando tempo em refinar, entender e talvez dividir estes itens de backlog mal entendidos. Esta atividade deve ser executado ao longo dos sprints como uma atividade planejamento que deve ser encorajada pleo scrum master j que SCRUM requer que se planeje para mudar. Outra questo que a justificativa para refinar progressivamente os requisitos o fato de que as coisas mudam principalmente em relao as suas prioridades, assim importante ter o foco do desenvolvimento sobre aquilo importante para o momento e gastar esforo (tempo) somente naquilo que est se tentando atingir no curto prazo do sprint. O refinamento progressivo de histrias fortemente sugerido pelo autor que chama as User Histories com um escopo muito amplo em que seu desenvolvimento muito grande para um nico sprint de pico. Assim a diviso de histrias muito amplas em histrias menores deve-se balizar na compreenso do time que estas histrias menores so passveis de se desenvolver em um nico ciclo. Histrias podem ser refinadas pela adio de condies de satisfao, desta forma o time capaz de identificar os objetivos a serem atingidos por aquela User History ficando mais fcil avaliar se o resultado atingido atendeu as expectativas. Por fim o autor aborda a questo de especificar pelo exemplo, no desprezando a forma usual de uma especificao inicial completa que pode ser til para iniciar um projeto, mas pode se obsoletar rapidamente se no for atualizada durante o projeto. Apontando que atravs de exemplos baseados nas situaes reais de uso do sistema em desenvolvimento, ajudariam muito no entendimento do que deve ser feito, de como funciona e principalmente, como deve ser testado. O que abrange todas as fases de desenvolvimento de um software.

O autor aborda, ainda, que o emprego de metodologias geis resultar em times cross-functional, onde testadores e desenvolvedores no esto preocupados em escrever, documentar, manter e interpretar documentaes extensas de especificao, mas sim em enderear implementaes para cenrios de testes que atendam as condies de satisfao das funcionalidades do projeto. Como resumo final apresentado o acrnimo DEEP para sumarizar um bom Product Backlog: Detalhado apropriadamente: histrias para serem desenvolvidas no prximo sprint possuem detalhes suficientes para seu entendimento e histrias para desenvolvimento futuro esto descritas com menos detalhes. Estimado: os itens de backlog mais priorizados ou para serem desenvolvidos em breve devem estar estimados ou comportados por um sprint, os demais tem uma estimativa menos precisa ou refinada. Emergente: o product backlog no esttico e ir mudar ao longo do tempo. Histrias so adicionadas, removidas e priorizadas. Priorizados: o product backlog deve ser ordenado pelos itens mais valiosos para os menso valiosos e sempre trabalhado na ordem de prioridade para maximizar o valor agregado em cada sprint ao produto ou sistema em desenvolvimento. Alm disso, enfatiza to importante quanto manter o product backlog atualizado, a manuteno da comunicao entre os vrios membros do projeto sejam testadores, desenvolvedores, product owner e scrum master para que todos atingim um grau de entendimento do projeto e mantenham-se comprometidos com o projeto.