Scrum numa visão gerencial tomando como base o processo de qualidade

Antes de darmos o nosso ponta – pé inicial e entrarmos no mérito do assunto, logo é importante conhecermos esse método ágil. O scrum (o nome é derivado de uma atividade que ocorre durante um jogo de rugby) é um modelo ágil de processo que foi desenvolvido por Jeff Sutherland e por sua equipe no início da década de 1990. Nos últimos anos foi realizado desenvolvimento adicional de métodos scrum por Scwaber e Beedle.

O parágrafo acima elucida sobre a origem da metodologia em questão, mas é necessário saber como funciona essa metodologia. Em primeiro lugar é importante conhecermos os papéis de cada “stakeholder”. Assim, temos o “Product Owner” (P.O.), “Scrum Master” (Líder) e o “Team” (Equipe). Cada qual com funções definidas, mas que ao final todos se ajudam para chegar a um objetivo comum, entregar. O “product owner” é o representante do cliente, dessa forma é ele quem passa as necessidades, aquilo que precisa. O “scrum master” é quem faz contato direto com o P.O. e, dessa forma, escuta e negocia as necessidades do cliente. A equipe é responsável por tornar realidade às solicitações do cliente.

É importante nos aprofundarmos mais sobre esses papéis, pois o dia – a – dia não é mecânico, mas sim dinâmico, com isso se observarmos com mais atenção o líder se torna uma espécie de facilitador, pois ele não deve somente aceitar as necessidades do cliente, mas sim informá – lo que nem tudo é possível, muitas vezes. Por exemplo, se a funcionalidade “x” não for possível de implementar naquela entrega por “n” razões, logo o líder deverá mostrar por “A” mais “B” que aquele não é o momento, ou seja, negociar. Isso se torna um fator que auxilia a equipe, pois é uma forma de não sobrecarregar o time. Por sua vez, na maioria das vezes, a equipe é quem vai alertar o líder de quê tal tarefa não é possível realizar por várias razões. Essa situação é comum, pois o time é quem será responsável pela construção; logo é quem terá noção da dificuldade de determinada tarefa. Dessa forma, com a equipe alertando o líder, este poderá negociar com o cliente de maneira que agrade seu time. Imaginamos que o líder fechou um escopo sem se reunir com sua equipe, logo, quando cada pessoa do time receber suas tarefas, poderão surgir divergências.

Outro assunto relevante são os artefatos que são criados pelo scrum. Apesar de ser uma metodologia ágil, o scrum tem como saída algumas pequenas documentações. Um importante artefato é o “backlog”, este pode ser definido como uma lista de itens, solicitados pelo cliente, que poderá ser feito naquele “Sprint”. Percebemos que na frase anterior não afirmamos que todos os itens entrarão no Sprint, isto por que o líder do time, como já salientado, é contato direto do cliente e tem poder negociação. Com isso colocado podemos abstrair outro artefato, o “Sprint backlog”, ou seja, dentre aqueles itens os que realmente entrarão naquele Sprint, sendo que os remanescentes poderão ser implementados em próximas “sprints”. Com o objetivo de seguir uma lógica, logo, mais a frente, falaremos sobre outro artefato, as histórias.

O scrum é composto de cerimônias (reuniões), que são: “sprint planning meeting”, “daylli scrum”, “sprint  review meeting” e “sprint retrospective”. A primeira define quais as tarefas mais prioritárias do “sprint backlog” e as estratégias que deverão ser tomadas para aquele “sprint”; a segunda é feita diariamente e tem como objetivo saber o que está sendo feito no momento, se tem algum impedimento que funcione como uma barreira na conclusão de certa atividade e o quê será feito até a próxima reunião; quando concluído o “sprint” é feito um “review” do Sprint e é nesse momento que todos deverão estar presentes, pois a “demo” será apresentada ao cliente, dessa forma é apresentado tudo que foi prometido funcionando; por último, a retrospectiva, normalmente, é reunida a equipe junto com o líder para saber o quê foi feito e refutar o quê deverá ser melhorado nas próximas “sprints”.

Como prometemos vamos falar um pouco sobre o artefato histórias. Estas são abstraídas do “sprint backlog”. Cada item que compõe a lista poderá corresponder a uma ou mais histórias, que seria um título ou resumo de uma implementação. As histórias podem ser quebradas em pequenos itens, que são as tarefas. Assim, quando concluídas todas as tarefas, logo temos uma história feita (done!). As histórias podem durar dias, porém as tarefas tem duração menor. A figura a seguir exibe todo funcionamento de scrum, isso servirá para termos uma noção visual de como funciona:

Os casos de testes dentro do scrum se dão desde a concepção. Dentro de uma metodologia ágil uma das filosofias é evitar a ociosidade, ou seja, não ficar parado. Sempre os “stakeholder’s” envolvidos devem ajudar em algo com o intuito de entregar no prazo. Assim, como falamos, o “backlog” dá origem ao “sprint backlog”. Esta lista, formada por um conjunto de itens, é quebrada em histórias. Destas são abstraídos os casos de testes. Estes estão dentro do roteiro de testes, que é um dos artefatos de qualidade.

Dando continuidade aos casos testes, logo é importante detalharmos acerca do roteiro de testes. Este pode ser adaptado à necessidade de cada projeto, mas seus campos podem ser: cenário, passos, prioridade, severidade, resultado esperado, resultado obtido e resultado final (colunas “OK” e “NOK”). O cenário é uma idéia genérica de testes, ou seja, aquilo que será testado; os passos são as etapas que é preciso executar para concluir o caso com sucesso; a prioridade coloca quais testes estão no topo no que tange as necessidades do cliente; a severidade deve ser colocada quando um caso de teste falha, logo podendo ser alta, média ou baixa; resultado esperado é o que esperamos do sistema no que tange a coerência em relação à história atrelada aquele caso ou, sendo mais direto, quando o sistema vai ao encontro daquilo pedido no cenário de testes; o resultado obtido nada mais é do que o que foi exibido pelo sistema após a execução do último passo do caso de teste e, por fim; o resultado final evidencia se o caso passou ou falhou. A gestão desse roteiro pode ser manual ou via ferramenta (veremos sobre ferramentas nos tópicos mais adiante).

Na execução desses casos de testes é importante sabermos quais serão os critérios de entrada, ou seja, qual massa de dados iremos utilizar para realizar a execução. Normalmente, esses critérios de entrada são passados pelo responsável da área que tem contato com cliente ou pessoas envolvidas com o negócio. Outro aspecto importante na execução é o ambiente, este deve estar estável, isolado e idêntico ao de produção (espelho). A estabilidade é fundamental para dar início à execução, pois a instabilidade do ambiente torna ineficaz o ciclo de teste em questão; o ambiente de teste deve ser isolado, isto é, apartado de qualquer outro ambiente, não pode sofrer influências externas e, além disso, deve ser idêntico ao de produção, pois com isso tornamos a execução mais fiel.

Em relação ao “time box” (2 a 4 semanas) de sprint, nesse período já estão incluídas todas as atividades de testes, sendo que para a execução, na maior parte das vezes, é reservado um tempo pequeno para sua conclusão. Dessa forma, é preciso correr, logo toda parte de elaboração de casos e definições devem ser feitas no início do “sprint” e não no final.

A elaboração e execução de casos de testes dentro do método ágil estão atreladas ao tempo e este, muitas vezes, é inimigo da qualidade; por isso o planejamento e a estratégia de testes são importantes, pois com esses dois elementos é possível organizar as idéias e colocar cada atividade no seu tempo. Desta forma evitamos estourar o tempo e sacrificar a qualidade da entrega.