Edgard Davidson

Foque na conformidade com o produto e não na conformidade com processo.

Em desenvolvimento de software não existe mágica, não existe bala de prata, não existe nenhuma conformidade processual que garanta um produto conforme.  Existe, no entanto, um ambiente de descoberta, aprendizado e melhoria constante. Um ambiente formado por pessoas, que praticam socialização, externalização, combinação e internalização em um espiral contínuo de criação de conhecimento, em nível individual, do grupo, e organizacional.  Desenvolvimento de Software pode ser encarado como um jogo cooperativo infinito onde, além de suas atividades de engenharia, também deve ser encarado como uma atividade de ciências humanas, acima das questões técnicas e puramente lógicas. Existem pessoas envolvidas no processo; as que criam e as que usam o software.  A interação entre elas é um dos principais fatores críticos de sucesso para alcançar a conformidade com o produto.

Um dos princípios do manifesto ágil já afirma que “Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.” e um dos valores do manifesto completa que “Indivíduos e interação entre eles mais que processos e ferramentas“. Em desenvolvimento de software os esforços devem ser desprendidos para alcançar a conformidade com o produto e nem tanto para alcançar a conformidade com o processo. O processo é o meio para alcançar o produto e não o fim. Elimine qualquer coisa que não agregue valor ao produto e que não são percebidos pelo cliente. Elimine o desperdício, simplifique e aceite mais um princípio ágil: “simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.” Segundo o pensamento Lean, existem alguns desperdícios clássicos em desenvolvimento de software, a seguir:

• Trabalho parcialmente feito  (o “inventário” de um processo de desenvolvimento)
• Processos extras (fáceis de encontrar no desenvolvimento centrado em documentação)
• Funcionalidades extras (desenvolvem-se apenas o que os clientes querem agora)
• Troca de tarefas (todos devem fazer uma coisa de cada vez)
• Espera (para instruções, para mais informações, típico em ambiente comando-controle)
• Handoffs (toneladas de conhecimento tácito se perde)
• Defeitos (pelo menos defeitos que não são rapidamente capturados por um teste)

Manter a conformidade com processo de desenvolvimento formais, tradicionais, prescritivos e centrados em documentação implica em um problema que está muito além de afirmações de serem burocráticos, waterfall, rígidos, etc.  O principal problema é o auto custo de se manter esse tipo de processo. Processo formal é caro, manter a conformidade com o processo é caro, manter conformidade na documentação é caro, manter uma equipe de Quality Assurance é caro e fazer alterações de requisitos no meio do projeto é mais caro ainda.  Processo de desenvolvimento de software baseado em modelos de maturidade como CMMI e MPS-BR só podem ser considerados maduros se houver uma equipe de Quality Assurance atuante, autônoma e não condicionada. Sem Quality Assurance nesse tipo de abordagem grande parte dos esforços no desenvolvimento de um produto em conformidade com o processo é puro desperdício. O que se espera desse tipo de processo, como em qualquer processo, é um ciclo de melhoria contínua a fim eliminar paulatinamente qualquer fonte de desperdício, e por mais incrível que pareça, as referidas fontes de desperdício acabam sendo em atividades redundantes e, sobretudo, em atividades da própria equipe de Quality Assurance. Quando uma equipe formal chega nesse nível significa que ela está madura. Quanto mais madura a equipe, menos atividades de inspeção e verificação são necessárias para garantir a conformidade com o processo e mais esforços podem ser realocado para garantir a conformidade do produto.

Em métodos ágeis, a conformidade com o produto é uma premissa, talvez seja por isso que são chamados de ágeis, e podem ser  observados no próprio manifesto ágil e em seus doze princípios.  As referidas premissas também podem ser observadas nos princípios do pensamento Lean, nos valores e práticas do eXtreme Programming, no jogo cooperativo do Crystal e nas cerimônias do Scrum.

Independente da abordagem, o que importa é “satisfazer o cliente, através da entrega adiantada e contínua de software de valor“. No entanto, no caminho para alcançar esse objetivo, as empresas que desenvolvem software tem que lidar com clientes que lidam diariamente com o caos, e freqüentes mudanças operacionais. Esse ambiente em constante mutação gera novas oportunidades e novas demandas dos clientes. O processo tem que ser flexível, melhorado continuamente  para atender as essas “oportunidades”, focando sempre na satisfação do cliente e embarcando conhecimento em conformidade com o  produto.