Gerenciamento de programa ágil

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
Buscar tópicos

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. 

Isso não deixa de apresentar desafios. Porém, não significa que não pode ser feito! 

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 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 do backlog 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.

Roteiros

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 vai ser disponibilizado. À medida que o programa se desenvolve, o roteiro pode sofrer mudanças – às vezes sutis, às vezes gerais. 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

backlog 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 no backlog para a equipe de engenharia. Então, a equipe de desenvolvimento usa o backlog priorizado como fonte única da verdade para qual 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, em geral, 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 lançamento sincronizado para produção.

Métricas ágeis

Equipes ágeis prosperam com as métricas. Os limites do trabalho em andamento (WIP) mantêm a equipe e os negócios 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. 

a seguir
Workflow