Concrete Logo
Hamburger button

Ágil como MacGyver no Caipira Ágil – parte 3

  • Blog
  • 30 de Agosto de 2012
Share

 
Continuação da série que começou com parte 1 e parte 2

 

No papo lá na UNICAMP foram abordados também uma série de problemas do dia a dia

    Como lidar com código que tem dono.

      Há gente que tem ciúmes do código que escreveu. E fica infeliz quando mexem na sua obra prima. Isto não é raro. Acho que até se pode dizer que é uma qualidade do ser humano orgulhar-se da sua cria.

      Mas o código precisa evoluir. Novas features podem exigir refatoração e até mesmo troca do algoritmo inicialmente escolhido.

      Há casos em que o melhor é mesmo deixar o criador alterar o que fez. Ou seja, que ele mesmo inclua as novas features que afetam o que fez. Afinal é quem mais conhece o código.

      Mas em compensação, permitir proprietários de código pode deixar o projeto na torcida que este tal proprietário não fique doente ou não saia da empresa.

      Code ownership also means code responsability

      Este é um dos muitos casos do nosso dia a dia em que precisamos ter habilidades que vão muito além do que se aprende nas aulas de computação. Vale mais a capacidade de negociação de cada um. Precisamos lidar com questões que afetam relações humanas.

      Ao contrario dos que valorizam somente os conhecimentos técnicos, acho que a evolução nas habilidades no trato com as pessoas é o que diferencia um desenvolvedor senior.

     
    Refatoração de código. Como convencer ao cliente de que isto é necessário.

      Muitas vezes iniciamos o projeto sem saber ou entender todo o contexto do que vem a frente. Mesmo usando TDD e/ou fazendo pequenas refatorações frequentes, pode acontecer o caso em que o projeto precise de uma refatoração maior que envolva uma boa parte do código.

      Refactoring

      Eu já passei por isto. E digo: foi muito difícil convencer o cliente. Na verdade o cliente não se convenceu. Digamos que engoliu, digeriu mal e regurgitou na primeira oportunidade que teve para reclamar de atraso no projeto. Alguém já passou por projeto que atrasou?

      Atrasos são comuns. Dar combustível para o cliente queimar nosso filme não é uma boa estratégia. Então o que fazer? Resposta difícil. A menos que o cliente seja uma mãe, vai espernear a beça se você disser que precisa desse tempo.

      Uma dica de uma ação que talvez funcione mas digo logo que nunca participei de um projeto assim, é manter na equipe o tal Batman da iteração. Talvez este cara possa se encarregar de uma eventual refatoração sem parar o sprint. Esta ideia é do James Shore e é descrita na página 243 do livro The Art of Agile Development. Também está muito bem explicada pelo pessoal da Bluesoft neste podcast.

     
    Conflitos pessoais

      Me perguntaram como agir nos casos em que há integrantes do time que se odeiam. A pergunta foi bem pertinente, isto não é tão raro assim e já vi acontecer muitas vezes. Como acontece? Uma troladinha anteontem e outra ontem, uma suspeita de disputa por cargo ou projeção, alguma coisa dita, outra coisa não dita, os motivos são águas passadas. Como lidar com uma equipe assim?

      Haters

      Há maiores chances se for possível identificar e tirar do projeto o que mais perturba os demais. Uma vez tive que fazer isto e sem outro projeto para alocá-lo, precisei demitir. Nunca tive 100% de certeza de que era ele mas talvez pelo susto o ambiente melhorou muito.

      Daí ficou uma lição que nem sempre a gente lembra: aquela piadinha diária que faz todo mundo rir menos quem foi trolado… aquela piadinha corrói mais do que falta de aumento de salário. E todo dia nós repetimos a dose. Digo nós porque, apesar de saber dos riscos, eu também faço isto e até rio quando outros fazem.

     

    De novo fui vítima da minha verborragia. Mais um post que ficou longo e que preciso dividir. Vou parar por aqui e deixar o resto para uma 4a e última parte (prometo).

    Repito, comentários são bem-vindos