Gestão de projetos de software Agile: dos sprints à governança de portfólio

O Agile no desenvolvimento de software: o que muda face ao PM tradicional

A gestão de projetos tradicional pressupõe que um projeto pode ser definido à partida: âmbito, cronograma, orçamento, recursos. O trabalho do gestor de projeto é planear tudo, obter aprovação e depois acompanhar a execução face ao plano. O Agile pressupõe o contrário: que os requisitos vão mudar, que o planeamento detalhado para além das próximas semanas é ficção e que o valor vem de entregar software funcional em ciclos curtos em vez de uma grande entrega no fim. Para um gestor de projeto isto é uma mudança real, não cosmética. O plano torna-se contínuo em vez de fixo, o reporte de estado passa a semanal em vez de baseado em marcos, e o sucesso mede-se pelo valor entregue em vez do cumprimento do cronograma original.

As mudanças dividem-se em três categorias. Primeiro, o planeamento passa de abrangente a progressivo: um roadmap de alto nível cobre vários meses, mas o planeamento detalhado só se estende ao próximo sprint ou dois. Segundo, o controlo passa do desvio de cronograma para a velocity e o throughput: o gestor de projeto deixa de perguntar se estamos de acordo com o diagrama de Gantt e começa a perguntar quanto valor entregámos neste sprint. Terceiro, a comunicação passa de relatórios de estado formais para uma transparência contínua: a revisão de sprint, a retrospetiva e a reunião diária substituem as reuniões semanais do gestor de projeto como principais canais de informação. Nenhuma destas mudanças torna o gestor de projeto redundante, mas mudam o que ele faz. Se precisar de uma definição mais completa do próprio Agile, o nosso guia O que é o Agile? cobre os fundamentos; o resto deste artigo pressupõe essa base e foca-se na prática do gestor de projeto.

O modelo operacional do gestor de projeto Agile: sprints, cerimónias, artefactos

O trabalho do gestor de projeto Agile acontece dentro de uma cadência de sprint, tipicamente de duas a quatro semanas por iteração. Compreender o ciclo na perspetiva do gestor de projeto (e não do programador) é a diferença entre conduzir um projeto Agile e apenas assistir às cerimónias.

Mecânica do sprint: planeamento, execução, revisão, retrospetiva

O sprint tem quatro pontos em que o papel do gestor de projeto é distinto. O planeamento do sprint é onde a equipa se compromete com um conjunto de histórias, e o trabalho do gestor de projeto é garantir que o compromisso é realista dadas as dependências conhecidas, a capacidade e as restrições externas. A execução é onde o gestor de projeto remove obstáculos que a equipa não consegue resolver sozinha: bloqueios de compras, indisponibilidade de partes interessadas, dependências entre equipas. A revisão de sprint é onde a equipa demonstra software funcional às partes interessadas, e o trabalho do gestor de projeto é traduzir os resultados técnicos para a linguagem de negócio para o patrocinador. A retrospetiva é onde a equipa melhora o seu processo, e o gestor de projeto contribui com o contexto entre equipas que a equipa pode não ver. A velocity, medida como story points concluídos por sprint, torna-se o principal input de previsão do gestor de projeto: com três ou quatro sprints de histórico, prever datas de lançamento torna-se um exercício matemático em vez de um palpite.

Gestão do backlog: da visão ao sprint

O product backlog é a lista mestra de tudo o que a equipa poderá construir; o sprint backlog é o subconjunto comprometido para o sprint atual. O Product Owner é responsável pelas prioridades do product backlog, mas o gestor de projeto contribui com contexto que o Product Owner pode não ter: dependências entre projetos, marcos de negócio que restringem a sequência, prazos regulatórios ou de conformidade. A estimativa em story points é o mecanismo pelo qual a equipa dimensiona o trabalho em relação a si própria em vez de em tempo absoluto, e o gestor de projeto deve compreendê-la bem o suficiente para questionar estimativas que fogem ao padrão, sem fazer a estimativa ele próprio. Quando a equipa estima uma história em 13 pontos e o histórico mostra histórias semelhantes em 5, esse é um sinal que vale a pena investigar.

Artefactos e reporte: burndown, velocity, fluxo cumulativo

