Resumo do Agile Brazil – Primeiro Dia

Semana passada, fui ao evento AgileBrazil, promovido pela PUC do Rio Grande do Sul. Foi um evento de quatro dias, embora os dois primeiros tenham sido reservados apenas para mini-cursos (XP, Coaching, etc – infelizmente, quando fiz minha inscrição não haviam mais vagas para estes cursos). Apesar de algumas falhas na organização (eu, particularmente, achei muito ruim o número de palestras simultâneas – no geral haviam quatro palestras ao mesmo tempo, além de Open Spaces entre outros. Achei ruim não ter conseguido participar de nenhum open space, mas é a vida), o evento contou com um nível técnico muito bom, ao meu ver, com palestras extremamente interessantes.

O evento começou com um Keynote do Martin Fowler, no qual ele apresentou três pequenas apresentações. Em uma delas, ele apresentou os perigos da gerência de software da forma como tem sido feito, fora do mundo ágil, apresentando que no passado, o sucesso era definido se o plano inicial foi seguido (o que ele considera um absurdo, pois um sistema pode ter sido bem-sucedido sem sequer ter sido posto em produção). Em seguida, ele citou sobre “Technical Debt”, um termo para indicar quando as boas-práticas são ignoradas, no desenvolvimento de software, em prol de uma série de coisas tal como “precisamos atender o prazo”, etc. Ele cita que tal débito precisa ser cuidadosamente controlado, caso contrário fica a produtividade começa a cair (e cita que o tempo que este débito pode sair do controle é medido em semanas, e não em meses como se achava). Por fim, sua última apresentação falou sobre integração contínua, no qual ele citou como faz seus “deploys”, no qual em cada Commit ele gera um executável que vai para uma bateria de testes (Smoke Tests, e Aceptance Tests), para depois cair em uma segunda bateria (mais Smoke Tests e Performance Tests) para, por fim, ir para produção (com mais Smoke Tests). Citou também o software Cruise, mas não entrou em muitos detalhes.

A segunda palestra que eu vi foi com o Jorge da GlobalCode, com a palestra “Testar: impossível”. Nesta palestra eu esperava algo mais, porém uma dinâmica feita mostrou algo preocupante: quase ninguém concorda com o que significa “teste de software”. Ele citou algumas coisas sobre testes, mostrou que só recentemente que as pessoas tem apresentado interesse crescente em testes automatizados (e cita que a maioria das pessoas faz mais Aceptance Tests do que Unit Tests, quando na verdade deveria ser exatamente o contrário) e definiu que inspeções de código não podem ser substituídas por testes, nem o contrário. Citou a ferramenta “Sonar”, porém também não entrou muito em detalhes.

A terceira palestra que eu iria ver era da Gabriela, que ia falar sobre integração contínua, mas logo no início da palestra ela citou que alterou sua palestra para falar menos de integração contínua. Nesse ponto, eu saí e fui ver a palestra do Alexandre Gomes, com a palestra “Pra você, desenvolver software é atividade intelectual? Pro Governo Brasileiro, não”, até porque eu vivo essa realidade no trabalho. Porém, ao contrário do que eu imaginei, a palestra foi mais uma lamentação coletiva sobre a forma como o governo brasileiro vê o desenvolvimento de software, como área estritamente técnica e controlada ao invés de trabalho criativo. No final da palestra, algumas pessoas citaram alguns cargos públicos que já estão fazendo licitações pedindo Scrum ou XP, e eu fiquei bem preocupado com isso-sejamos sinceros, é extremamente simples você “falsificar” um Scrum e continuar usando cascata (esse é o menor ponto), mas principalmente, aonde está a máxima do Manifesto Ágil que pede uma menor ênfase nos processos?

A quarta palestra que vi foi sobre Mocks (Já que vai fingir, finja direito – Testando com Mocks, do Rafael e Lucas, ambos da Caelum). Não gostei muito da palestra, que me pareceu mais um estudo sobre “Clean Code” (como refatorar, injeção de dependências, etc) ao invés de mock, e não me adicionou nada, realmente (por sinal, tenho um sério problema nos testes com mocks: eu sempre acho que meus testes com mocks não estão testando, efetivamente, nada. Se alguém souber como resolver isso e puder entrar em contato comigo, eu agradeceria imensamente).

Logo após, eu vi o Workshop Brasileiro de Métodos Ágeis pois ia apresentar a implantação de Scrum em meu trabalho, e acabei vendo mais palestras – vi o XP Tracking Tool, uma ferramenta que achei absurdamente burocrática e nada ágil (além disso, eu sempre sinto que usar essas ferramentas engessam a metodologia, e uma metodologia ágil pode ser tudo, menos engessada. Por exemplo, o XP Tracking Tool exige que cada tarefa esteja minuciosamente alocada para um par…), logo depois vi a “Realidade numa Fábrica de Software Usando Scrum”, no qual eles apresentaram como fizeram uma adaptação na ferramenta FireScrum , logo depois foi minha apresentação (que eu particularmente não gostei – achei que eu fiquei muito tempo discorrendo sobre o problema e pouco tempo apresentando realmente a implantação), seguido por implantação de Scrum numa Instituição Pública (semelhante ao meu projeto), um estudo no qual uma instituição optou por usar, em um desenvolvimento, a metodologia Scrum para que fosse possível analisar quais os ganhos e quais as dificuldades (e a maioria indicou “Testes” como maior dificuldade, e o uso de metáforas como maior de todas as dificuldades, mas no geral os resultados foram todos muito positivos – especialmente, o aprendizado). Por fim, eu vi o “Estudo de Scrum no Desenvolvimento Distribuído de Software”, embora na maior parte do tempo eu senti que o pessoal estava fazendo propaganda do software FireScrum (por sinal, outro software que eu senti ser burocrático). Também não gostei da idéia remota do FireScrum, no qual o Scrum Master vira um mediador, habilitando cada pessoa a falar (e desabilitando todas as outras) durante o Scrum Daily-afinal, Scrum é auto-organização, portanto se todos querem falar durante o Scrum Daily, eles mais cedo ou mais tarde perceberão que não estão sendo produtivos nessa reunião (pensando-se numa equipe preocupada e organizada como o Scrum pede). No geral, senti que as pessoas que usaram Scrum e fizeram seus estudos baseados nisso (fora a minha palestra e a seguida à minha, do estudo de caso em uma instituição pública) não possuíam equipes auto-organizadas… o que é uma pena.

