terça-feira, maio 18, 2010

Pecado: O culpado da persistência do modelo Waterfall no desenvolvimento de Software?

Quer entender melhor por que o manifesto Ágil fala em valorizar mais a colaboração com os clientes que a negociação de contratos? Um novo livro de um autor clássico dentro de nossa área de Engenharia de Software pode nos ajudar.

Estou lendo o novo e fantástico livro novo do Frederick Brooks, de título The Design of Design. Para aqueles da nossa área que ainda não o conhecem, Brooks é o autor do clássico livro de engenharia de software The Mythical Man-Month (que considero leitura obrigatória para executivos da área de TI).

Os primeiros capítulos do novo livro de Brooks são os mais interessantes, pois evidenciam claramente os problemas de se tentar realizar o design e construção de um produto seguindo um modelo cascata ( Waterfall ).

O capítulo 3 se chama "What's wrong with this model?" e é focado em explicar porque, nas palavras de Brooks: "o modelo cascata é errado e perigoso; precisamos superá-lo". Ele inclusive mostra como o próprio Winston Royce (suposto inventor do modelo cascata) critica fortemente o modelo cascata no mesmo artigo em que o descreve (Royce apenas o usou como uma referência do que NÃO funciona).

O resultado de um processo de produto Waterfall (onde os requisitos são completamente definidos antes do design e implementação começarem) é um conjunto de requisitos enorme e gigantesco, a união de muitas listas de desejos, levantada sem nenhum tipo de restrição. E, para piorar, a lista não é priorizada ou medida em termos de custo versus benefício. As forças sociais envolvidas acabam proibindo o conflitos dolorosos ocasionais gerados pela priorização.

Nas palavras de Brooks: "a proliferação de requisitos deve ser combatida, através de controle de natalidade e infanticídio destes requisitos". Ele inclusive dá um excelente exemplo de uma pesquisa realizada por um comitê nacional americano em projetos militares dos EUA: "Os projetos extremamente bem sucedidos tem um ou muito poucos objetivos e urgência de cronograma. Esses projetos começam com poucos requisitos de alto nível. Enquanto o desenvolvimento procedia, estes eram quebrados em requisitos mais específicos. Estes requisitos eram controlados e priorizados fortemente por gerentes capazes que continuamente balanceavam funcionalidade em relação a custo e prazo".

Aí vem a grande pergunta de Brooks no capítulo 4, de título "Requirements, Sin and Contracts": como podemos explicar a persistência de um modelo perigoso como o Cascata, quando já sabemos através de evidências maciças levantadas durante quase um quarto de século de que o modelo espiral/iterativo produz melhores resultados?

Antes da resposta, vamos supor o seguinte:
- O cliente ficará feliz em pagar para o seu fornecedor um preço justo pela sua experiência e trabalho.
- Ele conseguiu um fornecedor que age e usa suas habilidades para servir aos interesses reais dos clientes. Este fornecedor também realiza seu trabalho sempre almejando construir produtos com alta qualidade na melhor proporção de custo-benefício, dentro do prazo e orçamento.
- Todos são honestos, verdadeiros e a comunicação entre eles é excelente.

Tendo isso em vista, Brooks nos mostra que:
- Um contrato que pague o custo do fornecedor mais um bônus por metas irá dar ao cliente e ao fornecedor o melhor valor por dólar investido.
- Um modelo de processo espiral e iterativo vai gerar o produto mais apropriado para as necessidades principais do cliente.

Como podemos então explicar a existência de tantos projetos ainda seguindo um processo cascata? A resposta: Pecados... Especialmente Orgulho, Ganância e Preguiça.

Muitos olham as suposições acima e falam: "Essas suposições nunca ocorrem! Os humanos são pecadores e não podemos confiar na motivação do outro. Como os humanos são pecadores, não podemos nos comunicar perfeitamente". Por essa razão que entram contratos escritos. Precisamos de contratos para a proteção de faltas dos outros e para evitar nossa própria tentação de cometer transgressões.

E então, chegamos no ponto de Brooks: "Claramente, é a necessidade por contratos dentro de uma mesma organização ou entre organizações que força a descrição muito precoce de objetivos, requisitos e restrições detalhados". Portanto, segundo Brooks (e concordo com ele!), a necessidade por contratos detalhados melhor explica a persistência de um modelo errado como o cascata para projetar e construir sistemas complexos.

Quer saber mais sobre soluções interessantes para contratos de desenvolvimento de sistemas (ou implantação de ERPs e outros sistemas prontos que necessitam de customização) ? Vide meu artigo e apresentação sobre contratos com o título Contratos e Scrum: The Good, The Bad and the Ugly e também a palestra em vídeo que ministrei sobre contratos no Falando em Agile .

1 Comentários:

At 3:38 PM, Blogger ZED disse...

Quando falo para o cliente que ele tem que participar do processo de desenvolvimento e não apenas esperar a entrega ou, quando falo que ele me paga por hora ou por módulo, ele sai correndo.

Geralmente ele me descarta e contrata o primeiro cara que diz que vai entregar no prazo que ele quer e as vezes até por um preço bem maior.

Lembrando que a especificação do cliente é resumida em uma frase: "Eu quero o sistema igual o daquela loja ali."
E muitas vezes por uma rápida análise, acabo percebendo que ele precisa de partes do sistema e não te todo ele, ai quando argumento isto ele já me descarta também.


Em resumo, o cliente quer algo que resolva o problema dele que descubra pra ele o que ele realmente quer.
Prefere algo pronto, que não precise pensar e nem saber oq faz.


Por isso que qualquer um que entregue qualquer coisa perto do prazo, consegue fechar contrato.

Falo pelas minhas experiências, gostaria de conversar com pessoas que seguem metodologias Ágeis , saber qual tipo de perfil de cliente se encaixa nisso tudo.
Pois só encontro cliente que acha que programador é pai de santo, vidente etc.

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas