Concrete Logo
Hamburger button

Ágil como MacGyver no Caipira Ágil – parte 2

  • Blog
  • 28 de Agosto de 2012
Share

 
Continuação da série Ágil como MacGyver no Caipira Ágil que começou com a parte 1

 

O papo com a platéia

Tentarei resumir aqui um pouco do que conversamos.

A esta altura, a apresentação não tinha mais slides. Fui seguindo uma lista de práticas consideradas ágeis que coloquei no editor de texto.

Luca Bastos

O propósito não foi exatamente discutir as vantagens de seguir as práticas mas sim saber quem fazia e questionar o “fazer sempre”.

No papo foram abordados diversos tópicos de engenharia de software:

    Pair programming

      Tipo da coisa que depende muito das questões dos indivíduos envolvidos. Há gente que gosta de fazer quase o tempo todo. Que confessa ser dispersivo quando sozinho. Outros ficam exaustos mentalmente quando passam mais de 2 a 3 horas pareando.

      Na platéia poucos disseram que fazem programação em par na maior parte do tempo. Mas havia o pessoal da Webgoal que se disse bem habituado assim.

    Revisão de código

      Acho que são raras as empresas que consideram como produtivo o tempo dedicado a revisão de código. Para mim é uma atividade que deveria ser estimulada. Na platéia alguns disseram que onde trabalham existe esta prática.

    TDD

      Muito bom quando os desenvolvedores tem TDD entre os recursos que sabem usar. Mas não acho produtivo fazer sempre. Algumas vezes, principalmente naquelas em que a gente nem sabe como começar, acho TDD muito útil. Mas quando o projeto da classe parece óbvio, quando não há risco de ficar tudo engruvinhado, acho que se pode partir direto para escrever a classe com seus testes unitários.

      Uma boa discussão sobre o assunto no capítulo 5 do livro Introdução à Arquitetura e Design de Software.

      Outra ótima fonte são os slides da apresentação Métodos ágeis: o que é folclore e o que é real? do Maurício Aniche no QConSP. O slide 24 da apresentação dele diz:

        “A prática de TDD não guia o desenvolvedor para um bom projeto de classes de forma automática“.

      Este slide cita ainda a tese de mestrado do Maurício orientada pelo prof. Marco Aurélio Gerosa que vale a pena ler em Como a prática de TDD
      influencia o projeto de classes em sistemas orientados a objetos
      .

      Na mesma apresentação do QConSP o Maurício Aniche diz:

        Eu uso TDD quando…

          – Não sei bem como projetar minhas classes;
          – Sei bem o que quero fazer, mas não sei bem como fazer.
        Eu não uso TDD quando…

          – Já tenho bem claro o projeto da classe;
          – É código que lida com infraestrutura.

        Mas testo o tempo todo!

      Recomendo fortemente que vejam com atenção os slides da apresentação do Maurício, para mim ele é um dos que mais conhecem TDD no Brasil.

      Por fim deixo para pensar um tweet que surgiu alguns dias depois da minha apresentação:

        “My main reason for TDD is not better code. It is better coders.”

 
Quiz discutir também alguns rituais. Tomei por base o Scrum que ainda acho o mais fácil de indicar e seguir.

Scrum

    Duração dos sprints: 1 semana? 2 semanas? 3 semanas?

      O ponto principal é: adote a duração melhor para seu projeto. Na dúvida, escolha o mais curto. Adote o que não acarrete reuniões muito longas.

      Eu prefiro sprints de uma semana porque sendo mais longos, as reuniões duram muito e depois de algum tempo, gente como eu, já está concordando com tudo só para abreviar a reunião.

      Mas a minha preferência e o que você leu ou ouviu em algum lugar não tem nenhuma importância. O que vale é o que for melhor para o seu projeto e para as pessoas que o desenvolvem.

      Mesmo a divisão fixa de tempo, os chamados time boxes, conceito que é um dos pilares do Scrum, podem em alguma ocasião muito particular, precisar de um tamanho especial inusitado. Quem já desenvolveu software científico do tipo CAE/CAD talvez me entenda mas não vou entrar em detalhes. Só digo que já levei cerca de um mês ou mais para fazer uma única feature (uma fórmula) funcionar.

      Minha recomendação é: faça o que for preciso ao invés de ser escravo do que os outros dizem ou fazem.

      De qualquer forma vale o tweet do Jim Highsmith:

    Planning Poker / usar pontos para estimar

      Como previsto, é bem polêmica esta questão. Eu prefiro estimar em horas. Prefiro errar em horas. Na plateia havia gente defendendo os pontos. Ninguém conseguiu mudar minha opinião e meus argumentos também não foram assim tão convincentes. Espero mais opiniões nos comentários.

    Alguém mede a velocidade/confere pontos e horas.

      Se você usa pontos, precisa fazer algum tipo de estudo paralelo para conferir e melhorar os chutes dos pontos.

      Mas se usa horas para estimar, o fato do sprint ser medido assim não é razão suficiente para não conferir as estimativas. Sei que o próprio acúmulo de trabalho, às vezes, serve de desculpa para não fazer e isto é uma pena, pois melhoraria a capacidade de estimar/chutar da equipe.

    Aborta sprints quando entra imprevisto.

      Quem faz isto?

      E pior. Quem tem coragem de dizer não ao cliente, P.O. ou analista de negócio que diz ser importante entrar aquilo que não foi previsto na reunião? Será que não alterar o sprint é o certo?

        É claro que não se pode negar. Se quem entende do negócio diz que “tem que entrar”, isto passa a ser a prioridade do time.

      No papo não percebi ninguém mais radical dizendo que aborta o sprint. Mas eu já li isto como recomendação. Que quando acontece isto é preciso replanejar o sprint.

      Ao meu ver é mais uma questão para ser tratada caso a caso. Vai depender do esforço necessário para incluir o que não tinha sido previsto. Como disse, se precisa entrar, é porque é importante e se o time está comprometido em entregar valor, esta exigência precisa ser contemplada e sem maiores desgastes.

      Nem que para isto o sprint precise ser abortado.

      Ou o que eu acho menos radical, que se escolha para voltar ao backlog uma ou mais histórias com tamanho total equivalente ao que está entrando pela janela.

    Reunião diária

      Sei de ótimos desenvolvedores que detestam a reunião diária. Mas sei também de gente que adora. Como agir então?

      Aqui entram as habilidades pessoais do Scrum Master ou de quem esta conduzindo o projeto. Impor práticas que causam aborrecimentos pode ser ruim.

      Perder a transparência e feedback das reuniões diárias pode ser pior. O Scrum master ou quem conduz o projeto precisa ser esperto e procurar bons argumentos para encontrar um equilíbrio.

 
O papo foi mais longo e além de práticas e rituais de processos, conversamos também sobre características das pessoas. Para poder incluir também algumas considerações que acho importantes em uma equipe de desenvolvimento de software, vou parar este post por aqui e deixar o resto para uma 3a parte.

 
Comentários são bem-vindos.