Scrum: uma visão prática do framework (Ferramentas: Visual Studio e Test Manager

2013)

Roberto Passani GomesAnalista de Testes – BNY Mellon

Sobre o Scrum

O Scrum é uma abordagem ágil que prima pela otimização e objetividade no processo e em todas suas etapas, costuma minimizar burocracias, documentação e módulos em relação a outros processos (como RUP), e tudo é baseado nas reuniões do processo.

Entre uma reunião e outra o trabalho é realizado, as reuniões são importantes ao ponto de algumas empresas não usarem nenhuma documentação escrita, ou seja, fazem Sprints semanais e reuniões às segundas e sextas, de Planning e Review respectivamente, onde fazem todo o tracking das atividades e desenvolvimento do produto.

Estrutura do Sprint

Para a apresentação usaremos o modelo de um Sprint de 10 dias úteis, ou aproximadamente 14 dias corridos, sendo o Planning no primeiro dia e o Review no último. Após o Review ocorre a Retrospectiva e no decorrer do Sprint o Pré-planning. Diariamente devem ocorrer as reuniões Diárias (Daily Meetings). Todas essas etapas serão detalhadas durante a apresentação.

Apresentação do Ambiente

A equipe na qual este artigo foi baseado é constituída de Product Owner, Scrum Master (que usualmente também acumula funções de Coordenador), Analista de Testes e desenvolvedores (algumas empresas usam uma métrica de até quatro desenvolvedores para cada analista de testes). Mas, equipes de projeto podem também ter: Designer, Analista de UX (User Experience) e outros.

Além disso, temos equipes externas que dão suporte e ambiente aos projetos, como: analistas de produto, setor comercial e infraestrutura. Conforme será detalhado mais a frente na apresentação, é função do Scrum Master se comunicar com outras equipes e remover riscos; questões de infraestrutura, backend e serviço, portanto retirar quaisquer bloqueios das histórias antes que elas entrem em qualquer Sprint. Todos trabalhando para atender as demandas vindas do Product Owner.

Primeiros passos

O primeiro passo para desenvolvimento de um sistema no framework Scrum, segundo o formato aqui apresentado, seria a reunião de pre-planning, onde é detalhado o objetivo principal do sistema, isto é, aquilo que ele deseja atingir (seu core), portanto nessa primeira etapa vamos começar a rascunhar as histórias que serão estudadas e iniciarão o desenvolvimento, e nelas são inseridos os critérios de aceite ou entrega.

Estes são basicamente os requisitos do sistema, o detalhamento de todas as funcionalidades, desde as mais simples as principais.

Criação de HistóriasO título das histórias devem ser escritos na perspectiva de quem desejam atingir,

por exemplo: “Eu, como cliente, quero que o aplicativo faça…” ou “Eu, como área de negócios da empresa, quero inserir a logomarca de nosso patrocinador…”, ou ainda, “Eu, como Product Owner, quero ver uma mensagem de erro quando o usuário executar uma ação indevida…”. Isso facilita a análise de quem deve aprovar a história.

Caso exista alguém além do Product Owner para aprovar alguma história, então o Scrum Master fica já ciente de que deve convidar excepcionalmente aos ritos do Sprint essa pessoa que não é um participante direto das atividades, como Planning e Review, se há alguém externo à equipe que deseja inserir histórias ou acrescentar algo ao sistema, então essa pessoa já pode ser convidada às reuniões com o máximo de antecedência.

A equipe de desenvolvimento deve definir todo o backend (serviços e servidores) necessário, e tudo que será preciso para a implementação do sistema, para que o Scrum Master possa solicitar essa infraestrutura ao setor responsável da empresa.

Sobre o Pré-Projeto

Uma vez estruturado o backend de serviços, a equipe pode começar a implementação do software, e para priorizar as histórias e analisar quais farão parte de um primeiro sprint realiza-se uma primeira reunião de planning, onde as histórias iniciais são colocadas no primeiro sprint e priorizadas na ordem decrescente dentro dele.

