Planejamento (Planning)

Planejamento diz respeito ao planejamento da iteração, considerando o que será construído nela. Essa atividade é liderada pelo MAnGveMaster (MM) junto ao time, com participação ativa do MAnGveBiz (MB) e pode ocorrer em 3 contextos distintos e complementares:

1. • Product Planning: considera o planejamento do produto ou artefato como um todo. O principal objetivo é identificar quantos releases (entregas) ocorrerão até que todo o produto esteja pronto, e o que fará parte de cada uma delas, sem que ainda seja necessário um detalhamento das partes, podendo estar o escopo no formato de épicos, temas ou estórias. Pode ser realizado no contexto da atividade Decompor a Solução do Ciclo de Design. O MAnGveBiz deve participar ativamente da priorização daquilo que é mais importante ser entregue para o negócio/produto ou projeto, auxiliando no sequenciamento/priorização dos releases (entregas).

   • Release Planning: considera o planejamento de um release (entrega). O principal objetivo é caracterizar com exatidão o que fará parte da referida entrega, e das consequentes iterações necessárias para materializá-la. O escopo ainda pode estar no formato de temas ou estórias. Pode ser realizado no contexto da atividade Decompor a Solução e Especificar Artefatos do Ciclo de Design. O MAnGveBiz deve participar ativamente da priorização daquilo que é mais importante ser entregue para o negócio/produto ou projeto, auxiliando no sequenciamento/priorização dos releases (entregas). O MAnGveBiz deve participar ativamente da priorização das iterações, considerando aquilo que é mais importante ser entregue primeiro.

   • Iteration (Maré, Marola ou Sprint) Planning: considera o planejamento de uma iteração. Uma iteração isoladamente pode não gerar uma entrega útil ao cliente (uma parte do produto utilizável), mas ao final de uma sequência de iterações coordenadas espera-se fornecer um release do produto ao cliente (uma parte utilizável). O principal objetivo é detalhar, dimensionar e priorizar o que fará parte do escopo a ser construído pela iteração, devendo o escopo estar no formato de estórias e tarefas. O MAnGveBiz deve participar ativamente da priorização das estórias, considerando aquilo que é mais importante ser entregue primeiro. Estas ações são o principal foco da atividade Planejamento do Ciclo de Desenvolvimento, e serão descritas a seguir.

Entradas

A partir dos requisitos que foram organizados e especificados no formato de estórias, no ciclo anterior (Design), pela decomposição das partes que compõem os artefatos, que por sua vez combinados materializam a solução idealizada para resolver ou mitigar o problema ou superar o desafio identificado, o time planeja como cada estória será construída para entrega do artefato desejado.

Neste momento, se existirem épicos remanescentes, que farão parte do escopo da iteração, eles precisam retornar ao ciclo de design para decomposição em estórias e especificação, antes de prosseguir neste ciclo.

Ferramentas e Técnicas

Estimando complexidade (SP)

Uma outra ação importante desta atividade é a estimativa de complexidade de cada estória. Geralmente é utilizada a Série ou Sequência do matemático italiano Leonardo de Pisa (1170-1250), mais conhecido por Fibonacci.

A Série de Fibonacci é uma sequência de números inteiros, iniciando por 0 e 1, na qual cada termo subsequente corresponde à soma dos dois anteriores. Exemplo: 0,1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584…

Então, o time busca por debate e consenso atribuir um dos números da Série de Fibonacci a cada estória para expressar sua complexidade. Essa métrica é usualmente denominada no contexto de métodos ágeis de Story Points (SP) ou Pontos de Estória. Quanto maior o SP atribuído a uma estória, maior seria a sua complexidade de construção.

É comum utilizarmos o intervalo de 1 a 89 para caracterizar o SP de uma estória. Portanto, se após debate e consenso o time identificar que uma estória (em comparação com as demais já dimensionadas), possui SP maior que 89, considere decompô-las em 2 ou mais estórias.

Estimando Valor de Negócio (BV)

Realizado dimensionamento da complexidade das estórias, o time solicita que o MAnGveBiz (MB) ajude a estimar o valor de negócio de cada estória, para priorização das estórias que precisam ser entregues primeiro, sob o ponto de vista do negócio.

Geralmente, em métodos ágeis, é utilizado o conceito de Business Value (BV) ou valor de negócio para priorização de estórias. Mas qual é a lógica por trás do dimensionamento dos BV? Uma técnica em desenvolvimento é o estabelecimento de critérios de relevância para o negócio, que podem variar de acordo com cada organização, produto ou projeto.

Para exemplificação da técnica adotaremos os seguintes critérios:

1. • Importância: denota a relevância daquilo que sofrerá impacto no negócio da organização por meio daquela estória.

   • Urgência: evidencia a influência que a pressão do tempo exerce sobre a entrega daquela estória, considerando a mitigação ou a resolução que ela poderá proporcionar para resolver determinada situação do negócio.

   • Atratividade: indica o quanto o benefício esperado pela entrega de uma determinada estória é interessante para o negócio da organização. Este critério geralmente é associado à ideia de proporcionar algum diferencial competitivo ao negócio.

