O triângulo de ferro do planejamento

O mais novo ato de equilíbrio e como alcançar o nirvana do gerenciamento ágil de projetos

Tareq Aljaber Tareq Aljaber
Buscar tópicos

Todos os projetos de software ágeis têm objetivos: o que o projeto precisa entregar, quando ele precisa ser entregue e dentro de qual orçamento. No entanto, gerenciar essas três restrições pode ser um ato complexo de malabarismo. Então, vamos aproveitar o triângulo de ferro do planejamento, que existe há décadas, e aprender como equilibrar variáveis diferentes que podem ajudar as equipes de software ágeis a alcançar o nirvana do gerenciamento ágil de projetos.

O triângulo de ferro tradicional

Os modelos do triângulo de ferro restringem o gerenciamento de projetos e essas restrições são consideradas de "ferro", porque não é possível mudar uma restrição sem afetar as outras. O triângulo de ferro original, proposto pelo Dr. Martin Barnes em 1969, segue uma abordagem de cascata para o desenvolvimento de produto: o escopo é fixo e os recursos e o tempo são variáveis. Para uma equipe de software, isso significa que as equipes começariam um projeto definindo os requisitos do produto para determinar o escopo de um projeto (uma lista de itens de trabalho). Os recursos e o cronograma são variáveis e estimados dependendo do escopo fixo.

Restrições do triângulo de ferro
  • Escopo é o trabalho a ser feito – como recursos e funcionalidades – para entregar um produto funcional.
  • Recursos incluem o orçamento e os membros da equipe que trabalham para entregar e executar.
  • Tempo é quando as equipes vão entregar ao mercado tais versões e marcos.

O objetivo do triângulo de ferro é fornecer às equipes de produto as informações necessárias para fazer concessões que vão ajudar os negócios. Por exemplo, se as equipes tiverem um escopo fixo, elas podem estar na metade de um projeto e perceber que não vão conseguir cumprir data de lançamento. As únicas variáveis que elas podem mudar são: 1) Tempo — elas podem aceitar uma data de lançamento posterior ou 2) Recursos — elas podem adicionar mais pessoas ao projeto, o que vai aumentar os custos. À medida que o desenvolvimento de software evoluiu no século XXI, a necessidade de uma colaboração melhor e a capacidade de responder com rapidez ao feedback do cliente se tornaram cruciais e, além disso, a metodologia ágil surgiu.  

Triângulo de ferro em cascata | Instrutor ágil da Atlassian

Mapeando o triângulo de ferro até a agilidade

Se você faz parte de uma equipe que pratica o desenvolvimento de cascata ou se é novo no desenvolvimento ágil, é importante lembrar a diferença entre o que é fixo e o que é estimado. Diferente do desenvolvimento de cascata, os projetos ágeis têm cronograma e recursos fixos, enquanto o escopo varia. Embora o escopo de um projeto possa mudar no desenvolvimento ágil, as equipes se comprometem com iterações fixas do trabalho: sprints, se elas estiverem usando uma estrutura scrum; limites de WIP, se estiverem usando uma estrutura kanban. Também é uma prática recomendada manter as equipes fixas durante todo o processo de desenvolvimento. Ao manter as equipes consistentes em um produto ou projeto, elas se tornam mais eficientes por meio da confiança e continuidade desenvolvidas.  

Cascata versus ágil | Instrutor ágil da Atlassian

A ideia de escopo é a mesma que no desenvolvimento ágil: qual software construir e entregar. No entanto, a agilidade foca nos requisitos de alto nível, ao invés de tentar definir antecipadamente requisitos detalhados e profundos. O escopo de um projeto é gerenciado e organizado (priorizado) regularmente pelo gerente de projeto em uma ferramenta como o Jira Software. O gerente de produto decide qual trabalho deve ser realizado no próximo sprint com base no feedback ágil qualitativo e quantificativo de diversos canais (condições do mercado, feedback do cliente, concorrentes, etc.). E como os recursos e o tempo são fixos, é mais fácil para as equipes de desenvolvimento reagirem às mudanças de mercado e entregarem valor aos clientes com mais rapidez. Esta transparência de restrições mantém as equipes honestas sobre uma cadência rápida e consistente de lançamento, que é um locatário principal do desenvolvimento ágil; e observando os projetos pelas lentes do triângulo de ferro, as equipes são capazes de se adaptar sem abandonar um plano.  

Planejamento ágil de longo prazo e o triângulo de ferro

À medida que os projetos se tornam maiores, mais equipes são necessárias e a caixa de tempo se torna maior. Além disso, a noção de recursos e tempo fixos, enquanto o escopo varia, não é uma abordagem válida para todos os projetos ágeis. O planejamento ágil de longo prazo requer um triângulo de ferro mais flexível, que permite que as equipes planejem com antecedência e garantam que estão cumprindo os objetivos de negócios. Pense, por exemplo, sobre o movimento de início enxuto e a noção de produto mínimo viável (MVP). Um MVP, por definição, é um conjunto pequeno de recursos (escopo) que entrega valor ao cliente. Para chegar a isso, as equipes de MVP podem precisar ter um escopo fixo – o número de recursos – com tempo sendo a única variável (ex. você não pode lançar sem determinados recursos, então a data de lançamento é adiada). Apenas depois do lançamento do MVP, as equipes mudam para um escopo variável. 

Independente das diferenças entre o desenvolvimento ágil e o de cascata, ao usar o triângulo de ferro, não existe certo ou errado. Ele foi criado para ajudar você a fazer as melhores decisões e concessões para alcançar seus objetivos de negócios. Uma ferramenta como o Portfolio for Jira visualiza a base construtora de um plano – escopo, pessoas e tempo – para ajudar as equipes a planejar em tempo real. Você pode brincar facilmente com o escopo, as equipes e o tempo para planejar seu próximo lançamento de produto, usando os dados existentes da equipe no Jira Software.