Introdução

Lembro a primeira vez que tive contato com alguma metodologia ágil, em 2004. Naquele momento, a primeira prática que mais me trouxe resultado foi a integração contínua, mas o XP também falava de uma série de outras coisas. No meu post sobre TDD, relatei as tentativas de incorporar esta prática e o tempo que levou até entender o real benefício dela (no meu caso, fui bem cabeça-dura).

Das práticas mais confusas, a parte de estimativas do XP talvez seja a mais revolucionária. Mudar a idéia que eu já tinha na na época de cronograma, planejamento, levantamento detalhado de requisitos era muito pra mim. Quando eu percebi que a metodologia não mais daria aquela “certeza” de que a coisa aconteceria no prazo, logo conclui que o mercado nunca iria aderir àquilo, pois o modelo de comercialização seria muito complexo de implementar. Mas sempre achei que a XP descreve o que melhor funciona no mundo de software.

7 anos depois

Um bom tempo depois, numa das empresas que trabalhei, houve uma tentativa de implementação de SCRUM. Eu tinha lido muito pouco sobre o assunto, dada a conclusão precipitada que tive sobre a dificuldade de comercialização do SCRUM. Como trabalhava numa empresa que tinha um viés de desenvolvimento de produto (apesar das customizações por muitas vezes fazerem a empresa funcionar como uma consultoria que vendesse projeto a preço fechado), havia uma preocupação com a qualidade e com o acompanhamento dos projetos.

Foi engraçado ver tanta parede com post-it pregado e diversas reuniões, mas não consegui ver o entusiasmo nas pessoas e uma mudança cultural profunda. Depois entendi o que aconteceu. Foi mais uma daquelas situações que um processo é totalmente personalizado pra encaixar na empresa, o processo não funciona e posteriormente a coloca-se a culpa no processo. No Scrum inventaram até um nome pra isso: Scrum, but…

E o cascata, funcionava?

Eu sempre fui um defensor de trabalhar com projetos em fases menores no cascata (entregas menores e mais frequentes) e de levantamento de requisitos exaustivos (meu post, levantamento de requisitos mostra isso) e de fato consegui alguns resultados interessantes, mas minha experiência me mostrava que algumas coisas não iam tão bem assim.

O custo para montar um cronograma completo no início do projeto era enorme. Era de semanas a meses pensando atividade a atividade, quem iria fazer. Não foram poucas as vezes que “desenvolvedores virtuais” aparecerem no cronograma, contando que em algum momento eles seriam contratados, treinados e entrariam no projeto funcionando e jogando.

Sempre que alguma mudança ocorria no meio do projeto (o que acontecia com frequência, porque em desenvolvimento de software, requisitos mudam!) era um esforço enorme pra replanejar.

Numa empresa que trabalhei, percebi uma das maiores falhas do levantamento de requisitos exaustivo no início do projeto. Eu trabalhava para capturar os requisitos, escrevia casos de usos detalhados e os usuários validavam. Quando apresentávamos o software, ficava uma discussão quase contratual, pois o cliente alegava que não era o que ele precisava e o desenvolvedor alegava que era o que estava escrito. O cliente desejava melhorias no que foi entregue, porém, não existia o “espaço” no cronograma para tais melhorias, e voltava a discussão ao cronograma. Os dois estavam certos. Nova mudança, novo replanejamento, o que significava outro ciclo infinito de reuniões para discutir o cronograma, alinhar expectativas.

De fato, foram semanas discutindo cronograma e o que fazer. O tempo de alinhamento versus construção era desproporcional. Perdia-se mais tempo discutindo o que fazer do que de fato fazendo. O resultado final foi uma equipe frustrada, a consequente debandada e a paralisação de uma série de projetos.

Enfim, ágil

Recentemente, após uma mudança de área, passei a trabalhar com a abordagem ágil. Começamos com mais um Scrum But, ou seja, aplicando o Scrum somente na fase de desenvolvimento do projeto, e aos poucos fomos mudando para um modelo de inserir o usuário nas reuniões, nas discussões e estimulá-lo a exercer um papel de product owner.

Confesso que eu comecei meio cético no projeto, remetia ao passado, à brincadeira de mexer post-its e não conseguia entender como isso ia me ajudar a fazer software melhor. Eu recebi um release planning praticamente pronto, e fomos para nosso primeiro sprint planning.

Foi um pouco assustador, um time, pela primeira vez junto, num projeto que poucos tinham contexto discutindo como as coisas seriam feitas. Não conhecíamos o método, não conhecíamos o projeto e fomos com a cara e a coragem. Discutimos as atividades, estimamos (de forma errada, pois não tínhamos as estórias estimadas e sim as atividades). Erramos nas estimativas das primeiras sprints, mas já começávamos a observar as dificuldades. Na retrospectiva, apontamos as dificuldades, melhoramos o processo e assim seguimos.

Oito sprints depois (sprints e 2 semanas), já trabalhamos como um time muito mais integrado, estamos acertando nas estimativas (usamos os dados históricos), estimamos as estórias e o time está bastante satisfeito com o design da aplicação. Estamos fazendo TDD, Integração contínua, pair programming pois conseguimos nos organizar para tal, e apesar de um “Scrum but”, a coisa vem caminhando muito bem. O que de fato mudou?

Aprendizados

Pessoas

Trabalhar em equipe não é uma coisa fácil. As cerimônias de sprint planning, daily meetings e retrospectivas promovem isso. É praticamente impossível chegar ao fim dessas cerimônias sem interagir. Os medos, dificuldades aparecem e a sujeira sai debaixo do tapete.

Inspeção

O Burndown Chart e o Kanban, são ferramentas fantásticas. Elas vão constantemente mostrando ao time o seu progresso. Como foi o time quem deu as estimativas e se comprometeu com a sprint, o incômodo é generalizado. Enfim, o processo promove uma forma de você visualizar o que realmente está acontecendo, ou seja, se o time irá conseguir atingir a meta ou não.

O Kanban, recomendo que seja físico. Ele exerce uma pressão psicológica violenta quando mostra o real andamento do projeto, além do fato de ajudar a definir o foco, ou seja, estar constantemente mostrando o que é prioritário e o que precisa ser feito.

Após essas sprints, adotei o Kanban como ferramenta de planejamento para outras atividades (não relacionadas a desenvolvimento de software). É muito mais fácil visualizar e ajustar prioridades movendo post-its do que num Excel, além do fato que o Kanban é compartilhado e evita aquele tipo de reunião em que a equipe fica batendo papo enquanto uma das pessoas fica digitando no Excel.

Empowerment

O processo do Scrum ajuda a equipe a obter compromissos que pode cumprir e a dar poder para o time trabalhar. Isso automaticamente faz com que o time busque os recursos para ser mais performático.

Daily Meetings

Os daily meetings são muito importantes. Primeira regra é realizá-los dentro do tempo (15 minutos). Os grandes benefícios do daily meeting pra mim estão no alinhamento e no “pega-lazy”. Quando existe um membro do time que não está jogando para o time, o daily meeting rapidamente mostra isso. A pessoa fica enroscada na atividade e não apresenta o impedimento no daily meeting durante, 3, 4, 5 dias. Geralmente no último dia vem com alguma desculpa do porque não conseguiu realizar a atividade.

Peer pressure

No Scrum, não existem adividades com “donos”. O time é dono das atividades, logo, o time atinge o objetivo ou não. Nesse cenário, começa a ocorrer a pressão entre os pares. No cenário que eu citei acima, do daily meeting, o próprio time começa a se mobilizar para expelir o descomprometido do time. Assim como na existência de um problema, o time começa a buscar os mecanismos para resolvê-lo, pois ninguém quer perder a meta.

Líder facilitador

Observamos que num ambiente ágil não cabe a figura tradicional do chefe. Com o time se auto organizando e entendendo seu papel, o líder passa a ser um facilitador. Ele precisa desenvolver grande habilidade para mediar conflitos, buscar recursos e criar condições para o time trabalhar.

Datas?

É interessante ver como a metodologia tradicional de gestão de projetos criou uma cultura de cravar datas na pedra e exercer cobranças até que a atividade saia no prazo (usando a qualidade para pagar o preço). O Scrum, quando transparece as atividades que precisam ser realizadas, o esforço estimado e a velocidade do time, começa a trazer mais ferramentas que ajudam a visualizar se o objetivo será ou não atingido.

Aquelas situações que visualizamos do gerente perguntar o percentual de conclusão da tarefa, e este percentual ser reportado na progressão: 50%, 75%, 90%, 91%, 92%, 93%, 93.5% perdem o sentido. Como disse anteriormente, o Scrum tira a sujeira debaixo do tapete.

O que começa a ficar evidente é que o responsável pelo projeto precisará de fato aprender a negociar prioridade, escopo ou recursos para a realização do projeto, invés de somente exercer cobranças.

Mudanças de escopo

Mudanças de escopo são bem-vindas. No Scrum, a priorização do backlog simplifica a inclusão de novas estórias e repriorização das mesmas, assim como simplifica a medição dos impactos causados pela mudança. Se você ainda tem uma data alvo, e as mudanças não param de acontecer, o Scrum sem dúvida irá ajudá-lo a mostrar as mudanças e repriorizações e também quando estas impedirão a data alvo de serem atingidas.

Exercício constante de valor agregado

O processo, quando começa a sensibilizar os envolvidos do que está acontecendo (transparência) e mostrar o real custo para se entre

Conclusão

Se você tentou implementar o Scrum em seu time e fracassou, certifique-se se você não entortou o processo. Minha experiência com TDD e com Scrum me mostram isso.

Apesar de ainda estar trabalhando com uma variação de Scrum, é muito interessante observar como o jeitão de trabalhar é muito mais alinhado com trabalho em time, o que nos mostra que a soma dos membros do time é muito maior do que a contribuição individual. Transparência também é um valor fortemente promovido pelo processo.

O processo é feito de uma forma que promove a melhoria contínua, o que me faz acreditar que ainda há muito o que aprender e aprimorar, mas os resultados imediatos são evidentes.

O processo obviamente não ensina as pessoas a desenvolver software. É importante se apoiar em outras disciplinas e processos de engenharia de software (como as práticas de XP) para obter bons resultados. Também não é a bala de prata e vai resolver todos os problemas, mas de uma coisa eu não tenho dúvida: o Scrum cria um ambiente muito mais favorável à resolução de problemas, ao trabalho em equipe e ao desenvolvimento de software de qualidade.

Outra coisa muito importante é que cada vez mais processos ágeis como o Scrum e o Lean estão sendo adotados para desenvolvimento de produtos e não só por empresas de software.

Parece que realmente o Scrum veio para ficar. A discussão ainda de qual processo é melhor, waterfall ou Scrum para gestão de projetos (não somente projeto de software) ainda será muito promovida, e até aqui minha opinião é muitos simples: Projetos com alto grau de certeza terão melhores resultados com waterfall. Projetos com alto grau de incerteza terão melhores resultados com ágil.