Fundamentos de Scrum PDF

Fundamentos
do Scrum
Rodrigo Alves Costa

A RNP – Rede Nacional de Ensino
e Pesquisa – é qualificada como
uma Organização Social (OS),
sendo ligada ao Ministério da
Ciência, Tecnologia e Inovação
(MCTI) e responsável pelo
Programa Interministerial RNP,
que conta com a participação dos
ministérios da Educação (MEC), da
Saúde (MS) e da Cultura (MinC).
Pioneira no acesso à Internet no
Brasil, a RNP planeja e mantém a
rede Ipê, a rede óptica nacional
acadêmica de alto desempenho.
Com Pontos de Presença nas
27 unidades da federação, a rede
tem mais de 800 instituições
conectadas. São aproximadamente
3,5 milhões de usuários usufruindo
de uma infraestrutura de redes
avançadas para comunicação,
computação e experimentação,
que contribui para a integração
entre o sistema de Ciência e
Tecnologia, Educação Superior,
Saúde e Cultura.
Fundamentos
do Scrum
Rodrigo Alves Costa

Fundamentos
do Scrum
Rodrigo Alves Costa
Rio de Janeiro
Escola Superior de Redes
2016
Copyright © 2016 – Rede Nacional de Ensino e Pesquisa – RNP
Rua Lauro Müller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simões
Diretor de Serviços e Soluções

José Luiz Ribeiro Filho
Escola Superior de Redes

Coordenador Nacional
Leandro Marcos Oliveira Guimarães
Edição
Lincoln da Mata
Coordenador Acadêmico da Área de Governança de TI

Edson Kowask Bezerra
Equipe ESR (em ordem alfabética)

Adriana Pierro, Alynne Figueiredo, Celia Maciel, Derlinéa Miranda, Elimária Barbosa,
Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato ,
Renato Duarte e Yve Marcial.
Capa, projeto visual e diagramação

Tecnodesign
Versão
1.0.0
Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encon-
trado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de
conteúdo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Sumário
1. Introdução
A importância da informação e a crise do software 1
Crise do software 2
Por que se tornar ágil vale a pena? 3
Exercício de fixação – Como você entende que o Scrum pode melhorar a produtividade na
sua organização? 7
Processo Scrum 8
Papéis, fluxo e artefatos do Scrum 9
Papéis do Scrum 9
Exercício de fixação – Na sua organização, que papéis atuais poderiam ocupar os papéis do
Scrum em uma eventual transição para Scrum? 9
Fluxo do Scrum 9
Visão Scrum 13
Transparência 14
Inspeção 14
Adaptação 14
Scrum e processos de desenvolvimento 14
Exercício de fixação – O que você acha que precisa mudar na mentalidade da sua organiza-
ção para adotar um processo de gestão de projetos ágil como o Scrum? 15
Introduzindo um processo ágil em uma organização 16
Desenvolvedores 16
Realizando a transição de um processo peso-pesado 16
Scrum Escalável 17
Atividades práticas – Cenário para escolha sobre um processo a ser adotado 18
iii
2. O Scrum
Fase de especificação 19
Fase de projeto 20
Fase de implementação 20
Fase de teste 20
Fase de manutenção 21
Metodologias de desenvolvimento tradicionais:

vantagens e desvantagens 21
Vantagens e desvantagens 22
Exercício de fixação – Que metodologias de desenvolvimento são utilizadas na sua organização?

Você enxerga vantagens e desvantagens no seu uso? Quais? 23
Metodologias de Ágeis de Projetos 23
Software Funcional em vez de Documentação Detalhada 24
Colaboração ao cliente em vez de negociação de contratos 24
Indivíduos e iterações em vez de somente processos e ferramentas 25
Responder à mudanças x planos detalhados 25
Velocidade e qualidade 26
Vantagens e desvantagens 26
Exercício de fixação – Você acredita que a sua organização e os seus clientes se beneficia-
riam da adoção de uma metodologia como o Scrum? 27
Histórico do Scrum 27
Toyota, uma grande influência para o Scrum 27
Exercício de fixação – Como eliminar a restrição tripla na sua organização? 28
Exercício de fixação – Você acredita ser possível ter uma equipe auto-organizável na sua
organização? Qual o contexto para possibilitar tal auto-organização? 29
Origem do nome 29
O processo 31
Empírico 31
Iterativo e incremental 32
Fases do Scrum 32
Tamanho de projetos 33
Atividades práticas – Cenários para levantamento de requisitos 33
3. A metodologia
Papéis 36
Product Owner 36
Scrum Master 36
Equipe de desenvolvimento 37
Cerimônias 38
iv
Reunião de planejamento da Sprint (Planning Meeting) 38
Reuniões diárias de Scrum (Daily) 40
Artefatos 43
Planning Poker 45
Product Backlog 51
Sprint Backlog 53
Release Burndown 54
Gráfico de Burndown 55
Task Board 57
Release 57
Atividades práticas 58
4. Scrum e a organização
Scrum e o ciclo PDCA 59
Escalando projetos com Scrum 60
Infraestrutura 61
Staging 61
Equipes distribuídas 62
Reunião de planejamento da Sprint 63
Daily Scrum 64
Szcrum of Scrums 66
Sprint reviews e retrospectivas 66
Dicas gerenciais 66
Coexistindo com outras abordagens 67
Misturando Scrum e desenvolvimento sequencial 67
Governança 68
Conformidade a padrões 69
Recursos humanos, instalações e o PMO 70
Atividades 72
v
vi
1
Introdução
objetivos
Entender a crise do Software. Por que se tornar ágil vale a pena? Introdução
ao processo scrum. Realizando a transição de um processo peso-pesado para um ágil.
conceitos
Crise do Software. Processos ágeis e Motivação. Processos peso-pesado e transição
A importância da informação e a crise do software

Existe nas organizações uma constante sinergia de pressões e forças que criam ameaças q
e oportunidades para a expansão e retração do seu negócio, e que alimenta o processo
de tomada de decisão.
É por essa razão que gestores necessitam ter cautela nesse processo, bem como contar
com ferramentas que habilitem uma decisão que seja tomada estrategicamente, orientada
de maneira a não prejudicar a organização, levando em consideração as oportunidades de
negócio e garantindo a prosperidade das empresas, e o prejuízo que pode incorrer caso
decisões sejam tomadas incorretamente.
As organizações hoje consideram a informação como o seu principal ativo – é através dela
que os gestores decidem os caminhos a serem traçados. A informação tem o poder de dar
suporte e orientar decisões de negócios.
Assim, a informação é o canal que dá acesso ao conhecimento e que contribui para a q

mudança e o aperfeiçoamento, propiciando o conhecimento necessário para a tomada
de decisão e execução das ações.
Os administradores precisam analisar como um ambiente estrategicamente alimentado em

termos de informação pode afetar a posição competitiva de uma empresa no mercado.
Nesse contexto, independente da fonte, o valor ou a validade da informação, as orga- q

Capítulo 1 - Introdução
nizações necessitam de meios de armazenamento das informações relevantes e o

realizam em seus repositórios e bancos de dados.
Na verdade, a era do acesso a repositórios online já chegou. Os usuários conectados à

internet têm a possibilidade de acessar os mais variados tipos de informação.
1
A existência de um universo rico com uma quantidade imensa de informação tem deixado
pessoas e empresas um pouco perdidas, e o tomador de decisão pode, por vezes, ficar
confuso. Ter muita informação não significa que a empresa está bem informada.
É nesse contexto que surge a ciência da gestão da informação que, para Siqueira q
Marcelo Costa, autor do livro “Gestão Estratégica da Informação”, significa “a ação
sistêmica de procurar entender as necessidades informacionais de uma organização e
disponibilizá-las para a solução de problemas organizacionais, de forma estruturada
e clara, com conhecimento pleno de todos os procedimentos e processos da solução
encontrada, garantindo assim que ele seja eficaz e repetível”.
Como se pode imaginar, ter a informação certa na hora certa e não é uma tarefa fácil.
As informações devem ser exatas, relevantes e estar disponíveis em tempo hábil.
A gestão da informação, portanto, busca resolver o problema de buscar uma forma eficiente
de coletar e processar apenas as informações essenciais e indispensáveis, uma vez que é
humanamente impossível digerir a imensa quantidade de informações colocadas à disposição.
Como o compartilhamento e a distribuição do conhecimento organizacional é condição

vital prévia para transformação de informações e experiências organizacionais isoladas em
algo que a organização possa utilizar, e sendo a informação um ativo, ou seja, um bem que
agrega valor à empresa, é necessário fazer uso de recursos de Tecnologia da Informação (TI)
de maneira apropriada.
É necessário utilizar, produzir e adquirir ferramentas de software para gerenciar bases q

de dados que cresçam à medida que a informação se transforma e se torna disponível e
relevante organizacionalmente.
Crise do software
Paralelamente a essa necessidade pela produção de software relevante, que existe até os dias q
de hoje, um termo acerca de sua produção foi firmado nos primeiros dias da ciência da com-
putação e diz respeito à dificuldade de escrever programas de computador realmente úteis e
eficientes dentro do tempo necessário para as partes interessadas: “crise do software”.
A crise do software se deu por causa das melhorias rápidas nas capacidades dos compu-
tadores, e levando em consideração as complexidades dos problemas que conseguiriam
resolver. Com o aumento da complexidade dos softwares, muitos problemas dessa
natureza surgiram porque os métodos existentes não se mostraram suficientes.
O termo “crise do software” foi cunhado pelos participantes na Conferência de Engenharia

de Software da OTAN, em 1968, em Garmisch, na Alemanha. A palestra de Edsger Dijkstra,
da ACM, de 1972, faz referência a esse mesmo problema: "A principal causa da crise de
software é que as máquinas tornaram-se várias ordens de grandeza mais potentes! Para
colocá-lo muito claramente: enquanto não havia máquinas, a programação foi nenhum
problema em tudo; quando tivemos alguns computadores fracos, a programação tornou-se
um problema leve, e agora temos computadores gigantescos, a programação tornou-se um
problema igualmente gigantesco.”
Fundamentos do Scrum
2
As causas da crise do software estão ligadas à complexidade geral do hardware e o pro- q
cesso de desenvolvimento de software. A crise manifesta-se de várias maneiras:
11 Projetos em execução que estouram o orçamento;
11 Projetos que atrasam;
11 Software que, depois de entregue, se mostrou muito ineficiente;
11 Software de pouca qualidade;
11 Software que, muitas vezes, não atendeu aos requisitos;
11 Projetos se mostraram incontroláveis com um código difícil de manter;
11 Software nunca foi entregue.
A ideia principal por trás da crise é que as melhorias no poder de computação sobre-
pujaram a capacidade dos programadores de utilizarem eficazmente esses recursos.
Vários processos e metodologias foram desenvolvidos ao longo das últimas décadas
para melhorar a gestão da qualidade de software, tais como programação processual
e programação orientada a objetos. No entanto, projetos de software que são grandes,
complicados, mal especificados e que principalmente envolvem aspectos desconhecidos
ainda são vulneráveis a problemas grandes demais, imprevistos.
Por que se tornar ágil vale a pena?

Em uma realidade de crise, equipes ágeis de sucesso têm produzido software de melhor q
qualidade que atende às necessidades do usuário mais rapidamente e a um custo menor
do que as equipes tradicionais.
As organizações que se tornam ágeis adotando um processo como o Scrum têm expe-
rimentado benefícios significativos, incluindo ganhos dramáticos de produtividade com
diminuições correspondentes em custo. Elas são capazes de levar produtos ao mercado
muito mais rapidamente e com maior grau de satisfação do cliente, além de experi-
mentar maior visibilidade do processo de desenvolvimento, o que leva a maior previsibi-
lidade de resultados.
Uma das primeiras organizações a entender esses benefícios a adotar o Scrum foi a
Salesforce.com. Fundada em 1999 em um apartamento de San Francisco, a Salesforce.
com é uma das histórias de sucesso duradouras da época das pontocom. Em 2006, com
uma receita de mais de US$ 450 milhões e 2 mil funcionários, a Salesforce.com notou que
a frequência das suas releases tinha diminuído de quatro por ano para apenas uma. Os
clientes estavam recebendo menos entregas e esperando mais tempo para obtê-las, e algo
precisava ser feito. A empresa decidiu a transição para Scrum. Durante o primeiro ano de
mudança, a Salesforce.com:
11 Liberou 94% mais funcionalidades;
11 Entregou 38% mais funções por desenvolvedor;
11 E mais de 500% mais valor aos seus clientes em relação ao ano anterior.
Nos dois anos seguintes, a receita mais que dobrou, para mais de US$ 1 bilhão. Com
resultados como esses, não é surpreendente que tantas organizações fizessem a tran-
sição para Scrum. Ou pelo menos tentassem.
A transição para Scrum e outros métodos ágeis é difícil: muito mais difícil do que muitas
empresas antecipam. As alterações necessárias para colher todos os frutos que se tornar
ágil pode trazer são de longo prazo. Tais mudanças exigem grande quantidade de esforço
não só por parte dos desenvolvedores, mas de toda a organização. Não se trata apenas de
3
uma mudança das práticas, é necessário mudar a mentalidade e a forma de trabalho esta-
belecida. O objetivo deste curso, portanto, não é apenas mostrar como fazer essa transição
adequadamente, mas também como obter sucesso no longo prazo.
Toda mudança é difícil. Mudanças maiores podem ser ainda mais difíceis. No entanto, q
existem ainda certas características de transição para Scrum que o tornam mais difícil
do que a maioria das outras mudanças.
Uma mudança, para ser considerada de sucesso, não depende exclusivamente de ser
de cima para baixo ou de baixo para cima (ou seja, há múltiplos fatores que determinam
o sucesso da mudança): em uma mudança top down (de cima para baixo), um líder
influente compartilha uma visão do futuro e a organização segue o líder em direção a
essa visão.
Imagine um líder carismático, respeitado e poderoso como Steve Jobs dizendo a seus
funcionários da Apple que eles são se movendo “para além de hardware e software de
computador para dominar a música digital”. A sua reputação e estilo poderia ter apontado
a empresa em uma nova direção, mas isso por si só não teria sido suficiente para realizar
uma proeza tão improvável. Da mesma forma, sem compromisso operacional, as pessoas
l
O estado final é
resistem à cadeia de comando. Assim, a participação bottom-up (de baixo para cima) será imprevisível: uma
necessária, pois será o indivíduo, ou seja, os membros da equipe que trabalham com as transição para Scrum
não pode ser tal que
questões que vão descobrir como Scrum vai funcionar melhor dentro de sua organização.
“articula e define o todo
Assim, a chave para qualquer sucesso na adoção de Scrum será a combinação elementos de o processo de mudança
bottom-up e mudança top-down. necessária para
preencher a lacuna
Criar esse plano exigiria saltar dois obstáculos impossíveis: em primeiro lugar, saber exata- entre ‘como’ e ‘ser’ e
cria planos táticos”,
mente onde nós queremos acabar e, em segundo, saber exatamente os passos para chegar
como em um de
lá. Como não podemos superar essas impossibilidades, o melhor que se pode fazer é adotar gerenciamento de
uma abordagem de “provocar e observar” (Avery De, 2005), em que se pode tentar algo, ver mudanças tradicional,
segundo Carr, Duro, e
se ele nos move mais perto de um objetivo intermediário, verificar se o estado melhorou e, Trahant.
em caso afirmativo, fazer mais do mesmo. Esses processos da organização não são aleató-
rios, são cuidadosamente selecionados com base na experiência, conhecimento e intuição,
para dirigir uma transição para o Scrum.
l
Apresentar a revisão de prontidão operacional quase certamente vai impactar as finanças, Scrum é generalizada:
vendas ou outros departamentos. Portanto, cada um desses departamentos pode ser se tornar ágil terá
implicações para a
afetado pela Scrum. Dessa maneira, grupos financeiros terão de conciliar as políticas da organização que vão
empresa na capitalização com a maneira de como projetos Scrum se comportam quando muito além do
departamento de
estão em execução. As vendas e o marketing podem querer alterar como comunicam os
desenvolvimento de
seus prazos e o escopo, e podem mudar a forma como estruturam contratos. Com mais software.
grupos afetados por uma mudança para o Scrum, há mais chance para aumentar a resis-
tência e certamente mais chance de problemas, o que pode tornar a transição para Scrum
ainda mais difícil.
l
Muitos testadores, por exemplo, aprendem ao longo dos anos que o seu trabalho é testar Scrum é dramatica-
para conformidade com uma especificação de requisitos. Por sua vez, os programadores mente “diferente”: as
mudanças criadas
foram treinados para analisar um problema em profundidade e para conceber uma solução através da adoção do
perfeita antes que qualquer codificação comece. Em um projeto Scrum, testadores e progra- Scrum se permeiam ao
longo do desenvolvi-
madores precisam desaprender esses comportamentos. Testadores passam a entender que
mento, e muitas dessas
o teste é também entender que o sistema precisa estar em conformidade com as necessi- mudanças vão de
dades do usuário. Já os programadores entendem que um design nem sempre é necessário encontro à formação
passada da maior parte
(e às vezes nem mesmo desejável) antes que a codificação comece.
dos funcionários.
4
Como a transição para Scrum inclui pedir às pessoas para trabalhar de uma forma diferente
daquela que estão familiarizadas, ou seja, de uma forma que contradiz aquela da sua for-
mação e experiência, os funcionários muitas vezes se apresentam muitas vezes resistentes
à mudança.
As melhores práticas são arriscadas: como a maior parte de toda e qualquer

mudança organizacional, depois que alguém descobre a melhor maneira de fazer
alguma coisa, essa forma de fazer é capturada e registrada como uma “melhor
prática”, e compartilhada com todos os outros.
Para alguns tipos de trabalho, a coleta e reutilização de melhores práticas é uma tremenda
ajuda para o esforço de mudança. Por exemplo, uma organização que está vendendo um
produto para um novo tipo de cliente pode capturar as melhores práticas para superar
objeções por parte dos prospectos. Ao fazer a transição para Scrum, no entanto, a coleta
de melhores práticas pode ser arriscada, pois elas tentam fazer a equipe “relaxar e parar o
esforço de melhoria contínua”, que é essencial ao Scrum.
Embora os membros da equipe devam sempre pesquisar para compartilhar uns com os
outros as suas recém-descobertas acerca das melhores formas de trabalhar, eles devem
resistir ao impulso de codificá-las em um conjunto de melhores práticas.
Apesar de todas as razões pelas quais a transição para Scrum pode ser particularmente
difícil, partes interessadas nas organizações que a realizaram têm o tempo para o mercado
de seus produtos reduzido e se mostram satisfeitos depois de implementar um processo
ágil como Scrum.
Esse tempo de colocação no mercado mais rápido é possibilitado pela maior produtividade
das equipes ágeis, o que por sua vez é o resultado da maior qualidade de projetos nessa
disposição. Como os funcionários podem realizar trabalhos de alta qualidade e como eles
passam a ver o seu trabalho entregue mais cedo nas mãos dos usuários, a satisfação com o
trabalho sobe. Com maior satisfação dos funcionários, nota-se maior envolvimento, o que
leva a ganhos de produtividade, iniciando um ciclo virtuoso de melhoria contínua.
Podemos listar as seguintes razões porque uma transição para um processo ágil como q
Scrum é importante:
Aumento da produtividade e redução de custos
Infelizmente, não há medidas universalmente padronizadas para medição de produ-

tividade. Martin Fowler (2003) diz que medir a produtividade dos desenvolvedores de
software é impossível. No entanto, algumas equipes usam medidas como o número de
linhas de código como uma entrada para a produtividade. Outros usam como o número
de pontos de função, ou seja, pontos entregues ao cliente. Algumas equipes medem sua
produtividade por meio do número de características entregues, ignorando que nem
todas as características são do mesmo tamanho.
Obviamente, nenhuma dessas formas de medir produtividade é perfeita, mas a utilidade de se

tentar medi-la encontra-se na aproximação do entendimento do que se quer gerenciar.
Nesse sentido, a QSMA calcula sua produtividade por meio de um sistema que considera q
esforço, cronograma, dificuldade técnica das atividades e alguns outros fatores em uma
tentativa de realizar comparações entre equipes mais significativas.
5
Em sua comparação entre projetos tradicionais e ágeis, Mah (2008) entende que projetos
ágeis são 16% mais produtivos em qualquer situação. A figura 1.1 mostra a comparação de
projetos ágeis (pontos) comparado com a produtividade média de o desvio padrão na base
de dados da QSMA.
Como se pode ver, a maioria dos pontos encontra-se acima da média da indústria, com q
uma boa parte dos projetos mais de um desvio padrão acima de um nível de produtivi-
dade dessa média.
Alto
+/- 1 Desvio padrão
Produtividade
Média
Figura 1.1
Equipes ágeis são
significativamente
Projetos ágeis
mais produtivos
Baixo que a média da
Menor Maior indústria.
Tamanho do projeto
Os resultados da QSMA são corroborados por outras pesquisas, tais como as da DDJ e
VersionOne. De acordo com a primeira, 82% dos participantes sentiram que a produtividade
foi um pouco ou muito mais elevada do que antes, quando se utiliza métodos ágeis como o
Scrum. De acordo com a VersionOne, 73% acreditava que ser ágil tinham significativamente
melhorado (23%) ou melhorado (50%) a produtividade.
Ora, é razoável entender que, se os funcionários em uma organização são mais produtivos,
os custos serão menores. Embora encorajadores, esses números contam apenas parte
da história. Uma das críticas dos processos tradicionais é que eles são tão onerosos. Que,
muitas vezes, quando o software é entregue, algumas funcionalidades – ou o aplicativo
inteiro – não são mais necessárias. Um benefício significativo de ser ágil é que equipes ágeis
possuem a tendência de produzir apenas funcionalidades necessárias. Graças ao feedback
constante e à habilidade de priorizar novamente a cada Sprint, uma equipe Scrum é capaz
de trabalhar apenas naquelas funcionalidades que os usuários realmente precisam. Se isso
for incluído no nosso requisito de produtividade, provavelmente veríamos resultados ainda
mais dramáticos.
De acordo com o levantamento de Rico, com base em estudos de caso de equipes ágeis q
publicados até 2016, mostrada na tabela 1.1, há um aumento médio de produtividade de
88% e economias de 26% de custos quando se transiciona para ágil. Esses indicam uma
evidência sólida de que equipes ágeis são mais produtivas, o que leva à redução de
custos para os seus projetos.
Categoria Melhoria Mais Melhoria Média Melhoria Mais

Baixa Alta
Tabela 1.1
Produtividade 14% 88% 384%
Melhorias
Custo 10% 26% 70% verificadas com ágil
por categoria.
6
Exercício de fixação e
Como você entende que o Scrum pode melhorar a produtividade na
sua organização?
O envolvimento dos funcionários melhora também a satisfação no trabalho
Um fator que contribui para a maior produtividade e menores custos em projetos ágeis
é: os trabalhadores passam a gostar mais do que fazem. Quinze meses após a adoção do
Scrum, a Salesforce.com realizou uma pesquisa junto a seus funcionários e constatou que
l 86% estavam “gostando” ou o “gostando muito” de trabalhar na empresa. Antes de adotar

Uma razão pela qual os Scrum, apenas 40% respondiam a mesma coisa. Além disso, 92% dos funcionários disseram
funcionários podem que recomendariam uma abordagem ágil para os outros. Resultados como esses são
aproveitar mais os seus
trabalhos é devido ao comuns. Em seu levantamento na indústria, a VersionOne constatou que 74% dos entrevis-
ritmo sustentável tados relataram que a “moral” foi melhorada (44%) ou significativamente melhorada (30%).
promovido por
processos ágeis. Time to Market mais rápido
Equipes ágeis tendem a lançar seus produtos mais rapidamente do que as equipes tradi- q
cionais. De acordo com o estudo da VersionOne, 64% dos participantes relataram que o
tempo de comercialização foi melhorado (41%) ou significativamente melhorado (23%).
O estudo da QSMA comparou 26 projetos ágeis em uma base de dados de 7.500
projetos, em sua maioria tradicionais, chegando à conclusão de que os projetos ágeis
chegaram 37% mais rapidamente ao mercado, como mostrado na figura 1.2.
Alto
Projetos ágeis
+/- 1 Desvio padrão
Time to market
Média
Figura 1.2 Projetos

