A evidência definitiva da programação saudável

Como alguém pode saber que uma equipe de programadores desenvolve software com um processo saudável? Como podemos saber se as práticas adotadas pela equipe são suficientes para produzir software útil, correto e de fácil manutenção? Quais as evidências que devemos procurar para separar os bons projetos dos ruins?

Estas são questões fundamentais tanto para quem está procurando um fornecedor como para quem está projetando um novo selo ou certificado parecido com os milhares que já temos para identificar organizações que sabem desenvolver software. Quem se propõe a fornecer um selo desse tipo precisa observar o trabalho dos candidatos por algum tempo para tentar encontrar algumas evidências de um processo saudável e sustentável. Precisa procurar pelos rastros deixados por um trabalho bem feito.

Uma forma razoável de identificar estes rastros é projetar um processo de desenvolvimento que comprovadamente dá certo (pelo menos para alguns casos) e verificar o que uma equipe que usou este processo deixou pelo caminho. Alguns selos em uso atualmente fazem exatamente isso: eles certificam toda uma classe de processos que produzem os mesmos subprodutos que um processo original. As equipes que querem ser certificadas precisam aprender o modo de operação e repetí-lo, produzindo evidências concretas de que seguiram um processo aprovado pelo certificador. Documentos de requisitos, relações de casos de uso, matrizes de rastreabilidade, diagramas de relacionamento e relatórios de revisão são todos exemplos de evidências bastante tangíveis da existência de procedimentos definidos.

Porém nenhum desses documentos pode ser considerado uma evidência definitiva da qualidade do processo. Nenhum deles consegue provar sozinho que o processo de desenvolvimento funciona.

Nem mesmo todos eles juntos conseguem fazer isso.

A evidência definitiva de um processo de desenvolvimento de software saudável é bastante óbvia, mas isso não quer dizer que todo mundo consegue enxergá-la. O único produto suficiente e necessário para identificar que um processo realmente dá certo é simplesmente software funcionando.

Só isso.

Não são documentos de requisitos bem escritos, matrizes de rastreabilidade gigantescas, nem diagramas bonitos e coloridos. A maior evidência que se pode observar em projetos saudáveis é a simples entrega de software funcionando. Deve ser suficiente observar que uma equipe consegue entregar software funcionando a cada, digamos, uma ou duas semanas para saber que eles têm uma boa abordagem para desenvolvimento de software. Uma queda da velocidade de evolução do sistema é o que basta para saber que algo vai errado.

Nem todos os processos de desenvolvimento são projetados para entregar software funcionando dentro de períodos curtos de tempo. Por isso desenvolveram-se vários modelos que verificam subprodutos intermediários como diagramas de estado e especificações funcionais. É um caso clássico de quem não tem cão, caça com gato. Estes subprodutos servem como promessas, garantias, evidências de que em algum momento futuro o sistema será entregue como esperado. O problema é que nenhum subproduto desses é tão verificável quanto o produto final. Eles servem para tranqüilizar um pouco os clientes, que de um modo ou de outro recebem algumas garantias de que seu dinheiro está sendo bem gasto. Mas definitivamente não servem para dar certeza do sucesso do projeto, nem ao menos da transformação do produto em software funcionando.

1 Response to “A evidência definitiva da programação saudável”


  1. 1 João Paulo Lins 11/abr/2008 às 02\0259

    Software funcionando é uma boa evidência.

    “Uma queda da velocidade de evolução do sistema é o que basta para saber que algo vai errado.”

    Talvez isso não signifique que o software deixou de funcionar ou ser saudável, mas levanta uma pergunta:

    Como se manter saudável?

    Eu acho que essa pergunta fica ai nas entre linhas.

    Toda vez que eu tento responder ela acaba mostrando que para se manter saudável e ter software funcionando é preciso ter um PROCESSO ainda que este seja o mais informal ou abstrato possível e não tenha os sub-produtos que você falou acima, tenha como resultado final o produto: Software funcionando!

    O problema dos processos são as pessoas!
    Principalmente as que estão pagando para que o software saudável esteja sendo entregue continuamente, essas pessoas sempre podem estar colocando uma pedra no caminho (ainda que inconscientemente) e poderão está afetando o processo saudável.


Comments are currently closed.




%d blogueiros gostam disto: