Na versão tradicional de gestão de Projectos (leia-se PMI, no contexto), o âmbito do projecto é a base sobre a qual se estabelece o contrato entre um fornecedor e um cliente. Alterações ao âmbito dão origem a mudanças, que terão impacto no projecto, nas vertentes de custo, prazo, ou qualidade.
Na formulação ágil de gestão de projectos, o âmbito é essencialmente uma variável de gestão, apenas superficialmente definida, entendida como altamente mutável, sendo por isso o tempo e o custo as bases do contrato. Ou seja, num projecto Ágil, estabelece-se um orçamento, para um determinado tempo de projecto (timebox), no qual será desejável entregar um determinado âmbito, ainda não totalmente detalhado e a clarificar no detalhe, que serviu de base à estimativa de custo e de tempo. Mudanças no âmbito são assumidas ab initio como certezas, por isso a sua pré-definição não é um factor determinante do rigor da gestão.
Assim, em cada fase do projecto (sprint), é detalhado o âmbito concreto, definido o que cabe no tempo definido e negociado, em caso de necessidade, o que sai do âmbito do projecto, para continuarem a ser cumpridas as restrições do projecto: tempo e custo. O que não couber, passa para uma evolução seguinte do projecto.
Necessariamente, algumas expectativas do cliente, se não for clara esta situação, poderão ser goradas. Um produto que não cumpre, mesmo entregue no prazo, é um produto defeituoso.
Apesar das estatísticas sempre referirem que uma parte muito pequena dos projectos cumpre em prazo e em custo, será que as organizações estão verdadeiramente preparadas para aceitar que tudo é, afinal, uma questão de compromisso, resolvida pela gestão ágil?
Ou continua a ser regra que nada no âmbito é para negociar, em face das restantes restrições impostas, a não ser para cumprir o “já agora” que sempre acontece?
E como pode um GP trabalhar de duas formas tão distintas? Como muda o papel para o GP entre PMI e Agile?
skip to main |
skip to sidebar
Blog sobre gestão de projectos e as suas dificuldades, técnicas, conflitos, boas práticas, dúvidas, novidades, referências, processos e outras coisas para aprendermos entre todos, todos os dias.
Blog Archive
Sobre
Seguidores
Contribuidores
Contador
Blogger Templates created by Deluxe Templates
Wordpress by cubex
Copyright 2010 Gestão Projectos Portugal
All rights reserved.
Powered by Blogger
6 comentários:
Este é de facto um assunto pertinente, já que actualmente temos projectos Agile de decorrer e que estão a ser geridos de alguma forma alinhados com os principios do PMBoK, os quais estão reflectidos na actual metodologia de Gestão de Projectos (parte integrante do Sistema de Gestão da Qualidade).
Neste contexto, aquilo que se pretende é, de alguma forma, integrar aquilo que de bom existe nas duas metodologias.
Considero também que, para além da questão da integração das duas metodologias, há ainda a questão dos papeis e responsabilidades dos diversos intervenientes no projecto Agile e o Gestor de Projecto, nomeadamente a relação com o Engagement Manager (em projectos Outsystems). Qual é a responsabilidade de cada um?
Em termos de Gestão de Projecto, nos projectos que temos em execução, estamos a seguir as orientações do PMI na sua generalidade, sendo que o planeamento é efectuado em conjunto com o Engagament Manager e o Delivery Manager. Neste capítulo do planeamento, advogo que é necessário fixar o âmbito do projecto e, caso necessário (quando o grau de incerteza é grande), dividi-lo em fases, sendo que em cada fase poderão existir várias sprints.
Uma das maiores diferenças reside então no planeamento do cronograma, em que as diversas sprints devem ser nele espelhadas (com a respectivas timebox) e o âmbito/tarefas definidas para cada sprint.
Na minha opinião, a sprint deve cumprir com o ãmbito (na sua totalidade) para a qual foi criada/planeada. Ou seja, caso haja um atraso (ou avanço) numa tarefa da sprint, a data de conclusão da sprint sofreria o respectivo impacto. Isto quer dizer que o âmbito é fixo por sprint e a duração desta pode variar um pouco, consoante o progresso de execução das tarefas. Assim, desta forma, é possível, para um âmbito fixo, determinar o potencial atraso (ou avanço) do projecto face ao planeado, informação muito importante (e por vezes crucial) para o cliente.
De acordo com a minha experiência, o âmbito é uma das componentes mais importantes para o cliente, que paga um serviço para obter em troca exactamente aquilo que ele precisa, nada mais, nada menos. E é nesse sentido se deve orientar o controlo do projecto. Mas obviamente que admito haver outras aproximações à concretização de projectos Agile com a Gestão de Projectos orientada ao PMI.
Esta só poderia ser a opinião de alguém cuja experiência está focada no PMI. Alterações ao âmbito IMPLICAM alterações no prazo DA SPRINT. Em desenvolvimento Ágil, a resposta seria justamente contrária: alterações ao âmbito que necessitem ser colocadas na sprint actual remetem outro âmbito para a próxima Sprint. Alterações ao âmbito que comprometam a data estabelecida pela Timebox serão deixadas para a versão seguinte do produto. Ou seja...algo, seja do âmbito original ou das alterações, terá de cair, no actual projecto.
Na vertente clássica, âmbito é sagrado (aliás, é comum acrescentar, mas não retirar).
Na versão Ágil, tempo é sagrado, até porque o âmbito muda SEMPRE (exagero razoavelmente suportado pelas estatísticas).
Sendo que não dá para satisfazer os dois, quando há conflito...como fazer? Porque é necessário fazer alguma coisa.
Bom dia,
na minha opinião PMI e ágil são completamente ajustáveis, senão vejamos:
O PMI define 5 fases para a gestão do projecto: Iniciação, Planeamento, Execução e Controlo e por fim o encerramento.
Quando chegamos a fase do planeamento, realmente temos de ter o âmbito do produto a desenvolver de forma a claramente podermos planear o âmbito do projecto necessário ao dito desenvolvimento do produto.
Mas temos de nos lembrar que um projecto para o PMI pode ter vários ciclos de "Iniciação, Planeamento, Execução, Controlo e Encerramento".
Qual o motivo de não vermos cada ciclo como um sprint, onde em cada um se define o "pedaço" do produto a desenvolver, os objectivos, etc.
O que nos impede de definir ciclos de 1 mês com a metodologia PMI? Basta escolhermos o âmbito que conseguimos produzir nesse período.
Bem agora podem dizer-me que o PMI é muito pesado para quem quer percorrer um ciclo em 1 mês.
Mas também não é o PMI que define que os processos e ferramentas da sua framework devem ser escolhidas, adaptadas ou descartadas consoante a dimensão e complexidade do projecto?
O importante para o PMI é que conhecemos estes processos e ferramentas, e se as descartamos é porque estamos a fazê-lo como opção, no fundo uma escolha consciente.
Na minha opinião, e não tenho dúvidas, PMI é ágil e tenho a certeza que no ágil estão todos os princípios PMI.
Convêm desassociar a gestão de projecto PMI com as metodologias de desenvolvimento em cascata.
O PMI assenta quer na cascata quer no iterativo
Exactamente porque há sempre alterações ao âmbito (mais preocupantes em projectos não Time & Material) é que se deve ter um controlo rigoroso deste ao longo do projecto, sendo que o produto final deve satisfazer as necessidades do cliente, mas também que nenhuma das partes se sinta prejudicada relativamente ao impacto que as alterações ao âmbito causaram no preço e custo.
Uma das questões que me coloco é, como reage o cliente às demos do final de cada sprint quando frequentemente não vê exactamente o que esperava (devido, por exemplo, à remoção de funcionalidades na sprint), o que vê tem problemas de execução (devido, por exemplo, à falta de tempo na realização de testes e correções), etc. Como sabemos, o desfraldar das expectativas do cliente pode ter consequências sérias no relacionamente cliente-fornecedor.
Por fim, não compreendo exactamente qual a necessidade da duração das sprint ter de ser religiosamente fixa. Será que se tiverem uma duração um pouco mais flexivel não trará mais beneficios para ambas as partes cliente-fornecedor?
Eu comparo a data fixa da conclusão de um sprint com um preço fixo para aquisição de um produto: se eu não o estabelecer, dificilmente o cumprirei! A metodologia é Ágil, mas não tanto!
Em relação à reacção do cliente nas demos, as suas vantagens são notórias: o cliente obtém imediatamente uma perspectiva da evolução do projecto, mas também para que se possa aperceber de que ainda vai a tempo de alterar algo que tenha sido mal entendido/transmitido.
As questões colocadas só me levam a uma conclusão: a metodologia PMI visa essencialmente a defesa de quem faz a gestão, em prejuízo do cliente. Não interessa o feedback do cliente nas demos de cada sprint? Será preferível realizar um projecto durante X meses e só no final mostrar ao cliente? Nem quero imaginar como seria a reacção de um cliente a uma "má demo" no final do projecto!
Concordo contigo Layne quando afirmas que o PMI visa essencialmente a defesa de quem faz a gestão, uma vez que a metodologia PMI serve a Gestão de Projecto. O PMI é uma framework que assenta em diversas indústrias, não só a TI. Quando escolhemos uma abordagem que permite mostrar demos ao cliente logo ao fim de um mês, escolhemos porque reconhecemos que as alterações de requisitos são constantes e porque nem sempre o cliente ou o analista conseguem convergir no que realmente é necessário. Mas isto é um problema da nossa indústria (TI), não um problema de gestão de projecto. Para o PMI, os requisitos têm de estar bem definidos, e o PMI não ensina como especificar requisitos, isso é outra área, tão grande que dá por nome de análise de requisitos.
Enviar um comentário