Primeiramente colocam-se todas as histórias que precisam ser feitas e depois elas são priorizadas. Em seguida, pontua-se cada história de acordo com o critério utilizado no projeto (Fibonacci, por horas ou outro), daí podemos analisar se ainda é possível inserir alguma história, se a meta de pontos não estiver sido atingida, ou se alguma história deverá sair se a meta estiver sido ultrapassada. Caso a meta tenha sido ultrapassada e a quantidade de pontos das histórias for maior do que os pontos ultrapassados, então a última história, segundo os critérios de priorização, poderá ser dividida em duas.

Cuidados com a montagem do Sprint

Um Sprint nunca deve ser iniciado com a quantidade de pontos excedida, com histórias que possuem critérios de aceite não definidos, sem layout ou definição de UX incompleta. No caso de aplicativos móveis é necessário ter a tela completa e também cada botão separado, cada ícone, com todas as definições de tela para iOS: retina e não-retina(antigo), e para Android: LDPI, MDPI, HDPI, XHDPI, XXHDPI; já aprovados pelo Product Owner e pela equipe em Pré-Planning. O ideal é anexar todas as imagens na história para facilitar o acesso para a equipe otimizando o tempo e evitando ter que buscar em Drivers, e-mail, e etc., ou em um sistema de pastas que nem sempre é claro para todos.

Por isso, se a quantidade de pontos for excedida e não houver a possibilidade de troca com outra história, então os critérios de aceite devem ser divididos em duas histórias, podendo ser uma no Sprint atual, fechando o sprint dentro da métrica de pontuação e outra como a primeira história do próximo (segundo), abrindo o próximo sprint com os pontos e critérios de aceite que restaram, devendo ser devidamente entregue cada uma em seu sprint.

Primeiro Planning (e Planning 2)

Como penultima etapa antes de iniciarmos o desenvolvimento temos o Planning (final), onde as histórias são pontuadas e priorizadas junto com o Product Owner já em condições de iniciar o desenvolvimento, e as últimas dúvidas são definidas.

Em seguida é realizado o planning 2, já sem a presença do Product Owner, essa que é uma reunião puramente técnica e deve servir para analisar melhores formas de desenvolvimento de uma história, devem ser incluídas as tasks que definirão cada etapa de desenvolvimento com objetivo de atingir os critérios de aceite e fechar toda a estrutura para um processo sem bloqueios da história.

Estrutura de uma História no VS2013

Na história podem ser incluídos anexos, há campos de texto para detalhamento, ela fica associada ao Sprint, as tarefas (Child) que dependem dela, as Features (Parent) que ela é dependente, aos testes que farão a validação e aos possíveis defeitos encontrados. No projeto exemplo desse estudo usamos a contagem de Fibonacci para pontuar o esforço da história, agregando as atividades de desenvolvedores e testes, como podem ver na imagem acima.

Estrutura de uma História e seus dependentes

A visualização da história e tudo que está associado a ela no Visual Studio 2013.

Inclusão da Equipe

Todos devem participar desse processo, ajudar na definição dos critérios, ajudar no levantamento de critérios de exceção, mensagens de erro e possíveis cenários que faltam definição. A equipe deve ser unida profissionalmente e ter o objetivo comum de entregar o melhor sistema possível. E o analista de testes já inicia a escrita dos testes baseado nesses requisitos, criando todos os testes de validação, exceção, carga, performance, e o que mais for necessário, muitas vezes já escrevendo os testes (apenas com objetivo) na própria reunião, através de um bloco de notas, caderno ou qualquer outra ferramenta.

Pós-Planning

Logo após o planning, o Scrum Master deve marcar o pré-planning, review e planning que estão por vir, para 10 dias úteis após o primeiro planning, considerando que o planning já ocorre no primeiro dia do sprint e o review no último. Neste cenário, se o planning ocorre em uma segunda-feira dia 01, então o pré-planning deve ser marcado para quarta-feira dia 10 (aproximadamente) e o Review exatamente para o dia 12, sexta-feira. Tudo isso deve ser marcado com antecedência para que as datas de todos os ritos sejam de conhecimento de todos da equipe evitando atrasos por indisponibilidade de local ou surpresa em sua realização.

Sobre o uso de TDD no ProjetoNo projeto é utilizado o TDD, ou seja, Test Driven Development,

porém um TDD um pouco diferente, não baseado em testes unitários ou automatizados, mas baseado nos testes funcionais escritos a partir dos critérios de aceite definidos no pré-planning. Os testes da primeira história da ordem de priorização devem ficar prontos antes do início do Sprint. O desenvolvedor segue os casos de testes para criar o sistema. Portanto, o analista de testes já deve ter todos os testes escritos e detalhados a essa altura do processo com a maior cobertura possível de forma otimizada. Esses testes devem estar disponíveis na ferramenta para análise dos desenvolvedores, evitando paradas e atrasos no desenvolvimento, pois todas as perguntas já devem ter sido levantadas e respondidas, todas as mensagens de erro, validação e exceção com a cobertura adequada de forma que nenhuma demanda tenha que ser coberta no meio processo.

O inicio dos TestesConforme as histórias forem sendo iniciadas, elas vão obtendo status

de progresso na ferramenta e quando forem sendo completadas já podem ser disponibilizadas para teste. No caso de aplicativos móveis, é gerado um build que é instalado no aparelho, e os analistas de testes podem fazer uma execução em cima das funcionalidades já implementadas, no caso de projetos de sistemas web ou outros é feito um deploy, que deve ser disponibilidado online em ambiente especifico para testes, não é recomendável realizar testes localmente ou no mesmo ambiente da equipe de desenvolvimento, evitando conflitos ou um cenário que não representa a realidade.

Uma vez encontrados erros, eles devem ser registrados e, se bloquearem a história (severidade e prioridade) e não forem recorrentes, devem ser corrigidos no próprio sprint. Caso sejam erros recorrentes (que já vem ocorrendo desde outros Sprints) ou que não bloqueiam a história ou seus critérios de aceite, eles podem ser priorizados para correção em Sprint posterior.

Estrutura do Plano de Testes

Janela de Execução dos Testes

A Janela permite acompanhar a tela do sistema em paralelo com os passos do teste.

Também pode ser usada para auxiliar na gravação de script para testes automáticos.

Cadastro de BugsUma vez registrados bugs que ficam no sprint,

eles devem então ser corrigidos em um novo build do sistema, e todos os testes da nova funcionalidade devem ser reexecutados para garantir que a correção de um defeito não gerou erros em outras partes da nova funcionalidade. Esse processo é repetido até que todos os testes sejam executados e nenhum erro seja encontrado. Feito isso, a história poderá obter o status de completa na ferramenta e poderá ser liberada para o Review que ocorrerá no último dia do sprint.

Abertura e Manutenção de Bugs

A tela edição de um bug é similar a tela de uma história ou de um teste.

Dailies – Compromisso diário

Diariamente, na rotina do projeto e com horário fixo, sempre com a presença de todos ou o máximo possível de componentes da equipe, deve ocorrer a “Daily Meeting” (Reunião Diária), onde todos devem resumir suas atividades do projeto desde a daily meeting anterior, tentando detalhar as ações e que métodos usou para atingir seus objetivos, abrindo espaço para que os colegas possam auxiliar em dúvidas ou se utilizar dos dados ali compartilhados como lições aprendidas ou melhores práticas.

Tracking do Time

Trabalho esperado dos membros da equipe Trabalho realizado no Sprint

Intercorrências – Não PlanejadoNa prática, pode ocorrer de critérios de aceite ou exceção não

terem sido definidos, algum layout ou definição de UX aparecer de última hora durante o Sprint. Nesse caso, devem ser tratados com urgência, uma vez que o desenvolvimento pode ficar parado até que artefatos sejam criados. O responsável pela experiência de usuário (UX) ou designer precisam criar o material necessário com o menor impacto possível no sprint para evitar atrasos ou impedimento da entrega. Caso essa solução se torne demasiadamente grande e o impacto inevitável, então a história pode ter a prioridade reduzida para o fim do Sprint, quando a definição ou artefatos necessários estarão prontos.