Para cada critério poderia ser estabelecido uma Escala de 5 pontos, onde a maior pontuação estaria associada a superlatividade de cada critério. Como por exemplo na figura a seguir.

Então, uma forma de contabilizar o BV de uma estória, seria multiplicar a pontuação atribuída pelo MB a cada critério mencionado para a estória em análise.

Exemplificando, se uma determinada estória “A” tiver as seguintes pontuações I=2, U=4, A=5, o produtório desses critérios produziria como BV = 2*4*5 = 40.

Uma alternativa, a depender da característica do projeto, produto ou organização, poderia ser ainda a atribuição de pesos distintos para os critérios adotados e a geração de um resultado ponderado para o BV.

Pactuando Expectativas

Após a priorização inicial do MB, o time debate com o MAnGveBiz eventuais “limitações do processo de construção”, para uma reavaliação da prioridade sugerida pelo MB.

Muitas vezes essas limitações são decorrência da engenharia da construção do produto ou de limitações tecnológicas vivenciadas.

1. • Por exemplo, numa analogia simplificativa, por mais que seja interessante para o MB ter um “terraço” no telhado da casa (produto), não será possível para equipe entregar esse “terraço” sem antes construir a “fundação” e levantar as paredes da casa que darão sustentação ao “telhado”, onde se encontrará o “terraço”.

Realizados tais alinhamentos, o BV pode ser revisto pelo MB.

Calculando ROI

Uma vez que cada estória possua SP e BV, já é possível calcular o seu ROI (Return of Investment) ou Retorno do Investimento. O ROI é dado pela razão entre o valor de negócio (BV) atribuído pelo MB, e a complexidade de construção daquela estória (SP) dimensionada pelo time, i.e., ROI = BVSP.

1. • Desta forma um ROI de alto valor significa uma CARACTERÍSTICA do produto que agrega MUITO VALOR ao negócio e possui BAIXA COMPLEXIDADE para ser produzida.

Uma vez calculado o ROI das estórias, o Backlog (lista de estórias a desenvolver) da Iteração é priorizado pela ordem decrescente do ROI. Em tese o time deve procurar desenvolver primeiro aquilo que entrega mais valor e é menos complexo de ser desenvolvido (ROI maior primeiro!).

Definindo o escopo da iteração

Contudo, outra reflexão precisa ser realizada pelo time. Com base na experiência vivenciada pelo time do quanto de complexidade (SP) o time conseguiu remover na sua última iteração, o time então deve avaliar o que “cabe na iteração” que está começando. A esse conceito do somatório do SP das estórias que o time conseguiu entregar na última iteração denominamos Velocity (V) ou Velocidade do Time. Embora seja importante “ousar” na aplicação de métodos ágeis, o time deve evitar cair na tentação de selecionar para o backlog da atual iteração um conjunto de estórias, cujo somatório da complexidade estimada seja muito maior que o seu atual Velocity, evitando gerar frustração e baixa estima no caso de não conseguirem alcançar a meta estipulada.

Fatorando as estórias em tarefas

Uma vez definido o escopo da iteração, o próximo passo é fatorar as estórias (aquilo que o time entrega no final da iteração) nas tarefas que ele precisa realizar para entregar cada estória, por meio de uma discussão aprofundada que o time desenvolve nesta etapa.

1. • Exemplo, se o time precisa entregar a “fundação” ou “alicerce” de uma casa. Ele precisa identificar cada tarefa que precisará ser realizada para que o “alicerce” seja entregue ao final da iteração, considerando desde a “limpeza do terreno”, passando pela “escavação”, “armação”, “nivelamento”, até a “produção” e “aplicação do concreto”.

   • Outro detalhe importante, é que as estórias são estimadas em SP, denotando sua complexidade, e BV, indicando seu valor para o negócio. Já as tarefas são dimensionadas em termos de “esforço” (tempo ou pessoa-hora).

Definindo os critérios de aceitação

Um outro parâmetro importante para o desenvolvimento das estórias de uma iteração é a definição dos “critérios de aceitação”. O teste de aceitação é um tipo de teste realizado, usando esses critérios, para verificar se a parte do produto representada por aquela estória está pronta e pode ser utilizada pelo usuário/cliente, para atender os requisitos para os quais o produto foi construído.

1. • Geralmente, é um texto descritivo e objetivo do resultado esperado pelo uso daquela parte do produto pelo usuário.

   • Os testes de aceitação não precisam ser realizados apenas neste momento, pois é natural que “o que se espera por cada parte que compõe o produto” seja percebida e registrada no Ciclo de Design, por ocasião da atividade Especificar Artefatos.

   • Contudo, se novas estórias surgiram no refinamento do escopo da iteração, ou ainda existe alguma estória sem teste de aceitação definido, este é o momento de fazê-lo.

Distribuindo tarefas no time

É natural esperar que ao final desta atividade na qual o time discutiu, debateu, detalhou, dimensionou, priorizou e refinou cada parte daquilo que será construído na iteração em questão, que cada integrante do time demonstre de forma espontânea que estória gostaria de desenvolver.

Quando isso não acontece, o MAnGveMaster (MM) pode atribuir as estórias aos membros do time conforme a especialidade e/ou a experiência de cada membro.

Saídas

O principal produto deste estágio é o Backlog da Iteração planejado, dimensionado e fatorado para construção do(s) artefato(s). Depois de dimensionar detalhes que envolvem o trabalho do time e particularidades de cada parte de um artefato, o time se prepara para colocar artefatos ou suas partes na "linha de produção".

Templates

Veja aqui o(s) template(s) recomendável(is) para esta atividade. Para aquele(s) que não possue(m) link de acesso, você pode buscar alternativas na internet. Posteriormente, poderemos incluí-lo(s) na seção.

• Matriz IUA

• Backlog

Síntese

Teste (Testing)

O teste de conformidade verifica se o artefato construído atende às especificações detalhadas no ciclo de Design. Neste estágio, o time conta com a revisão do artefato sob à ótica de suas especificações, em caso positivo também pode surgir a análise de possuir um artefato que não está suficientemente pronto para ser homologado, embora todas as especificações tenham sido consideradas.

Entradas

Cada artefato construído passa por uma verificação de conformidade para identificar se atende às especificações detalhadas no ciclo de Design. Como um artefato é composto por estórias, é possível testar suas partes e sua completude.

Ferramentas e Técnicas

As estórias desenvolvidas e já testadas unitariamente são então testadas minuciosamente, por outro membro da equipe que não participou de seu desenvolvimento, procurando encontrar qualquer eventual não conformidade que tenha passado despercebido pelos membros que a desenvolveram.

As estórias nas quais forem identificadas não conformidades, são devolvidas para os desenvolvedores para correção, e posteriormente novamente testadas. E as estórias que não apresentarem desconformidade com os requisitos especificados e/ou os testes de aceitação aguardam a realização do Review.

Saídas

O principal produto deste estágio é a compreensão sobre o alinhamento entre as especificações para um artefato ser construído e o seu resultado. Com a verificação de conformidade o time pode perceber que as especificações detalhadas não foram suficientes para que o artefato estivesse pronto para ser homologado ou que o artefato foi construído não fidedignamente às especificações apresentadas. Em ambos os casos (e poderão existir outras motivações), as estórias não conformes retornam aos desenvolvedores para correção, seja para ajustar as especificações na atividade de Especificar Artefatos no Ciclo de Design, seja implementar ajustes no Planejamento do Ciclo de Desenvolvimento, seguindo o fluxo até que os artefatos estejam prontos a serem homologados no estágio posterior.

Templates

Veja aqui o(s) template(s) recomendável(is) para esta atividade. Para aquele(s) que não possue(m) link de acesso, você pode buscar alternativas na internet. Posteriormente, poderemos incluí-lo(s) na seção.

• Relatório de Teste

Síntese

Retrospectiva (Retrospective)

É a cerimônia que avalia como ocorreu o ciclo em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas, buscando identificar lições aprendidas.

Entradas

O time busca fazer uma retrospectiva de todos os acontecimentos decorrentes do ciclo de desenvolvimento buscando identificar ações que devem continuar ocorrendo no time, ações que não devem se repetir, e discutir erros e acertos com a finalidade de melhorar o ciclo de trabalho do time, consequentemente melhorar a qualidade de entrega.

Ferramentas e Técnicas

A cerimônia geralmente ocorre como uma reunião comum, síncrona em que o MAnGveMaster (MM) encoraja o time a revisar seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima iteração.

Nessa sessão geralmente são refletidos os seguintes aspectos:

1. • continue doing: aquilo que o time vem fazendo que tem gerado resultado satisfatório.

   • stop doing: aquilo que o time decide para de fazer, pois não está produzindo resultado satisfatório.

   • start doing: aquilo que o time acha que se fizesse poderia gerar um resultado melhor do que o que vem alcançando.

Os pontos importantes discutidos e principalmente as mudanças a serem implementadas no processo pelo time precisam ser registradas e publicizadas.

Saídas

O principal produto deste estágio é a compreensão e análise do ciclo de desenvolvimento com foco nas pessoas, nas relações entre elas, nos processos e nas ferramentas, em busca de lições aprendidas que fazem parte do processo de amadurecimento do time e promovem melhorias de trabalho futuramente.

Templates

Veja aqui o(s) template(s) recomendável(is) para esta atividade. Para aquele(s) que não possue(m) link de acesso, você pode buscar alternativas na internet. Posteriormente, poderemos incluí-lo(s) na seção.

• Apresentação Retrospective

Síntese