Modifiquei meu artigo para o modo apresentação do PowerPoint e inseri algumas imagens de ferramentas Microsoft que uso na empresa atual.

1. Scrum: uma visão prática do
framework
Roberto Passani Gomes
Analista de Testes – BNY Mellon

2. 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.

3. 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.

4. 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 (autor do artigo), Designer, Analista de
UX (User Experience) e desenvolvedores (no caso,
quatro), que se dividem entre as plataformas iOS e
Android (desenvolvimento Móvel), 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.

5. Primeiros passos
O primeiro passo para desenvolvimento de um
sistema no Scrum, segundo o formato aqui apresentado,
seria a reunião de pre-planning, onde são definidos o
objetivo principal do sistema, isto é, aquilo que ele deseja
atingir (core): o mercado, o público e a/as
funcionalidade(s) principal(ais) - para um aplicativo, por
exemplo, seja trânsito, notícias, compras ou futebol -
onde são pré-planejadas as histórias que 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.

6. 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.

7. 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.

8. 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.

9. 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. 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, sendo 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.

10. Primeiro Planning
No planning, todo o layout e definições de UX já devem
estar prontos e aprovados pelo “Product Owner”, tudo já deve
estar disponível para análise da equipe de testes e
desenvolvimento. 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, e para Android: LDPI, MDPI, HDPI, XHDPI, XXHDPI. 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. Portanto, para realizar o
desenvolvimento, todas as histórias do sprint que está para se
iniciar precisam ter status de definidas na ferramenta usada
pela empresa, que indica que todos os dados aqui descritos já
foram detalhados, anexados à história e/ou link tenha sido
disponibilizado.

11. 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.

12. Sobre o uso de TDD no Projeto
No 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.

13. O inicio dos Testes
Conforme as histórias forem sendo iniciadas, elas
vão obtendo status de progresso na ferramenta. Após
isso, 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 analisar as funcionalidades
já implementadas.
Uma vez encontrados erros, eles devem ser
registrados 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 erros
recorrentes ou que não bloqueiam a história ou seus
critérios de aceite, eles podem ser deixados no backlog
para priorização posterior.

14. Cadastro de Bugs
Uma 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.

15. 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.

16. Intercorrências – Não Planejado
Na prática, sempre 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.

17. A Review
Apó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.

18. 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.

19. 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 foram
os últimos dias (do Sprint), 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, atuação de
colegas, etc.

20. Remoção de Riscos
Apó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.

21. 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.

22. Descrição dos papéis de cada
personagem do processo
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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.