Caso isso ainda não seja o bastante, então podemos finalizar o Sprint dentro do prazo normal e essa deverá ser a primeira história do próximo, a Review não deve ser adiada ou o Sprint alongado, salvo exceções, mas isso pode trazer impacto negativo a longo prazo e nunca deve se tornar uma rotina.

Pré-Planning – Sprint 2

Durante o Sprint, deve ser realizada a reunião pré-planning. Nela devem ser enriquecidas as histórias para o Sprint 2, inserir critérios de aceite e priorizar histórias de UX, design e backend; para que tudo esteja pronto quando houver o planning.

A ReviewApós finalizado o processo de desenvolvimento, passadas muitas “daily meetings” e

muitas linhas de código, ocorre a primeira reunião de Review. A primeira versão poderá ser entregue, as funcionalidades devem ser preparadas e o ambiente todo pronto para a análise do “product owner”.

Ao iniciar a reunião, o sistema deve estar disponível para uso de forma que as funcionalidades entregue possam ser exibidas, de preferência no projetor, e os critérios de aceite vão sendo passados ponto a ponto para análise do cliente. Ele pode realizar os testes necessários e passar por seus critérios de pronto. Quando finalizadas, as histórias obtêm aprovação no sistema e o cliente passa a analisar a próxima. Caso a história não seja completa e os critérios de aceite não sejam todos atingidos, ela pode passar por “split”, ou seja, ser dividida em duas, onde a segunda história poderá ser a primeira do próximo Sprint e terá os critérios de aceite que faltam para completar. Algumas ferramentas automaticamente repassam as tarefas incompletas para a história do próximo sprint.

Caso os critérios de pronto do cliente é que não sejam atendidos, ou seja, ele visualizar novos critérios de aceite que deveriam ser incluídos para que a história possa ficar disponível para o usuário final então deve ser criada uma nova história para um sprint futuro e que será priorizada no planning. Essa deve conter os novos critérios de aceite que finalizam a nova funcionalidade.

Retrospectiva do primeiro Sprint

Logo após o fim do Sprint, deve ser feita uma reunião de retrospectiva, onde os membros da equipe (exceto Product Owner) devem relatar como foi o trabalho, todas as atividades de sucesso, boas práticas, lições aprendidas e “à melhorar” para obter um processo mais sólido e rico, satisfatório para todos, todos devem ter liberdade para falar tudo que desejam, sem ser oprimidos por alguma opinião contraditória, abrir discussão sobre o ponto apresentado e detalhar melhor sobre qualquer tópico. Geralmente abordam-se primeiro os pontos positivos, mas não é uma regra, pode ser feito assim apenas porque os pontos negativos costumam gerar mais polêmica.

Após essa etapa discutem-se os pontos de melhoria, que costumam gerar mais polêmica e deixar ânimos exaltados. Todos devem se sentir à vontade para falar de qualquer tópico: desde a internet no ambiente de trabalho, relacionamento com outras equipes e pessoas, ar-condicionado, assim como questões técnicas que influenciam diretamente no projeto como design, UX, critérios de aceite, formato de código, algoritmos, processo, links, lógica, atuação de colegas, etc.

Remoção de RiscosApós apresentados e discutidos os dois lados do último sprint, ações de

melhoria devem ser tomadas, ou seja, Product Owner, Scrum Master e Coordenador devem definir como e onde podem agir para tentar resolver ou, ao menos, apaziguar os pontos de melhoria do projeto que dependem de ação externa. Relacionamento com outras equipes, ações com a gerência da área ou até com as diretorias da empresa com o objetivo de tornar o ambiente do projeto o melhor possível, ações internas, como performance de um colaborador específico ou mudanças no processo devem ser resolvidas internamente e monitoradas durante as daily meetings do próximo sprint.

