“Se virol” – Reunião de Abril do GUMA-RS

Aconteceu hoje, 11 de Abril de 2012, na Faculdade de Informática da PUC-RS sala 516, mais uma reunião do Grupo de Usuários de Metodologias Ágeis do Rio Grande do Sul. Realmente tem valido a pena estar em terras gauchas!! Grandes talks, muito networking e várias idéias….

O evento teve início as 19:28h, com o Marco Enes fazendo sua lightning talk no “Se virol”… quer dizer o título que era “se virol”!!! O Marco é diretor da Meganti, e assim como muitos dos empreendedores atuais se viu as voltas com a consolidação de uma cultura ágil dentro da empresa, e neste cenário propós o talk.

Segundo o Marco, ele assim como vários amigos, gerentes de projetos ou fundadores de startups, veem percebendo um padrão comportamental dentro dos times, como um estado coletivo de letargia, com grande dependência e baixíssima proatividade. Ao que ele relata os times não estão se comportando como esperado de times auto-organizados, impulsionados por preceitos ágeis como “_Indivíduos e interação_ entre eles _mais_ que processos _e_ ferramentas”… por que será?

O relato, expectativas e  justificativas me pareceram muito familiares, já vimos e ouvimos em vários grupos relatos semelhantes… times construidos sobre bases de incerteza… times ou pessoas que por um bom tempo seguiram métodos puramente prescritivos, sob qualquer cenário, e dos quais se espera que por completa força de vontade metodologica, seja feito “o exorcismo” de práticas enraizadas e fortalecidas por gerações dentro da mente de todos. Se desfazer do burocrático, dependente e longinquamente adaptativo, em prol do crescer e do fazer em curtos ciclos não é para qualquer um, ou qualquer cenário!! Hum…. acho que não dá para fazer mágica!!

O Marco acredita bastante nisso e para tal propõe o “se virol” como uma composição de bom senso, proatividade e motivação que facilita o processo de crescimento da cultura ágil. Para os times Meganti, vem se dosando neste um ano o apoio mútuo, com a criação de um ambiente proativo de auxilio, com gerentes de projetos/produtos que confiam e apoiam seus times, dando a eles autonomomia, apoiando a estes o alcanço de dada maestria e alinhando proposito (conferir o TED sobre motivação do Dan Pink).

Então antes de começarmos pelo fim e dizermos que o processo não funciona ou que as pessoas não servem para aquilo, devemos conjuntamente analisar onde estamos e queremos ir… de preferência todos na mesma direção.

Tem um artigo de 2002 do Pete McBreen autor do livro Software Craftmanship, que já enumera sinais claros de que a culpa não é de quem… mas talvez do como!

Não é de hoje que muitos seguem a estrada do But this but that e adentram bem estes cenários dos que muito dizem ser ágeis e que não assumem a responsabilidade do grupo só as delegam para os demais… Então, ficam ai as 10 dicas do Pete, sinais simples para provar que você pode estar no caminho errado (tradução livre e comentários):

  1. O Plano de Projeto acaba de ser divulgado pelo gerente de projetos e mostra o primeiro release acontecendo 18 meses depois do início do projeto. Uma equipe ágil não é comunicada sobre o plano, ela colabora e se compromete com a sua criação, o foco está no planejamento e não no plano resultante. O planejamento faz com que a equipe tome decisões e estabeleça prioridades para que algo valioso possa ser lançado em alguns meses.
  1. O gerente de projeto fala sobre artefatos que serão produzidos por analistas para os arquitetos.  O próximo passo é entregar as especificações de arquitetura aos projetistas, que entregam aos programadores… que apenas codificam!! Como é possível não esperar a discordia em um ambiente com tão pouco envolvimento? O melhor quem sabe é se resguardar! Cada um com seu documento?
  1. Analistas e arquitetos afirmam orgulhosamente que não codificaram uma linha sequer em seus últimos projetos. Mostra que se pensa em codificar como atividade trivial. Isso vai totalmente contra o Agile Manifesto, que diz claramente que software funcionando tem mais valor que documentação. Sempre que qualquer membro de uma equipe “ágil” se gaba de ter trabalho “superior” ao de outro membro da equipe, a equipe está apenas fingindo estar preparada!! Provavelmente nada foi feito para fundamentar o verdadeiro objetivo, entregar software que agregue valor de forma colaborativa!
    *Artigo sobre especialistas generalistas.
  1. Programadores e testadores estão no nível mais abaixo da cadeia alimentar.  Times ágeis começam a programar e testar muito antes do que as abordagens mais tradicionais, normalmente dentro das primeiras semanas do projeto. Assim que devemos incentivar a coragem! Colocar os programadores e testadores no final de uma cadeia alimentar a longo torna impossível para que o projeto seja ágil.
  1. O analista cosntantemente tenta fazer os usuarios assinarem o tal documento dos requerimentos. A proposta Ágil é colaborar com o cliente, e compartilhar expectativas e responsabilidades sobre o sucesso do projeto! Não limitar escolhas! Se a sua equipe ainda pensa desta forma, talvez a agilidade ainda esteja um pouco longe!
  1. Desenvolvedores reclamam quando uma mudança nos requisitos passa por cima do burocrático processo de controle de mudanças.  Achei que o manifesto falava algo sobre abraçar as mudanças, muitos times tem o seu momento de fúria com novas solicitações de mudança… talvez mais um ponto que devemos lembrar de trabalhar antes das reuniões diárias?
  1. Você está a mais de dois meses no projeto e ainda não foi exibida pelo time nenhuma funcionalidade útil aos usuários. PowerPoint e telas mock não contam. Projetos ágeis devem permitir um aprendizagem com validações de hipoteses a todo o momento. Os usuários devem colocar suas mãos no software muito cedo, de modo que estes consigam direcionar o crescimento de forma solida e sem desperdicios.
  1. O líder do projeto considera que a documentação é mais importante que a comunicação. Isso acontece quando o projeto está produzindo um rastro de papel, registrando todas as decisões tomadas para garantir a rastreabilidade dos requisitos, mas, apesar disso, ninguém na equipe parece entender o que realmente está acontecendo!! Se algo é importante para valer um documento, é importante para ser conhecido por todos. Não se conquista o comprometimento, maturidade ou autogerenciamento sem envolver todos nas decisões! Fortaleça a comunição e a responsabilidade!
  1. Testes e verificação de qualidade não são partes integrantes e respeitáveis do processo. Se o seu time não se preocupa com qualidade em primeiro lugar, como poderia estar se autogerenciando bem? Como ele poderia fazer qualquer coisa sem qualidade? Todas as abordagens ágeis contam com testes para a validação de feedback sobre a qualidade do software. Como tal, as atividades de garantia de teste e qualidade são reconhecidas como uma parte vital do processo de desenvolvimento que tem que começar no dia 1 do projeto. Adiando testes ou atividades de garantia de qualidade até o final do projeto é um sinal claro de que o processo não é ágil e provavelmente isso não é culpa do processo…
  1. Tarefas são dadas a pessoas, que pegam seus trabalhos e se isolam num lugar quieto tratando aquilo como um trabalho solo. Se a sua empresa é um lugar onde as pessoas usam sempre fones de ouvido ou se isolam para não serem perturbados, você pode apostar que o elas não entendem o desenvolvimento colaborativo. Seu problema está só começando!  Se não entendem o básico disto, podem ter certeza que o processo não é ágil, não importa os quadro-brancos, reuniões diárias em pé ou programação em par!