No Scrum, todos da equipe são responsáveis por uma Sprint. Será? O que acontece quando a equipe de testes é chutada para fora da equipe? O que acontece se a equipe de desenvolvimento achar que testes não é necessário dentro da Sprint "deles", considerando-os como uma "Sprint paralela" ao desenvolvimento? Eu vivi isso e vou te contar neste post.
Toda mudança possui vários altos e baixos, e passamos por basicamente 4 estágios:
- 1º você rejeita
- 2º você tenta um boicote à mudança
- 3º você aceita
- 4º você coopera com a mudança
Quando começou a implantação da metodologia ágil, no meu local de trabalho, não foi diferente. Mas eu, como parte da equipe de teste, via algumas interpretações corretas e outras absurdas da metodologia. Contextualizando a ordem dos fatos:
- A empresa sentiu necessidades de mudança, pois viu que outras empresas levam metade do tempo para fazer grandes entregas (possivelmente com um grande incentivo do novo diretor de desenvolvimento);
- Começou um projeto piloto para implantação da metodologia;
- Adquiriram ferramentas específicas para auxiliar no gerenciamento de Sprints;
- Liberaram um documento com a política de funcionamento do processo ágil na empresa (mais parecia um cópia e cola de um site cheio de erros de português e loops no processo);
- Começou uma onda de mudanças, onde algumas equipes foram avisadas que a partir de X data poderiam migrar seus projetos para a ferramenta e trabalhar com o processo em ágil.
Se vocês ficarem bem atentos, verão várias inconsistências:
- A empresa acreditou que as pessoas chaves do projeto sabiam como funciona a metodologia ágil e um simples documento seria o bastante para aplicar ágil nos projetos;
- Migrar projetos do modo cascata pro ágil? Sem coordenação ou acompanhamento de um gerente de projetos?
- Fizeram do trabalho de faculdade de alguém um documentos de processo de funcionamento ágil? É isso mesmo?
Enfim, o problema estava claro pra toda a equipe de testes que teve de se adaptar. A adaptação não é um problema! A equipe de testes geralmente é bastante flexível, pois estamos acostumados com mudanças no processo de trabalho e mudanças de projetos de trabalho. O problema é que nem todos os analistas de testes/testadores dos produtos sabiam como se impor e alguns projetos viraram um caos.
No modo tradicional de desenvolvimento, o cascata, as equipes eram acostumadas a iniciar testes só depois que a implementação está pronta. Na metodologia ágil isso deixa de existir. A equipe de testes está testando partes antes de estarem concluídas, está dando ideias de situações que os programadores devem prever durante a implementação, pois a equipe de testes conhece o negócio e antecipa a ação que o cliente usará.
Eu vi uma equipe criar Sprints sem atividade de testes. Os testadores estavam num tipo de "sprint paralela" e atrasada do projeto. Você não leu errado, o sentimento era de total descaso com testes! Assim que a equipe de desenvolvimento acabava toda a implementação envolvida de uma Story, a mesma era encerrada. A Sprint acabava e uma nova Sprint era planejada! E testes? Os testadores precisavam buscar no "limbo do projeto" as Storys encerradas para então fazer um teste integrado. Não recebiam nenhum alerta de encerramento da Story e um controle paralelo era necessário. O desenvolvimento levando os créditos de que a Sprint foi um sucesso, encerrada no tempo planejado. SEM TESTES é só um detalhe? Ao meu ver, a Sprint só é um sucesso quando a equipe de testes dá seu aval de "Testes OK".
Isso parece um belo boicote à mudança. Jeff Sutherland, do livro "Scrum - a arte de fazer o dobro de trabalho em metade do tempo", disse que todos na equipe deveriam ser responsáveis pelas Sprints. Eu via que isso não estava acontecendo naquela equipe. O desenvolvimento não sentia que testes deveriam fazer parte da equipe. Para piorar, a pessoa que deveria apoiar e coordenar os trabalhos em testes ouviu todo esse problema e ficou por isso mesmo.
Recebi um retorno da não conformidade que abri, dizendo que era uma situação grave e deveria ser combatida. Quando a bagunça da equipe em questão acabar eu apresento a solução aqui no
blog. Vale lembrar que esta é a única equipe que vi deixar testes de lado enquanto usavam metodologia ágil (não, eles não tem testes unitários para garantir coisa alguma). Mais alguém está achando que a metodologia usada por essa equipe mais parece
GO HORSE?
Resumo da história: O pessoal de testes precisa se impor. Precisam mostrar que testes é importante sim dentro da Sprint e brigar por isso. O modo tradicional de testes, de testar somente quando a entrega já está pronta, não funciona na metodologia ágil. Testes unitários não garantem integração de produtos. Os testes de integração DEVEM entrar na Sprint! Cadê a responsabilidade da equipe toda em fazer uma entrega rápida e sem impactos para clientes?
Quando terminamos a implementação de uma feature, no universo ágil, não podemos deixar de falar em critérios de aceite.