Muitos projetos não veem importância na retrospectiva, principalmente com a evolução dos sprints onde o processo fica mais sólido e as retrospectivas se tornam repetitivas. Porém, só há evolução do projeto se houver reuniões de retrospectivas bem feitas. É importante também estar atento ao fato de que ninguém pode levar os pontos de melhoria para o lado pessoal. Essa é uma reunião para um processo de maturidade e o conceito é altamente profissional com objetivo de fazer um trabalho melhor.

Planning - Sprint #2

Após a retrospectiva, analisados os pontos positivos e definidos os pontos de melhoria, ocorre o Planning para definir o segundo sprint. As ações de melhoria já devem começar a ser adotadas imediatamente, e o processo se reinicia, histórias devem ser priorizadas. Se houve história com split no sprint anterior, então essas podem ser as primeiras, porém não é obrigatório, por isso os branches devem estar bem organizados para que uma história com menor prioridade possa ser continuada em um sprint posterior sem uma linha de aprendizado muito longa. Após priorizadas as histórias, deve-se discutir a pontuação, e definir as histórias que ficam no Sprint e quais serão adiadas para os próximos sprints.

Devem ser evitadas discussões paralelas nas reuniões. No Planning algumas pessoas tendem a sair do foco, gostam de opinar, porém é o Product Owner quem define, as prioridades são dele e da área de negócios. É necessário manter o objetivo de construir o Sprint rapidamente para retornar ao desenvolvimento, porém sem deixar pontos indefinidos, como dito antes, todo o design, UX, backend, serviços, etc., precisa estar definido antes de iniciar o Sprint.

Como no Sprint anterior, logo em seguida do Planning, já é realizado o Planning 2, onde a equipe técnica irá definir suas tarefas e as melhores práticas para chegar aos critérios de aceite.

Para explicar melhor as atividades durante o processo de desenvolvimento de software, é interessante esclarecer as funções e papéis de cada ator no processo, o que é esperado de cada um e onde ele pode fazer algo mais, o “quilômetro extra” (versão brasileira da “Extra Mile” americana, que é aquilo feito além do esperado, além das responsabilidades) por onde se pode andar, onde se pode auxiliar na melhoria do processo para obter mais qualidade do sistema e mais satisfação do cliente. Eventualmente, em um processo de maturidade elevada e profissional, as pessoas opinam na forma como os colegas atuam, ou seja, o desenvolvedor tenta melhorar o processo de testes, o analista de testes ajuda o Scrum Master e esse pode ajudar nas funções do “Product Owner” ou coordenador, por exemplo.

Scrum Master – Funções e responsabilidades

Sua função principal é definir e manter o processo sendo seguido, marcar e manter os ritos, garantir a presença de todos (ou o máximo possível) os participantes, ver se cada ação é realizada corretamente em cada reunião a que pertence, garantir que todos estão executando suas atividades no momento certo do projeto, se o desenvolvimento segue padrões de qualidade, testes unitários, design patterns, métricas, buscar novas formas de atingir metas assim como, analisar se o analista de testes (ou qualidade) está seguindo corretamente o processo, escrevendo os objetivos de testes no pré-planning, se os testes da primeira história já estão prontos após o planning (para iniciar o desenvolvimento), se a cobertura dos cenários de testes está adequada, coordenar se o processo é corretamente seguido, bem próximo dos analistas que fazem com que ele ocorra.

Seu excedente pode ser analisar o sistema e ver se há formas diferentes e talvez melhores de fazer o mesmo, pesquisar, procurar se inteirar nos documentos sobre sistemas similares e analisar se há novos padrões sendo adotados, procurar o que há de mais moderno, quais os caminhos que estão sendo seguidos para obter o melhor desse modelo de sistema, assim como também do processo. Seguir práticas, discussões em fóruns, ler as revistas especializadas e obter dados de como otimizar o processo sem denegrir a qualidade, ou seja, o ScrumMaster deve ser sempre muito dedicado e proativo, muito curioso e ciente das atividades diversas para ver falhas onde não estão olhando, seja no desenvolvimento ou nos testes, sempre com objetivo de aprimorar onde pode haver algum tipo de evolução.

Analista de Testes – O CoringaÉ responsável por validar e garantir a qualidade do sistema,

verificar que os critérios de aceite são devidamente atendidos, nenhum bug escape ou deixe de ser registrado, que os testes regressivos continuem aumentando, sendo atualizados, evoluindo, sendo executados em todos os critérios corretamente, que o ambiente seja bem preparado para a Review, que os testes sejam bem escritos e a cobertura seja adequada já no Planning.

Outra função que o analista de testes costuma ter é fornecer dados para as métricas do projeto, analisar quantos defeitos são encontrados, quantos são corrigidos e quantos novos defeitos são encontrados a partir disso. Além disso, deve fornecer esses dados para a equipe de qualidade que irá analisar o desenvolvimento do sistema e a performance dos desenvolvedores, a evolução da equipe e se o processo está sendo seguido corretamente.

Desenvolvedor – Cabeça no código

É responsável por criar o sistema, elaborar as funcionalidades, seguir corretamente os testes e critérios de aceite, analisar pontos de exceção, levantar questões sobre o planning para visualizar falhas de cobertura, pontuar com critério as histórias inserindo também o tempo de testes de cada feature e o regression ao final do Sprint. Precisam também seguir o processo de testes unitários definido e garantir que haja sempre evolução na quantidade de testes e melhora na cobertura.

Analista de UX – Usabilidade e Fluxo do Sistema

É responsável pelo desenho do sistema, interfaces com usuário, a localização das funcionalidades, o resultado esperado de cada ação, que o sistema tenha a melhor usabilidade, que as funcionalidades sejam práticas, atendam padrões dos fabricantes (no caso de aplicativos móveis, por exemplo), que mensagens de erro sejam evitadas, mas, caso necessário, é responsável pelo texto da mensagem, pelo nome (“label”) dos botões.

Além disso, deve analisar estatísticas do aplicativo, uso de funcionalidades e priorizar aquilo que é o foco e que o usuário mais procura no sistema. Também é responsabilidade do analista de UX pesquisar e fazer simulações com usuários, passar formulários, para descobrir quais são as funcionalidades que o usuário procura, e quais melhorias enriqueceriam o sistema e trariam mais usuários.

Designer – Ícones e Layout

O designer de um sistema é responsável pelo layout, escolha de cores, logomarca, por aplicar o que o analista de produto (UX) projetou e o Project Owner aprovou.

Coordenador – “Pára-raios” dos problemas

É função do coordenador do projeto dar toda estrutura de qualidade para que a equipe de forma adequada. Normalmente, associa-se ao Scrum Master para garantir a manutenção dos ritos e que o processo seja seguido. Além disso, atua no sentido de auxiliar na correção dos pontos de melhoria.

Product Owner – “O Dono”, parcerias e patrocínios

É o dono do projeto, o cliente. É por ele que tudo começa, quem toma as decisões, as histórias são priorizadas com a opinião de todos mas de acordo com a vontade do PO. É ele quem define os critérios de aceite, na função de cliente ele utiliza todos os estudos do designer e do analista de UX para definir quais melhor se encaixam com os objetivos de projeto, e as necessidades de quem de fato utiliza o sistema. Também é função dele atuar próximo à área de negócio para ajudar a trazer patrocinadores, verba ou investimento ao projeto.

No Scrum, tudo ocorre ao redor das reuniões, por isso elas são primordiais e precisam ser muito bem feitas. Essas etapas precisam ser bem obedecidas para garantir a qualidade do sistema e ter evolução no processo e no produto. Sendo bem definidas as reuniões e ficando claras as funções e responsabilidades de cada ator, as chances de desenvolver um projeto de sucesso utilizando o Scrum serão maiores.

Perguntas?

Roberto Passani Gomes- robertopassani@gmail.com- roberto.passani@bnymellon.com.br- Twitter/ Facebook/ Skype: Roberto Passani