Smarana

Discussões sobre Memória Organizacional em ambientes de desenvolvimento de Software

Projeto de vários ciclos – a grande mentira

Sejamos francos. Vejo muita gente certificada falar em projetos de vários ciclos – o que para mim é uma grande asneira, uma mentira deslavada ou simplesmente repetição do que se ouve por aí. A própria definição de projeto diz claramente que ele se apoia em uma tríade custo/prazo/escopo. Sem ela, não se sustenta uma definição clara de projeto para uma determinada “coisa” que se analisa.

Isso me remete (lá ele) a uma confusão na área de Gerenciamento de Projetos de desenvolvimento de software com a qual nunca me conformei. O ciclo iterativo NÃO pode ser caracterizado como projeto por ser deficiente no estabelecimento da tríade balizadora do conceito de projeto. E isso representa uma corrupção do próprio conceito de ciclo de vida na engenharia de sofware. Recapitulando o que aprendemos na faculdade, vemos que o foco do cascata (com ou sem sobreposição) poderia guardar uma semelhança entre o ciclo de vida do produto e o do projeto, pois ele está bem definido e apresenta retorno ao ao princípio quando do seu final (e nas outras atividades, vale a pena alertar). Pois bem, quando um projeto acaba, pode-se iniciar outro, agregando mudanças ao produto vigente. Mas é isso que significa o retorno?

ciclo de vida em cascata

Foco no projeto

Observando mais atentamente o gráfico, percebemos que as flechas de retorno podem acontecer a qualquer momento por uma necessidade de rever atividades já realizadas para corrigir algo ou modificar de acordo com novos acordos – inclusive durante a validação. Isso demove, para fim de clareza, a propriedade do ciclo como definição de produto. Se, por outro lado, o autor expressamente fala em ciclo de produto, o retorno em outras fases que não a validação indicaria uma revisão do próprio projeto, descartando (pelo mesmo fim de clareza) a revisão por motivos não negociais.

Entretanto, vou deixar essa discussão para focar em algo mais interessante e contundente: o ciclo de vida iterativo. A maioria dos processos tradicionais derivam da definição de ciclo de vida iterativo consolidado pela Espiral de Boehm, que embora descreva detalhadamente um projeto, deixa claro o entendimento que a continuidade da espiral indica o encadeamento de projetos no desenvolvimento de um PRODUTO, com visibilidade de elementos agregados, como custo e compromisso. Inclusive, nos materiais que consultei (livros e artigos), a associação do ciclo a projetos é evento raríssimo, havendo mais referências ao estabelecimento da relação entre a espiral e o desenvolvimento de produto. Pois bem, a espiral assume que jamais um software estará pronto quando entregue, pois há mudanças de cenário que exigirão modificações – essa é a natureza do ciclo iterativo e, acredito eu, a realidade do desenvolvimento de soluções.

Espiral de Boehm

Foco no projeto, mas com fácil visão global de produto.

Uma vez certo da incompletude da solução, parece-me senso comum a divisão do trabalho (não do projeto) em pacotes menores, para que as modificações não tornem o trabalho infinito e a frustração da não-entrega atormente desenvolvedores e clientes. Inclusive, essa recomendação é amplamente divulgada no PMBoK (alvo de severas críticas por não ser ágil). Se o trabalho tende ao infinito (rs), é óbvio que ficam prejudicadas quaisquer estimativas de escopo/prazo/custo, derrubando a ideia do “projetão”, vigente (infelizmente) em todos os lugares por que passei. Seria mais adequado, portanto, considerar um único pacote como projeto, pois a seleção do escopo pode ser feita, a um custo e prazo (curtos) definidos de maneira mais justa, gerando entregas constantes e, inclusive, podendo garantir um fluxo de caixa saudável para a entidade desenvolvedora.

Ainda que exista uma precedência de objetivos para cada pacote e que haja um objetivo maior, o produto não se configura como projeto, como criticado anteriormente, mas como programa, pela definição do PMBoK. Ora, o programa não é simplesmente um agregado desconexo de projetos, deve conter um elo lógico – no caso, objetivo – que promova sua coesão. Sendo assim, o produto de software é um programa sob a ótica do gerenciamento de projetos. Tratar como tal garantirá estimativas mais acertadas, em vez dos “chutes” atualmente feitos na certeza que passarão muito distantes da realidade.

Não me pergunte a razão das coisas serem como são hoje… ainda não descobri. Algumas possibilidades são:

  1. “Sempre vi fazerem assim, então faço assim” ou “Me ensinaram assim”. Em suma, a falta de senso crítico e de busca pelo conhecimento hoje dominante;
  2. “Dá trabalho fazer vários projetos”. Já tentou fazer diferente? Certamente o trabalho, mesmo num processo tradicional, será dividido. Com a divisão do escopo, porém, haverá menos variáveis em jogo, facilitando a gestão do projeto. Além disso, a proposta não é fazer vários projetos em paralelo, mas cadenciados, garantindo entregas constantes, e
  3. “Os requisitos do projeto são um todo”. Se você leu a crítica acima, resta clara nessa desculpa a confusão entre projeto e produto.
Mais alguma alternativa? Alguém se arrisca a escolher uma razão?
Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado em quarta-feira, junho 22, 2011 por em Gerenciamento de Projetos, Processos e Metodologias.

O Autor

Twitter

Goodreads

Oath of non-allegiance

Oath of non-allegiance

Oath of non-allegiance

%d blogueiros gostam disto: