Alow Brasil !!!

Voltando a postar minhas idéias por aqui Uma das coisas que estavam na fila é abordar um pouco as diferenças entre um projeto com entregas de escopo ”programado”  e um projeto com entregas incrementais de software.

Acho que nos últimos meses, tivemos algumas situações bem interessantes que baseiam uma boa análise sobre este assunto. Vamos lá então.

Primeiro, é preciso conceituar os dois modelos: Entrega Cascata e Entrega Incremental.

Entrega Cascata:

Parte do principio que o projeto é dividido em fases estensas com cada uma focada numa área de conhecimento da engenharia de software. Em geral, os modelos mais comum parecem com isso:

Modelo waterfall padrão

Neste modelo, as fases do projeto são divididas e as entregas são feitas ao final de cada fase, separando-se os entregáveis geralmente em:

• Documentação funcional;
• Documentação técnica;
• Código fonte / programas;
• Plano e casos de testes;
• Evidência de testes;
• Documentação gerencial (cronogramas, WBSs, etc).

Pode-se também adotar uma estratégia de quebrar a fase de desenvolvimento em vários releases ou entregas parciais, que podem ou não ser focadas em módulos funcionais do sistema.

Este modelo apresenta alguns princípios básicos que o norteiam do início ao fim:

• O escopo é definido e desenhado no início do projeto e “não muda”. Além disso, o tempo e custo do projeto também são definidos desde o principio, baseado num processo de métrica como APF, UCP, ou outro qualquer;
• Antes da codificação, é altamente necessário que os modelos técnicos sejam fechados e provados, por meio de especificações técnicas;
• A codificação é feita sobre as especificações técnicas e funcionais escritas nas fases anteriores do projeto;
• Mudanças são tratadas como “change-requests” durante o projeto.
• O software é entregue somente após a fase de desenvolvimento, mesmo que haja modularização na etapa de desenvolvimento, o chamado “teste de integração” sempre será feito no final;

Existem outras características que até são importantes, mas não vou abordar agora, ok? Acho que essas já definem bem o modelo.

Entrega Incremental

Parte do princípio que o projeto é desenvolvido contando-se com o aprendizado funcional e técnico do cliente e das pessoas envolvidas. Possui tempo x custo fechados, mas aceita e encoraja melhorias e alterações no escopo para entregar um produto melhor ao final do projeto.

Em geral, um modelo incremental é bem parecido com isso:

Modelo padrão incremental

O projeto todo é dividido em releases e a cada entrega os envolvidos têm a chance de avaliar e dar feedback para que haja melhoria no proximo release. As disciplinas de engenharia de software são absorvidas dentro da construção de cada release, não estando em fases separadas.

Uma caracteristica muito importante neste modelo é que um time é obrigatoriamente composto por profissionais multidisciplinares, pois o trabalho é multidisciplinar.

Os princípios básicos que o norteiam este modelo são:

• Entregas incrementais de software funcionando e não somente ao final do projeto;
• Times muldisciplinares dedicados ao mesmo projeto do início ao fim;
• Feedback do cliente e usuários do sistema, vendo partes funcionais entregues a cada ciclo pequeno;
• Possibilidade de mudanças no escopo de acordo com o aprendizado obtido nas entregas;
• Alto nível de visibilidade de riscos no projeto, uma vez que eles precisam ser mitigados rapidamente para que uma entrega de software seja realizada;
• Mais foco na comunicação e menos nos documentos, uma vez que não é preciso documentar as necessidades do cliente detalhadamente, pois elas são rapidamente desenvolvidas pelo time e apresentadas ao cliente.

Também existem outras características importantes neste modelo, mas que não precisam ser ditas agora.

Bom, uma vez que conceituamos os dois mundos, vamos analisar no que isso impacta quando falamos num projeto de software:

Geralmente, tanto o cliente quanto a equipe de desenvolvimento estão acostumados a receber/entregar código-fonte e/ou programas funcionando somente no final do projeto. Isso traz uma falsa percepção de andamento, fornecida pelo famoso “%” de conclusão das tarefas.

A verdade é que enquanto não existe software funcionando, não dá pra dizer que algo no projeto andou de fato. Isso é um dos motivos para afimarmos que uma estratégia de “GANT” não serve para projetos de software.

Pois bem, as pessoas estão acostumadas a terem um projeto rodando muito bem do começo até a hora do “QA” ou ciclo de testes ao final da etapa de desenvolvimento. Com isso, o stress do projeto fica sempre para o final e a capacidade de se tomar decições corretivas ou de estabilização fica totalmente comprometida. Afinal, ficamos com pouco tempo hábil para corrigir os problemas de um projeto inteiro na hora do teste, certo?

Por outro lado, quando trabalhamos com desenvolvimento incremental, o stress que aconteceria no final do projeto vem para o começo. Isso é bom sob a ótica de gestão do projeto, pois temos uma tendência de melhorar a cada iteração.

MAS, nem tudo são flores. O grande problema, é que em geral o cliente não está preparado para ter stress logo no início de um projeto. Ele acaba achando que se as coisas estão ruins no começo, a tendência será sempre de piora e não de melhora.

Isso faz com que o nível de stress e desconfiança fique insuportável e em muitos casos com que a estratégia de entrega incremental fique inviável tanto para o cliente quanto para o time, pois as pessoas do time também não conseguem desenvolver um trabalho com o stress, pressão e desconfiança do cliente a todo instante.

Certa vez, ouvimos de um cliente:

“Nossa, mas vocês estão sendo transparentes demais com os problemas do projeto. Isso está errado, nós não queremos saber dos problemas de vocês. Contratamos um projeto e ele deve ser entregue, independente dos problemas…”

O fator de falha aqui está na cultura da contratação e na relação cliente x fornecedor. Se o cliente sabe do problema, automaticamente se torna responsável pela solução e ninguém quer ter problemas para resolver, mesmo que um dia eles venham puxa-lo pro buraco.

Em resumo, em alguns casos vemos que a “ilusão” de um projeto andando bem e que a falsa percepção de evolução é mais importante para o cliente do que ver software funcionando ou saber dos problemas para trata-los. Afinal, enquanto os problemas estão debaixo do tapete, fica muito mais fácil de não se comprometer e ao final jogar a culpa do fracasso no time de projeto.

Num caso como esse, deve-se repensar se realmente uma estratégia de entrega incremental agrega ao projeto. Em alguns casos, vamos ver que a única saída será o “bom e velho” Waterfall…

E você, o que pensa a respeito? Qual o melhor modelo de entregas na sua opinião?

Grande abraço !!!

André Nascimento