Execução de programas ágeis (sem perder a cabeça)

Algumas pessoas podem pensar que a transição para ágil significa perder de vista uma visão geral maior. Não há como não discordar.

Dan Radigan Dan Radigan

Os usuários iniciais do desenvolvimento ágil eram equipes pequenas e independentes que trabalhavam em projetos pequenos e independentes. Eles provaram que o modelo ágil pode funcionar para a alegria e a melhoria de fabricantes de software ao redor do mundo. Mais recentemente, organizações maiores estão usando dimensionamento ágil além do uso em projetos ou equipes pequenas, buscando maneiras de aplicá-lo aos programas como um todo. 

This is not without its challenges. But that doesn't mean it can't be done! 

Cascata versus ágil

Vamos começar com o básico – como o que torna ágil diferente. 

Estilos de gerenciamento de projeto tradicional, como cascata, criação em fases. Abaixo está uma ilustração de um projeto cascata padrão. Esse estilo de desenvolvimento de produto coloca tudo em uma única versão "big bang" de alto risco. Uma vez que um projeto passa por uma fase, é difícil para revisá-lo, pois as equipes estão sempre avançando para a próxima fase.

Exemplo de liberação cascata | Coach Agile Atlassian

Estilos de gerenciamento de projeto tradicional muitas vezes criam "caminhos críticos", nos quais o projeto não pode avançar até um problema seja resolvido. Para adicionar insulto à injúria, o cliente final não pode interagir com o produto até que ele esteja totalmente completo. Assim, questões importantes no design do produto, bem como o código, ficam desconhecidas até o lançamento.

Vamos comparar isso com um estilo de gerenciamento de projetos ágil, que usa uma abordagem iterativa para desenvolvimento com intervalos de feedbacks regulares. Essas iterações permitem que a equipe possa se focar (e ser produtiva) em outra área do projeto enquanto um obstáculo é resolvido.

Exemplo de gerenciamento de projetos ágeis | Coach Agile Atlassian

Além de remover caminhos críticos, as iterações permitem interagir com o produto durante o desenvolvimento.

Isso, por sua vez, fornece à equipe oportunidades constantes de criar, entregar, aprender e ajustar. Mudanças do mercado não pegarão você desprevenido, e as equipes estão preparadas para se adaptarem rapidamente aos novos requisitos.

Um benefício ainda maior é o compartilhamento de conjuntos de habilidades na equipe de software. Os conjuntos de habilidades sobrepostos da equipe adicionam flexibilidade ao trabalho em todas as partes da base de código da equipe. Desse modo, trabalho e tempo não são desperdiçados se a direção do projeto mudar. (Para mais sobre isso, consulte nosso artigo sobre criação de ótimas equipes ágeis).

Como criar um ótimo programa ágil

Quando um programa migra do gerenciamento de projeto tradicional para o ágil, a equipe e as partes interessadas devem usar dois conceitos importantes:

  • O foco do proprietário do produto é otimizar o valor da produtividade da equipe de desenvolvimento. A equipe de desenvolvimento depende de o proprietário do produto priorizar o trabalho mais importante.
  • A equipe de desenvolvimento só pode aceitar o trabalho que tem capacidade para realizar. O proprietário do produto não envia trabalho para a equipe ou compromete a equipe com prazos arbitrários. A equipe de desenvolvimento puxa o trabalho da lista de pendências do programa à medida que consegue aceitar novos trabalhos.

Vamos explorar os mecanismos que os programas ágeis usam para organizar, executar e estruturar o trabalho de uma forma iterativa.

Roadmaps

Um roteiro mostra como um produto ou solução se desenvolve ao longo do tempo. Os roteiros são compostos por iniciativas, que são grandes áreas de funcionalidade, e incluem cronogramas que comunicam quando um recurso será disponibilizado. À medida que o programa se desenvolve, o roteiro pode mudar–às vezes sutilmente, às vezes totalmente. A meta é manter o roteiro focado nas condições atuais do mercado e nas metas a longo prazo. 

Requisitos

Cada iniciativa no roteiro é dividida em um conjunto de requisitos. Os requisitos ágeis são descrições breves da funcionalidade exigida, em vez de documentos com 100 páginas associados a projetos tradicionais. Eles são desenvolvidos ao longo do tempo e usam o entendimento compartilhado sobre o cliente pela equipe e o produto desejado. Os requisitos ágeis permanecem enxutos enquanto todos na equipe desenvolvem um entendimento compartilhado por meio de colaboração e conversas contínuas. Apenas quando a implementação está para começar que eles são mais detalhados. 

Lista de pendências

lista de pendências define as prioridades para o programa ágil. A equipe inclui todos os itens de trabalho na lista de pendências: novos recursos, erros, melhorias, tarefas técnicas e de arquitetura, etc. O proprietário do produto prioriza o trabalho na lista de pendências para a equipe de engenharia. Então, a equipe de desenvolvimento usa a lista de pendências priorizada como fonte única da verdade para o que o trabalho precisa ser feito. 

Veículos de entrega ágil

O método ágil pode ser implementado usando várias estruturas (como scrum e kanban) para fornecer software. As equipes scrum usam sprints para guiar desenvolvimento, e as equipes kanban normalmente trabalham sem intervalos de trabalho fixos. No entanto, ambas as estruturas usam  veículos de entrega grandes , como epics e versões, para estruturar o desenvolvimento para uma frequência de liberação sincronizada para produção.

Métricas ágeis

Equipes ágeis prosperam com as métricas. Os limites dotrabalho em andamento (WIP) mantêm a equipe e o negócio focados na entrega de um trabalho de alta prioridade. Os gráficos, como burndown e gráficos de controle, ajudam a equipe a prever a frequência de entrega, e os diagramas de fluxo contínuo ajudam a identificar os obstáculos. Essas métricas e artefatos mantêm todos focados em grandes metas e aumentam a confiança na capacidade da equipe de entregar trabalho futuro. 

Execuções ágeis com confiança

Um programa ágil não pode funcionar sem um nível elevado de confiança entre os membros da equipe. Isso requer sinceridade ao ter conversas difíceis sobre o que é certo para o programa e o produto. Como as conversas acontecem em intervalos regulares, ideias e preocupações são expressas regularmente. Isso significa que os membros da equipe também devem confiar na capacidade do outro (e vontade) para executar as decisões tomadas durante as conversas.

Em resumo, o desenvolvimento ágil é uma abordagem iterativa e estruturada para fazer software. Ele fornece a capacidade de responder às mudanças sem sair dos trilhos. E isso é uma boa notícia para qualquer programa.