Sem tempo suficiente

{ June 29th, 2010 }


cmilfont

Autor: cmilfont

Recentemente, em um determinado projeto, tínhamos uma semana para disponibilizar uma versão e uma timeline definida por motivos externos que não poderíamos furar. O problema era que toda modificação gerava ainda mais medo por conta da baixa cobertura de testes, praticamente estavam codificando e corrigindo nessa altura do campeonato.

Eu radicalmente sugeri um grande refactoring para corrigir nossa bateria de testes, uma parada faltando apenas uma semana para entrega, mas só assim voltaríamos a trabalhar na entrega das features.

Nesse momento, o cl√°ssico “N√£o temos tempo para isso” surgiu das profundezas do inferno.

Fiquei sozinho nessa decis√£o, o time inteiro foi contra. Na defesa da solu√ß√£o apresentada eu falei: “Voc√™s podem se enganar imaginando que podem entregar essa release em uma semana com a qualidade do c√≥digo existente que voc√™s sabem que vai de mal a pior ou podem trabalhar para corrigir esses problemas e entregar o poss√≠vel, mas funcionando”.

Sabemos da import√Ęncia de testes, todas as metodologias os cobra obrigatoriamente, ent√£o se voc√™ n√£o testa, voc√™ est√° errado em todas as metodologias. O problema sempre √© a desculpa da timeline e quanto mais vai se aproximando mais desculpas procuramos encontrar para esconder as defici√™ncias. Como nesse caso n√£o t√≠nhamos Test First, os problemas v√£o se empilhando no final e se tornam mais dif√≠ceis de serem detectados.

Por sorte, minha sugest√£o acabou sendo acatada, apesar de ser apenas um consultor no projeto, portanto uma galinha e n√£o porco.

De onde nascem essas desculpas?

Coragem é um dos valores do XP, é importante enfrentarmos esse tipo de situação que descrevi, na vida real isso quase nunca é possível porque essas arquiteturas flácidas ou códigos mal cheirosos não nascem do dia para o outro e vão se acumulando.

O projeto que descrevi era um projeto novo, tecnologias fresquinhas e um time modernoso. Imagina agora se você está em uma corporação que usa um processo cascata, todo amarrado, criando documentos UML desnecessários no EA, struts 1 como framework, CVS como controle de versão do código [quando há! Sim, em pleno 2010 ainda há quem não use nenhum], o código de banco de dados cheio de procedures e tantas modernidades da década de 80.

Então, acha que só coragem basta?

Em muitas oportunidades o custo de mudan√ßas ou simplesmente “fazer o que se tem que fazer” n√£o se pagar√° nem a m√©dio prazo, nessas horas convencer j√° n√£o basta. √Č muito dif√≠cil voc√™ convencer a alta dire√ß√£o que deve jogar fora um determinado projeto e come√ßar do zero, ou modificar toda a infraestrutura existente.

A degradação de um software nasce de pequenos problemas que se acumulam, no final há tanto para se fazer que ninguém mais tem coragem para isso.

Socorro, Milfont!

Recebo constantemente pedido de socorro de pessoas que me conhecem das comunidades que participo como XPCE, GURU-CE, JAVA-CE, entre outras. Geralmente são funcionários que se encontram nessa situação que citei anteriormente, com projetos muito defasados e problemáticos.  O pedido é sempre o mesmo, querem que eu vá lá dizer para a alta direção o que eles [funcionários] já sabem. Só que isso não basta, o movimento tem que começar por lá.

Em reuni√£o com a turma da TriadWorks, temos discutido isso j√° h√° muito tempo e acabamos preparando um servi√ßo de resgate aos clientes para contornar esse problema. A proposta √© envolver as pessoas desses clientes, dar coragem e √Ęnimo nelas para come√ßarem a resolver o problema.

Resolvemos começar com nossos próprios clientes, sim, dá preferência a quem tem contrato conosco e depois verificar como abrir para a comunidade.

Ent√£o, esse envolvimento n√≥s demos o codinome de “AvoidNotEnoughTime” e consiste basicamente em um conjunto de a√ß√Ķes/eventos¬† com os funcion√°rios dessas empresas para dar essa for√ßa necess√°ria para anular o NotEnoughTime na base. √Č um movimento de baixo pra cima, roots, ser√£o desde Coding Dojos, Code Retreat, Code Jam, Hack Days, Lightning Talks, Open Space ou um formato adequado a um determinado problema que identificarmos.

