quinta-feira, 26 de janeiro de 2012

Perigos da separação entre o QA e a equipe ágil.

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?


segunda-feira, 9 de janeiro de 2012

Scrum Alliance vai fortalecer certificação CSM



A Scrum Alliance está promovendo mudanças para fortalecer a certificação CSM (Certified ScrumMaster). Agora os candidatos terão que ser aprovados no exame e haverá um programa de desenvolvimento profissional para que os profissionais certificados mantenham a certificação.

Atualmente, a certificação CSM da Scrum Alliance é conferida a indivíduos que participam de cursos com duração de dois dias e completam um exame pró-forma (não há reprovação). O processo de certificação será modificado em 2012 para incluir um exame com possibilidade de reprovação e um novo programa de desenvolvimento profissional (com Professional Development Units - PDUs) será implementado até janeiro de 2013, para que os CSMs mantenham suas certificações. CSMs necessitarão obter PDUs para manter suas certificações, abrindo-se a possibilidade para cursos mais avançados de Scrum.

Em um email para os Certified Scrum Trainers, Carol McEwan, diretora da Scrum Alliance, explica que o novo exame estará disponível a partir de 1 de janeiro de 2012. Para os três primeiros meses do ano, todos os candidatos que completarem o exame serão aprovados. A partir de 1 de abril de 2012, os candidatos a CSM terão 60 dias em que poderão realizar até duas tentativas para passar no exame. Caso o candidato precise realizar o teste por uma terceira vez, terá que pagar uma taxa de 25 dólares.

O exame em si será curto, contendo apenas 25 questões, cobrindo conhecimentos gerais de Agile e Scrum, papéis em Scrum, cerimônias e artefatos do Scrum. O candidato poderá fazer o exame online em qualquer localidade (não haverão centros de teste). Ao final do exame, uma lista com as respostas incorretas será mostrada. 

conteúdo e objetivos de aprendizado do CSM, nos quais o teste é baseado, estão disponíveis para download no site da Scrum Alliance.


Fonte: INFOQ

segunda-feira, 2 de janeiro de 2012

Feliz 2012.

Um 2012 repleto de alegrias e boas oportunidades a todos.
Nesse ano muitos posts e grandes temas.

Aquele abraço e muita saúde.

AC