menu

Medida primária de progresso em software – Case pessoal

Por

Existe a questão do PRONTO como medida de progresso efetivo. E o problema do falso “pronto” eu vivenciei bem na industria de software.

Gerenciei vários projetos de software no modelo cascata, onde a maioria da equipe era junior, incluindo eu. E, apesar da boa vontade, a % concluída nunca é real ou tem algum significado confiável. Ter 80% do projeto concluído, imaginando que isso represente toda a fase de desenvolvimento, não significa que os 20% restante (testes e ajustes) irão gastar somente 20% do tempo. E isso pode acontecer por vários motivos, mas principalmente pela quantidade de débito técnico deixado no meio do caminho, pela “junioridade” dos recursos, pelo não entendimento de algum requisito e terem construído “como entenderam”, etc.. (não culpo o modelo cascata somente).

Tentamos sempre melhorar em cada novo projeto, e uma abordagem interessante foi a criação de iterações com a presença e validação do cliente em cada uma. Algo mais próximo das práticas ágeis. Mas ainda assim havia muito estress nas entregas (devido à bugs), questões que eram postergadas por terem achado problemas próximo da apresentação ao cliente (o tempo é sempre curto), dentre outras questões, mas que, no geral, já era um bom avanço para a equipe.

Entretanto ainda apresentávamos o sistema em nossas máquinas de homologação e, apesar do cliente já conhecer seu produto e aprender com ele nas iterações, ainda tínhamos questões técnicas, de deploy em produção por exemplo, que impediam dizer que estava realmente pronto. E, como não tínhamos, em alguns casos, tempo nem recursos para realizar testes em produção paralelos ao desenvolvimento, sempre encontrávamos surpresas nesta etapa que levava a data efetiva de conclusão para mais longe. E quando todos respiravam aliviados, lembrávamos que os manuais precisavam ser revisados para contemplar as mudanças feitas. : (

É por isso que práticas como as da XP pregam que a medida primária é ter o SOFTWARE FUNCIONANDO NO CLIENTE, EM PRODUÇÃO, DE FORMA INCREMENTAL, pois se antecipa os aprendizados e evita-se procrastinar atividades essenciais à entrega.

Está ou não está pronto?
http://blog.kudoos.com.br/gestao-agil/esta-pronto-ou-nao-esta-dilema-de-projetos-de-software/

 

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top