Gerência de Projetos

Ξ 4 comentários

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

publicado por Alexander Picoli

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:

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á…

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Autor

Sou um dos dinossauros da informática: comecei meu relacionamento conturbado com ela em 1984, com o TK85 do meu primo, e 1985, com um curso de basic em um CP300. Passei por um TK2000, um TK3000 e um curso de informática industrial. Saí da área em 1990 para fazer engenharia de alimentos, mas não resisti e comecei a voltar em 1994, quando achei um professor maluco que mexia com informática e eletrônica dentro da engenharia de alimentos. Fiquei nesse romance duplo entre a Engenharia de Alimentos e Informática por 4 anos, quando me cansei da vida acadêmica e voltei para a informática. A volta foi dolorosa: professorzinho de informática, programador Microsoft Access, até que em 2001 apareceu a oportunidade de trabalhar para uma grande corporação azul. Fiquei nesta corporação até 13 de junho de 2011, como analista programador, arquiteto ad-Hoc, desenvolvedor Java "and the All Around Nice Guy" . Neste momento estou procurando trabalho.

Alexander Picoli

Comentários

4 Comments

  • Penso que a empresa deve arcar com as consequencias da falta de visão e atualização bem como mente fechada dos seus proprietários. Os métodos ágeis propõe novas abordagens de parceria e colaboração cliente-fornecedor que podem ser bem interessantes em relação a esse assunto abordado, inclusive o autor menciona o “XP”. Infelizmente a cultura da corporação e a politicagem que hoje em dia são muito presentes nem sempre propiciam que sejam aplicados os métodos e soluções mais apropriados. Que se pague o preço, sem choro!

  • Bem, não entendo muito de códigos. Não é propriamente a minha área. Porém sou focado na solução de problemas. Assim, entre manter pessoas fazendo revisões de código e solucionar o problema eu sempre opto pela segunda alternativa. Então pergunto: Não seria mais fácil estabelecer padrões de codificação os quais devem ser seguidos por todos os programadores? Pergunto: Não seria melhor abrir uma frente para reescrever o código e eliminar o problema da manutenção corretiva constante?
    Para mim fica claro que se uma rotina tem muita manutenção é melhor reescrevê-la. O custo da tarefa é bem menor do que o custo da manutenção e das rotinas constantes de revisão.
    É só ver o histórico de frequência de manutenções de um determinado código para saber a onde está pegando. O resto é Gestão de Projeto de Manutenção.

  • Sergio, o Problema é que código sempre é um texto, uma redação, e a lógica é a ideia inspirada no momento para resolver uma situação (criar a rotina da funcionalidade esperada). Sendo assim, por mais que se crie padrões de código, o item criatividade sempre está presente e a criatividade está ligada também ao conhecimento. Esses fatores, criatividade e conhecimento, podem ser armadilhas para os novatos, E não é interessante, mesmo em desenvolvimento de sistemas nivelar a capacidade e criatividade por baixo. Ou seja, nivelar pelo programador como menos criatividade e conhecimento é deixar um sistema pobre. Rotinas que poderiam ser feitas com 5 linhas passam a ser feitas com 200 nesta concepção.

    Sem contar outros fatores.

    Na minha concepção o problema não está somente no desenvolvimento mas no levantamento dos requisitos que visa meramente entender as necessidades do cliente. Em meus 25 anos de desenvolvimento de sistemas eu aprendi que: o que o usuário precisa, nem sempre é o que o usuário quer. No entanto, uma pessoa com excelência tecnológica não necessariamente vai fazer levantamento adequado pois não consegue ver as entrelinhas.. aquilo que o usuário não consegue mostrar conforme e as vezes é mais importante do que aquilo que ele está pedindo. Isto gera Casos de uso que serão bem desenvolvidos, seguindo todos os padões de código porém com um nível de manutenção altíssimo.

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes