Inspeção e adaptação: a força dos processos ágeis

Comments
daily meeting retroalimentação sprint review
08 September 2008

Até começarmos a utilizar Scrum eu nunca havia entendido direito o mecanismo chamado de inspeção e adaptação. Toda a minha experiência com desenvolvimento de software até então era com utilização de processos cascata em caixinha. Eu chamo de processos em caixinha aqueles processos utilizados em grandes consultorias geralmente mantidos por uma equipe de tamanho razoavel que tem como principal responsabilidade escrever e gerenciar diversos templates de documentos. O interessante é que quase nunca as pessoas sabem porque devem preencher esses documentos e na maioria das vezes nem as pessoas que escrevem os templates sabem pra que eles servem.

Nessa época eu sempre me perguntava se era realmente necessário documentar nos mínimos detalhes tudo que era feito dentro do projeto e, quando eu falo de documentar não me refiro somente a artefatos intimamente ligados com código como especificações e modelos, mas também a extensas planilhas de rastreabilidade, longos emails com cópia pra Deus e o mundo entre outros tipos de documentos que completam essa lista.

No final, esses documentos eram todos utilizados pra poder garantir os selos de ISO e CMM que a consultoria buscava ou já mantinha.

No entanto, nunca nenhum desses milhares de documentos que só enchiam o Source Control ajudou algúem em alguma ocasião de problema. Muito pelo contrário: as vezes o cidadão tomava uma bela chamada porque não mantinha os malditos documentos atualizados. Também pudera, diversos documentos espalhados e sem nenhuma utilidade prática. Quem é que tem paciência de manter atualizado um troço desses?

Em uma dessas empresas que trabalhei, numa determinada época, os desenvolvedores tiveram que estudar a respeito de Six Sigma, pois uma auditoria estava próxima e todos deveriam estar com as respostas prontas na ponta da lingua. Foi ai que eu tive o primeiro contato com o mecanismo que intitula este post. Ai foi só ligar as peças. Todos esses documentos que a equipe gerava deveriam servir como base histórica para consulta a fim de melhorar futuras estimativas e antecipar problemas, ou seja, inspecionar e adaptar!

O problema é que apesar de termos diversos documento e dos mantenedores de processo apostarem suas vidas quando diziam que as metodologias de caixinha utilizavam deste mecanismo, nunca faziamos nada parecido com uma sprint retrospective, por exemplo. Este é o grande ponto falho de modelos cascata. Como tudo é feito de uma vez, fase a fase, quando percebemos que alguma coisa foi mal (geralmente nas últimas semanas de projeto) já é muito tarde pra correr atrás do problema. Tudo o que sobra então é procurar quem culpar.

Inspeção e adaptação é um dos mecanismos mais importantes e úteis que você pode utilizar pra melhorar seu trabalho. E é ai que a força dos processos ágeis está. E não são necessários documentos para isso. Basta comunicação fluente e contínua entre os membros da equipe.

Os processos agéis são a evolução do modelo cascata. No entanto essa retroalimentação do processo é algo que foi deixada de lado.

Modelos ágeis nos forçam a olhar pra trás frequentemente para ver onde erramos e onde acertamos. Dentro do Scrum nós temos pelo menos dois momentos para realizar a inspeção e adaptação: Daily Meeting e Sprint Retrospective. Essa primeira reunião executa este processo de maneira menos formal, mas possibilita que todos os membros do time sincronizem seus trabalhos e evitem cometer erros que outros membros já cometeram. Isso acontece naturalmente na conversa diária de quinze minutos. Já no Sprint Retrospective, que no meu caso acontece de duas em duas semanas, todos estão focados para identificar o que não foi legal e poder corrigir e continuar executando o que estiver dando certo.

Contudo, existe uma coisa que pode prejudicar essa retroalimentação: a incapacidade dos membros do time entenderem que as críticas não são pessoais, mas para críticas as atitudes que levam a falha e ao erro. É importantíssimo que todos no time saibam aceitar quando erraram e procurar melhorar, pois só um time que não deixa de se criticar a cada momento consegue ter pleno sucesso. A crítica é a base para o crescimento.

E funciona porque o processo é executado todo o tempo, e desvios são encontrados quando ainda há tempo de corrigi-los. É o puro exercício do aprendizado contínuo!


<< Eba! Primeira certificação Microsoft!
DDD no Entity Framework>> 
comments powered by Disqus
tucaz

tucaz

.NET Software Developer
About
All Posts
RSS
@tucaz
GitHub