Quando se faz um contrato de desenvolvimento e manutenção de sistemas, imagino que uma série de cuidados são tomados 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á…
Leave a Comment