QA em time de Scrum
Em um time de projetos utilizando a metodologia Scrum, seria um pouco “estranho” perguntar:
Bom, talvez em empresas focadas em desenvolvimento de software ou em empresas de menor porte isso seja uma realidade, onde todos do time tenha suas preferências técnicas e sejam melhores em determinadas áreas que em outras, mas no final das contas todos fazem de tudo um pouco, desde html até codificação de EJBs no backend.
Em empresas cujo a herança seja o tradicional departamento/áreas, como: Qualidade (QA), Administração de Banco de Dados (DBA), Layout, Design, Usabilidade, etc….. fica praticamente impossível de se quebrar este paradigma, que na verdade está muito mais atrelado a vaidade dos departamentos (vaidade não no termo pejorativo, afinal, precisamos de especialistas) do que em quebra de paradigma propriamente dito, especialmente se a empresa for de médio a grande porte, afinal a primeira preocupação de quem não acredita/gosta de desenvolvimento ágil seria de medo, pois o status quo está sendo ameaçado. Claro!
Este post foi originado após uma conversa com um grande amigo meu, Fábio Brandão na noite do dia 01/01/2009, (pois é, viciado que é viciado só melhora após a terceira ou quarta linha de código compilado
) a respeito de alguns problemas com papéis/departamentos X Scrum, vou tratar neste post, um detalhe mais específico a respeito do Papel de QA (Qualidade) em um time de Scrum e as idéias que me perturbam a respeito.
Eu sempre trabalhei em empresas onde existia um time de qualidade verificando o sistema de forma manual ou automática, navegando pelo sistema, algumas vezes com uma planilha com os pontos de atenção, estes são os pontos que não poderia haver nenhuma fala, chamado risco 0 (risco zero), outra planilha com as novas features implementadas que não precisavam ter necessariamente risco 0, e uma terceira planilha com as issues, onde seria devidamente registrados os erros encontrados.
Após o programador (algumas vezes eu) sinalizar no sistema ou face-2-face que o desenvolvimento estava concluído, entrava em campo o pessoal da qualidade, agora lendo o documento que utilizei para desenvolver o sistema, retestando o sistema, testando as novas funcionalidades e apontando os erros, enquanto o programador (…..eu) já estava em um novo caso de uso, esse cara algumas vezes nem se lembrava mais do código do caso de uso passado, estava com foco total no novo caso de uso.
Passado algum tempo, o produto estava todo codificado e com vários bugs, logo, hora de corrigir os bugs.
Aqueles programadores que mal se lembravam o que haviam jantado na noite passada (provavelmente pizza, pois ficou até tarde na empresa, gerando mais algumas linhas de código sem testes) deveriam começar a corrigir os erros que eles mesmos causaram, que foram levantados pelo pessoal de QA. Agora com um documento mais “enxuto” que continham os erros encontrados.
Após a maratona de correções, com alguma sorte, o pessoal de Qualidade não encontrariam os mesmos erros quando executassem os testes novamente.
Pensando em uma abordagem um pouco mais prática, ágil e proporcional aos excelentes técnicos que trabalham com qualidade, a tarefa devesse ser a de garantir a qualidade de produto como um todo, assim como um programador está apto a desenvolver: frontend, backend, testes unitários, integrados, modelagem de tabelas em objetos, QA deveria minimizar os problemas relacionados ao sistema como um todo, por exemplo: erros visuais, problemas técnicos relacionados a código não performático, erros de escrita em banco de dados, arquitetura, e também negócio.
O trabalho estaria terminado, se fossem encontrados erros nestas esferas.
Mas então o trabalho de QA seria apenas de encontrar erros no sistema? Seria aquele primo chato que sempre aparece quando menos se deseja?
O programador receberia com alegria a notícia de que seu código está errado? Ou que o código recém entregue não está performático?
Eu não acredito nisso, definitivamente eu acredito que esta já é uma evolução do “QA em time de QA”, mas acredito que esteja longe de ser uma boa abordagem.
Mas se o problema é dinheiro(falta de), o que fazer então?
Eliminar a qualidade do time?
De forma alguma!
Acredito cegamente que se o time, TODOS do time estiverem motivados, balizados com o que deve e o que não deve ser feito especialmente nas áreas em que não são especialistas o time deve servir de seus próprios QA’s.
Em um ambiente propício, onde existe motivação isso acontece de forma natural, onde um programador dá palpite no código do outro programador, o administrador de dados está disposto a alterar o modelo de dados para melhorar o desenvolvimento, o webdesigner trabalha de forma parceira com o programador para definir o que será retornado no JSON da chamada Ajax, o analista de negócio está ao lado do desenvolvimento alertando para os erros cometidos (ainda em tempo de desenvolvimento)
Em um ambiente como este será que é valido se quer o questionamento sobre o papel de QA em um time de Scrum?
Acho que não, pois todos estão AGINDO de forma a assegurar a qualidade técnica e não técnica da solução que está sendo implementada.
Talvez a pergunta correta desde o início desde post devesse ser:
PS: Utilizei o time de QA apenas para exemplificar, fica a critério do leitor substituir QA, por AD, DBA, Business, ou qualquer outro time que achar interessante.
Qual o papel de XX departamento em um time de Scrum?Afinal, em um time de Scrum o princípio é de que o time seja multidisciplinar, qual seria a dúvida por tanto?
Bom, talvez em empresas focadas em desenvolvimento de software ou em empresas de menor porte isso seja uma realidade, onde todos do time tenha suas preferências técnicas e sejam melhores em determinadas áreas que em outras, mas no final das contas todos fazem de tudo um pouco, desde html até codificação de EJBs no backend.
Em empresas cujo a herança seja o tradicional departamento/áreas, como: Qualidade (QA), Administração de Banco de Dados (DBA), Layout, Design, Usabilidade, etc….. fica praticamente impossível de se quebrar este paradigma, que na verdade está muito mais atrelado a vaidade dos departamentos (vaidade não no termo pejorativo, afinal, precisamos de especialistas) do que em quebra de paradigma propriamente dito, especialmente se a empresa for de médio a grande porte, afinal a primeira preocupação de quem não acredita/gosta de desenvolvimento ágil seria de medo, pois o status quo está sendo ameaçado. Claro!
Este post foi originado após uma conversa com um grande amigo meu, Fábio Brandão na noite do dia 01/01/2009, (pois é, viciado que é viciado só melhora após a terceira ou quarta linha de código compilado
) a respeito de alguns problemas com papéis/departamentos X Scrum, vou tratar neste post, um detalhe mais específico a respeito do Papel de QA (Qualidade) em um time de Scrum e as idéias que me perturbam a respeito.Qualidade em Casa (QA em time de QA)
Fique claro que quando digo: papel de QA estou me referindo ao contexto que disse logo acima, onde existe um departamento de Qualidade e que o time de desenvolvedores não necessariamente faz o trabalho de QA.Eu sempre trabalhei em empresas onde existia um time de qualidade verificando o sistema de forma manual ou automática, navegando pelo sistema, algumas vezes com uma planilha com os pontos de atenção, estes são os pontos que não poderia haver nenhuma fala, chamado risco 0 (risco zero), outra planilha com as novas features implementadas que não precisavam ter necessariamente risco 0, e uma terceira planilha com as issues, onde seria devidamente registrados os erros encontrados.
Após o programador (algumas vezes eu) sinalizar no sistema ou face-2-face que o desenvolvimento estava concluído, entrava em campo o pessoal da qualidade, agora lendo o documento que utilizei para desenvolver o sistema, retestando o sistema, testando as novas funcionalidades e apontando os erros, enquanto o programador (…..eu) já estava em um novo caso de uso, esse cara algumas vezes nem se lembrava mais do código do caso de uso passado, estava com foco total no novo caso de uso.
Passado algum tempo, o produto estava todo codificado e com vários bugs, logo, hora de corrigir os bugs.
Aqueles programadores que mal se lembravam o que haviam jantado na noite passada (provavelmente pizza, pois ficou até tarde na empresa, gerando mais algumas linhas de código sem testes) deveriam começar a corrigir os erros que eles mesmos causaram, que foram levantados pelo pessoal de QA. Agora com um documento mais “enxuto” que continham os erros encontrados.
Após a maratona de correções, com alguma sorte, o pessoal de Qualidade não encontrariam os mesmos erros quando executassem os testes novamente.
Qualidade em time de Scrum?
Acho que em um time de scrum a abordagem de QA em time de QA é totalmente fora de propósito, afinal a equipe de qualidade estaria fazendo apenas o papel de apurador de erros, seria realmente este o propósito de um time de qualidade? Encontrar erros?Pensando em uma abordagem um pouco mais prática, ágil e proporcional aos excelentes técnicos que trabalham com qualidade, a tarefa devesse ser a de garantir a qualidade de produto como um todo, assim como um programador está apto a desenvolver: frontend, backend, testes unitários, integrados, modelagem de tabelas em objetos, QA deveria minimizar os problemas relacionados ao sistema como um todo, por exemplo: erros visuais, problemas técnicos relacionados a código não performático, erros de escrita em banco de dados, arquitetura, e também negócio.
O trabalho estaria terminado, se fossem encontrados erros nestas esferas.
Mas então o trabalho de QA seria apenas de encontrar erros no sistema? Seria aquele primo chato que sempre aparece quando menos se deseja?
O programador receberia com alegria a notícia de que seu código está errado? Ou que o código recém entregue não está performático?
Eu não acredito nisso, definitivamente eu acredito que esta já é uma evolução do “QA em time de QA”, mas acredito que esteja longe de ser uma boa abordagem.
Qualidade!
Como descrito acima, QA deveria ser um supertime, com:- Arquitetos da informação, para assegurar de que os textos estão colocados corretamente;
- Webdesigners e Webmasters, para assegurar que o layout esteja de acordo como foi desenhado e implementado por eles e requisitado pelo Product Owner.
- Arquitetos de sistema, para assegurar que a aplicação esteja performática e que todas as regras corporativa para acesso a legados estejam sendo cumpridas.
- Programadores: para assegurar que o código está bem feito, com cobertura de X% de testes unitários, funcionais
- Analistas de negócio: para assegurar que o que foi pedido pelo Product Owner esteja de acordo com o que está sendo codificado.
- Administradores de Dados: assegurando que o modelo desenhado esteja coerente com os padrões da empresa e esteja normalizado
- Administradores de Banco de Dados
Mas se o problema é dinheiro(falta de), o que fazer então?
Eliminar a qualidade do time?
De forma alguma!
Acredito cegamente que se o time, TODOS do time estiverem motivados, balizados com o que deve e o que não deve ser feito especialmente nas áreas em que não são especialistas o time deve servir de seus próprios QA’s.
Em um ambiente propício, onde existe motivação isso acontece de forma natural, onde um programador dá palpite no código do outro programador, o administrador de dados está disposto a alterar o modelo de dados para melhorar o desenvolvimento, o webdesigner trabalha de forma parceira com o programador para definir o que será retornado no JSON da chamada Ajax, o analista de negócio está ao lado do desenvolvimento alertando para os erros cometidos (ainda em tempo de desenvolvimento)
Em um ambiente como este será que é valido se quer o questionamento sobre o papel de QA em um time de Scrum?
Acho que não, pois todos estão AGINDO de forma a assegurar a qualidade técnica e não técnica da solução que está sendo implementada.
Talvez a pergunta correta desde o início desde post devesse ser:
Como motivar um time?Isto será uma conversa para outro post, mas acho que resposta de forma bem curta seria…………….. Paixão!
PS: Utilizei o time de QA apenas para exemplificar, fica a critério do leitor substituir QA, por AD, DBA, Business, ou qualquer outro time que achar interessante.
Rafael Umgeher Taborda
8 May 09 at 2:08 pm