Desdobrando o Manifesto Ágil: O funcionamento do software acima de documentação abrangente (versão Alpha)

O manifesto contém quatro princípios fundamentais que valorizam:

• Os indivíduos e suas interações acima de procedimentos e ferramentas;

• O funcionamento do software acima de documentação abrangente;

• A colaboração dos clientes acima da negociação de contratos;

• A capacidade de resposta à mudanças acima de um plano pré-estabelecido

Este texto esta em versão Alpha e é o segundo de uma série de 4 posts fundamentando e mostrando os alicerces do manifesto Ágil.

O funcionamento do software

acima de documentação abrangente

Para explicar esta citação, volto aos princípios do "Lean Thinking", onde se encaixa muito bem aqui a “Cadeia de Valor”, a formação da estrutura do valor está vinculada à percepção do cliente ao produto/serviço e atender às suas necessidades exatamente com o que eles desejam.

“MUDA é uma palavra japonesa que você não pode deixar de conhecer. Soa estranho, pois muda significa “desperdício”, especificamente, qualquer atividade humana que absorve recursos, mas não cria valor: erros que exigem retificação, produção de artefatos que ninguém deseja, e acúmulo de artefatos em espéra, etapas de processamento que, na verdade, não são necessárias, ..., grupos de pessoas em uma atividade posterior, que ficam esperando porque uma atividade anterior não foi realizada dentro do prazo, e bens e serviços que não atendem às necessidades do cliente.” (Womack et al.1998, p. 3)

Um dos fundamento do Pensamento Enxuto é a eliminação de desperdício, redução de estágios do processo (alguns cargos “como analista” ou processos não deveriam nem existir) e a delegação e transferência do máximo de tarefas e responsabilidades, tanto da gerência quanto da mão-de-obra indireta – manutenção, preparação ferramental, qualidade, etc...; para os trabalhadores que realmente agregam valor ao produto ou serviço.

A maioria dos artefatos/documentação sugeridas pela Engenharia de Software tradicional não tem valor algum para o cliente. Muitos dos artefatos/documentação são produzidos simplesmente para transcrever o que um mau programador deve codificar, sendo que o código é o que realmente agrega valor ao cliente.

Segundo Womack et al. (1998), da mesma forma que “as atividades que não podem ser medidas não podem ser adequadamente gerenciadas”, as atividades usadas para criar um bem ou serviço que não possam ser precisamente identificadas, analisadas e associadas, igualmente, não poderiam ser questionadas, melhoradas ou até eliminadas. Daí a importância de se gerenciar as cadeias de valor específicas para bens ou serviços específicos, pois conforme o autor as atividades que compõem estas cadeias podem ser divididas nas seguintes categorias:

• aquelas que realmente criam valor, o qual é percebido pelo cliente;

• aquelas que não criam valor, no entanto são necessárias para os sistemas de desenvolvimento ou produção de um produto ou serviço;

• aquelas que não criam valor para o cliente, as quais podem e devem ser imediatamente eliminadas.

Para Porter et al. (1999), o conceito de “cadeia de valor” identifica as várias atividades que a empresa desempenha para executar o seu negócio. Estas atividades, diferenciadas do ponto de vista tecnológico e econômico, são chamadas de “atividades de valor” e vão gerar o valor, que é mensurado através do preço que os compradores estão dispostos a pagar pelo produto ou serviço. “O negócio é rentável quando o valor que cria é superior ao custo do desempenho das atividades de valor”. Logo, as atividades e o custo de gerar qualquer tipo de documentação devem ser avaliadas pelo desejo do cliente.

Vale aqui citar alguns avanços da tecnologia, ferramentas e técnicas que são usados nas metodologias Ágeis e reduzem enormemente a necessidade de uma documentação abrangente. BDD, TDD, DDD, ubiquitous language são ótimos exemplos destes avanços. Dentre outras avanços, temos também outra vertente; geração de documentação a partir do código. Estas tecnologias trazem uma enorme vantagem competitiva pois este tipo de documentação tem custo zero e nunca fica desatualizada.

O fracasso da engenharia de software tradicional.

O conceito de Engenharia de Software surgiu inicialmente em uma conferência organizada para discutir o que foi então chamada de crise de software. Este post tem como objetivo mostrar o fracasso da engenharia de sofware tradicional mostrando que pouco mudou desde então. O Standish Group, publicou uma série de relatórios de caos descrevendo embaraçosamente os projetos de TI e suas baixas taxas de sucesso, começando com uma péssima taxa de 16 por cento em 1994 e uma melhoria para ridículos 34 por cento em 2006 . Outras pesquisas mostram que nossa Engenharia de Software não mudou muito a crise de software.

As estatísticas da Scientific American [filho, 2000] mostram que o tempo realizado dos projetos de software excede em 50% o tempo planejado no cronograma do projeto.

O standish Groups relatou em 1994 [Standish, 1994] que apenas 16% dos projetos de software atingem o seu objetivo dentro do cronograma e do orçamento previstos.

Os dados de 2001 do Standish Groups [Standish, 2001] mostram as seguintes estatísticas: 27% dos projetos de software são finalizados no tempo e custos previstos; 40% dos projetos são cancelados antes de finalizarem; 50% dos projetos custam em média 108% a mais da estimativa original; em 2006 a Standish O CHAOS Report [Standish, 2006] apresentou os seguintes dados: apenas 34% dos projetos são bem sucedidos.

Cabe salientar que ocorreu uma pequena melhoria nas estatísticas de projetos que terminam dentro do prazo (cronograma) e orçamento previstos do Standish Group de 1994 (16%) , 2001 (27%) e 2006 (34%). Entretando, a melhoria ainda se mostra frustrante e seus índices um tanto embaraçador.

Note que se um projeto é subestimado, mesmo utilizando-se os melhores métodos para a elicitação de requisitos, design, implementação e testes, o projeto corre um alto risco (40%) de ser cancelado.

O principal risco que afeta os projetos de software subestimados é o de pressão excessiva do cronograma, o qual pode forçar o término prematuro do projeto, colocando em risco a qualidade e a funcionalidade do projeto [Jones, 1994]. Entre as possíveis conseqüências desse risco temos: cancelamento do projeto, baixa moral da equipe, baixa qualidade, atrasos de cronograma, custos excessivos devido a um grande número de horas extras e atritos entre o gerente e a equipe [Hazan, 1999].

Nas pesquisas aqui explanadas, não são contempladas os projetos que não obtiveram êxito no processo de licitação ou as propostas que não foram aceitas por algum contratante devido a sua estimativa superestimada em seu orçamento.



Outra pesquisa muito conhecida no mundo ágil é de utilização das funcionalidades de um software. Esta estatística demonstra que 64% da funcionalidades de um software típico raramente ou nunca são usadas, salientando para um grade desperdício de código desenvolvido.

Estas pesquisas demonstram que, nossa área de Desenvolvimento de Software, não somente não fazemos software direito mas também fazemos as coisas erradas.

A solução para tudo isto fica para os próximos posts...