Experimente um projeto ágil

Em 2007 deixe um projeto ágil mudar seus resultados. Se você conseguir se livrar dos racismos sem fundamentos técnicos e permitir a revisão de seus próprios paradigmas, verificará na prática uma nova realidade de satisfação de clientes de projetos de software.

por Fabio Camara

Introdução

Por mais que a engenharia de software seja uma “ciência” muito nova, está muito perigoso o caminho que os negócios estão impondo para os projetos de software. Perigoso porque é antagônico: de um lado compradores vão ao mercado e perguntam qual fornecedor faz mais barato, e do outro as metodologias estão preocupadas com a “cientificidade” da engenharia e apresentam mais e mais métodos, bem como técnicas que encarecem o processo de construção e controle.

Eu entendo o quanto é difícil para nós, técnicos, aceitarmos a teoria que os projetos de software hoje estão sendo comprados como se fossem commodities. Contudo, por mais quanto tempo vamos fechar nossos olhos para esta realidade?

As propostas de qualidade, as exigências de padrões como CMMI, as ofertas de controle mais adequados com técnicas do PMBok, podem até fazer parte das solicitações de tomada de preços (ou RFP, Request For Proposal), mas na grande maioria dos casos a influência do preço é determinística a escolha vencedora.

A idéia na mente do cliente

Nossos clientes de projetos de software não estão distinguindo em atos o processo de compra de serviços baseados em projetos de engenharia como compras de commodities, apesar de na teoria afirmarem diferenciar. Eu assumo esta afirmativa como uma leitura pessoal, entretanto solicito respeitosamente que você aceite-a como “colaboração do benefício da dúvida”. É com base nesta afirmativa que escrevo todo o texto a seguir neste artigo.

Como não é inteligente ficar colocando a culpa nos clientes, vamos assumir nossas responsabilidades e aprender como nós técnicos contribuímos, e muito, para o cenário de compras de projetos estabelecido hoje no Brasil.

Primeiro defende-se a aplicação de vários padrões de mercado inspirados em fábricas ou engenharia civil. Na minha posição, apesar de admitir que certas analogias são sensatas, afirmo que a maioria destas práticas podem ser inadequadas ao processo de construção e controle de software.

Exemplificando, processos e técnicas baseados em fábricas consideram trabalhos braçais e uma linha de montagem. Francamente, existem pontos de um projeto de software que podemos automatizar por serem braçais, mas a grande maioria das atividades necessárias são trabalhos intelectuais. Também reconheço que ao estudar SDLC – Software Development Life Cycle (ciclo de vida de desenvolvimento) podemos compreender a tentativa de estabelecer uma espécie de linha de montagem. Entretanto, comparar um ciclo de vida de desenvolvimento com uma linha de montagem de carros é uma analogia surrealista em vários aspectos, principalmente quando reconhecemos que em projetos de software temos poucas atividades de “apertar parafuso” ou atividades que poderiam ser efetuadas por um robô.

Um conhecido exemplo da engenharia civil é o famoso gráfico sobre o preço de uma alteração no decorrer do projeto. As analogias com a engenharia civil nos ensinam que mudar um banheiro de lugar em tempo de planta é o esforço de replanejar. Mudar o banheiro após os tijolos estarem no lugar implica em perda de material e retrocesso no estágio da obra. É irracional não concordar que na engenharia civil é assim, mas eu acredito que este exemplo não é devidamente proporcional para a engenharia de software. Minha crença, baseada em práticas ágeis e em meu histórico de realizações defende o seguinte gráfico:

Figura 1- Gráfico do custo do esforço de modificações conforme a fase do projeto. Na eixo ‘x’ temos o custo de investimento percentual da alteração em comparação ao que já foi feito e no eixo ‘y’ temos as fases do ciclo do projeto.

No gráfico observamos que uma mudança de escopo de uma funcionalidade na fase de planejamento custa um esforço de retrabalho em torno de 25% para as duas visões, porém nas fases mais adiantes a diferença de esforço e consequentemente custo é assustadora.

Na minha visão, o exemplo de projetos tradicionais foi fundamentado na analogia com a engenharia civil e não tem histórico de veracidade comprovado, ou se existir, é muito específico.

Este dois exemplos explanados mostram-me que nós, técnicos e fornecedores de projetos de software, somos os principais incentivadores do processo de compra de software como se fosse commodities.

Commodity é um bem material normalmente produzido em massa que possui parâmetros de qualidade muito semelhantes no qual o consumidor não tem muitos mecanismos de diferenciá-los. Para este tipo de produto as técnicas de escolha são baseadas em preço e atendimento.

A revisão dos paradigmas da engenharia de software

O título deste subtópico do texto já começou errado. Propositalmente coloquei desta forma para que o leitor possa visualizar minhas preocupações. As idéias que pretendem mudanças não podem serem apresentadas sem considerar os aspectos humanos das pessoas que precisam entendê-las. De fato, existe uma resistência natural nas pessoas a qualquer proposta que começa com a silaba “re”. É mais fácil despertar interesse de evoluções do que de revoluções. Propostas revolucionárias são fracassadas. Propostas que apresentam o novo de forma suave sem “acordar” os sempre presentes temores dos humanos possuem uma chance de sucesso maior.

Então, ao invés de “a revisão dos paradigmas da engenharia de software”, encontraríamos muito menos resistência das pessoas se o título fosse “uma nova visão para a engenharia de software”. Por que é importante entender isso? É porque qualquer proposta nova sofre do racismo natural a mudança e quando escrevo um artigo fico conversando com meu “leitor imaginário” como posso ajudá-lo a propagar as idéias da matéria.

Sobre os paradigmas, quero expor os seguintes pensamentos:

1- A maioria das propostas de metodologia foram criadas na década de 80 influenciadas com os grandes avanços de hardware patrocinados pela guerra fria entre o bloco capitalista e o bloco socialista.

2- Todas as pesquisas sobre o sucesso em projetos de software realizadas pelo Standish Group nos últimos 15 anos apresentam números catastróficos onde visualiza-se pouquíssimos sucessos e um alto número de fracassos;

3- Os ajustes das propostas de metodologia, ou suas variações evolutivas, foram baseadas na experiência do fracasso na busca incessante de evitar o fracasso. Conclusão: Aumento de controle, processos “pesados” e técnicas míopes;

4- Crescente número de padrões impondo aos fornecedores de software uma espécie de “normatização” visando tornar a concorrência de preço equilibrada (nota do autor: os projetos vão virar commodities).

A compreensão destes pensamentos pode trazer-te uma série de dúvidas sobre onde está o problema, entretanto o ponto mais importante para mim é a ausência de foco no sucesso. Percebam que as propostas novas querem evitar o fracasso ou normatizar a concorrência, não houve um direcionamento específico a realização “projeto de sucesso”.

O aprofundamento neste pensamentos resultarão em duas hipóteses distintas:

1- O sucesso no projeto é uma coisa muito pessoal que os que conseguirão guardam os detalhes mais preciosos a “sete chaves”. Nesta linha justifica-se os pensadores que defendem somente projetos de software como atividades intelectuais que poucos humanos são capazes de realizar;

2- Perdeu-se a referência do que é sucesso. Os valores foram distorcidos com o tempo, as pessoas perderam as referências certas e foram invadidas pelas experiência (lições aprendidas) dos fracassos.

Particularmente posiciono-me na segunda hipótese. Sendo assim, precisamos definir o que é sucesso em projetos de software. Novamente, minha posição pessoal é: Sucesso de software é a satisfação do cliente.

Para o fornecedor que está preocupado com muitos outros valores como rentabilidade, produtividade, previsibilidade, qualidade e outros “dades” existentes, sem problemas. Satisfazer o cliente plenamente é atender todos os valores do cliente respeitando os valores do fornecedor também. É uma sinergia.

O pedido colocado neste artigo é: Ao invés de buscar e implantar técnicas para evitar o fracasso nos projetos de software, permita-se estudar novas técnicas preocupadas em satisfazer o cliente.

As propostas ágeis

Como fugir da mentalidade “quanto menor o preço, melhor o negócio”? Criando controles para congelar tudo no projeto e esquivar-se de prejuízos financeiros? Padronizando todos os fornecedores de software com certificados para que todos tenham o mesmo preço?

As propostas ágeis baseiam-se na compreensão que a compra de um projeto de software segue orientação calçada em um serviço único, exclusivo. Um projeto nunca é igual a outro, por mais que existam padrões e aplique-se “militarmente” uma metodologia.

As principais orientações de um projeto ágil são:

· Aprender com o valor do projeto;

· Foco total na satisfação do cliente;

· Comunicação transparente dentro da equipe e com o cliente.

O maior valor que o projeto trará para o próprio projeto, não são as lições aprendidas como erros que precisam ser evitados. A lição válida é aprender com os acertos. Aprender com os erros é uma afirmativa que questiono há alguns anos.

Vou exemplificar com o sentido da palavra experiência. Para mim, experiência se adquire quando você não consegue atingir seu objetivo. Uma analogia engraçada: Um amigo meu ontem ao avistar uma linda mulher desacompanhada indagou comigo que ia paquerá-la. Após alguns minutos ele retorna. Eu pergunto-o: E aí, o que conseguiu? É, ganhei experiência para a próxima – respondeu ele.

Um exemplo que apliquei com sucesso em meu último projeto: Investimos 16 horas para confeccionar documentos de caso de uso que descreviam o fluxo principal, o fluxo alternativo e o fluxo de exceção de determinada tela do sistema. Pedi para os analistas de negócios aprenderem com o próprio projeto. Orientei-os a escreverem somente o fluxo principal e enviarem para o desenvolvimento. Após implementado, os analistas de negócios testavam as telas e escreviam os fluxos alternativos e de exceção. Resultado: Aumentamos a qualidade do produto sensivelmente e reduzimos o tempo de especificação em 50%.

A satisfação do cliente, por incrível que pareça, em muitos projetos é tratada com importância secundária. Sem entender os valores do cliente como iremos atendê-los? Eu concordo que requisitos de negócios são como água, quanto mais congelados mais fáceis são de trabalhar. Entretanto, não permitir que o cliente evolua suas idéias pode fazer com que você entregue o projeto no prazo e com o custo previsto, mas o projeto não seja utilizado pelo cliente.

A melhor forma de atender mudanças evolutivas de escopo sem comprometer o resultado financeiro do projeto é pegar constantemente o feedback do cliente o mais cedo possível. Vamos imaginar como fazemos isso de forma simples:

1- Na entrevista ou nos processos de especificação escreva tudo que o usuário quer, afinal papel aceita qualquer coisa mesmo;

2- Antes de passar ao desenvolvimento, classifique o que o usuário pediu como mais importante com destaque. Mantenha o foco nestes pontos, são os mais relevantes;

3- Planeje duas semanas de trabalho que incluem desenvolvimento e testes básicos;

4- Oriente para que a implementação seja a mais simples possível, ela corre sério risco de ser modificada;

5- Assim que atender os requisitos mínimos de qualidade nos testes que você aplicou, mostre para o usuário.

Trabalhe todas as observações do usuário com maior atenção nesta fase, assim você estará investindo maior esforço em um requisito com maior “maturidade”. Depois disso repita estes cinco passos para todos os conjuntos de funcionalidades afins do projeto. De duas em duas semanas, o projeto será finalizado agradando plenamente o usuário.

Um conselho pessoal que passo como complementar neste ponto é “faça sempre a parte mais difícil primeiro”. No fundo, os clientes pouco estão ligando para cadastros básicos e querem ver mesmo a parte mais importante do software funcionando. Esta prática que aconselho tem inúmeras vantagens, entre elas, se você precisar reduzir escopo para não estourar o orçamento do projeto, é bem mais fácil retirar cadastros simples e listagens do que os principais requisitos do projeto.

Comunicação é um tema tão discutido e tão pouco efetivamente evoluído dentro dos projetos que nos deixa desanimado de escrever. Para mim, o erro já nasce nas universidades que consideram os cursos de informática como ciência exata. Tom DeMarco, em seu livro Peopleware, deixa claro desde a década passada que os problemas em projetos de software estão muito mais relacionados a fatores humanos que técnicos. Conheço muitos programadores excelentes de código que não conseguem se relacionar com seres humanos e acham engraçado quando comentamos que deveríamos colocá-los trancados em uma sala sem janelas e passar por debaixo da porta as especificações e a pizza.

Falta na formação do técnico em informática disciplinas que ensinam o trabalho em equipe, inteligência emocional, resolução de conflitos e comunicação clara (entre outras).

Considerações finais

Mudar o enfoque de quais são os problemas nos projetos que precisam de técnicas para ser resolvidos, trará uma nova realidade de estudo e prática. As técnicas mais comuns que aprendemos hoje foram criadas na tentativa de solucionar uma crise do software que, inclusive, já dura mais de dez anos. Se uma crise dura mais que três anos, para mim, não é mais uma crise, é a nova realidade da vida.

Basear-se também em exemplos de engenharias similares e processos de fábrica não vão propor nenhuma solução efetiva aos problemas de hoje. É importante saber reconhecer e separar o que são trabalhos intelectuais dos trabalhos braçais.

Por último, se o mercado nos força a oferecer nossos serviços como commodities, vamos nos adequar a esta realidade com propostas econômicas e que objetivam a satisfação do cliente.

Experimente um projeto ágil, você vai se surpreender.

Referências

Agile Software Development: The Cooperative Game by Alistair Cockburn;

Visual Studio Team System Rocks by Fábio Câmara, Clementino Mendonça e outros;

Extreme Programming by Vinícius Manhães Teles;

Modelagem Ágil by Scott Ambler;

Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer;

Rapid Development by Steve McConnell;

Code Complete, 2nd Edition by Steve McConnell.