Todos ganhanm 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. Observamos 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.
Conseqüências da separaçãoO 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?
Um problema comumMichael 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 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 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:
• Integrar-se ao time, colaborando na prevenção de possíveis bugs, além de discutir com os desenvolvedores sobre as funcionalidades;
• Validar funcionalmente as histórias de usuários (user stories), baseando-se nas expectativas do usuário e não a simplesmente na totalidade de bugs encontrados;
• Realizar os testes de aceitação do usuário com o Product Owner;
• Descrever os testes de aceitação, a fim de que os desenvolvedores ajudem a automatizá-los;
• Escrever testes automatizados e integrá-los a uma ferramenta de integração contínua;
• Ajudar a definir indicadores de qualidade e assegurar a qualidade do produto.
O que você acha?
Conseqüências da separaçãoO 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?
Um problema comumMichael 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 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 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:
• Integrar-se ao time, colaborando na prevenção de possíveis bugs, além de discutir com os desenvolvedores sobre as funcionalidades;
• Validar funcionalmente as histórias de usuários (user stories), baseando-se nas expectativas do usuário e não a simplesmente na totalidade de bugs encontrados;
• Realizar os testes de aceitação do usuário com o Product Owner;
• Descrever os testes de aceitação, a fim de que os desenvolvedores ajudem a automatizá-los;
• Escrever testes automatizados e integrá-los a uma ferramenta de integração contínua;
• Ajudar a definir indicadores de qualidade e assegurar a qualidade do produto.
O que você acha?
Fonte: www.infoq.com
De: João Celso Romachelli
ResponderExcluirjoaocelsor@uol.com.br
linked in
--------------------
Antonio Carlos:
Conclui mestrado em PDP e a integração de equipes multifuncionais é sem dúvida crítica no processo. A junção de especialistas sem o devido link é um problema crítico. A qualidade só pode ser ratificada com a devida validação desde o projeto e a partir deste em cada etapa do PDP. A função qualidade não deve ser responsabilidade de um departamento como validação (CQ) este deve ser órgão de coordenação entre as áreas e os atributos de projeto devem estar bem definidos, se possível utilizando entre outras a ferramenta QFD. Quando se trata de projetos coordenados dentro de uma logística de montagem a partir de integração de determinada cadeia de suprimentos a responsabilidade de cada fabricante não deve se ater ao seu componente, mas ao conjunto do qual faz parte, somando esforços e dividindo responsabilidades. Acho que o sistema japonês de qualidade total tem a vantagem, mais do que a sistematização de procedimentos especialmente de gestão formal e validação de buscar a cultura do resultado buscando sistematizar a cultura. A economia mundial em crise tem forçado a diminuição do lead time de lançamento de novos produtos e a redução frenética de custos como instrumento de busca de competitividade. O resultado é que mesmo com investimentos crescentes em departamentos de ratificação de qualidade a quantidade de recall têm sido enormes, inclusive com FMEA de alta criticidade, com produtos e equipamentos proporcionando perigo de vida a clientes. Internamente as empresas têm atuado com grandes conflitos internos com pressão de resultados a partir das dificuldades de mercado para lançamento de produtos que na proposta de redução de custos principalmente se encontram cada vez mais perto do risco. "Se a outra empresa faz nós também temos que fazer". De outro lado, o ciclo de vida de produtos é cada vez menor, porque se produz apenas para a qualidade percebida necessária. Vide os projetos de linha branca por exemplo. A prova disto inclusive é o surgimento de mais outra forma de negócio que ganha corpo, ou seja a garantia extendida.
Não sei se o comentário foi válido, mas se não por este motivo aproveito para lhe parabenizar por sua preocupação e contribuição através de seu blog.
Acompanhei também sua paixão pelo Corinthians e lhe envio por isto os duplos Parabéns.
João Celso Romachelli
joaocelsor@uol.com.br