Logo após, fui ao Coffee Break (que estava MUITO RUIM, por sinal) e vi a palestra da ThougtWorks (sejamos sinceros, a melhor palestra de patrocinadores que eu já vi), no qual eles apresentaram os projetos de auxílio social que eles têm desenvolvido, todos com tecnologias novíssimas saindo do forno, para nós que queremos trabalhar com coisas legais que não vamos, jamais, conseguir convencer nossos chefes a usar. Em seguida (e com muita dor de cabeça, portanto tinha definido que seria a última palestra que eu veria) fui ver a palestra do Felipe, sobre Kanban. Foi outra palestra que eu achei muito ruim-a apresentação de Kanban até me pareceu interessante (processo feito pela Toyota, e isso me deixou com um pé atrás-tenho acompanhado a idéia “lean” por trás da Toyota, e me parece muito mais marketing do que “lean” de verdade, além disso já vi um post de estudantes que visitaram o desenvolvimento de software da Toyota e viram que eles usam “waterfall”). O Kanban, no geral, é um processo no qual você define, para cada fase do projeto, um número máximo de tarefas, e à medida que o tempo vai passando você transfere as tarefas para a próxima fase (a vantagem é que a tarefa pode ser mudada desde que não esteja em desenvolvimento), mas a forma como o palestrante apresentou, deixou claro que eles faziam nada mais nada menos do que um “Waterfall” disfarçado (diversas fases do projeto, desde desenvolvimento até testes até deploy, cada fase com seus “especialistas”-a velha linha de montagem de software).

Depois desta palestra, minha dor de cabeça tinha aumentado consideravelmente (é dose ser sensível à luz-aquelas lâmpadas fluorescentes, tão bajuladas pela mídia como “a lâmpada econômica, salvação mundial para todos os nossos problemas” são as piores) e resolvi voltar para o hotel. Em linhas gerais, achei o nível das palestras bem superiores aos que eu já tinha visto, PORÉM (e este é um grande porém) não gostei de como as pessoas têm implantado métodos ágeis, ESPECIALMENTE Scrum. A impressão que dá é que a maioria das pessoas não consegue pensar no velho padrão “KISS”, e PRECISA complicar Scrum a todo custo. Deve ser por isso que a maioria das palestras no qual você realmente vê o espírito ágil são as palestras de XP, porque é uma metodologia (a meu ver) mais rígida e que impõe mais regras. Ao mesmo tempo, eu vejo as coisas de uma forma relativamente diferente: a forma mais ágil de se trabalhar é com poucas regras, e uma equipe que sabe quais práticas são importantes ou não. Achar uma equipe dessas é um trabalho MUITO difícil, mas é possível (e teve gente no Agile que conseguiu-no próximo post, citarei isso). Portanto, se você quer implantar métodos ágeis, especialmente Scrum, compre um livro do Ken Schwaber, LEIA-O para saber o que é Scrum (pois é-Scrum não pede quadros brancos com post-its. Incrível, não?) e DEPOIS que ele estiver implantado, veja o que funciona e o que não funciona. Tente usar práticas do XP para “fechar os buracos”, e estimule a equipe a crescer.

Não adianta relaxar as (ou inventar outras) regras enquanto a equipe não for madura o suficiente. E isso demora, pode demorar meses ou anos. Até lá, faça as pessoas caminharem, mantenha o ritmo, e sinta (não aplique questionários, não pergunte, não faça reuniões – sinta) se elas estão prontas para relaxar as regras ou inventar outras. Se elas não estiverem, seja mediador. É normal que uma equipe inexperiente fale “mas e se a gente não testar tudo?”, ou “mas uma cobertura de código de 50% não é suficiente?”, portanto seja o mediador e saiba dizer “não”. Mas cuidado: a partir do momento que a equipe amadurecer, deixe-a mais em paz. Gerência de pessoas não é inimiga do Scrum (vi uma palestra sobre liderança que falava de nível de maturidade, usando uns quadrantes com as letras Q1, Q2, Q3 e Q4-isto auxiliou muito em certos entendimentos) ou dos métodos ágeis. Dar auto-organização para um time de zeros-à-esquerda que não sabem o que estão fazendo é jogar seu produto no lixo. Um Scrum Master, ou qualquer outro “líder ágil” tem a função de auxiliar as pessoas a adquirirem auto-organização E maturidade. Nada mais, nada menos.