Três artefactos orientam o reporte do gestor de projeto Agile. O gráfico de burndown mostra o trabalho restante face ao tempo num sprint, e a sua forma revela se a equipa cumprirá o compromisso do sprint. As tendências de velocity ao longo de vários sprints revelam a capacidade e a estabilidade da equipa: uma velocity crescente muitas vezes significa que a equipa está a ganhar destreza com a base de código, uma velocity estável sugere um estado estacionário, e uma velocity decrescente frequentemente sinaliza dívida técnica ou disrupção da equipa. Os diagramas de fluxo cumulativo mostram os itens de trabalho ao longo dos estados (backlog, em curso, revisão, concluído) e revelam estrangulamentos: se o trabalho em curso incha enquanto o concluído fica estável, a equipa tem um problema de fluxo a resolver. O trabalho do gestor de projeto não é produzir estes artefactos (as ferramentas Agile geram-nos automaticamente) mas lê-los e traduzir os seus sinais num reporte adequado ao patrocinador.

Papéis e responsabilidades nas equipas de software Agile

O elemento mais mal compreendido do Agile no desenvolvimento de software é onde o gestor de projeto se enquadra. O Scrum define três papéis (Product Owner, Scrum Master, equipa de desenvolvimento) e não inclui um gestor de projeto. Na prática, a maioria das implementações Agile empresariais continua a ter gestores de projeto, e compreender o que eles realmente fazem evita o modo de falha comum em que o gestor de projeto e o Scrum Master se sobrepõem ou entram em conflito.

O papel do gestor de projeto nas equipas Agile

O gestor de projeto numa equipa Agile é responsável pelos resultados visíveis fora da equipa: entrega aos patrocinadores, coordenação entre equipas, reporte ao nível do portfólio, escalonamento de riscos e alinhamento com o negócio. O gestor de projeto não conduz as cerimónias do sprint (isso é território do Scrum Master) e não decide as prioridades das funcionalidades (isso é território do Product Owner). A autoridade do gestor de projeto está focada na entrega: é responsável pela data de entrega perante o negócio, pelo orçamento gasto, pelas dependências com outras equipas e pela comunicação com as partes interessadas fora da equipa. Na prática, isto significa que o gestor de projeto vive no espaço entre a equipa e a organização, traduzindo em ambas as direções e removendo os obstáculos organizacionais que a equipa não consegue resolver internamente.

Product Owner, Scrum Master, equipa de desenvolvimento

O Product Owner é responsável pelo product backlog, prioriza as funcionalidades e representa o cliente perante a equipa. O Scrum Master facilita as cerimónias, remove os impedimentos ao nível da equipa e orienta a equipa na prática Agile. A equipa de desenvolvimento (tipicamente de cinco a nove membros) constrói o software, auto-organiza-se em torno do compromisso do sprint e compromete-se com histórias específicas em cada sprint. Estes papéis são abordados com mais profundidade no nosso guia do Scrum Master e no guia do Product Owner; o ponto relevante para os gestores de projeto é que estes três papéis tratam do trabalho voltado para a equipa, enquanto o gestor de projeto trata do trabalho voltado para a organização.

Partes interessadas e direção: como os projetos Agile se ligam ao negócio

Uma equipa Agile não entrega a um cliente abstrato; entrega a um contexto de negócio com patrocinadores, comités de direção e responsáveis de negócio que precisam de tomar decisões com base no progresso da equipa. O gestor de projeto estrutura esta ligação através de três mecanismos: atualizações periódicas ao patrocinador que traduzem os resultados do sprint em termos de negócio, uma cadência de comité de direção (normalmente mensal) onde se tomam as decisões importantes, e uma relação com o responsável de negócio onde as perguntas do dia a dia sobre o produto são respondidas. Sem estas estruturas, a equipa desaparece da visibilidade organizacional, e as organizações reagem acrescentando uma supervisão ao estilo cascata que compromete a flexibilidade Agile. O trabalho do gestor de projeto é tornar o Agile legível para a organização sem o fazer deixar de ser Agile.

Frameworks no desenvolvimento de software: Scrum, Kanban, Scrumban, SAFe

Nem todas as equipas Agile deveriam usar Scrum. A escolha da framework é uma decisão do gestor de projeto que depende do padrão de trabalho da equipa, da maturidade Agile da organização e da natureza do software a construir. As quatro frameworks seguintes cobrem a maioria do desenvolvimento de software Agile empresarial.

Scrum é o clássico baseado em sprints. Iterações de duração fixa (tipicamente duas semanas), cerimónias definidas e um sprint backlog comprometido. Ideal para equipas que constroem novas funcionalidades numa cadência previsível, com um Product Owner capaz de se comprometer com um âmbito de sprint estável. Fraco para equipas com muito trabalho de manutenção ou onde dominam prioridades ditadas por interrupções. Abordado em profundidade na nossa introdução à metodologia Scrum.

Kanban é fluxo contínuo em vez de baseado em sprints. Os itens de trabalho movem-se através de colunas (backlog, em curso, revisão, concluído) com limites de trabalho em curso a controlar o fluxo. Ideal para equipas de suporte, trabalho de manutenção e equipas onde as prioridades mudam com mais frequência do que a duração de um sprint. Fraco para equipas que precisam de uma cadência de lançamento previsível ligada aos limites do sprint. Consulte o nosso guia de fluxo de trabalho Kanban e o guia do quadro Kanban.

Scrumban hibridiza os dois: cerimónias Scrum para o planeamento e a revisão, quadro Kanban para a gestão diária do trabalho. Útil para equipas em transição de Scrum para Kanban (normalmente quando o Scrum parece demasiado pesado) ou de Kanban para Scrum (normalmente quando a equipa precisa de mais disciplina em torno do compromisso). Muitas vezes a escolha pragmática para equipas que ultrapassam o Scrum estrito sem quererem abandonar totalmente as iterações.

SAFe (Scaled Agile Framework) destina-se a organizações que coordenam várias equipas Agile num programa ou produto partilhado. Sobrepõe um planeamento ao nível do programa (planeamento de Program Increment, tipicamente trimestral) ao Scrum ao nível da equipa. Útil para empresas com dezenas de equipas Agile a trabalhar no mesmo produto. Excessivo para organizações com menos de 5-10 equipas; considere LeSS ou Nexus como alternativas mais leves.

A escolha não é permanente. As organizações Agile maduras mudam muitas vezes de framework à medida que a composição da equipa, a maturidade do produto e o contexto organizacional evoluem. O trabalho do gestor de projeto durante a escolha da framework é tornar os compromissos visíveis e testar a escolha face à forma como a equipa realmente trabalha, e não à forma como os puristas do Agile dizem que a equipa deveria trabalhar.

Ligar o Agile e o PMO: ferramentas para portfólios mistos

A maior parte do desenvolvimento de software empresarial acontece em organizações que também executam projetos não relacionados com software: iniciativas de negócio, campanhas de marketing, investimentos de capital, programas de conformidade. Isto cria um problema de ferramentas que a maioria dos textos sobre Agile ignora.

O problema do portfólio misto: programadores no Jira, negócio no PPM

Os programadores preferem claramente o Jira (ou o Azure DevOps) porque se ajusta ao seu fluxo de trabalho: acompanhamento ao nível da história, quadros de sprint, refinamento do backlog, integração com o controlo de versões. As equipas de negócio preferem os sistemas PPM (gestão de portfólio de projetos) porque se ajustam ao seu fluxo de trabalho: acompanhamento de marcos, gestão de orçamento, dashboards ao nível do portfólio, capacidade de recursos entre projetos. A liderança precisa de uma visão única de todo o portfólio, Agile e cascata em conjunto. Quando cada domínio usa a sua ferramenta nativa, a organização acaba com três fontes de verdade: a visão dos programadores no Jira, a visão dos responsáveis de negócio no PPM e a visão da liderança montada manualmente em slides para cada comité de direção. Este é o modo de falha que a maioria das empresas atinge quando a adoção do Agile cresce sem uma estratégia de ferramentas.

Como integrar as ferramentas Agile com um sistema de portfólio de projetos

A resposta arquitetonicamente limpa é manter o trabalho ao nível da equipa no Jira (onde deve estar) e o trabalho ao nível do portfólio num PPM (onde deve estar), com uma integração a sincronizar os dois. O que deve sincronizar: o estado ao nível da tarefa (aberto, em curso, concluído), a atribuição do responsável, as datas e os story points ou estimativas. O que não deve sincronizar: os comentários diários, a granularidade das subtarefas, os campos específicos dos programadores. A sobre-sincronização cria ruído; a subsincronização cria lacunas. O padrão correto é que os programadores trabalhem naturalmente no Jira, que os gestores de projeto e o PMO vejam no PPM o subconjunto do trabalho do Jira relevante para o portfólio ao lado dos projetos não-Jira, e que ninguém tenha de entrar numa ferramenta que não é o seu espaço de trabalho principal.

A integração FlexiProject-Jira na prática

O FlexiProject implementa este padrão com uma integração direta com o Jira que importa epics, histórias e tarefas do Jira preservando o estado, o responsável e o tipo. Os filtros JQL permitem aos gestores de projeto selecionar exatamente que itens de trabalho aparecem na visão do FlexiProject, e as importações podem extrair de vários projetos Jira em simultâneo para programas entre equipas. O mapeamento de utilizadores resolve o problema comum de a mesma pessoa ter identificadores diferentes no Jira e no PPM: o mapeamento é configurado uma vez e depois é automático, pelo que a titularidade das tarefas permanece coerente entre os dois sistemas. O resultado é que as tarefas do Jira aparecem no cronograma do FlexiProject ao lado de tarefas de negócio, de marketing e de outro trabalho não relacionado com software – a liderança e o PMO veem todo o portfólio sem nunca entrar no Jira, enquanto os programadores continuam a trabalhar na sua ferramenta preferida. O artigo dedicado à integração FlexiProject-Jira aborda a configuração técnica com mais detalhe.

Governança e reporte de projetos Agile num PMO

Os PMO governam os projetos Agile de forma diferente dos projetos em cascata, e fazer isto bem é onde a maioria das empresas tem dificuldades. O modo de falha é aplicar governança em cascata (acompanhamento detalhado do cronograma, aprovações de marcos, controlo de alterações de âmbito) ao trabalho Agile, o que produz atrito sem acrescentar valor de supervisão.

Métricas que importam para o reporte do PMO Agile

Nem toda a métrica Agile pertence a um relatório de PMO. Os gráficos de burndown e a velocity são métricas ao nível da equipa úteis para a própria equipa; mostrá-las a um patrocinador convida ao microgestão sem acrescentar valor de decisão. As métricas que pertencem ao reporte do PMO são orientadas a resultados: cycle time (quanto tempo do compromisso à entrega), throughput (funcionalidades entregues por período), taxa de defeitos escapados (qualidade da entrega) e taxa de sucesso do objetivo do sprint (se os compromissos estão a ser cumpridos). Estas métricas respondem às perguntas que os patrocinadores realmente fazem: estamos a entregar, a qualidade aguenta, os compromissos são realistas. As métricas internas do sprint ficam com a equipa; as métricas ao nível do portfólio vão para o PMO.

Visão ao nível do portfólio: misturar projetos Agile e em cascata

Um projeto Agile sem datas de fim rígidas e um projeto em cascata com marcos fixos precisam de aparecer na mesma visão de portfólio, e conciliar os seus ritmos diferentes é onde as ferramentas de PMO justificam o seu custo. O padrão pragmático é o rolling wave: os projetos Agile mostram uma onda de curto prazo comprometida (os próximos um a três sprints) ao nível de detalhe, e as ondas futuras ao nível de estimativa. Os projetos em cascata mostram marcos e dependências com o mesmo peso visual que as ondas Agile. A visão de portfólio mostra ambos ao mesmo tempo, com o patrocinador a poder ver que o próximo lançamento da equipa Agile se alinha com (ou falha) o marco de transição do projeto em cascata. As abordagens de gestão de projetos híbrida tratam o mesmo problema de conciliação ao nível do projeto; as ferramentas ao nível do portfólio escalam-no por toda a organização.

Gestão de riscos em projetos Agile

Os projetos Agile têm um perfil de risco próprio que a gestão de riscos tradicional muitas vezes ignora. A falha de sprint (a equipa não conclui as histórias comprometidas) sinaliza problemas de estimativa ou planeamento e justifica investigação, não culpa. A variância de velocity de sprint para sprint sinaliza frequentemente uma disrupção da equipa (novos membros, doença, prioridades concorrentes) que o gestor de projeto pode abordar. O risco de dependência entre equipas é a maior fonte isolada de atraso no Agile em escala: se o sprint da equipa A depende do trabalho concluído da equipa B, e B atrasa, A fica bloqueada. A acumulação de dívida técnica é um risco oculto que reduz a velocity ao longo do tempo sem qualquer defeito visível. Os registos de riscos do PMO devem captar estes riscos específicos do Agile ao lado dos riscos de projeto tradicionais, e a cadência de revisão deve alinhar-se aos limites do sprint em vez dos ciclos mensais do gestor de projeto.

FAQ: gestão de projetos de software Agile

Qual é a diferença entre um gestor de projeto e um Scrum Master?

O Scrum Master facilita a equipa internamente: conduz as cerimónias, orienta na prática Agile, remove os impedimentos ao nível da equipa. O gestor de projeto entrega à organização externamente: gere a comunicação com o patrocinador, as dependências entre equipas, o orçamento, o reporte de portfólio e os obstáculos organizacionais que a equipa não consegue resolver sozinha. Em equipas pequenas uma pessoa pode desempenhar ambos os papéis, mas no Agile empresarial são distintos: o Scrum Master é responsável pela saúde da equipa, o gestor de projeto é responsável pela entrega perante o negócio.

Como se planeia um lançamento com equipas Agile?

O planeamento do lançamento combina a velocity da equipa (pontos concluídos por sprint) com o backlog do lançamento (pontos estimados para o âmbito do lançamento) para produzir um intervalo provável de data de lançamento. Três sprints de histórico de velocity dão uma previsão utilizável; dez sprints dão uma fiável. As datas de lançamento são expressas como intervalos (P50 e P80) em vez de pontos, e refinadas à medida que mais sprints se concluem. Os lançamentos de data fixa exigem flexibilidade de âmbito; os lançamentos de âmbito fixo exigem flexibilidade de data.

Como é que o Agile se enquadra num portfólio com projetos em cascata?

Os projetos Agile e em cascata coexistem no portfólio através de um sistema de gestão de portfólio que mostra ambos com a granularidade apropriada. Os projetos Agile mostram o trabalho comprometido de curto prazo em detalhe e o trabalho futuro ao nível de estimativa; os projetos em cascata mostram marcos e dependências. A visão de portfólio faz emergir as dependências entre projetos (o lançamento da equipa Agile bloqueia o go-live do projeto em cascata) para que os PMO possam gerir o portfólio misto sem forçar uma metodologia na forma da outra.

De que ferramentas precisam os gestores de projeto Agile para além do Jira?

O Jira gere bem o trabalho Agile ao nível da equipa mas não gere bem o PPM ao nível do portfólio. Os gestores de projeto Agile normalmente precisam de um sistema PPM que se integre com o Jira (importando tarefas, estados e estimativas) para o reporte ao nível do portfólio, as dependências com projetos não Agile, a gestão de orçamento ao longo do projeto e os dashboards executivos. Quer o PPM seja o FlexiProject, o Planview ou outra plataforma, o padrão de integração é o mesmo: os programadores ficam no Jira, os gestores de projeto e o PMO trabalham no PPM, a integração mantém ambos sincronizados.

Como se lida com projetos de âmbito fixo e prazo fixo com Agile?

Os projetos puramente de âmbito e prazo fixos não se adequam bem ao Agile puro, mas são comuns em setores regulados, projetos de conformidade e contratos com fornecedores. A resposta pragmática é híbrida: compromisso de âmbito e prazo ao estilo cascata ao nível do projeto, execução ao estilo Agile no seu interior. Os sprints entregam de forma incremental rumo ao prazo fixo, com os primeiros sprints a produzir funcionalidade mínima viável e os sprints posteriores a acrescentar acabamento. Os compromissos de âmbito acontecem através de um controlo de alterações explícito em vez de um refinamento contínuo, protegendo o compromisso de prazo.

Fazer o PM Agile funcionar na prática

A gestão de projetos de software Agile não consiste em conduzir cerimónias de sprint ou escrever story points. Consiste em entregar projetos de software com sucesso numa organização que também executa trabalho não Agile, onde o gestor de projeto se situa entre uma equipa Scrum e um PMO que precisa de visibilidade ao nível do portfólio. O trabalho do gestor de projeto é diferente do do Scrum Master: o Scrum Master é responsável pela saúde da equipa, o gestor de projeto é responsável pela entrega perante o negócio. O modelo operacional do gestor de projeto funciona na cadência do sprint mas reporta em métricas de resultado, usa frameworks Agile adequadas ao padrão de trabalho da equipa e integra o trabalho de equipa baseado no Jira numa visão de portfólio baseada em PPM. A governança e o reporte adaptam-se ao ritmo do Agile em vez de forçarem o Agile a padrões de reporte em cascata. As ferramentas importam: sem integração entre o Jira e um sistema PPM, a organização acaba com três fontes de verdade e nenhuma delas completa. O FlexiProject apoia este padrão através de uma integração direta com o Jira que importa epics, histórias e tarefas com o estado, o responsável e o tipo preservados, seleção filtrada por JQL, mapeamento de utilizadores entre sistemas e uma visão de cronograma unificada onde o trabalho do Jira aparece ao lado dos projetos não Agile. A liderança vê todo o portfólio, os programadores ficam na sua ferramenta preferida, e os gestores de projeto deixam de reconstruir a mesma visão em três sítios todas as semanas. O trabalho do gestor de projeto Agile é fazer isto funcionar na prática, não apenas saber como deveria funcionar na teoria.