Fiz um treinamento de XP com o Vinícius Teles e ele relatou decidiu só trabalhar com escopo aberto, prazo flexível, técnicas ágeis e Ruby On Rails. Se o cliente não quisesse alguma dessas coisas, “poderia procurar outro fornecedor”, em outras palavras. Não acho que ele seja tão rigoroso assim, mas deu para ver a posição da empresa dele. Isso é bom. Mas é preciso um mercado maduro para aceitar tais coisas. Empresas mais tradicionais vão querer impor, e não aceitar. Ficamos limitados.

No caso a empresa dele é no Rio, eu vivo em Fortaleza. Já são realidades diferentes. Em SP nem se fala. Mas em geral, na medida que o mercado amadurece é que essas questões surgem com mais força. É preciso um patrocinador. Mas nada que impede que a comunidade catalize o amadurecimento. Creio que esse seja a idéia.

* Engraçado que acabamos discutindo modelos tradicionais x ágeis, e não iterações x cascata. É a aplicação da discussão na nossa realidade. Mas é estranho no mínimo, pois iterações já deveriam ser padrão (em ambos os casos) há décadas. A gente vai levando…

Abraços.

Você leu certo mesmo: estou falando de um comentário de um cliente, não de meus colegas choramingando contra o processo em cascata da empresa.

A equipe estava apresentando os casos de uso revisados após alterações solicitadas pelo cliente, como exigido pela polícia do processo interna, e a observação dele foi que sempre que lhe mostravam documentos daquele tipo ali ele só podia imaginar que as coisas iam funcionar como esperado e que confiava na equipe de desenvolvimento para fazer a coisa certa, mas que só tinha certeza realmente que tudo funcionaria durante a homologação final. O detalhe é que, devido às várias representações intermediárias exigidas e ao escopo nada enxuto das iterações nesta empresa em particular, a tal “homologação” só seria dali a dois meses. Ou seja, o cliente iria demorar pelo menos dois meses para saber se a equipe estava no rumo certo.

Claro que isto é só evidência pontual, uma história dentre milhares que podem ser contadas. Estatisticamente irrelevante, certo? Pode ser que este seja o único cliente do mundo que prefere ver software funcionando do que documentos. Mas eu desconfio que não.

Se você me permite, arrisco dizer que o problema não é conosco. É com o cliente. Cada vez mais vejo que o cliente de software tem muito o que aprender ainda para que a vida de ambos (fornecedor e consumidor) seja melhor. Eles é que são os conservadores, não nós. Para a maioria dos desenvolvedores trabalhar com desenvolvimento ágil, escopo aberto, prazos e esforço negociável e flutuante é o paraíso. Mas tente empurrar isso em empresas grandes e mais antigas, principalmente as que não são da área de T.I. É bater com a cabeça no muro.

Por isso ficamos no modelo cascata. O cliente quer garantia de entrega, quer o escopo todo implementando, quer prazos fechados.
Como iniciar a desenvolver algo antes da análise estar concluída se o cliente pode mudar de idéia e podemos ter jogado dinheiro (tempo) fora? Como mostrar algo antes do tempo para o cliente para que ele acabe mudando de idéia e solicite uma mudança sem entender que mudar algo nessa altura significa maior custo e maior prazo? Quem vai arcar com o prejuízo?

É vendo essa realidade, e principalmente aplicando modelos como o CMMi, que vemos na prática como é difícil desenvolver em iterações corretamente. Acabamos preferindo a segurança da burocracia, mesmo sabendo que em termos de produtividade e qualidade não é a melhor opção. Mas isso é algo que precisamos discutir e mudar.

Abraços.

Hoje estou em um projeto absolutamente em cascata, e já bati muito nesta tecla com a equipe para diminuirmos -termos- iterações, pois nem isso temos, ou seja, o cliente somente receberá o software depois de um ano aproximadamente.

Devido a problemas com licitação e prazos ficou resolvido que haveria uma iteração intermediária, algo próximo de 6 meses, mas isso somente porque fomos (empresa) obrigados. Ainda assim, como você mesmo disse, uma iteração de 6 meses é muito, mas muito tempo.

Desenvolvimento de software não é uma tarefa simples, ainda mais com uma equipe e principalmente uma gerência que acredita piamente em um modelo em cascata.

Abraços e parabéns pelo post!

Atitudes como esta sua, elucidar o povo da nossa área, que o 1up4dev busca também.

[]s