Alai

Se soubéssemos o que estávamos fazendo, não seria chamado de pesquisa.

-Albert Einstein

Picos são um tipo de história de exploração Enabler Story in SAFe. Definidos inicialmente em Programação Extrema (XP), representam atividades como pesquisa, design, investigação, exploração e prototipagem. Seu propósito é adquirir o conhecimento necessário para reduzir o risco de uma abordagem técnica, compreender melhor uma exigência ou aumentar a confiabilidade de uma estimativa de história.

Como outras histórias, os picos são estimados e depois demonstrados no final da Iteração. Eles também fornecem um protocolo e fluxo de trabalho acordado que os Agile Release Trains (ARTs) utilizam para ajudar a determinar a viabilidade de Epics.

Agile e Lean value facts over speculation. Quando confrontadas com uma questão, risco ou incerteza, as Equipes Ágeis conduzem pequenos experimentos antes de passar à implementação, em vez de especular sobre o resultado ou pular para uma Solução. As equipes podem usar picos em uma variedade de situações:

• Estimar novas Características e Capacidades para analisar o comportamento implícito, fornecendo insight sobre a abordagem para dividi-los em partes menores e quantificáveis
• Executar análise de viabilidade e outras atividades que ajudam a determinar a viabilidade de épicos
• Conduzir pesquisa básica para familiarizá-los com uma nova tecnologia ou domínio
• Ganhar confiança em uma abordagem técnica ou funcional, reduzindo risco e incerteza

Picos envolvem a criação de um pequeno programa, atividade de pesquisa ou teste que demonstre algum aspecto da nova funcionalidade.

Picos Técnicos e Funcionais

Picos vêm principalmente em duas formas: técnica e funcional.

Picos funcionais – São usados para analisar o comportamento geral da solução e determinar:

• Como decompô-lo
• Como organizar o trabalho
• Quando existe risco e complexidade
• Como usar insights para influenciar decisões de implementação

Picos técnicos – São usados para pesquisar várias abordagens no domínio da solução. Por exemplo:

• Determinar uma decisão de construção-versus-compra
• Avaliar o desempenho potencial ou impacto de carga de uma nova história de usuário
• Avaliar abordagens técnicas específicas de implementação
• Desenvolver confiança sobre o caminho da solução desejada

Algumas características e histórias de usuário podem requerer ambos os tipos de picos. Aqui está um exemplo:

“Como consumidor, eu quero ver meu uso diário de energia em um histograma para que eu possa rapidamente entender meu consumo de energia passado, atual e projetado.”

Neste caso, uma equipe pode criar ambos os tipos de picos:

• Um pico técnico para pesquisar quanto tempo leva para atualizar a exibição de um cliente para o uso atual, determinando os requisitos de comunicação, largura de banda, e se deve empurrar ou puxar os dados
• Um pico funcional – Protótipo de um histograma no portal web e obter algum feedback do usuário sobre o tamanho da apresentação, estilo e gráficos

Guias para os picos

Desde que os picos não fornecem diretamente valor ao usuário, use-os com parcimônia. As seguintes diretrizes se aplicam.

Quantificável, demonstrável, e aceitável

Como outras histórias, os espigões são colocados no Backlog da Equipe, estimados, e dimensionados para caber em uma iteração. Os resultados dos espigões são diferentes de uma história porque os espigões normalmente produzem informação em vez de código de trabalho. Eles devem desenvolver apenas os dados necessários para identificar e dimensionar as histórias que a impulsionam com confiança.

O resultado de um espigão é demonstrável, tanto para a equipe quanto para quaisquer outros interessados, o que traz visibilidade à pesquisa e aos esforços arquitetônicos, e também ajuda a construir a propriedade coletiva e a responsabilidade compartilhada para a tomada de decisões. O Proprietário do Produto aceita picos que foram rebaixados e satisfazem os seus critérios de aceitação.

Timing of Spikes

Desde que representem incerteza em uma ou mais histórias potenciais, o planeamento tanto para o pico como para as histórias resultantes na mesma iteração é por vezes arriscado. Entretanto, se for pequena e direta, e uma solução rápida for provavelmente encontrada, então pode ser bastante eficiente fazer ambas na mesma iteração.

A Exceção, Não a Regra

A história de cada usuário tem incerteza e risco; essa é a natureza do desenvolvimento Ágil. A equipe descobre a solução certa através de discussão, colaboração, experimentação e negociação. Assim, em um sentido, cada história de usuário contém atividades em forma de picos para identificar os riscos técnicos e funcionais. O objetivo de uma equipe Ágil é aprender como lidar com a incerteza em cada iteração. Os picos são críticos quando existe alta incerteza, ou há muitas incógnitas.

Aprenda Mais

Leffingwell, Dean. Requisitos do Software Agile: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Última atualização: 10 de fevereiro de 2021