O processo proposto considera o ciclo de vida de Scrum e é composto por sete atividades relacionadas à garantia da qualidade, sendo elas: Planejamento; Apoio; Auditoria de Processo; Auditoria de Produto; Acompanhamento; Apresentação; e Aprendizagem. Estas atividades implementam, respectivamente, as seguintes áreas do modelo proposto: 2.1 Planejamento da Garantia da Qualidade (QAP); 2.2 Apoio ao Time (TEA); 2.3 Avaliação de Processo (PCA); 2.4 Avaliação de Produto (PDA); 2.5 Gestão de Não Conformidade (NCM); 2.6 Avaliação da Satisfação do Cliente (CSA); e 3.2 Gestão de Lições Aprendidas (LLM). Em virtude de combinar Scrum e atividades de garantia da qualidade, o processo foi denominado ScrumQA.
A Figura 6.1 apresenta entre colchetes as atividades de garantia da qualidade, ao longo do ciclo de desenvolvimento de Scrum para uma sprint.
Figura 6.1 – Ciclo de vida de Scrum e atividades de garantia da qualidade
Fonte: Adaptada de Mountain Goat Software (2005)
As atividades do processo podem ser agrupadas em três fases, sendo elas: Definição, que compreende as atividades de Planejamento e Apoio; Avaliação, que envolve Auditoria de Processo, Auditoria de Produto e Acompanhamento; e Percepção, referente à Apresentação e Aprendizagem. Estas fases se aproximam das fases definidas para o ciclo de vida da disciplina Qualidade Ágil de Software (QAS), proposta por Albuquerque (2005), e da metodologia Agile Software Development (ASD), definida em Highsmith (2000). Entretanto, no presente processo as fases possuem foco distinto, além de serem executadas no contexto das práticas da metodologia Scrum e da garantia da qualidade.
As atividades têm início desde o planejamento do projeto (fase de Definição), como recomendado no AgileQA-RM, o que neste caso corresponde à elaboração do Backlog do Produto, a partir das estórias iniciais trazidas pelo Proprietário do Produto. O responsável pela garantia da qualidade (Software Quality Analyst – SQA) participa deste processo inicial de definição do projeto. Nesta ocasião, tem-se a oportunidade de conhecer o projeto, surgir ideias inovadoras, definir os requisitos e qual o valor a ser agregado ao cliente. O SQA deve revisar as estórias identificando sobretudo critérios de aceitação (QA Review), como sugerido por Ghisi e Portela (2013).
Uma vez definido o Backlog do Produto com as correspondentes Sprints, o SQA apoia a equipe no planejamento da Sprint e na especificação da metodologia que será seguida para o
desenvolvimento em si (podendo ser realizado um Kickoff de garantia da qualidade). Se a organização trabalha com a possibilidade de seguir uma metodologia mais tradicional, por exigência do cliente, ou uma metodologia com ciclo mais ágil (como XP), esse é o momento de se definir. Em ambos os casos, é importante refletir sobre as práticas que serão aplicadas ao processo daquele projeto e defini-las de forma explícita, cabendo ao Scrum Master (SM) o registro dessas decisões e a visibilidade delas aos membros da equipe.
As práticas ágeis aplicadas ao processo de desenvolvimento, costumam variar também em organizações que só atuam com desenvolvimento ágil. Elas variam em função do tipo do projeto, conhecimento da equipe sobre o domínio do projeto, disponibilidade e caracterização do proprietário do produto, entre outros fatores. Por exemplo, a prática ágil Programação em Par, prevista em XP, pode ser viável para alguns projetos ágeis, enquanto para outros, em decorrência de aspectos relacionados ao projeto (tecnologia, domínio, requisitos ou conhecimento técnico) pode não ser viável. Durante o planejamento da sprint, o Time verificará as estórias (requisitos) que irão compor o próximo ciclo de desenvolvimento, decompondo-as em tarefas. Sugere-se que o processo tenha sprints com duração de duas a quatro semanas e a equipe tem liberdade para redefinir isso de acordo com o projeto, sendo importante apenas que se deixe explícito quando as atividades deverão ocorrer, como recomendam os modelos de maturidade.
Ao iniciar o ciclo de desenvolvimento da sprint (fase de Avaliação), é importante estabelecer junto ao Quadro de Tarefas, sobretudo em equipes que utilizam quadros em estilo Kanban, tarefas relacionadas à garantia da qualidade, como as auditorias de processo e de produto, com o propósito de prover visibilidade a todos. É interessante que as auditorias causem pouca interferência nas atividades de desenvolvimento do projeto, caso contrário poderão ter um impacto na produtividade da equipe. Entrevistas, por exemplo, podem ser realizadas com os desenvolvedores em horários alternados, evitando a parada total da equipe. Nos casos em que a organização conta com uma equipe dedicada à garantia da qualidade ou que esta equipe seja composta por representantes das equipes de desenvolvimento, as avaliações tendem a ser mais pontuais. Nos casos em que os próprios membros da equipe ágil são responsáveis por garantir a qualidade, elas podem ocorrer de forma mais constante, fazendo parte do dia a dia da equipe.
Após realizar as auditorias, deve-se dar visibilidade à equipe sobre as não conformidades encontradas, promovendo o acompanhamento da resolução das mesmas. Para equipes exclusivamente dedicadas à qualidade, a participação nas reuniões diárias às vezes é dificultada, porque o SQA acompanha simultaneamente mais de um projeto, com reuniões
diárias ocorrendo simultaneamente. Assim, a presença do SQA nas reuniões diárias não é obrigatória. O próprio SQA em conjunto com a equipe pode definir quais os procedimentos para cada projeto. Quando o SQA é parte da equipe de desenvolvimento, a participação nas reuniões é importante, assim como de todos os membros da equipe.
No encerramento da sprint (fase de Percepção), durante a reunião de revisão, o representante de qualidade deve observar se o resultado da sprint, seja ele um release ou um incremento de funcionalidade, está atendendo aos critérios definidos. As não conformidades referentes à qualidade do produto cuja resolução não foi possível durante a sprint devem ser apresentadas (escalonadas) ao nível de gerência apropriado ou ao representante do cliente, cabendo as estes decidirem se aceitam o incremento ou release mesmo ferindo algum critério de aceitação. Caso não aceitem, correções deverão ser providenciadas na próxima sprint. Uma avaliação da satisfação do cliente é sugerida.
As reuniões de retrospectiva representam o momento ideal para discutir desvios que ocorrem constantemente nos projetos. Também é um momento para se levantar lições aprendidas, bem como constituir uma base de conhecimento que será levada ao nível organizacional, com experiências que podem ser aplicadas em outros projetos. A Figura 6.2 apresenta uma visão detalhada do processo e suas fases, destacando as atividades, papéis, práticas e artefatos, os quais são descritos nas seções seguintes.
Figura 6.2 – Detalhamento das atividades do processo de garantia da qualidade ágil