Se você não entendeu a piada com o título clique aqui.
Então tivemos o Scrum Gathering Brazil esta semana. Infelizmente eu não estava por lá mas acompanhei bastante a movimentação via twitter e conversando com amigos nos instant messengers da vida. Agora estou lendo a cobertura dos blogs.
A que mais me chamou atenção –e eu já previa isso tendo conversado com o autor durante a evento- foi a do Rodrigo Yoshima. Entre diversos comentários sobre apresentações que deixaram pontos de interrogação e exclamação na cabeça do autor eu destaco:
Usando Scrum com o Visual Studio Team Systeam - Fabio Camara [...]
- Ele acha incrível como a Regra de Pareto se aplica a projetos de software: 20% dos desenvolvedores fazem 80% do trabalho.
- Ele se questiona se vale a pena o programador testar. Para ele, o programador só deve verificar e um testador, que é mais barato, testa efetivamente. Na mesma linha ele questiona TDD para projetos que ele denomina “time-driven”. Não achei referências para esse termo, mas ele classifica como os projetos onde tudo é para ontem. Nesses projetos não há tempo para pensar em testes unitários.
- A maior divergência porém, é o papel do ScrumMaster na visão do Fabio Camara. Para ele o ScrumMaster Monta o Plano, Distribui Atividades, Obtém Feedback e Refaz o Plano. Ele deixou claro na palestra que essa é a opinião dele. Quando questionei a respeito da auto-organização do Scrum ele disse que também não acredita na auto-organização.
E o grande sumario disso (desculpe o hotlink, Rodrigo!):
Este é o tipo de coisa sobre a qual eu falei aqui, aqui, aqui, aqui e, principalmente, aqui.
Quanto mais as metodologias ágeis ganham o mainstream mas nós vamos ver este tipo de coisa. O fato de que Scrum possui certificações e selinhos só piora tudo já que dá credibilidade imediata a uma informação errada no seu princípio básico.
Isso me lembrou alguns casos. Uma vez uma amiga foi para um cliente que havia implantado Scrum há pouco tempo. Todos fizeram o cursinho e tinham selinho de CSM. O diretor do programa tem o selinho melhor, CSP, e estava no caminho do seu CST, o selinho máximo.
Ela é uma analista de negócios e quando chegou foi levada imediatamente para uma sala com todos os stakeholders e desenvolvedores. Eles olharam seriamente para ela e disseram algo como:
- Precisamos muito da sua ajuda. Precisamos de aconselhamento em como deixar a informação visível. Agora com Scrum nós precisamos deixar claro o que está acontecendo aqui no desenvolvimento para todos.
- Uh. Ok, então acho que vocês podem começar me explicando o processo de negócios, acho que posso ficar algumas horas vendo como vocês trabalham e como o sistema é usado. Depois queria conversar um pouco com o time de desenvolvimento, podemos fazer uma mini-retrospectiva e uma futurospectiva para tentar entender porque a comunicação é um problema. A partir daí nós traçamos um plano, pode ser necessário conseguirmos coaches técnicos e, talvez, um gerente de projetos com experiência em métodos ágeis…
- Er… ahm. Ta. Mas… não era bem isso que estávamos pensando. Sabe, nós já fizemos tudo isso. Tivemos uma grande reunião, acertamos os fluxos de trabalho e tal.
- É? Mas… pelo que eu vi conversando com pessoas durante as últimas semanas vocês ainda têm problemas, os desenvolvedores estão reclamando de que tudo muda o tempo todo, o pessoal de negócios reclama que vocês estão quinze meses atrasados…
- Sim, sim, sabemos disso tudo. Mas nós sabemos que com o Scrum eventualmente essas coisas vão se resolver, não estamos preocupados. O que nós não conseguimos entender é como otimizar a radiação de informações utilizando kanbans distribuído pelo chão de fábrica.
- “Otimizar..kanban…” peraí, vocês querem que eu ajude você a decidir onde colocar seu story wall?
- É, acho que você pode colocar deste jeito…
- Você tem alguma idéia do quanto vocês estão pagando por hora pra eu estar aqui?!?
Eventualmente o cliente percebeu que onde posicionar o story wall era o menor dos seus problemas. Um dos principais problemas deles é que estavam fazendo exatamente o que o Fabio Câmara sugeriu: tinham um Scrum Master que criava, gerenciava e ajustava o plano. Os desenvolvedores estavam sempre atrasados porque eles nem sabiam qual era o plano, apenas sabiam das atividades. Discussão típica:
- Estamos atrasados!
- Você está atrasado, meu time está em dia.
- Como assim?
- Eu falei que precisava de dois dias para colocar o back-end em produção, bom estamos terminando agora, com o mínimo de atraso.
- Mas o front-end não está pronto, qual a diferença?
- Isso é com o time do Beltrano. Nós aqui estamos certos. Sprint goal atingido, vamos para o bar.
Ou, na “obtenção de feedback”:
- Ok, esta tarefa aqui está demorando muito então vamos acabar entregando aquela ali atrasada.
- Você está dizendo que o projeto vai atrasar?!
- Não, não. Você me entendeu mal. Meu time está OK, nós vamos entregar em dia, não se preocupa não.
[dois dias depois]
- E aí, tudo certo?
- Tudo.
- Aquela tarefa ali… está meio atrasada, não?
- Não, não. Veja bem, ela já vai estar pronta… já já.
[final do sprint]
- Então, como estamos?
- Bom. Aquela tarefa ali atrasou. Isso fez com que o Fulano ficasse preso ajudando o Beltrano e não fizesse o trabalho dele. Mas não tem tanto problema porque ele não ia conseguir fazer o trabalho dele mesmo já que esta tarefa depende da outra.
- Então… o que vocês estão entregando hoje?
- O Domain Model, todas as classes no lugar. Ta pronto. Só falta testar.
A solução neste caso específico teve que ser meio drástica. O que queríamos fazer era remover todos os Scrum Master e devolvê-los a sua posição original (geralmente gerente de projetos e desenvolvedores sênior) mas vimos que isso ia causar problemas políticos demais. A solução mais viável foi manter os Scrum Masters -pelo menos o título- e usarmos “Gerentes de Iteração”. Iteration Manager é o termo que usamos para um papel equivalente ao Scrum Master –gerente de projetos é outra coisa- e estes caras atuavam como lideres dos times e gerentes de iteração.
Os gerentes de projeto -ainda chamados Scrum Masters por razões históricas- tinham ainda o “plano”, algo em extremo alto nível que dizia que considerando a situação atual de escopo e velocidade a funcionalidade X vai ser entregue dia Y, a Z dia W e assim por diante. Arrastar barrinhas no Microsoft Project não mudava o plano, ele era apenas um retrato da situação real e para mudar a situação real você tem que resolver seus impedimentos. Sem truques.
Outro problema foi o tal do testes. Nós sabemos que desenvolvedores profissionais testam mas neste cliente eles compartilhavam da idéia do Fábio de que testar é coisa pra recurso barato. Resultado? Os recursos caros ficavam dias produzindo código caro que não funcionava. Apos um sprint inteiro de código caro produzido se tinha que reescrever boa parte. Como é aquela história de “o barato sai caro mesmo”?
Nada disso, qualidade é algo muito caro para ser produzido por “recursos baratos”. Como o Jason Yip diz: controle qualidade é responsabilidade do time todo -ele sugere o termo “Inspetor de Qualidade” para o que normalmente chamamos de QA- e para isso os desenvolvedores precisam entrar na dança.
Sendo extremamente sincero, eu não consigo entender como um desenvolvedor experiente assume que uma metodologia ágil consiga funcionar sem testes. Você não tem sequer uma especificação dizendo o que vai construir!
A única maneira que eu vejo disso meio que funcionar é se ao invés de uma metodologia ágil você utilizar apenas mini-waterfalls a cada sprint. Fica um tempo especificando o que vai ser feito, um tempo fazendo, um tempo testando. Enxágüe e repita. Mas isto não é uma metodologia ágil, o ciclo de feedback é muito longo!
E este foi só um dos múltiplos exemplos que tivemos nos últimos dois anos. É preciso ter cuidado, muito cuidado. Scrum vêm crescendo muito como hype e é um framework, cheio de lacunas por definição. Quando alguém com bastante bagagem vê as lacunas no Scrum ele logo assume que basta enfiar o que já se usa em desenvolvimento “tradicional” e acaba criando um híbrido de modelos quase sempre extremante ineficiente.
Scrum não diz como desenvolver software? Sem problemas, nós sabemos fazer isso: escreve uma especificação no wiki, codifica, testa. Scrum não diz como compartilhar conhecimento sobre o código? Sem problemas, nós sabemos como fazer isso: antes do código ser enviado para o SCM ele tem que ser aprovado por um membro mais sênior do time. Scrum não diz como integrar código? Sem problemas: cada um cria seu branch e nós integramos no final do Sprint.
É bom notar que mesmo com as lacunas citadas o framework tem princípios bem definidos. A opinião de que o Scrum Master é o dono do plano vai de encontro com o que o Scrum prega. Pode ser a opinião de alguém experiente, você pode achar que faz sentido… só não pode dizer que isso é Scrum.
E se você soma isso ao fato de que não é preciso muita coisa para ter um certificado em Scrum o problema toma proporções gigantescas. Scrum em si não diz que é errado, digamos, escrever um documento de caso de uso de vinte páginas para cada item de backlog. E se, ainda por cima, a pessoa que sugeriu isso ainda possui um selinho dizendo que ele sabe Scrum?
Se você não tem um time experiente em metodologias ágeis então comece seguindo todas as práticas de XP. Após ganhar experiência decida o que funciona e o que não funciona –mas teste todas antes, e por um tempo considerável.
Não comece apenas por Scrum. Como falei antes você vai encontrar muitos buracos e sempre a solução mais fácil vai ser fazer o que já se fazia antes.
Repetindo um tema freqüente neste blog: eu posso programar FORTRAN em qualquer linguagem. Eu posso gerenciar waterfall e/ou comando-e-controle em qualquer metodologia.
