Desenvolvimento de aplicação de grande porte (ou até mesmo um projeto mais simples), exige vários aspectos a serem abordados com os clientes, falo isso, porque recentemente em um de nosso projetos para um determinado cliente se tornou um "tanto" desgastado, devido a informações precárias, em baixa quantidade e a bipolaridade da empresa (isso porque esta tudo em contrato, o que seria e não seria feito pelo valor contratado), enfim, isso apresenta muitos desafios. É preciso ser capaz de analisar um projeto para que as equipes individuais possam trabalhar em um sub- sistema e integrá-lo sem problemas com o cliente.
Uma das discussões mais difíceis , que ocorre entre os profissionais ágeis gira em torno da necessidade de planejamento prévio e backlog. O Sprint Pre-Planning geralmente ocorre no final de um sprint anterior para uma próxima corrida, quando a equipe pode prever se tudo pode ser preenchido e poucos dias antes de o exercício de planejamento do sprint padrão.
Geralmente gosto de fazer na quarta-feira antes do final do sprint anterior. O Sprint Pre-Planning não deve demorar mais de uma hora por uma semana Sprint. O objetivo da reunião é duplo .
Primeiro - garantir o backlog é priorizado;
Segundo - quais termos provavelmente vão ser apresentados são devidamente formados ( são no formato adequado , elas fazem sentido , incluem critérios de aceitação inicial e incluir referências a todos os materiais auxiliares necessários ) .
Provavelmente a razão mais importante para planejar antecipadamente é garantir que a principal reunião de planejamento do sprint realizado com a equipe principal no primeiro dia do sprint é eficiente e eficaz. Um exemplo de um calendário a partir de um sprint duas semanas, mostrando o tempo de planejamento prévio e outra reunião padrão é mostrado abaixo.
Participantes: Preplanning geralmente não envolve todos da equipe. Uma sub- equipe de três: o Cliente, Analista de Negócios e programadores. Uma razão para restringir o atendimento é que as pessoas estão mais ocupados mais tarde em um sprint, independentemente quaisquer discussões sobre o ritmo sustentável.
Processo : Como uma equipe, revê quaisquer unidades de trabalho que você não antecipar. Há uma tendência natural, em supor que uma história incompleta irá apenas rolar para o próximo sprint. Não faça essa suposição! Você deve avaliar o suficiente para que tenha sido concluída ou algo novo que foi aprendido para alterar a proposta de valor da unidade de trabalho. Priorizar o backlog com base no que a equipe e organização sabe hoje. A equipe de pré-planejamento deve, então, percorrer os itens do backlog que provavelmente vão ser aceito no próximo sprint , mais um pouco mais ( sempre estar preparado ). Você pode usar os seguintes critérios:
Não entendemos o que significa o problema ?
Pode a unidade de trabalho ser concisa ?
É pequeno o suficiente para ser concluída no próximo Sprint sendo planejada ?
É o problema formatado corretamente?
A unidade de trabalho definiram critérios de aceitação ?
Problemas que deixam qualquer um destes critérios precisam ser corrigidos imediatamente. É por isso que os três papéis citados acima são fundamentais para o processo de planejamento . O Cliente fornece sua compreensão da necessidade de negócios, o analista de negócios pode falar ambas as línguas técnicas e comerciais e o programador sabe como provar que a história está completa. Já vi situações em que uma história não pode ser corrigida em tempo hábil , porque a equipe de planejamento prévio não entendeu a unidade de trabalho. Isso levou à unidade de trabalho que está sendo descartada no próximo sprint ou tratada como um projeto de pesquisa específico (conhecido como spike [pico]) de modo que possa ser planejada no futuro.
Uma vez, chamado o processo de planejamento prévio, um pre-chew
(pré- mastigar), usamos uma analogia para fazer uma impressão em um grupo que eu estava treinando, especificamente, que a sessão de planejamento prévio faz com que o processo geral de planejamento do sprint mais fácil de digerir. Preplanning ajuda a evitar situações em que toda a equipe tropeça, tentando decidir (ou pior argumentando ) que uma unidade de meios de trabalho e o que pode fazer para ser completa.
Esta interação é usada para criar o backlog inicial para o lançamento. Os participantes do encontro envolveu a equipe que trabalha fazendo a programação, o arquiteto líder , a equipe de boas práticas , cliente , representantes de serviços , projetos de interface do usuário , garantia de qualidade e gestão.
Os objetivos são os seguintes :
Entenda quaisquer grandes problemas de arquitetura
Identificar onde o software tem para fazer a interface com os subsistemas externos
Definir como se comunicar com sistemas externos
Definir as restrições gerais do sistema
Cliente para esclarecer os requisitos
Definir as histórias de usuários iniciais.
Tamanho das histórias de usuários
A sua participação é muito importante para a equipe manter a sua velocidade durante um sprint. O proprietário do produto tem que constantemente revendo o software trabalhando para ter certeza de que está no caminho certo com as expectativas .
Mesmo que não muito conhecidos no mundo ágil, há alguns artefatos do Scrum que podem ser empregados para expandir o campo de planejamento e aperfeiçoar a precisão de uma Sprint. Um destes artefatos é a Sprint Pre-Planning (Reunião de Pré-Planejamento), normalmente confundida com a Sprint Planning (Reunião de Planejamento), devido à semelhança no nome. Muitas empresas utilizam estes dois artefatos, mas não conhecem a distinção entre eles.
Já trabalhei em uma empresa que realizava duas cerimônias de planejamento: Sprint Planning 1 e Sprint Planning 2. Entretanto, apesar de se tratarem de uma sequência de reuniões, essas duas cerimônias apresentavam propósitos diferentes. Mais tarde, ao ler sobre Desenvolvimento Ágil no blog de uma empresa canadense, notei que eles também realizam as mesmas reuniões, mas denominam a primeira como Sprint Pre-Planning. Esse nome me despertou curiosidade. Após conferir as literaturas do Scrum, descobri que essa reunião realmente existe.
Qual a diferença entre as duas?
Bem, sabemos que a Sprint Planning consiste em definir e atribuir as user stories (histórias do cliente) para cada membro da equipe, certo? Porém, antes disso há uma etapa de seleção das novas funcionalidades e um cálculo do tamanho de cada uma baseado em story points e/ou na estimativa da equipe. Na maioria dos casos, essas duas etapas (seleção e atribuição) são realizadas em reuniões diferentes para não comprometer o tempo dos membros. A equipe, então, decide “quebrar” a reunião em duas partes para definir o Sprint Backlog, quando, na verdade, ela está elaborando duas reuniões distintas: a Sprint Pre-Planning e a Sprint Planning.
A Sprint Pre-Planning pode ser resumida na atividade de determinar quantas e quais funcionalidades serão incluídas na próxima Sprint. Nessa reunião, o Product Owner deve estar presente para selecionar as funcionalidades enquanto a equipe estima o tempo e esforço necessário para cada uma delas. Além disso, a equipe também pode identificar os pré-requisitos e os impactos que as novas funcionalidades irão causar no software em desenvolvimento, bem como “trocar” ou excluir certas funcionalidades que possam afetar o prazo ou o escopo. Só um adendo: quando digo “equipe”, me refiro também ao Scrum Master.
Como essa discussão das funcionalidades é conduzida?
Para que todos possam visualizar e discutir sobre cada funcionalidade, a equipe pode utilizar um quadro, geralmente conhecido como Planning Board. Este quadro contém apenas duas colunas: Product Backlog e Sprint Backlog. Ao iniciar a reunião, a primeira coluna deverá conter todas as funcionalidades pendentes a serem implementadas no software (representadas por post-its), enquanto a segunda coluna estará vazia. O objetivo é preencher a segunda coluna até o final da reunião com o que será desenvolvido na próxima Sprint. Para isso, o Product Owner se encarrega de selecionar as funcionalidades (arrastando os post-its da primeira para a segunda coluna), enquanto a equipe revisa e discute as estimativas.
Caso muitos post-its sejam arrastados para a segunda coluna, e equipe deve se manifestar para convencer o Product Owner de que a Sprint Backlog se encontra bastante extensa. Se necessário, a equipe ainda pode apresentar métricas de produtividade como argumento para a discussão.
O que é gerado com essa reunião?
Uma vez concluída, a Sprint Pre-Planning fornecerá uma estrutura definida da próxima Sprint Backlog, de forma que o planejamento das implementações, atribuições e outros aspectos técnicos possam ser designados com maior precisão na reunião seguinte, na qual finalmente chamamos de Sprint Planning!
Antes de finalizar o artigo, gostaria de fazer uma observação, aliás, uma sugestão. No início do artigo, mencionei que é possível ocorrer duas reuniões de planejamento (Sprint Planning 1 e 2), visto que, em algumas empresas, a equipe é tão grande que apenas uma cerimônia não é o suficiente, levando a equipe a dividir o planejamento em duas partes. Neste caso, eu sugiro que uma decomposição da equipe seja considerada, formando subequipes (também denominadas “células de trabalho”) regidas por Scrum Masters diferentes. Essa é uma premissa do framework Large-Scale Scrum, introduzida por Craig Larman e Bas Vodde no livro Practices for Scaling Lean & Agile Development, de 2010.
Fonte: SubRotina