O documento descreve o framework Scrum para desenvolvimento ágil de software. Ele explica as principais etapas e reuniões do Scrum como Planning, Daily Meetings e Review. Também discute a estrutura de histórias, testes, bugs e como o time deve trabalhar junto para entregar incrementos de valor a cada Sprint.

1. Scrum: uma visão prática do
framework
(Ferramentas: Visual Studio e Test
Manager 2013)
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 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.

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

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

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

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

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

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

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

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

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

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

15. O inicio dos Testes
Conforme 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.

16. Estrutura do Plano de Testes

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

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

19. Abertura e Manutenção de Bugs
A tela edição de um bug é similar a
tela de uma história ou de um teste.

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

21. Tracking do Time
Trabalho esperado dos membros da equipe Trabalho realizado no
Sprint

22. Intercorrências – Não Planejado
Na 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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