Unidade 1 - Revisão Ágil

Prévia do material em texto

Desenvolvimento Ágil 
Responsável pelo Conteúdo:
Prof. Me. Artur Marques 
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Revisão Ágil
Revisão Ágil
• Revisar Scrum e Lean como metodologias de gerenciamento de software ágil.
OBJETIVO DE APRENDIZADO 
• Revisão e Atualizações;
• Revisão Scrum;
• Uso e Recomendações sobre Definição e Montagem de um Time Scrum;
• Uso de XP na Engenharia de Sistemas;
• Sprint 0 e o Controle do Tempo do Projeto Ágil;
• Determinação do Tempo da Sprint do Projeto;
• Resumo Lean.
UNIDADE Revisão Ágil
Revisão e Atualizações
O Manifesto Ágil é um contraste dramático com o guia e os padrões tradicionais 
do Corpo de Conhecimento do Gerente de Projeto (PMBOK) focado no desenvolvi-
mento sequencial ou Cascata.
E sim, ágil possui muitos termos associados a ele, como, por exemplo, Lean, 
DevOps, Kanban e Scrum. 
Falar de processos ágeis, ao contrário do senso comum sobre essa palavra, é 
complexo e multidisciplinar. Abordamos assuntos relacionados à estimativa, como 
previsibilidade, transparência, inspeção, adaptação, incerteza, velocidade e rastrea-
mento de tempo. Mas a ideia aqui é recapitular de maneira geral, para trabalharmos 
na iniciação de um Projeto.
Então, vamos passo a passo!
De acordo com a Agile Alliance (2019, p. 1): “Agile é a capacidade de criar e 
responder às mudanças. É uma maneira de lidar e, finalmente, ter sucesso em um 
ambiente incerto e turbulento.” Enquanto isso, “Desenvolvimento ágil de software é 
um termo genérico para um conjunto de estruturas e práticas baseadas nos valores 
e nos princípios expressos no Manifesto para software ágil”. 
Isso, para ser executado, exige forte comprometimento comportamental dos in-
divíduos, criando o que se chama de mentalidade ágil, que envolve aceitar e adotar 
mudanças úteis e que gerem valor.
Revisão Scrum
O SCRUM foi desenvolvido, inicialmente, para gerenciar e desenvolver produtos. 
Todavia, encontrou um grande apelo na indústria de software devido a suas deman-
das complexas e que devem ser respondidas de forma rápida e direta, produzindo 
software de qualidade.
De acordo com o Scrumguides.org (2018), a partir do início dos anos 1990, o 
Scrum tem sido amplamente utilizado em todo o mundo para desenvolver software, 
hardware, software embarcado, redes de funções interativas, veículos autônomos, 
escolas, governo, marketing, gerenciamento da operação de Organizações e quase 
tudo o que usamos em nossas vidas diárias, como indivíduos e Sociedades.
À medida que as complexidades tecnológicas, de Mercado e ambientais e suas 
interações aumentam, rapidamente a utilidade do SCRUM em lidar com a complexi-
dade é comprovada diariamente.
Em essência, quando falamos de SCRUM, estamos tratando de uma Equipe peque-
na de pessoas (entre 5 e 9 pessoas, quando você inclui o Dono do Produto, e o Scrum 
8
9
Master fica entre 7 e 11 – tente não ultrapassar isso), altamente flexível e adaptável, 
que colaboram e interoperam por meio de sofisticadas arquiteturas de desenvolvimento 
e ambientes de liberação de destino (versionamento de softwares e funcionalidades).
Para trabalharmos com SCRUM, há um guia mantido por 2 dos profissionais 
que elaboraram e participaram ativamente não apenas do Manifesto Ágil, mas do 
desenvolvimento de metodologias que hoje são o arcabouço da agilidade no geral e 
do SCRUM em particular. São eles: Ken Schwaber e Jeff Sutherland, portanto, os 
criadores do SCRUM.
Em primeiro lugar, quando vamos iniciar um Projeto, temos em SCRUM o DOD – 
Definition of Done ou, se prefere em Português, uma Definição de Concluído/Pronto. 
Essa é uma maneira de ajudar uma Equipe e seus stakeholders a entender a dife-
rença entre o que a Equipe entrega a cada Sprint versus o que seria necessário para 
que o produto fosse incrementado em um estado “entregável” (e, apesar de essa 
palavra não existir em Português, é a mais utilizada e aceita no linguajar de Projetos. 
Ela vem de Deliverable e significa Entrega) a cada Sprint.
Mas antes disso, você deve se lembrar das regras do SCRUM, certo?!
• C ada Sprint tem o mesmo comprimento;
• Cada Sprint tem quatro semanas ou menos de duração;
• Não há quebras entre Sprints;
• A intenção de cada Sprint é um software “potencialmente remetível”;
• Todo Sprint inclui Planejamento de Sprint;
• A Reunião de Planejamento da Sprint tem a validade definida para 2 horas/
semana de duração da Sprint;
• Cada Sprint inclui a Revisão da Sprint para obter feedback das partes interes-
sadas sobre o produto;
• Cada Sprint inclui Retrospectiva da Sprint para que a Equipe inspecione e 
se adapte;
• As reuniões de revisão e retrospectiva são colocadas em caixas de horas no total 
de 2 horas/semana de duração da Sprint;
• Não há interrupção entre as reuniões da Sprint Review e da Retrospective;
• O escopo do trabalho de um Sprint nunca é expandido no meio do Sprint
(interrupções);
• Todas as partes interessadas são convidadas a participar da parte demo da 
Sprint Review;
• Os PBIs têm seu esforço estimado coletivamente pela Equipe que os implementará;
• A Equipe Scrum é composta por cinco a onze pessoas;
• A Equipe Scrum inclui o Product Owner, o ScrumMaster e os membros da Equipe;
9
UNIDADE Revisão Ágil
• A Equipe Scrum não inclui outras pessoas (por exemplo, um Gerente que não 
executa tarefas).
Assim como sobre o Backlog do Produto:
• Não existem dois PBIs (Product Backlog Items) na mesma posição no Product 
Backlog (pedido);
• Todos os PBIs estão relacionados a um único produto (ou Sistema);
• Os PBIs são ordenados pelo valor esperado (ROI, NIAT etc.);
• Os PBIs são «fatias» através do nosso Sistema (recursos ou funções);
• Os PBIs são escritos como Histórias de Usuário (“Como ___ eu posso ___ para 
que ___”);
• Os PBIs principais são pequenos o suficiente (esforço) para que vários possam 
caber em um único Sprint;
• PBIs são convites para conversas, não especificações detalhadas;
• Defeitos conhecidos (qualidade externa), geralmente, são solicitados na parte 
superior do Backlog do Produto para serem corrigidos no próximo Sprint;
• O Product Backlog é refinado para garantir que esteja pronto para todas as 
reuniões do Sprint Planning;
• Qualquer parte interessada (por exemplo, membro da Equipe, vendedor, cliente) 
pode sugerir um novo PBI;
• O Backlog do Produto é facilmente visível para todas as partes interessadas (por 
exemplo, cartões em uma parede ou uma ferramenta eletrônica com acesso aberto):
Desenvolvimento Ágil
1 – Requisitos
2 – Planejam
ento
3 – D
esign
4 – Desenvolvimento
5 –
 Li
be
ra
çã
o
6 – 
Rast
reab
ilida
de
e Mo
nito
ram
ento
Figura 1 – característica circular do SDLC Ágil 
Ciclo de Vida do Desenvolvimento de Software Ágil
Fonte: Freepik
10
11
Uso e Recomendações sobre Definição
e Montagem de um Time Scrum
O que é um time ágil segundo seus próprios criadores e membros da AGILE 
ALLIANCE:
Definição: U ma “Equipe” no sentido Ágil é um pequeno grupo de pes-
soas, designado a um mesmo projeto ou esforço, quase todos em período 
integral. Uma pequena minoria de membros da Equipe pode colaborar 
em período parcial ou ter responsabilidades concorrentes. A noção de 
Equipe implica responsabilidade compartilhada: bom ou ruim, os resul-
tados devem ser atribuídos a toda a Equipe, e não a qualquer indivíduo. 
Espera-se que a Equipe possua todas as competências necessárias, sejam 
técnicas (programação, design, teste) ou comerciais (conhecimento de 
 domínio, capacidade de tomada de decisão).
Papéis e responsabilidades: não importam tanto quanto resultados: um 
desenvolvedor pode testar, executar análises ou pensar nos requisitos; um 
analista ou especialista em domínio pode sugerir ideias sobre implemen-
tação e assim por diante.
Armadilhas comuns: o erro mais elementar é equiparar “grupo” e 
“Equipe”, para pensar que uma Equipe resulta automaticamente de ter 
pessoas trabalhando juntas. Uma Equipe deve ter pelo menos três pessoas 
(duas são um par) e geralmente não excederá dez.Uma única pessoa 
pode contribuir com mais de um “projeto” simultaneamente, mas é alta-
mente improvável que se considere pertencer a mais de uma “Equipe” ao 
mesmo tempo.
Origens: 2004, Kent Beck propõe “Equipe Inteira” como a nova denomi-
nação para a prática anteriormente conhecida como “Cliente no Local”
O modelo conceitual de Tuckman (“normatizar, formar, atacar, executar”) 
é provavelmente o mais citado com relação à dinâmica das Equipes Agile”. 
(AGILE ALLIANCE, 2019, p. 1)
Sugerimos duas leituras importantes para você entender os modelos de monta-
gem de times ágeis para um projeto SCRUM validados pela AGILE ALLIANCE.
Vale o investimento de tempo nisso:
TUCKMAN B. W. Developmental sequence in small groups. “Desenvolvimento sequencial 
em pequenos grupos”. 1984. Disponível em: https://bit.ly/3erJAfE
HOEGL, M.; GEMUENDEN, H. G. Teamwork Quality and the Success of Innovative Projects: 
A Theoretical Concept and Empirical Evidence. “Qualidade e sucesso de projetos inovadores: 
um conceito teórico e evidências empíricas”. 2001. Disponível em: https://bit.ly/2TZN8w4
Lembrando-se rapidamente dos componentes de uma Equipe SCRUM:
• Scrum Master: é responsável pela criação da Equipe, pela reunião do sprint e 
por remover os obstáculos ao Progresso do Projeto;
11
UNIDADE Revisão Ágil
• Product Owner: proprietário do produto: cria um backlog do produto, prioriza 
o backlog e é responsável pela entrega da funcionalidade a cada iteração;
• Equipe Scrum: gerencia seu próprio trabalho e organiza o trabalho para con-
cluir o sprint ou o ciclo.
Aqui vão regras úteis para você quanto a ser um membro da Equipe:
• Eu uso o Scrum como uma ferramenta para o desenvolvimento de produtos;
• Sou sincero quanto à qualidade interna do meu produto (dívida técnica);
• Eu trabalho com apenas uma Equipe Scrum;
• Sou membro em tempo integral dessa Equipe (não há deveres que não sejam 
membros da Equipe);
• Conheço bem meu produto e posso descrever rapidamente seu objetivo de 
alto nível;
• Conheço bem meu produto e posso descrever rapidamente sua arquitetura de 
alto nível;
• Busco ativamente ajudar meus companheiros de Equipe;
• Comprometo-me a fazer o que for preciso para atingir todos os objetivos 
da Sprint;
• Sou voluntário para uma nova tarefa do backlog da Sprint assim que concluo 
uma tarefa;
• Compartilho meus obstáculos (técnicos, ferramentas, processos, trabalho em 
Equipe, pessoal) todos os dias do Scrum Diário;
• Estou disposto a aprender qualquer habilidade necessária para ajudar 
minha Equipe;
• Eu trabalho com todos os membros da Equipe para expandir a Definição 
de “Concluído”;
• Eu tomo a direção do escopo e a visão do produto pelo Dono do Produto da 
minha Equipe;
• Vivo os valores e princípios do Manifesto Ágil em minha Equipe;
• Participo pessoalmente de todas as reuniões do Sprint Planning;
• Participo de todas as reuniões diárias do Scrum pessoalmente;
• Participo de todas as reuniões de revisão da Sprint pessoalmente;
• Participo pessoalmente de todas as reuniões retrospectivas da Sprint;
• Eu nunca digo a nenhum outro membro da Equipe qual tarefa trabalhar 
na próxima;
• Nenhum membro da minha Equipe se reporta a mim;
• Não acompanho minhas horas ou meu tempo “real” nas tarefas;
12
13
• Cada Sprint tem o mesmo comprimento;
• Cada Sprint tem quatro semanas ou menos de duração;
• Não há quebras entre sprints;
• A intenção de cada Sprint é um software “potencialmente viável para produção”; 
• Todo Sprint inclui Planejamento de Sprint;
• A Reunião de Planejamento da Sprint tem a validade definida para 2 horas/
semana de duração da Sprint;
• Cada Sprint inclui a Revisão da Sprint para obter feedback das partes interes-
sadas sobre o produto;
• Cada Sprint inclui Retrospectiva da Sprint para que a Equipe inspecione e 
se adapte;
• As reuniões de revisão e retrospectiva são colocadas em caixas de horas no total 
de 2 horas/semana de duração da Sprint;
• Não há interrupção entre as reuniões da Sprint Review e da Retrospective;
• O Daily Scrum é timeboxed por 15 minutos;
• O Daily Scrum ocorre todos os dias na mesma hora do dia;
• Os membros da Equipe respondem apenas a três perguntas no Daily Scrum
(sem discussão);
• O escopo do trabalho de um Sprint nunca é expandido no meio do Sprint (in-
terrupções);
• Todas as partes interessadas são convidadas a participar da parte demo da 
Sprint Review;
• Os PBIs têm seu esforço estimado coletivamente pela Equipe que os implementará.
Mas caso você seja um Scrum Master:
• Cada Sprint tem o mesmo comprimento;
• Cada Sprint tem quatro semanas ou menos de duração;
• Não há quebras entre Sprints;
• A intenção de cada Sprint é um software “potencialmente funcional”;
• Todo Sprint inclui Planejamento de Sprint;
• A Reunião de Planejamento da Sprint tem a validade definida para 2 horas/
semana de duração da Sprint;
• Cada Sprint inclui a Revisão da Sprint para obter feedback das partes interes-
sadas sobre o produto;
• Cada Sprint inclui Retrospectiva da Sprint para que a Equipe inspecione e 
se adapte;
13
UNIDADE Revisão Ágil
• As reuniões de revisão e de retrospectiva são colocadas em caixas de horas no 
total de 2 horas/semana de duração da Sprint;
• Não há interrupção entre as reuniões da Sprint Review e da Retrospective;
• O Daily Scrum é determinado em 15 minutos;
• O Daily Scrum ocorre todos os dias na mesma hora do dia;
• Os membros da Equipe respondem apenas a três perguntas no Daily Scrum 
(sem discussão);
• O escopo do trabalho de um Sprint nunca é expandido no meio do Sprint 
(interrupções);
• Todas as partes interessadas são convidadas a participar da parte demo da 
Sprint Review;
• Os PBIs (backlog do produto) têm seu esforço estimado coletivamente pela Equi-
pe que os implementará;
• A Equipe Scrum é composta por cinco a onze pessoas;
• A Equipe Scrum inclui o Product Owner, o Scrum Master e os membros 
da Equipe;
• A Equipe Scrum não inclui outras pessoas (por exemplo, um Gerente que não 
executa tarefas).
Por fim, caso você tenha o papel de Dono do Produto, veja o que se espera de sua 
função, porque há muita coisa daqui que as pessoas, no geral, acham que é o Scrum 
Master que faz, principalmente aqui no Brasil.
Eu, nas minhas consultorias, tenho visto Scrum Masters sendo obrigados a faze-
rem papel de Gerente de Produto, coisa que não existe no SCRUM, porque a Equipe 
é multifuncional e a liderança é situacional:
• Cada Sprint tem o mesmo comprimento;
• Cada Sprint tem quatro semanas ou menos de duração;
• Não há quebras entre Sprints;
• A intenção de cada Sprint é um software “potencialmente funcional”;
• Todo Sprint inclui Planejamento de Sprint;
• A Reunião de Planejamento da Sprint tem a validade definida para 2 horas/
semana de duração da Sprint;
• Cada Sprint inclui a Revisão da Sprint para obter feedback das partes interes-
sadas sobre o produto;
• Cada Sprint inclui Retrospectiva da Sprint para que a Equipe inspecione e 
se adapte;
• As reuniões de revisão e retrospectiva são colocadas em caixas de horas no total 
de 2 horas/semana de duração da Sprint;
14
15
• Não há interrupção entre as reuniões da Sprint Review e da Retrospective;
• O Daily Scrum é feito em 15 minutos e somente isso!;
• O Daily Scrum ocorre todos os dias na mesma hora do dia;
• Os membros da Equipe respondem apenas a três perguntas no Daily Scrum
(sem discussão);
• O escopo do trabalho de um Sprint nunca é expandido no meio do Sprint (in-
terrupções);
• Todas as partes interessadas são convidadas a participar da parte demo da
Sprint Review;
• Os PBIs têm seu esforço estimado coletivamente pela Equipe que os implementará;
• A Equipe Scrum é composta por cinco a onze pessoas;
• A Equipe Scrum inclui o Product Owner, o Scrum Master e os membros
da Equipe;
• A Equipe Scrum não inclui outras pessoas (por exemplo, um Gerente que não
executa tarefas).
Lembrando-se de que o Dono do Produto se preocupa muito com o que foi pro-
metido em cada sprint (sprint backlog), lembrando-se deque: a Sprint Backlog (uma 
fração escolhida por prioridade pelo dono do produto a partir do backlog do produto 
visando a realizar uma entrega útil e funcional para o cliente) define o trabalho, ou 
tarefas, que uma Equipe (entre 5 à 9 pessoas) define para transformar o Backlog 
do produto (a quantidade de tarefas totais a serem feitas, ou seja, o produto ou um 
Sistema de Informação inteiro) selecionado para esse Sprint em um incremento da 
funcionalidade do produto potencialmente implementável. 
A Equipe compila uma lista inicial dessas tarefas na segunda parte da reunião de 
planejamento da Sprint, de tal forma que as tarefas devem ser divididas para cada 
uma tomar de 4 a 16 horas para acabar.
Tarefas maiores de 4 a 16 horas são consideradas como não tendo sido definidas 
de forma adequada.
Para que tudo isso funcione de maneira sinérgica, trataremos aqui de algumas 
regras de ouro que devem ser seguidas para a composição de um time ágil e de um 
SCRUM nos eixos e funcional que, além disso, são alguns conselhos. 
Você que trabalha ou trabalhará com o framework, deve ler o Manual SCRUM 
GUIDE e seguir esses princípios. 
Mersino (2018), do PMI, revela-nos o seguinte:
A Equipe é auto-organizada: O Guia Scrum é bastante claro sobre 
isso, afirmando que “Ninguém (nem mesmo o Scrum Master) diz à 
Equipe de Desenvolvimento ...” como realizar o trabalho. A Equipe 
é composta por indivíduos motivados, competentes e deve pos-
15
UNIDADE Revisão Ágil
suir confiabilidade da empresa. O que frequentemente encontramos 
é alguém fora da Equipe dizer a Equipe o que fazer, e esse alguém é 
o Scrum Master. Por vezes, é o gerente de desenvolvimento ou, outra 
gerente funcional. De qualquer forma, a Equipe não é confiável ou confi-
gurada para operar sem essa dependência. Portanto, essa falta de auto-
nomia prejudica a adesão e a motivação dos membros da Equipe.
O Scrum Master é um líder servo que ensina a Equipe do Scrum 
como se auto organizar. O papel do Scrum Master é amplamen-
te mal compreendido. Como o nome indica, o Scrum Master deve 
 dominar o SCRUM. Eles não são gerentes de projetos. Em vez disso, eles 
são um tutor que ensina a todos o SCRUM e ajuda a Equipe a se auto 
organizar. Se bem feito, o Scrum Master sairia do trabalho à medida que 
a Equipe aprende e cresce. Vemos frequentemente o Scrum Masters que 
não conhecem SCRUM, não saberem atuar nem como tutores e nem 
como líderes e, portanto, não sabem como ajudar as Equipes a se auto 
organizarem. Eles geralmente vêm de outros papéis e carregam a baga-
gem desses papéis. Eles frequentemente se sentem compelidos a tomar 
decisões e a dizer à Equipe o que fazer. Em vez de tornar a Equipe inde-
pendente, esses Scrum Masters se fazem tornar indispensáveis.
O Scrum Master não precisa participar do Daily Scrum. Essa é 
uma regra interessante que se alinha à regra anterior. O pensamento 
tradicional é que uma pessoa – normalmente o gerente do projeto – hos-
peda e dirige a reunião de status. Não é assim que as coisas funcionam 
no Scrum. O Daily Scrum não é uma reunião de status, é uma reunião 
para os membros da Equipe coordenarem seu trabalho e garantirem que 
estão no caminho certo para alcançar seu objetivo da sprint. O motivo 
pelo qual o Scrum Master não pode participar da reunião é porque eles 
não são necessários na reunião. Scrum Masters novos ou inábeis podem 
realmente fazer mais mal comparecendo do que bem.
O Scrum Master é responsável por garantir que a Reunião diária do 
Scrum ocorra, que seja eficaz e que seja mantida dentro do prazo 
de 15 minutos. A Equipe deve ter a reunião, independentemente 
de o SM estar presente ou não. As Equipes de Scrum devem traba-
lhar de forma multifuncional sem transferências. As Equipes tradicionais 
trabalham como se estivessem realizando uma corrida de revezamento: 
membros especializados da Equipe entregam o trabalho em uma fase a 
diferentes especialistas na próxima fase. As transferências entre os silos 
são geralmente a maior área de risco. Espera-se que as Equipes Scrum 
colaborem e trabalhem de forma multifuncional em um ou alguns itens de 
cada vez. Dentro da Equipe Scrum, você não deve ouvir os membros da 
Equipe falando sobre a “Equipe de front end” ou a “Equipe de controle 
de qualidade”. A Equipe do Scrum deve estar operando como um todo.
Realize eventos do Scrum ao mesmo tempo e local. Os eventos do 
Scrum devem estar no calendário e realizados ao mesmo tempo e 
colocar cada sprint. Essa prática ajuda a criar consistência e evitar o 
desperdício associado ao reagendamento de reuniões ou à reserva dupla 
16
17
de pessoas e salas. O que vemos ocorrendo é que as reuniões são remar-
cadas, mantidas fora de sequência ou simplesmente canceladas. Muitas 
organizações operam em um ciclo contínuo de combate a incêndios e 
não veem que a adesão a uma estrutura como o SCRUM os ajudaria a 
minimizar esses incêndios. Além disso, faça as reuniões na sequência 
correta, da maneira como foram projetadas. Eu observei uma reunião de 
que foi realizada no meio do sprint. Os membros da Equipe já haviam 
esquecido o que aconteceu no sprint anterior e não foram capazes de 
incorporar melhorias na próxima.
O proprietário do produto é a única fonte de trabalho para a Equipe. 
O objetivo desta regra é ter um tomador de decisão que priorize o 
trabalho para a Equipe. Ninguém mais pode dizer à Equipe o que 
 fazer, e a Equipe não deve agir de acordo com o que os outros dizem. 
O proprietário do produto possui a lista de pendências e todo o 
trabalho é refletido na lista de pendências. Existem algumas maneiras 
pelas quais as organizações quebram essa regra. Alguns não atribuem o 
proprietário de um produto. Alguns têm um proprietário do produto, mas 
não permitem que o proprietário do produto seja o proprietário e priorize 
a lista de pendências; em vez disso, o Scrum Master, o gerente de projetos 
ou o gerente funcional o fazem. Às vezes, há um proprietário do produto 
priorizando o trabalho, mas os membros da Equipe ainda são orientados 
a trabalhar em outros itens.
Não há títulos na Equipe SCRUM além do desenvolvedor. O moti-
vo dessa regra é incentivar o comportamento multifuncional, evitar 
subEquipes e promover a propriedade da Equipe. O SCRUM procura 
evitar as ineficiências dos líderes de Equipe e subEquipes especializadas 
dentro da Equipe. Cada membro da Equipe é responsável por participar 
totalmente da Equipe. As Equipes do Scrum trabalham como Equipes de 
rugby, com o único objetivo de mover a bola para o campo. (MERSINO, 
2018, p. 2-3)
Uso de XP na Engenharia de Sistemas
A Técnica de Programação Extrema XP é muito útil quando há demandas ou 
requisitos constantemente em mudança dos clientes ou quando eles não têm certeza 
sobre a funcionalidade do sistema. 
Para tanto, XP defende “lançamentos” frequentes do produto em curtos ciclos 
de desenvolvimento, o que melhora inerentemente a produtividade do sistema e 
introduz um ponto de verificação em que quaisquer requisitos do cliente podem ser 
facilmente implementados. 
O XP desenvolve softwares mantendo o cliente como foco.
17
UNIDADE Revisão Ágil
Requisitos do
Projeto
Automação de Testes Unitários
Métricas das
Histórias
Iteração
Teste 
do Cliente
Entrada
do Cliente
Reunião de
Planejamento
de Iteração
Testes de
Aceitação
Iteração
Casos de Testes Tarefas ConclusãoHistórias
Figura 2 – Projeto XP
Os requisitos de negócios são reunidos em termos de histórias. Todas essas histó-
rias são armazenadas em um local chamado “depósito”.
Nesse tipo de metodologia, as liberações são baseadas nos ciclos mais curtos 
chamados Iterações, com período de 14 dias. Cada iteração inclui fases como codi-
ficação, teste de unidade e teste do sistema, no qual, em cada fase, algumas funcio-
nalidades menores ou maiores serão construídas no aplicativo.
São seis as fases do XP, a saber:
Quadro 1
Planejamento
• Identificação de partes interessadas e patrocinadores;
• Requisitos de infraestrutura;
• Informações e coleta relacionadasà segurança;
• Acordos de nível de serviço e suas condições.
Análise
• Captura de Histórias em Estacionamento;
• Priorizar histórias no estacionamento;
• Limpeza de histórias para estimativa;
• Definir tempo da Iteração;
• Planejamento de recursos para as Equipes de desenvolvimento e 
controle de qualidade.
Projeto
• Divisão de tarefas;
• Preparação do cenário de teste para cada tarefa;
• Estrutura de automação de regressão.
Execução
• Codificação;
• Teste de Unidade;
• Execução de cenários de teste manual;
• Geração de relatórios de defeitos;
• Conversão de casos de teste de regressão manual para automação;
• Revisão da Iteração Média;
• Revisão de fim de iteração.
Release
• Pequenas Versões;
• Teste de regressão;
• Demonstrações e críticas (lições aprendidas);
• Desenvolva novas histórias com base na necessidade;
• Melhorias de processo com base nos comentários da revisão de final 
da iteração.
18
19
Encerramento
• Lançamento do piloto;
• Treinamento;
• Lançamento de produção;
• Garantia de Nível de Serviço ou SLA;
• Revise da estratégia;
• Suporte à Produção ou Sustentação.
Sprint 0 e o Controle do
Tempo do Projeto Ágil
Sprint é a unidade básica de trabalho quando utilizamos o SCRUM. Os sprints
têm duração fixa, de modo que a Equipe tenha tempo previsível disponível para rea-
lizar o trabalho, o que, por sua vez, auxilia no planejamento de curto e longo prazo, 
conforme Berteig (2013, p. 1). 
Ao fazer com que cada Sprint tenha o mesmo comprimento, a Equipe Scrum
aprende sua própria capacidade de trabalho. Se a duração do Sprint mudar, o ritmo 
do Scrum será interrompido e uma Equipe terá de reaprender sua capacidade, o que, 
geralmente, leva pelo menos alguns Sprints. 
Se houver uma pausa entre os Sprints, a Equipe pode esquecer o que aprendeu 
ou deixar de aplicar esse aprendizado em tempo hábil no próximo Sprint.
A duração de uma Sprint determina a rapidez com que uma Equipe Scrum pode 
“inspecionar e se adaptar” a mudanças de circunstâncias e aprendizado. 
Se uma Equipe tem um Sprint de cinco semanas (ou mais), os benefícios do 
Scrum diminuem rapidamente. Em particular, você aumenta drasticamente os riscos 
associados ao planejamento de curto prazo, respondendo a mudanças, desenvolvi-
mento de Equipes, janelas de oportunidades de negócios e detecção de erros.
Mas, e a Sprint Zero?
Na maioria das vezes, as pessoas pensam na Sprint Zero como a aplicação da 
estrutura de uma Sprint Scrum normal ao processo de pré planejamento de um 
Projeto ou, como alguns dizem, “O Projeto antes do projeto”. No entanto, essa é 
uma representação simplificada, se não problemática, do significado do Sprint Zero.
Bom, para facilitar o entendimento e tirar um pouco dos mitos que envolvem esse 
artefato, vamos deixar claro para você o que ela não é:
• A Sprint Zero não é a fase em que a Equipe é montada;
• Para realizar uma Sprint, mesmo a Zero, em primeiro lugar, uma Equipe já
deve existir;
• Não se trata da fase de configuração da infraestrutura, que já deve ser imple-
mentada ou facilmente implementada sob demanda, mas não como parte da
Sprint Zero;
19
UNIDADE Revisão Ágil
• Por fim, mas sem se esgotar, uma Sprint Zero não deve envolver a adição de 
produtos a uma lista de pendências ou considerar/incluir no planejamento.
Cuidado, todas as etapas acima devem ser realizadas nas fases de pré planejamento, 
mas não como parte de qualquer Sprint, mesmo um Sprint Zero no SCRUM. 
Creio que isso que estou escrevendo pouca Literatura de Concursos ou até mesmo 
de vídeos relata, e isso é um ponto problemático para quem quer tocar um Projeto 
baseado em SCRUM ou realizar os desafios de estudo dessa Disciplina mais prática. 
Normalmente, numa Empresa estruturada e que trabalha de verdade com SCRUM, 
um grupo de colaboradores que criará a Sprint Zero é, provavelmente, composto 
por pensadores de alto nível que podem não fazer parte de outros Sprints, portanto, 
do time SCRUM desse ou de outro Projeto.
Watts (2018), bastante recentemente, nos mostra que o principal objetivo de uma 
Sprint Zero é fornecer algum valor utilizável que possa ser construído pela próxima 
Equipe (time SCRUM designado para o projeto). 
Para que essa abordagem funcione, deve haver algumas histórias no backlog 
antes do início do Sprint Zero, apenas o suficiente para que resulte em um produto 
que possa ser demonstrado.
A Sprint Zero serve para:
• Criar o arcabouço do projeto;
• Manter o design mínimo (nada desnecessário ou vultuoso, apenas o simples 
e indispensável);
• Desenvolver um pequeno número de histórias do usuário até a conclusão;
• Ser de baixa velocidade e leve (nada de complexidade para desenvolver):
O principal objetivo de um Sprint Zero é a produção. Mas um Sprint 
Zero não é necessário para desenvolver tanto software intensivo quanto 
um Scrum Sprint. De fato, as Equipes da Sprint Zero devem mantê-lo 
leve, como mencionado acima. Mais especificamente, as entregas de um 
Sprint Zero devem ser as seguintes:
• Um pedaço de código utilizável, por menor que seja;
• Um ambiente mínimo para escrever código;
• Uma priorização de recursos ou uma lista de histórias;
• Um plano de lançamento atribuindo cada história a um Sprint;
• Um plano para a implementação mais provável de recursos.
Como a ênfase de um Sprint Zero é garantir a prontidão para um Sprint, 
algumas organizações ou projetos não precisarão incorporar essa abor-
dagem. Se sua empresa produz Sprints de sucesso em projetos recentes, 
você já deve conhecer sua situação de prontidão para Sprint sem realizar 
um Sprint Zero.
Assim como outros Sprints, o Sprint Zeros deve seguir as mesmas atividades:
• Backlog atualizado;
20
21
• A sessão de planejamento da Sprint segue ;
• Reuniões diárias da Equipe Sprint ;
• Sessões de revisão de sprint ou debrief ;
• Produto entregue ;
• Retrospectiva do Sprint .
O principal benefício de um Sprint Zero é que ele permite que uma Equi-
pe tenha uma ideia do trabalho à sua frente. Eles podem se auto orga-
nizar para ter um desempenho melhor a longo prazo. Isso também cria 
confiança nos membros da Equipe de que eles podem lidar com o traba-
lho que está por vir.
Diferentemente de outros Sprints, o Sprint Zeros não deve demorar mais 
que alguns dias; uma semana no máximo. (WATTS, 2018, p. 3)
Determinação do Tempo
da Sprint do Projeto
No Scrum, uma estimativa é um dos quatro atributos prescritos de um item do 
Backlog do Produto, assim como valor, descrição e ordem, além, é claro, da inclusão 
opcional de descrições de teste, principalmente, se você está trabalhando com TDD 
(Desenvolvimento Orientado por Testes) e XP (Programação Extrema). 
Mas não se iluda: o Dono do Produto determina o valor e, por outro lado, a com-
plexidade e o esforço são atribuições da Equipe de Desenvolvimento.
Portanto, cada item do Backlog do Produto deve possuir:
• Atributos de descrição;
• Ordem e/ou prioridade;
• Estimativa;
• Valor.
O Scrumguide (2017, p. 14) escreve que a Equipe de desenvolvimento, geralmen-
te, começa projetando o Sistema e o trabalho necessário para converter o Backlog
do produto em um incremento do produto em funcionamento.
Uma coleção de itens de backlog, quando postas para serem resolvidas dentro de 
um tempo determinado, é uma Sprint (corrida), sendo que as Sprints devem seguir 
certas regras, a saber:
• Metas de qualidade pré-determinadas devem ser mantidas;
• Depois que um Sprint começa, nenhuma alteração deve ser feita para impedir
que a meta seja atrasada ou concluída;
• O escopo só pode ser renegociado entre o Scrum Master e o Product Owner;
21
UNIDADE Revisão Ágil
• O Sprint deve ter entre 2 a 4 semanas de duração.
Além disso, cada Sprint aderirá a um padrão cíclico de ações:
• Backlog atualizado;
• A sessão de planejamento da Sprint segue:
• Reuniões diárias da Equipe Sprint;
• Sessões de revisão de sprint ou debrief;
• Produto entregue;
• Retrospectiva do Sprint.
Quando um sprint termina, o backlog é atualizado para que o processo inicie 
novamente atéque o desenvolvimento do software seja concluído e encerrado. 
Complexidade é um tema central no Scrum, pois ele foi projetado para ser apli-
cado em ambientes complexos, nos quais as pessoas lidam com problemas adapta-
tivos complexos. 
Seu valor está em fazer com que as Equipes possam otimizar a previsibilidade e 
controlar os riscos, baseadas nos pilares de transparência, inspeção e adaptação.
A complexidade tem como resposta no SCRUM o exercício da transparência 
quando temos que estimar. Senão, vejamos, segundo Nijland (2018, p. 3), sem trans-
parência dada pela Equipe durante a estimativa, o Dono do produto enfrentará difi-
culdades para solicitar o backlog do produto com eficiência. 
Além disso, o exercício de estimar é realmente mais valioso do que a estimativa 
resultante. Quando estimamos coletivamente, na verdade, estamos trabalhando para 
criar um entendimento compartilhado do que é conhecido na época sobre valor (que 
revela propósito) e complexidade. As Equipes que não se importam com a estimativa 
coletiva terão essa falta de transparência assombrando-as ao longo do desenvolvimento.
Figura 3 – Uma Equipe estimando coletivamente PBIs 
(Cartões de História para compor o Backlog do Produto) por meio do Planning Poker 
Fonte: Getty Images 
22
23
Uma das coisas que impactarão profundamente as estimativas que você 
fará quando participante de um time SCRUM diz respeito à complexidade. E ela 
pode se revelar de diversas formas quando vemos um cartão de história sobre a 
mesa de um jogo de planejamento com Plannig Poker, por exemplo. 
Uma variável importante para a complexidade é a dependência. Quando 
as dependências existem, mas não são conhecidas, ocorre o caos, mas quando 
conhe-cidas, revela complicações e complexidades. 
Nesse aspecto, quero lembrá-lo(a), caro(a) aluno(a), a que me refiro como dependência. 
Conforme um Sistema de Informação vai crescendo, mesmo quando de sua 
cons-trução, e as sprints vão se acumulando, devemos nos lembrar de que quando 
vamos resolver as complexidades dos cartões para compor a próxima sprint 
devemos olhar as dependências entre as histórias e resolvê-las, levá-las em 
consideração para que possamos compor um sprint backlog possível e correto. 
Quanto mais nos adapta-mos ao criar clareza sobre dependências, melhor será 
nossa tomada de decisão.
Melhor entenderemos o quão complicado é algo provável e quanto esforço 
pro-vavelmente estará envolvido. É por isso que a estimativa costuma ser um 
exercício coletivo, pois as Equipes de desenvolvimento são multifuncionais. 
As estimativas no SCRUM são abordadas, principalmente, sobre o que já 
aconteceu, portanto, isso pode ser utilizado para tomadas de decisão prospectivas.
Quanto mais pessoas envolvidas com um item do Backlog do produto, mais 
com-plicado ele é. Por isso você deve sempre se lembrar no início de nossa 
unidade de que SCRUM coloca Equipes de desenvolvimento de 5 até 9.
Nijland (2018, p. 5) explica que a tomada de decisão, quando estamos em 
Equipes grandes, gerará muita complexidade para que um Processo empírico seja 
útil, e usa como exemplo figuras geométricas (pessoas e linhas).
23
UNIDADE Revisão Ágil
Figura 4 – Relação de complexidade versus membros da Equipe
Fonte: WENBIN, 2017, p. 1 
Como o diagrama acima ilustra, quanto mais pessoas envolvidas com um 
item do Backlog do produto, mais complicado ele é. Outra consideração 
para determinar a complexidade é o nível de consistência. A consistência 
reduz a complexidade e otimiza a previsibilidade. É por isso que é importan-
te manter os intervalos, locais e caixas de tempo dos eventos consistentes.
Trabalhar em ciclos consistentes permite que uma Equipe SCRUM avalie suas 
atividades dentro desses ciclos e detecte certos padrões e tendências.
Uma Equipe SCRUM poderia, por exemplo, acompanhar quanto tempo gasta no 
trabalho que eles não haviam previsto. Isso pode envolver a resposta à complexidade 
inesperada, mas também à mudança de prioridades, pois a Equipe ou o cliente des-
cobre algo novo de alto valor. 
Bem, como o valor e a complexidade dos itens do Backlog do Produto são esti-
mados, isso deve ser acompanhado de uma inspeção do que realmente aconteceu. 
Assim, mantemos a consistência e fazemos os ajustes às mudanças, quando pós 
executado, recalibrando a expectativa. 
E aqui vai uma reflexão para você!
Não escrevemos nesse texto sobre estimativas no SCRUM, uma linha sequer, 
 sobre cronogramas elaborados, diagramas de sequência, PERT/CPM, Gantt, cálcu-
los de rede PERT tentando dizer quanto tempo dura cada etapa, cada tarefa. 
Para SCRUM, a unidade de tempo e de produção nesse tempo é chamada 
SPRINT, e ela pode variar de 1 semana de trabalho até 4 semanas cada iteração.
24
Veja:
25
Não interessa se dentro dessa sprint existam 3 tarefas ou 10 tarefas, o que inte-
ressa é que, por exemplo, em 1 semana, todo o trabalho estimado para aquela sprint
tenha sido executado, testado, validado e entregue com valor agregado ao cliente. 
Simples assim.
SCRUM permite que, em intervalos regulares, a Equipe reflita sobre como se tornar 
mais eficaz, depois ajusta e ajusta seu comportamento de acordo com o necessário.
Nijland (2018, p. 8) expõe da seguinte maneira: o Daily Scrum não serve para 
ensinar as Equipes a seguir o plano, mas para fazer alterações à medida que mais for 
aprendido durante a execução daquela Sprint. 
A revisão e as retrospectivas da Sprint servem para permitir que a Equipe revele 
o progresso e os aprendizados reais de forma consistente.
Eles ensinarão a Equipe a agir de acordo com as experiências e as descobertas 
reais, em vez das projeções desejadas.
Por fim, em ambientes complexos, sempre haverá incerteza. Poderíamos dizer 
que o aumento da incerteza é igual ao aumento do risco. Dito isso, também existe o 
risco de assumir a certeza, o que normalmente, nesse tipo de, irá nos levará inevita-
velmente ao desastre. 
Até porque, quanto mais garantidos nos sentimos, menos preparados e abertos 
estaremos para responder com ideia novas e criativas.
Dessa forma, a incerteza de algo acaba por nos tornar melhores em lidar com 
incertezas dos negócios e dos Sistemas de Informação que os refletem.
Como resolver um problema de estimativa relacionado a um alto grau de incerte-
za, portanto, risco? 
Aproprio-me de uma atitude importante que vem do XP – Programação Extrema. 
Quando uma dificuldade técnica ameaça atrasar o desenvolvimento do Sistema, 
por exemplo, coloque um par de desenvolvedores no problema por uma semana ou 
duas e reduza o risco potencial para, quando chegar a hora, estarmos preparados. 
Isso funciona se esse pessoal for sênior, principalmente:
As Equipes costumam usar um número estimado relativo de complexida-
de e, em seguida, medem o total de quanto eles são capazes de concluir 
cada Sprint. Esta não é uma prática prescrita ou mesmo recomendada. 
A experiência nos ensinou que estes podem ser facilmente abusados, pois 
o gerenciamento organizacional pressiona as Equipes a aumentar sua ve-
locidade. Alguns até (de maneira um tanto ingênua) estabelecem metas 
para as Equipes aumentarem sua velocidade em x % durante um perío-
do de tempo. Algumas organizações simplesmente contratam um “Scum 
Master” para esse fim. A velocidade é frequentemente medida no total de 
Story Points entregues. Os Story Points são indicadores de complexidade 
e esforço. ELES NÃO REPRESENTAM VALOR. Portanto, eles não re-
25
UNIDADE Revisão Ágil
presentam o valor que está sendo entregue, apenas a complexidade sen-
do resolvida. Atletas profissionais passam muito tempo treinando como 
aperfeiçoar uma jogada aparentemente simples. Muito esforço é feito para 
tomar pequenos passos / ações, para que sejam feitos da maneira certa. 
Isso também envolve um aprendizado que não se move. Isso pode levá-los 
a um início aparentemente lento, mas o configura para aceleração rápida. 
No Scrum, as tentativas de apressar uma Equipe os desacelerarão, per-
mitindo que eles tomem o tempo necessário paradar pequenos passos 
certos, em incrementos pequenos, mas frequentes, os acelerará.
A necessidade do controle de produção através de folhas de apontamento 
está martelando a falta de confiança e envolvimento. Se a alta gestão quer 
saber como os desenvolvedores estão se saindo (e se estão realmente tra-
balhando nas coisas certas), devem trabalhar com eles (sim, é inadmissível 
no meio de TI um gerente não saber as rotinas produtivas, codificar por 
exemplo), inspecionar seu trabalho real ou confiar que eles farão seu tra-
balho corretamente, como eles fazem. (NIJLAND, 2018, p. 9)
O Scrumguides (2017, p. 10) descreve que a Equipe de Desenvolvimento é 
responsável por todas as estimativas. 
O Dono do Produto pode influenciar a Equipe de Desenvolvimento, ajudando-a 
a entender e selecionar trade-offs, mas as pessoas que executarão o trabalho fazem 
a estimativa final. 
Embora o Lean, o Agile e o DevOps tenham origem nas Equipes de Desenvolvi-
mento de Software, não são apenas essas Equipes que podem usá-los. 
As práticas Lean e Agile podem beneficiar todos os Departamentos de uma Or-
ganização. 
Devido às suas características, é mais provável que o DevOps seja usado nos 
Departamentos de TI, mas não há restrições quanto ao tipo de Departamento 
que pode adotar e usar o DevOps. 
Resumo Lean
Refere-se a um conjunto de conhecimentos chamado de Lean Manufacturing, 
ou Manufatura Lean, desenvolvido no Japão, nas décadas de 50 e 60 do século XX, 
por um engenheiro chamado Taiichi Ohno. 
O Lean transformou muitos conceitos tradicionais, como:
• A produção deve ser baseada na demanda e não na oferta. Trata-se, portanto,
de fazer algo quando alguém deseja e ordena, em vez de fazê-lo primeiro, espe-
rando que alguém precise;
26
27
• A produção é mais eficiente se realizada em pequenos lotes para aproveitar as 
economias de escala;
• Reservar um tempo para se concentrar na qualidade também aumenta a produ-
ção e a eficiência;
• Trabalhadores, não Gerentes, são responsáveis por definir sua maneira de trabalhar.
• Em vez de executar tarefas predefinidas repetidas vezes, os trabalhadores 
devem melhorar continuamente a maneira como trabalham com o Kaizen 
ou melhoria contínua.
A metodologia Lean diz para eliminar implacavelmente tudo o que não agrega valor. 
Eliminar o desperdício significa eliminar reuniões, tarefas e documentação des-
necessárias, mas também eliminar formas ineficientes de trabalho. A metodologia 
Lean também coloca uma ênfase muito forte no que chama de “sistema”, isto é, 
como a Equipe opera como um todo.
Essa metodologia alega respeitar o fato de que as pessoas que fazem o trabalho 
são as que sabem como fazê-lo melhor. Depois de oferecer a eles o que eles preci-
sam para ser eficazes, você deve deixá-los fazer isso e confiar neles. Além disso, algo 
muito importante tanto em Lean quanto em Ágil em geral é que as pessoas/traba-
lhadores que executam as tarefas são mais importantes do que as ferramentas que 
usam, e criar valor para o cliente é o único objetivo do processo de desenvolvimento.
SDLC usando LEAN para desenvolver software. Disponível em: https://bit.ly/3p0Hybi
27
UNIDADE Revisão Ágil
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Scrum – Aprenda Scrum em 9 minutos
https://youtu.be/XfvQWnRgxG0
Os Papéis do Scrum
https://youtu.be/9__bzr_lX88
Extreme Programming (XP) – Programação Extrema
https://youtu.be/ALvpFMcL-dI
Lean Software Development – Princípios
https://youtu.be/6HtpkqHswFw
28
29
Referências
BERTEIG, M. Cada Sprint é do mesmo Comprimento. 2013. Disponível em: 
<http://www.agileadvice.com/2013/05/15/referenceinformation/the-rules-of-
-scrum-every-sprint-is-the-same-length/>. Acesso em: 20/01/2020.
MERSINO, A. Sucesso com Scrum: não quebre estas 7 regras. 2018. Disponí-
vel em: <https://pmi-portland.org/news-and-content/758-7-rules-of-scrum>. Acesso 
em: 20/01/2020.
NIJLAND , S. Estimativa. 2018. p. 1-9. Disponível em: <https://medium.com/
serious-scrum/estimation-103de626551e>. Acesso em: 20/01/2020.
WATTS, S. O que é o Sprint Zero? 2018. P. 2-4. Disponível em: <https://www.
bmc.com/blogs/sprint-zero/>. Acesso em: 20/01/2020.
WENBIN, J. H. Construindo Equipes eficazes, o principal desafio é lidar com 
a complexidade das comunicações. 2017. p. 1. Disponível em: <https://john-
sonwongvp.wordpress.com/2017/10/11/building-effective-teams-main-challenge-is-
-dealing-with-the-complexity-of-communications/>. Acesso em: 20/01/2020.
Sites Visitados
AGILE ALLIANCE. Essenciais Ágeis. 2019. Disponível em: <https://www.agi-
lealliance.org/glossary/team/#q=~(infinite~false~filters~(postType~(~’page~’post
~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_
paper~’aa_video)~tags~(~’team))~searchTerm~’~sort~false~sortDirection~’asc~pa
ge~1)>. Acesso em: 20/01/2020.
________. O que é Agile? 2019. Disponível em: <https://www.agilealliance.org/
agile101/>. Acesso em: 20/01/2020.
SCRUMGUIDES. Alterações entre os Guias Scrum de 2016 e 2017. 2018. 
p. 1. Disponível em: <https://www.scrumguides.org/revisions.html>. Acesso em: 
20/01/2020.
 ________. Guia SCRUM. 2017. p. 10-14. Disponível em: <https://www.scrum-
guides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf>. 
Acesso em: 20/01/2020.
29