Conceitos financeiros para administrar a incerteza e os riscos resultantes para o valor de um ativo estão voltando a se firmar no desenvolvimento de software, como mostram vários posts e discussões na internet.
Alistair Cockburn recentemente questionou o conceito do “'Último Momento Responsável” no pensamento ágil. Ao fazer isso, iniciou uma discussão de como melhor lidar com riscos e incertezas no desenvolvimento de software.
Em post relacionado, foram reconhecidos Chris Matts, Olav Maassen e Karl Scotland por trazerem as opções reais (das finanças) ao debate entre as comunidades Agile e Lean. O assunto não é necessariamente novidade para o desenvolvimento de software, como mostraria uma rápida pesquisa na Amazon ou no Google. Mas o assunto pode estar ressurgindo como um caminho interessante no auxílio de ações para escalar as práticas ágeis (Matts e Maassen escreveram sobre isso em 2007 para o InfoQ norte-americano).
Com o interesse renovado das comunidades ágeis e lean pelo conceito de opções reais, devemos esperar a evolução nas técnicas de gestão de riscos no desenvolvimento de software? A história parece indicar que sim. Como sugere um post da "Project Management Association", a criação de técnicas ágeis foi principalmente uma reação para lidar com riscos em uma das áreas fundamentais do desenvolvimento de aplicações: os requisitos.
O risco em requisitos tem sido tema constante no desenvolvimento software e até mesmo este autor tem escrito alguns posts sobre o valor de reduzir riscos relacionados os requisitos, através da melhora de técnicas de elicitação.
Mas no centro de todas essas visões, está a premissa de que podemos tornar mais previsível o desenvolvimento de software e também menos sujeito a desperdícios. Será que realmente podemos?
Teóricos da metodologia Lean acreditam que sim. Jack Milunsky escreveu algums posts em 2009 sobre os 7 Desperdícios no Desenvolvimento de Software, fazendo um paralelo com os 7 desperdícios da Fabricação Lean. A visão de Milunsky é a de que essas áreas causam grande parte da variabilidade no desenvolvimento de software:
- Trabalho parcialmente completo
- Funcionalidades adicionais
- Reaprendizado
- Repasses (handoffs)
- Alternância entre tarefas
- Atrasos
- Bugs
Mas o desenvolvimento de software é também visto como um esforço artesanal ou criativo. Aqueles que defendem este ponto de vista geralmente rejeitam as comparações com a Fabricação Lean. Gary Police escreveu um artigo sobre arte e artesanato em software, em que defende que a excelência no trabalho (de software ou não) vem de experimentação, erros e a motivação por fazer o melhor. Esta visão pareceria indicar que desperdícios são inerentes à criatividade e, por extensão, ao desenvolvimento de software.
Qual sua opinião? Podemos aumentar a previsibilidade no desenvolvimento de software ou, ao fazer isso, estaríamos destruindo o aspecto de criatividade que faz o desenvolvimento ser tão valioso?