Metodologia ágil ou tradicional: porque não as duas?
outubro 3, 2011 2 Comentários
Os modelos ágeis de gestão vem ganhando cada vez mais espaço nas organizações, mas nem sempre são bem aceitas ou entendidas por gerentes/executivos acostumados com o gerenciamento de projetos no modelo tradicional (em cascata, ou waterfall). As discussões sobre vantagens e desvantagens de cada modelo são, muitas vezes, inflamadas e polarizadas, onde cada um dos lados tenta doutrinar o outro.
Por mais que cada modelo ofereça uma série de vantagens e desvantagens (que devem ser avaliadas por cada organização e, mais especificamente, cada tipo de projeto) o que eu tenho visto é que a implementação “pura” de um modelo ou de outro é muito rara. Poucos são os lugares onde o gerenciamento do projeto segue dogmaticamente os preceitos (“boas práticas”) listadas no PMBoK ou que executem todos os seus projetos usando Scrum, por exemplo. Se olharmos criticamente um conjunto de projetos de determinada empresa é muito provável que vejamos a utilização de práticas de ambos modelos.
O objetivo desse post é compartilhar uma experiência onde tive a oportunidade de trabalhar com os dois modelos simultaneamente no mesmo projeto, e discutir sobre os ganhos percebidos, dificuldades encontradas e adaptações (tailoring) necessárias.
Histórico do projeto
O projeto tratava do desenvolvimento de uma inovação em um produto do cliente, cuja janela de inserção no mercado era bem definida (e restrita). Os requisitos do sistema, por sua vez, eram bastante complexos, e ainda não totalmente especificados (o que ocorreu ao longo do projeto).
Devido à importância estratégica do projeto o cliente necessitava validar entregas parciais e ter algumas funcionalidades implementadas em versões de demonstração do produto para ser utilizado em “Road Shows”. Assim, uma das ações para garantir a execução desse trabalho foi o estabelecimento de um contrato para a alocação de um time de tamanho fixo durante um período determinado.
Considerando as características do projeto o modelo de desenvolvimento escolhido foi o Scrum, uma vez que este permitiria tratar o desenvolvimento do produto de forma incremental e ainda assim garantir a qualidade do produto e do processo (outro requisito importante para o cliente).
No entanto, apesar de entender o funcionamento do modelo “puro” do Scrum o cliente demandou um acompanhamento nos moldes tradicionais, considerando um projeto “waterfall” e artefatos previstos no modelo de maturidade CMMi. Com isso, por exemplo, foram criados o cronograma macro de entregas descrito em um gráfico de Gantt, algumas métricas de acompanhamento de valor agregado e relatórios de status semanais.
Desafios
Em virtude dessa gestão “mista” foi necessário avaliar processos e práticas das duas correntes de pensamento e avaliar criticamente o uso das mesmas no projeto, tendo em mente a não duplicação do trabalho e a otimização do tempo e esforço para a gestão do projeto, com a garantia do atendimento das expectativas dos stakeholders.
Como resultado dessa análise alguns processos tiveram de ser adaptados. Já alguns outros continuaram a ser executados da mesma maneira, uma vez que o resultado produzido era o mesmo ou não apresentava diferenças significativas usando um dos métodos.
Os ajustes no processo foram sendo feitos e validados com o cliente ao longo do projeto, com o consequente mapeamento das práticas e grupos de processos de modo a gerenciar o projeto de forma eficiente.
A prática
As principais disciplinas exercidas durante o projeto estão listadas a seguir, juntamente com uma explanação de como elas foram executadas.
Gestão do escopo
O escopo do projeto foi dividido em pacotes de trabalho, sendo que cada requisito foi detalhado pelo analista de requisitos para a criação do product backlog do projeto. No entanto, diferentemente de um projeto ágil puro, toda a quebra dos requisitos em estórias e atividades foi feita durante o planejamento do projeto e o backlog resultante foi usado como guia para o planejamento das iterações (sprints).
Quaisquer mudanças nos requisitos do projeto, seja por entendimento dos mesmos ou por alteração do escopo original, foram tratadas através de um procedimento de “Solicitações de Mudança” (Change Requests), onde as mudanças eram analisadas, detalhadas e incluídas no product backlog.
Gestão do cronograma
Apesar do projeto ter sido executado usando Scrum o conteúdo de cada iteração foi definido com base na priorização do backlog feita pelo Product Owner ainda durante a fase de planejamento. Como o conteúdo de cada iteração estava, em grande parte, definido de antemão a reunião de planejamento de cada sprint focava no balanceamento de volume de trabalho (esforço) e força produtiva disponível (capacidade), além de fazer adaptações necessárias na velocidade do time e incorporação de atividades remanejadas de outros sprints.
Como o Gerente de Projetos do cliente precisava ter visibilidade do projeto como um todo, foi criado um cronograma no MS-Project para acompanhar a execução de cada requisito, sendo que os milestones definidos continham um subconjunto de requisitos que seriam implementados. O cronograma era acompanhado com base no progresso dos sprints, e servia como referência para coleta de métricas do projeto.
O acompanhamento do projeto se dava tanto pelo cronograma de funcionalidades quanto pelo gráfico de burndown de cada sprint. Os dados do cronograma eram usados para informar o progresso do projeto como um todo, enquanto o burndown indicava o progresso de cada sprint.
Gestão do custo
Como o time de projeto era fixo a gestão dos custos do projeto limitou-se ao controle de despesas, o que simplificou a tarefa. Os índices de valor agregado derivavam diretamente dos dados inseridos no MS-Project.
Gestão da comunicação
O plano de comunicação foi criado no início do projeto após a identificação de todos os stakeholders. Para cada tipo de informação a ser divulgada foi definida a periodicidade e sua audiência, bem como o propósito e o responsável pela coleta e divulgação de cada informação. O time de projeto era informado regularmente através das reuniões diárias e demais cerimônias (planning, review) do sprint. Já a alta gerência e o cliente eram informados através de relatórios semanais de progresso.
Um mapa com papéis e responsabilidades de cada stakeholder foi criado e divulgado, de modo a tornar público todos os canais de informação do projeto.
Gestão de riscos
O processo de identificação e análise qualitativa dos riscos, bem como o planejamento de resposta aos mesmos, seguiu o processo tradicional, com o uso de uma planilha de acompanhamento atualizada semanalmente, sendo que o time e demais stakeholders eram envolvidos no processo através das reuniões diárias, reuniões periódicas de status e cerimônias do Scrum.
Gestão da qualidade
O projeto seguiu um processo de desenvolvimento aderente ao CMMi e foi acompanhado por um analista da área de Qualidade, que auditava periodicamente (a cada final de sprint) as entregas (artefatos) do mesmo. A qualidade era garantida através da criação e acompanhamento de itens de “Não Conformidade” em ferramenta específica, que eram enviados ao cliente mensalmente.
Gestão de RH:
A alocação de pessoas foi facilitada pelo fato do time ter um tamanho fixo ao longo de todo o projeto. Como a estrutura da empresa é do tipo matricial o gerente funcional era responsável pela alocação das pessoas, mas uma vez definido o time com as habilidades necessárias (com base no escopo definido) o esforço de gestão foi reduzido, limitando-se ao planejamento e controle de ausências ocasionais e períodos de férias, bem como, obviamente, ao acompanhamento do desempenho dos membros da equipe.
Gestão de aquisições:
Não foi necessário durante o projeto.
Conclusão
A amostra de projetos executados com essa metodologia é pequena e limitada aos projetos que eu gerenciei para esse cliente específico mas, apesar do trabalho inicial de análise ter tomado algum tempo, os resultados foram bastante satisfatórios.
O gerente de projetos do cliente ficou satisfeito por ter a visibilidade que precisava, e os produtos dos projetos foram entregues no prazo e com qualidade necessária. Um resultado adicional, que comprova a eficiência do modelo, é que ele tem sido adotado inclusive por outros parceiros com quem esse cliente executa projetos.
E você, tem alguma experiência desse tipo?
Posts relacionados:
