Scrum: uma visão prática do framework

Roberto Passani GomesAnalista de Testes – BNY Mellon

Sobre o Scrum

O Scrum é uma abordagem ágil que prima pelaotimização e objetividade no processo e em todas suasetapas, costuma minimizar burocracias, documentação emó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, asreuniões são importantes ao ponto de algumas empresas nãousarem nenhuma documentação escrita, ou seja, fazemSprints semanais e reuniões às segundas e sextas, de Planninge Review respectivamente, onde fazem todo o tracking dasatividades e desenvolvimento do produto.

Estrutura do Sprint

Para a apresentação usaremos o modelode um Sprint de 10 dias úteis, ouaproximadamente 14 dias corridos, sendo oPlanning no primeiro dia e o Review no último.Após o Review ocorre a Retrospectiva e nodecorrer do Sprint o Pré-planning. Diariamentedevem ocorrer as reuniões Diárias (DailyMeetings). Todas essas etapas serão detalhadasdurante a apresentação.

Apresentação do Ambiente

A equipe na qual este artigo foi baseado éconstituída de Product Owner, Scrum Master (queusualmente também acumula funções de Coordenador),Analista de Testes (autor do artigo), Designer, Analista deUX (User Experience) e desenvolvedores (no caso,quatro), que se dividem entre as plataformas iOS eAndroid (desenvolvimento Móvel), além disso temosequipes externas que dão suporte e ambiente aosprojetos, como analistas de produto, setor comercial einfraestrutura. Conforme será detalhado mais a frente naapresentação, é função do Scrum Master se comunicarcom outras equipes e remover riscos; questões deinfraestrutura, backend e serviço, portanto retirarquaisquer bloqueios das histórias antes que elas entremem qualquer Sprint.

Primeiros passos

O primeiro passo para desenvolvimento de umsistema no Scrum, segundo o formato aqui apresentado,seria a reunião de pre-planning, onde são definidos oobjetivo principal do sistema, isto é, aquilo que ele desejaatingir (core): o mercado, o público e a/asfuncionalidade(s) principal(ais) - para um aplicativo, porexemplo, seja trânsito, notícias, compras ou futebol -onde são pré-planejadas as histórias que iniciarão odesenvolvimento, e nelas são inseridos os critérios deaceite ou entrega.

Estes são basicamente os requisitos do sistema, odetalhamento de todas as funcionalidades, desde as maissimples as principais.

Criação de Histórias

O 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 analisar quem deve aprovar a história. Caso exista alguém além do Product Owner, o Scrum Master consegue analisar se há alguém além dos participantes diretos do projeto que deva ser convidado para os ritos, como Planning e Review, se há alguém externo à equipe que deseja inserir histórias ou acrescentar algo ao sistema.

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. Já a equipe de desenvolvimento pode começar a pensar em todo o backend (serviços e servidores) necessário, e tudo que será preciso para a implementação do sistema.

Sobre o Pré-Projeto

Uma vez estruturado o backend de serviços, a equipepode começar a implementação do software, e para priorizaras histórias e analisar quais farão parte de um primeiro sprintrealiza-se uma primeira reunião de planning, onde as históriasiniciais são colocadas no primeiro sprint e priorizadas naordem decrescente dentro dele. Primeiramente colocam-setodas as histórias que precisam ser feitas e depois elas sãopriorizadas. Em seguida, pontua-se cada história de acordocom o critério utilizado no projeto (Fibonacci, por horas ououtro), daí podemos analisar se ainda é possível inseriralguma história, se a meta de pontos não estiver sido atingida,ou se alguma história deverá sair se a meta estiver sidoultrapassada. Caso a meta tenha sido ultrapassada e aquantidade de pontos das histórias for maior do que ospontos ultrapassados, então a última história, segundo oscritérios de priorização, poderá ser dividida em duas.

Cuidados com a montagem do Sprint

Um Sprint nunca deve ser iniciado com aquantidade de pontos excedida, com histórias quepossuem critérios de aceite não definidos, sem layout oudefinição de UX incompleta. Por isso, se a quantidade depontos for excedida e não houver a possibilidade de trocacom outra história, então os critérios de aceite devem serdivididos em duas histórias, sendo uma no Sprint atual,fechando o sprint dentro da métrica de pontuação eoutra como a primeira história do próximo (segundo),abrindo o próximo sprint com os pontos e critérios deaceite que restaram, devendo ser devidamente entreguecada uma em seu sprint.

Primeiro Planning

No planning, todo o layout e definições de UX já devemestar prontos e aprovados pelo “Product Owner”, tudo já deveestar disponível para análise da equipe de testes edesenvolvimento. No caso de aplicativos móveis é necessárioter 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, e para Android: LDPI, MDPI, HDPI, XHDPI, XXHDPI. Oideal é anexar todas as imagens na história para facilitar oacesso para a equipe otimizando o tempo e evitando ter quebuscar em Drivers, e-mail, e etc., ou em um sistema de pastasque nem sempre é claro para todos. Portanto, para realizar odesenvolvimento, todas as histórias do sprint que está para seiniciar precisam ter status de definidas na ferramenta usadapela empresa, que indica que todos os dados aqui descritos jáforam detalhados, anexados à história e/ou link tenha sidodisponibilizado.

Pós-Planning

Logo após o planning, o Scrum Master deve marcaro pré-planning, review e planning que estão por vir, para10 dias úteis após o primeiro planning, considerando queo planning já ocorre no primeiro dia do sprint e o reviewno último. Neste cenário, se o planning ocorre em umasegunda-feira dia 01, então o pré-planning deve sermarcado para quarta-feira dia 10 (aproximadamente) e oReview exatamente para o dia 12, sexta-feira. Tudo issodeve ser marcado com antecedência para que as datas detodos os ritos sejam de conhecimento de todos da equipeevitando atrasos por indisponibilidade de local ousurpresa em sua realização.

Sobre o uso de TDD no Projeto

No projeto é utilizado o TDD, ou seja, Test DrivenDevelopment, porém um TDD um pouco diferente, nãobaseado em testes unitários ou automatizados, mas baseadonos testes funcionais escritos a partir dos critérios de aceitedefinidos no pré-planning. Os testes da primeira história daordem de priorização devem ficar prontos antes do início doSprint. O desenvolvedor segue os casos de testes para criar osistema. Portanto, o analista de testes já deve ter todos ostestes escritos e detalhados a essa altura do processo com amaior cobertura possível de forma otimizada. Esses testesdevem estar disponíveis na ferramenta para análise dosdesenvolvedores evitando paradas e atrasos nodesenvolvimento, pois todas as perguntas já devem ter sidolevantadas e respondidas, todas as mensagens de erro,validação e exceção com a cobertura adequada de forma quenenhuma demanda tenha que ser coberta no meio processo.

O inicio dos Testes

Conforme as histórias forem sendo iniciadas, elasvão obtendo status de progresso na ferramenta. Apósisso, quando forem sendo completadas, já podem serdisponibilizadas para teste. No caso de aplicativosmóveis, é gerado um build que é instalado no aparelho, eos analistas de testes podem analisar as funcionalidadesjá implementadas.

Uma vez encontrados erros, eles devem serregistrados na ferramenta e, se bloquearem a história(severidade e prioridade) e não forem recorrentes,devem ser corrigidos no próprio sprint. Caso sejam errosrecorrentes ou que não bloqueiam a história ou seuscritérios de aceite, eles podem ser deixados no backlogpara priorização posterior.

Cadastro de Bugs

Uma vez registrados bugs que ficam no sprint,eles devem então ser corrigidos em um novo builddo sistema, e todos os testes da novafuncionalidade devem ser reexecutados paragarantir que a correção de um defeito não gerouerros em outras partes da nova funcionalidade.

Esse processo é repetido até que todos ostestes sejam executados e nenhum erro sejaencontrado. Feito isso, a história poderá obter ostatus de completa na ferramenta e poderá serliberada para o Review que ocorrerá no último diado sprint.

Dailies – Compromisso diário

Diariamente, na rotina do projeto e comhorário fixo, sempre com a presença de todos ou omáximo possível de componentes da equipe, deveocorrer a “Daily Meeting” (Reunião Diária), ondetodos devem resumir suas atividades do projetodesde a daily meeting anterior, tentando detalharas ações e que métodos usou para atingir seusobjetivos, abrindo espaço para que os colegaspossam auxiliar em dúvidas ou se utilizar dos dadosali compartilhados como lições aprendidas oumelhores práticas.

Intercorrências – Não Planejado

Na prática, sempre pode ocorrer de critérios de aceite ouexceção não terem sido definidos, algum layout ou definição de UXaparecer de última hora durante o Sprint. Nesse caso, devem sertratados com urgência, uma vez que o desenvolvimento pode ficarparado até que artefatos sejam criados. O responsável pelaexperiência de usuário (UX) ou designer precisam criar o materialnecessário com o menor impacto possível no sprint para evitar atrasosou impedimento da entrega. Caso essa solução se tornedemasiadamente grande e o impacto inevitável, então a história podeter a prioridade reduzida para o fim do Sprint, quando a definição ouartefatos necessários estarão prontos.

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

A Review

Após finalizado o processo de desenvolvimento, passadas muitas “daily meetings” emuitas linhas de código, ocorre a primeira reunião de Review. A primeira versão poderá serentregue, 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 asfuncionalidades entregue possam ser exibidas, de preferência no projetor, e os critérios de aceitevão sendo passados ponto a ponto para análise do cliente. Ele pode realizar os testes necessáriose passar por seus critérios de pronto. Quando finalizadas, as histórias obtêm aprovação nosistema e o cliente passa a analisar a próxima. Caso a história não seja completa e os critérios deaceite não sejam todos atingidos, ela pode passar por “split”, ou seja, ser dividida em duas, ondea segunda história poderá ser a primeira do próximo Sprint e terá os critérios de aceite quefaltam para completar. Algumas ferramentas automaticamente repassam as tarefas incompletaspara a história do próximo sprint.

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

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.

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 foramos últimos dias (do Sprint), todas as atividades de sucesso, boas práticas, liçõesaprendidas e “à melhorar” para obter um processo mais sólido e rico, satisfatóriopara todos, todos devem ter liberdade para falar tudo que desejam, sem seroprimidos por alguma opinião contraditória, abrir discussão sobre o pontoapresentado e detalhar melhor sobre qualquer tópico. Geralmente abordam-seprimeiro os pontos positivos, mas não é uma regra, pode ser feito assim apenasporque os pontos negativos costumam gerar mais polêmica.

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

Remoção de Riscos

Após apresentados e discutidos os dois lados do último sprint, açõesde melhoria devem ser tomadas, ou seja, Product Owner, Scrum Master eCoordenador devem definir como e onde podem agir para tentar resolver ou,ao menos, apaziguar os pontos de melhoria do projeto que dependem deaçã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 oambiente do projeto o melhor possível, ações internas, como performance deum colaborador específico ou mudanças no processo devem ser resolvidasinternamente 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 eas retrospectivas se tornam repetitivas. Porém, só há evolução do projeto sehouver reuniões de retrospectivas bem feitas. É importante também estaratento ao fato de que ninguém pode levar os pontos de melhoria para o ladopessoal. 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 demelhoria, ocorre o Planning para definir o segundo sprint. As ações demelhoria já devem começar a ser adotadas imediatamente, e o processo sereinicia, histórias devem ser priorizadas. Se houve história com split no sprintanterior, então essas podem ser as primeiras, porém não é obrigatório, porisso os branches devem estar bem organizados para que uma história commenor prioridade possa ser continuada em um sprint posterior sem umalinha de aprendizado muito longa. Após priorizadas as histórias, deve-sediscutir a pontuação, e definir as histórias que ficam no Sprint e quais serãoadiadas para os próximos sprints.Devem ser evitadas discussões paralelas nas reuniões. No Planning algumaspessoas tendem a sair do foco, gostam de opinar, porém é o Product Ownerquem define, as prioridades são dele e da área de negócios. É necessáriomanter o objetivo de construir o Sprint rapidamente para retornar aodesenvolvimento, porém sem deixar pontos indefinidos, como dito antes,todo o design, UX, backend, serviços, etc., precisa estar definido antes deiniciar o Sprint.

Descrição dos papéis de cada personagem do processo

Para explicar melhor as atividades durante o processo dedesenvolvimento de software, é interessante esclarecer asfunções e papéis de cada ator no processo, o que é esperadode cada um e onde ele pode fazer algo mais, o “quilômetroextra” (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 doprocesso para obter mais qualidade do sistema e maissatisfação do cliente. Eventualmente, em um processo dematuridade elevada e profissional, as pessoas opinam naforma como os colegas atuam, ou seja, o desenvolvedor tentamelhorar o processo de testes, o analista de testes ajuda oScrum Master e esse pode ajudar nas funções do “ProductOwner” ou coordenador, por exemplo.

Scrum Master – Funções e responsabilidades

Sua função principal é definir e manter o processo sendo seguido, marcar e manter osritos, garantir a presença de todos (ou o máximo possível) os participantes, ver se cadaação é realizada corretamente em cada reunião a que pertence, garantir que todosestão executando suas atividades no momento certo do projeto, se o desenvolvimentosegue padrões de qualidade, testes unitários, design patterns, métricas, buscar novasformas 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 (parainiciar o desenvolvimento), se a cobertura dos cenários de testes está adequada,coordenar se o processo é corretamente seguido, bem próximo dos analistas quefazem com que ele ocorra.Seu excedente pode ser analisar o sistema e ver se há formas diferentes e talvezmelhores de fazer o mesmo, pesquisar, procurar se inteirar nos documentos sobresistemas 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 melhordesse 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 oprocesso sem denegrir a qualidade, ou seja, o ScrumMaster deve ser sempre muitodedicado e proativo, muito curioso e ciente das atividades diversas para ver falhasonde não estão olhando, seja no desenvolvimento ou nos testes, sempre com objetivode 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 devidamenteatendidos, nenhum bug escape ou deixe de ser registrado,que os testes regressivos continuem aumentando, sendoatualizados, evoluindo, sendo executados em todos oscritérios corretamente, que o ambiente seja bem preparadopara a Review, que os testes sejam bem escritos e a coberturaseja adequada já no Planning.Outra função que o analista de testes costuma ter é fornecerdados para as métricas do projeto, analisar quantos defeitossão encontrados, quantos são corrigidos e quantos novosdefeitos são encontrados a partir disso. Além disso, devefornecer esses dados para a equipe de qualidade que iráanalisar o desenvolvimento do sistema e a performance dosdesenvolvedores, 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 asfuncionalidades, seguir corretamente os testes e critériosde aceite, analisar pontos de exceção, levantar questõessobre o planning para visualizar falhas de cobertura,pontuar com critério as histórias inserindo também otempo de testes de cada feature e o regression ao final doSprint. Precisam também seguir o processo de testesunitários definido e garantir que haja sempre evolução naquantidade de testes e melhora na cobertura.

Analista de UX – Usabilidade e Fluxo do Sistema

É responsável pelo desenho do sistema, interfaces comusuário, a localização das funcionalidades, o resultadoesperado de cada ação, que o sistema tenha a melhorusabilidade, que as funcionalidades sejam práticas, atendampadrões dos fabricantes (no caso de aplicativos móveis, porexemplo), que mensagens de erro sejam evitadas, mas, casonecessário, é responsável pelo texto da mensagem, pelonome (“label”) dos botões.Além disso, deve analisar estatísticas do aplicativo, uso defuncionalidades e priorizar aquilo que é o foco e que o usuáriomais procura no sistema. Também é responsabilidade doanalista de UX pesquisar e fazer simulações com usuários,passar formulários, para descobrir quais são asfuncionalidades que o usuário procura, e quais melhoriasenriqueceriam o sistema e trariam mais usuários.

Designer – Ícones e Layout

O designer de um sistema é responsável pelolayout, escolha de cores, logomarca, por aplicaro que o analista de produto (UX) projetou e oProject Owner aprovou.

Coordenador – “Pára-raios” dos problemas

É função do coordenador do projeto dar todaestrutura de qualidade para que a equipe deforma adequada. Normalmente, associa-se aoScrum Master para garantir a manutenção dosritos e que o processo seja seguido. Além disso,atua no sentido de auxiliar na correção dospontos 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 aopinião de todos mas de acordo com a vontade do PO. É elequem define os critérios de aceite, na função de cliente eleutiliza todos os estudos do designer e do analista de UX paradefinir 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 atrazer patrocinadores, verba ou investimento ao projeto.No Scrum, tudo ocorre ao redor das reuniões, por isso elassão primordiais e precisam ser muito bem feitas. Essas etapasprecisam ser bem obedecidas para garantir a qualidade dosistema e ter evolução no processo e no produto. Sendo bemdefinidas as reuniões e ficando claras as funções eresponsabilidades de cada ator, as chances de desenvolver umprojeto de sucesso utilizando o Scrum serão maiores.