Disseminando conhecimento e inovação em desenvolvimento de software corporativo
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Postado por Paulo Rebelo em 29 Abr 2011
Todos ganham quando há uma equipe ágil focada no produto e com o mesmo compromisso de entrega de valor de negócio. Ganha principalmente o cliente. Um dos piores males ocorre, entretanto, quando um dos membros não faz parte integral do time. Observei muitas situações em que o analista de qualidade estava em outra área, separada da equipe de desenvolvimento. E isso acontecia, perigosamente, em muitos projetos.
O problema começava na divisão por área do conhecimento. Outra questão era a aparente separação hierárquica: o analista de qualidade se preocupava mais em aferir e cobrar um processo de qualidade em si do que propriamente entregar, em conjunto com a equipe, um produto de qualidade que atendesse ao cliente.
Da forma que estava sendo feito, o processo de qualidade já interferia por si só em um dos princípios do manifesto ágil, pois desconsiderava as pessoas e a comunicação aberta. Focava, em vez disso, em impor um conjunto de regras e padrões burocráticos, que impediam o progresso produtivo e incremental. Já cheguei a presenciar o analista de qualidade dizendo que o contrato de QA (Quality Assurance) precisava ser seguido, mesmo que isso acontecesse em detrimento de toda a agilidade que a equipe estava realizando.
Essa situação tornou o projeto lento, muito formal e pernicioso para a equipe, causando conflitos incessantes entre o analista de qualidade e todos os demais. E quando se questionava o trabalho do profissional QA, ele respondia apenas que devia seguir o fluxo e o processo adotado.
Onde existem múltiplos "departamentos" trabalhando com objetivos antagônicos, o resultado é uma guerra entre essas divisões, com cada parte buscando ter mais poder que a outra, infelizmente.
A situação se agravava quando o analista de qualidade cobrava do ScrumMaster quanto ao posicionamento dos bugs da aplicação. Chegava a formalizar toda a comunicação por email, com a intenção de se "blindar" de eventuais problemas que surgissem no projeto.
Não é mais saudável, ágil e produtivo termos uma equipe única em prol de um objetivo comum?
Michael Azoff tratou desse assunto em sua revisão dos últimos 10 anos do Agile, onde abordou o que evoluiu e regrediu neste período. Parece, portanto, que não é somente aqui no Brasil que ocorre o problema, e que existem de fato "gargalos" gerados pela separação dos times de QA e de desenvolvimento.
Ron Jeffries também aborda o assunto em seu artigo sobre Quality Assurance, no qual responde a questões de um gerente da área de qualidade sobre como o QA se "encaixa" no Extreme Programming. Jeffries recomenda que o o QA se concentre no planejamento e na execução de testes funcionais, apoiando o cliente na homologação das entregas do produto final. Sugere ainda que o gerente de qualidade realize um treinamento de XP e se integre ao time. Com isso, o time fica com um objetivo único: entregar um software que funcione e que satisfaça o cliente.
Enfim, em um cenário ágil, o analista de qualidade poderia cumprir com as seguintes responsabilidades:
O que você acha?
Paulo Rebelo (@phfrebelo) trabalha em desenvolvimento de software há mais de 18 anos. Começou a carreira profissional com Mainframe IBM/3270, passando por várias tecnologias e linguagens (Assembler, Cobol, C/C++, Java, Ruby), e agora concentra-se no desenvolvimento para internet. Nos últimos cinco anos, vem se dedicando à gestão de projetos e pessoas, onde atuou na Sodexo como Coordenador Internet e ScrumMaster no UOL. Atualmente, trabalha na Abril como Gerente de Projetos, com foco em metodologias ágeis como Scrum, XP, Lean e Kanban. É Mestre em Engenharia de Software pelo IPT e Licenciado e Bacharel em Matemática.
Eu vejo que a disciplina de QA tem tomado um rumo diferente dos seus reais objetivos. Não pretendo abrir nenhuma polêmica com o modelo CMMi, mas muitas empresas acreditam que apenas tendo uma certificação qualquer que seja o seu nível, já garante qualidade no desenvolvimento.
Você colocou muito bem o papel do analista de qualidade em um cenário ágil. Eu iria mais além; esse papel deve ser aplicado até mesmo em equipes "não-ágeis".
Integração Contínua, por exemplo, é uma prática que pode, e deve, ser adotada em qualquer processo de desenvolvimento. Inclusive, como forma de automatizar tarefas de revisão de código praticadas no CMMi; vide ferramentas como PMD e Checkstyle.
Para as empresas, não basta apenas dizer que tem QA ou que atende algum modelo de qualidade; é preciso por em prática, colaborando na prevenção de bugs, validando funcionalmente as histórias de usuários (ou casos de uso), realizar e descrevendo testes, acompanhando relatórios de ferramentas de integração contínua, etc.
Penso o seguinte:
Não existe entrega de valor para o cliente se produto não tem qualidade. O QA tem fazer parte da equipe, pois, não tem como separar qualidade do produto. A distância de mentalidade e objetivos entre Analista de Qualidade e a equipe ágil aumenta as chances de conflito.
Acho que ponto a ser trabalhado é a "integração da equipe", pois, todos as pessoas devem ter um único objetivo, trabalhar juntas para entregar valor ao cliente.
Coaching e/ou mentoring podem ajudar na solução de conflitos.
Os papéis de Desenvolvedor e de Analista de teste foram distanciados no modelo tradicional de desenvolvimento e, agora, as práticas ágeis buscam aproximá-los em prol de software em funcionamento.
Apresentamos aqui os principais conceitos vistos no workshop de Ash Maurya sobre a aplicabilidade prática do Lean Canvas
Na quarta parte da série sobre equipes de alto desempenho veremos como identificar os acontecimentos em uma equipe que sai da fase de Conflitos e entra na fase de Normatização.
Ash Maurya, um dos maiores especialistas em Lean Startup falou com exclusividade ao InfoQ Brasil sobre a aplicabilidade do Lean e como seus conceitos contribuem com empreendimentos e equipes ágeis.
Conheça um guia prático, proposto por Esther Derby, para diagnosticar a eficácia de equipes, usando mapas mentais como referência, além de entender o perigo de equipes disfuncionais,
Esther Derby aposta os riscos em se transformar estimativas em um cronograma; e Allan Kelly apresenta pesquisas indicando ser impossível prever o tempo para se realizar uma atividade.
Martin Odersky, criador do Scala, discute o futuro da linguagem, trata da questão de quebra de compatibilidade binária e faz comparações com F# e Java.
Anil Gaur da Oracle fala sobre o cronograma para o Java EE 7, APIs para computação em nuvem, ferramentas e suporte a PaaS.
2 comentários
Acompanhar Discussão Responder