Construindo softwares com eficiência econômica

Como lidar com a complexidade da construção de softwares

Muitas empresas tratam a construção de softwares através de processos determinísticos. Estes processos se baseiam em planejamentos prescritivos detalhados, papéis segmentados e apartados e documentação como representação da verdade. Exemplos  incluem cronogramas detalhados à exaustão com dezenas/centenas de tarefas dispostas em redes de Gantt, processos cascata e documentações completas como premissas para o início do trabalho de desenvolvedores. Os efeitos práticos de tais premissas são desastrosos. Quase 2/3 dos projetos tradicionais falham ou são entregues em atrasos, segundo pesquisas do Standish Group. Além disso, a produtividade destes processos é ruim, para não dizer pífia. Para os céticos ou curiosos, uma fundamentação estatística destes resultados é endereçada no excelente livro Applied Software Measurement, de Capers Jones.

Problemas Comuns, Complicados e Complexos

Um framework que busca lançar luz sobre classes de problemas é o Cinefyn, representado na figura abaixo.

Framework Cynefin

Framework Cynefin

Este framework mostra que existem problemas de diferentes naturezas, e que estas naturezas requerem abordagens de solução diferentes. Pare por um instante e pense como você classificaria os problemas de construção de software da sua empresa. Seriam eles simples (obvious)?

Provavelmente a sua resposta foi não para a pergunta acima, o que requer que a sua solução para construir softwares seja baseada em dois padrões:

  • Sentir/Analisar/Responder – Para problemas complicados
  • Experimentar/Sentir/Responder – Para problemas complexos

A indústria de TI tem buscado, desde os anos 90, lidar com a complexidade da construção de software com processos baseados nos padrões acima descritos. Estes processos são chamados de empíricos ou adaptativos. Os métodos lean/ágeis são exemplos de processos empíricos e tem se mostrado na prática muito mais apropriados para lidar com a construção de software, que não são problemas óbvios.

Efeitos Econômicos Práticos

Capers Jones, no livro supracitado, mostra que times que usam métodos ágeis entregam software com o dobro da eficiência de times tradicionais que usam métodos cascata. Isso acontece porque estes tipos de métodos buscam entender a natureza não-trivial da produção de software e atacar este problemas com as armas corretas (redução do escopo através de sprints, inspeção e adaptação , transparência radical, melhoria contínua, redução de tempo de ciclo, intensa colaboração entre pessoas e times auto-organizados).

E você, como tem tratado o desenvolvimento ou aquisição de software na sua empresa? Está feliz com os resultados alcançados?


1 comentário

» Implantação de Práticas Ágeis · 16 de abril de 2015 às 00:18

[…] muito complexo, mas os resultados compensam. Números da índustria mostram que times ágeis entregam o dobro de resultados de times […]

Deixe uma resposta

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