Story / Impact Mapping – Contexto, Princípios e Visão Geral
Desenvolvimento de software em pequenos lotes é bom
Há muitas vantagens em seguir a abordagem de pequenos lotes (muitos passos pequenos e individuais) no desenvolvimento de software:
- Feedback mais rápido
- Problemas são localizados
- Risco reduzido
- Mais pressão e rotina para reduzir o esforço
Desenvolvimento de software em pequenos lotes de forma ingênua não é tão bom assim
No entanto, quando se aborda o desenvolvimento de software em pequenos lotes de forma ingênua, também há uma desvantagem significativa: a falta de conexão com o objetivo geral.
Jeff Patton descreveu esse fenômeno usando o exemplo de uma árvore e um saco cheio de folhas:
„Eu imagino uma árvore cujo tronco é formado pelos objetivos e benefícios desejados que impulsionam o sistema. Os galhos grossos são os usuários, os galhos mais finos e ramos são as capacidades que eles precisam. As folhas representam as User Stories, que são pequenas o suficiente para serem desenvolvidas nas iterações.
Depois de todo esse trabalho, depois de construirmos tanto entendimento compartilhado, tenho a sensação de que tiramos todas as folhas da árvore e as enfiamos em um grande saco – e então derrubamos a árvore."
O "saco cheio de folhas" refere-se a uma lista descontextualizada e priorizada de tarefas num backlog e reflete a compreensão ingénua de "backlogs" que, na minha opinião, é particularmente típica de iniciantes em Agile. Embora teoricamente pareça uma abordagem de pequenos lotes, o "saco cheio de folhas" separa a ligação com os princípios e objetivos subjacentes, minando assim a autonomia.
Os 5 atributos de uma abordagem eficaz de pequenos lotes no desenvolvimento de software
Uma abordagem mais eficaz vai além da simples divisão em unidades menores. Uma abordagem mais eficaz:
- enfatiza a intenção real através de objetivos.
- enfatiza a relação lógica entre os objetivos e as tarefas necessárias.
- apresenta de forma visível os objetivos, tarefas e relações para revelar possíveis inconsistências e mal-entendidos.
- está orientada para o trabalho colaborativo.
- é iterativa, ou seja, não é necessária completude no início.
- Story/Impact Mapping vs. Desenvolvimento de software em pequenos lotes
Tanto o "User Story Mapping" de Jeff Patton como o "Impact Mapping" de Gojko Adzic são respostas (em grande parte equivalentes) às abordagens ingénuas para determinar os passos menores no desenvolvimento de software em pequenos lotes (ou seja, para a criação de backlogs). Eu descreveria da seguinte forma:
Nota: Este processo de Impact Mapping deve ser iterativo. Aqui está apresentado de forma sequencial apenas para melhor compreensão. Não é necessário nem recomendável executar cada passo nesta ordem. Em vez disso, podes começar no ponto onde te encontras e trocar os passos conforme necessário.
1) Identificar objetivos
O que queres alcançar?
Deve ser algo que se possa observar e, portanto, também medir. Por isso, gosto do termo "impacto", pois significa que algo é mensurável. No entanto, "objetivo" é mais comum e além disso não gosto de introduzir nova terminologia quando não é absolutamente necessário.
Pode haver vários objetivos.
2) Identificar papéis e atividades
Quem precisa participar numa atividade para alcançar os objetivos? Ou seja, que atividades precisam ser realizadas por alguém para alcançar os objetivos?
Geralmente, prefiro começar pelas atividades. Na prática, porém, é um processo bastante iterativo.
Por favor, nota que "papel" não significa "pessoa". "Pessoa" pode referir-se a outros papéis que não têm nada a ver com os teus objetivos e sim com os seus próprios objetivos. Isso geralmente significa que é preciso adicionar objetivos adicionais que precisam ser apoiados.
3) Identificar Capabilities
Qual é o pré-requisito para que o papel possa realizar uma atividade?
Capabilities não precisam necessariamente ser algo incorporado no software.
4) Identificar Features e Stories
O que precisa ser feito para criar ou possibilitar Capabilities?
Stories devem consistir em trabalhos menores. Features têm mais a ver com possibilitar discussões a um nível mais detalhado.
Este texto é do blog de Jason Yip e foi traduzido por nós para português.