BT

Desenvolvimento de software como gerenciamento de riscos?

por Christopher Goldsbury , traduzido por Rafael Buzon em 31 Out 2011 |

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?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT