Inspeção Cruzada Alternada Frequente: Muito Além da Garantia de Qualidade

jun 30, 2011

Quando se faz um contrato de desenvolvimento e manutenção de sistemas, imagino que uma série de cuidados é tomada em sua redação: o contrato é revisto por inúmeros departamentos, passa na mão de várias pessoas, cada uma tentando achar aquele “pelo de ovo” que pode fazer com que de lucros exorbitantes a contratada passe a ter prejuízos fatais.

É muito triste ver, com muita frequência, que este cuidado tomado no começo do projeto não seja mantido ao longo dele.

O que eu vejo é que, tipicamente, fechado o contrato, a empresa contrata uma centena de programadores, fala do SLA, pode até dar um cursinho de programação na arquitetura do sistema, e daí larga os “minino” pra programar. Nesta hora, tudo o que interessa é cumprir os prazos acordados. E pode acontecer uma situação como a que descrevo a seguir.

Alguns anos depois do início do projeto, Minino, programador que estava desde o início no projeto, morreu.

Algumas semanas depois, o cliente reclamou que a rotina de faturamento não estava funcionando corretamente. Então os gerentes de projeto descobriram que Minino cuidava justamente da rotina de envio de faturas. Como a rotina era crítica, era sempre Minino que fazia a manutenção. Afinal, Minino “corrigia as coisas rápido pra danar” e suas correções eram sempre aprovadas pela equipe de QA de código fonte e de Testes Funcionais.

Aí, a gerência chamou Fulanim, o programador mais experiente da equipe, pra verificar o problema. Após passar algumas semanas olhando a tela fixamente, até baba sair dos cantos da boca, Fulanim é internado em uma clínica psiquiátrica: Minino fez pós-graduação em computação quântica, e resolveu utilizar um algoritmo obscuro no código, que chamaremos de PoliX, que só Minino conhecia: ninguém mais parecia ser capaz de dar manutenção na rotina de faturamento. O cliente ficou muito insatisfeito com isso, o SLA foi pro espaço, e o projeto desceu pelo ralo.

Existem várias formas de se evitar o problema demonstrado.

• · Dividir sempre a responsabilidade de manutenção do código entre duas ou mais pessoas.
  • Isto não evita entregas de baixa manutenibilidade, pois a cada demanda uma pessoa trabalharia no código por vez, sem inspeção.
• · Implementar processos formais de revisão e inspeção, como proposto no SWEBOK
  • Na minha opinião, é muito burocrático e envolve vários revisores, o que impacta em muito a produtividade.
• · Utilizar a programação em pares, como proposta no XP:
  • Este processo é bastante controverso. Vide: http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp

Porém, quero propor algo que seria intermediário entre a revisão formal e a programação em pares: em períodos específicos, de preferência frequentes, uma semana no máximo, os membros da equipe fazem uma revisão cruzada em pares: Fulanim revisa o código de Minino, e Minino revisa o código de Fulanim, em uma entrevista rápida. Além disto, a alternação entre pares deve acontecer: Fulanim revisa o trabalho de Minino num dia, daí Juquim revisa o trabalho de Minino em outro dia. No dia em que Minino tentar usar o PoliX, o seu revisor naquele dia, Fulanim, vai pegar Minino na consumação do ato, e uma das duas coisas pode acontecer:

• · Minino explica o PoliX pra Fulanim, que gosta da idéia e começa a usar também.
• · Fulanim fica completamente maluco, escala pra gerência, e Minino é obrigado a implementar algo mais legível.

É possível identificar os seguintes benefícios diretos da adoção da Inspeção Frequente:

• · Se for realmente frequente, evita que membros da equipe fiquem “travados” em determinada tarefa, pois alguém poderá fornecer uma visão nova ao problema sendo combatido.
• · Membros mais novos podem descobrir mais rapidamente os “truques” do sistema.
• · Membros mais experientes podem identificar que sua solução é muito complexa.
• · Aumenta a interação, e consequentemente a integração, entre os membros da equipe.
• · Aumenta a consciência dentro da equipe dos talentos de cada membro.
• · Se a inspeção se estender inclusive entre departamentos de diferentes domínios, por exemplo, entre desenvolvedores de corretivas, evolutivas e gerentes de requisitos, melhora o entendimento entre essas equipes, pela formação de um dialeto comum.

Ainda há muito a ser refinado neste procedimento, e algumas questões a serem respondidas. Espero não morrer até lá…

Number of View :1185

Posts Relacionados:

1. Benchmarking de TI – Muito além dos Indicadores
2. Gestão de Qualidade com qualidade em TI
3. Segurança da Informação vai além de dispositivos
4. Segurança além das permissões de acessos
5. Crescimento sem mudança: Tem tudo para não dar muito certo!