Nós não vamos cobrar a mais dos clientes por isso, aliás, eles nem foram avisados e não terão controle sobre o projeto, nós que decidimos quando, como e com quem faremos justamente para evitar sabotagem ou direcionamento.

Sem planejamento nem nada, resolvemos iniciar mesmo assim, domingo passado [27/06/2010] realizamos um Git Session onde eu [@cmilfont], @triadworks representada por @handersonbf, @rponte e @carlosatilabreu, recebemos funcion√°rios de clientes nossos. @jeffersongirao da TubForm, @rodrigogalba da Casa Magalh√£es e @rodrigodealer da Fortes Inform√°tica.

O que vocês ganham com isso?

Resolvemos fazer um Git Hack Session devido alguns de nossos clientes usarem CVS e SVN. O tempo perdido resolvendo problemas de reposit√≥rio como merges e bobagens simples causam um preju√≠zo enorme, as desculpas para mudarem cai sempre no “n√£o temos suficiente” ou “depois fazemos quando terminar esse projeto”.

Ent√£o cada ponto de dificuldade que um time enfrenta e observarmos que se repete nos demais clientes, vamos organizar a√ß√Ķes para envolver essa turma afim de anular essas desculpas. Treinar multiplicadores em todos os princ√≠pios.

No caso do Jefferson Gir√£o, que trabalha tamb√©m para a Hoodiny, veio mais para nos auxiliar, j√° que est√° mestre no uso do git no meu cliente Tubform [uma das maiores ind√ļstrias do Nordeste].

Dessa forma nosso trabalho de consultoria ser√° facilitado e no m√≠nimo j√° far√≠amos esses eventos internamente, ent√£o unimos o √ļtil ao agrad√°vel.

Se você gostaria de participar de algum desses eventos mesmo não sendo funcionário de cliente nosso, mande um email para mim [cmilfont@gmail.com] e tentaremos incluir sempre quando puder. Domingo agora surgiu um desfalque, até twittei convocando alguém que estivesse disponível, mas foi em cima da hora.

Começou #gitsession on Twitpic

Categories: Engenharia de Software, Melhores pr√°ticas, Metodologia, M√©todos √Āgeis, Test Driven, XP ~ ~ Trackback


Assine os coment√°rios deste artigo.


7 Responses to “Sem tempo suficiente”

  1. 1
    Henrique Gogó

    Só para dizer que desse time modernoso que usa tecnologias fresquinhas, não fui totalmente contra o refactoring. Só 62,3% hehehe

  2. 2
    Tweets that mention Milfont.org Ultrapassando os limites da WEB -- Topsy.com

    […] This post was mentioned on Twitter by cmilfont, Rodrigo Oliveira. Rodrigo Oliveira said: RT: @cmilfont: #MilfontConsulting e #TriadWorks criaram o #AvoidNotEnoughTime http://www.milfont.org/tech/2010/06/29/sem-tempo-suficiente/ […]

  3. 3
    Bruno Pedroso

    Parabéns Milfont!
    Se estivesse em Fortaleza, ia querer participar! :-)

  4. 4
    Rafael Ponte

    Excelente post, Milfont – as always!

    A desculpa do “not enough time” √© mais comum do que muita gente imagina.

    Nosso #githackday foi apenas o inicio de um projeto tímido, AvoidNotEnoughTime, mas que possui chances de ser tornar maior do que podemos imaginar. Entre os objetivos almejados está levar estas sessions, assim que possível, para a comunidade.

    Enfim, fiquei muito feliz e mais motivado ainda após o primeiro encontro. Só ouvi elogios do pessoal que participou e pedidos de outros membros dos clientes para participarem do próximo!

  5. 5
    Rodrigo Galba

    Posta bacana Milfont.
    Nosso #githackday foi bastante proveitoso e √ļtil.
    Acho que ‘vendemos o peixe’ para usar Git na empresa.
    Só temos a ganhar.

    Pode contar comigo para levar esta iniciativa para a comunidade.

  6. 6
    Palestra Agilidade no Mundo Real - Milfont Consulting

    […] Blog « Sem tempo suficiente […]

  7. 7
    Meu ambiente de desenvolvimento em 7 items - Milfont Consulting

    […] Conta p√ļblica e privada no Github. Alguns reposit√≥rios internos em clientes no CVS, SVN e GIT. Temos uma meta de substituir tudo pelo Git em todos os clientes, at√© de gra√ßa. […]

Leave a Reply