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?

Avalie esse artigo

Relevância
Estilo/Redação

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
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.