ágeis possuem
um time to Market
Baixo
37% mais rápido
Menor Maior
comparado com a
média da indústria. Tamanho do projeto
Melhoria na satisfação das partes interessadas

Tendo em conta todos os benefícios de processos ágeis até agora, não é surpreendente q
que eles conduzam a uma melhoria na satisfação das partes interessadas. A pesquisa da
DDJ descobriu que 78% dos participantes da pesquisa acreditam que o uso de um pro-
cesso ágil levou a uma melhoria “um pouco maior” (47%) ou “muito mais elevada” (31%)
na satisfação das partes interessadas.
Uma das razões pelas quais as partes interessadas ficam mais satisfeitas com processos ágeis
é porque as suas práticas são mais amigáveis com relação às mudanças de prioridades, o que
é uma necessidade na vida das organizações de ritmo acelerado e competitivo de hoje.
No estudo da VersionOne, 92% dos participantes consideraram que as metodologias q

ágeis melhoraram a capacidade de gerenciar mudanças de prioridades.
7
Além disso, juntamente com a capacidade de mudar mais facilmente as prioridades, as
partes interessadas em projetos ágeis aprendem a gerenciar o impacto da mudança. Outras
razões incluem a melhoria na visibilidade dos projetos, a melhoria do alinhamento da TI e
objetivos de negócio, e a redução de riscos de projeto.
O que as organizações têm feito não funciona

Uma razão final para considerar a mudança para o Scrum é se o seu processo de desen-
volvimento atual não está mais funcionando. Quando um processo que até funcionou no
passado encontra muitas barreiras, uma tendência comum é “fazer mais do mesmo”. Esse foi
certamente o caso no Yahoo!, onde o diretor de produto Pete Deemer foi um dos primeiros a
reconhecer a necessidade de mudança: “Inicialmente, o Yahoo! tentou Scrum puramente por
desespero. A abordagem sequencial claramente não estava funcionando, e fizemos uma ten-
lCrie cartões para
tativa de um ano para fazer a sequencial ‘melhor’ através de um planejamento e uma análise compartilhar com
outras equipes com os
mais aprofundada de documentos, mais sign-offs e, assim por diante, era tornar as coisas seus resultados,
piores, não melhores. Para as equipes que viram benefícios, que eram a maioria das equipes explicando por que vale
a pena mudar para o
que tentaram Scrum, os benefícios eram visíveis quase que imediatamente.”
q
Scrum, se mostrarem
interesse na transição.
Assim, ao adotar o Scrum, é interessante identificar continuamente os benefícios
Isso pode diminuir a
obtidos até determinado ponto, selecionar fatores de interesse da organização e fazer resistência da
com que tais fatores sejam uma linha de base contra a qual se possa comparar mais organização como um
todo.
tarde – uma boa dica é qualidade, moral da equipe e satisfação das partes interessadas.
Processo Scrum
Todas as práticas do Scrum estão cravadas em um esqueleto de processo incremental. q
Esse esqueleto é mostrado na figura 1.3. O círculo de baixo representa uma iteração de
atividades de desenvolvimento que ocorrem uma após a outra, e a saída de cada uma
delas é um incremento no produto. Já o círculo superior representa uma espécie de
inspeção diária que ocorre durante a iteração citada anteriormente, durante a qual cada
membro da equipe se reúne para acompanhar as atividades umas dos outros e realizar
adaptações adequadas. O que guia as interações são uma lista de requisitos e o ciclo se
repete enquanto houver orçamento disponível para o projeto.
Reunião de
24 h
Scrum Diária
2 – 4 semanas
Product Sprint Incremento Figura 1.3

Backlog Backlog no Produto O processo Scrum.
q
O esqueleto de processo funciona da seguinte maneira: no início de uma iteração, a

equipe analisa o que deve fazer. Em seguida, seleciona o que acredita que pode se trans-
formar em um incremento potencialmente utilizável de funcionalidade até no final de
um ciclo da iteração, que dura entre duas e quatro semanas. Cada ciclo desses é conhe-
cido como Sprint. A equipe é então deixada sozinha para fazer o seu trabalho durante a
Sprint. No final, ela apresenta o incremento de funcionalidade que construiu, de modo
que as partes interessadas podem inspecionar a funcionalidade e as adaptações opor-
tunas para que o projeto possa ser feito.
8
O coração de Scrum reside na iteração. A equipe lança um olhar sobre os requisitos, con- q
sidera a tecnologia disponível, e avalia as suas próprias habilidades e capacidades. Em
seguida, coletivamente determina como construir a funcionalidade, modificando a sua
abordagem diariamente, à medida que encontra novas complexidades, as dificuldades e
surpresas. A equipe descobre o que precisa ser feito e seleciona a melhor maneira de fazê-
lo. Esse processo criativo é o coração da produtividade Scrum.
Papéis, fluxo e artefatos do Scrum

Papéis do Scrum
Scrum possui três papéis: product Owner, Scrum Master e a equipe.
11 Product Owner: o Product Owner deve ser a pessoa com visão, autoridade e dispo- q
nibilidade. O Product Owner é responsável por se comunicar continuamente com o
time de desenvolvimento sobre a visão do projeto e as prioridades.
Muitas vezes, é difícil para os Product Owners atingir o ponto ideal de envolvimento. Como
Scrum valoriza auto-organização entre equipes, um Product Owner deve lutar a necessi-
dade de microgerenciar. Ao mesmo tempo, Product Owners devem estar disponíveis para
responder questões da equipe;
11 Scrum Master: o Scrum Master age como um facilitador para o Product Owner e q
para a equipe. O Scrum Master não gerencia a equipe. O Scrum Master trabalha para
remover quaisquer impedimentos ou barreiras que porventura venham atrapalhar a
equipe para atingir os objetivos da Sprint.
Isso ajuda a equipe a se manter criativa e produtiva ao mesmo tempo em que garante que seus
sucessos estão visíveis ao Product Owner. O Scrum Master também trabalha para auxiliar o
Product Owner em como maximizar o ROI (retorno sobre investimento) para a equipe;
11 Equipe: de acordo com os criadores do Scrum, “a equipe é totalmente autogeren- q

ciável”. A equipe de desenvolvimento é responsável por se auto-organizar para
completar o trabalho. Uma equipe de desenvolvimento Scrum contém mais ou menos
sete membros completamente dedicados (oficialmente de 3 a 9), idealmente em uma
sala protegida de distrações externas.
Para projetos de software, uma equipe típica inclui uma mistura de engenheiros de sof-
tware, arquitetos, programadores, analistas, especialistas em qualidade, testadores e desig-
ners de interface gráfica. A cada Sprint, a equipe é responsável por determinar como vai
conseguir finalizar o trabalho. A equipe possui a autonomia e responsabilidade para atingir
os objetivos da Sprint.
Na sua organização, que papéis atuais poderiam ocupar os papéis do Scrum
em uma eventual transição para Scrum?
Fluxo do Scrum
Um projeto Scrum começa com uma visão do sistema a ser desenvolvido. A visão pode q
ser vaga no início, talvez expressa em termos de mercado, em vez de requisitos de
sistema, mas ela se tornará mais clara à medida que o projeto avança.
9
O Product Owner é responsável por garantir o financiamento do projeto e por entregar a q
visão de uma forma que maximiza o retorno do investimento. O Product Owner também
formula um plano para fazê-lo, que inclui um Product Backlog. O Product Backlog é uma
lista de requisitos funcionais e não funcionais que, quando transformado em funciona-
lidade, vai entregar essa visão. O Product Backlog é priorizado para que os itens com
maior probabilidade de gerar valor sejam prioridade e estejam divididos em lança-
mentos propostos.
O Product Backlog priorizado é um ponto de partida, e os seus conteúdos, as priori-

dades, e agrupamento em releases geralmente muda no momento do início do projeto,
como esperado. Mudanças no Product Backlog refletem mudanças nos requisitos de
negócios e quão rapidamente a equipe pode transformar esses requisitos em funcionali-
dade implementada.
Todo o trabalho é feito em Sprints. Cada Sprint é uma iteração de 30 ou 15 dias conse-
cutivos e é iniciada com uma reunião de planejamento, onde o proprietário do produto
e equipe se juntam para colaborar sobre o que será feito para a próxima Sprint. A ideia
é que o Product Owner selecione o item de mais alta prioridade no Product Backlog, e
que a equipe explique ao mesmo o quanto do que é desejado ela acredita que pode ser
transformado em funcionalidade ao longo da próxima Sprint. Reuniões de planejamento
da Sprint não podem ser muito demoradas, não devendo durar mais do que oito horas,
evitando muita angústia sobre o que é possível. O objetivo é começar a trabalhar, não
pensar em planejar o trabalho.
Todos os dias, a equipe se reúne para uma reunião de 15 minutos chamada Daily Scrum.
O objetivo da reunião é sincronizar o trabalho de todos os membros da equipe diaria-

mente e agendar quaisquer reuniões adicionais que a equipe necessite para transmitir o
seu progresso.
No final da Sprint, uma reunião de revisão da Sprint é realizada. Essa é uma reunião de
quatro horas em que a equipe apresenta o que foi desenvolvido durante a Sprint para o
Product Owner e quaisquer outros interessados que queiram participar. Trata-se de uma
reunião informal em que a funcionalidade é apresentada e destina-se a reunir as pessoas
e ajudá-los de forma colaborativa, determinando o que a equipe deve fazer a seguir.
Após a revisão da Sprint, e antes da próxima reunião de planejamento da Sprint, o

ScrumMaster realiza uma reunião retrospectiva da Sprint com a equipe. Nessa reunião,
o ScrumMaster encoraja a equipe a rever seu processo de desenvolvimento, no âmbito
e práticas do processo Scrum, para torná-lo mais eficaz e agradável para a próxima
Sprint. Juntos, a reunião de planejamento da Sprint, o Daily Scrum, a revisão Sprint e a
retrospectiva da Sprint constituem as práticas de inspeção e de adaptação empíricos de
Scrum.
Na figura 1.4, podemos encontrar o processo Scrum estendido, incluindo as reuniões

recém-citadas.
10
A cada
24 horas
Scrum diário
Sprint
Nova funcionalidade
Backlog da Sprint demonstrada ao ﬁnal
da Sprint
Selected Product Backlog
Backlog do Produto: Emergente,

requisitos priorizados
Visão: ROI esperado,

lançamentos, Millestore
Artefatos
q
Figura 1.4
Visão geral do Scrum introduz alguns novos artefatos. Estes são utilizados em todo o processo de
processo do Scrum.
scrum e são descritos a seguir.
Product Backlog
Os requisitos para o sistema ou produto que está sendo desenvolvido pelo projeto estão q
listados no Product Backlog. O Product Owner é responsável pelo conteúdo, priorização
e a disponibilidade do Product Backlog. O Product Backlog nunca está completo,
finalizado, ou seja, o Product Backlog utilizado no plano de projeto é apenas uma
estimativa inicial das necessidades e evolui à medida que o produto e o ambiente em
que será usado evolui. Em outras palavras, o Product Backlog é dinâmico e a gestão
muda constantemente tal documento para identificar o que o produto necessita para
Tabela 1.2 que seja adequado, competitivo e útil. Enquanto o produto existir, o Product Backlog
Product Backlog. existe. Um exemplo pode ser encontrado na tabela 1.2:
Product Backlog
Requisito Num Categoria Status Pri Estimativa
Registrar requisitos na base de dados 17 funcionalidade em curso 4 5

Processar cenário de saque simples 232 caso de uso em curso 4 60
Aprovação de crédito muito lento 12 problema não iniciado 3 10
Cálculo de comissão de venda 43 defeito finalizado 2 2
Captura de venda em ponto de venda 321 melhoria não iniciado 1 100
Processar cenário de crédito PMT 45 caso de uso em curso 3 30
11
Sprint Backlog
O Sprint Backlog define o trabalho (ou as tarefas que uma equipe define para transformar os q
itens do Product Backlog que ele escolheu para o Sprint), de maneira a transformá-lo em um
incremento de funcionalidade do produto potencialmente utilizável. Somente o time pode
mudar o Sprint Backlog. O Sprint Backlog deve ser altamente visível, e deve ser um quadro
que demonstra em tempo real o trabalho que a equipe planeja efetuar durante a Sprint.
Um exemplo de um Sprint Backlog é mostrado na tabela 1.3. As linhas representam

tarefas do Sprint Backlog; as colunas representam os 30 dias no Sprint. Uma vez que uma
tarefa é definida, a estimativa do número de horas restantes para completar a tarefa é
colocada no cruzamento da tarefa, e o dia Sprint pela pessoa que trabalhe com a tarefa.
Sprint Backlog
Horas de trabalho restantes por dia

Descrição da
Responsável
Atividade
Origem
Status
1 2 3 4 5 6 7 8 9 10 11 12
Release do Rosa João em curso 8 8 8 8 8 8 8 8 8 8 8 8

serviço
Gerar docu- Pedro não 16 16 16 16 16 16 16 16 16 16 16 16

mentação iniciado
do SDK
Disponibilizar João não 6 6 6 6 6 6 6

documen- iniciado
tação na wiki
LDAP: grupos Maria finalizado 26 18 10 2 0 0 0 0 0 0 0 0

de suporte
Documen- Pedro não 4 4 4 4 4 4 4 4 4 4 4 4

tação de iniciado
branch:
fontes e
builds
Impedir Maria finalizado 20 12 4 0 0 0 0

criação de
relações
"erradas"
Descrever Pedro em curso 64 58 50 42 34 26 18 10 2 2 2 2

extensão
de PDA
Incremento potencialmente utilizável de funcionalidade de produto Tabela 1.3
q
Sprint Backlog.
Scrum exige que os times desenvolvam um incremento de funcionalidade do produto a
cada Sprint. Esse incremento deve ser potencialmente utilizável, porque o Product
Owner pode optar por implementar a funcionalidade imediatamente.
12
l Isso requer que os incrementos precisem ser exaustivamente testados e bem estruturados,
Essa é a definição
de um incremento que o código seja construído em um arquivo executável e que a funcionalidade implemen-
“pronto”. tada para operação do usuário seja escrita em um código bem documentado e disponibili-
zada em arquivos de ajuda ou em outra documentação de usuário acordada.
Visão Scrum
Scrum é uma ferramenta para desenvolver e manter produtos complexos. A ciência do q
Scrum está por trás do desenvolvimento de software complexo.
Obviamente tal fato não é muito surpreendente, porque o universo é cheio de complexi-
dades. A maioria delas são desconhecidas para a maioria das pessoas. Algumas – como
o processo através do qual a pressão transforma carvão em diamantes, por exemplo, é
irrelevante para a maioria das pessoas por ser natural e cuidar de si mesma. Outras, como o
deslocamento para o trabalho diariamente, podem tolerar alguma imprecisão.
No entanto, é impossível ignorar a complexidade no desenvolvimento de software. Seus q

resultados são efêmeros, consistindo apenas de sinais que controlam máquinas de estado.
O processo de desenvolvimento de software é totalmente intelectual, e todos os seus

produtos intermediários são representações marginais dos pensamentos envolvidos.
Os materiais que usamos para criar o produto final são extremamente voláteis: os requisitos
dos usuários para um programa que utilizarão no futuro, a interoperabilidade de sinais
entre outros programas com o aplicativo a ser desenvolvido e a interação dos organismos
mais complexos do planeta – pessoas.
Dessa forma, Scrum se propõe a ser visto como um quadro no qual as pessoas podem q
resolver os problemas adaptativos complexos, ao mesmo tempo em que o realizam de
forma produtiva e fornecem, de maneira criativa, produtos de maior valor possível. Scrum é:
11 Leve (Lightweight);
11 Simples de entender;
11 Difícil de dominar.
Scrum é uma estrutura de processo que tem sido utilizada para gerenciar o desenvolvimento
de produtos complexos desde o início da década de 1990. Scrum não é um processo ou
uma técnica para a construção de produtos; ao contrário, é um quadro no qual você pode
empregar vários processos e técnicas.
Scrum torna clara a eficácia relativa das suas práticas de gestão e desenvolvimento de pro-
dutos para que você possa melhorar. O framework Scrum consiste em equipes Scrum e seus
papéis associados, eventos, artefatos e regras. Cada componente no quadro serve a um
propósito específico e é essencial para o sucesso e uso do Scrum.
As regras do Scrum unir os eventos, papéis e artefatos, que rege as relações e interações q
entre eles. As regras de Scrum são descritas ao longo desse documento. Táticas espe-
cíficas para o uso do framework Scrum variam. Scrum é fundada na teoria de controle
de processos empíricos: o empirismo. Essa teoria afirma que o conhecimento vem de

decisões de experiência, preparando com base no que é conhecido. Scrum emprega uma
abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.
São três os pilares que sustentam qualquer implementação de controle de processos empí-
ricos: a transparência, a inspeção e a adaptação.
13
Transparência
Aspectos significativos do processo devem ser visíveis para os responsáveis pelo resul- q
tado. A transparência exige que esses aspectos sejam definidos por um padrão comum
de modo que observadores compartilhem um entendimento comum sobre o que está
sendo visto. Por exemplo:
11 Uma linguagem comum referindo-se ao processo deve ser partilhada por todos
os participantes;
11 Aqueles que executam o trabalho e aqueles que aceitam o produto do trabalho

devem compartilhar uma comum definição de “Pronto”.
Inspeção
Usuários de um projeto do Scrum devem frequentemente inspecionar artefatos pro- q
duzidos pelo projeto e progredir em direção a uma meta de uma Sprint para detectar
variações indesejáveis. Obviamente, a inspeção não deve ser tão frequente de maneira a
tornar a inspeção uma barreira ao trabalho.
As inspeções são mais benéficas quando a diligência é realizada por inspetores qualifi-
cados no trabalho.
Adaptação
Se um inspetor determina que um ou mais aspectos de um processo se desvia dos q
limites aceitáveis e que o produto resultante será inaceitável, o processo ou o material a
ser processado tem de ser ajustado. Um ajuste deve ser feito o mais rapidamente pos-
sível para impedir desvios futuros.
Os eventos prescritos pelo Scrum para garantir inspeção e adaptação são:
11 Planejamento da Sprint;
11 Scrum diária;
11 Revisão da Sprint.
11 Retrospectiva da Sprint
Scrum e processos de desenvolvimento

A abordagem Scrum para o desenvolvimento de software ágil marca uma saída radical q
das abordagens tradicionais. Scrum e outros métodos ágeis foram inspirados pelas defi-
ciências daquelas abordagens, e enfatizam em colaboração, software funcional, auto-
gestão de equipe e na flexibilidade a adaptar-se a necessidades emergentes de negócios.
Essas necessidades são as mais comumente verificadas em negócios de software, cujos
clientes normalmente não conhecem todos os requisitos de negócio no começo do
projeto, e têm necessidades emergentes durante a sua execução.
Scrum é parte do movimento ágil. Esse é uma resposta à falha da maioria dos para-
digmas de gestão de projetos de desenvolvimento, e toma emprestado muitos princí-

pios de lean manufacting. Em 2011, 17 pioneiros de métodos similares se reuniram no
Resort Snow Bird Ski, em Utah, e escreveram o Manifesto Ágil, uma declaração de quatro
valores e doze princípios. Esses valores e princípios contradizem fundamentalmente as
áreas de conhecimento tradicionais do PMBoK.
No entanto, o Manifesto Ágil não provê passos concretos. As organizações normalmente

procuram métodos mais específicos dentro do movimento Ágil. Estes incluem Crystal Clear,
14
Extreme Programming, Desenvolvimento Orientado a Funções, Scrum e outros. Tipica-
mente, uma solução que possui definições simples como o Scrum habilita a equipe com a
autonomia necessária para realizar o melhor trabalho enquanto auxilia a alta gestão (cujos
membros podem se tornar Product Owner) a obter os resultados de negócio que desejam.
Scrum é capaz de abrir portas para outras abordagens ágeis úteis como desenvolvimento
orientado a testes. Uma organização realmente ágil dificilmente possui um lado “técnico” e
um lado “de negócios”, mas possui equipes trabalhando diretamente que desejam entregar
valor de negócios. Ora, os melhores resultados de negócios são entregues quando o negócio
inteiro está envolvido no processo.
Os primeiros defensores do Scrum foram inspirados por ciclos de feedback de inspeção

e adaptação para se adaptar a complexidade e risco. Scrum enfatiza que o processo de
decisão deve ser baseado em resultados do mundo real, em vez de especulação. O tempo
deve ser dividido em cadências pequenas de trabalho, conhecidas como Sprints, de uma
ou duas semanas. O produto é mantido em um estado potencialmente entregável (ou seja,
adequadamente integrado e testado) o tempo inteiro. No fim de cada Sprint, as partes inte-
ressadas e os membros de equipe se reúnem para uma demonstração de uma melhoria do
produto e planejar seus próximos passos.
Dessa forma, podemos ver Scrum como um conjunto simples de papéis, responsabilidades
e reuniões que nunca mudam. Ao remover toda imprevisibilidade não necessária, é possível
se adaptar à necessária imprevisibilidade da descoberta e aprendizagem típica dos projetos.
Assim, as regras e práticas para Scrum – um processo simples para gerenciar projetos
complexos – são poucas, diretas e fáceis de aprender. No entanto, a simplicidade do Scrum
em si e sua falta de prescrição podem ser tão sensibilizantes que novos praticantes acabam
em situações em que aos poucos revertem para velhos hábitos e ferramentas de gestão de
projetos, produzindo resultados menos satisfatórios.
Assim, para entender a base na teoria e prática do Scrum, é necessária uma mentalidade q
que possibilite:
11 Controlar até mesmo os mais complexos projetos;
11 Gerir eficazmente os requisitos do produto desconhecidos ou mudança;
11 Simplificar a cadeia de comando com as equipes de desenvolvimento de autogestão;
11 Receber mais claras especificações e feedback de clientes;
11 Reduzir grandemente o tempo de planejamento de projeto e ferramentas necessárias;
11 Construir e lançar produtos em ciclos de 30 dias para que os clientes obtenham resul-
tados mais cedo;
11 Evitar erros inspecionando regularmente relatórios sobre os projetos e realizar ajuste

fino constantemente sobre estes;
11 Apoiar várias equipes trabalhando em um projeto em larga escala a partir de muitas

localizações geográficas;
11 Maximizar o retorno sobre o investimento.

O que você acha que precisa mudar na mentalidade da sua organização para
adotar um processo de gestão de projetos ágil como o Scrum?
15
Introduzindo um processo ágil em uma organização
O Manifesto Agil estabelece uma base comum para esses processos: valorizar mais q
os indivíduos e as interações que os processos e as ferramentas, trabalhar mais no
software do que no detalhamento da documentação, colaborar mais com o cliente na
negociação do contrato e responder mais rapidamente às mudanças do que seguir um
plano à risca. As metodologias ágeis mais conhecidas são Extreme Programming (XP),
Lean Development, Crystal e Scrum.
Com o Scrum, os projetos progridem em uma série de interações mensais, denominadas

sprints. Antes de cada sprint, as equipes de desenvolvimento se reúnem com o cliente,
ou com o product owner, para priorizar o trabalho a ser realizado e selecionar as ativi-
dades que a equipe pode finalizar na próxima sprint. Durante a sprint, a equipe é acom-
panhada através de reuniões diárias (daily scrum) e, no fim das sprints, a equipe entrega
um incremento do produto que pode ser potencialmente utilizado pelo cliente.
O Scrum é, portanto, ideal para projetos que possuem requisitos que ou mudam cons-
tantemente ou são desconhecidos no começo do projeto e que possuam a tendência de
surgir rapidamente, como projetos para web e para desenvolvimento de produtos em
novos mercados.
Desenvolvedores
A maioria dos desenvolvedores respondem à introdução de um processo ágil com uma q
combinação de ceticismo, entusiasmo e otimismo cauteloso. Outros desenvolvedores,
no entanto, tendem a resistir à mudança ou simplesmente iniciar o projeto sem preme-
ditação. É importante ressaltar que ambas as reações podem causar problemas.
Em geral, processos ágeis valorizam mais a produção de código do que processos orientados
a planejamento. Em um processo assim, os desenvolvedores tratam a UML e outros itens
que não são código como artefatos de primeira classe. Em um processo ágil, no entanto,
esses itens só existem para suportar a atividade de codificação.
Ao introduzir o Scrum em várias equipes de projeto, é normal encontrar programadores que

passam mais tempo produzindo artefatos que não são código do que necessário. Também
encontramos desenvolvedores que medem seu nível de contribuição no projeto pelo
número de reuniões de que participam. Esses analistas vão além da “paralisia da análise”
e ativamente buscam oportunidades para adicionar novas atividades no processo ágil,
deixando-o mais complicado do que precisa ser.
Em tais situações, o melhor é não intervir. Outros membros da equipe avaliarão a efetivi-
dade e o valor dessas atividades, e não as adotarão se estas não ajudarem o esforço de
desenvolvimento geral da equipe.
Realizando a transição de um processo peso-pesado

Um número surpreendente de desenvolvedores enxerga o uso de um método ágil q
como uma tentativa da gestão de microgerenciá-los. Abordagens como o Scrum e o XP

aceleram ciclos de projeto, e assim desenvolvedores interagem com seus gerentes mais
frequentemente, mas por períodos mais curtos. Em um processo orientado a planos,
um gerente pode passar até a semana inteira sem conversar com um desenvolvedor em
particular, enquanto o contato diário é a norma na maioria dos processos ágeis.
16
Programadores que têm essa visão percebem as interações com seus gerentes de projeto
como sendo sobre datas de entrega e prazos perdidos. Para impedir esse problema, os
líderes devem constantemente demonstrar seu desejo de remover obstáculos assim que
possível e evitar reclamar se uma atividade demorar mais do que o previsto. Gestores
podem se surpreender, mas não devem se mostrar excessivamente críticos ao serem infor-
mados de que uma tarefa vai demorar mais do que se pensava originalmente.
A transição gradual de um processo mais pesado para um processo ágil pode tornar a q
mudança mais fácil para a equipe de desenvolvimento. Algumas equipes, em seu pri-
meiro contato com o Scrum, ficam estagnados com a falta de ação gerada pela liberdade
de não possuir um cronograma diário direcionando seu trabalho. A ideia é ajudar esses
times ao definir tipos de sprint:
11 Prototipação;
11 Captura de requisitos;
11 Análise e design;
11 Implementação;
11 Estabilização.
A cada reunião de planejamento, trabalha-se com as equipes para definir os artefatos

que vão resultar de cada tipo de Sprint. Ao usar tipos de Sprint, introduzimos um nível de
formalidade suficiente para permitir que as equipes vejam mais claramente sua função ao
longo do projeto. Na medida que os times se tornam mais familiarizados com a informali-
dade do processo ágil, eles gradualmente abandonam o conceito de tipos de Sprint.
Scrum Escalável
Quando muitas equipes trabalham no mesmo produto, eles normalmente usam um q
mesmo Product Owner (que realmente toma decisões de negócio) e um único Backlog
de Produto com requisitos orientados ao cliente. Cada equipe do Scrum deve buscar
se tornar uma equipe de funcionalidades, capaz de desenvolver uma fatia completa
de produto que pode ser entregue ao cliente. Quando interdependências aparecem,
equipes de funcionalidade devem aprender a usar princípios da auto-organização para
coordenar com outras equipes.
Infelizmente, a maioria dos times não estão inicialmente acostumados com esse nível de
responsabilidade, e hábitos pré-existentes de gestão e hierarquias apresentam impedi-
mentos organizacionais.
A ideia do Scrum é eliminar papéis de coordenação como gestor de projetos e PMO, pois q
entende que eles interferem na auto-organização da equipe. O Scrum também elimina
papéis ditatoriais como “arquitetos”, pois entende que as decisões técnicas devem ser
tomadas por times colaborativos.
Enquanto um cenário de agilidade ótima requer mudanças fundamentais na estrutura

organizacional, é tentador usar algumas abordagens híbridas que combinam uma versão
enfraquecida do Scrum ao mesmo tempo em que se utiliza uma gestão hierárquica tradi-
cional. Recomenda-se que organizações maiores que estão comprometidas com valores
e princípios do Manifesto Ágil aprendam sobre LeSS (Large Scale Scrum).
17
Atividades práticas e
Cenário para escolha sobre um processo a ser adotado
Tutorial para uso de uma ferramenta Scrum (sugestão: Tuleap)
18
2
O Scrum
objetivos
Metodologias tradicionais: vantagens e desvantagens. Filosofia por trás das

metodologias ágeis. Metodologias ágeis: características, vantagens e desvantagens.
conceitos
O Scrum. Metodologias de desenvolvimento de software. Filosofia do Scrum.
Processo de software
Em uma visão geral do processo/projeto de desenvolvimento de software, podemos q
subdividi-lo em cinco fases genéricas que independem da área de aplicação, tamanho ou
complexidade do projeto:
11 Especificação;
11 Projeto;
11 Implementação;
11 Validação;
11 Manutenção.
Para cada uma delas, existe uma série de atividades que são executadas.
O processo de software pode ser visto como um gerador de produtos, sendo o software
em si o produto final – no entanto, é importante perceber que existem subprodutos
gerados em cada fase. Por exemplo, no final da fase de especificação, é comum se pro-
duzir e entregar um ou mais documentos em que se detalham os requisitos do sistema.
A seguir, detalharemos um pouco essas fases e suas atividades associadas.
Fase de especificação
É uma das etapas iniciais do projeto, pois é onde procuram-se identificar funcionali- q
Capítulo 2 - O Scrum
dades, restrições, validações, interfaces e principalmente os requisitos-chave que o

projeto deve cobrir.
Deve haver interação com o cliente para validar todas as informações por ele passadas e
com ele coletadas, a fim de que todos os requisitos sejam atendidos de maneira correta no
decorrer da implementação do produto.
19
É composta por três atividades principais, que são executadas, independentemente dos q
métodos utilizados, porém podem variar de acordo com o paradigma usado. As suas
tarefas são:
11 Engenharia de sistema: estabelecimento de uma solução geral para o problema,

envolvendo questões de tecnologia e equipamento;
11 Análise de requisitos: levantamento das necessidades do software a ser implementado

– tem como objetivo produzir uma especificação de requisitos em forma de documento;
11 Especificação de sistema: descrição funcional do sistema. Pode incluir um plano de

testes para verificar adequação.
Fase de projeto
O projeto é finalizado quando seus objetivos propostos são alcançados e quando se q
encontra estruturado, em termos de arquitetura, interface e técnicas. Suas atividades são:
11 Projeto arquitetural: aqui se desenvolve um modelo conceitual para o sistema, com-

posto por módulos mais ou menos independentes;
11 Projeto de interface: onde cada módulo tem sua interface de comunicação estudada e
definida. Pode resultar em um protótipo;
11 Projeto detalhado: onde os módulos em si são definidos e, possivelmente, traduzidos

para pseudocódigo.
Fase de implementação
Também chamada de fase de desenvolvimento ou codificação. É a fase que define como q
os dados serão estruturados e implementados tecnicamente. Em outras palavras, é
quando o projeto, que antes estava documentado em papel, passa a ser transformado
para entrar em operação de fato. Linguagens de programação, técnicas e métodos – que
podem variar de projeto para projeto –, contudo, atividades comuns a todas metodolo-
gias precisam ser realizadas, tais como:
11 Projeto de software: parte central do desenvolvimento, que mostra o que e como

será desenvolvido;
11 Geração de código: que consiste em traduzir em linguagem de programação o que foi

especificado no projeto de software.
Fase de teste
Nesta fase, encontram-se as não conformidades com o que foi especificado durante a q
fase de especificação, com o objetivo de aumentar a qualidade do produto. Suas ativi-
dades são:
11 Teste de unidade e módulo: consiste na realização de testes para verificar a

presença de erros e comportamento inadequado relacionado às funções e módulos
básicos do sistema;
11 Integração: reunião dos diferentes módulos em um produto de software homogêneo

e verificação da interação entre esses quando operando em conjunto.
20
Fase de manutenção
Considerada a fase final, onde se analisa todo o produto. Tem como foco principal as q
modificações, como correções de erros, adaptações necessárias e melhorias (novas
funcionalidades não planejadas inicialmente) para evolução do software.
Nessa fase, o software em geral entra em um ciclo interativo que abrange as fases anteriores.
Como ocorrem alterações, a fase de manutenção abrange características das fases anteriores,
porém seu enfoque é um software já existente.
São quatro os tipos de modificações que podem ocorrer: q

11 Manutenção corretiva: visa corrigir os defeitos que ocorreram durante a fase de
desenvolvimento;
11 Manutenção adaptativa: modifica o software para adaptá-lo a alterações no

ambiente externo;
11 Manutenção perfectiva: adiciona novas funcionalidades ao software. Essas novas

especificações estão fora do escopo do projeto original e são consideradas como
melhorias de produto;
11 Manutenção preventiva: assume que mudanças tanto no ambiente externo quanto

de especificações vão ocorrer – portanto, já é implantado para que o impacto
causado por essas alterações não afete o sistema.
Para tornar o desenvolvimento de software uma atividade menos caótica, e buscando

aumentar a qualidade e produtividade em seus projetos, as organizações produzem
seus próprios modelos de processo de software.
Assim, é impossível conceber um modelo uniforme que possa descrever com precisão o que
de fato acontece durante todas as fases de produção de um software – os procedimentos
utilizados são variados e as necessidades organizacionais diferem substancialmente.
O que se pode dizer é que todo modelo de software deve levar em consideração as fases q
descritas anteriormente; no entanto, cada organização organiza as fases do seu Modelo
de Processo de Software de acordo com sua filosofia.
Assim, um modelo, ou uma metodologia de desenvolvimento, é uma filosofia do anda-

mento das fases – ciclo de vida – e não uma descrição de como cada atividade deve ser
executada ao pé da letra. Um modelo de desenvolvimento corresponde a uma repre-
sentação abstrata do processo de desenvolvimento que vai, em geral, definir como as
etapas relativas ao desenvolvimento do software serão conduzidas e inter-relacionadas
para atingir o objetivo do desenvolvimento – que é a obtenção de um produto de sof-
tware de alta qualidade a um custo relativamente baixo.
Metodologias de desenvolvimento tradicionais:

vantagens e desvantagens
As Metodologias de Desenvolvimento de Software são uma resposta das organizações, q
em especial das Software Houses, que buscavam desenvolver projetos de maneira mais
organizada e profissional, à Crise do Software. Linguagens foram criadas para modelar e

facilitar o produto pelo cliente e pela própria empresa desenvolvedora.
A documentação gerada a partir da análise e especificação dos projetos era acompa-

nhada por um método de desenvolvimento para suportar o processo de fabricação do
software. Os métodos surgiram para dividir todo o processo em etapas e prover sua
melhor visualização, sempre com foco na melhor qualidade final do produto.
21
De acordo com Sommerville, metodologia de desenvolvimento é o “conjunto de práticas q
recomendadas para o desenvolvimento de softwares, sendo que essas práticas geral-
mente passam por passos ou fases, que são subdivisões do processo para ordená-lo
e melhor gerenciá-lo”. As metodologias consideradas tradicionais, também chamadas
de “pesadas”, têm como característica marcante a sua divisão em etapas e fases bem
definidas, como Análise, Modelagem, Desenvolvimento e Testes. A conclusão de cada
fase gera um marco, que tipicamente refere-se um documento, protótipo do software ou
versão do sistema.
O foco principal dessas metodologias é a previsibilidade dos requisitos do sistema, que

traz a grande vantagem de tornar os projetos completamente planejados, facilitando
sua gestão, mantendo uma linha de comando e caracterizando o processo com bas-
tante rigor. Essa previsibilidade é alcançada porque mais tempo é dedicado na fase de
análise e na elaboração da documentação de planejamento. Como se pode imaginar, o
controle do projeto é dificultado já que, em situações reais de projeto, sempre que se
deseja alterar um requisito, ou parte do escopo, é necessário voltar ao início do projeto
e reiniciar todo o processo de planejamento.
As metodologias pesadas defendem que uma documentação detalhada é necessária por

oferecer um embasamento maior para manutenção do software e prevenir a troca de
recursos. Caso um desenvolvedor resolva sair do projeto, por exemplo, todo o projeto
estará documentado e quem assumir estará munido de informações para continuar o
projeto sem necessidade de perder muito tempo.
Apesar de os modelos de desenvolvimento terem atendido diversos problemas originados

pela Crise do Software, eles possuem limitações que na prática acabam não atendendo as
necessidades de uma equipe técnica, podendo até mesmo inviabilizar os projetos de desen-
volvimento em função dessas deficiências.
Levando em consideração que o processo de desenvolvimento é bastante mutável, ele

acaba demandando muito tempo de trabalho, pois frequentemente há o surgimento de
novos requisitos por parte do cliente, tanto funcionais como não funcionais, assim como a
não conformidade de algumas solicitações resulta na necessidade de alteração constante na
documentação e no produto em si.
Vantagens e desvantagens
As vantagens principais das metodologias de desenvolvimento tradicionais são: redução q
de riscos envolvendo custos a um único incremento e aceleração do tempo de desenvol-
vimento do projeto como um todo, visto que os desenvolvedores trabalham de maneira
mais eficiente quando buscam resultados objetivos.
Quando se segue uma metodologia moderna como o Rational Unified Process (RUP), as
metodologias tradicionais incorporam uma série de outros benefícios, tais como:
11 Gerenciamento de requisitos: para garantir que as mudanças nos requisitos, que

são comuns após o início do desenvolvimento, sejam administradas em um projeto
desenvolvimento iterativamente;
11 Integração de elementos: quando cada módulo desenvolvimento é integrado ao

sistema como um todo, evitando que a atividade de “juntar as partes” seja um pro-
blema no fim do projeto;
22
11 Gerenciamento de riscos: a cada iteração, é possível analisar pontos críticos e pla- q
nejar estratégias para não perder tempo durante o desenvolvimento;
11 Testes: são realizados no fim de cada módulo, permitindo que erros e não conformi-
dades possam ser tratados ainda dentro do mesmo ciclo.
Embora as abordagens tradicionais tenham surgido como um recurso para empresas

desenvolvedoras de software, são diversas as críticas e limitações que surgiram. Além das
já citadas anteriormente, o enorme número de documentos exigidos em cada atividade
dificulta a implantação por empresas que não possuem recursos para criar e gerenciar tal
documentação. Com isso, são muito poucas as pequenas organizações que conseguiram
implantar processos pesados e tradicionais com sucesso – eles são mais indicados para
grandes equipes de desenvolvimento.
Que metodologias de desenvolvimento são utilizadas na sua organização?
Você enxerga vantagens e desvantagens no seu uso? Quais?
Metodologias de Ágeis de Projetos

Na última década, um novo segmento da comunidade da Engenharia de Software vem q
defendendo processos simplificados, com foco nas pessoas que compõem o processo
e, principalmente, no programador. Também chamada de metodologia de desenvol-
vimento leve, as metodologias ágeis propõem a execução dos passos do projeto em
paralelo, e sua principal característica é o menor esforço à documentação.
A documentação do projeto tende a ser simplificada e orientada pelo código-fonte.

A crítica mais frequente às metodologias tradicionais é que são burocráticas. Para seguir
a metodologia, é produzida grande quantidade de material, que faz diminuir a veloci-
dade de desenvolvimento.
Arquitetura /
Projeto
Levantamento
Prototipação
Requisitos
Validação
Implantação
do cliente
Figura 2.1
Fases de uma
metodologia Testes Desenvolvimento
tradicional.
23
O novo advento ágil iniciou com alguns especialistas da indústria do desenvolvimento de q
software, que se uniram para encontrar valores e princípios relacionados ao desenvolvi-
mento, que escreveram o Manifesto Ágil. Esse manifesto destacava quatro valores:
11 Software funcional em vez de documentação detalhada;
11 Colaboração ao cliente em vez de negociação de contratos;
11 Indivíduos e iterações em vez de somente processos e ferramentas;
11 Responder às mudanças em vez de seguir um plano minuciosamente detalhado

inicialmente.
Software Funcional em vez de Documentação Detalhada

A ideia dos projetos ágeis é medir o progresso do projeto em função da quantidade de q
software funcional existente, em vez de considerar um grande volume de documentos
e a fase do processo em que o projeto se encontra como fatores determinantes para o
progresso atual. Considera-se que 30% do projeto estão prontos quando 30% das funcio-
nalidades necessárias estiverem funcionando.
A documentação de um projeto é extremamente necessária para o seu sucesso, e projetos

ágeis reconhecem isso. O código não é o melhor meio de comunicação entre o racional e a
lO Manifesto Ágil, no
estrutura do sistema. Documentação legível é necessária para manter o sistema e fazê-lo entanto, não é contra
documentação. Ele diz
evoluir; porém, o excesso de documentação é pior do que a falta dela. O manifesto, no claramente: “Nenhum
entanto, sugere que somente a documentação necessária seja gerada, e que esta seja documento é gerado a
não ser que seja
sempre atualizada com o código gerado.
necessário e significante.”
Uma documentação enxuta promove integração na equipe em função da transferência de
conhecimento sobre o projeto que será realizado paralelamente com o código, uma vez que
este não permite duplas interpretações. De nada adianta ter uma extensa gama de docu-
mentos que demandam muito tempo para serem gerados, depois lidos e, principalmente,
para mantê-los atualizados. A documentação tem o papel de orientar todos os membros
envolvidos no projeto.
Documentações e papéis não contam como entregas, pois não satisfazem a necessidade do
cliente. O cliente escolhe se vai implantar o sistema incompleto, se vai apenas testá-lo para
definir novas funcionalidades ou se vai apenas testá-lo para encontrar não conformidades
com aquilo que deseja.
Colaboração ao cliente em vez de negociação de contratos

As metodologias leves enfatizam o relacionamento próximo com o cliente, exigindo que q
sua participação seja dedicada, inteligível, colaborativa e efetiva. Esse envolvimento
favorece caso os requisitos sejam imprevisíveis e sujeitos a mudanças; porém, havendo
pontos de vista diferentes entre os desenvolvedores e cliente, possivelmente ocorrerão
conflitos, riscos e negligências. Esses riscos podem ser reduzidos através de métodos
guiados por documentação, planejamento e revisão na arquitetura.
As metodologias ágeis abordam o desenvolvimento de uma lista de prioridades e funcio-

nalidades, para que o cliente defina e classifique o que é prioritário para ele. Tal definição é
atualizada constantemente no início de cada ciclo.
24
Indivíduos e iterações em vez de somente processos e ferramentas
A experiência e capacitação dos profissionais no desenvolvimento do projeto afetam q
diretamente na qualidade do produto e no bom desempenho da equipe do projeto. Ter
excelentes profissionais, no entanto, não é uma garantia de sucesso, pois eles dependem
diretamente do processo.
Um processo de má qualidade pode fazer com que os melhores desenvolvedores

não sejam capazes de usar todo o seu talento.
Além da combinação do processo adequado com bons profissionais, é preciso que toda q
a equipe possa interagir perfeitamente entre si. Comunicação é mais importante que
simples talento para programação. Um desenvolvedor que consegue se relacionar bem
e trabalha bem em equipe tipicamente é mais produtivo que um excelente programador
que só consegue trabalhar sozinho. Comunicação é o principal valor dos Processos Ágeis
e é a maneira mais rápida de se obter informações.
Além disso, as responsabilidades e decisões são compartilhadas por toda a equipe, mos-
trando que todos estão envolvidos no processo e trabalhando em grupo. Assim, para a
seleção dos funcionários envolvidos, deve-se levar em consideração o perfil, a competência,
o comportamento individual e em equipe, e o profissional deve ser comunicativo. Obviamente,
uma organização em transição deve ser capaz de treinar os seus profissionais – no entanto,
é fundamental que todos estejam motivados, seja com o apoio de outros membros da
equipe ou com o material e equipamento.
Outra característica é a iteração. Após cada iteração, deve ser possível apresentar um pro-
tótipo para o cliente e coletar o seu retorno. Como já dito anteriormente, nas metodologias
ágeis, é criada uma lista de prioridades de funcionalidades de acordo com o que o cliente
julga como prioritário para ele. Tal lista é atualizada constantemente a cada iteração, permi-
tindo acrescentar novos requisitos e mudanças, ajustando as prioridades. Dessa maneira,
o gerente de projeto pode garantir que a equipe de desenvolvimento esteja trabalhando de
acordo com os aspectos que o cliente considera mais significativo.
Um processo ágil consiste em entregas rápidas e constantes. Entrega-se no início do q

projeto o primeiro sistema, ou parte do sistema, já com algumas funcionalidades desen-
volvidas, sendo que novos pacotes de funcionalidades continuam sendo desenvolvidos e
integrados ao módulo anterior no decorrer do tempo.
Responder à mudanças x planos detalhados

Assumindo que mudanças de especificação sempre vão ocorrer em qualquer projeto, q
é possível afirmar que tais projetos terão mais sucesso quando se adaptarem a essas
mudanças. Flexibilidade é fator fundamental para o sucesso em projetos, pois determina
o quanto estes são adaptáveis. Processos ágeis são receptivos a mudanças, mesmo que
elas apareçam durante o desenvolvimento e os testes. Os participantes não temem as

mudanças, pois assumem que elas são indicadores de que a equipe está aprendendo
sobre o sistema, tentando atingir a satisfação do cliente.
25
Acerca da existência de planos, o Manifesto Ágil não é contra. Ele defende que planos sejam
esboçados, mas que, como não é possível prever o futuro, as visões desses não devem ir
muito longe.
O planejamento, portanto, deve ser de curto prazo, em virtude das alterações que q
invariavelmente vão aparecer. Na verdade, é muito difícil seguir planos de longo prazo
à risca, então faz pouco sentido concentrar muito esforço nisso. Uma dica importante
quando se identifica que o projeto será muito extenso é dividi-lo em fases, tornando
mais fácil gerenciá-lo e executá-lo.
Velocidade e qualidade
Ora, para garantir um desenvolvimento rápido, é necessário um software limpo e mais q
robusto possível. Isso porque as equipes de projetos ágeis são orientadas a desenvolver
códigos com qualidade.
Assim, o que deve ser mantido nos Processos Ageis é a velocidade do desenvolvimento.
De nada adianta iniciar um projeto desenvolvendo-o rapidamente se essa velocidade
declinar com o tempo, pois isso pode iludir o cliente, causando a ele uma impressão de falsa
velocidade, além de estressar os desenvolvedores e diminuir a qualidade final do produto,
quebrando os principais valores dos Processos Ágeis.
Vantagens e desvantagens
As vantagens da Metodologia de Desenvolvimento Ágil são: q
11 Receptividade às mudanças;
11 Orientada às pessoas, não aos processos;
11 Complementada por checagens dinâmicas;
11 Equipes de desenvolvimento menores;
11 Com foco para o compartilhamento do conhecimento;
11 Feedback praticamente instantâneo;
11 Versões úteis;
11 Visão clara de riscos e incertezas na arquitetura do projeto;
11 Poderá ser considerada uma solução de valor agregado;
11 Uma versão poderá ser entregue ao cliente em um tempo menor do que uma versão
desenvolvida com a metodologia pesada;
11 São adaptáveis, favorecendo o aprendizado dos envolvidos, aprimorando o projeto e

formando assim um ciclo de projeto.
O gerente do projeto não precisa desenvolver um projeto pesado de documentação – pelo

contrário, ele só precisa ter foco no absoluto necessário, como a programação das tarefas.
No entanto, a grande limitação das metodologias ágeis é a maneira como elas manipulam
grandes equipes. Metodologias pesadas e seus métodos pré-guiados se adaptam melhor às

dificuldades de comunicação, algo extremamente complexo, entre pessoas em projetos que
contam com mais de vinte desenvolvedores.
26
Como a prioridade máxima das metodologias ágeis é satisfazer o cliente, fornecendo o mais q
rapidamente possível e continuamente novas funcionalidades para o seu software, em
grandes sistemas essa filosofia pode resultar em retrabalho por falta de escala em sua arqui-
tetura. Tradicionalmente, os objetos da metodologia pesada como previsibilidade, repetição
e otimização são características de um desenvolvimento seguro. Portanto, seria displicente a
aplicação da modelagem ágil em sistemas críticos de manutenção vital, por exemplo.
Você acredita que a sua organização e os seus clientes se beneficiariam da
adoção de uma metodologia como o Scrum?
Histórico do Scrum
O Scrum foi a princípio concebido como um estilo de gerenciamento de projetos em q
empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka,
no artigo “The New Product Development Game” (Harvard Business Review, janeiro-feve-
reiro 1986). Nesse artigo, eles comparavam equipes de alto desempenho e multifuncionais
com um jogo de rugby e concluíram que equipes são formadas de menores e equipes tra-
balhando com sucesso em direção a um objetivo comum. Os autores notaram que projetos
usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores
resultados, e associaram essas equipes altamente eficazes à formação Scrum do Rugby (utili-
zada para reinício do jogo em certos casos).
Em meados de 1983, seguindo a mesma linha de Nonaka e Takeuchi, a metodologia começou

a ser aperfeiçoada por Jeff Sutherland, vice-presidente de engenharia da Easel, que enquanto
trabalhavam em construir uma ferramenta de Object Oriented Analysis and Design (OOAD)
no produto smalltalk, percebeu que seu time de software também precisava de uma versão
melhorada de desenvolvimento rápido de aplicação. O seu objetivo era um processo similar
ao Scrum, de curtas interações, onde o CEO da Easel conseguisse ver código funcionando do
que diagramas Gantt. Seus procedimentos e ferramentas para medir produtividade e com-
parar diferentes estratégias foram fundamentais na criação do Scrum.
Apesar de a metodologia ter sido iniciada pelos autores supracitados, no ano de 1995, a
documentação da metodologia foi publicada por Ken Schwaber com a ajuda de Jeff, que se
empenharam para sintetizar o que tinham aprendido através dos anos e criaram uma nova
metodologia, a qual chamaram de Scrum. Em 1995, Ken Schwaber formalizou a definição de
O primeiro artigo
d Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo.
O objetivo de Ken Schwaber durante todo esse período era auxiliar sua empresa, a Advanced
sobre o tema foi
“Scrum and the Perfect Development Methods, Inc. a aprimorar seu processo de desenvolvimento de software
Storm”, publicado na com o objetivo de melhorar a produtividade de sua equipe. Após uma extensa análise
revista OOPSLA pela
de como fornecedores de softwares bem-sucedidos e independentes produziram seus
Object Management
Group (OMG). produtos, ele concluiu que os processos de desenvolvimento desses fornecedores
eram bastante análogos, os quais requeriam constantes verificações e adequações.
Toyota, uma grande influência para o Scrum

Como a maioria dos termos do Scrum estão presentes nos processos da Toyota, essa
empresa, sem intenção, acabou contribuindo para o desenvolvimento da metodologia.
A própria missão da organização reflete um dos valores principais do Scrum: “Contribuir
com o crescimento da economia das comunidades dos Estados Unidos e para estabilidade e
bem-estar dos membros da equipe.” O ponto principal parece ser trazer benefícios para as
pessoas, uma proposta distinta da maioria das empresas americanas.
27
Conforme já explicamos anteriormente, o foco do Scrum está nas pessoas. A metodologia
trabalha para melhorar a vida de todos os envolvidos no projeto – principalmente os desen-
volvedores de software. Um segundo foco é adicionar valor aos clientes, já que o Scrum é
um processo de adição de valor, com foco no cliente.
É interessante que o Scrum por si só está construindo comunidades de práticas, através de

um programa de treinamento para certificação ScrumMaster. Hoje há milhares de certificados
ao redor do mundo – estima-se cerca de 20 mil certificados, e cerca de 40 mil ScrumMasters
não certificados atuando em projetos de Scrum no mercado.
Normalmente, tem-se uma tendência em abrir mão da variável custo para obter qua- q
lidade, ou abrir mão da qualidade para se obter o objetivo do projeto em um tempo
menor. É isso que se chama de restrição tripla de projetos, composto pelas pontas:
“custo, qualidade e prazos”, conforme mostrado na figura 2.2. Essa decisão ainda é um
paradigma forte nas principais e na mente dos desenvolvedores: a tendência de desprio-
rizar um vértice para conseguir otimizar o outro.
Qualidade
Figura 2.2
Restrição tripla em
Custo Prazo
projetos.
Porém, a filosofia da Toyota vai de encontro a isso. A empresa trabalhou para quebrar q
a restrição tripla como um triângulo de ferro e uniu todas essas pontas, buscando
qualidade, entrega rápida, variedade de produtos e preço baixo. É nesse sentido que a
Toyota e o Scrum caminham juntos – o sistema da Toyota é baseado na quebra da res-
trição tripla, buscando maximizar todas as variáveis da restrição tripla ao mesmo tempo,
reduzindo custos, tempo e barreiras funcionais através de um processo interativo que
inspeciona, junto com o cliente, cada passo do processo, para alcançar um resultado
final com qualidade.
Como eliminar a restrição tripla na sua organização?
Enfrentar e alinhar a gestão e o controle da estrutura do cliente são as partes mais q
difíceis do Scrum. A equipe deve ser auto-organizada, e isso é mais fácil de conseguir
em organizações emergentes, pois estas têm uma facilidade maior de se auto-organizar
através da ação local. Caso se pare para reparar as pessoas na linha de frente, geral-
mente são as que estão no campo, e, portanto, detêm mais conhecimento do negócio.
Na Toyota, isso ocorre entre vendedores de carros ou nas linhas de montagem. É lá que
as coisas acontecem e surgem, e assim permitem a distribuição do conhecimento e das
ações para desenvolver os projetos. Da mesma forma, no contexto do Scrum, a equipe deve
ser formada de maneira a permitir que se auto-organize também. E esse é o segredo do
Scrum. Um projeto que utiliza a metodologia tem de ser capaz de formar um time que se
auto-organize.
28
Takeuchi e Nonaka argumentam que há alguns sinais que podem ser identificados para q
dizer se uma equipe está se auto-organizando:
1. Verifique se a equipe está localizada, tem um objetivo e senso comum. É possível

descobrir isso respondendo às perguntas:
22 Os membros da equipe se sentem totalmente responsáveis?
22 Há alguém no caminho atrapalhando o processo?
22 Os membros da equipe estão completamente envolvidos e com foco no projeto?
22 Os membros da equipe sabem o que têm de fazer?
22 Os membros da equipe sabem por que estão ali?
22 A equipe é independente?
2. Verifique se há senso comum, ou seja, se cada membro da equipe está com foco no
sucesso da equipe, ao invés do seu próprio avanço pessoal na empresa. Caso isso
não ocorra, a equipe não se auto-organizará.
3. A terceira, denominada polinização, é fazer com que membros mais experientes

ajudem membros menos experientes. Pessoas que têm alguma especialidade estão
compartilhando conhecimento com os outros?
Você acredita ser possível ter uma equipe auto-organizável na sua organização?
Qual o contexto para possibilitar tal auto-organização?
Em alguns casos, o trabalho de remover a gestão é árduo – no entanto, tornar os partici- q
pantes independentes e com liberdade colabora para que o projeto tenha um resultado
de sucesso.
A perspectiva diversificada na Toyota e no Scrum vem dos times de funcionalidade múltipla:

quando a Toyota começou a desenvolver o projeto Prius, trouxeram um engenheiro chefe que
não sabia nada sobre o projeto. Por desconhecer o projeto, ele precisava montar uma equipe
com os melhores e mais capazes membros da organização, reuni-los em uma sala para que
eles o dissessem o que fazer.
Mesmo sendo o engenheiro o mais experiente do grupo, ele precisava deixar que o projeto
se desenvolvesse a partir daquela equipe diversificada – uma característica típica do Scrum.
No Scrum, todos são parte do processo, a equipe tem uma estrutura vertical e, portanto,
todos estão no mesmo patamar, trabalhando juntos: gerentes, clientes, pessoal da insta-
lação, suporte, entre outros.
Origem do nome
O nome Scrum foi inspirado em uma jogada do Rugby – a figura 2.3 mostra como é um q
Scrum no Rugby. Essa analogia feita entre uma jogada de Rugby e o Scrum tem dois fun-
damentos: o senso de equipe e as constantes reuniões em círculo durante o jogo.
29
Senso de equipe Figura 2.3
q
Exemplo de Scrum.
O Scrum no Rugby consiste em uma equipe de oito jogadores abraçados, que realizam
uma força, onde o objetivo é empurrar o outro time. Essa jogada só é eficaz quando
todos os jogadores fazem força ao mesmo tempo e na mesma direção, fazendo com que
a soma das forças individuais sejam maiores que as do time adversário, e consigam
assim pegar a bola.
Podemos concluir que o desenvolvimento de um software realmente se tornou um

esporte em equipe. O estilo de “corrida de revezamento” aplicado ao desenvolvimento
de produtos pode conflitar com o alcance do objetivo final.
Essa corrida em estilo holístico, onde a equipe busca, como em um jogo de Rugby,
de forma integrada, chegar ao gol, com passes de bola, pode servir melhor às atuais
necessidades competitivas.
Reuniões constantes
No jogo de Rugby, os jogadores se organizam em círculo para planejar a próxima jogada. q
É uma forma de mostrar que o projeto deve ser conduzido em pequenos círculos, mas
com uma visão de longo prazo, que é ganhar o jogo. O mesmo ocorre na metodologia
Scrum: cada interação é uma forma de recomeçar a partida reunindo todos os jogadores
após um incidente ou quando a bola sair de campo. A ideia básica é reunir os desenvol-
vedores e deixar o jogo continuar acontecendo.
A Metodologia Scrum apenas estabelece conjuntos de regras e práticas de gestão que

devem ser adotadas para garantir o sucesso de um projeto. No entanto, esse método não
requer nem fornece qualquer técnica ou método específico para a fase de desenvolvi-
mento de software.
30
O processo
Ken Schawber defende que Scrum não é uma metodologia em si, mas um framework. q
Scrum não vai dizer exatamente o que fazer, mas dar um conjunto de diretrizes que
podem ser seguidas e adaptadas para uma realidade específica do projeto.
Na concepção desse autor, Scrum é enquadrado como um processo para gerenciamento

de projetos ágeis. De maneira semelhante, não vai resolver todos os problemas, mas, se
bem adequado à realidade de projeto, certamente os problemas serão mais facilmente
identificados.
Para Martins, “Scrum é um processo bastante leve para gerenciar e controlar projetos de
desenvolvimento de software e para criação de projetos de produtos. O Scrum segue a filo-
sofia iterativa e incremental, se concentrando no que é realmente importante: gerenciar o
projeto e criar um produto que acrescenta valor para o negócio. O valor decorre da funcio-
nalidade propriamente dita, do prazo em que ela é necessária, do custo e da qualidade”.
Ou seja, a abordagem do Scrum é oposta à do modelo em cascata, já que inicia a análise q

assim que alguns requisitos estão disponíveis. Depois que alguma análise foi realizada,
inicia-se rapidamente os trabalhos de projeto técnico (design), e assim por diante. Em
outras palavras, o projeto trabalha em pequenos ciclos de cada vez, até a conclusão do
projeto final. Essa abordagem pode ser chamada de iterativa, e cada iteração consiste na
captura de requisitos, um pouco de análise, um pouco de design e mais alguma progra-
mação e testes, culminando em um ciclo iterativo com várias entregas.
Empírico
Segundo Cruz, existem dois tipos de processos: definidos e empíricos. Processos defi- q
nidos determinam o que deve ser feito, quando e como. Para um mesmo conjunto de
variáveis de entrada, podemos esperar o mesmo resultado sempre. Um exemplo bem
conhecido de processo definido é a metodologia RUP. De acordo com Highsmith (2004),
um processo de desenvolvimento de software extremamente bem definido tem uma
probabilidade de sucesso drasticamente reduzida quando utilizado no desenvolvimento
de um produto.
O Scrum utiliza uma implantação de um controle descentralizado que lida de forma efi-
ciente com situações menos previsíveis, o que aparece como uma possível solução para
atacar esse problema.
Ora, de acordo com Schwaber (2004), o principal objetivo do Scrum é o desenvolvimento de

sistemas de software envolvendo uma porção de várias técnicas e de ambiente, como requi-
sitos, tecnologia e recursos, que podem mudar durante o processo. O foco desse método é
encontrar uma maneira de os membros da equipe trabalharem para produzir o sistema de
forma flexível e em ambiente passível de sofrer mudanças constantes – o resultado desse
trabalho deve ser um sistema de software realmente útil para o contratante.
Nesse sentido, os processos empíricos devem ser utilizados sempre que os processos
definidos não forem adequados devido à complexidade do projeto, ou seja, sempre que não
se conheçam todas as variáveis de entrada para que se possa estabelecer um processo que
pode ser repetido(com a mesma saída sempre), o Scrum é um exemplo deste.
O Scrum é assim o mais perplexo e paradoxal processo para o gerenciamento de q

projetos complexos, mesmo sendo um método incrivelmente simples. Antes de mais
nada, não é um método prescritivo, ou seja, não descreve o que se deve fazer em cada
circunstância. É usado para trabalhos complexos nos quais é impossível predizer tudo o
que vai acontecer durante o desenvolvimento do sistema de software.
31
De acordo com Beedle (2001), Scrum é um método de desenvolvimento ágil que procura
uma forma de lidar com o caos, em detrimento a um processo bem definido, cuja função
primária é ser utilizado em gerenciamento de projetos de desenvolvimento de sistemas
de software. Ele tem sido utilizado com sucesso para esse fim e pode ser utilizado em
qualquer situação em que um grupo de pessoas precise trabalhar juntas para atingir um
objetivo comum.
Iterativo e incremental
Em virtude da complexidade, tamanho, mudanças de requisitos, urgência e necessidade q
de demonstrar valor mais rápido para o cliente, fica quase inconcebível desenvolver
software utilizando o modelo cascata, ou seja, desenvolver software de uma única vez.
A metodologia considera um modelo iterativo e incremental por uma questão de estra-
tégia de planejamento. O modelo segue uma filosofia: dividir para conquistar, onde o
projeto é divido em blocos, em ciclos, onde a cada iteração é feito um novo incremento
(parte do software funcional) até completar o software.
Para esclarecer os conceitos de incremental e iterativo, segue uma figura retirada de um

trabalho da Agile Way, um portal sobre metodologias ágeis. Nela, podemos ter uma ideia
melhor do que significam esses conceitos. Com respeito ao conceito de incremental, a
cada ciclo vai aumentando e no final completa-se o objetivo. Com respeito ao conceito de
iterativo, a cada ciclo melhora-se o trabalho, chegando a um objetivo com mais qualidade.
Entrega 1 Entrega 2 Entrega 3

Plano incremental
Plano de iteração
Figura 2.4
Incremental
e iterativo –
diferenças.
Fases do Scrum
Basicamente, a metodologia Scrum é dividida em três fases simples, que se repetem a q
cada ciclo: planejamento, desenvolvimento e encerramento.
11 Planejamento: consiste na análise e definição de requisitos de uma nova funciona-

lidade requerida pelo cliente para o sistema, baseado na necessidade do negócio do
cliente e no projeto do sistema como um todo. Em seguida, é realizada a estimativa de
tempo e custo do novo desenvolvimento. Após a aprovação do cliente, tal funcionali-
dade segue o fluxo para a fase seguinte;
11 Desenvolvimento: consiste no desenvolvimento de fato de uma nova funcionalidade,

respeitando o tempo, requisitos exigidos e nível de qualidade pré-definida na fase
anterior;
32
11 Encerramento: preparação para a entrega da funcionalidade planejada e desenvol- q
vida nas fases anteriores, consistindo nas atividades a seguir:
22 Teste unitário;
22 Teste integrado;
22 Elaboração de documentação de usuário;
22 Treinamento.
Tamanho de projetos
Scrum é uma metodologia que se aplica a projetos de qualquer tamanho, realizando uma
avaliação correta do ambiente em evolução. Adapta constantemente o “caos” de interesses
e necessidades, e é indicado e utilizado para o desenvolvimento de software em ambientes
complexos, onde os requisitos mudam com certa frequência, sendo o caminho utilizado
para aumentar a produtividade nesses tipos de sistemas.
Atividades práticas e
Cenários para levantamento de requisitos
A partir de requisitos, escrever User stories. Cenários (Sprint previamente finalizada)
para cálculo de Burndown a partir do Tuleap. Cenários (idem) para cálculo de Velocidade.
É importante o instrutor explicar a diferença e importância dessas métricas.
33
34
3
A metodologia
objetivos
Entender a Metodologia do Scrum; Papéis, Cerimônias e Artefatos do Scrum
conceitos
Scrum Master, Product Owner; Daily Scrums, Reuniões de Planejamento e Reuniões
de Revisão; Product Backlog, Sprint Backlog e Gráfico de Burndown
Antes de descrever o passo a passo da metodologia, precisamos conhecer os insumos q

que a compõem. Dessa forma, torna-se possível familiarizar-se com os termos que serão
utilizados. A metodologia é formada por Papéis, Cerimônias e Artefatos, e cada um deles
se subdivide em insumos menores, conforme a lista a seguir:
11 Papéis:
22 Product Owner (Proprietário do produto);
22 Scrum Master;
22 Equipe de Desenvolvimento;
22 Cliente.
11 Cerimônias:
22 Reunião de planejamento do Sprint;
22 Reuniões diárias de Scrum (Daily);
22 Reunião de Revisão do Sprint.
11 Artefatos:
22 User Stories (História);
22 Planning Poker;
22 Sprint;
Capítulo 3 - A metodologia
22 Product Backlog;
22 Sprint Backlog;
22 Burndown Chart.
35
Papéis
Como já mencionado anteriormente, a metodologia define como a equipe deve trabalhar. q
O primeiro passo para o desenvolvimento baseado no Scrum é definir quem vai fazer o
quê. A metodologia define dois tipos de papéis básicos:
11 Principais;
11 Auxiliares.
Papéis principais são os profissionais que fazem parte da equipe do fornecedor – ou seja,
são aquelas pessoas comprometidas com o projeto no processo do Scrum. Produzem o
produto em si, o objetivo final do projeto.
Já os papéis auxiliares são aqueles sem papel formal e nenhum envolvimento frequente
no processo Scrum, mas que ainda precisam ser levados em conta.
Product Owner
Podemos dizer que o Product Owner é um analista de negócio e um profissional com q
conhecimento nas duas pontas: no negócio do cliente e na tecnologia. Tem como
principal objetivo representar os interesses do cliente com a equipe técnica. Funciona,
l
portanto, como uma interface entre o cliente e a equipe de desenvolvedores, e deve
estar sempre em contato com o cliente para saber o que precisa ser feito no projeto para
satisfazer o negócio. Veremos esse termo
em detalhes no tópico
Juntamente com os outros envolvidos, ele é o responsável por listar as prioridades e os de Artefatos.
requisitos, além de revisar e aprovar as entregar no final de cada Sprint.
Mais detalhadamente, ele tem as seguintes responsabilidades: q

11 Definir os requisitos e funcionalidades de produto;
11 Decidir sobre data de lançamento e término;
11 Ser responsável pela rentabilidade do produto (ROI);
11 Priorizar as funções de acordo com a necessidade atual do cliente;
11 Ajustar recursos e priorizar tarefas a cada ciclo, geralmente de 30 em 30 dias,

como necessário;
11 Aceitar ou rejeitar o resultado do trabalho.
Scrum Master
É o líder da equipe de desenvolvimento, geralmente o programador ou analista de sistemas q
mais experiente da equipe. É responsável por garantir a aplicação das práticas do Scrum,
assim como repassar os ensinamentos da metodologia para os outros membros do
projeto. Gerencia e delega as atividades que foram definidas durante o planejamento
pelo Product Owner.
Suas principais responsabilidades são:

11 Assegurar-se de que a equipe de desenvolvimento funciona plenamente e é produ-

tiva, intermediando a comunicação entre a equipe e o Product Owner;
11 Assegurar-se de que a metodologia está sendo seguida;
11 Conduzir reuniões diárias e reuniões de planejamento de atividades;
11 Revisar atividades, tendo conhecimento das que foram concluídas e das que
foram iniciadas;
36
11 Identificar novas tarefas, priorizá-las e alterar qualquer estimativa que possa ter q
mudado. Isso permite a ele atualizar sempre o Burndown Chart (veremos esse termo
em detalhes no tópico de Artefatos);
11 Tomar ações para tarefas em aberto e computar quantas tarefas estão em aberto com
o objetivo de minimizá-las o máximo possível para garantir um trabalho eficiente;
11 Avaliar as pendências e obstáculos que causam prejuízos ao andamento do projeto.

Essas pendências e obstáculos devem ser listados, para receber níveis de prioridade
e ser acompanhados com o objetivo de minimizá-los o mais rapidamente possível, a
fim de serem solucionados. Um plano de ação deve ser implementado de acordo com
a ordem de prioridade desses impedimentos. Alguns podem ser resolvidos pelo time,
outros através de vários times, e outros precisam do envolvimento da gerência ou até
do cliente, pois podem ser problemas que não são da alçada da equipe e, portanto,
podem correr o risco de causar um bloqueio no andamento do projeto;
11 Efetuar a gestão das pessoas, percebendo e resolvendo problemas pessoais ou conflitos

entre os integrantes do time do desenvolvimento Scrum. Caso o Scrum Master não
consiga resolver algum tipo de problema, deve solicitar ajuda à gerência ou do depar-
tamento de Recursos Humanos. Alguns estudos apontam que 50% dos problemas de
desenvolvimento acontecem por razões pessoais, então o Scrum Master precisa estar
sempre atento ao time para maximizar a produtividade e motivação da equipe.
Equipe de desenvolvimento
Também conhecida como Scrum Team, correspondem aos membros encarregados por q
realizar as atividades de projeto. Ou seja, são aqueles que vão efetivamente colocar a
mão na massa para que o projeto se concretize.
Suas principais atividades são organizar e gerenciar suas próprias atividades. e geral-
mente estão integralmente dedicados ao projeto. Dependendo da complexidade do sof-
tware, um projeto pode ter mais do que uma equipe de desenvolvimento. No entanto, a
troca de equipe só deve ocorrer na mudança de ciclo.
Suas principais características são:
11 Multifuncional e auto-organizável;
11 Pequenas e multidisciplinares, com até 10 participantes;
11 Definem metas a cada Sprint, junto com o Scrum Master, e especificam seus resul-
tados de trabalho;
11 Têm como responsabilidade principal entregar o bloco (Sprint) no tempo determi-

nado e com o mínimo de erro possível;
11 Têm o dever de respeitar as regras da metodologia;
11 Devem sempre manter o senso de equipe.
Como já falamos, por ser multifuncional, a equipe de desenvolvimento Scrum deve ser
composta por profissionais dos mais variados perfis, incluindo, mas não se limitando a:
11 Programadores;
11 Testadores;
11 Analistas;
11 Desenvolvedores de interfaces;
11 Administradores de bancos de dados.
37
Na prática, a diferença entre uma equipe não multifuncional é que na primeira, como q
podemos visualizar na figura 3.1, o projeto anda mais rápido, pois profissionais de dife-
rentes especialidades trabalham juntos para cumprir uma tarefa. O sentido de equipe é
exatamente esse – os membros compensam entre si as competências e as carências, em
um aprendizado mútuo e contínuo.
Time não Multifuncional

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Análise Código Testa
Time Multifuncional
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Análise Análise Análise
Figura 3.1
Código Código Código Diferença de
velocidade entre
equipes não
Testa Testa Testa multifuncionais e
multifuncionais.
Cerimônias
A equipe também tem a responsabilidade de participar das cerimônias. Essas são q
reuniões que ocorrem em diversos momentos durante o projeto. O método é dividido
sucintamente em basicamente três cerimônias principais, a saber:
11 Reuniões de Planejamento da Sprint (Planning Meetings);
11 Reuniões Diárias de Scrum (Daily Meetings);
11 Reunião de Revisão da Sprint (Sprint Retrospective).
Esses três tipos de evento caracterizam bem o ciclo de vida de cada Sprint, que possui
início, meio e fim.
Reunião de planejamento da Sprint (Planning Meeting)

Os participantes da reunião de planejamento são: q
11 Product Owner;
11 Cliente (e outras quaisquer partes interessadas, como diretores ou representantes

do cliente);
11 Scrum Master;
11 Equipe de desenvolvimento.
38
Também chamada de Scrum Planning Meeting, a reunião de planejamento é a primeira q
reunião do projeto, e seu objetivo é realizar o planejamento da Sprint, definindo escopo,
estimativa e importância.
Segundo Cockburn (2001), essa reunião é crítica para o sucesso do projeto, pois se não for
devidamente planejada e bem realizada, pode ocasionar problemas com atrasos, estimativas
mal realizadas e outros problemas típicos.
Em uma primeira etapa da reunião de planejamento da Sprint, o Product Owner trabalha q

em conjunto com o cliente para levantar todas as funcionalidades que o cliente deseja
e assim criar uma lista de funcionalidades requeridas. Em seguida, são selecionadas as
funcionalidades que devem ser entregues na próxima Sprint e definidas as prioridades
de cada funcionalidade de acordo com as necessidades do cliente. Essa lista final é o que
chamamos de Product Backlog, e é a base da segunda parte da reunião.
Na segunda etapa, o Scrum Master trabalha junto com o Product Owner e a Equipe de
Desenvolvimento para determinar como as tarefas devem ser executadas e o tempo
que cada funcionalidade do Product Backlog demandará para ser concluída. Isso ajuda o
Product Owner a definir prazos reais para o projeto e permite acompanhar o andamento
do projeto durante todo o período de desenvolvimento.
Após a confecção do Product Backlog com as prioridades e prazos relacionados, a

reunião continua apenas com Scrum Master e a Equipe de Desenvolvimento. O Scrum
Master quebra cada tarefa em pequenas tarefas, delegando-as aos respectivos profissio-
nais.
Assim, a reunião de planejamento da Sprint tem duas partes. As primeiras quatro horas
são gastas com o Product Owner apresentando a maior prioridade do Product Backlog
para a equipe, incluindo questionamentos da equipe sobre o conteúdo, propósito, signi-
ficado e as intenções do Product Backlog. Quando a equipe sabe o suficiente, mas dentro
dessas primeiras quatro horas, a equipe seleciona tanto do Product Backlog quanto
acredita que pode se transformar em um incremento completo de funcionalidade do
produto potencialmente utilizável até o final do Sprint.
Durante a segunda parte de quatro horas de reunião de planejamento do Sprint, a

equipe planeja, de fato, a Sprint. Como a equipe é responsável pela gestão do seu
próprio trabalho, ela precisa de um plano provisório para iniciar a Sprint. As tarefas
que compõem esse plano são colocadas em um Sprint Backlog; as tarefas dessa Sprint
Backlog vão emergir à medida que a Sprint evolui. No início do segundo período de
quatro horas da reunião de planejamento do Sprint, na verdade já se considera que a
Sprint começou, e o relógio está correndo em direção à Sprint de 30 dias.
Como a equipe de desenvolvimento é auto-organizada, deve informar as horas gastas

em cada tarefa e o Scrum Master a ajuda a definir o tempo baseado no grau de dificul-
dade da funcionalidade e do nível de produtividade de cada profissional. A equipe de
desenvolvimento não pode sofrer interferências externas. É blindada pelo Scrum Master
de qualquer desvio que saia do objetivo previamente definido.
Essa reunião dura até 8 horas, e é ela que define o Sprint Backlog. Para validar se todos
os pontos que devem ser abordados em reunião foram concluídos, é interessante fazer
um checklist da reunião respondendo às seguintes questões:
11 A visão do produto foi completamente entendida?
11 Todas as funcionalidades que o cliente deseja foram levantadas?
39
11 Os itens do Product Backlog que serão entregues na próxima Sprint foram selecionados? q
11 Os níveis de prioridade dos itens do Product Backlog foram definidos?
11 Os prazos dos itens do Product Backlog foram definidos?
11 A meta da Sprint (ou seja, o que deve ser entregue) foi estabelecida?
11 As histórias (funcionalidades narradas pelo cliente) estão quebradas em várias tarefas?
11 Todas as tarefas têm um profissional responsável?
11 Preparar o “Task Board” – quadro de tarefas;
11 Preparar o gráfico de Burndown.
Uma vez definido o Sprint Backlog, com a listagem de todas as tarefas, seus responsáveis
e prazos, o processo de desenvolvimento começa.
Reuniões diárias de Scrum (Daily)

Os participantes das reuniões diárias são: q
11 Scrum Master;
11 Equipe de desenvolvimento.
Uma das principais características da metodologia são as reuniões diárias de Scrum,

onde o Scrum Master se reúne com a equipe de desenvolvimento para avaliar os pro-
gressos do projeto e possíveis impedimentos que estejam atrapalhando o progresso
do trabalho de desenvolvimento.
As regras para as Daily são:
11 Essas reuniões acontecem todos os dias durante o ciclo de desenvolvimento;
11 São tipicamente rápidas e objetivas;
11 A ideia é que os participantes estejam de pé durante a reunião;
11 Ocorrem preferencialmente no turno da manhã;
11 Têm uma duração de no máximo 15 minutos, para evitar perder o foco do que está
sendo desenvolvido e divergências de assuntos.
A reunião diária de Scrum é uma maneira eficiente de manter os membros cientes dos
objetivos e forçar que os profissionais não percam o foco. Elas não representam uma
forma de cobrança vinda de um gerente de projetos, mas uma maneira de sincronizar a
equipe às tarefas e relatar os impedimentos que possam estar interferindo no anda-
mento da Sprint. Uma reunião diária de Scrum típica pode ser encontrada na figura 3.2.
Figura 3.2
Reunião diária de
Scrum
(Daily Scrum).
40
Na Daily Scrum, cada membro da equipe responde a três perguntas: q
11 O que você fez nesse projeto desde a última reunião diária do Scrum?
11 O que você planeja fazer nesse projeto entre agora e a próxima reunião diária do Scrum?
11 Que obstáculos se interpõem no caminho da equipe para atender seus compro-

missos a esse Sprint e esse projeto?
Como se pode imaginar, o Scrum Master tem um papel muito importante nessas
reuniões, pois é o responsável por identificar todos os problemas ou novas tarefas que
surgirem e replanejar o plano da Sprint atual, remanejando o Task Board e o gráfico de
Burndown, artefatos que estudaremos na próxima sessão.
Reunião de revisão da Sprint (Sprint Review)

Também denominada de Sprint Review, a reunião de revisão da Sprint ajuda a equipe, q
de forma colaborativa, a obter feedback e determinar os objetivos da próxima iteração,
assim como a qualidade e as capacidades das funcionalidades produzidas.
Os participantes da reunião de revisão da Sprint são:
11 Product Owner;
11 Equipe de Desenvolvimento;
11 Scrum Master;
11 Clientes (e outras partes interessadas, tais como diretores e representantes do cliente);
11 Engenheiros de outros projetos semelhantes.
Segundo Martins (2006), a reunião de revisão da Sprint é uma reunião informal de quatro
horas de duração, na qual a equipe de desenvolvimento, juntamente do Scrum Master, se
reúne com o Product Owner e convidados para apresentar o resultado da Sprint – ou seja,
tudo o que foi desenvolvido durante o ciclo de desenvolvimento da Sprint atual.
Na primeira parte da reunião, o Product Owner é responsável por validar os requisitos e,

caso necessário, solicitar ajustes para que o projeto se torne adequado às necessidades
do cliente. Depois de revisar todo esse resultado, o Product Owner define quais itens do
Product Backlog foram completados na Sprint, discutindo então com membros da equipe e
com o cliente quais serão as novas prioridades. Esse é o primeiro passo para criar uma nova
Sprint e definir juntamente com a equipe um novo incremento no produto, ou seja, uma
nova parte do produto utilizável que será entregue no final da nova Sprint.
Ao final da apresentação das funcionalidades desenvolvidas, o cliente é questionado quanto

às suas impressões, mudanças necessárias e alterações de prioridades. Possíveis rearranjos
nos itens do Product Backlog ou funcionalidades que não foram entregues como esperado
podem ser inseridos na próxima Sprint.
Depois que essa reunião é finalizada, uma nova Sprint pode começar até que todo o q
produto seja implementado ou finalizado e o Product Backlog esteja sem pendências.

Para validar se todos os pontos abordados na reunião foram concluídos, é interessante
fazer um checklist da reunião, respondendo às seguintes questões:
11 Qual o valor acrescentado nesse incremento (bloco)?
11 O que foi completado no nosso Sprint backlog?
11 Qual o feedback por parte do cliente do projeto?
41
11 Quais foram os pontos fracos e fortes da equipe durante o Sprint? q
11 Alguém teve alguma dificuldade?
11 Alguém vê algum risco futuro para o projeto?
11 Quais os pontos de melhoria a seguir com o próximo processo na próxima Sprint?
Reunião de retrospectiva da Sprint (Sprint Retrospective)

Durante a retrospectiva, o Scrum Master reúne-se com a equipe de desenvolvimento e q
revisa os altos e baixos do ciclo. O time conversa para analisar os pontos positivos e como
pode melhorar ainda mais o ambiente de trabalho, as ferramentas e o convívio entre as
partes, bem como suas funções. Trata-se basicamente de uma parte de um aprimora-
mento interno.
Parte de qualquer projeto ágil de gestão, a retrospectiva do Sprint é uma reunião em

que o Scrum Master, o proprietário do produto e a equipe de desenvolvimento discutem
como a Sprint acontecem e como podem melhorar na próxima. Se a equipe Scrum inte-
rage regularmente com os agentes externos, as percepções dessas partes interessadas
podem ser bastante valiosas e elas podem merecer um convite para a retrospectiva.
O objetivo da retrospectiva da Sprint é melhorar continuamente os processos. Melhorar

e personalizar os processos de acordo com as necessidades de cada equipe Scrum
individualmente aumenta a moral da equipe Scrum, melhora a eficiência e aumenta a
velocidade – ou seja, a produção de trabalho.
É importante entender que os resultados encontrados nas retrospectivas de Sprint podem

ser únicos para equipes diferentes de Scrum. Por exemplo, uma equipe pode decidir entrar
em trabalho cedo e sair mais cedo em determinado dia: ou fazer o oposto. A flexibilidade
para trabalhar quando a equipe se sente mais produtiva pode aumentar a motivação e a
velocidade de trabalho. É importante lembrar também que abordagens ágeis rapidamente
revelam problemas dentro de projetos – dados do Sprint Backlog mostram exatamente
onde a equipe de desenvolvimento mostrou pioras ou melhoras.
A reunião de retrospectiva da Sprint é orientada à ação e deve cobrir três perguntas q

principais:
11 O que deu certo durante a Sprint?
11 O que gostaríamos de mudar?
11 Como podemos implementar tal mudança?
Dica: para a primeira retrospectiva da Sprint, todos na equipe scrum precisam considerar as
três perguntas antes da reunião iniciar. Assim, é bom o Scrum Master enviar as perguntas
antecipadamente, para que todos na equipe de Scrum façam algumas notas de antemão
ou até mesmo tomem notas durante toda a Sprint. Uma boa estratégia é anotar os impe-
dimentos encontrados durante as reuniões diárias e tentar encontrar possíveis pontos de
melhoria a partir destes. A partir da segunda reunião de retrospectiva da Sprint, podemos
comparar a Sprint atual com anteriores.
Tópicos adicionais que podem ser cobertos nessa reunião: q

11 Resultados: compare a quantidade de trabalho planejado com o que a equipe de
desenvolvimento acabou completando de fato. Revise o gráfico de Burndown para
entender a performance da equipe de desenvolvimento.
42
11 Pessoas: discuta o alinhamento e a composição da equipe; q
11 Relacionamentos: discuta sobre comunicação, colaboração e trabalho em pares;
11 Processos: discuta sobre suporte, desenvolvimento e processos de revisão de código;
11 Ferramentas: como estão as ferramentas atuais para a equipe de desenvolvimento

Scrum? Pense sobre os artefatos, ferramentas automatizadas, de comunicação
e técnicas;
11 Produtividade: como a equipe poderia melhorar a produtividade e realizar a maior

quantidade de trabalho na próxima Sprint?
Para algumas equipes Scrum, pode ser difícil se abrir no início. O Scrum Master pode precisar
fazer perguntas específicas para iniciar discussões. Participar em retrospectivas requer
prática. O que importa é para incentivar a equipe Scrum a assumir a responsabilidade: para
realmente abraçar a característica de autogestão.
A retrospectiva da Sprint é uma das melhores oportunidades que a equipe Scrum tem de
colocar as ideias de inspeção e adaptação em ação. É importante que a equipe possua a
capacidade de identificar desafios e soluções durante a retrospectiva e não deixe essas
soluções para após a reunião. Assim, a reunião de retrospectiva é ser orientada a ações, tais
como inspeção e adaptação da equipe, que podem ser gravados, inclusive, informalmente:
o importante é garantir visibilidade de ações sobre os itens listados após a reunião.
Artefatos
Os artefatos do Scrum são as ferramentas básicas para se trabalhar com esse modelo q
de desenvolvimento. Esses artefatos servem como guias e indicadores para suportar o
processo e são divididos em seis. Podemos citar:
11 Estórias (User stories);
11 Planning Poker;
11 Sprint;
l 11 Product Backlog;
Nesta sessão, 11 Sprint Backlog;
estudaremos cada um
deles em detalhes. 11 Burndown Chart.
Histórias (user stories)

Uma história do usuário, também denominada de user story, é uma pequena descrição q
que detalha um item do Product Backlog. Esse item posteriormente virará uma fun-
cionalidade ou mais. É tipicamente narrada pelo cliente e o Product Owner, através de
técnicas de levantamento de requisitos, o ajuda a detalhar e extrair pontos importantes
para composição de funcionalidades do sistema para o tornar legível – em um formato

que se torne útil o suficiente para suportar o negócio.
As user stories ajudam no entendimento das atividades de negócio e também são

utilizadas como suporte para atividades de planejamento. São usadas como base para
cálculo de velocidade da equipe. Usualmente, a estimativa é feita em pontos, os denomi-
nados story points, embora também possam ser feitos em horas.
43
Uma dica para escrever uma boa história é conversar sobre ela, entre os desenvolvedores e os
clientes, de forma a detalhar os itens e esclarecer todas as dúvidas sobre o que deve ser feito.
Antes de se reunir com o cliente, o proprietário do produto e a equipe de desenvolvimento devem
preparar um questionário com perguntas que auxiliam o cliente a lembrar de fatos que podem
passar despercebidos, mas que podem ter sido importantes para o desenvolvimento do produto.
Exemplo: “Eu gostaria de efetuar um orçamento automaticamente, a partir de um cliente q

ou serviço. Gostaria de poder enviar o orçamento para o cliente sem precisar nem entrar
em contato. Eu acho que passo muitas horas calculando o total do orçamento, pois por
serem muitos, eu nunca tenho os preços atualizados.”
Seria difícil dar início ao desenvolvimento baseado apenas nesse pequeno texto.
Baseado nesse exemplo, seguem os tipos de questões que a equipe pode aplicar para
extrair mais informações úteis para o projeto:
11 Você faz o orçamento sempre para os mesmos clientes?
11 No sistema atual você está acostumado a fazer pesquisa de serviços através de

quais atributos?
11 Um produto é fornecido apenas por um fornecedor?
11 O cliente sempre compra os mesmos serviços?
11 É possível enviar o orçamento por e-mail ou através de interface para o cliente;

porém, como você pretende receber a autorização? Via interface gráfica, e-mail, ou
através de um contato fora do sistema?
11 Os preços dos serviços são muito dinâmicos?
11 Os preços dos serviços são personalizados para cada cliente?
11 Você já tem um cadastro de serviço no software atual?
É comum que os detalhes sejam expressos em histórias futuras. É melhor ter muitas histó-
rias menores do que ter poucas histórias grandes. É também importante lembrarmos que a
comunicação “cara a cara” é um dos princípios da filosofia ágil e, por isso, em vez de escrever
todos os detalhes na user story, o melhor a fazer é reunir a equipe de desenvolvimento e o
cliente e garantir uma discussão sobre os detalhes, já definindo as funcionalidades.
Partindo desse exemplo de user story, poderíamos definir as seguintes funcionalidades: q

11 Manter cliente:
22 Consultar cliente.
11 Manter serviço:
22 Cadastrar serviço;
22 Atualizar preço do serviço;
22 Excluir serviço;
22 Consultar serviço.
11 Manter orçamento:
22 Criar orçamento;
22 Calcular orçamento;
22 Enviar orçamento;
22 Excluir orçamento;
22 Consultar orçamento;
22 Autorizar orçamento.
44
É interessante que o proprietário do produto faça uma espécie de estágio no cliente para
vivenciar a atividade no negócio e assim consiga ser mais sensível às necessidades.
Um princípio-chave no Scrum é o reconhecimento de que, durante um projeto, os clientes
podem mudar de ideia sobre o que eles querem e precisam (muitas vezes, chamados de
“requirements churn” – do inglês “requisitos agitados”), e que os desafios imprevisíveis não
podem ser facilmente tratados de uma maneira preditiva ou planejada. Como tal, o Scrum
adota uma abordagem empírica, aceitando que o problema não pode ser totalmente enten-
dido ou definido, focando na maximização da habilidade da equipe para entregar rapida-
mente e responder as necessidades emergentes.
As user stories devem ser compreensíveis por todos os envolvidos: usuários, cliente q
e equipe de desenvolvimento. Portanto, existem alguns critérios importantes com os
quais se preocupar quando se descreve histórias de usuário. Elas precisam ser:
11 Negociáveis: uma user story não é um processo jurídico e, portanto, não necessita
ter excesso de informações. A ausência dessas informações estimulará que a equipe
esteja sempre negociando os detalhes em futuras conversas com o cliente;
11 Valiosas: as user stories precisam ter valor para o cliente ou usuários;
11 Entendimento comum: como o planejamento do Sprint no Scrum é baseado em

estimativas, as user stories precisam ser estimáveis. Não é necessário que a equipe
entenda todos os detalhes da user story, mas é necessário um nível de entendimento
comum dela para que seja possível realizar a estimativa;
11 Pequena: uma user story deve ser pequena o suficiente para que possa ser imple-
mentada e implantada, mas grande o suficiente para traga valor para o negócio;
11 Testável: as user stories precisam ser testáveis; caso contrário, não será possível a
equipe saber se o desenvolvimento foi validado ou não.
Planning Poker
O Planning Poker é basicamente a atribuição de pontos às user stories. É uma prática q
que ajuda na estimativa de uma história ou de uma tarefa. Tais pontos representam um
grau de dificuldade de uma funcionalidade perante o projeto.
Planning Poker no Scrum reúne várias opiniões de especialistas para a estimativa ágil de
um projeto. Nesse tipo de planejamento, que deve incluir todos, desde programadores,
testadores e engenheiros de banco de dados com analistas e designers de interação
do usuário. Como esses membros da equipe representam todas as disciplinas de um
projeto de software, eles são adequados para a tarefa de estimativa.
A dinâmica do Planning Poker é como segue: inicialmente, a equipe do projeto deve

definir uma escala para o Planning Poker. Normalmente, esse usa uma escala de pontos
não linear, como, por exemplo:
10, 20, 30, 50, 70, 130...
Em segundo lugar, devem-se definir valores de referências. Como, por exemplo: identificar
uma user story à qual pode ser atribuída o menor valor (10 pontos), outra que representa
um valor mediano (50 pontas) e outra à qual representa o valor máximo (130 pontos). Dessa
forma, essas histórias serão utilizadas como referências para pontuação de demais user
stories que apareçam durante o processo de estimativa nas reuniões de planejamento.
45
No início do exercício de planejamento ágil, a cada estimador é dado um baralho de q
cartões de Planning Poker. Cada cartão tem uma das estimativas válidas sobre ela,
como as recém-descritas. Para cada história de usuário ou tema a ser estimado, um
moderador (geralmente o Product Owner ou o Scrum Master) lê a descrição. Haverá
alguma discussão, onde o moderador responde a quaisquer perguntas dos avaliadores.
Mas o objetivo de Planning Poker no Scrum não é para derivar uma estimativa de que vai
resistir a qualquer controle futuro. Em vez disso, a ideia é obter uma estimativa valiosa
que pode ser alcançada de forma barata.
Após a discussão, cada um estimador seleciona de maneira privada um cartão repre-

sentando sua estimativa. Uma vez que cada estimador fez uma seleção, os cartões são
simultaneamente virados e mostrados, de forma que todos os participantes podem ver
a estimativa uns dos outros. Nesse ponto, é provável que as estimativas provavelmente
sejam significativamente diferentes, e isso é aceitável. O moderador deve encorajar
que as estimativas marginais expliquem as suas perspectivas para que a equipe possa
entender o porquê de números mais discrepantes. O moderador toma notas durante
essa sessão de planejamento ágil, pois se imagina que isso será útil quando a história for
programada e testada. Não haverá problemas se, após discussões, quaisquer parti-
cipantes decidirem mudar suas estimativas em função de discordâncias ou convenci-
mentos – é comum em equipes ágeis.
Após a discussão, uma nova rodada de estimativa deve acontecer e uma nova seleção
de cartão pode ocorrer. Muitas vezes, as estimativas vão convergir na segunda rodada.
Senão, repita o processo até que a equipe concorde com uma única estimativa a ser
usada para a user story. Raramente será necessário mais do que três rodadas de discus-
sões na estimativa para se alcançar a meta Sprint.
Sprint é uma iteração, ou seja, um bloco de desenvolvimento em Scrum, que deve

ser completada em 15 dias ou em 1 mês. Como todos os processos ágeis, Scrum é
uma abordagem iterativa e incremental ao desenvolvimento de software. Embora os
termos iterativo e incremental sejam normalmente utilizados em conjunto, cada um
deles possui um significado único. Vamos brevemente provocá-los separados para que
possamos entender melhor seus significados.
O desenvolvimento incremental envolve a construção de um sistema peça por peça. Ini-

cialmente desenvolve-se uma parte e, em seguida, um o bloco adicional é adicionado à pri-
meira, e assim por diante. Alistair Cockburn (2008) descreve desenvolvimento incremental
principalmente como uma “estratégia de encenação e de agendamento”. Por exemplo, uma
abordagem incremental para o desenvolvimento de um site de leilão on-line pode envolver
inicialmente desenvolver a capacidade de criar contas no site. Depois, o desenvolvimento
da capacidade de listar itens para venda e, em seguida, a capacidade de oferta em itens, e
assim por diante.
Por outro lado, o desenvolvimento iterativo é o que Cockburn refere-se como um “retra-
balho estratégia de programação”. Um processo de desenvolvimento iterativo reconhece a
impossibilidade – ou, pelo menos, improbabilidade – de se conseguir acertar o desenvolvi-
mento de funcionalidade em sua inteireza da primeira vez. Dentro da construção de um site

de leilão on-line de forma iterativa, podemos primeiro desenvolver uma versão preliminar
do site completo, obter feedback sobre ele, desenvolver uma versão subsequente do site
completo que incorpora o feedback do cliente na segunda vez e repetir o processo, con-
forme necessário.
46
Assim, em um processo incremental, desenvolvemos totalmente uma funcionalidade e, em
seguida, segue-se para a próxima. Em um processo iterativo, se constrói todo o sistema, mas
isso é feito de forma imperfeita em primeiro lugar, usando passos subsequentes através
de todo o sistema para melhoria. As fraquezas inerentes de ser apenas iterativo ou apenas
incrementais desaparecem quando eles são combinados, e essa é a forma como eles estão
dispostos em Scrum.
Ao final da Sprint, a equipe do projeto deverá produzir uma entrega de valor para o cliente –
que se trata de um software funcional. A entrega de valor é, portanto, a meta da Sprint, que
deverá estar bem definida e combinada com o cliente antes do começo de sua execução.
Durante cada Sprint, a equipe cria um incremento de produto “entregável”, ou seja, as
funcionalidades testadas e prontas para uso. O conjunto de funcionalidades que entram em
uma Sprint vem do Product Backlog.
Um software funcional é aquele que está potencialmente completo e pronto para uso.
Aprender como entregar um software dessa natureza é um dos maiores desafios que uma
equipe nova nos processos Scrum pode passar. No entanto, isso é fundamental para se
tornar ágil. Na verdade, é tão importante que um dos quatro valores indicados no Manifesto
Ágil afirma que se valoriza “software funcional mais que documentação abrangente” (Beck
et al., 2001).
Metodologias ágeis enfatizam software funcional por três razões: q

11 Software funcional possibilita feedback: uma equipe pode coletar mais e melhor
feedback se mostra (ou melhor, entrega) um produto parcial em funcionamento para
os utilizadores do que se fornece a esses usuários documento sobre o que o produto
vai fazer;
11 Software funcional auxilia a equipe avaliar seu processo: um dos maiores riscos
em um projeto não é saber o quanto ainda resta a ser feito. Quando se permite
muito de um sistema em estado inacabado, é extremamente difícil saber o quanto de
esforço ainda resta para trazer o sistema para um estado potencialmente de entrega;
11 Software funcional permite que a equipe entregue o produto mais rapidamente

se desejar: no mundo competitivo e em rápida mudança de hoje, a opção de entregar
o produto precocemente, mesmo que isso signifique entrega de menos recursos,
pode ser muito valioso. Colocar o software em uma posição próxima a essa, no final
de cada Sprint, oferece essa opção.
Conforme vimos anteriormente, durante a reunião de planejamento da Sprint, são defi-

nidos os itens do Product Backlog que entrarão para o Sprint. Nessa reunião, o Product
Owner informa a equipe dos itens no Product Backlog que o cliente deseja que sejam
priorizados. A equipe então determina quanto eles podem se comprometer a concluir
durante a próxima Sprint e registram isso no Sprint Backlog.
Regras da Sprint:
1. Entregue algo de valor a cada Sprint.

2. Prepare essa Sprint para a próxima.
3. Mantenha os períodos de tempo regulares e estritos.
4. Não mude os objetivos.
5. Obtenha feedback, aprenda e adapte.
47
Entregue algo de valor a cada Sprint
Mesmo que se certificar que no fim de cada Sprint haja um software funcional não seja q
um desafio muito grande, as equipes Scrum também devem entregar algo valioso para
os usuários ou clientes ao fim de cada Sprint em termos de sistema. A definição do que
é valioso para usuários ou clientes pode ser estipulado muito facilmente e de forma
quase maliciosa.
Por exemplo, uma equipe pode argumentar que atualizar os desktops dos desen-
volvedores para a versão mais recente de seu Sistema Operacional preferido lhes
permite desenvolver mais rapidamente para que os novos recursos se tornem dispo-
nível aos clientes de maneira mais eficientemente. Embora isso possa muito bem ser
verdade, a intenção é que, a cada Sprint, se deve entregar algo de valor imediato para
os usuários ou clientes que eles possam enxergar.
Prepare essa Sprint para a próxima
Esteja preparado. Passe um pouco de esforço em cada Sprint preparando-se para a q

Sprint Seguinte. Ken Schwaber (2009) recomenda a alocação de cerca de 10% do
tempo disponível de uma equipe em qualquer esforço para se preparar para o próximo
esforço. A equipe deve, é claro, ajustar esse valor para cima ou para baixo com base na
sua experiência.
Já sabemos que uma equipe não deve puxar uma user story ou outro item do Product
Backlog em uma Sprint se é claramente muito grande para ser concluído. Uma história de
usuário épica que levará meses para completar deve ser decomposta em pedaços menores,
de modo que cada uma possa ser concluída dentro de uma Sprint. Este é verdadeiro para
user stories que são demasiadamente vagas. Se uma história não pode ser concluída em
uma Sprint, ela não deve ser trazida para a Sprint. Em vez disso, a equipe precisa para
passar por algum esforço para aprender sobre a estória pela primeira vez.
No entanto, perceba que uma user story não precisa estar completamente compreendida
para entrar em uma Sprint. Uma história de usuário no Product Backlog não precisa ser
totalmente pensada, com todos os detalhes trabalhados, antes de ser puxada para uma
Sprint. O Product Owner e outros membros da equipe ainda vão colaborar com a história
durante a Sprint. No entanto, cada história de usuário puxada para a Sprint deve ser enten-
dida em detalhes o suficiente para que, quando discutida e argumentada durante a Sprint,
possa ser detalhada e concluída.
Há algumas coisas que a equipe Scrum deve fazer para garantir esse pensamento q
proativo nas Sprints:
11 Discutir o product backlog. identificar os cinco principais itens na necessidade de pro-

mover o pensamento proativo. Para cada um dos itens, discutir quem precisa pensar
sobre isso (arquiteto? Designer de experiência com o usuário? Administrador de
banco de dados? Outro?) E decidir em quantas Sprints de antemão que deve começar;
11 Nas suas próximas Sprints Reviews, discuta se cada item no Product Backlog possui deta-
lhes suficientes incluídos detalhes suficientes e se ele foi adicionado apenas no tempo;
11 Para cada Sprint, é necessário controlar a quantidade de tempo gasto pensando no

futuro. Normalmente, cerca de 10% do tempo disponível de uma equipe deve ser
gasto olhando para frente.
48
Mantenha os períodos de tempo regulares e estritos
Manter os períodos de tempo estritos para as Sprints reforça a ideia que o projeto se move
continuamente adiante. A equipe deve entregar um novo incremento de produto potencial-
mente utilizável constantemente. Caso contrário, ou seja, se os períodos variarem (“Vamos
executar uma Sprint de seis semanas agora porque nós estamos trabalhando em elementos
arquiteturais”) ou se estes são ocasionalmente estendidos (“Nós só precisamos de mais três
dias”), essa disciplina valiosa será perdida ao longo do tempo.
Podemos citar algumas vantagens de se manter períodos de tempo regulares: q

11 Equipes se beneficiam de uma cadência regular: quando as durações Sprint variam,
os membros da equipe são muitas vezes se sentem inseguros do cronograma. Per-
guntas como “Essa é a última semana da Sprint?” ou “Será que nós enviamos nessa
quinta-feira ou na próxima quinta-feira?” tornam-se comuns. Uma cadência regular de
uma a quatro semanas ajuda as equipes a se acostumarem a um ritmo de trabalho;
11 Planejar a Sprint se torna mais fácil: tanto o planejamento da Sprint, quanto o pla-
nejamento do release, são simplificados quando as equipes ficam com uma duração
da Sprint constante. O planejamento da Sprint é mais fácil, porque depois de normal-
mente duas a cinco Sprints a equipe aprende facilmente quantas horas de trabalho
podem ser planejadas em uma Sprint;
11 Planejar a release se torna mais fácil: equipes Scrum derivam seus planos de lan-
çamento empiricamente (sempre que possível). Eles estimam o tamanho do trabalho
a ser feito em um projeto e, em seguida, medem a quantidade concluída por Sprint.
Se a quantidade de horas na Sprint varia, medir a velocidade de uma equipe se torna
mais difícil, pois não há nenhuma garantia de que uma Sprint de quatro semanas vai
entregar o dobro que uma Sprint de duas semanas. Normalizar a velocidade como
“velocidade por semana” funciona um pouco, mas é um trabalho extra desnecessário
quando as Sprints são mantidas sob o mesmo período de tempo.
Para deixar claro que os prazos da Sprint precisam ser cumpridos rigorosamente, é óbvio
que as equipes vão ocasionalmente precisar deixar de fazer algum trabalho que tinham ini-
cialmente planejado durante alguma Sprint. Essa situação não é desejada, mas é realista, e
espera-se que estes possam compensá-la acrescentando ocasionalmente mais trabalho em
uma Sprint futura. Desde que o trabalho seja realizado em ordem de prioridade, isso não é o
fim do mundo. Assim, invariavelmente, termine as Sprints no tempo correto. Não chegue na
data planejada e decida que precisa de mais um ou dois dias para finalizar o trabalho.
Não mude os objetivos
Durante uma Sprint, nenhum integrante da equipe, nem mesmo o Product Owner, pode q
alterar o Sprint Backlog. Ou seja, a cada Sprint, os requisitos são congelados. O desen-
volvimento de cada Sprint deve terminar no tempo predefinido em reunião. Caso os
requisitos não sejam finalizados por qualquer motivo, eles são deixados de fora e voltam
para o Product Backlog.
A postura de Scrum de ser contra as alterações meio do Sprint pode parecer prejudicial para
o sucesso do projeto. Afinal, às vezes as mudanças são tão importantes que precisam ser
feitas. E outras vezes novas informações podem tornar inútil o trabalho no qual a equipe
está atualmente envolvida. No entanto, existem algumas exceções.
Primeiro vamos considerar o caso de o Product Owner descobrir algum novo requisito
importante que precisa ser feito prioritariamente em vez do trabalho que a equipe está
49
trabalhando. Antes de mais nada, o Scrum Master deve garantir que os objetivos da Sprint
atual sejam visíveis e conhecidos por toda a organização. Mas, quando isso acontecer, a
direção do Scrum é anunciar uma finalização anormal na Sprint, seguida imediatamente
pelo planejamento de uma nova Sprint para incluir a funcionalidade recém-descoberta de
mais alta importância.
Garantir a visibilidade dos objetivos da Sprint é importante porque torna menos

provável de acontecer.
Em muitas organizações, os únicos que veem o redirecionamento constante da equipe são

os membros da equipe em si. A abordagem Scrum de não permitir a mudança em um Sprint
Backlog, mas disponibilizar o encerramento anormal seguido de um novo começo aumenta
a visibilidade de aumento de custos e frequência de mudança. Isso deve dificultar a quanti-
dade de mudanças lançadas contra a equipe no meio de uma Sprint, pois apenas mudanças
realmente mais importantes justificarão o encerramento anormal de uma Sprint.
No caso, quando novas informações são aprendidas sobre o trabalho que está sendo reali-
zado (que pode fazer o trabalho planejado menos desejável), pode ser que a equipe aprenda
algo que significa que ele deve parar de trabalhar em alguma parte de uma Sprint. Por
exemplo, um objetivo da Sprint atual pode ser a de adicionar uma funcionalidade especial
especificamente para ajudar a fazer uma venda a um grande cliente. No meio da Sprint,
o cliente lhe diz que sua empresa tem tido um congelamento do orçamento e não pode
comprar o seu produto, mesmo que tenha a nova funcionalidade, ou que ele foi adquirido e
será forçado a usar o produto do seu concorrente, ou qualquer das situações semelhantes.
Nesses casos, pode fazer sentido parar de trabalhar nessa funcionalidade específica, depen-
dendo da conveniência geral para outros clientes e de quanto tempo o trabalho pode requerer.
No entanto, situações como essas acontecem com menos frequência do que a maioria das
pessoas que são novas para Scrum pensam. Uma situação muito mais comum é a de ter um
negócio orientado a interrupções, mudanças, em que mudanças simplesmente continuam a
aparecer e que, por causa disso, os desenvolvedores e o resto da equipe também precisam ser.
Através dos anos, as organizações se tornaram viciadas em redirecionar constantemente

suas equipes. Muitas vezes as equipes não são nem interrompidas porque o Product Owner
descobriu uma necessidade do cliente crítica ou outra interrupção válida, mas simples-
mente porque as partes interessadas não conseguiram pensar no futuro. Eles se tornaram
acostumados a trabalhar dessa forma e não estão cientes do impacto negativo que essa
abordagem tem sobre as suas equipes de desenvolvimento.
Em outras palavras, nada é permitido mudar dentro da Sprint. A equipe compromete-se a

um conjunto de trabalhos no primeiro dia e, em seguida, espera que as suas prioridades
permaneçam inalteradas durante a duração da Sprint. No entanto, embora não sejam per-
mitidas alterações na Sprint, o mundo inteiro pode estar mudando fora dela. Por fim, depois
que uma Sprint é completada, a equipe demonstra como usar o software.
Obtenha feedback, aprenda e adapte
Cada Sprint pode ser vista como um experimento. O proprietário do produto e da equipe q
se encontram no início da Sprint para identificar a experiência mais valiosa que eles
podem executar. O experimento envolve a criação de uma certa quantidade de novas
funcionalidades na forma de software funcional.
50
Grande parte da aprendizagem será sobre o produto: o que os usuários gostam? O que eles
não gostam? O que eles acham confuso? O que eles querem seguir? Quais são as caracte-
rísticas do novo incremento que pode ajudá-los pensar acerca de coisas sobre as quais eles
não tinham pensado antes?
Talvez parte do aprendizado será sobre o uso da equipe sobre o próprio Scrum: quanto
trabalho que podemos fazer em um sprint? O que fica no nosso caminho? O que poderia nos
ajudar a ir mais rápido? Estamos obtendo “feito” software a cada Sprint?
A própria característica do Scrum: ser de desenvolvimento iterativo e incremental é sobre a

geração de feedback, aprender com ele, e então adaptar o que está sendo construindo e como
este está sendo construindo. Sprints fornecem às equipes os mecanismos para fazer isso.
Product Backlog
Uma equipe Scrum renuncia a uma longa fase de requisitos em favor de uma abordagem
l
just-in-time. Assim, descrições de funcionalidades podem ser recolhidas em alto nível
no início, mas elas devem ser progressivamente refinadas no decorrer do projeto. Elas
Na reunião de
Planejamento, o são documentadas em um Product Backlog, que é uma lista de todas as funcionalidades
Product Owner prepara desejadas que ainda não estão no produto. Ele é mantido pelo Product Owner e possui uma
uma lista de funcionali-
ordem de prioridade, o que o faz ser conhecido muitas vezes como lista de funcionalidades
dades desenvolvida
em conjunto o cliente, priorizadas. Ao contrário de um documento de requisitos tradicional, um Product Backlog é
que é organizada por altamente dinâmico: itens são adicionados, removidos e priorizados novamente a cada Sprint,
prioridade de entrega.
à medida que se aprende mais sobre o produto, os usuários, a equipe e assim por diante.
Esse é o Product
Backlog.
O Product Backlog é uma lista em nível de negócio. Dessa forma, não está escrito em nível
de negócio e estão em uma linguagem do cliente. Já vimos que o Product Backlog não é final,
e que a equipe de desenvolvimento também contribui para a sua manutenção. Essa contri-
buição se dá por meio das estimativas de custos das funcionalidades.
Há um grande mito sobre os requisitos: se você os escreve, os usuários receberão exata- q

mente o que eles querem. Isso não é verdade! Na melhor das hipóteses, os usuários rece-
berão exatamente o que foi escrito, que pode ou não ser o que eles realmente querem. As
palavras escritas são enganosas – parecem ser mais precisas do que realmente são.
11 Documentos escritos podem fazer você suspender o julgamento: quando algo está
escrito, parece oficial, formal e finalizado, especialmente quando uma formatação
organizacional foi aplicada;
11 Com um documento escrito, não conversamos acerca do significado como faríamos

em uma conversa, para garantir uma transferência de entendimento;
11 Documentos escritos diminuem a responsabilidade da equipe como um todo: um

dos objetivos da mudança para o Scrum é fazer com que toda a equipe trabalhe em
conjunto em direção ao objetivo de oferecer um grande produto. Queremos tirar do
processo de desenvolvimento maus hábitos que prejudicam esse objetivo. Docu-
mentos escritos criam transferências sequenciais de atividade, que tiram a equipe
de uma unidade de propósito. Uma pessoa (ou grupo) define o produto; outro grupo
constrói. A comunicação bidirecional é desencorajada;
51
11 Não deixar o bebê sozinho sem documentação: tais deficiências na comunicação q
escrita não significam que devemos abandonar completamente os documentos de
requisitos. Em vez disso, devemos usar documentos onde for apropriado. Como o
Manifesto Ágil diz ser a favor de “software funcional em vez de documentação abran-
gente”, ágil tem sido mal interpretada como sendo totalmente contra documentação.
O objetivo no desenvolvimento ágil é encontrar o equilíbrio certo entre a documen-
tação e discussão;
11 Use User Stories para o Product Backlog: histórias de usuários são a melhor maneira
de mudar o foco de escrever sobre funcionalidades para falar sobre eles mesmos.
A user story é uma breve descrição, simples de uma funcionalidade, contada a partir
da perspectiva da pessoa que deseja uma nova função, geralmente um usuário ou
cliente do sistema. Elas são muitas vezes escritas em cartões de índice ou notas,
armazenadas e dispostos em paredes ou mesas para facilitar o planejamento e dis-
cussão. Como tal, as histórias de usuário mudam fortemente o foco de escrever sobre
os recursos para discuti-las. Uma user story frequentemente tem o formato:
Como um <tipo de usuário>, eu gostaria de <algum objetivo>, pois <alguma razão>.
Em resumo, o Product Backlog deve incluir todas as funcionalidades visíveis ao cliente e

em torno de dez dias de desenvolvimento esses itens deverão estar prontamente defi-
nidos para o seu desenvolvimento começar. As tarefas que têm mais prioridade e comple-
xidade deverão ser quebradas em sub-tarefas para poderem ser estimadas e testadas.
Observe a tabela 3.1. Um exemplo de sub-tarefa são as funcionalidades Cancelar Vinculo Tabela 3.1
e Vincular Caixa de Picking List. Product Backlog.
Product Backlog
Funcionalidade (Use case) Prioridade Estimativa Pré requisito

inicial (h)
Código Título
UC_01MC003 Manter Perfil 1 12 -
UC_01MC004 Associar Operadores aos Perfils 2 16 UC_01MC003
UC_01MC002 Gerenciar Perfil de Acesso 2 16 UC_01CT013
UC_01MC001 Painel de Rotas 1 22 UC_01CT013
UC_01CT013 Efetuar Login no Sistema 3 8 -
UC_01CT014 Gerar Relatório de Picking List 1 10 -
UC_01CT015 Registrar Mercadoria danificada 2 12 -
UC_01CT016 Manter Caixa 2 18 UC_01CT023
UC_01CT024 Manter Vínculo
UC_01CT024a Cancelar Vínculo 2 10 UC_01CT024b

UC_01CT024b Vincular Caixa ao Picking List 3 32 -
UC_01CT019 Manter Cubagem 1 28 -
UC_01CT020 Escanear Unidade 1 20 -
UC_01CT021 Expedir Picking List 2 12 -
UC_01CT023 Manter Tipo de Caixa 1 10 -
52
Sprint Backlog
Assim que a equipe Scrum escolher e definir a lista de requisitos e a prioridade de seus q
itens no Product Backlog, dá-se início a um novo ciclo, chamado Sprint. Cada um desses
itens agora será dividido em partes menores para o Sprint Backlog. Um documento
especificando o detalhe de cada funcionalidade do sistema, com informações técnicas
adicionais que auxiliarão no desenvolvimento.
A seguir, segue um exemplo de um Sprint Backlog, na tabela 3.2, da funcionalidade Con-

sultar Caixa. Não existe um padrão, pode ser feito de várias formas: Excel, Word, em um
quadro, post-it na parede, entre outros. O importante é que as informações se tornem
disponíveis para controle do projeto.
Sprint Backlog
Funcionalidade (Use case) Descrição
Código UC_01CT016 Permitir a consulta, a edição, a exclusão de caixas

e o cadastramento de novas caixas.
Título Manter Caixa
1. Operador acessa a tela de Caixas
(TL_01CU006_01);
Prioridade 2
2. Operador preenche os parâmetros de
Estimativa inicial 18 consultas desejados (Caixa, Tipo) e clica na
opção "Consultar";
Horas Trab. -
3. Sistema faz a consulta na base de dados
filtrando as caixas pelos parâmetros
Status Pendente informados;
Pré requisito UC_01CT023 4. Sistema carrega a tela com o resultado da

consulta, preenchendo os campos da grid
Menu Menu: Cadastros g Caixas (Caixa, Status, Tipo, Selecionar).
Regras Campos Status e Tipo com combobox
Tabela 3.2 A equipe compila uma lista inicial dessas tarefas na segunda parte da reunião de planeja-
Sprint Backlog da mento do Sprint. As tarefas devem ser divididas de modo que cada um leva cerca de 4 a
Funcionalidade
Consultar Caixa. 16 horas para terminar. Tarefas que durariam mais de 4 a 16 horas são considerados meros
espaços reservados para as tarefas que ainda não foram adequadamente definidas.
Logo após o Sprint Backlog estar concluído, é preenchido o campo “Horas Trab” com a q
quantidade de horas que a funcionalidade demandou para ser concluída. Sendo assim, é
possível comparar o total de horas trabalhadas com a estimativa pré-definida na reunião
de planejamento, dando oportunidade de melhorar futuras estimativas. Caso haja uma
diferença significativa, a equipe Scrum deve negociar novamente com o cliente uma
nova data de entrega.
É importante selecionar uma pessoa para adicionar, atualizar e excluir informações no

Sprint Backlog em uma planilha Excel ou em um aplicativo. No entanto, uma interface
comum, a que todos da equipe tenham acesso e possam editar os seus itens também é
recomendado, para que os membros da equipe possam podendo incluir itens conforme
concluam suas atividades, como um quadro de cartões ou post-its ou um software que
simule essa interface, como mostrado na figura 3.3. Dessa forma, o responsável pelo
Sprint Backlog pode, ao fim do dia, atualizar o arquivo.
53
Mais Importante Menos Importante
Manter Tipo Vincular Caixa

Cancelar Vínculo Manter Caixa
de Caixa ao Pick List
Figura 3.3
Lista de prioridades
simulando quadro
de cartões post-its.
Usar uma superfície grande e visível de cartões é positivo porque: q

11 As pessoas ficam de pé e caminham ficando despertas e acordadas por mais tempo;
11 Todos se sentem mais pessoalmente mais envolvidos, em vez de uma só pessoa

responsável pela planilha;
11 Fica mais fácil priorizar novamente as atividades – basta trocar a posição dos cartões;
11 Após a reunião, os cartões podem ser levados para a sala da equipe e colocado no
quadro de tarefas (Task Board) para que todos visualizem melhor.
Release Burndown
É considerado o principal gráfico de controle do Scrum e representa o trabalho restante q
dentro da Sprint de uma versão do sistema que será entregue. No exemplo mostrado a
seguir, na figura 3.4, o eixo horizontal do gráfico exibe as iterações e o eixo vertical exibe
a quantidade de trabalho restante.
250
245
200
202
Horas Restantes
150 159
140
100 113
68
50
28 Figura 3.4
0 Gráfico de
Release 5\ Release 5\ Release 5\ Release 5\ Release 5\ Release 5\ Release 6\ Burndown em
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 1 Planejamento.
De acordo com Mountain (2011), esse tipo de gráfico funciona em muitas situações e com
diversas equipes. Porém, em projetos com muitas mudanças de requisitos, talvez o gráfico
não seja adequado, já que a quantidade de horas não vai refletir a ideia de um projeto que
se consome.
Segundo Highsmith (2004), uma das principais ferramentas de equipe para acompanhar o
projeto no Scrum é o release burndown chart, que mostra o andamento diário da equipe
por horas, de acordo com a soma das tarefas listadas no Sprint Backlog. A equipe também
possui uma task board onde as funcionalidades são colocadas separadas por estados.
54
Gráfico de Burndown
É uma das principais ferramentas para o gerenciamento do processo de desenvolvimento, q
pois permite mostrar as partes do trabalho que faltam para uma Sprint acabar, dia por dia.
É um gráfico que mostra a quantidade cumulativa restante de trabalho de uma Sprint,

diariamente, e permite visualizar o trabalho ainda não cumprida sobre o tempo, assim,
habilitando a avaliação sobre a quantidade restante de trabalho e o tempo restante para
completar uma Sprint. É com base nesse gráfico que se pode orientar e tomar decisões
quanto à modificação do escopo ou cancelamento da Sprint.
Sua atualização deve ser diária para que assim a tomada de decisão seja realizada com
base em dados atualizados, melhorando a produtividade da equipe e habilitando a
previsibilidade de riscos. Durante as Scrums diárias, o Scrum Master acompanha os
membros da equipe para perceber o que foi concluído até aquele momento. Assim, dia a
dia, ele ajusta o gráfico de Burndown e, a qualquer momento, todo o time pode ter uma
ideia do andamento do processo. O mesmo gráfico pode ser mostrado para o Product
Owner visualizar a trajetória do projeto: atrasado, adiantado ou dentro do cronograma.
Em outras palavras, esse gráfico informa se a equipe está aproximadamente dentro do

prazo, servindo como um sinal de alarme para o projeto. Através da leitura do Burndown,
decide-se adicionar novas tarefas na Sprint, se a velocidade da equipe estiver acima do
planejado, o que vai melhorar sua produtividade ou retirar tarefas, caso a velocidade
esteja a seguir do previsto, pois a meta da Sprint estará comprometida se a redução de
tarefas não aconteça. Segue-se a análise de três gráficos de projeto que se encontram
em situações diferentes.
Na figura 3,5, podemos perceber a linha real do andamento do projeto com muitos
pontos estimados, mas poucos pontos realizados ao longo dos dias, com relação àqueles
estimados inicialmente para a Sprint. Recomenda-se nesse caso a remoção de funciona-
lidades do Sprint Backlog, diminuindo o escopo da Sprint.
250
200
150
Pontos
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Figura 3.5
Dias
Gráfico de
Burndown Estimado
para Sprint Realizado
Superestimada.
55
Se, em caso contrário, a linha real do andamento do projeto estiver muito acima da linha q
estimada, deve-se aumentar o escopo da Sprint. A seguir, na figura 3.6, segue um exemplo
de projeto para a gestão de uma imobiliária em que o projeto foi sendo realizado antes do
estimado – ou seja, muitos pontos foram sendo desenvolvidos antes do tempo pré-deter-
minado. Nesse caso, é possível aumentar o escopo.
160
140
120
100
80
Pontos
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Figura 3.6
Dias Gráfico de
Burndown
Estimado
para Sprint
Realizado Subestimada.
O ideal em situações assim é retirar tarefas de alta prioridade da próxima Sprint. Caso a q
meta da próxima Sprint seja muito baixa, podemos até mesmo optar pelo cancelamento
da Sprint, juntando as tarefas restantes a Sprint seguinte.
Finalmente, na figura 3.7, podemos ver um projeto para gestão de construtora sendo
realizado mais ou menos conforme estimado – ou seja, muitos pontos estão sendo
desenvolvidos no tempo determinado. Esse é um exemplo de um projeto ideal.
160
140
120
100
80
Pontos
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Dias Figura 3.7

Estimado Gráfico de
Burndown para
Realizado Sprint Ideal.
56
Task Board
Consiste em um grande painel, que possibilita colocar as diversas informações rele- q
vantes para o acompanhamento da Sprint, tais como o Product Backlog, e as atividades
da Sprint juntamente com o seu status (“Pendente”, “Em desenvolvimento”, “A verificar”
e “Concluída”). A ideia do Task Board é tornar essas informações sempre visíveis para
todos os interessados no desenvolvimento do projeto. Geralmente, o painel é dese-
nhado e colocado em uma parede, e as atividades são descritas em cartões de post-its,
como na figura 3.8:
Sprint Backlog Em Execução Concluído BurnDown
Cadastro de
categorias de
apartamentos
Cadastro de
apartamentos
Problemas
no servidor
de teste
SCRUM Master
Figura 3.8 Cadastro de deverá resolver
Task Board com clientes (remover) este
Impedimento. impedimento
Release
Como não é criado um Product Backlog para cada produto, Scrum recomenda a criação q
de um plano de Release, que divide os itens do Product Backlog em Sprints. Cada Sprint
gera um “entregável”, que são funcionalidades desenvolvidas naquela Sprint. Conforme
pode ser visualizado na figura 3.9, a junção dos entregáveis de algumas Sprints gera um
release – ou seja, uma Sprint é parte de um release.
O release se trata de um produto pronto para ser testado e utilizado pelo usuário. Os
entregáveis de cada Sprint não são liberados para os usuários conforme são concluídos,
mas são liberados quando a junção de cada entrega forma um produto que faça sentido
e adicione valor para o cliente.
Conforme é possível visualizar na figura 3.9-, as funcionalidades “Manter Caixa” e

“Manter Pick List” foram desenvolvidas na Sprint 1 e geraram a entrega 1. Essa entrega
é enviada à equipe de teste que realizará testes de integração apenas entre essas duas
funcionalidades. Durante a Sprint, estas também foram testadas unitariamente.
57
Sprint #1
Manter Entrega 1
Manter Caixa Pick List
Sprint #2
Vincular Caixa Entrega 2

ao Pick List Painel de Rotas Releases
Sprint #3
Entrega 3
Cancelar Vínculo
Figura 3.9
Funcionalidades,
Sprints, Entregas e
Produto Releases formando
o Produto.
O mesmo ocorre na Sprint 2 e na Sprint 3 com as funcionalidades “Vincular Caixa ao Picklist”,

“Painel de Rotas” e “Cancelar Vínculo”. no final de cada entrega, gera-se as entregas.3.4
Atividades práticas
Cenários para realização de uma Planning, incluindo: análise de backlog, análise de user
stories, quebra de stories em atividades, scrum poker e finalização da Sprint.
Dividir os estudantes em equipes de 2 a 3 pessoas para eles planejarem uma Sprint.

58
4
Scrum e a organização
objetivos
Entender como Ciclo PDCA e Scrum se complementam; Dicas gerenciais para Scrum;
Scrum e Governança
conceitos
Ciclo PDCA; Equipes distribuídas; Recursos humanos, instalações e PMO
Scrum e o ciclo PDCA

Cada Sprint é um bloco de iteração que segue um ciclo PDCA e entrega um incremento de q
funcionalidades prontas para serem incorporadas ao software. Um ciclo PDCA, também
conhecido como o círculo de Deming, é um método de gerenciamento iterativo de quatro
passos usado em gestão para o controle e melhoria contínua de processos e produtos.
Plan Do
(Planejar) (Fazer)
Act Check
(Agir) (Checar)
Figura 4.1
Ciclo PDCA.
q
Capítulo 4 - Scrum e a organização
Em resumo, o ciclo tem quatro fases, que significam passos no processo de adminis-
tração. Quando aplicadas ao Scrum, elas podem ser perfeitamente correlacionadas às
ações de uma Sprint, conforme analogia a seguir:
11 Plan: essa é a primeira fase do processo. Durante essa etapa, a equipe discute os obje-
tivos, o processo e as condições claras de finalização da Sprint (condições de aceitação).
Essa etapa define os objetivos mensuráveis e realizáveis para a equipe;
11 Do: a equipe trabalha em conjunto para atingir o objetivo fixado na fase de planeja-
mento. A equipe trabalha com o conjunto de processos acordados;
59
11 Check: uma vez que a entrega foi realizada, a equipe se reúne e verifica a saída, q
comparando-a com as condições acordadas de aceitação, decididas durante a fase de
planejamento. Os desvios, se existirem, são anotados. É importante notar que essa
verificação se dá não somente com relação ao produto entregue, mas também com
relação aos processos realizados;
11 Act: se qualquer desvio em tarefas planejadas foi observado durante a fase de veri-
ficação, a análise de causa raiz deve ser conduzida. Brainstorms juntamente com a
equipe serão realizados para identificação das alterações necessárias para evitar tais
desvios no futuro. A equipe também realiza brainstorms para entender mudanças
de ideias no processo, incluindo as mudanças de escopo e métricas de medição que
podem resultar em um melhor processo ou produto no próximo ciclo ou iteração.
Assim, qualquer pessoa com um conhecimento básico de Scrum pode correlacionar as

terminologias Scrum a essa abordagem científica.
11 Plan: planejamento da Sprint;
11 Do: Sprint engenharia real;
11 Check: Sprint Review;
11 Act: retrospectiva da Sprint.
O processo começa com um conjunto claro de metas e critérios de aceitação. Não pode
haver mal-entendidos, o que ajuda a minimizar o desperdício. O grupo sabe o que fazer
e ter orientação adequada para alcançá-lo. A verificação das tarefas planejadas também
acontece em relação aos critérios de aceitação conhecidos. O processo ajuda a equipe a
fazer pequenas mudanças, obter feedback e seguir em frente. A inspeção e adaptação ajuda
a equipe a crescer. O cliente final provavelmente encontra-se satisfeito, porque pode ver a
saída rapidamente e pode fazer as mudanças com base nas condições de mercado.
Escalando projetos com Scrum

Muitos projetos requerem mais esforço do que uma única equipe Scrum pode propor- q
cionar. Nessas circunstâncias, vários grupos podem ser empregados. Trabalhando em
paralelo, os esforços dessas equipes podem ser coordenados através de uma variedade
de mecanismos diferentes, que podem ser formais em alguns e mais aleatórios em
outros. Quando mais de uma equipe Scrum trabalha simultaneamente em um projeto,
esse projeto passa a ser referido como “projeto em escala”, e os mecanismos utilizados
para coordenar o trabalho dessas equipes são chamados “mecanismos de escala”.
Cada projeto escalado tem suas próprias complexidades, cada um dos quais normalmente
exige sua própria solução única e individual. Scrum escala do mesmo modo como qualquer
outro processo de desenvolvimento, utilizando praticamente os mesmos mecanismos de
escala, mantendo todas as práticas empíricas que formam o seu núcleo.
O núcleo em torno do qual a escala ocorre é a equipe Scrum. Um projeto com 800 q
pessoas será composto por 100 equipes de 8 pessoas, então a dificuldade encontra-se
em examinar como coordenar o trabalho dessas equipes, mantendo a produtividade de

cada equipe Scrum individual. Também é importante examinar como dimensionar projetos,
independentemente do número de pessoas que envolvem, bem como o tipo de aplicação,
o tipo de sistema, o número de lugares em que o desenvolvimento precisa ocorrer e outras
dimensões de escala relevantes.
60
Infraestrutura
Antes de escalar qualquer projeto, uma infraestrutura adequada deve ser colocada em q
prática. Se um projeto vai empregar várias equipes co-instaladas, um mecanismo para
sincronizar com frequência o seu trabalho deve ser concebido e implementado. Além
disso, um produto mais detalhado e a arquitetura técnica devem ser construídos de modo
que o trabalho possa ser dividido entre as equipes. Se essas equipes estão distribuídas
geograficamente, tecnologia de compartilhamento de código-fonte, sincronizado constrói
e comunicações alternativas, tais como mensagens instantâneas, devem ser empregados.
l
Tudo o que suporta o esforço da escala deve ser concebido e implementado antes do esca-
lonamento do projeto; todo esse trabalho é feito em Sprints. Scrum exige que cada Sprint
Demonstrar funcionali-
dade de negócios produza um incremento de funcionalidade do produto potencialmente utilizável, e esse
permite a produção do requisito pode ser cumprido se meses são necessários para conceber e implementar uma
tipo de resultados que
infraestrutura para escalar o projeto.
o Product Owner e as
partes interessadas
Na verdade, embora menos funcionalidade de negócio seja criada durante as Sprints iniciais
tanto prezam desde o
início, e ajudam o seu nas quais a infraestrutura será criada, ainda é necessário demonstrar algumas funcio-
engajamento e nalidades de negócios no final. Na verdade, é ainda mais importante fazê-lo, porque isso
envolvimento no
permite que a infraestrutura seja testada com o trabalho de desenvolvimento de funcionali-
projeto.
dade à medida que a mesma evolui.
Os requisitos não funcionais para construir a infraestrutura de escala são uma priori- q
dade elevada no Product Backlog, porque devem ser concluídos antes de escala em si.
Como a funcionalidade de negócios deve ser demonstrada no final de cada Sprint, esses
requisitos não funcionais são misturados com a funcionalidade de negócios de mais alta
prioridade. Se um pedaço de funcionalidade de negócios depende de um requisito não
funcional, o requisito não funcional deve ser priorizado no Product Backlog para ser
desenvolvido antes ou em paralelo com a funcionalidade de negócios.
Staging
O processo de definição e priorização dos requisitos não funcionais para escala é chamado q
de Staging. Staging ocorre antes do início do primeiro Sprint e leva apenas um dia, durante
o qual os requisitos de escala para o projeto são determinados e colocados no Product
Backlog. Por exemplo, se você está escalando o projeto para usar várias equipes, os
seguintes requisitos não funcionais devem ser adicionados ao backlog do produto:
11 Decompor a arquitetura de negócios para suportar o desenvolvimento de interfaces

de várias equipes;
11 Decompor a arquitetura de sistemas para suportar o desenvolvimento de interfaces

de várias equipes;
11 Se necessário, definir e implementar um ambiente para suportar diversas equipes

alocadas em ambientes distribuídos.
Após esses requisitos não funcionais para dimensionamento serem colocados no Product
Backlog, as Sprints podem começar. No entanto, apenas uma equipe pode iniciar seus traba-
lhos até a infraestrutura de escala estar no lugar, como não é claro haverá mecanismo para
coordenar o trabalho de várias equipes no mesmo período.
Veja a figura 4.2 para uma representação do Product Backlog inicial com todos os requi- q
sitos não funcionais adequados para o tipo de Staging imaginado.
61
Equipe única Figura 4.2
Sprints de Escala.
Backlog do produto inicial
Requisitos funcionais
Requisitos não funcionais
Staged scalability requirements
The rest of the functional and
non-functional requirements
Várias equipes
Backlog do produto
Requisitos funcionais
Requisitos não funcionais
O Product Owner e a equipe devem ficar juntos em uma reunião de planejamento da q

Sprint e colaboram para selecionar uma combinação de requisitos funcionais e não fun-
cionais. A equipe então inicia Sprints e iteram tantas vezes quanto necessário, até que
a infraestrutura para a encenação esteja no lugar. Nesse ponto, as reuniões de plane-
jamento das Sprints para cada uma das várias equipes de Sprint podem ser realizadas.
Cada nova equipe é semeada com um membro da equipe original, que serve como
especialista da nova equipe em infraestrutura e arquitetura do projeto.
Equipes distribuídas
Há alguns anos, as equipes co-instaladas eram a norma: se tornou difícil encontrar uma q
equipe distribuída geograficamente. Agora, o inverso parece ser verdadeiro: é uma sur-
presa quando uma organização tem toda a equipe trabalhando no mesmo edifício. Com
a prevalência de equipes espalhadas por todo o mundo, ou pelo menos através de fusos
horários distintos, é importante considerar quão bem Scrum funciona quando uma
equipe está geograficamente distribuída.
Um equívoco comum é que Scrum não é uma boa metodologia para uma equipe geogra-
ficamente dispersa. O argumento do Scrum pela preferência por uma comunicação face
a face faz com que muitos pensem que escolher equipes distribuídas seja má escolha.
Felizmente, esse argumento é falso. Embora seja verdade que uma equipe local sempre
vai superar a equipe distribuída equivalente (Ramasubbu e Balan 2007), Scrum pode
realmente ajudar as equipes geograficamente distribuídas.
62
Existem algumas regras do Scrum para equipes distribuídas que veremos a seguir, e q
dizem respeito basicamente à forma com que as cerimônias devem acontecer e como
a equipe deve ser disposta. A razão para isso é que uma diferença de fuso horário
tem muito impacto sobre a forma como uma equipe trabalha. Na verdade, possui um
impacto muito maior do que a distância geográfica em si.
Reunião de planejamento da Sprint

Existem basicamente duas abordagens que podem ser utilizadas para o planejamento q
da Sprint. As estratégias podem ser referenciadas pelos seus nomes descritivos: a tele-
conferência longa e duas teleconferências. A seguir, analisamos as vantagens e desvan-
tagens de cada uma dessas abordagens.
Teleconferência longa
É a abordagem padrão seguida pela maioria das equipes, e consiste em ligar para um q
número de teleconferência e conduzir a reunião de planejamento normalmente,
simulando o formato de reunião pessoal. Todo o trabalho de uma reunião de planeja-
Tabela 4.1
A teleconferência mento de Sprint regular é realizado nessa reunião. Quando ela se encerra, a Sprint deve
longa. estar completamente planejada como se a equipe fosse local.
Vantagens Desvantagens
Pode levar a boas discussões se todos se Participantes podem se distrair em uma ligação tão longa
mantiverem engajados
O planejamento da Sprint pode se encerrar Só funciona quando há muitas horas em comuns no dia de
em um dia trabalho na equipe geograficamente dispersa
É consistente com a abordagem utiliza em Pode significar estender o dia de trabalho em uma ou mais
equipes co-localizadas localidades
Duas teleconferências
Para algumas equipes, é simplesmente impraticável planejar a reunião de planejamento q
da Sprint em uma teleconferência: a separação de fusos horários é muito grande para
proporcionar sobreposição suficiente nos dias de trabalho. A próxima abordagem de pla-
nejamento do Sprint, duas chamadas, divide a reunião através de dois telefonemas reali-
zados em dias consecutivos. Substituir a sessão inicial de oito horas por duas sessões de
quatro horas separadas, realizadas em dias consecutivos, é mais prático.
Normalmente, a primeira sessão se concentra em identificar as principais tarefas, resul-

tados e dependências de alto nível. Ela tem como foco discutir as expectativas e prioridades
Tabela 4.2 mais altas do Product Owner. Durante a segunda sessão, cada membro da equipe define as
Duas atividades e fornece estimativas para cada tarefa que ele aceite. Seu foco é sincronizar os
teleconferências. compromissos de cada equipe individual com os quais pode se comprometer.
Pode ser uma forma mais eficiente de se Esse senso de utilidade pode variar grandemente,
usar o tempo dependendo de como a equipe está distribuída
Pode ser usada mesmo quando há Como muitas discussões acontecem entre as equipes, nem
poucas horas em comum nos dias de todo o conhecimento é compartilhado com a equipe global,
trabalho na equipe o que pode levar a mal-entendidos
Não se completa em um dia.
63
Daily Scrum
A Scrum diária introduz um conjunto de novos desafios em relação à reunião de pla- q
nejamento da Sprint em equipes geograficamente dispersas. Como o Scrum diário é
uma reunião diária de 15 minutos, a sua realização não representa um problema para
equipes com dias de trabalho que se sobrepõem, mas são um problema, no entanto,
para equipes amplamente distribuídas sem sobreposição em horas de trabalho. Realizar
chamadas diárias em uma hora em que você normalmente não está trabalhando não é
sustentável a longo prazo. Existem basicamente três métodos que podem ser usados
para as Scrums diárias nessas situações: uma conferência única, reunião escrita e
reunião regional. Veremos as vantagens e desvantagens de cada uma delas a seguir.
Teleconferência única
Talvez a abordagem mais comum e aquela que é inicialmente tentada pela maioria das q
equipes é fazer com que todos os participantes da equipe entrem juntos em um único
telefonema. Para as equipes coincidindo em fusos horário uns dos outros, essa é uma
excelente abordagem. Infelizmente, a abordagem se deteriora rapidamente quando o
número de fusos horários aumenta. Eventualmente, as equipes mais amplamente
Tabela 4.3
distribuídas rapidamente entendem ser necessária uma estratégia diferente para as Teleconferência
suas Scrum diárias. única.
Similar à abordagem usada em equipes locais, Pode ser inconveniente para membros da
então nada novo precisa ser mudado equipe
Discussões envolvem toda a equipe Não é sustentável se as pessoas precisam rea-

lizar ligações fora de seus horários de trabalho
Todo mundo aprende todas as pendências, o que leva a

maior aprendizagem da equipe e um comprometimento de
uma abordagem compartilhada
Reunião escrita
Para minimizar o trabalho de horas de telefonemas para alguns locais, algumas equipes q
abandonam reuniões diárias completamente. No entanto, sem querer desistir do valor
da comunicação diária inteiramente, tais equipes normalmente substituem reuniões
diárias por uma versão escrita da reunião.
Os membros da equipe concordam em enviar um e-mail, atualizar uma página de wiki ou

fazer uma entrada em outra ferramenta de colaboração assíncrona em que fornecem as
mesmas informações que eles compartilhariam em um telefonema. Uma variação dessa
abordagem é a realização de uma chamada de telefone em um momento que seja conve-
niente para o maior número de membros da equipe, com outros membros da equipe “par-
ticipando” através da apresentação de um relatório escrito. Isso é particularmente comum
quando a maioria da equipe está localizada apenas com alguns membros remotos.
Normalmente, essa abordagem não é indicada como técnica primária, mas pode ser
usada para completar chamadas diárias, se a equipe decide que elas estão acontecendo
demasiadamente, estão prejudicando a equipe que está trabalhando fora da sua hora de
trabalho normal e, por isso, precisa reduzir a sua frequência.
64
Há características importantes de uma Scrum diária que são perdidas quando a q
chamada é transformada em uma atualização diária escrita. Por exemplo, o compro-
misso assumido parece mais forte quando um membro da equipe diz: “Eu vou fazer isso
hoje”, do que quando as mesmas palavras são escritas. Talvez isso seja porque a
Tabela 4.4 mensagem falada é um compromisso assumido na frente dos próprios colegas de
Reunião escrita. trabalho, enquanto a mensagem escrita é um compromisso feito em privado.
Sustentável a longo prazo Problemas não são discutidos e podem ficar “adormecidos”
por dias
Ajuda a resolver problemas de linguagem, Não há realmente garantias de que as atualizações escritas vão
incluindo sotaques ser lidas
Os membros da equipe tendem a se importar menos com as

responsabilidades que os outros assumiram no dia anterior
Reuniões regionais
A terceira e última abordagem para a reunião de Scrum diária é ter um conjunto de reu- q
niões regionais seguidas por algum esforço para compartilhar a questões-chave de cada
uma dessas reuniões. Se uma equipe é dividida em duas cidades muito distantes, por
exemplo, cada cidade pode ter sua própria reunião diária.
Esse seria o caso, por exemplo, para uma equipe com membros em escritórios da
empresa em São Francisco, nos EUA, e Londres, na Inglaterra, que possuem intervalos
de horas de diferença.
Às vezes, uma equipe distribuída tem alguns escritórios com sobreposição de horas de
trabalho, além de um escritório mais remoto – nesses casos, os locais com horários sobre-
postos podem ter um Scrum diário, já a localização mais remota teria sua própria reunião.
As reuniões regionais, se todo mundo está presente em um escritório, ou de discagem em
uma chamada entre as diversas cidades, são, então, geralmente seguidas por uma comuni-
cação adicional, de modo que cada equipe está consciente do trabalho das outras equipes.
Tabela 4.5 Uma maneira de realizar essa comunicação é um telefonema com pelo menos um q
Reuniões regionais. representante de cada equipe.
Reduz grandemente o estresse de trabalho Informação de uma reunião para outra pode estar incorreta
em horas extras ou incompleta, nem compartilhada na hora necessária
Permite o compartilhamento de informação Pode levar para um sentimento de “nós” e “eles” entre
chave em equipes locais equipes diferentes
Nem todos se encontram presentes para todas

as discussões
65
Szcrum of Scrums
O Scrum dos Scrums é usado por várias equipes para coordenar seu trabalho. Envolve q
um representante de cada equipe, e acontece geralmente duas ou três vezes por
semana. A frequência reduzida dessa reunião a torna menos problemática para uma
equipe distribuída. Essa reunião dura quase sempre uma hora ou menos; portanto, uma
equipe distribuída com qualquer sobreposição de horas em sua jornada de trabalho será
capaz de facilmente programá-la.
Os desafios surgem, naturalmente, quando a equipe é tão amplamente distribuída que se

torna impossível compartilhar horários de trabalho comuns. Nesses casos, recomenda-se
que as equipes usem uma das estratégias anteriores para o Scrum, como chamada única
diária ou reuniões regionais. Quando um número reduzido de equipes está envolvido, uma
única reunião geralmente é suficiente, já que os participantes da reunião podem encontrar
algum tempo que será minimamente inconveniente para pessoas suficientes.
Isso é mais fácil de fazer do que é para o Scrum diário por duas razões: primeiro, a q
maioria dos Scrum dos Scrums não são diárias e, em segundo lugar, a maioria das
equipes, ocasionalmente, mudam quem participa dessas reuniões.
Sprint reviews e retrospectivas

Revisões de Sprint e retrospectivas compartilham características tanto das Scrums q
diárias quanto das reuniões de planejamento da Sprint. Assim como reuniões de plane-
jamento de Sprint, essas reuniões não são realizadas diariamente, então membros da
equipe se sentem mais disponíveis para participar fora do horário normal de trabalho.
No entanto, assim como as daily Scrums, revisões de Sprint e retrospectivas são um pouco l
mais fáceis de planejar, porque elas são mais curtas do que uma reunião de planejamento do Se tanto a revisão e a
Sprint. Isso faz com que a tarefa de encontrar um momento certo adequado para a reunião retrospectiva foram
curtas, alguns membros
seja relativamente fácil, já que equipes com sobreposição de horas de trabalho agendam essas da equipe podem
reuniões durante a parte sobreposta de seus horários. Equipes cujas horas de trabalho quase preferir agendá-las uma
logo após a outra.
se sobrepõem normalmente agendarão essas reuniões no final de um dia de trabalho para
Outras equipes podem
uns e no início para outros. preferir agendá-las um
dia logo após o outro.
Dicas gerenciais
Alguns pontos finais a considerar em equipes virtualmente discretas são os que seguem: q
11 Decida como distribuir as equipes: uma equipe colaborativa em uma localidade ou
equipes deliberadamente distribuídas;
11 Tente criar coerência;
11 Entenda as diferenças culturais significativas
11 Entenda as diferenças culturais pequenas;
11 Fortaleça as culturas funcionais e de equipe;

11 Comunique e estabeleça uma visão compartilhada;
11 Construa confiança ao enfatizar o progresso desde o começo do projeto;
11 Tente se reunir presencialmente;
11 Encoraje a comunicação lateral.
66
Coexistindo com outras abordagens
Uma coisa é olhar para o desenvolvimento ágil de software em um tubo de ensaio; outra q
é experimentá-lo no mundo real. No tubo de ensaio, metodologias ágeis como o Scrum
são facilmente adotadas por todos os membros, e as realidades da política corporativa,
economia, e não podem intrometer. No mundo real, contudo, todas essas questões
desagradáveis não existem. Raramente é simples tomar a decisão de utilizar Scrum e,
em seguida, ser capaz de fazê-lo sem outras restrições.
Por exemplo, um projeto pode tentar Scrum desde que isso não interfira na certificação
CMMI Nível 3 da organização. Outro projeto pode tentar experimentá-lo enquanto ele
está na revisão preliminar de arquitetura e, em seguida, tem uma reunião para aprovar
o design.
Pode haver razões válidas para uma organização para colocar essas restrições sobre os
projetos. Nesta sessão, estudaremos como um projeto Scrum é afetado quando se cruza
com um processo sequencial. A seguir, consideramos o impacto da governança do projeto
e como projetos Scrum podem coexistir com sucesso com abordagens de governança não
ágeis. Finalmente, vamos explorar maneiras projetos Scrum podem cumprir com normas
como a ISO 9001 ou CMMI.
Misturando Scrum e desenvolvimento sequencial

Poucas organizações de grande porte desfrutarão do luxo de fazer todos os seus pro- q
jetos com Scrum. A maioria será obrigada a suportar um período em que alguns projetos
foram transferidos para Scrum, enquanto outros ainda não. Isso pode ser porque seria
muito perturbador para a transição de toda a empresa de uma só vez, porque seria
perturbador para fazer uma mudança processo no meio do curso para um projeto parti-
cular, ou qualquer número de outras razões.
São basicamente três os cenários onde essa mistura pode acontecer:
11 Sequencial a princípio: a confluência de Scrum e desenvolvimento sequencial no

início do projeto geralmente ocorrem quando uma organização tem obstáculos de
aprovação do projeto. Livrar-se desses obstáculos requer geralmente que a equipe
Scrum anule qualquer pendência em relação aos documentos e crie uma especifi-
cação, plano de projeto ou outro artefato que é necessário para aprovação. Depois
que um projeto em cascata for aprovado, ele é executado como um projeto normal
de Scrum;
11 Sequencial no final: quando as características de Scrum e sequenciais se encontram

no fim do projeto, geralmente dizem respeito às fases de teste. Às vezes, essa conflu-
ência ocorre porque a organização só abraçou o Scrum “tentativamente”, e deixou os
testadores ou a garantia de qualidade como um grupo separado que se engajou no
final para verificar e validar o produto. Outras vezes, a característica sequencial no

final ocorre quando há um link externo para um grupo de operações, por exemplo, se
exige que alguns testes ocorram no final com um grupo externo ao time. Tipicamente,
no final do projeto, a equipe tem se acostumado à sua nova forma ágil de trabalhar,
por isso continua a usar o máximo de Scrum quanto possível, mesmo no final. Em
outras palavras, a equipe continua a trabalhar em sprints, realizará reuniões de pla-
nejamento sprints, têm reuniões diárias, e assim por diante;
67
11 Sequencial no meio: a maneira mais complicada em que Scrum tem de interagir com q
o desenvolvimento sequencial é esta. Um exemplo comum disso é quando duas ou
mais equipes devem trabalhar juntas para criar um único produto e pelo menos uma
equipe delas está usando Scrum, e a outra está usando uma abordagem sequencial.
A coordenação do trabalho e a comunicação frequente são geralmente as principais
fontes de problemas quando essa disposição existe. A equipe sequencial prefere se
comunicar por meio de reuniões e documentos que bloqueiam a interface, enquanto
a equipe Scrum vai preferir deixar interfaces mais vagas e eleger uma comunicação
informal, com interfaces e compromissos definidos de forma progressiva. A equipe
Scrum que se encontra nessa situação geralmente acha útil atrair os gestores dos
projetos sequenciais para participar de reuniões de planejamento do Sprint e para as
reuniões diárias.
Governança
Uma das razões pelas quais muitas organizações adotam uma abordagem sequencial q
para o desenvolvimento de software é o encaixe natural entre uma sequência definida,
as fases de desenvolvimento e a necessidade de supervisão do projeto. O objetivo da
supervisão do projeto, comumente chamado de governança, é certificar-se de que um
projeto não vai se extraviar. Governança eficaz do projeto pode, por exemplo, identificar
um projeto que vai exceder seu orçamento, levando a conversas sobre se o projeto deve
ser cancelado.
Governança também pode identificar um produto que está à deriva muito longe de seus
objetivos originais, um projeto que está a se desviar de um padrão arquitetural ou qualquer
número de considerações de alto nível similares importantes para a organização.
A equipe de software pode encontrar portas ou pontos de verificação de governança em

uma variedade de situações:
11 Uma análise precoce de seus planos para o escopo, orçamento e cronograma;
11 A revisão de decisões de arquitetura e design;
11 Uma revisão quando o aplicativo está pronto para o sistema ou teste de aceitação
do cliente;
11 Uma revisão quando o produto pode ser entregue a uma organização de apoio;
e assim por diante.
Esses postos de controle muitas vezes podem causar estragos no desejo de uma equipe de
software de usar Scrum, pois eles não são adequados para o trabalho feito de forma iterativa.
O primeiro passo para conciliar a necessidade de governança do projeto e o desejo de q

usar Scrum é perceber que a governança do projeto e gerenciamento de projetos não
são a mesma coisa. Não é um problema separar a governança do projeto e a sua gestão.
Ao separá-los, na verdade estamos permitindo à equipe alcançar a capacidade de ter pontos

de controle de alto nível para fornecer a supervisão necessária, permitindo ainda a liber-
dade de gerir a si mesmo e ao projeto de forma ágil.
68
Passos para rodar o projeto Scrum com governança não ágil: q
1. Negocie e deixe claro quais são as expectativas desde o princípio.
2. Ajuste os seus relatórios às expectativas atuais.
3. Convide os membros do comitê de governança para o processo Scrum.
4. Nada convence como sucesso – quando obtiver sucesso, referencie o sucesso.
Conformidade a padrões
Nem todas as equipes ou mesmo departamentos de desenvolvimento de software têm q
o luxo de ter o controle completo sobre seu processo de desenvolvimento. Por exemplo,
clientes terceirizados durante o desenvolvimento do contrato muitas vezes requerem
que fornecedores sejam certificados CMMI Nível 5, o que requer que os desenvolvedores
de software sigam algumas das melhores práticas estabelecidas.
Além disso, alguns produtos de software são entregues em setores regulados e cumprem
com normas como a ISO 9001.
Nenhum desses padrões prescreve um ciclo de vida que é contraditório como o Scrum.
Como cumprir normas na organização raramente é opcional, equipes Scrum devem preo-
cupar-se com a melhor forma de cumpri-las, começando em alguns casos com a questão de
saber se isso vai ser possível com um processo Scrum. Nesta sessão, vamos estudar como
equipes de Scrum podem ficar em conformidade com ISO 9001 e CMMI, dois dos padrões
mais comuns com que Scrum precisa coexistir. A partir deles, podemos generalizar algumas
estratégias de enfrentamento em outras situações de conformidade.
ISO 9001
A Organização Internacional de Normalização (ISO) mantém o padrão 9001, que normal- q
mente é designado em sua inteireza como ISO 9001:2000 ou ISO 9001:2008, ambos os
quais indicam o ano de uma versão específica do padrão. A certificação ISO 9001 não se
destina a garantir que os produtos de uma organização atinjam um nível de qualidade
específico. Em vez disso, a certificação indica que a organização segue um conjunto de
práticas formais no desenvolvimento de seus produtos. Uma grande parte do esforço
em conformidade com a ISO 9001 é a criação de um sistema de gestão da qualidade, que
geralmente é um longo documento ou conjunto de páginas da web que descrevem as
práticas de qualidade seguidas pela organização.
Primavera Systems, desenvolvedora de sistemas de gerenciamento de projetos e portfólio,

criou o seu sistema de gestão da qualidade ao longo de um período de dez meses.
A empresa realizou 30 oficinas para documentar seus processos existentes, e cada
workshop incluiu uma representação multifuncional dos desenvolvedores. Primavera
já tinha experiência substancial com práticas ágeis no momento em que iniciou o seu
esforço ISO 9001.
Em tal ambiente, seria natural para os funcionários se preocuparem com a perda de agili-
dade com a introdução de ISO 9001. Bill McMichael, da Primavera, e Marc Lombardi, um
consultor com experiência em ISO 9001, trabalharam juntos por iniciativa e chegaram
à conclusão de que a documentação não diminuiu a sua agilidade. O mantra foi prover
apenas documentação suficiente e referências que fossem realmente úteis para ajudar
com a garantia do processo que já existisse.
69
CMMI
Desde que o primeiro projeto ágil surgiu do lodo primordial, as empresas têm se pergun- q
tado se as metodologias ágeis são compatíveis com o Capability Maturity do Instituto de
Engenharia de Software Model Integration (CMMI). Como medida de algumas maneiras
de quanto processo de uma organização tem (ou pelo menos como muito do que tem
sido definida), o CMMI e seu antecessor, o Capability Maturity Model Software (SW-
CMM), são muitas vezes vistos como formas de pesos pesados de desenvolvimento de
software e a antítese do desenvolvimento ágil.
A incorporação de Scrum em um 5 processo CMMI Nível mostra uma solução para um

problema comum com implementações do CMMI. Ao prosseguir com um nível CMMI
particular, muitas organizações se esquecem de que o objetivo final é melhorar a forma
como eles constroem software (e, presumivelmente, portanto, quais os produtos vão
entregar), em vez de tornar-se com focos em preencher deficiências supostas acordo
com a documentação CMMI sem a preocupação de saber se as mudanças vão melhorar
o processo ou os seus produtos. Esse problema pode ser eliminado quando as metas do
CMMI são combinadas com o “valor concentrado” na mentalidade inerente Scrum, de
entregas constantes. O Scrum garante que os processos estão implementados eficiente-
mente e o CMMI garante que todos os processos relevantes estão considerados.
Conseguindo conformidade
De maneira geral, conseguimos estabelecer que Scrum é compatível com ISO 9001 e q
CMMI, tanto teoricamente quanto empiricamente. Para tornar Scrum conforme a sua
organização, um passo a passo pode ser seguido:
1. Coloque esforço suficiente no Product Backlog.
2. Tente deixar o Product Backlog conforme padrões previamente existentes

na organização.
3. Considere o uso de checklists.
4. Automatize testes e a geração de builds.
5. Use uma ferramenta de gerenciamento de projetos ágeis.
6. Mova-se devagar, mas de forma estável.
7. Trabalhe com seu auditor no processo ao qual você deseja ficar conforme.
8. Traga ajuda externa, se necessário, como um Scrum Master.
Recursos humanos, instalações e o PMO

Para alcançar o sucesso a longo prazo com Scrum, as implicações de se tornar ágil q
devem ser transferidas para outras partes da organização. Quando isso não for feito,
gravidade organizacional – ou seja, as influências organizacionais que formaram a orga-
nização no formato em que ela estava antes do início da transição – se inicia. Transições
Scrum já foram interrompidas ou completamente paradas porque ignoraram o impacto
de se tornar ágeis em grupos de fora do desenvolvimento. Isso resulta em situações

como essas:
70
11 Recursos humanos: equipes Scrum começam a fazer muito bem até que chega o q
tempo de revisão anual. De repente, todo mundo percebe que eles serão novamente
avaliados e a receber aumentos, com base exclusivamente no desempenho indivi-
dual. A revisão anual pode ter um campo para avaliar se um indivíduo se dá bem com
os outros, mas no final do dia contribuições e o heroísmo individual é o que é impor-
tante em termos de aumentos e promoções. É impossível pensar em adotar um pro-
cesso fundado sobre uma preferência por “indivíduos e interações sobre processos
e ferramentas” sem envolver o departamento de recursos humanos. Na organização
típica, esse grupo pode ter ainda mais influência sobre como as pessoas percebem
seus trabalhos e atuar neles do que os gerentes funcionais desses indivíduos;
11 Instalações: é muito mais fácil ser ágil quando toda a equipe está no mesmo local.
Mas quando um grupo de instalações torna tão tudo mais difícil, ou quando se
impede que as equipes Scrum usem o espaço da parede para os gráficos de manejo
e outros dados importantes do projeto, as equipes se tornam desmoralizadas.
Torna-se mais difícil manter o impulso de se tornar melhor em Scrum quando
parece que todo mundo está contra. O ambiente físico em que trabalhamos tem
uma influência direta sobre nós. Considere as mensagens conflitantes enviadas
quando uma empresa proclama “as pessoas são nosso maior patrimônio”, enquanto
o conjunto de instalações proíbe pendurar gráficos de burndown nas paredes. A
verdadeira mensagem é alta e clara:
“As paredes são um bem maior.”;
11 PMO: sem pensar em como seu projeto se refere a um PMO existente, uma equipe
Scrum inicia com uma atitude de “dane-se a papelada e processo”. Isso cria um
inimigo no PMO, um grupo que já estava inquieto sobre os experimentos iniciais
da organização com Scrum. O PMO responde convencendo gerência do departa-
mento que não tem problemas com Scrum, desde que ele seja complementado por
um conjunto de documentos e práticas. O PMO muitas vezes tem um enorme peso
político e experiência do projeto. Ao conseguir que essa parte da organização esteja
de acordo com Scrum, não só se evita uma possível fonte de resistência, mas também
se beneficia da sua experiência. Os membros do PMO podem se tornar guardiões de
auto-organização, melhoria contínua, propriedade, comunicação, experimentação,
colaboração e outros valores.
Quando Scrum é erroneamente encarado apenas como uma mudança dentro do grupo
de desenvolvimento, a gravidade organizacional criada pelos departamentos de fora da
TI pode puxar o grupo de desenvolvimento de volta para onde tudo começou. É possível
ignorar as implicações do Scrum sobre esses grupos e ser bem-sucedido, por algum
tempo. Eventualmente; porém, será necessário envolver com eles para criar uma tran-
sição bem-sucedida, a longo prazo.
É fácil ver os recursos humanos, instalações e do escritório de gerenciamento de projeto

como obstáculos a serem superados. Uma abordagem mais produtiva é ver cada um
como um aliado para ser inscrito. Embora uma relação conflituosa possa funcionar por um
tempo, o sucesso a longo prazo requer o apoio de toda a organização. O caminho para se
tornar ágil pode ser longo; quando for possível, é melhor fazer amigos, em vez de inimigos.
71
Atividades
Cada Sprint é um bloco de iteração que segue um ciclo PDCA e entrega um incremento de
funcionalidades prontas para serem incorporadas no software. Um ciclo PDCA, também
conhecido como o círculo de Deming, é um método de gerenciamento iterativo de quatro
passos usado em gestão para o controle e melhoria contínua de processos e produtos.
72
Rodrigo Alves Costa atualmente é
professor efetivo do curso de Ciências
da Computação da Universidade Esta-
dual da Paraíba e doutorando em Ciên-
cias da Computação na Universidade
Federal de Pernambuco (UFPE). Possui
mestrado em Ciências da Computação
pela UFPE (2010), MBA em Gerenciamento de Projetos pela
Fundação Getúlio Vargas (2007) e graduação em Ciências da
Computação pela UFPE (2005). É certificado Project Manage-
ment Professional (PMP) pelo Project Management Institute
(PMI) (2006). Tem vasta atuação profissional, destacando-se
em funções como executivo de projetos, analista de siste-
mas, engenheiro de sistemas, de segurança e de software
em empresas como IBM, Siemens, Motorola e C.E.S.A.R.
Também é autor de livros na área de administração organi-
zacional com foco em projetos, entre os quais Gerencia-
mento de Projetos de TI, e colaborador de cursos de gestão
empresarial em tecnologias da informação e comunicação
em diversas organizações e instituições de ensino, sendo
um dos idealizadores do currículo de governança da Rede
Nacional de Pesquisa, vinculado à ESR/RNP/CNPQ. Foi bol-
sista CNPQ durante o mestrado e a graduação (PIBIC), e atu-
almente está vinculado aos diretórios de pesquisa da
entidade, no grupo de estudos em Segurança Computacio-
nal da UFPE. Pesquisador na área de Ciência da Computa-
ção, com ênfase em segurança computacional e teoria da
computação, e na área de Gerenciamento de Projetos, com
ênfase em gerenciamento de projetos virtuais e planeja-
mento estratégico orientado por TIC. É membro entusiasta
do PMI, membro da Association for Computing Machinery
(ACM) e da Sociedade Brasileira de Computação (SBC).
O curso aborda os principais conceitos do Scrum, apre-
LIVRO DE APOIO AO CURSO
sentando aos alunos os fundamentos do gerenciamento

de projetos ágeis, as vantagens e desvantagens da utili-
zação desta metodologia de trabalho e como o processo
de transição para esta prática ocorre nas organizações.
-
dologia Scrum, compreendendo seus processos, papéis,
entregas acontecem.

Fundamentos de Scrum PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Fundamentos de Scrum PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Fundamentos

Rodrigo Alves Costa

Rodrigo Alves Costa

Rodrigo Alves Costa

Diretor de Serviços e Soluções

Escola Superior de Redes

Coordenador Acadêmico da Área de Governança de TI

Equipe ESR (em ordem alfabética)

Capa, projeto visual e diagramação

Por que se tornar ágil vale a pena? 3

Papéis, fluxo e artefatos do Scrum 9

Scrum e processos de desenvolvimento 14

Introduzindo um processo ágil em uma organização 16

Realizando a transição de um processo peso-pesado 16

Metodologias de desenvolvimento tradicionais:

Exercício de fixação – Que metodologias de desenvolvimento são utilizadas na sua organização?

Metodologias de Ágeis de Projetos 23

Software Funcional em vez de Documentação Detalhada 24

Colaboração ao cliente em vez de negociação de contratos 24

Indivíduos e iterações em vez de somente processos e ferramentas 25

Responder à mudanças x planos detalhados 25

Toyota, uma grande influência para o Scrum 27

Exercício de fixação – Como eliminar a restrição tripla na sua organização? 28

Atividades práticas – Cenários para levantamento de requisitos 33

Reuniões diárias de Scrum (Daily) 40

Escalando projetos com Scrum 60

Reunião de planejamento da Sprint 63

Sprint reviews e retrospectivas 66

Coexistindo com outras abordagens 67

Misturando Scrum e desenvolvimento sequencial 67

Recursos humanos, instalações e o PMO 70

A importância da informação e a crise do software

Assim, a informação é o canal que dá acesso ao conhecimento e que contribui para a q

Os administradores precisam analisar como um ambiente estrategicamente alimentado em

Nesse contexto, independente da fonte, o valor ou a validade da informação, as orga- q

nizações necessitam de meios de armazenamento das informações relevantes e o

Na verdade, a era do acesso a repositórios online já chegou. Os usuários conectados à

Como o compartilhamento e a distribuição do conhecimento organizacional é condição

É necessário utilizar, produzir e adquirir ferramentas de software para gerenciar bases q

O termo “crise do software” foi cunhado pelos participantes na Conferência de Engenharia

11 Projetos em execução que estouram o orçamento;

11 Projetos que atrasam;

11 Software que, depois de entregue, se mostrou muito ineficiente;

11 Software de pouca qualidade;

11 Software que, muitas vezes, não atendeu aos requisitos;

11 Projetos se mostraram incontroláveis com um código difícil de manter;

11 Software nunca foi entregue.

Por que se tornar ágil vale a pena?

11 Liberou 94% mais funcionalidades;

11 Entregou 38% mais funções por desenvolvedor;

As melhores práticas são arriscadas: como a maior parte de toda e qualquer

Aumento da produtividade e redução de custos

Infelizmente, não há medidas universalmente padronizadas para medição de produ-

Obviamente, nenhuma dessas formas de medir produtividade é perfeita, mas a utilidade de se

Categoria Melhoria Mais Melhoria Média Melhoria Mais

l 86% estavam “gostando” ou o “gostando muito” de trabalhar na empresa. Antes de adotar

Figura 1.2 Projetos

Melhoria na satisfação das partes interessadas

No estudo da VersionOne, 92% dos participantes consideraram que as metodologias q

O que as organizações têm feito não funciona

Product Sprint Incremento Figura 1.3

O esqueleto de processo funciona da seguinte maneira: no início de uma iteração, a

Papéis, fluxo e artefatos do Scrum