Fundamentos Do Scrum

Fundamentos
do Scrum
Rodrigo Alves Costa
A RNP Rede Nacional de Ensino

e Pesquisa qualificada como
uma Organizao Social (OS),
sendo ligada ao Ministrio da
Cincia, Tecnologia e Inovao
(MCTI)
responsvel
pelo
Programa Interministerial RNP,

que conta com a participao dos
ministrios da Educao (MEC), da
Sade (MS) e da Cultura (MinC).
Pioneira no acesso Internet no
Brasil, a RNP planeja e mantm a
rede Ip, a rede ptica nacional
acadmica de alto desempenho.
Com Pontos de Presena nas
27 unidades da federao, a rede
tem mais de 800 instituies
conectadas. So aproximadamente
3,5 milhes de usurios usufruindo
de uma infraestrutura de redes
avanadas para comunicao,
computao e experimentao,
que contribui para a integrao
entre o sistema de Cincia e
Tecnologia, Educao Superior,
Sade 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 Mller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho
Escola Superior de Redes

Coordenador Nacional
Leandro Marcos Oliveira Guimares

Edio
Lincoln da Mata
Coordenador Acadmico da rea de Governana de TI
Edson Kowask Bezerra
Equipe ESR (em ordem alfabtica)
Adriana Pierro, Alynne Figueiredo, Celia Maciel, Derlina Miranda, Elimria Barbosa,
Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato ,
Renato Duarte e Yve Marcial.
Capa, projeto visual e diagramao
Tecnodesign
Verso
1.0.0
Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de
contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores no 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.
Sumrio
1. Introduo
A importncia da informao e a crise do software 1
Crise do software2
Por que se tornar gil vale a pena? 3
Exerccio de fixao Como voc entende que o Scrum pode melhorar a produtividade na
sua organizao?7
Processo Scrum8
Papis, fluxo e artefatos do Scrum9
Papis do Scrum9
Exerccio de fixao Na sua organizao, que papis atuais poderiam ocupar os papis do
Scrum em uma eventual transio para Scrum?9
Fluxo do Scrum9
Viso Scrum13
Transparncia14
Inspeo14
Adaptao14
Scrum e processos de desenvolvimento14
Exerccio de fixao O que voc acha que precisa mudar na mentalidade da sua organizao para adotar um processo de gesto de projetos gil como o Scrum?15
Introduzindo um processo gil em uma organizao 16
Desenvolvedores16
Realizando a transio de um processo peso-pesado16
Scrum Escalvel17
Atividades prticas Cenrio para escolha sobre um processo a ser adotado 18
iii
2. O Scrum
Fase de especificao19
Fase de projeto20
Fase de implementao20
Fase de teste20
Fase de manuteno21
Metodologias de desenvolvimento tradicionais:
vantagens e desvantagens21
Vantagens e desvantagens22
Exerccio de fixao Que metodologias de desenvolvimento so utilizadas na sua organizao?
Voc enxerga vantagens e desvantagens no seu uso? Quais?23
Metodologias de geis de Projetos23
Software Funcional em vez de Documentao Detalhada24
Colaborao ao cliente em vez de negociao de contratos24
Indivduos e iteraes em vez de somente processos e ferramentas25
Responder mudanas x planos detalhados25
Velocidade e qualidade26
Vantagens e desvantagens26
Exerccio de fixao Voc acredita que a sua organizao e os seus clientes se beneficiariam da adoo de uma metodologia como o Scrum?27
Histrico do Scrum27
Toyota, uma grande influncia para o Scrum27
Exerccio de fixao Como eliminar a restrio tripla na sua organizao?28
Exerccio de fixao Voc acredita ser possvel ter uma equipe auto-organizvel na sua
organizao? Qual o contexto para possibilitar tal auto-organizao?29
Origem do nome29
O processo31
Emprico31
Iterativo e incremental32
Fases do Scrum32
Tamanho de projetos33
Atividades prticas Cenrios para levantamento de requisitos33
3. A metodologia
Papis36
Product Owner36
Scrum Master36
Equipe de desenvolvimento37
Cerimnias38
iv
Reunio de planejamento da Sprint (Planning Meeting)38

Reunies dirias de Scrum (Daily)40
Artefatos43
Planning Poker45
Product Backlog51
Sprint Backlog53
Release Burndown54
Grfico de Burndown55
Task Board57
Release57
Atividades prticas58
4. Scrum e a organizao
Scrum e o ciclo PDCA59
Escalando projetos com Scrum60
Infraestrutura61
Staging61
Equipes distribudas62
Reunio de planejamento da Sprint63
Daily Scrum64
Szcrum of Scrums66
Sprint reviews e retrospectivas66
Dicas gerenciais66
Coexistindo com outras abordagens67
Misturando Scrum e desenvolvimento sequencial67
Governana68
Conformidade a padres69
Recursos humanos, instalaes e o PMO70
Atividades72
vi
1
Entender a crise do Software. Por que se tornar gil vale a pena? Introduo
ao processo scrum. Realizando a transio de um processo peso-pesado para um gil.
conceitos
Crise do Software. Processos geis e Motivao. Processos peso-pesado e transio
A importncia da informao e a crise do software

Existe nas organizaes uma constante sinergia de presses e foras que criam ameaas
e oportunidades para a expanso e retrao do seu negcio, e que alimenta o processo

de tomada de deciso.
por essa razo que gestores necessitam ter cautela nesse processo, bem como contar
com ferramentas que habilitem uma deciso que seja tomada estrategicamente, orientada
de maneira a no prejudicar a organizao, levando em considerao as oportunidades de
negcio e garantindo a prosperidade das empresas, e o prejuzo que pode incorrer caso
decises sejam tomadas incorretamente.
As organizaes hoje consideram a informao como o seu principal ativo atravs dela
que os gestores decidem os caminhos a serem traados. A informao tem o poder de dar
suporte e orientar decises de negcios.
Assim, a informao o canal que d acesso ao conhecimento e que contribui para a
mudana e o aperfeioamento, propiciando o conhecimento necessrio para a tomada

de deciso e execuo das aes.
Os administradores precisam analisar como um ambiente estrategicamente alimentado em
termos de informao pode afetar a posio competitiva de uma empresa no mercado.
Nesse contexto, independente da fonte, o valor ou a validade da informao, as organizaes necessitam de meios de armazenamento das informaes relevantes e o
realizam em seus repositrios e bancos de dados.
Na verdade, a era do acesso a repositrios online j chegou. Os usurios conectados
internet tm a possibilidade de acessar os mais variados tipos de informao.
Captulo 1 - Introduo
objetivos
Introduo
A existncia de um universo rico com uma quantidade imensa de informao tem deixado
pessoas e empresas um pouco perdidas, e o tomador de deciso pode, por vezes, ficar
confuso. Ter muita informao no significa que a empresa est bem informada.
nesse contexto que surge a cincia da gesto da informao que, para Siqueira
Marcelo Costa, autor do livro Gesto Estratgica da Informao, significa a ao

sistmica de procurar entender as necessidades informacionais de uma organizao e
disponibiliz-las para a soluo de problemas organizacionais, de forma estruturada
e clara, com conhecimento pleno de todos os procedimentos e processos da soluo
encontrada, garantindo assim que ele seja eficaz e repetvel.
Como se pode imaginar, ter a informao certa na hora certa e no uma tarefa fcil.
As informaes devem ser exatas, relevantes e estar disponveis em tempo hbil.
A gesto da informao, portanto, busca resolver o problema de buscar uma forma eficiente
de coletar e processar apenas as informaes essenciais e indispensveis, uma vez que
humanamente impossvel digerir a imensa quantidade de informaes colocadas disposio.
Como o compartilhamento e a distribuio do conhecimento organizacional condio
vital prvia para transformao de informaes e experincias organizacionais isoladas em
algo que a organizao possa utilizar, e sendo a informao um ativo, ou seja, um bem que
agrega valor empresa, necessrio fazer uso de recursos de Tecnologia da Informao (TI)
de maneira apropriada.
necessrio utilizar, produzir e adquirir ferramentas de software para gerenciar bases
de dados que cresam medida que a informao se transforma e se torna disponvel e

relevante organizacionalmente.
Crise do software
Paralelamente a essa necessidade pela produo de software relevante, que existe at os dias
de hoje, um termo acerca de sua produo foi firmado nos primeiros dias da cincia da computao e diz respeito dificuldade de escrever programas de computador realmente teis e
eficientes dentro do tempo necessrio para as partes interessadas: crise do software.
A crise do software se deu por causa das melhorias rpidas nas capacidades dos computadores, e levando em considerao as complexidades dos problemas que conseguiriam
resolver. Com o aumento da complexidade dos softwares, muitos problemas dessa
natureza surgiram porque os mtodos existentes no se mostraram suficientes.
O termo crise do software foi cunhado pelos participantes na Conferncia de Engenharia
de Software da OTAN, em 1968, em Garmisch, na Alemanha. A palestra de Edsger Dijkstra,
da ACM, de 1972, faz referncia a esse mesmo problema: "A principal causa da crise de
software que as mquinas tornaram-se vrias ordens de grandeza mais potentes! Para
coloc-lo muito claramente: enquanto no havia mquinas, a programao foi nenhum
problema em tudo; quando tivemos alguns computadores fracos, a programao tornou-se
Fundamentos do Scrum
um problema leve, e agora temos computadores gigantescos, a programao tornou-se um
problema igualmente gigantesco.
As causas da crise do software esto ligadas complexidade geral do hardware e o pro-
cesso de desenvolvimento de software. A crise manifesta-se de vrias maneiras:

11 Projetos em execuo que estouram o oramento;
11 Projetos que atrasam;
11 Software que, depois de entregue, se mostrou muito ineficiente;
11 Software de pouca qualidade;
11 Software que, muitas vezes, no atendeu aos requisitos;
11 Projetos se mostraram incontrolveis com um cdigo difcil de manter;
11 Software nunca foi entregue.
A ideia principal por trs da crise que as melhorias no poder de computao sobrepujaram a capacidade dos programadores de utilizarem eficazmente esses recursos.
Vrios processos e metodologias foram desenvolvidos ao longo das ltimas dcadas
para melhorar a gesto da qualidade de software, tais como programao processual
e programao orientada a objetos. No entanto, projetos de software que so grandes,
complicados, mal especificados e que principalmente envolvem aspectos desconhecidos
ainda so vulnerveis a problemas grandes demais, imprevistos.
Por que se tornar gil vale a pena?

Em uma realidade de crise, equipes geis de sucesso tm produzido software de melhor
qualidade que atende s necessidades do usurio mais rapidamente e a um custo menor

do que as equipes tradicionais.
As organizaes que se tornam geis adotando um processo como o Scrum tm experimentado benefcios significativos, incluindo ganhos dramticos de produtividade com
diminuies correspondentes em custo. Elas so capazes de levar produtos ao mercado
muito mais rapidamente e com maior grau de satisfao do cliente, alm de experimentar maior visibilidade do processo de desenvolvimento, o que leva a maior previsibilidade de resultados.
Uma das primeiras organizaes a entender esses benefcios a adotar o Scrum foi a
Salesforce.com. Fundada em 1999 em um apartamento de San Francisco, a Salesforce.
com uma das histrias de sucesso duradouras da poca das pontocom. Em 2006, com
uma receita de mais de US$ 450 milhes e 2 mil funcionrios, a Salesforce.com notou que
a frequncia das suas releases tinha diminudo 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 transio para Scrum. Durante o primeiro ano de
mudana, a Salesforce.com:
11 Liberou 94% mais funcionalidades;
11 Entregou 38% mais funes por desenvolvedor;
Nos dois anos seguintes, a receita mais que dobrou, para mais de US$ 1 bilho. Com
resultados como esses, no surpreendente que tantas organizaes fizessem a transio para Scrum. Ou pelo menos tentassem.
A transio para Scrum e outros mtodos geis difcil: muito mais difcil do que muitas
empresas antecipam. As alteraes necessrias para colher todos os frutos que se tornar
gil pode trazer so de longo prazo. Tais mudanas exigem grande quantidade de esforo
11 E mais de 500% mais valor aos seus clientes em relao ao ano anterior.
no s por parte dos desenvolvedores, mas de toda a organizao. No se trata apenas de

3
uma mudana das prticas, necessrio mudar a mentalidade e a forma de trabalho estabelecida. O objetivo deste curso, portanto, no apenas mostrar como fazer essa transio
adequadamente, mas tambm como obter sucesso no longo prazo.
Toda mudana difcil. Mudanas maiores podem ser ainda mais difceis. No entanto,
existem ainda certas caractersticas de transio para Scrum que o tornam mais difcil
do que a maioria das outras mudanas.
Uma mudana, para ser considerada de sucesso, no depende exclusivamente de ser
de cima para baixo ou de baixo para cima (ou seja, h mltiplos fatores que determinam
o sucesso da mudana): em uma mudana top down (de cima para baixo), um lder
influente compartilha uma viso do futuro e a organizao segue o lder em direo a
essa viso.
Imagine um lder carismtico, respeitado e poderoso como Steve Jobs dizendo a seus
funcionrios da Apple que eles so se movendo para alm de hardware e software de
computador para dominar a msica digital. A sua reputao e estilo poderia ter apontado
a empresa em uma nova direo, mas isso por si s no teria sido suficiente para realizar
uma proeza to improvvel. Da mesma forma, sem compromisso operacional, as pessoas
resistem cadeia de comando. Assim, a participao bottom-up (de baixo para cima) ser
necessria, pois ser o indivduo, ou seja, os membros da equipe que trabalham com as
questes que vo descobrir como Scrum vai funcionar melhor dentro de sua organizao.
Assim, a chave para qualquer sucesso na adoo de Scrum ser a combinao elementos de
bottom-up e mudana top-down.
Criar esse plano exigiria saltar dois obstculos impossveis: em primeiro lugar, saber exatamente onde ns queremos acabar e, em segundo, saber exatamente os passos para chegar
l. Como no podemos superar essas impossibilidades, o melhor que se pode fazer adotar
uma abordagem de provocar e observar (Avery De, 2005), em que se pode tentar algo, ver
se ele nos move mais perto de um objetivo intermedirio, verificar se o estado melhorou e,
em caso afirmativo, fazer mais do mesmo. Esses processos da organizao no so aleatrios, so cuidadosamente selecionados com base na experincia, conhecimento e intuio,
para dirigir uma transio para o Scrum.
Apresentar a reviso de prontido operacional quase certamente vai impactar as finanas,
vendas ou outros departamentos. Portanto, cada um desses departamentos pode ser
afetado pela Scrum. Dessa maneira, grupos financeiros tero de conciliar as polticas da
empresa na capitalizao com a maneira de como projetos Scrum se comportam quando
esto em execuo. As vendas e o marketing podem querer alterar como comunicam os
seus prazos e o escopo, e podem mudar a forma como estruturam contratos. Com mais
l
O estado final
imprevisvel: uma
transio para Scrum
no pode ser tal que
articula e define o todo
o processo de mudana
necessria para
preencher a lacuna
entre como e ser e
cria planos tticos,
como em um de
gerenciamento de
mudanas tradicional,
segundo Carr, Duro, e
Trahant.
l
Scrum generalizada:
se tornar gil ter
implicaes para a
organizao que vo
muito alm do
departamento de
desenvolvimento de
software.
grupos afetados por uma mudana para o Scrum, h mais chance para aumentar a resistncia e certamente mais chance de problemas, o que pode tornar a transio para Scrum
ainda mais difcil.
Muitos testadores, por exemplo, aprendem ao longo dos anos que o seu trabalho testar
para conformidade com uma especificao de requisitos. Por sua vez, os programadores
foram treinados para analisar um problema em profundidade e para conceber uma soluo
perfeita antes que qualquer codificao comece. Em um projeto Scrum, testadores e programadores precisam desaprender esses comportamentos. Testadores passam a entender que
o teste tambm entender que o sistema precisa estar em conformidade com as necessidades do usurio. J os programadores entendem que um design nem sempre necessrio
(e s vezes nem mesmo desejvel) antes que a codificao comece.
l
Scrum dramaticamente diferente: as
mudanas criadas
atravs da adoo do
Scrum se permeiam ao
longo do desenvolvimento, e muitas dessas
mudanas vo de
encontro formao
passada da maior parte
dos funcionrios.
Como a transio para Scrum inclui pedir s pessoas para trabalhar de uma forma diferente
daquela que esto familiarizadas, ou seja, de uma forma que contradiz aquela da sua formao e experincia, os funcionrios muitas vezes se apresentam muitas vezes resistentes
mudana.
As melhores prticas so arriscadas: como a maior parte de toda e qualquer

mudana organizacional, depois que algum descobre a melhor maneira de fazer
alguma coisa, essa forma de fazer capturada e registrada como uma melhor
prtica, e compartilhada com todos os outros.
Para alguns tipos de trabalho, a coleta e reutilizao de melhores prticas uma tremenda
ajuda para o esforo de mudana. Por exemplo, uma organizao que est vendendo um
produto para um novo tipo de cliente pode capturar as melhores prticas para superar
objees por parte dos prospectos. Ao fazer a transio para Scrum, no entanto, a coleta
de melhores prticas pode ser arriscada, pois elas tentam fazer a equipe relaxar e parar o
esforo de melhoria contnua, que essencial ao Scrum.
Embora os membros da equipe devam sempre pesquisar para compartilhar uns com os
outros as suas recm-descobertas acerca das melhores formas de trabalhar, eles devem
resistir ao impulso de codific-las em um conjunto de melhores prticas.
Apesar de todas as razes pelas quais a transio para Scrum pode ser particularmente
difcil, partes interessadas nas organizaes que a realizaram tm o tempo para o mercado
de seus produtos reduzido e se mostram satisfeitos depois de implementar um processo
gil como Scrum.
Esse tempo de colocao no mercado mais rpido possibilitado pela maior produtividade
das equipes geis, o que por sua vez o resultado da maior qualidade de projetos nessa
disposio. Como os funcionrios podem realizar trabalhos de alta qualidade e como eles
passam a ver o seu trabalho entregue mais cedo nas mos dos usurios, a satisfao com o
trabalho sobe. Com maior satisfao dos funcionrios, nota-se maior envolvimento, o que
leva a ganhos de produtividade, iniciando um ciclo virtuoso de melhoria contnua.
Podemos listar as seguintes razes porque uma transio para um processo gil como
Scrum importante:
Aumento da produtividade e reduo de custos
Infelizmente, no h medidas universalmente padronizadas para medio de produtividade. Martin Fowler (2003) diz que medir a produtividade dos desenvolvedores de
software impossvel. No entanto, algumas equipes usam medidas como o nmero de
linhas de cdigo como uma entrada para a produtividade. Outros usam como o nmero
de pontos de funo, ou seja, pontos entregues ao cliente. Algumas equipes medem sua
produtividade por meio do nmero de caractersticas entregues, ignorando que nem
Obviamente, nenhuma dessas formas de medir produtividade perfeita, mas a utilidade de se

tentar medi-la encontra-se na aproximao do entendimento do que se quer gerenciar.
Nesse sentido, a QSMA calcula sua produtividade por meio de um sistema que considera
esforo, cronograma, dificuldade tcnica das atividades e alguns outros fatores em uma
tentativa de realizar comparaes entre equipes mais significativas.
todas as caractersticas so do mesmo tamanho.
Em sua comparao entre projetos tradicionais e geis, Mah (2008) entende que projetos
geis so 16% mais produtivos em qualquer situao. A figura 1.1 mostra a comparao de
projetos geis (pontos) comparado com a produtividade mdia de o desvio padro na base
de dados da QSMA.
Como se pode ver, a maioria dos pontos encontra-se acima da mdia da indstria, com
uma boa parte dos projetos mais de um desvio padro acima de um nvel de produtividade dessa mdia.
+/- 1 Desvio padro
Produtividade
Alto
Mdia
Figura 1.1
Equipes geis so
significativamente
mais produtivos
que a mdia da
indstria.
Projetos geis
Baixo
Maior
Menor
Tamanho do projeto
Os resultados da QSMA so 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 mtodos geis como o
Scrum. De acordo com a VersionOne, 73% acreditava que ser gil tinham significativamente
melhorado (23%) ou melhorado (50%) a produtividade.
Ora, razovel entender que, se os funcionrios em uma organizao so mais produtivos,
os custos sero menores. Embora encorajadores, esses nmeros contam apenas parte
da histria. Uma das crticas dos processos tradicionais que eles so to onerosos. Que,
muitas vezes, quando o software entregue, algumas funcionalidades ou o aplicativo
inteiro no so mais necessrias. Um benefcio significativo de ser gil que equipes geis
possuem a tendncia de produzir apenas funcionalidades necessrias. Graas ao feedback
constante e habilidade de priorizar novamente a cada Sprint, uma equipe Scrum capaz
de trabalhar apenas naquelas funcionalidades que os usurios realmente precisam. Se isso
for includo no nosso requisito de produtividade, provavelmente veramos resultados ainda
mais dramticos.
De acordo com o levantamento de Rico, com base em estudos de caso de equipes geis
publicados at 2016, mostrada na tabela 1.1, h um aumento mdio de produtividade de

88% e economias de 26% de custos quando se transiciona para gil. Esses indicam uma
evidncia slida de que equipes geis so mais produtivas, o que leva reduo de
custos para os seus projetos.
Categoria
Melhoria Mais
Baixa
Melhoria Mdia
Melhoria Mais
Alta
Produtividade
14%
88%
384%
Custo
10%
26%
70%
Tabela 1.1
Melhorias
verificadas com gil
por categoria.
Exerccio de fixao e
Como voc entende que o Scrum pode melhorar a produtividade na
sua organizao?
O envolvimento dos funcionrios melhora tambm a satisfao 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 aps a adoo do
Uma razo pela qual os

funcionrios podem
aproveitar mais os seus
trabalhos devido ao
ritmo sustentvel
promovido por
processos geis.
Scrum, a Salesforce.com realizou uma pesquisa junto a seus funcionrios e constatou que
86% estavam gostando ou o gostando muito de trabalhar na empresa. Antes de adotar
Scrum, apenas 40% respondiam a mesma coisa. Alm disso, 92% dos funcionrios disseram
que recomendariam uma abordagem gil para os outros. Resultados como esses so
comuns. Em seu levantamento na indstria, a VersionOne constatou que 74% dos entrevistados relataram que a moral foi melhorada (44%) ou significativamente melhorada (30%).
Time to Market mais rpido

Equipes geis tendem a lanar seus produtos mais rapidamente do que as equipes tradi-
cionais. De acordo com o estudo da VersionOne, 64% dos participantes relataram que o
tempo de comercializao 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 concluso de que os projetos geis
chegaram 37% mais rapidamente ao mercado, como mostrado na figura 1.2.
Alto
+/- 1 Desvio padro
Time to market
Mdia
Baixo
Menor
Maior
Tamanho do projeto
Melhoria na satisfao das partes interessadas

Tendo em conta todos os benefcios de processos geis at agora, no surpreendente
que eles conduzam a uma melhoria na satisfao das partes interessadas. A pesquisa da
DDJ descobriu que 78% dos participantes da pesquisa acreditam que o uso de um processo gil levou a uma melhoria um pouco maior (47%) ou muito mais elevada (31%)
na satisfao das partes interessadas.
Uma das razes pelas quais as partes interessadas ficam mais satisfeitas com processos geis
porque as suas prticas so mais amigveis com relao s mudanas de prioridades, o que
uma necessidade na vida das organizaes de ritmo acelerado e competitivo de hoje.
No estudo da VersionOne, 92% dos participantes consideraram que as metodologias
geis melhoraram a capacidade de gerenciar mudanas de prioridades.
Figura 1.2 Projetos

geis possuem
um time to Market
37% mais rpido
comparado com a
mdia da indstria.
Projetos geis
Alm disso, juntamente com a capacidade de mudar mais facilmente as prioridades, as

partes interessadas em projetos geis aprendem a gerenciar o impacto da mudana. Outras
razes incluem a melhoria na visibilidade dos projetos, a melhoria do alinhamento da TI e
objetivos de negcio, e a reduo de riscos de projeto.
O que as organizaes tm feito no funciona

Uma razo final para considerar a mudana para o Scrum se o seu processo de desenvolvimento atual no est mais funcionando. Quando um processo que at funcionou no
passado encontra muitas barreiras, uma tendncia 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 mudana: Inicialmente, o Yahoo! tentou Scrum puramente por
desespero. A abordagem sequencial claramente no estava funcionando, e fizemos uma tentativa de um ano para fazer a sequencial melhor atravs de um planejamento e uma anlise
mais aprofundada de documentos, mais sign-offs e, assim por diante, era tornar as coisas
piores, no melhores. Para as equipes que viram benefcios, que eram a maioria das equipes
que tentaram Scrum, os benefcios eram visveis quase que imediatamente.
Assim, ao adotar o Scrum, interessante identificar continuamente os benefcios
obtidos at determinado ponto, selecionar fatores de interesse da organizao e fazer

com que tais fatores sejam uma linha de base contra a qual se possa comparar mais
tarde uma boa dica qualidade, moral da equipe e satisfao das partes interessadas.
Processo Scrum
Todas as prticas do Scrum esto cravadas em um esqueleto de processo incremental.
lCrie cartes para

compartilhar com
outras equipes com os
seus resultados,
explicando por que vale
a pena mudar para o
Scrum, se mostrarem
interesse na transio.
Isso pode diminuir a
resistncia da
organizao como um
todo.
Esse esqueleto mostrado na figura 1.3. O crculo de baixo representa uma iterao de
atividades de desenvolvimento que ocorrem uma aps a outra, e a sada de cada uma
delas um incremento no produto. J o crculo superior representa uma espcie de
inspeo diria que ocorre durante a iterao citada anteriormente, durante a qual cada
membro da equipe se rene para acompanhar as atividades umas dos outros e realizar
adaptaes adequadas. O que guia as interaes so uma lista de requisitos e o ciclo se
repete enquanto houver oramento disponvel para o projeto.
Reunio de
Scrum Diria
24 h
2 4 semanas
Product
Backlog
Sprint
Backlog
Incremento
no Produto
O esqueleto de processo funciona da seguinte maneira: no incio de uma iterao, a

equipe analisa o que deve fazer. Em seguida, seleciona o que acredita que pode se transformar em um incremento potencialmente utilizvel de funcionalidade at no final de
um ciclo da iterao, que dura entre duas e quatro semanas. Cada ciclo desses conhecido como Sprint. A equipe ento 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 adaptaes oportunas para que o projeto possa ser feito.
Figura 1.3
O processo Scrum.
O corao de Scrum reside na iterao. A equipe lana um olhar sobre os requisitos, con-
sidera a tecnologia disponvel, e avalia as suas prprias 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 fazlo. Esse processo criativo o corao da produtividade Scrum.
Papis, fluxo e artefatos do Scrum

Papis do Scrum
Scrum possui trs papis: product Owner, Scrum Master e a equipe.
11 Product Owner: o Product Owner deve ser a pessoa com viso, autoridade e dispo-
nibilidade. O Product Owner responsvel por se comunicar continuamente com o

time de desenvolvimento sobre a viso do projeto e as prioridades.
Muitas vezes, difcil para os Product Owners atingir o ponto ideal de envolvimento. Como
Scrum valoriza auto-organizao entre equipes, um Product Owner deve lutar a necessidade de microgerenciar. Ao mesmo tempo, Product Owners devem estar disponveis para
responder questes da equipe;
11 Scrum Master: o Scrum Master age como um facilitador para o Product Owner e
para a equipe. O Scrum Master no 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 esto visveis ao Product Owner. O Scrum Master tambm 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-
civel. A equipe de desenvolvimento responsvel por se auto-organizar para

completar o trabalho. Uma equipe de desenvolvimento Scrum contm mais ou menos
sete membros completamente dedicados (oficialmente de 3 a 9), idealmente em uma
sala protegida de distraes externas.
Para projetos de software, uma equipe tpica inclui uma mistura de engenheiros de software, arquitetos, programadores, analistas, especialistas em qualidade, testadores e designers de interface grfica. A cada Sprint, a equipe responsvel por determinar como vai
conseguir finalizar o trabalho. A equipe possui a autonomia e responsabilidade para atingir
Exerccio de fixao e
Na sua organizao, que papis atuais poderiam ocupar os papis do Scrum
em uma eventual transio para Scrum?
Fluxo do Scrum
Um projeto Scrum comea com uma viso do sistema a ser desenvolvido. A viso pode
ser vaga no incio, talvez expressa em termos de mercado, em vez de requisitos de
sistema, mas ela se tornar mais clara medida que o projeto avana.
os objetivos da Sprint.
O Product Owner responsvel por garantir o financiamento do projeto e por entregar a

viso de uma forma que maximiza o retorno do investimento. O Product Owner tambm
formula um plano para faz-lo, que inclui um Product Backlog. O Product Backlog uma
lista de requisitos funcionais e no funcionais que, quando transformado em funcionalidade, vai entregar essa viso. O Product Backlog priorizado para que os itens com
maior probabilidade de gerar valor sejam prioridade e estejam divididos em lanamentos propostos.
O Product Backlog priorizado um ponto de partida, e os seus contedos, as prioridades, e agrupamento em releases geralmente muda no momento do incio do projeto,
como esperado. Mudanas no Product Backlog refletem mudanas nos requisitos de
negcios e quo rapidamente a equipe pode transformar esses requisitos em funcionalidade implementada.
Todo o trabalho feito em Sprints. Cada Sprint uma iterao de 30 ou 15 dias consecutivos e iniciada com uma reunio de planejamento, onde o proprietrio do produto
e equipe se juntam para colaborar sobre o que ser feito para a prxima 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 prxima Sprint. Reunies de planejamento
da Sprint no podem ser muito demoradas, no devendo durar mais do que oito horas,
evitando muita angstia sobre o que possvel. O objetivo comear a trabalhar, no
pensar em planejar o trabalho.
Todos os dias, a equipe se rene para uma reunio de 15 minutos chamada Daily Scrum.
O objetivo da reunio sincronizar o trabalho de todos os membros da equipe diariamente e agendar quaisquer reunies adicionais que a equipe necessite para transmitir o
seu progresso.
No final da Sprint, uma reunio de reviso da Sprint realizada. Essa uma reunio 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
reunio 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.
Aps a reviso da Sprint, e antes da prxima reunio de planejamento da Sprint, o
ScrumMaster realiza uma reunio retrospectiva da Sprint com a equipe. Nessa reunio,
o ScrumMaster encoraja a equipe a rever seu processo de desenvolvimento, no mbito
e prticas do processo Scrum, para torn-lo mais eficaz e agradvel para a prxima
Sprint. Juntos, a reunio de planejamento da Sprint, o Daily Scrum, a reviso Sprint e a
retrospectiva da Sprint constituem as prticas de inspeo e de adaptao empricos de
Scrum.
Na figura 1.4, podemos encontrar o processo Scrum estendido, incluindo as reunies
recm-citadas.
10
A cada
24 horas
Scrum dirio
Sprint
Nova funcionalidade
demonstrada ao nal
da Sprint
Backlog da Sprint
Selected Product Backlog
Backlog do Produto: Emergente,

requisitos priorizados
Viso: ROI esperado,
lanamentos, Millestore
Figura 1.4
Viso geral do
processo do Scrum.
Artefatos
Scrum introduz alguns novos artefatos. Estes so utilizados em todo o processo de
scrum e so descritos a seguir.
Product Backlog
Os requisitos para o sistema ou produto que est sendo desenvolvido pelo projeto esto
listados no Product Backlog. O Product Owner responsvel pelo contedo, priorizao

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 dinmico e a gesto
muda constantemente tal documento para identificar o que o produto necessita para
Tabela 1.2
Product Backlog.
que seja adequado, competitivo e til. Enquanto o produto existir, o Product Backlog
existe. Um exemplo pode ser encontrado na tabela 1.2:
Requisito
Num
Categoria
Status
Pri
Estimativa
Registrar requisitos na base de dados
17
funcionalidade
em curso
Processar cenrio de saque simples
232
caso de uso
em curso
60
Aprovao de crdito muito lento
12
problema
no iniciado
10
Clculo de comisso de venda
43
defeito
finalizado
Captura de venda em ponto de venda
321
melhoria
no iniciado
100
Processar cenrio de crdito PMT
45
caso de uso
em curso
30
Product Backlog
11
Sprint Backlog
O Sprint Backlog define o trabalho (ou as tarefas que uma equipe define para transformar os
itens do Product Backlog que ele escolheu para o Sprint), de maneira a transform-lo em um
incremento de funcionalidade do produto potencialmente utilizvel. Somente o time pode
mudar o Sprint Backlog. O Sprint Backlog deve ser altamente visvel, 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 nmero 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
Origem
Responsvel
Status
Descrio da
Atividade
Horas de trabalho restantes por dia
Rosa
Joo
em curso
Gerar documentao
do SDK
Pedro
no
iniciado
16
16
16
16
16
16
16
16
16
16
16
16
Disponibilizar
documentao na wiki
Joo
no
iniciado
LDAP: grupos
de suporte
Maria
finalizado
26
18
10
Documentao de
branch:
fontes e
builds
Pedro
no
Impedir
criao de
relaes
"erradas"
Maria
finalizado
20
12
Descrever
extenso
de PDA
Pedro
em curso
26
18
10
Release do
servio
12
10
11
12
iniciado
64
58
50
42
34
Incremento potencialmente utilizvel de funcionalidade de produto

Scrum exige que os times desenvolvam um incremento de funcionalidade do produto a
cada Sprint. Esse incremento deve ser potencialmente utilizvel, porque o Product
Owner pode optar por implementar a funcionalidade imediatamente.
Tabela 1.3
Sprint Backlog.
Isso requer que os incrementos precisem ser exaustivamente testados e bem estruturados,
que o cdigo seja construdo em um arquivo executvel e que a funcionalidade implementada para operao do usurio seja escrita em um cdigo bem documentado e disponibilizada em arquivos de ajuda ou em outra documentao de usurio acordada.
Viso Scrum
Scrum uma ferramenta para desenvolver e manter produtos complexos. A cincia do
Scrum est por trs do desenvolvimento de software complexo.

Obviamente tal fato no muito surpreendente, porque o universo cheio de complexidades. A maioria delas so desconhecidas para a maioria das pessoas. Algumas como
o processo atravs do qual a presso transforma carvo 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 impreciso.
No entanto, impossvel ignorar a complexidade no desenvolvimento de software. Seus
resultados so efmeros, consistindo apenas de sinais que controlam mquinas de estado.

O processo de desenvolvimento de software totalmente intelectual, e todos os seus
produtos intermedirios so representaes marginais dos pensamentos envolvidos.
Os materiais que usamos para criar o produto final so extremamente volteis: os requisitos
dos usurios para um programa que utilizaro no futuro, a interoperabilidade de sinais
entre outros programas com o aplicativo a ser desenvolvido e a interao dos organismos
mais complexos do planeta pessoas.
Dessa forma, Scrum se prope a ser visto como um quadro no qual as pessoas podem
resolver os problemas adaptativos complexos, ao mesmo tempo em que o realizam de

forma produtiva e fornecem, de maneira criativa, produtos de maior valor possvel. Scrum :
11 Leve (Lightweight);
11 Simples de entender;
11 Difcil de dominar.
Scrum uma estrutura de processo que tem sido utilizada para gerenciar o desenvolvimento
de produtos complexos desde o incio da dcada de 1990. Scrum no um processo ou
uma tcnica para a construo de produtos; ao contrrio, um quadro no qual voc pode
empregar vrios processos e tcnicas.
Scrum torna clara a eficcia relativa das suas prticas de gesto e desenvolvimento de produtos para que voc possa melhorar. O framework Scrum consiste em equipes Scrum e seus
papis associados, eventos, artefatos e regras. Cada componente no quadro serve a um
propsito especfico e essencial para o sucesso e uso do Scrum.
As regras do Scrum unir os eventos, papis e artefatos, que rege as relaes e interaes
entre eles. As regras de Scrum so descritas ao longo desse documento. Tticas especficas para o uso do framework Scrum variam. Scrum fundada na teoria de controle
de processos empricos: o empirismo. Essa teoria afirma que o conhecimento vem de
decises de experincia, preparando com base no que conhecido. Scrum emprega uma
abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.
So trs os pilares que sustentam qualquer implementao de controle de processos empricos: a transparncia, a inspeo e a adaptao.
Essa a definio
de um incremento
pronto.
13
Transparncia
Aspectos significativos do processo devem ser visveis para os responsveis pelo resul-
tado. A transparncia exige que esses aspectos sejam definidos por um padro 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 definio de Pronto.
Inspeo
Usurios de um projeto do Scrum devem frequentemente inspecionar artefatos pro-
duzidos pelo projeto e progredir em direo a uma meta de uma Sprint para detectar
variaes indesejveis. Obviamente, a inspeo no deve ser to frequente de maneira a
tornar a inspeo uma barreira ao trabalho.
As inspees so mais benficas quando a diligncia realizada por inspetores qualificados no trabalho.
Adaptao
Se um inspetor determina que um ou mais aspectos de um processo se desvia dos
limites aceitveis e que o produto resultante ser inaceitvel, o processo ou o material a

ser processado tem de ser ajustado. Um ajuste deve ser feito o mais rapidamente possvel para impedir desvios futuros.
Os eventos prescritos pelo Scrum para garantir inspeo e adaptao so:
11 Planejamento da Sprint;
11 Scrum diria;
11 Reviso da Sprint.
11 Retrospectiva da Sprint
Scrum e processos de desenvolvimento

A abordagem Scrum para o desenvolvimento de software gil marca uma sada radical
das abordagens tradicionais. Scrum e outros mtodos geis foram inspirados pelas deficincias daquelas abordagens, e enfatizam em colaborao, software funcional, autogesto de equipe e na flexibilidade a adaptar-se a necessidades emergentes de negcios.
Essas necessidades so as mais comumente verificadas em negcios de software, cujos
clientes normalmente no conhecem todos os requisitos de negcio no comeo do
projeto, e tm necessidades emergentes durante a sua execuo.
Scrum parte do movimento gil. Esse uma resposta falha da maioria dos paradigmas de gesto de projetos de desenvolvimento, e toma emprestado muitos princpios de lean manufacting. Em 2011, 17 pioneiros de mtodos similares se reuniram no
Resort Snow Bird Ski, em Utah, e escreveram o Manifesto gil, uma declarao de quatro
valores e doze princpios. Esses valores e princpios contradizem fundamentalmente as
reas de conhecimento tradicionais do PMBoK.
No entanto, o Manifesto gil no prov passos concretos. As organizaes normalmente
procuram mtodos mais especficos dentro do movimento gil. Estes incluem Crystal Clear,
14
Extreme Programming, Desenvolvimento Orientado a Funes, Scrum e outros. Tipicamente, uma soluo que possui definies simples como o Scrum habilita a equipe com a
autonomia necessria para realizar o melhor trabalho enquanto auxilia a alta gesto (cujos
membros podem se tornar Product Owner) a obter os resultados de negcio que desejam.
Scrum capaz de abrir portas para outras abordagens geis teis como desenvolvimento
orientado a testes. Uma organizao realmente gil dificilmente possui um lado tcnico e
um lado de negcios, mas possui equipes trabalhando diretamente que desejam entregar
valor de negcios. Ora, os melhores resultados de negcios so entregues quando o negcio
inteiro est envolvido no processo.
Os primeiros defensores do Scrum foram inspirados por ciclos de feedback de inspeo
e adaptao para se adaptar a complexidade e risco. Scrum enfatiza que o processo de
deciso deve ser baseado em resultados do mundo real, em vez de especulao. O tempo
deve ser dividido em cadncias pequenas de trabalho, conhecidas como Sprints, de uma
ou duas semanas. O produto mantido em um estado potencialmente entregvel (ou seja,
adequadamente integrado e testado) o tempo inteiro. No fim de cada Sprint, as partes interessadas e os membros de equipe se renem para uma demonstrao de uma melhoria do
produto e planejar seus prximos passos.
Dessa forma, podemos ver Scrum como um conjunto simples de papis, responsabilidades
e reunies que nunca mudam. Ao remover toda imprevisibilidade no necessria, possvel
se adaptar necessria imprevisibilidade da descoberta e aprendizagem tpica dos projetos.
Assim, as regras e prticas para Scrum um processo simples para gerenciar projetos
complexos so poucas, diretas e fceis de aprender. No entanto, a simplicidade do Scrum
em si e sua falta de prescrio podem ser to sensibilizantes que novos praticantes acabam
em situaes em que aos poucos revertem para velhos hbitos e ferramentas de gesto de
projetos, produzindo resultados menos satisfatrios.
Assim, para entender a base na teoria e prtica do Scrum, necessria uma mentalidade
que possibilite:
11 Controlar at mesmo os mais complexos projetos;
11 Gerir eficazmente os requisitos do produto desconhecidos ou mudana;
11 Simplificar a cadeia de comando com as equipes de desenvolvimento de autogesto;
11 Receber mais claras especificaes e feedback de clientes;
11 Reduzir grandemente o tempo de planejamento de projeto e ferramentas necessrias;
11 Construir e lanar produtos em ciclos de 30 dias para que os clientes obtenham resultados mais cedo;
11 Evitar erros inspecionando regularmente relatrios sobre os projetos e realizar ajuste
fino constantemente sobre estes;
11 Apoiar vrias equipes trabalhando em um projeto em larga escala a partir de muitas
11 Maximizar o retorno sobre o investimento.
Exerccio de fixao e
O que voc acha que precisa mudar na mentalidade da sua organizao para
adotar um processo de gesto de projetos gil como o Scrum?
localizaes geogrficas;
15
Introduzindo um processo gil em uma organizao

O Manifesto Agil estabelece uma base comum para esses processos: valorizar mais
os indivduos e as interaes que os processos e as ferramentas, trabalhar mais no

software do que no detalhamento da documentao, colaborar mais com o cliente na
negociao do contrato e responder mais rapidamente s mudanas do que seguir um
plano risca. As metodologias geis mais conhecidas so Extreme Programming (XP),
Lean Development, Crystal e Scrum.
Com o Scrum, os projetos progridem em uma srie de interaes mensais, denominadas
sprints. Antes de cada sprint, as equipes de desenvolvimento se renem com o cliente,
ou com o product owner, para priorizar o trabalho a ser realizado e selecionar as atividades que a equipe pode finalizar na prxima sprint. Durante a sprint, a equipe acompanhada atravs de reunies dirias (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 constantemente ou so desconhecidos no comeo do projeto e que possuam a tendncia de
surgir rapidamente, como projetos para web e para desenvolvimento de produtos em
novos mercados.
Desenvolvedores
A maioria dos desenvolvedores respondem introduo de um processo gil com uma
combinao de ceticismo, entusiasmo e otimismo cauteloso. Outros desenvolvedores,

no entanto, tendem a resistir mudana ou simplesmente iniciar o projeto sem premeditao. importante ressaltar que ambas as reaes podem causar problemas.
Em geral, processos geis valorizam mais a produo de cdigo do que processos orientados
a planejamento. Em um processo assim, os desenvolvedores tratam a UML e outros itens
que no so cdigo como artefatos de primeira classe. Em um processo gil, no entanto,
esses itens s existem para suportar a atividade de codificao.
Ao introduzir o Scrum em vrias equipes de projeto, normal encontrar programadores que
passam mais tempo produzindo artefatos que no so cdigo do que necessrio. Tambm
encontramos desenvolvedores que medem seu nvel de contribuio no projeto pelo
nmero de reunies de que participam. Esses analistas vo alm da paralisia da anlise
e ativamente buscam oportunidades para adicionar novas atividades no processo gil,
deixando-o mais complicado do que precisa ser.
Em tais situaes, o melhor no intervir. Outros membros da equipe avaliaro a efetividade e o valor dessas atividades, e no as adotaro se estas no ajudarem o esforo de
desenvolvimento geral da equipe.
Realizando a transio de um processo peso-pesado
16
Um nmero surpreendente de desenvolvedores enxerga o uso de um mtodo gil

como uma tentativa da gesto 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 perodos 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 dirio a norma na maioria dos processos geis.
Programadores que tm essa viso percebem as interaes com seus gerentes de projeto
como sendo sobre datas de entrega e prazos perdidos. Para impedir esse problema, os
lderes devem constantemente demonstrar seu desejo de remover obstculos assim que
possvel e evitar reclamar se uma atividade demorar mais do que o previsto. Gestores
podem se surpreender, mas no devem se mostrar excessivamente crticos ao serem informados de que uma tarefa vai demorar mais do que se pensava originalmente.
A transio gradual de um processo mais pesado para um processo gil pode tornar a
mudana mais fcil para a equipe de desenvolvimento. Algumas equipes, em seu primeiro contato com o Scrum, ficam estagnados com a falta de ao gerada pela liberdade
de no possuir um cronograma dirio direcionando seu trabalho. A ideia ajudar esses
times ao definir tipos de sprint:
11 Prototipao;
11 Captura de requisitos;
11 Anlise e design;
11 Implementao;
11 Estabilizao.
A cada reunio de planejamento, trabalha-se com as equipes para definir os artefatos
que vo resultar de cada tipo de Sprint. Ao usar tipos de Sprint, introduzimos um nvel de
formalidade suficiente para permitir que as equipes vejam mais claramente sua funo ao
longo do projeto. Na medida que os times se tornam mais familiarizados com a informalidade do processo gil, eles gradualmente abandonam o conceito de tipos de Sprint.
Scrum Escalvel
Quando muitas equipes trabalham no mesmo produto, eles normalmente usam um
mesmo Product Owner (que realmente toma decises de negcio) 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 interdependncias aparecem,
equipes de funcionalidade devem aprender a usar princpios da auto-organizao para
coordenar com outras equipes.
Infelizmente, a maioria dos times no esto inicialmente acostumados com esse nvel de
responsabilidade, e hbitos pr-existentes de gesto e hierarquias apresentam impedimentos organizacionais.
A ideia do Scrum eliminar papis de coordenao como gestor de projetos e PMO, pois
entende que eles interferem na auto-organizao da equipe. O Scrum tambm elimina

papis ditatoriais como arquitetos, pois entende que as decises tcnicas devem ser
tomadas por times colaborativos.
organizacional, tentador usar algumas abordagens hbridas que combinam uma verso
enfraquecida do Scrum ao mesmo tempo em que se utiliza uma gesto hierrquica tradicional. Recomenda-se que organizaes maiores que esto comprometidas com valores
e princpios do Manifesto gil aprendam sobre LeSS (Large Scale Scrum).
Enquanto um cenrio de agilidade tima requer mudanas fundamentais na estrutura
17
Atividades prticas e
Cenrio para escolha sobre um processo a ser adotado
Tutorial para uso de uma ferramenta Scrum (sugesto: Tuleap)
18
2
Metodologias tradicionais: vantagens e desvantagens. Filosofia por trs das
metodologias geis. Metodologias geis: caractersticas, vantagens e desvantagens.
conceitos
O Scrum. Metodologias de desenvolvimento de software. Filosofia do Scrum.
Processo de software
Em uma viso geral do processo/projeto de desenvolvimento de software, podemos
subdividi-lo em cinco fases genricas que independem da rea de aplicao, tamanho ou

complexidade do projeto:
11 Especificao;
11 Projeto;
11 Implementao;
11 Validao;
11 Manuteno.
Para cada uma delas, existe uma srie de atividades que so 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 especificao, comum se produzir 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 especificao
uma das etapas iniciais do projeto, pois onde procuram-se identificar funcionali-
dades, restries, validaes, interfaces e principalmente os requisitos-chave que o

projeto deve cobrir.
Deve haver interao com o cliente para validar todas as informaes por ele passadas e
com ele coletadas, a fim de que todos os requisitos sejam atendidos de maneira correta no
decorrer da implementao do produto.
Captulo 2 - O Scrum
objetivos
O Scrum
19
composta por trs atividades principais, que so executadas, independentemente dos
mtodos utilizados, porm podem variar de acordo com o paradigma usado. As suas
tarefas so:
11 Engenharia de sistema: estabelecimento de uma soluo geral para o problema,
envolvendo questes de tecnologia e equipamento;
11 Anlise de requisitos: levantamento das necessidades do software a ser implementado
tem como objetivo produzir uma especificao de requisitos em forma de documento;
11 Especificao de sistema: descrio funcional do sistema. Pode incluir um plano de
testes para verificar adequao.
Fase de projeto
O projeto finalizado quando seus objetivos propostos so alcanados e quando se
encontra estruturado, em termos de arquitetura, interface e tcnicas. Suas atividades so:

11 Projeto arquitetural: aqui se desenvolve um modelo conceitual para o sistema, composto por mdulos mais ou menos independentes;
11 Projeto de interface: onde cada mdulo tem sua interface de comunicao estudada e
definida. Pode resultar em um prottipo;
11 Projeto detalhado: onde os mdulos em si so definidos e, possivelmente, traduzidos
para pseudocdigo.
Fase de implementao
Tambm chamada de fase de desenvolvimento ou codificao. a fase que define como
os dados sero estruturados e implementados tecnicamente. Em outras palavras,

quando o projeto, que antes estava documentado em papel, passa a ser transformado
para entrar em operao de fato. Linguagens de programao, tcnicas e mtodos que
podem variar de projeto para projeto , contudo, atividades comuns a todas metodologias precisam ser realizadas, tais como:
11 Projeto de software: parte central do desenvolvimento, que mostra o que e como
ser desenvolvido;
11 Gerao de cdigo: que consiste em traduzir em linguagem de programao o que foi
especificado no projeto de software.
Fase de teste
Nesta fase, encontram-se as no conformidades com o que foi especificado durante a
fase de especificao, com o objetivo de aumentar a qualidade do produto. Suas atividades so:
11 Teste de unidade e mdulo: consiste na realizao de testes para verificar a
presena de erros e comportamento inadequado relacionado s funes e mdulos
bsicos do sistema;
20
11 Integrao: reunio dos diferentes mdulos em um produto de software homogneo

e verificao da interao entre esses quando operando em conjunto.
Fase de manuteno
Considerada a fase final, onde se analisa todo o produto. Tem como foco principal as
modificaes, como correes de erros, adaptaes necessrias e melhorias (novas

funcionalidades no planejadas inicialmente) para evoluo do software.
Nessa fase, o software em geral entra em um ciclo interativo que abrange as fases anteriores.
Como ocorrem alteraes, a fase de manuteno abrange caractersticas das fases anteriores,
porm seu enfoque um software j existente.
So quatro os tipos de modificaes que podem ocorrer:
11 Manuteno corretiva: visa corrigir os defeitos que ocorreram durante a fase de

desenvolvimento;
11 Manuteno adaptativa: modifica o software para adapt-lo a alteraes no
ambiente externo;
11 Manuteno perfectiva: adiciona novas funcionalidades ao software. Essas novas
especificaes esto fora do escopo do projeto original e so consideradas como
melhorias de produto;
11 Manuteno preventiva: assume que mudanas tanto no ambiente externo quanto
de especificaes vo ocorrer portanto, j implantado para que o impacto
causado por essas alteraes no afete o sistema.
Para tornar o desenvolvimento de software uma atividade menos catica, e buscando
aumentar a qualidade e produtividade em seus projetos, as organizaes produzem
seus prprios modelos de processo de software.
Assim, impossvel conceber um modelo uniforme que possa descrever com preciso o que
de fato acontece durante todas as fases de produo de um software os procedimentos
utilizados so variados e as necessidades organizacionais diferem substancialmente.
O que se pode dizer que todo modelo de software deve levar em considerao as fases
descritas anteriormente; no entanto, cada organizao 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 andamento das fases ciclo de vida e no uma descrio de como cada atividade deve ser
executada ao p da letra. Um modelo de desenvolvimento corresponde a uma representao abstrata do processo de desenvolvimento que vai, em geral, definir como as
etapas relativas ao desenvolvimento do software sero conduzidas e inter-relacionadas
para atingir o objetivo do desenvolvimento que a obteno de um produto de software de alta qualidade a um custo relativamente baixo.
As Metodologias de Desenvolvimento de Software so uma resposta das organizaes,

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 prpria empresa desenvolvedora.
A documentao gerada a partir da anlise e especificao dos projetos era acompanhada por um mtodo de desenvolvimento para suportar o processo de fabricao do
software. Os mtodos surgiram para dividir todo o processo em etapas e prover sua
q
Captulo 2 - O Scrum
Metodologias de desenvolvimento tradicionais:

vantagens e desvantagens
melhor visualizao, sempre com foco na melhor qualidade final do produto.

21
De acordo com Sommerville, metodologia de desenvolvimento o conjunto de prticas
recomendadas para o desenvolvimento de softwares, sendo que essas prticas geralmente passam por passos ou fases, que so subdivises do processo para orden-lo
e melhor gerenci-lo. As metodologias consideradas tradicionais, tambm chamadas
de pesadas, tm como caracterstica marcante a sua diviso em etapas e fases bem
definidas, como Anlise, Modelagem, Desenvolvimento e Testes. A concluso de cada
fase gera um marco, que tipicamente refere-se um documento, prottipo do software ou
verso 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 gesto, mantendo uma linha de comando e caracterizando o processo com bastante rigor. Essa previsibilidade alcanada porque mais tempo dedicado na fase de
anlise e na elaborao da documentao de planejamento. Como se pode imaginar, o
controle do projeto dificultado j que, em situaes reais de projeto, sempre que se
deseja alterar um requisito, ou parte do escopo, necessrio voltar ao incio do projeto
e reiniciar todo o processo de planejamento.
As metodologias pesadas defendem que uma documentao detalhada necessria por
oferecer um embasamento maior para manuteno 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 informaes 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 limitaes que na prtica acabam no atendendo as
necessidades de uma equipe tcnica, podendo at mesmo inviabilizar os projetos de desenvolvimento em funo dessas deficincias.
Levando em considerao que o processo de desenvolvimento bastante mutvel, ele
acaba demandando muito tempo de trabalho, pois frequentemente h o surgimento de
novos requisitos por parte do cliente, tanto funcionais como no funcionais, assim como a
no conformidade de algumas solicitaes resulta na necessidade de alterao constante na
documentao e no produto em si.
Vantagens e desvantagens
As vantagens principais das metodologias de desenvolvimento tradicionais so: reduo
de riscos envolvendo custos a um nico incremento e acelerao do tempo de desenvolvimento 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 srie de outros benefcios, tais como:
11 Gerenciamento de requisitos: para garantir que as mudanas nos requisitos, que
22
so comuns aps o incio do desenvolvimento, sejam administradas em um projeto

desenvolvimento iterativamente;
11 Integrao de elementos: quando cada mdulo desenvolvimento integrado ao
sistema como um todo, evitando que a atividade de juntar as partes seja um problema no fim do projeto;
11 Gerenciamento de riscos: a cada iterao, possvel analisar pontos crticos e pla-
nejar estratgias para no perder tempo durante o desenvolvimento;

11 Testes: so realizados no fim de cada mdulo, permitindo que erros e no conformidades possam ser tratados ainda dentro do mesmo ciclo.
Embora as abordagens tradicionais tenham surgido como um recurso para empresas
desenvolvedoras de software, so diversas as crticas e limitaes que surgiram. Alm das
j citadas anteriormente, o enorme nmero de documentos exigidos em cada atividade
dificulta a implantao por empresas que no possuem recursos para criar e gerenciar tal
documentao. Com isso, so muito poucas as pequenas organizaes que conseguiram
implantar processos pesados e tradicionais com sucesso eles so mais indicados para
grandes equipes de desenvolvimento.
Exerccio de fixao e
Que metodologias de desenvolvimento so utilizadas na sua organizao?
Voc enxerga vantagens e desvantagens no seu uso? Quais?
Metodologias de geis de Projetos

Na ltima dcada, um novo segmento da comunidade da Engenharia de Software vem
defendendo processos simplificados, com foco nas pessoas que compem o processo
e, principalmente, no programador. Tambm chamada de metodologia de desenvolvimento leve, as metodologias geis propem a execuo dos passos do projeto em
paralelo, e sua principal caracterstica o menor esforo documentao.
A documentao do projeto tende a ser simplificada e orientada pelo cdigo-fonte.
A crtica mais frequente s metodologias tradicionais que so burocrticas. Para seguir
a metodologia, produzida grande quantidade de material, que faz diminuir a velocidade de desenvolvimento.
Arquitetura /
Projeto
Levantamento
Requisitos
Prototipao
Validao
do cliente
Implantao
Testes
Desenvolvimento
Captulo 2 - O Scrum
Figura 2.1
Fases de uma
metodologia
tradicional.
23
O novo advento gil iniciou com alguns especialistas da indstria do desenvolvimento de
software, que se uniram para encontrar valores e princpios relacionados ao desenvolvimento, que escreveram o Manifesto gil. Esse manifesto destacava quatro valores:
11 Software funcional em vez de documentao detalhada;
11 Colaborao ao cliente em vez de negociao de contratos;
11 Indivduos e iteraes em vez de somente processos e ferramentas;
11 Responder s mudanas em vez de seguir um plano minuciosamente detalhado
inicialmente.
Software Funcional em vez de Documentao Detalhada

A ideia dos projetos geis medir o progresso do projeto em funo da quantidade de
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 esto prontos quando 30% das funcionalidades necessrias estiverem funcionando.
A documentao de um projeto extremamente necessria para o seu sucesso, e projetos
geis reconhecem isso. O cdigo no o melhor meio de comunicao entre o racional e a
entanto, no contra
documentao. Ele diz
claramente: Nenhum
documento gerado a
no ser que seja
necessrio e significante.
estrutura do sistema. Documentao legvel necessria para manter o sistema e faz-lo

evoluir; porm, o excesso de documentao pior do que a falta dela. O manifesto, no
entanto, sugere que somente a documentao necessria seja gerada, e que esta seja
sempre atualizada com o cdigo gerado.
Uma documentao enxuta promove integrao na equipe em funo da transferncia de
conhecimento sobre o projeto que ser realizado paralelamente com o cdigo, uma vez que
este no permite duplas interpretaes. De nada adianta ter uma extensa gama de documentos que demandam muito tempo para serem gerados, depois lidos e, principalmente,
para mant-los atualizados. A documentao tem o papel de orientar todos os membros
envolvidos no projeto.
Documentaes e papis no contam como entregas, pois no 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 no conformidades
com aquilo que deseja.
Colaborao ao cliente em vez de negociao de contratos

As metodologias leves enfatizam o relacionamento prximo com o cliente, exigindo que
sua participao seja dedicada, inteligvel, colaborativa e efetiva. Esse envolvimento

favorece caso os requisitos sejam imprevisveis e sujeitos a mudanas; porm, havendo
pontos de vista diferentes entre os desenvolvedores e cliente, possivelmente ocorrero
24
conflitos, riscos e negligncias. Esses riscos podem ser reduzidos atravs de mtodos
guiados por documentao, planejamento e reviso na arquitetura.
As metodologias geis abordam o desenvolvimento de uma lista de prioridades e funcionalidades, para que o cliente defina e classifique o que prioritrio para ele. Tal definio
atualizada constantemente no incio de cada ciclo.
lO Manifesto gil, no
Indivduos e iteraes em vez de somente processos e ferramentas

A experincia e capacitao dos profissionais no desenvolvimento do projeto afetam
diretamente na qualidade do produto e no bom desempenho da equipe do projeto. Ter

excelentes profissionais, no entanto, no uma garantia de sucesso, pois eles dependem
diretamente do processo.
Um processo de m qualidade pode fazer com que os melhores desenvolvedores
no sejam capazes de usar todo o seu talento.
Alm da combinao do processo adequado com bons profissionais, preciso que toda
a equipe possa interagir perfeitamente entre si. Comunicao mais importante que
simples talento para programao. Um desenvolvedor que consegue se relacionar bem
e trabalha bem em equipe tipicamente mais produtivo que um excelente programador
que s consegue trabalhar sozinho. Comunicao o principal valor dos Processos geis
e a maneira mais rpida de se obter informaes.
Alm disso, as responsabilidades e decises so compartilhadas por toda a equipe, mostrando que todos esto envolvidos no processo e trabalhando em grupo. Assim, para a
seleo dos funcionrios envolvidos, deve-se levar em considerao o perfil, a competncia,
o comportamento individual e em equipe, e o profissional deve ser comunicativo. Obviamente,
uma organizao em transio 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 caracterstica a iterao. Aps cada iterao, deve ser possvel apresentar um prottipo 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 prioritrio para ele. Tal lista atualizada constantemente a cada iterao, permitindo acrescentar novos requisitos e mudanas, 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 rpidas e constantes. Entrega-se no incio do
projeto o primeiro sistema, ou parte do sistema, j com algumas funcionalidades desenvolvidas, sendo que novos pacotes de funcionalidades continuam sendo desenvolvidos e
integrados ao mdulo anterior no decorrer do tempo.
Responder mudanas x planos detalhados

Assumindo que mudanas de especificao sempre vo ocorrer em qualquer projeto,
possvel afirmar que tais projetos tero mais sucesso quando se adaptarem a essas
mudanas. Flexibilidade fator fundamental para o sucesso em projetos, pois determina
elas apaream durante o desenvolvimento e os testes. Os participantes no temem as
mudanas, pois assumem que elas so indicadores de que a equipe est aprendendo
sobre o sistema, tentando atingir a satisfao do cliente.
Captulo 2 - O Scrum
o quanto estes so adaptveis. Processos geis so receptivos a mudanas, mesmo que
25
Acerca da existncia de planos, o Manifesto gil no contra. Ele defende que planos sejam
esboados, mas que, como no possvel prever o futuro, as vises desses no devem ir
muito longe.
O planejamento, portanto, deve ser de curto prazo, em virtude das alteraes que
invariavelmente vo aparecer. Na verdade, muito difcil seguir planos de longo prazo

risca, ento faz pouco sentido concentrar muito esforo nisso. Uma dica importante
quando se identifica que o projeto ser muito extenso dividi-lo em fases, tornando
mais fcil gerenci-lo e execut-lo.
Velocidade e qualidade
Ora, para garantir um desenvolvimento rpido, necessrio um software limpo e mais
robusto possvel. Isso porque as equipes de projetos geis so orientadas a desenvolver

cdigos 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 impresso de falsa
velocidade, alm 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 so:
11 Receptividade s mudanas;
11 Orientada s pessoas, no aos processos;
11 Complementada por checagens dinmicas;
11 Equipes de desenvolvimento menores;
11 Com foco para o compartilhamento do conhecimento;
11 Feedback praticamente instantneo;
11 Verses teis;
11 Viso clara de riscos e incertezas na arquitetura do projeto;
11 Poder ser considerada uma soluo de valor agregado;
11 Uma verso poder ser entregue ao cliente em um tempo menor do que uma verso
desenvolvida com a metodologia pesada;
11 So adaptveis, favorecendo o aprendizado dos envolvidos, aprimorando o projeto e
formando assim um ciclo de projeto.
O gerente do projeto no precisa desenvolver um projeto pesado de documentao pelo
contrrio, ele s precisa ter foco no absoluto necessrio, como a programao das tarefas.
26
No entanto, a grande limitao das metodologias geis a maneira como elas manipulam
grandes equipes. Metodologias pesadas e seus mtodos pr-guiados se adaptam melhor s
dificuldades de comunicao, algo extremamente complexo, entre pessoas em projetos que
contam com mais de vinte desenvolvedores.
Como a prioridade mxima das metodologias geis satisfazer o cliente, fornecendo o mais
rapidamente possvel e continuamente novas funcionalidades para o seu software, em

grandes sistemas essa filosofia pode resultar em retrabalho por falta de escala em sua arquitetura. Tradicionalmente, os objetos da metodologia pesada como previsibilidade, repetio
e otimizao so caractersticas de um desenvolvimento seguro. Portanto, seria displicente a
aplicao da modelagem gil em sistemas crticos de manuteno vital, por exemplo.
Exerccio de fixao e
Voc acredita que a sua organizao e os seus clientes se beneficiariam da
adoo de uma metodologia como o Scrum?
Histrico do Scrum
O Scrum foi a princpio concebido como um estilo de gerenciamento de projetos em
empresas de fabricao de automveis e produtos de consumo, por Takeuchi e Nonaka,

no artigo The New Product Development Game (Harvard Business Review, janeiro-fevereiro 1986). Nesse artigo, eles comparavam equipes de alto desempenho e multifuncionais
com um jogo de rugby e concluram que equipes so formadas de menores e equipes trabalhando com sucesso em direo 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 formao Scrum do Rugby (utilizada para reincio do jogo em certos casos).
Em meados de 1983, seguindo a mesma linha de Nonaka e Takeuchi, a metodologia comeou
a ser aperfeioada 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 tambm precisava de uma verso
melhorada de desenvolvimento rpido de aplicao. O seu objetivo era um processo similar
ao Scrum, de curtas interaes, onde o CEO da Easel conseguisse ver cdigo funcionando do
que diagramas Gantt. Seus procedimentos e ferramentas para medir produtividade e comparar diferentes estratgias foram fundamentais na criao do Scrum.
Apesar de a metodologia ter sido iniciada pelos autores supracitados, no ano de 1995, a
documentao da metodologia foi publicada por Ken Schwaber com a ajuda de Jeff, que se
empenharam para sintetizar o que tinham aprendido atravs dos anos e criaram uma nova
Scrum e ajudou a implant-lo no desenvolvimento de softwares em todo o mundo.
O objetivo de Ken Schwaber durante todo esse perodo era auxiliar sua empresa, a Advanced
Development Methods, Inc. a aprimorar seu processo de desenvolvimento de software
com o objetivo de melhorar a produtividade de sua equipe. Aps uma extensa anlise
de como fornecedores de softwares bem-sucedidos e independentes produziram seus
produtos, ele concluiu que os processos de desenvolvimento desses fornecedores
eram bastante anlogos, os quais requeriam constantes verificaes e adequaes.
Toyota, uma grande influncia para o Scrum

Como a maioria dos termos do Scrum esto presentes nos processos da Toyota, essa
empresa, sem inteno, acabou contribuindo para o desenvolvimento da metodologia.
A prpria misso da organizao 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 benefcios para as
Captulo 2 - O Scrum
O primeiro artigo
sobre o tema foi
Scrum and the Perfect
Storm, publicado na
revista OOPSLA pela
Object Management
Group (OMG).
metodologia, a qual chamaram de Scrum. Em 1995, Ken Schwaber formalizou a definio de
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 desenvolvedores de software. Um segundo foco adicionar valor aos clientes, j que o Scrum
um processo de adio de valor, com foco no cliente.
interessante que o Scrum por si s est construindo comunidades de prticas, atravs de
um programa de treinamento para certificao ScrumMaster. Hoje h milhares de certificados
ao redor do mundo estima-se cerca de 20 mil certificados, e cerca de 40 mil ScrumMasters
no certificados atuando em projetos de Scrum no mercado.
Normalmente, tem-se uma tendncia em abrir mo da varivel custo para obter qua-
lidade, ou abrir mo da qualidade para se obter o objetivo do projeto em um tempo

menor. isso que se chama de restrio tripla de projetos, composto pelas pontas:
custo, qualidade e prazos, conforme mostrado na figura 2.2. Essa deciso ainda um
paradigma forte nas principais e na mente dos desenvolvedores: a tendncia de despriorizar um vrtice para conseguir otimizar o outro.
Qualidade
Custo
Figura 2.2
Restrio tripla em
projetos.
Prazo
Porm, a filosofia da Toyota vai de encontro a isso. A empresa trabalhou para quebrar
a restrio tripla como um tringulo de ferro e uniu todas essas pontas, buscando
qualidade, entrega rpida, variedade de produtos e preo baixo. nesse sentido que a
Toyota e o Scrum caminham juntos o sistema da Toyota baseado na quebra da restrio tripla, buscando maximizar todas as variveis da restrio tripla ao mesmo tempo,
reduzindo custos, tempo e barreiras funcionais atravs de um processo interativo que
inspeciona, junto com o cliente, cada passo do processo, para alcanar um resultado
final com qualidade.
Exerccio de fixao e
Como eliminar a restrio tripla na sua organizao?
Enfrentar e alinhar a gesto e o controle da estrutura do cliente so as partes mais
difceis do Scrum. A equipe deve ser auto-organizada, e isso mais fcil de conseguir
em organizaes emergentes, pois estas tm uma facilidade maior de se auto-organizar
atravs da ao local. Caso se pare para reparar as pessoas na linha de frente, geral-
28
mente so as que esto no campo, e, portanto, detm mais conhecimento do negcio.

Na Toyota, isso ocorre entre vendedores de carros ou nas linhas de montagem. l que
as coisas acontecem e surgem, e assim permitem a distribuio do conhecimento e das
aes para desenvolver os projetos. Da mesma forma, no contexto do Scrum, a equipe deve
ser formada de maneira a permitir que se auto-organize tambm. E esse o segredo do
Scrum. Um projeto que utiliza a metodologia tem de ser capaz de formar um time que se
auto-organize.
Takeuchi e Nonaka argumentam que h alguns sinais que podem ser identificados para
dizer se uma equipe est se auto-organizando:

1. Verifique se a equipe est localizada, tem um objetivo e senso comum. possvel
descobrir isso respondendo s perguntas:
22 Os membros da equipe se sentem totalmente responsveis?
22 H algum no caminho atrapalhando o processo?
22 Os membros da equipe esto completamente envolvidos e com foco no projeto?
22 Os membros da equipe sabem o que tm de fazer?
22 Os membros da equipe sabem por que esto 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 invs do seu prprio avano pessoal na empresa. Caso isso
no ocorra, a equipe no se auto-organizar.
3. A terceira, denominada polinizao, fazer com que membros mais experientes
ajudem membros menos experientes. Pessoas que tm alguma especialidade esto
compartilhando conhecimento com os outros?
Exerccio de fixao e
Voc acredita ser possvel ter uma equipe auto-organizvel na sua organizao?
Qual o contexto para possibilitar tal auto-organizao?
Em alguns casos, o trabalho de remover a gesto rduo no entanto, tornar os partici-
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 mltipla:
quando a Toyota comeou a desenvolver o projeto Prius, trouxeram um engenheiro chefe que
no sabia nada sobre o projeto. Por desconhecer o projeto, ele precisava montar uma equipe
com os melhores e mais capazes membros da organizao, 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 caracterstica tpica do Scrum.
No Scrum, todos so parte do processo, a equipe tem uma estrutura vertical e, portanto,
todos esto no mesmo patamar, trabalhando juntos: gerentes, clientes, pessoal da instalao, suporte, entre outros.
O nome Scrum foi inspirado em uma jogada do Rugby a figura 2.3 mostra como um
Scrum no Rugby. Essa analogia feita entre uma jogada de Rugby e o Scrum tem dois fundamentos: o senso de equipe e as constantes reunies em crculo durante o jogo.
q
Captulo 2 - O Scrum
Origem do nome
29
Senso de equipe
O Scrum no Rugby consiste em uma equipe de oito jogadores abraados, que realizam
uma fora, onde o objetivo empurrar o outro time. Essa jogada s eficaz quando
todos os jogadores fazem fora ao mesmo tempo e na mesma direo, fazendo com que
a soma das foras individuais sejam maiores que as do time adversrio, 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 holstico, 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.
Reunies constantes
No jogo de Rugby, os jogadores se organizam em crculo para planejar a prxima jogada.
uma forma de mostrar que o projeto deve ser conduzido em pequenos crculos, mas
com uma viso de longo prazo, que ganhar o jogo. O mesmo ocorre na metodologia
Scrum: cada interao uma forma de recomear a partida reunindo todos os jogadores
30
aps um incidente ou quando a bola sair de campo. A ideia bsica reunir os desenvolvedores e deixar o jogo continuar acontecendo.
A Metodologia Scrum apenas estabelece conjuntos de regras e prticas de gesto que
devem ser adotadas para garantir o sucesso de um projeto. No entanto, esse mtodo no
requer nem fornece qualquer tcnica ou mtodo especfico para a fase de desenvolvimento de software.
Figura 2.3
Exemplo de Scrum.
O processo
Ken Schawber defende que Scrum no uma metodologia em si, mas um framework.
Scrum no vai dizer exatamente o que fazer, mas dar um conjunto de diretrizes que
podem ser seguidas e adaptadas para uma realidade especfica do projeto.
Na concepo desse autor, Scrum enquadrado como um processo para gerenciamento
de projetos geis. De maneira semelhante, no vai resolver todos os problemas, mas, se
bem adequado realidade de projeto, certamente os problemas sero mais facilmente
identificados.
Para Martins, Scrum um processo bastante leve para gerenciar e controlar projetos de
desenvolvimento de software e para criao de projetos de produtos. O Scrum segue a filosofia iterativa e incremental, se concentrando no que realmente importante: gerenciar o
projeto e criar um produto que acrescenta valor para o negcio. O valor decorre da funcionalidade propriamente dita, do prazo em que ela necessria, do custo e da qualidade.
Ou seja, a abordagem do Scrum oposta do modelo em cascata, j que inicia a anlise
assim que alguns requisitos esto disponveis. Depois que alguma anlise foi realizada,
inicia-se rapidamente os trabalhos de projeto tcnico (design), e assim por diante. Em
outras palavras, o projeto trabalha em pequenos ciclos de cada vez, at a concluso do
projeto final. Essa abordagem pode ser chamada de iterativa, e cada iterao consiste na
captura de requisitos, um pouco de anlise, um pouco de design e mais alguma programao e testes, culminando em um ciclo iterativo com vrias entregas.
Emprico
Segundo Cruz, existem dois tipos de processos: definidos e empricos. Processos defi-
nidos determinam o que deve ser feito, quando e como. Para um mesmo conjunto de
variveis 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 implantao de um controle descentralizado que lida de forma eficiente com situaes menos previsveis, o que aparece como uma possvel soluo para
atacar esse problema.
Ora, de acordo com Schwaber (2004), o principal objetivo do Scrum o desenvolvimento de
sistemas de software envolvendo uma poro de vrias tcnicas e de ambiente, como requisitos, tecnologia e recursos, que podem mudar durante o processo. O foco desse mtodo
encontrar uma maneira de os membros da equipe trabalharem para produzir o sistema de
forma flexvel e em ambiente passvel de sofrer mudanas constantes o resultado desse
trabalho deve ser um sistema de software realmente til para o contratante.
definidos no forem adequados devido complexidade do projeto, ou seja, sempre que no

se conheam todas as variveis de entrada para que se possa estabelecer um processo que
pode ser repetido(com a mesma sada sempre), o Scrum um exemplo deste.
O Scrum assim o mais perplexo e paradoxal processo para o gerenciamento de
projetos complexos, mesmo sendo um mtodo incrivelmente simples. Antes de mais
nada, no um mtodo prescritivo, ou seja, no descreve o que se deve fazer em cada
Captulo 2 - O Scrum
Nesse sentido, os processos empricos devem ser utilizados sempre que os processos
circunstncia. usado para trabalhos complexos nos quais impossvel predizer tudo o
que vai acontecer durante o desenvolvimento do sistema de software.
31
De acordo com Beedle (2001), Scrum um mtodo de desenvolvimento gil que procura
uma forma de lidar com o caos, em detrimento a um processo bem definido, cuja funo
primria 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 situao em que um grupo de pessoas precise trabalhar juntas para atingir um
objetivo comum.
Iterativo e incremental
Em virtude da complexidade, tamanho, mudanas de requisitos, urgncia e necessidade
de demonstrar valor mais rpido para o cliente, fica quase inconcebvel desenvolver
software utilizando o modelo cascata, ou seja, desenvolver software de uma nica vez.
A metodologia considera um modelo iterativo e incremental por uma questo de estratgia de planejamento. O modelo segue uma filosofia: dividir para conquistar, onde o
projeto divido em blocos, em ciclos, onde a cada iterao 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 iterao
Figura 2.4
Incremental
e iterativo
diferenas.
Fases do Scrum
Basicamente, a metodologia Scrum dividida em trs fases simples, que se repetem a

cada ciclo: planejamento, desenvolvimento e encerramento.
11 Planejamento: consiste na anlise e definio de requisitos de uma nova funcionalidade requerida pelo cliente para o sistema, baseado na necessidade do negcio do
cliente e no projeto do sistema como um todo. Em seguida, realizada a estimativa de
tempo e custo do novo desenvolvimento. Aps a aprovao do cliente, tal funcionalidade segue o fluxo para a fase seguinte;
11 Desenvolvimento: consiste no desenvolvimento de fato de uma nova funcionalidade,
respeitando o tempo, requisitos exigidos e nvel de qualidade pr-definida na fase
32
anterior;
11 Encerramento: preparao para a entrega da funcionalidade planejada e desenvol-
vida nas fases anteriores, consistindo nas atividades a seguir:

22 Teste unitrio;
22 Teste integrado;
22 Elaborao de documentao de usurio;
22 Treinamento.
Tamanho de projetos
Scrum uma metodologia que se aplica a projetos de qualquer tamanho, realizando uma
avaliao correta do ambiente em evoluo. 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 frequncia, sendo o caminho utilizado
para aumentar a produtividade nesses tipos de sistemas.
Atividades prticas e
Cenrios para levantamento de requisitos
A partir de requisitos, escrever User stories. Cenrios (Sprint previamente finalizada)
para clculo de Burndown a partir do Tuleap. Cenrios (idem) para clculo de Velocidade.
Captulo 2 - O Scrum
importante o instrutor explicar a diferena e importncia dessas mtricas.
33
34
3
Entender a Metodologia do Scrum; Papis, Cerimnias e Artefatos do Scrum
Scrum Master, Product Owner; Daily Scrums, Reunies de Planejamento e Reunies

de Reviso; Product Backlog, Sprint Backlog e Grfico de Burndown
Antes de descrever o passo a passo da metodologia, precisamos conhecer os insumos
conceitos
que a compem. Dessa forma, torna-se possvel familiarizar-se com os termos que sero
utilizados. A metodologia formada por Papis, Cerimnias e Artefatos, e cada um deles
se subdivide em insumos menores, conforme a lista a seguir:
11 Papis:
22 Product Owner (Proprietrio do produto);
22 Scrum Master;
22 Equipe de Desenvolvimento;
22 Cliente.
11 Cerimnias:
22 Reunio de planejamento do Sprint;
22 Reunies dirias de Scrum (Daily);
22 Reunio de Reviso do Sprint.
11 Artefatos:
22 User Stories (Histria);
22 Planning Poker;
22 Sprint;
22 Product Backlog;
22 Sprint Backlog;
22 Burndown Chart.
Captulo 3 - A metodologia
objetivos
A metodologia
35
Papis
Como j mencionado anteriormente, a metodologia define como a equipe deve trabalhar.
O primeiro passo para o desenvolvimento baseado no Scrum definir quem vai fazer o
qu. A metodologia define dois tipos de papis bsicos:
11 Principais;
11 Auxiliares.
Papis principais so os profissionais que fazem parte da equipe do fornecedor ou seja,
so aquelas pessoas comprometidas com o projeto no processo do Scrum. Produzem o
produto em si, o objetivo final do projeto.
J os papis auxiliares so 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 negcio e um profissional com
conhecimento nas duas pontas: no negcio do cliente e na tecnologia. Tem como

principal objetivo representar os interesses do cliente com a equipe tcnica. Funciona,
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 negcio.
Veremos esse termo

em detalhes no tpico
de Artefatos.
Juntamente com os outros envolvidos, ele o responsvel por listar as prioridades e os

requisitos, alm de revisar e aprovar as entregar no final de cada Sprint.
Mais detalhadamente, ele tem as seguintes responsabilidades:
11 Definir os requisitos e funcionalidades de produto;

11 Decidir sobre data de lanamento e trmino;
11 Ser responsvel pela rentabilidade do produto (ROI);
11 Priorizar as funes de acordo com a necessidade atual do cliente;
11 Ajustar recursos e priorizar tarefas a cada ciclo, geralmente de 30 em 30 dias,
como necessrio;
11 Aceitar ou rejeitar o resultado do trabalho.
Scrum Master
o lder da equipe de desenvolvimento, geralmente o programador ou analista de sistemas
mais experiente da equipe. responsvel por garantir a aplicao das prticas 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 so:
11 Assegurar-se de que a equipe de desenvolvimento funciona plenamente e produtiva, intermediando a comunicao entre a equipe e o Product Owner;
11 Assegurar-se de que a metodologia est sendo seguida;
11 Conduzir reunies dirias e reunies de planejamento de atividades;
11 Revisar atividades, tendo conhecimento das que foram concludas e das que
foram iniciadas;
36
11 Identificar novas tarefas, prioriz-las e alterar qualquer estimativa que possa ter
mudado. Isso permite a ele atualizar sempre o Burndown Chart (veremos esse termo
em detalhes no tpico de Artefatos);
11 Tomar aes para tarefas em aberto e computar quantas tarefas esto em aberto com
o objetivo de minimiz-las o mximo possvel para garantir um trabalho eficiente;
11 Avaliar as pendncias e obstculos que causam prejuzos ao andamento do projeto.
Essas pendncias e obstculos devem ser listados, para receber nveis de prioridade
e ser acompanhados com o objetivo de minimiz-los o mais rapidamente possvel, a
fim de serem solucionados. Um plano de ao deve ser implementado de acordo com
a ordem de prioridade desses impedimentos. Alguns podem ser resolvidos pelo time,
outros atravs de vrios times, e outros precisam do envolvimento da gerncia ou at
do cliente, pois podem ser problemas que no so da alada da equipe e, portanto,
podem correr o risco de causar um bloqueio no andamento do projeto;
11 Efetuar a gesto das pessoas, percebendo e resolvendo problemas pessoais ou conflitos
entre os integrantes do time do desenvolvimento Scrum. Caso o Scrum Master no
consiga resolver algum tipo de problema, deve solicitar ajuda gerncia ou do departamento de Recursos Humanos. Alguns estudos apontam que 50% dos problemas de
desenvolvimento acontecem por razes pessoais, ento o Scrum Master precisa estar
sempre atento ao time para maximizar a produtividade e motivao da equipe.
Equipe de desenvolvimento
Tambm conhecida como Scrum Team, correspondem aos membros encarregados por
realizar as atividades de projeto. Ou seja, so aqueles que vo efetivamente colocar a

mo na massa para que o projeto se concretize.
Suas principais atividades so organizar e gerenciar suas prprias atividades. e geralmente esto integralmente dedicados ao projeto. Dependendo da complexidade do software, um projeto pode ter mais do que uma equipe de desenvolvimento. No entanto, a
troca de equipe s deve ocorrer na mudana de ciclo.
Suas principais caractersticas so:
11 Multifuncional e auto-organizvel;
11 Pequenas e multidisciplinares, com at 10 participantes;
11 Definem metas a cada Sprint, junto com o Scrum Master, e especificam seus resultados de trabalho;
11 Tm como responsabilidade principal entregar o bloco (Sprint) no tempo determinado e com o mnimo de erro possvel;
11 Tm o dever de respeitar as regras da metodologia;
Como j falamos, por ser multifuncional, a equipe de desenvolvimento Scrum deve ser
composta por profissionais dos mais variados perfis, incluindo, mas no se limitando a:
11 Programadores;
11 Testadores;
11 Analistas;
11 Desenvolvedores de interfaces;
11 Administradores de bancos de dados.
11 Devem sempre manter o senso de equipe.
37
Na prtica, a diferena entre uma equipe no multifuncional que na primeira, como
podemos visualizar na figura 3.1, o projeto anda mais rpido, pois profissionais de diferentes especialidades trabalham juntos para cumprir uma tarefa. O sentido de equipe
exatamente esse os membros compensam entre si as competncias e as carncias, em
um aprendizado mtuo e contnuo.
Time no Multifuncional
Sprint 4
Sprint 1
Sprint 2
Sprint 3
Anlise
Cdigo
Testa
Anlise
Cdigo
Testa
Anlise
Cdigo
Testa
Sprint 4
Sprint 5
Sprint 5
Time Multifuncional
Sprint 1
Sprint 2
Sprint 3
Anlise
Anlise
Anlise
Cdigo
Cdigo
Cdigo
Testa
Testa
Testa
Cerimnias
A equipe tambm tem a responsabilidade de participar das cerimnias. Essas so
Figura 3.1
Diferena de
velocidade entre
equipes no
multifuncionais e
multifuncionais.
reunies que ocorrem em diversos momentos durante o projeto. O mtodo dividido

sucintamente em basicamente trs cerimnias principais, a saber:
11 Reunies de Planejamento da Sprint (Planning Meetings);
11 Reunies Dirias de Scrum (Daily Meetings);
11 Reunio de Reviso da Sprint (Sprint Retrospective).
Esses trs tipos de evento caracterizam bem o ciclo de vida de cada Sprint, que possui
incio, meio e fim.
Reunio de planejamento da Sprint (Planning Meeting)

Os participantes da reunio de planejamento so:
38
11 Product Owner;
11 Cliente (e outras quaisquer partes interessadas, como diretores ou representantes
do cliente);
11 Scrum Master;
11 Equipe de desenvolvimento.
Tambm chamada de Scrum Planning Meeting, a reunio de planejamento a primeira
reunio do projeto, e seu objetivo realizar o planejamento da Sprint, definindo escopo,

estimativa e importncia.
Segundo Cockburn (2001), essa reunio crtica para o sucesso do projeto, pois se no for
devidamente planejada e bem realizada, pode ocasionar problemas com atrasos, estimativas
mal realizadas e outros problemas tpicos.
Em uma primeira etapa da reunio de planejamento da Sprint, o Product Owner trabalha
em conjunto com o cliente para levantar todas as funcionalidades que o cliente deseja
e assim criar uma lista de funcionalidades requeridas. Em seguida, so selecionadas as
funcionalidades que devem ser entregues na prxima 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 reunio.
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 concluda. Isso ajuda o
Product Owner a definir prazos reais para o projeto e permite acompanhar o andamento
do projeto durante todo o perodo de desenvolvimento.
Aps a confeco do Product Backlog com as prioridades e prazos relacionados, a
reunio continua apenas com Scrum Master e a Equipe de Desenvolvimento. O Scrum
Master quebra cada tarefa em pequenas tarefas, delegando-as aos respectivos profissionais.
Assim, a reunio de planejamento da Sprint tem duas partes. As primeiras quatro horas
so gastas com o Product Owner apresentando a maior prioridade do Product Backlog
para a equipe, incluindo questionamentos da equipe sobre o contedo, propsito, significado e as intenes 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 utilizvel at o final do Sprint.
Durante a segunda parte de quatro horas de reunio de planejamento do Sprint, a
equipe planeja, de fato, a Sprint. Como a equipe responsvel pela gesto do seu
prprio trabalho, ela precisa de um plano provisrio para iniciar a Sprint. As tarefas
que compem esse plano so colocadas em um Sprint Backlog; as tarefas dessa Sprint
Backlog vo emergir medida que a Sprint evolui. No incio do segundo perodo de
quatro horas da reunio de planejamento do Sprint, na verdade j se considera que a
Sprint comeou, e o relgio est correndo em direo 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 dificuldade da funcionalidade e do nvel de produtividade de cada profissional. A equipe de
de qualquer desvio que saia do objetivo previamente definido.
Essa reunio dura at 8 horas, e ela que define o Sprint Backlog. Para validar se todos
os pontos que devem ser abordados em reunio foram concludos, interessante fazer
um checklist da reunio respondendo s seguintes questes:
11 A viso do produto foi completamente entendida?
11 Todas as funcionalidades que o cliente deseja foram levantadas?
desenvolvimento no pode sofrer interferncias externas. blindada pelo Scrum Master
39
11 Os itens do Product Backlog que sero entregues na prxima Sprint foram selecionados?
11 Os nveis 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 histrias (funcionalidades narradas pelo cliente) esto quebradas em vrias tarefas?
11 Todas as tarefas tm um profissional responsvel?
11 Preparar o Task Board quadro de tarefas;
11 Preparar o grfico de Burndown.
Uma vez definido o Sprint Backlog, com a listagem de todas as tarefas, seus responsveis
e prazos, o processo de desenvolvimento comea.
Reunies dirias de Scrum (Daily)

Os participantes das reunies dirias so:
11 Scrum Master;
11 Equipe de desenvolvimento.
Uma das principais caractersticas da metodologia so as reunies dirias de Scrum,
onde o Scrum Master se rene com a equipe de desenvolvimento para avaliar os progressos do projeto e possveis impedimentos que estejam atrapalhando o progresso
do trabalho de desenvolvimento.
As regras para as Daily so:
11 Essas reunies acontecem todos os dias durante o ciclo de desenvolvimento;
11 So tipicamente rpidas e objetivas;
11 A ideia que os participantes estejam de p durante a reunio;
11 Ocorrem preferencialmente no turno da manh;
11 Tm uma durao de no mximo 15 minutos, para evitar perder o foco do que est
sendo desenvolvido e divergncias de assuntos.
A reunio diria de Scrum uma maneira eficiente de manter os membros cientes dos
objetivos e forar que os profissionais no percam o foco. Elas no representam uma
forma de cobrana 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 reunio diria de Scrum tpica pode ser encontrada na figura 3.2.
40
Figura 3.2
Reunio diria de
Scrum
(Daily Scrum).
Na Daily Scrum, cada membro da equipe responde a trs perguntas:
11 O que voc fez nesse projeto desde a ltima reunio diria do Scrum?
11 O que voc planeja fazer nesse projeto entre agora e a prxima reunio diria do Scrum?
11 Que obstculos se interpem no caminho da equipe para atender seus compromissos a esse Sprint e esse projeto?
Como se pode imaginar, o Scrum Master tem um papel muito importante nessas
reunies, pois o responsvel por identificar todos os problemas ou novas tarefas que
surgirem e replanejar o plano da Sprint atual, remanejando o Task Board e o grfico de
Burndown, artefatos que estudaremos na prxima sesso.
Reunio de reviso da Sprint (Sprint Review)

Tambm denominada de Sprint Review, a reunio de reviso da Sprint ajuda a equipe,
de forma colaborativa, a obter feedback e determinar os objetivos da prxima iterao,

assim como a qualidade e as capacidades das funcionalidades produzidas.
Os participantes da reunio de reviso da Sprint so:
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 reunio de reviso da Sprint uma reunio informal de quatro
horas de durao, na qual a equipe de desenvolvimento, juntamente do Scrum Master, se
rene 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 reunio, o Product Owner responsvel por validar os requisitos e,
caso necessrio, 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 ento com membros da equipe e
com o cliente quais sero 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 utilizvel que ser entregue no final da nova Sprint.
Ao final da apresentao das funcionalidades desenvolvidas, o cliente questionado quanto
s suas impresses, mudanas necessrias e alteraes de prioridades. Possveis rearranjos
podem ser inseridos na prxima Sprint.
Depois que essa reunio finalizada, uma nova Sprint pode comear at que todo o
produto seja implementado ou finalizado e o Product Backlog esteja sem pendncias.
Para validar se todos os pontos abordados na reunio foram concludos, interessante
fazer um checklist da reunio, respondendo s seguintes questes:
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?
nos itens do Product Backlog ou funcionalidades que no foram entregues como esperado
41
11 Quais foram os pontos fracos e fortes da equipe durante o Sprint?
11 Algum teve alguma dificuldade?

11 Algum v algum risco futuro para o projeto?
11 Quais os pontos de melhoria a seguir com o prximo processo na prxima Sprint?
Reunio de retrospectiva da Sprint (Sprint Retrospective)

Durante a retrospectiva, o Scrum Master rene-se com a equipe de desenvolvimento e
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 convvio entre as
partes, bem como suas funes. Trata-se basicamente de uma parte de um aprimoramento interno.
Parte de qualquer projeto gil de gesto, a retrospectiva do Sprint uma reunio em
que o Scrum Master, o proprietrio do produto e a equipe de desenvolvimento discutem
como a Sprint acontecem e como podem melhorar na prxima. Se a equipe Scrum interage regularmente com os agentes externos, as percepes 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 eficincia e aumenta a
velocidade ou seja, a produo 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 motivao e a
velocidade de trabalho. importante lembrar tambm 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 reunio de retrospectiva da Sprint orientada ao e deve cobrir trs perguntas
principais:
11 O que deu certo durante a Sprint?
11 O que gostaramos de mudar?
11 Como podemos implementar tal mudana?
Dica: para a primeira retrospectiva da Sprint, todos na equipe scrum precisam considerar as
trs perguntas antes da reunio iniciar. Assim, bom o Scrum Master enviar as perguntas
antecipadamente, para que todos na equipe de Scrum faam algumas notas de antemo
ou at mesmo tomem notas durante toda a Sprint. Uma boa estratgia anotar os impedimentos encontrados durante as reunies dirias e tentar encontrar possveis pontos de
melhoria a partir destes. A partir da segunda reunio de retrospectiva da Sprint, podemos
42
comparar a Sprint atual com anteriores.

Tpicos adicionais que podem ser cobertos nessa reunio:
11 Resultados: compare a quantidade de trabalho planejado com o que a equipe de
desenvolvimento acabou completando de fato. Revise o grfico de Burndown para
entender a performance da equipe de desenvolvimento.
11 Pessoas: discuta o alinhamento e a composio da equipe;
11 Relacionamentos: discuta sobre comunicao, colaborao e trabalho em pares;

11 Processos: discuta sobre suporte, desenvolvimento e processos de reviso de cdigo;
11 Ferramentas: como esto as ferramentas atuais para a equipe de desenvolvimento
Scrum? Pense sobre os artefatos, ferramentas automatizadas, de comunicao
e tcnicas;
11 Produtividade: como a equipe poderia melhorar a produtividade e realizar a maior
quantidade de trabalho na prxima Sprint?
Para algumas equipes Scrum, pode ser difcil se abrir no incio. O Scrum Master pode precisar
fazer perguntas especficas para iniciar discusses. Participar em retrospectivas requer
prtica. O que importa para incentivar a equipe Scrum a assumir a responsabilidade: para
realmente abraar a caracterstica de autogesto.
A retrospectiva da Sprint uma das melhores oportunidades que a equipe Scrum tem de
colocar as ideias de inspeo e adaptao em ao. importante que a equipe possua a
capacidade de identificar desafios e solues durante a retrospectiva e no deixe essas
solues para aps a reunio. Assim, a reunio de retrospectiva ser orientada a aes, tais
como inspeo e adaptao da equipe, que podem ser gravados, inclusive, informalmente:
o importante garantir visibilidade de aes sobre os itens listados aps a reunio.
Artefatos
Os artefatos do Scrum so as ferramentas bsicas para se trabalhar com esse modelo
de desenvolvimento. Esses artefatos servem como guias e indicadores para suportar o

processo e so divididos em seis. Podemos citar:
11 Estrias (User stories);
11 Planning Poker;
Nesta sesso,
estudaremos cada um
deles em detalhes.
11 Product Backlog;
11 Sprint Backlog;
11 Burndown Chart.
Histrias (user stories)

Uma histria do usurio, tambm denominada de user story, uma pequena descrio
que detalha um item do Product Backlog. Esse item posteriormente virar uma funcionalidade ou mais. tipicamente narrada pelo cliente e o Product Owner, atravs de
tcnicas de levantamento de requisitos, o ajuda a detalhar e extrair pontos importantes
para composio de funcionalidades do sistema para o tornar legvel em um formato
que se torne til o suficiente para suportar o negcio.
As user stories ajudam no entendimento das atividades de negcio e tambm so
utilizadas como suporte para atividades de planejamento. So usadas como base para
clculo de velocidade da equipe. Usualmente, a estimativa feita em pontos, os denominados story points, embora tambm possam ser feitos em horas.
11 Sprint;
43
Uma dica para escrever uma boa histria conversar sobre ela, entre os desenvolvedores e os
clientes, de forma a detalhar os itens e esclarecer todas as dvidas sobre o que deve ser feito.
Antes de se reunir com o cliente, o proprietrio do produto e a equipe de desenvolvimento devem
preparar um questionrio 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 oramento automaticamente, a partir de um cliente
ou servio. Gostaria de poder enviar o oramento para o cliente sem precisar nem entrar
em contato. Eu acho que passo muitas horas calculando o total do oramento, pois por
serem muitos, eu nunca tenho os preos atualizados.
Seria difcil dar incio ao desenvolvimento baseado apenas nesse pequeno texto.
Baseado nesse exemplo, seguem os tipos de questes que a equipe pode aplicar para
extrair mais informaes teis para o projeto:
11 Voc faz o oramento sempre para os mesmos clientes?
11 No sistema atual voc est acostumado a fazer pesquisa de servios atravs de
quais atributos?
11 Um produto fornecido apenas por um fornecedor?
11 O cliente sempre compra os mesmos servios?
11 possvel enviar o oramento por e-mail ou atravs de interface para o cliente;
porm, como voc pretende receber a autorizao? Via interface grfica, e-mail, ou
atravs de um contato fora do sistema?
11 Os preos dos servios so muito dinmicos?
11 Os preos dos servios so personalizados para cada cliente?
11 Voc j tem um cadastro de servio no software atual?
comum que os detalhes sejam expressos em histrias futuras. melhor ter muitas histrias menores do que ter poucas histrias grandes. tambm importante lembrarmos que a
comunicao cara a cara um dos princpios 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 discusso sobre os detalhes, j definindo as funcionalidades.
Partindo desse exemplo de user story, poderamos definir as seguintes funcionalidades:
11 Manter cliente:
22 Consultar cliente.
11 Manter servio:
22 Cadastrar servio;
22 Atualizar preo do servio;
22 Excluir servio;
22 Consultar servio.
11 Manter oramento:
22 Criar oramento;
22 Calcular oramento;
22 Enviar oramento;
22 Excluir oramento;
22 Consultar oramento;
22 Autorizar oramento.
44
interessante que o proprietrio do produto faa uma espcie de estgio no cliente para
vivenciar a atividade no negcio e assim consiga ser mais sensvel s necessidades.
Um princpio-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 ingls requisitos agitados), e que os desafios imprevisveis no
podem ser facilmente tratados de uma maneira preditiva ou planejada. Como tal, o Scrum
adota uma abordagem emprica, aceitando que o problema no pode ser totalmente entendido ou definido, focando na maximizao da habilidade da equipe para entregar rapidamente e responder as necessidades emergentes.
As user stories devem ser compreensveis por todos os envolvidos: usurios, cliente
e equipe de desenvolvimento. Portanto, existem alguns critrios importantes com os

quais se preocupar quando se descreve histrias de usurio. Elas precisam ser:
11 Negociveis: uma user story no um processo jurdico e, portanto, no necessita
ter excesso de informaes. A ausncia dessas informaes 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 usurios;
11 Entendimento comum: como o planejamento do Sprint no Scrum baseado em
estimativas, as user stories precisam ser estimveis. No necessrio que a equipe
entenda todos os detalhes da user story, mas necessrio um nvel de entendimento
comum dela para que seja possvel realizar a estimativa;
11 Pequena: uma user story deve ser pequena o suficiente para que possa ser implementada e implantada, mas grande o suficiente para traga valor para o negcio;
11 Testvel: as user stories precisam ser testveis; caso contrrio, no ser possvel a
equipe saber se o desenvolvimento foi validado ou no.
Planning Poker
O Planning Poker basicamente a atribuio de pontos s user stories. uma prtica
que ajuda na estimativa de uma histria ou de uma tarefa. Tais pontos representam um
grau de dificuldade de uma funcionalidade perante o projeto.
Planning Poker no Scrum rene vrias opinies 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 interao
do usurio. Como esses membros da equipe representam todas as disciplinas de um
projeto de software, eles so adequados para a tarefa de estimativa.
A dinmica 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
no linear, como, por exemplo:
Em segundo lugar, devem-se definir valores de referncias. Como, por exemplo: identificar
uma user story qual pode ser atribuda o menor valor (10 pontos), outra que representa
um valor mediano (50 pontas) e outra qual representa o valor mximo (130 pontos). Dessa
forma, essas histrias sero utilizadas como referncias para pontuao de demais user
stories que apaream durante o processo de estimativa nas reunies de planejamento.
10, 20, 30, 50, 70, 130...
45
No incio do exerccio de planejamento gil, a cada estimador dado um baralho de
cartes de Planning Poker. Cada carto tem uma das estimativas vlidas sobre ela,
como as recm-descritas. Para cada histria de usurio ou tema a ser estimado, um
moderador (geralmente o Product Owner ou o Scrum Master) l a descrio. Haver
alguma discusso, onde o moderador responde a quaisquer perguntas dos avaliadores.
Mas o objetivo de Planning Poker no Scrum no para derivar uma estimativa de que vai
resistir a qualquer controle futuro. Em vez disso, a ideia obter uma estimativa valiosa
que pode ser alcanada de forma barata.
Aps a discusso, cada um estimador seleciona de maneira privada um carto representando sua estimativa. Uma vez que cada estimador fez uma seleo, os cartes so
simultaneamente virados e mostrados, de forma que todos os participantes podem ver
a estimativa uns dos outros. Nesse ponto, provvel que as estimativas provavelmente
sejam significativamente diferentes, e isso aceitvel. O moderador deve encorajar
que as estimativas marginais expliquem as suas perspectivas para que a equipe possa
entender o porqu de nmeros mais discrepantes. O moderador toma notas durante
essa sesso de planejamento gil, pois se imagina que isso ser til quando a histria for
programada e testada. No haver problemas se, aps discusses, quaisquer participantes decidirem mudar suas estimativas em funo de discordncias ou convencimentos comum em equipes geis.
Aps a discusso, uma nova rodada de estimativa deve acontecer e uma nova seleo
de carto pode ocorrer. Muitas vezes, as estimativas vo convergir na segunda rodada.
Seno, repita o processo at que a equipe concorde com uma nica estimativa a ser
usada para a user story. Raramente ser necessrio mais do que trs rodadas de discusses na estimativa para se alcanar a meta Sprint.
Sprint uma iterao, ou seja, um bloco de desenvolvimento em Scrum, que deve
ser completada em 15 dias ou em 1 ms. 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 construo de um sistema pea por pea. Inicialmente desenvolve-se uma parte e, em seguida, um o bloco adicional adicionado primeira, e assim por diante. Alistair Cockburn (2008) descreve desenvolvimento incremental
principalmente como uma estratgia de encenao e de agendamento. Por exemplo, uma
abordagem incremental para o desenvolvimento de um site de leilo 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 Fundamentos do Scrum
balho estratgia de programao. Um processo de desenvolvimento iterativo reconhece a
46
impossibilidade ou, pelo menos, improbabilidade de se conseguir acertar o desenvolvimento de funcionalidade em sua inteireza da primeira vez. Dentro da construo de um site
de leilo on-line de forma iterativa, podemos primeiro desenvolver uma verso preliminar
do site completo, obter feedback sobre ele, desenvolver uma verso subsequente do site
completo que incorpora o feedback do cliente na segunda vez e repetir o processo, conforme necessrio.
Assim, em um processo incremental, desenvolvemos totalmente uma funcionalidade e, em

seguida, segue-se para a prxima. Em um processo iterativo, se constri todo o sistema, mas
isso feito de forma imperfeita em primeiro lugar, usando passos subsequentes atravs
de todo o sistema para melhoria. As fraquezas inerentes de ser apenas iterativo ou apenas
incrementais desaparecem quando eles so combinados, e essa a forma como eles esto
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 comeo de sua execuo.
Durante cada Sprint, a equipe cria um incremento de produto entregvel, 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, to importante que um dos quatro valores indicados no Manifesto
gil afirma que se valoriza software funcional mais que documentao abrangente (Beck
et al., 2001).
Metodologias geis enfatizam software funcional por trs razes:
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 usurios documento sobre o que o produto
vai fazer;
11 Software funcional auxilia a equipe avaliar seu processo: um dos maiores riscos
em um projeto no saber o quanto ainda resta a ser feito. Quando se permite
muito de um sistema em estado inacabado, extremamente difcil saber o quanto de
esforo 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 rpida mudana de hoje, a opo de entregar
o produto precocemente, mesmo que isso signifique entrega de menos recursos,
pode ser muito valioso. Colocar o software em uma posio prxima a essa, no final
de cada Sprint, oferece essa opo.
Conforme vimos anteriormente, durante a reunio de planejamento da Sprint, so definidos os itens do Product Backlog que entraro para o Sprint. Nessa reunio, o Product
Owner informa a equipe dos itens no Product Backlog que o cliente deseja que sejam
priorizados. A equipe ento determina quanto eles podem se comprometer a concluir
durante a prxima Sprint e registram isso no Sprint Backlog.
1. Entregue algo de valor a cada Sprint.

2. Prepare essa Sprint para a prxima.
3. Mantenha os perodos de tempo regulares e estritos.
4. No mude os objetivos.
5. Obtenha feedback, aprenda e adapte.
Regras da Sprint:
47
Entregue algo de valor a cada Sprint

Mesmo que se certificar que no fim de cada Sprint haja um software funcional no seja
um desafio muito grande, as equipes Scrum tambm devem entregar algo valioso para
os usurios ou clientes ao fim de cada Sprint em termos de sistema. A definio do que
valioso para usurios ou clientes pode ser estipulado muito facilmente e de forma
quase maliciosa.
Por exemplo, uma equipe pode argumentar que atualizar os desktops dos desenvolvedores para a verso mais recente de seu Sistema Operacional preferido lhes
permite desenvolver mais rapidamente para que os novos recursos se tornem disponvel aos clientes de maneira mais eficientemente. Embora isso possa muito bem ser
verdade, a inteno que, a cada Sprint, se deve entregar algo de valor imediato para
os usurios ou clientes que eles possam enxergar.
Prepare essa Sprint para a prxima
Esteja preparado. Passe um pouco de esforo em cada Sprint preparando-se para a
Sprint Seguinte. Ken Schwaber (2009) recomenda a alocao de cerca de 10% do

tempo disponvel de uma equipe em qualquer esforo para se preparar para o prximo
esforo. A equipe deve, claro, ajustar esse valor para cima ou para baixo com base na
sua experincia.
J sabemos que uma equipe no deve puxar uma user story ou outro item do Product
Backlog em uma Sprint se claramente muito grande para ser concludo. Uma histria de
usurio pica que levar meses para completar deve ser decomposta em pedaos menores,
de modo que cada uma possa ser concluda dentro de uma Sprint. Este verdadeiro para
user stories que so demasiadamente vagas. Se uma histria no pode ser concluda em
uma Sprint, ela no deve ser trazida para a Sprint. Em vez disso, a equipe precisa para
passar por algum esforo para aprender sobre a estria pela primeira vez.
No entanto, perceba que uma user story no precisa estar completamente compreendida
para entrar em uma Sprint. Uma histria de usurio no Product Backlog no 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 vo colaborar com a histria
durante a Sprint. No entanto, cada histria de usurio puxada para a Sprint deve ser entendida em detalhes o suficiente para que, quando discutida e argumentada durante a Sprint,
possa ser detalhada e concluda.
H algumas coisas que a equipe Scrum deve fazer para garantir esse pensamento
proativo nas Sprints:
11 Discutir o product backlog. identificar os cinco principais itens na necessidade de promover o pensamento proativo. Para cada um dos itens, discutir quem precisa pensar
sobre isso (arquiteto? Designer de experincia com o usurio? Administrador de
banco de dados? Outro?) E decidir em quantas Sprints de antemo que deve comear;
48
11 Nas suas prximas Sprints Reviews, discuta se cada item no Product Backlog possui detalhes suficientes includos detalhes suficientes e se ele foi adicionado apenas no tempo;
11 Para cada Sprint, necessrio controlar a quantidade de tempo gasto pensando no
futuro. Normalmente, cerca de 10% do tempo disponvel de uma equipe deve ser
gasto olhando para frente.
Mantenha os perodos de tempo regulares e estritos

Manter os perodos de tempo estritos para as Sprints refora a ideia que o projeto se move
continuamente adiante. A equipe deve entregar um novo incremento de produto potencialmente utilizvel constantemente. Caso contrrio, ou seja, se os perodos variarem (Vamos
executar uma Sprint de seis semanas agora porque ns estamos trabalhando em elementos
arquiteturais) ou se estes so ocasionalmente estendidos (Ns s precisamos de mais trs
dias), essa disciplina valiosa ser perdida ao longo do tempo.
Podemos citar algumas vantagens de se manter perodos de tempo regulares:
11 Equipes se beneficiam de uma cadncia regular: quando as duraes Sprint variam,

os membros da equipe so muitas vezes se sentem inseguros do cronograma. Perguntas como Essa a ltima semana da Sprint? ou Ser que ns enviamos nessa
quinta-feira ou na prxima quinta-feira? tornam-se comuns. Uma cadncia regular de
uma a quatro semanas ajuda as equipes a se acostumarem a um ritmo de trabalho;
11 Planejar a Sprint se torna mais fcil: tanto o planejamento da Sprint, quanto o planejamento do release, so simplificados quando as equipes ficam com uma durao
da Sprint constante. O planejamento da Sprint mais fcil, porque depois de normalmente 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 fcil: equipes Scrum derivam seus planos de lanamento empiricamente (sempre que possvel). Eles estimam o tamanho do trabalho
a ser feito em um projeto e, em seguida, medem a quantidade concluda por Sprint.
Se a quantidade de horas na Sprint varia, medir a velocidade de uma equipe se torna
mais difcil, pois no 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 desnecessrio
quando as Sprints so mantidas sob o mesmo perodo de tempo.
Para deixar claro que os prazos da Sprint precisam ser cumpridos rigorosamente, bvio
que as equipes vo ocasionalmente precisar deixar de fazer algum trabalho que tinham inicialmente planejado durante alguma Sprint. Essa situao no 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 no o
fim do mundo. Assim, invariavelmente, termine as Sprints no tempo correto. No chegue na
data planejada e decida que precisa de mais um ou dois dias para finalizar o trabalho.
No mude os objetivos
Durante uma Sprint, nenhum integrante da equipe, nem mesmo o Product Owner, pode
alterar o Sprint Backlog. Ou seja, a cada Sprint, os requisitos so congelados. O desenvolvimento de cada Sprint deve terminar no tempo predefinido em reunio. Caso os
para o Product Backlog.
A postura de Scrum de ser contra as alteraes meio do Sprint pode parecer prejudicial para
o sucesso do projeto. Afinal, s vezes as mudanas so to importantes que precisam ser
feitas. E outras vezes novas informaes podem tornar intil o trabalho no qual a equipe
est atualmente envolvida. No entanto, existem algumas excees.
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
requisitos no sejam finalizados por qualquer motivo, eles so deixados de fora e voltam
49
trabalhando. Antes de mais nada, o Scrum Master deve garantir que os objetivos da Sprint
atual sejam visveis e conhecidos por toda a organizao. Mas, quando isso acontecer, a
direo do Scrum anunciar uma finalizao anormal na Sprint, seguida imediatamente
pelo planejamento de uma nova Sprint para incluir a funcionalidade recm-descoberta de
mais alta importncia.
Garantir a visibilidade dos objetivos da Sprint importante porque torna menos
provvel de acontecer.
Em muitas organizaes, os nicos que veem o redirecionamento constante da equipe so
os membros da equipe em si. A abordagem Scrum de no permitir a mudana em um Sprint
Backlog, mas disponibilizar o encerramento anormal seguido de um novo comeo aumenta
a visibilidade de aumento de custos e frequncia de mudana. Isso deve dificultar a quantidade de mudanas lanadas contra a equipe no meio de uma Sprint, pois apenas mudanas
realmente mais importantes justificaro o encerramento anormal de uma Sprint.
No caso, quando novas informaes so aprendidas sobre o trabalho que est sendo realizado (que pode fazer o trabalho planejado menos desejvel), 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 oramento e no pode
comprar o seu produto, mesmo que tenha a nova funcionalidade, ou que ele foi adquirido e
ser forado a usar o produto do seu concorrente, ou qualquer das situaes semelhantes.
Nesses casos, pode fazer sentido parar de trabalhar nessa funcionalidade especfica, dependendo da convenincia geral para outros clientes e de quanto tempo o trabalho pode requerer.
No entanto, situaes como essas acontecem com menos frequncia do que a maioria das
pessoas que so novas para Scrum pensam. Uma situao muito mais comum a de ter um
negcio orientado a interrupes, mudanas, em que mudanas simplesmente continuam a
aparecer e que, por causa disso, os desenvolvedores e o resto da equipe tambm precisam ser.
Atravs dos anos, as organizaes se tornaram viciadas em redirecionar constantemente
suas equipes. Muitas vezes as equipes no so nem interrompidas porque o Product Owner
descobriu uma necessidade do cliente crtica ou outra interrupo vlida, mas simplesmente porque as partes interessadas no conseguiram pensar no futuro. Eles se tornaram
acostumados a trabalhar dessa forma e no esto 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
permaneam inalteradas durante a durao da Sprint. No entanto, embora no sejam permitidas alteraes na Sprint, o mundo inteiro pode estar mudando fora dela. Por fim, depois
que uma Sprint completada, a equipe demonstra como usar o software.
50
Obtenha feedback, aprenda e adapte

Cada Sprint pode ser vista como um experimento. O proprietrio do produto e da equipe
se encontram no incio da Sprint para identificar a experincia mais valiosa que eles
podem executar. O experimento envolve a criao de uma certa quantidade de novas
funcionalidades na forma de software funcional.
Grande parte da aprendizagem ser sobre o produto: o que os usurios gostam? O que eles
no gostam? O que eles acham confuso? O que eles querem seguir? Quais so as caractersticas do novo incremento que pode ajud-los pensar acerca de coisas sobre as quais eles
no tinham pensado antes?
Talvez parte do aprendizado ser sobre o uso da equipe sobre o prprio Scrum: quanto
trabalho que podemos fazer em um sprint? O que fica no nosso caminho? O que poderia nos
ajudar a ir mais rpido? Estamos obtendo feito software a cada Sprint?
A prpria caracterstica do Scrum: ser de desenvolvimento iterativo e incremental sobre a
gerao de feedback, aprender com ele, e ento 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
Na reunio de
Planejamento, o
Product Owner prepara
uma lista de funcionalidades desenvolvida
em conjunto o cliente,
que organizada por
prioridade de entrega.
Esse o Product
Backlog.
just-in-time. Assim, descries de funcionalidades podem ser recolhidas em alto nvel

no incio, mas elas devem ser progressivamente refinadas no decorrer do projeto. Elas
so documentadas em um Product Backlog, que uma lista de todas as funcionalidades
desejadas que ainda no esto no produto. Ele mantido pelo Product Owner e possui uma
ordem de prioridade, o que o faz ser conhecido muitas vezes como lista de funcionalidades
priorizadas. Ao contrrio de um documento de requisitos tradicional, um Product Backlog
altamente dinmico: itens so adicionados, removidos e priorizados novamente a cada Sprint,
medida que se aprende mais sobre o produto, os usurios, a equipe e assim por diante.
O Product Backlog uma lista em nvel de negcio. Dessa forma, no est escrito em nvel
de negcio e esto em uma linguagem do cliente. J vimos que o Product Backlog no final,
e que a equipe de desenvolvimento tambm contribui para a sua manuteno. Essa contribuio se d por meio das estimativas de custos das funcionalidades.
H um grande mito sobre os requisitos: se voc os escreve, os usurios recebero exata-
mente o que eles querem. Isso no verdade! Na melhor das hipteses, os usurios recebero exatamente o que foi escrito, que pode ou no ser o que eles realmente querem. As
palavras escritas so enganosas parecem ser mais precisas do que realmente so.
11 Documentos escritos podem fazer voc suspender o julgamento: quando algo est
escrito, parece oficial, formal e finalizado, especialmente quando uma formatao
organizacional foi aplicada;
11 Com um documento escrito, no conversamos acerca do significado como faramos
em uma conversa, para garantir uma transferncia de entendimento;
11 Documentos escritos diminuem a responsabilidade da equipe como um todo: um
dos objetivos da mudana para o Scrum fazer com que toda a equipe trabalhe em
conjunto em direo ao objetivo de oferecer um grande produto. Queremos tirar do
processo de desenvolvimento maus hbitos que prejudicam esse objetivo. Documentos escritos criam transferncias sequenciais de atividade, que tiram a equipe
de uma unidade de propsito. Uma pessoa (ou grupo) define o produto; outro grupo
constri. A comunicao bidirecional desencorajada;
51
11 No deixar o beb sozinho sem documentao: tais deficincias na comunicao

escrita no 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 documentao abrangente, gil tem sido mal interpretada como sendo totalmente contra documentao.
O objetivo no desenvolvimento gil encontrar o equilbrio certo entre a documentao e discusso;
11 Use User Stories para o Product Backlog: histrias de usurios so a melhor maneira
de mudar o foco de escrever sobre funcionalidades para falar sobre eles mesmos.
A user story uma breve descrio, simples de uma funcionalidade, contada a partir
da perspectiva da pessoa que deseja uma nova funo, geralmente um usurio ou
cliente do sistema. Elas so muitas vezes escritas em cartes de ndice ou notas,
armazenadas e dispostos em paredes ou mesas para facilitar o planejamento e discusso. Como tal, as histrias de usurio mudam fortemente o foco de escrever sobre
os recursos para discuti-las. Uma user story frequentemente tem o formato:
Como um <tipo de usurio>, eu gostaria de <algum objetivo>, pois <alguma razo>.
Em resumo, o Product Backlog deve incluir todas as funcionalidades visveis ao cliente e
em torno de dez dias de desenvolvimento esses itens devero estar prontamente definidos para o seu desenvolvimento comear. As tarefas que tm mais prioridade e complexidade devero ser quebradas em sub-tarefas para poderem ser estimadas e testadas.
Observe a tabela 3.1. Um exemplo de sub-tarefa so as funcionalidades Cancelar Vinculo
e Vincular Caixa de Picking List.
Tabela 3.1
Product Backlog.
Product Backlog
Funcionalidade (Use case)
52
Prioridade
Estimativa
inicial (h)
Pr requisito
Cdigo
Ttulo
UC_01MC003
Manter Perfil
12
UC_01MC004
Associar Operadores aos Perfils
16
UC_01MC003
UC_01MC002
Gerenciar Perfil de Acesso
16
UC_01CT013
UC_01MC001
Painel de Rotas
22
UC_01CT013
UC_01CT013
Efetuar Login no Sistema
UC_01CT014
Gerar Relatrio de Picking List
10
UC_01CT015
Registrar Mercadoria danificada
12
UC_01CT016
Manter Caixa
18
UC_01CT023
UC_01CT024
Manter Vnculo
UC_01CT024a
Cancelar Vnculo
10
UC_01CT024b
UC_01CT024b
Vincular Caixa ao Picking List
32
UC_01CT019
Manter Cubagem
28
UC_01CT020
Escanear Unidade
20
UC_01CT021
Expedir Picking List
12
UC_01CT023
Manter Tipo de Caixa
10
Sprint Backlog
Assim que a equipe Scrum escolher e definir a lista de requisitos e a prioridade de seus
itens no Product Backlog, d-se incio 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 informaes tcnicas
adicionais que auxiliaro no desenvolvimento.
A seguir, segue um exemplo de um Sprint Backlog, na tabela 3.2, da funcionalidade Consultar Caixa. No existe um padro, pode ser feito de vrias formas: Excel, Word, em um
quadro, post-it na parede, entre outros. O importante que as informaes se tornem
disponveis para controle do projeto.
Sprint Backlog
Funcionalidade (Use case)
Descrio
Cdigo
UC_01CT016
Ttulo
Manter Caixa
Permitir a consulta, a edio, a excluso de caixas

e o cadastramento de novas caixas.
Prioridade
Estimativa inicial
18
Horas Trab.
Status
Pendente
Pr requisito
UC_01CT023
Menu
Menu: Cadastros g Caixas
Regras
Campos Status e Tipo com combobox
2. Operador preenche os parmetros de

consultas desejados (Caixa, Tipo) e clica na
opo "Consultar";
3. Sistema faz a consulta na base de dados
filtrando as caixas pelos parmetros
informados;
4. Sistema carrega a tela com o resultado da
consulta, preenchendo os campos da grid
(Caixa, Status, Tipo, Selecionar).
A equipe compila uma lista inicial dessas tarefas na segunda parte da reunio de planejamento do Sprint. As tarefas devem ser divididas de modo que cada um leva cerca de 4 a
16 horas para terminar. Tarefas que durariam mais de 4 a 16 horas so considerados meros
espaos reservados para as tarefas que ainda no foram adequadamente definidas.
Logo aps o Sprint Backlog estar concludo, preenchido o campo Horas Trab com a
quantidade de horas que a funcionalidade demandou para ser concluda. Sendo assim,
possvel comparar o total de horas trabalhadas com a estimativa pr-definida na reunio
de planejamento, dando oportunidade de melhorar futuras estimativas. Caso haja uma
diferena significativa, a equipe Scrum deve negociar novamente com o cliente uma
nova data de entrega.
importante selecionar uma pessoa para adicionar, atualizar e excluir informaes 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 tambm
recomendado, para que os membros da equipe possam podendo incluir itens conforme
concluam suas atividades, como um quadro de cartes ou post-its ou um software que
simule essa interface, como mostrado na figura 3.3. Dessa forma, o responsvel pelo
Sprint Backlog pode, ao fim do dia, atualizar o arquivo.
Tabela 3.2
Sprint Backlog da
Funcionalidade
Consultar Caixa.
1. Operador acessa a tela de Caixas

(TL_01CU006_01);
53
Mais Importante
Menos Importante
Manter Tipo
de Caixa
Cancelar Vnculo
Vincular Caixa
ao Pick List
Manter Caixa
Figura 3.3
Lista de prioridades
simulando quadro
de cartes post-its.
Usar uma superfcie grande e visvel de cartes positivo porque:

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
responsvel pela planilha;
11 Fica mais fcil priorizar novamente as atividades basta trocar a posio dos cartes;
11 Aps a reunio, os cartes 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 grfico de controle do Scrum e representa o trabalho restante
dentro da Sprint de uma verso do sistema que ser entregue. No exemplo mostrado a
seguir, na figura 3.4, o eixo horizontal do grfico exibe as iteraes e o eixo vertical exibe
a quantidade de trabalho restante.
250
245
Horas Restantes
200
202
150
159
140
113
100
68
50
28
0
Release 5\
Sprint 1
Release 5\
Sprint 2
Release 5\
Sprint 3
Release 5\
Sprint 4
Release 5\
Sprint 5
Release 5\
Sprint 6
Release 6\
Sprint 1
De acordo com Mountain (2011), esse tipo de grfico funciona em muitas situaes e com
diversas equipes. Porm, em projetos com muitas mudanas de requisitos, talvez o grfico
no seja adequado, j que a quantidade de horas no 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 dirio da equipe
por horas, de acordo com a soma das tarefas listadas no Sprint Backlog. A equipe tambm
possui uma task board onde as funcionalidades so colocadas separadas por estados.
54
Figura 3.4
Grfico de
Burndown em
Planejamento.
Grfico de Burndown
uma das principais ferramentas para o gerenciamento do processo de desenvolvimento,
pois permite mostrar as partes do trabalho que faltam para uma Sprint acabar, dia por dia.
um grfico que mostra a quantidade cumulativa restante de trabalho de uma Sprint,
diariamente, e permite visualizar o trabalho ainda no cumprida sobre o tempo, assim,
habilitando a avaliao sobre a quantidade restante de trabalho e o tempo restante para
completar uma Sprint. com base nesse grfico que se pode orientar e tomar decises
quanto modificao do escopo ou cancelamento da Sprint.
Sua atualizao deve ser diria para que assim a tomada de deciso seja realizada com
base em dados atualizados, melhorando a produtividade da equipe e habilitando a
previsibilidade de riscos. Durante as Scrums dirias, o Scrum Master acompanha os
membros da equipe para perceber o que foi concludo at aquele momento. Assim, dia a
dia, ele ajusta o grfico de Burndown e, a qualquer momento, todo o time pode ter uma
ideia do andamento do processo. O mesmo grfico pode ser mostrado para o Product
Owner visualizar a trajetria do projeto: atrasado, adiantado ou dentro do cronograma.
Em outras palavras, esse grfico informa se a equipe est aproximadamente dentro do
prazo, servindo como um sinal de alarme para o projeto. Atravs 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 reduo de
tarefas no acontea. Segue-se a anlise de trs grficos de projeto que se encontram
em situaes 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 relao queles
estimados inicialmente para a Sprint. Recomenda-se nesse caso a remoo de funcionalidades do Sprint Backlog, diminuindo o escopo da Sprint.
250
200
Pontos
150
100
0
Figura 3.5
Grfico de
Burndown
para Sprint
Superestimada.
Dias
Estimado
Realizado
10
11
12
13
14
50
55
Se, em caso contrrio, a linha real do andamento do projeto estiver muito acima da linha
estimada, deve-se aumentar o escopo da Sprint. A seguir, na figura 3.6, segue um exemplo
de projeto para a gesto de uma imobiliria em que o projeto foi sendo realizado antes do
estimado ou seja, muitos pontos foram sendo desenvolvidos antes do tempo pr-determinado. Nesse caso, possvel aumentar o escopo.
160
140
120
Pontos
100
80
60
40
20
0
10
11
12
13
14
Dias
Estimado
Realizado
O ideal em situaes assim retirar tarefas de alta prioridade da prxima Sprint. Caso a
Figura 3.6
Grfico de
Burndown
para Sprint
Subestimada.
meta da prxima 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 gesto de construtora sendo
realizado mais ou menos conforme estimado ou seja, muitos pontos esto sendo
desenvolvidos no tempo determinado. Esse um exemplo de um projeto ideal.
160
140
120
Pontos
100
80
60
40
56
20
0
Dias
Estimado
Realizado
10
11
12
13
14
Figura 3.7
Grfico de
Burndown para
Sprint Ideal.
Task Board
Consiste em um grande painel, que possibilita colocar as diversas informaes rele-
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 Concluda). A ideia do Task Board tornar essas informaes sempre visveis para
todos os interessados no desenvolvimento do projeto. Geralmente, o painel desenhado e colocado em uma parede, e as atividades so descritas em cartes de post-its,
como na figura 3.8:
Sprint Backlog
Em Execuo
Concludo
BurnDown
Cadastro de
categorias de
apartamentos
Cadastro de
apartamentos
Problemas
no servidor
de teste
Cadastro de
clientes
SCRUM Master
dever resolver
(remover) este
impedimento
Release
Como no criado um Product Backlog para cada produto, Scrum recomenda a criao
de um plano de Release, que divide os itens do Product Backlog em Sprints. Cada Sprint
gera um entregvel, que so funcionalidades desenvolvidas naquela Sprint. Conforme
pode ser visualizado na figura 3.9, a juno dos entregveis 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 usurio. Os
entregveis de cada Sprint no so liberados para os usurios conforme so concludos,
mas so liberados quando a juno de cada entrega forma um produto que faa sentido
e adicione valor para o cliente.
Conforme possvel 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 integrao apenas entre essas duas
funcionalidades. Durante a Sprint, estas tambm foram testadas unitariamente.
Figura 3.8
Task Board com
Impedimento.
57
Sprint #1
Manter
Pick List
Manter Caixa
Entrega 1
Sprint #2
Vincular Caixa
ao Pick List
Painel de Rotas
Entrega 2
Releases
Sprint #3
Cancelar Vnculo
Entrega 3
Produto
O mesmo ocorre na Sprint 2 e na Sprint 3 com as funcionalidades Vincular Caixa ao Picklist,
Painel de Rotas e Cancelar Vnculo. no final de cada entrega, gera-se as entregas.3.4
Atividades prticas
Cenrios para realizao de uma Planning, incluindo: anlise de backlog, anlise de user
stories, quebra de stories em atividades, scrum poker e finalizao da Sprint.
Dividir os estudantes em equipes de 2 a 3 pessoas para eles planejarem uma Sprint.
58
Figura 3.9
Funcionalidades,
Sprints, Entregas e
Releases formando
o Produto.
4
objetivos
Scrum e a organizao
Entender como Ciclo PDCA e Scrum se complementam; Dicas gerenciais para Scrum;
Scrum e Governana
Scrum e o ciclo PDCA

Cada Sprint um bloco de iterao que segue um ciclo PDCA e entrega um incremento de
conceitos
Ciclo PDCA; Equipes distribudas; Recursos humanos, instalaes e PMO
funcionalidades prontas para serem incorporadas ao software. Um ciclo PDCA, tambm

conhecido como o crculo de Deming, um mtodo de gerenciamento iterativo de quatro
passos usado em gesto para o controle e melhoria contnua de processos e produtos.
Act
(Agir)
Do
(Fazer)
Check
(Checar)
Figura 4.1
Ciclo PDCA.
Em resumo, o ciclo tem quatro fases, que significam passos no processo de administrao. Quando aplicadas ao Scrum, elas podem ser perfeitamente correlacionadas s
aes de uma Sprint, conforme analogia a seguir:
11 Plan: essa a primeira fase do processo. Durante essa etapa, a equipe discute os objetivos, o processo e as condies claras de finalizao da Sprint (condies de aceitao).
Essa etapa define os objetivos mensurveis e realizveis para a equipe;
11 Do: a equipe trabalha em conjunto para atingir o objetivo fixado na fase de planejamento. A equipe trabalha com o conjunto de processos acordados;
Captulo 4 - Scrum e a organizao
Plan
(Planejar)
59
11 Check: uma vez que a entrega foi realizada, a equipe se rene e verifica a sada,
comparando-a com as condies acordadas de aceitao, decididas durante a fase de

planejamento. Os desvios, se existirem, so anotados. importante notar que essa
verificao se d no somente com relao ao produto entregue, mas tambm com
relao aos processos realizados;
11 Act: se qualquer desvio em tarefas planejadas foi observado durante a fase de verificao, a anlise de causa raiz deve ser conduzida. Brainstorms juntamente com a
equipe sero realizados para identificao das alteraes necessrias para evitar tais
desvios no futuro. A equipe tambm realiza brainstorms para entender mudanas
de ideias no processo, incluindo as mudanas de escopo e mtricas de medio que
podem resultar em um melhor processo ou produto no prximo ciclo ou iterao.
Assim, qualquer pessoa com um conhecimento bsico de Scrum pode correlacionar as
terminologias Scrum a essa abordagem cientfica.
11 Plan: planejamento da Sprint;
11 Do: Sprint engenharia real;
11 Check: Sprint Review;
11 Act: retrospectiva da Sprint.
O processo comea com um conjunto claro de metas e critrios de aceitao. No pode
haver mal-entendidos, o que ajuda a minimizar o desperdcio. O grupo sabe o que fazer
e ter orientao adequada para alcan-lo. A verificao das tarefas planejadas tambm
acontece em relao aos critrios de aceitao conhecidos. O processo ajuda a equipe a
fazer pequenas mudanas, obter feedback e seguir em frente. A inspeo e adaptao ajuda
a equipe a crescer. O cliente final provavelmente encontra-se satisfeito, porque pode ver a
sada rapidamente e pode fazer as mudanas com base nas condies de mercado.
Escalando projetos com Scrum

Muitos projetos requerem mais esforo do que uma nica equipe Scrum pode propor-
cionar. Nessas circunstncias, vrios grupos podem ser empregados. Trabalhando em

paralelo, os esforos dessas equipes podem ser coordenados atravs de uma variedade
de mecanismos diferentes, que podem ser formais em alguns e mais aleatrios 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 so chamados mecanismos de escala.
Cada projeto escalado tem suas prprias complexidades, cada um dos quais normalmente
exige sua prpria soluo nica e individual. Scrum escala do mesmo modo como qualquer
outro processo de desenvolvimento, utilizando praticamente os mesmos mecanismos de
escala, mantendo todas as prticas empricas que formam o seu ncleo.
O ncleo em torno do qual a escala ocorre a equipe Scrum. Um projeto com 800
60
pessoas ser composto por 100 equipes de 8 pessoas, ento a dificuldade encontra-se
em examinar como coordenar o trabalho dessas equipes, mantendo a produtividade de
cada equipe Scrum individual. Tambm importante examinar como dimensionar projetos,
independentemente do nmero de pessoas que envolvem, bem como o tipo de aplicao,
o tipo de sistema, o nmero de lugares em que o desenvolvimento precisa ocorrer e outras
dimenses de escala relevantes.
Infraestrutura
Antes de escalar qualquer projeto, uma infraestrutura adequada deve ser colocada em
prtica. Se um projeto vai empregar vrias equipes co-instaladas, um mecanismo para

sincronizar com frequncia o seu trabalho deve ser concebido e implementado. Alm
disso, um produto mais detalhado e a arquitetura tcnica devem ser construdos de modo
que o trabalho possa ser dividido entre as equipes. Se essas equipes esto distribudas
geograficamente, tecnologia de compartilhamento de cdigo-fonte, sincronizado constri
e comunicaes alternativas, tais como mensagens instantneas, devem ser empregados.
Demonstrar funcionalidade de negcios

permite a produo do
tipo de resultados que
o Product Owner e as
partes interessadas
tanto prezam desde o
incio, e ajudam o seu
engajamento e
envolvimento no
projeto.
Tudo o que suporta o esforo da escala deve ser concebido e implementado antes do escalonamento do projeto; todo esse trabalho feito em Sprints. Scrum exige que cada Sprint
produza um incremento de funcionalidade do produto potencialmente utilizvel, e esse
requisito pode ser cumprido se meses so necessrios para conceber e implementar uma
infraestrutura para escalar o projeto.
Na verdade, embora menos funcionalidade de negcio seja criada durante as Sprints iniciais
nas quais a infraestrutura ser criada, ainda necessrio demonstrar algumas funcionalidades de negcios no final. Na verdade, ainda mais importante faz-lo, porque isso
permite que a infraestrutura seja testada com o trabalho de desenvolvimento de funcionalidade medida que a mesma evolui.
Os requisitos no funcionais para construir a infraestrutura de escala so uma priori-
dade elevada no Product Backlog, porque devem ser concludos antes de escala em si.
Como a funcionalidade de negcios deve ser demonstrada no final de cada Sprint, esses
requisitos no funcionais so misturados com a funcionalidade de negcios de mais alta
prioridade. Se um pedao de funcionalidade de negcios depende de um requisito no
funcional, o requisito no funcional deve ser priorizado no Product Backlog para ser
desenvolvido antes ou em paralelo com a funcionalidade de negcios.
Staging
O processo de definio e priorizao dos requisitos no funcionais para escala chamado
de Staging. Staging ocorre antes do incio do primeiro Sprint e leva apenas um dia, durante
o qual os requisitos de escala para o projeto so determinados e colocados no Product
Backlog. Por exemplo, se voc est escalando o projeto para usar vrias equipes, os
seguintes requisitos no funcionais devem ser adicionados ao backlog do produto:
11 Decompor a arquitetura de negcios para suportar o desenvolvimento de interfaces
de vrias equipes;
11 Decompor a arquitetura de sistemas para suportar o desenvolvimento de interfaces
de vrias equipes;
11 Se necessrio, definir e implementar um ambiente para suportar diversas equipes
alocadas em ambientes distribudos.
Aps esses requisitos no funcionais para dimensionamento serem colocados no Product
Backlog, as Sprints podem comear. No entanto, apenas uma equipe pode iniciar seus trabalhos at a infraestrutura de escala estar no lugar, como no claro haver mecanismo para
coordenar o trabalho de vrias equipes no mesmo perodo.
Veja a figura 4.2 para uma representao do Product Backlog inicial com todos os requisitos no funcionais adequados para o tipo de Staging imaginado.
61
Equipe nica
Figura 4.2
Sprints de Escala.
Backlog do produto inicial

Requisitos funcionais
Requisitos no funcionais
Staged scalability requirements
The rest of the functional and
non-functional requirements
Vrias equipes
Backlog do produto
Requisitos funcionais
Requisitos no funcionais
O Product Owner e a equipe devem ficar juntos em uma reunio de planejamento da
Sprint e colaboram para selecionar uma combinao de requisitos funcionais e no funcionais. A equipe ento inicia Sprints e iteram tantas vezes quanto necessrio, at que
a infraestrutura para a encenao esteja no lugar. Nesse ponto, as reunies de planejamento das Sprints para cada uma das vrias 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 distribudas
H alguns anos, as equipes co-instaladas eram a norma: se tornou difcil encontrar uma
equipe distribuda geograficamente. Agora, o inverso parece ser verdadeiro: uma surpresa quando uma organizao tem toda a equipe trabalhando no mesmo edifcio. Com
a prevalncia de equipes espalhadas por todo o mundo, ou pelo menos atravs de fusos
horrios distintos, importante considerar quo bem Scrum funciona quando uma
equipe est geograficamente distribuda.
Um equvoco comum que Scrum no uma boa metodologia para uma equipe geograficamente dispersa. O argumento do Scrum pela preferncia por uma comunicao face
a face faz com que muitos pensem que escolher equipes distribudas seja m escolha.
62
Felizmente, esse argumento falso. Embora seja verdade que uma equipe local sempre
vai superar a equipe distribuda equivalente (Ramasubbu e Balan 2007), Scrum pode
realmente ajudar as equipes geograficamente distribudas.
Existem algumas regras do Scrum para equipes distribudas que veremos a seguir, e
dizem respeito basicamente forma com que as cerimnias devem acontecer e como
a equipe deve ser disposta. A razo para isso que uma diferena de fuso horrio
tem muito impacto sobre a forma como uma equipe trabalha. Na verdade, possui um
impacto muito maior do que a distncia geogrfica em si.
Reunio de planejamento da Sprint

Existem basicamente duas abordagens que podem ser utilizadas para o planejamento
da Sprint. As estratgias podem ser referenciadas pelos seus nomes descritivos: a teleconferncia longa e duas teleconferncias. A seguir, analisamos as vantagens e desvantagens de cada uma dessas abordagens.
Teleconferncia longa
a abordagem padro seguida pela maioria das equipes, e consiste em ligar para um
nmero de teleconferncia e conduzir a reunio de planejamento normalmente,

Tabela 4.1
A teleconferncia
longa.
simulando o formato de reunio pessoal. Todo o trabalho de uma reunio de planejamento de Sprint regular realizado nessa reunio. Quando ela se encerra, a Sprint deve
estar completamente planejada como se a equipe fosse local.
Vantagens
Desvantagens
Pode levar a boas discusses se todos se

mantiverem engajados
Participantes podem se distrair em uma ligao to longa
O planejamento da Sprint pode se encerrar

em um dia
S funciona quando h muitas horas em comuns no dia de

trabalho na equipe geograficamente dispersa
consistente com a abordagem utiliza em

equipes co-localizadas
Pode significar estender o dia de trabalho em uma ou mais

localidades
Duas teleconferncias
Para algumas equipes, simplesmente impraticvel planejar a reunio de planejamento
da Sprint em uma teleconferncia: a separao de fusos horrios muito grande para

proporcionar sobreposio suficiente nos dias de trabalho. A prxima abordagem de planejamento do Sprint, duas chamadas, divide a reunio atravs de dois telefonemas realizados em dias consecutivos. Substituir a sesso inicial de oito horas por duas sesses de
quatro horas separadas, realizadas em dias consecutivos, mais prtico.
Normalmente, a primeira sesso se concentra em identificar as principais tarefas, resultados e dependncias de alto nvel. Ela tem como foco discutir as expectativas e prioridades
mais altas do Product Owner. Durante a segunda sesso, cada membro da equipe define as
atividades e fornece estimativas para cada tarefa que ele aceite. Seu foco sincronizar os
compromissos de cada equipe individual com os quais pode se comprometer.
Vantagens
Desvantagens
Pode ser uma forma mais eficiente de se

usar o tempo
Esse senso de utilidade pode variar grandemente,

dependendo de como a equipe est distribuda
Pode ser usada mesmo quando h

poucas horas em comum nos dias de
trabalho na equipe
Como muitas discusses acontecem entre as equipes, nem

todo o conhecimento compartilhado com a equipe global,
o que pode levar a mal-entendidos
No se completa em um dia.
Tabela 4.2
Duas
teleconferncias.
63
Daily Scrum
A Scrum diria introduz um conjunto de novos desafios em relao reunio de pla-
nejamento da Sprint em equipes geograficamente dispersas. Como o Scrum dirio

uma reunio diria de 15 minutos, a sua realizao no representa um problema para
equipes com dias de trabalho que se sobrepem, mas so um problema, no entanto,
para equipes amplamente distribudas sem sobreposio em horas de trabalho. Realizar
chamadas dirias em uma hora em que voc normalmente no est trabalhando no
sustentvel a longo prazo. Existem basicamente trs mtodos que podem ser usados
para as Scrums dirias nessas situaes: uma conferncia nica, reunio escrita e
reunio regional. Veremos as vantagens e desvantagens de cada uma delas a seguir.
Teleconferncia nica
Talvez a abordagem mais comum e aquela que inicialmente tentada pela maioria das
equipes fazer com que todos os participantes da equipe entrem juntos em um nico
telefonema. Para as equipes coincidindo em fusos horrio uns dos outros, essa uma
excelente abordagem. Infelizmente, a abordagem se deteriora rapidamente quando o
nmero de fusos horrios aumenta. Eventualmente, as equipes mais amplamente
Tabela 4.3
Teleconferncia
nica.
distribudas rapidamente entendem ser necessria uma estratgia diferente para as

suas Scrum dirias.
Vantagens
Desvantagens
Similar abordagem usada em equipes locais,

ento nada novo precisa ser mudado
Pode ser inconveniente para membros da

equipe
Discusses envolvem toda a equipe
No sustentvel se as pessoas precisam realizar ligaes fora de seus horrios de trabalho
Todo mundo aprende todas as pendncias, o que leva a

maior aprendizagem da equipe e um comprometimento de
uma abordagem compartilhada
Reunio escrita
Para minimizar o trabalho de horas de telefonemas para alguns locais, algumas equipes
abandonam reunies dirias completamente. No entanto, sem querer desistir do valor

da comunicao diria inteiramente, tais equipes normalmente substituem reunies
dirias por uma verso escrita da reunio.
Os membros da equipe concordam em enviar um e-mail, atualizar uma pgina de wiki ou
fazer uma entrada em outra ferramenta de colaborao assncrona em que fornecem as
mesmas informaes que eles compartilhariam em um telefonema. Uma variao dessa
abordagem a realizao de uma chamada de telefone em um momento que seja conve-
niente para o maior nmero de membros da equipe, com outros membros da equipe par-
64
ticipando atravs da apresentao de um relatrio escrito. Isso particularmente comum

quando a maioria da equipe est localizada apenas com alguns membros remotos.
Normalmente, essa abordagem no indicada como tcnica primria, mas pode ser
usada para completar chamadas dirias, se a equipe decide que elas esto acontecendo
demasiadamente, esto prejudicando a equipe que est trabalhando fora da sua hora de
trabalho normal e, por isso, precisa reduzir a sua frequncia.
H caractersticas importantes de uma Scrum diria que so perdidas quando a
chamada transformada em uma atualizao diria escrita. Por exemplo, o compromisso assumido parece mais forte quando um membro da equipe diz: Eu vou fazer isso
hoje, do que quando as mesmas palavras so escritas. Talvez isso seja porque a
Tabela 4.4
Reunio escrita.
mensagem falada um compromisso assumido na frente dos prprios colegas de

trabalho, enquanto a mensagem escrita um compromisso feito em privado.
Vantagens
Desvantagens
Sustentvel a longo prazo
Problemas no so discutidos e podem ficar adormecidos

por dias
Ajuda a resolver problemas de linguagem,

incluindo sotaques
No h realmente garantias de que as atualizaes escritas vo

ser lidas
Os membros da equipe tendem a se importar menos com as
responsabilidades que os outros assumiram no dia anterior
Reunies regionais
A terceira e ltima abordagem para a reunio de Scrum diria ter um conjunto de reu-
nies regionais seguidas por algum esforo para compartilhar a questes-chave de cada
uma dessas reunies. Se uma equipe dividida em duas cidades muito distantes, por
exemplo, cada cidade pode ter sua prpria reunio diria.
Esse seria o caso, por exemplo, para uma equipe com membros em escritrios da
empresa em So Francisco, nos EUA, e Londres, na Inglaterra, que possuem intervalos
de horas de diferena.
s vezes, uma equipe distribuda tem alguns escritrios com sobreposio de horas de
trabalho, alm de um escritrio mais remoto nesses casos, os locais com horrios sobrepostos podem ter um Scrum dirio, j a localizao mais remota teria sua prpria reunio.
As reunies regionais, se todo mundo est presente em um escritrio, ou de discagem em
uma chamada entre as diversas cidades, so, ento, geralmente seguidas por uma comunicao adicional, de modo que cada equipe est consciente do trabalho das outras equipes.
Uma maneira de realizar essa comunicao um telefonema com pelo menos um
representante de cada equipe.
Vantagens
Desvantagens
Reduz grandemente o estresse de trabalho

em horas extras
Informao de uma reunio para outra pode estar incorreta

ou incompleta, nem compartilhada na hora necessria
Permite o compartilhamento de informao

chave em equipes locais
Pode levar para um sentimento de ns e eles entre

equipes diferentes
Nem todos se encontram presentes para todas
as discusses
Tabela 4.5
Reunies regionais.
65
Szcrum of Scrums
O Scrum dos Scrums usado por vrias equipes para coordenar seu trabalho. Envolve
um representante de cada equipe, e acontece geralmente duas ou trs vezes por

semana. A frequncia reduzida dessa reunio a torna menos problemtica para uma
equipe distribuda. Essa reunio dura quase sempre uma hora ou menos; portanto, uma
equipe distribuda com qualquer sobreposio de horas em sua jornada de trabalho ser
capaz de facilmente program-la.
Os desafios surgem, naturalmente, quando a equipe to amplamente distribuda que se
torna impossvel compartilhar horrios de trabalho comuns. Nesses casos, recomenda-se
que as equipes usem uma das estratgias anteriores para o Scrum, como chamada nica
diria ou reunies regionais. Quando um nmero reduzido de equipes est envolvido, uma
nica reunio geralmente suficiente, j que os participantes da reunio podem encontrar
algum tempo que ser minimamente inconveniente para pessoas suficientes.
Isso mais fcil de fazer do que para o Scrum dirio por duas razes: primeiro, a
maioria dos Scrum dos Scrums no so dirias e, em segundo lugar, a maioria das
equipes, ocasionalmente, mudam quem participa dessas reunies.
Sprint reviews e retrospectivas

Revises de Sprint e retrospectivas compartilham caractersticas tanto das Scrums
dirias quanto das reunies de planejamento da Sprint. Assim como reunies de planejamento de Sprint, essas reunies no so realizadas diariamente, ento membros da
equipe se sentem mais disponveis para participar fora do horrio normal de trabalho.
No entanto, assim como as daily Scrums, revises de Sprint e retrospectivas so um pouco

mais fceis de planejar, porque elas so mais curtas do que uma reunio de planejamento do
Sprint. Isso faz com que a tarefa de encontrar um momento certo adequado para a reunio
seja relativamente fcil, j que equipes com sobreposio de horas de trabalho agendam essas
reunies durante a parte sobreposta de seus horrios. Equipes cujas horas de trabalho quase
se sobrepem normalmente agendaro essas reunies no final de um dia de trabalho para
uns e no incio para outros.
Dicas gerenciais
Alguns pontos finais a considerar em equipes virtualmente discretas so os que seguem:
11 Decida como distribuir as equipes: uma equipe colaborativa em uma localidade ou
equipes deliberadamente distribudas;
11 Tente criar coerncia;
11 Entenda as diferenas culturais significativas
11 Entenda as diferenas culturais pequenas;
66
11 Fortalea as culturas funcionais e de equipe;

11 Comunique e estabelea uma viso compartilhada;
11 Construa confiana ao enfatizar o progresso desde o comeo do projeto;
11 Tente se reunir presencialmente;
11 Encoraje a comunicao lateral.
Se tanto a reviso e a
retrospectiva foram
curtas, alguns membros
da equipe podem
preferir agend-las uma
logo aps a outra.
Outras equipes podem
preferir agend-las um
dia logo aps o outro.
Coexistindo com outras abordagens

Uma coisa olhar para o desenvolvimento gil de software em um tubo de ensaio; outra
experiment-lo no mundo real. No tubo de ensaio, metodologias geis como o Scrum

so facilmente adotadas por todos os membros, e as realidades da poltica corporativa,
economia, e no podem intrometer. No mundo real, contudo, todas essas questes
desagradveis no existem. Raramente simples tomar a deciso de utilizar Scrum e,
em seguida, ser capaz de faz-lo sem outras restries.
Por exemplo, um projeto pode tentar Scrum desde que isso no interfira na certificao
CMMI Nvel 3 da organizao. Outro projeto pode tentar experiment-lo enquanto ele
est na reviso preliminar de arquitetura e, em seguida, tem uma reunio para aprovar
o design.
Pode haver razes vlidas para uma organizao para colocar essas restries sobre os
projetos. Nesta sesso, estudaremos como um projeto Scrum afetado quando se cruza
com um processo sequencial. A seguir, consideramos o impacto da governana do projeto
e como projetos Scrum podem coexistir com sucesso com abordagens de governana no
geis. Finalmente, vamos explorar maneiras projetos Scrum podem cumprir com normas
como a ISO 9001 ou CMMI.
Misturando Scrum e desenvolvimento sequencial

Poucas organizaes de grande porte desfrutaro do luxo de fazer todos os seus pro-
jetos com Scrum. A maioria ser obrigada a suportar um perodo em que alguns projetos
foram transferidos para Scrum, enquanto outros ainda no. Isso pode ser porque seria
muito perturbador para a transio de toda a empresa de uma s vez, porque seria
perturbador para fazer uma mudana processo no meio do curso para um projeto particular, ou qualquer nmero de outras razes.
So basicamente trs os cenrios onde essa mistura pode acontecer:
11 Sequencial a princpio: a confluncia de Scrum e desenvolvimento sequencial no
incio do projeto geralmente ocorrem quando uma organizao tem obstculos de
aprovao do projeto. Livrar-se desses obstculos requer geralmente que a equipe
Scrum anule qualquer pendncia em relao aos documentos e crie uma especificao, plano de projeto ou outro artefato que necessrio para aprovao. Depois
que um projeto em cascata for aprovado, ele executado como um projeto normal
de Scrum;
11 Sequencial no final: quando as caractersticas de Scrum e sequenciais se encontram
no fim do projeto, geralmente dizem respeito s fases de teste. s vezes, essa conflutestadores ou a garantia de qualidade como um grupo separado que se engajou no
final para verificar e validar o produto. Outras vezes, a caracterstica sequencial no
final ocorre quando h um link externo para um grupo de operaes, 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 mximo de Scrum quanto possvel, mesmo no final. Em
outras palavras, a equipe continua a trabalhar em sprints, realizar reunies de planejamento sprints, tm reunies dirias, e assim por diante;
ncia ocorre porque a organizao s abraou o Scrum tentativamente, e deixou os
67
11 Sequencial no meio: a maneira mais complicada em que Scrum tem de interagir com
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 coordenao do trabalho e a comunicao frequente so geralmente as principais
fontes de problemas quando essa disposio existe. A equipe sequencial prefere se
comunicar por meio de reunies e documentos que bloqueiam a interface, enquanto
a equipe Scrum vai preferir deixar interfaces mais vagas e eleger uma comunicao
informal, com interfaces e compromissos definidos de forma progressiva. A equipe
Scrum que se encontra nessa situao geralmente acha til atrair os gestores dos
projetos sequenciais para participar de reunies de planejamento do Sprint e para as
reunies dirias.
Governana
Uma das razes pelas quais muitas organizaes adotam uma abordagem sequencial
para o desenvolvimento de software o encaixe natural entre uma sequncia definida,

as fases de desenvolvimento e a necessidade de superviso do projeto. O objetivo da
superviso do projeto, comumente chamado de governana, certificar-se de que um
projeto no vai se extraviar. Governana eficaz do projeto pode, por exemplo, identificar
um projeto que vai exceder seu oramento, levando a conversas sobre se o projeto deve
ser cancelado.
Governana tambm pode identificar um produto que est deriva muito longe de seus
objetivos originais, um projeto que est a se desviar de um padro arquitetural ou qualquer
nmero de consideraes de alto nvel similares importantes para a organizao.
A equipe de software pode encontrar portas ou pontos de verificao de governana em
uma variedade de situaes:
11 Uma anlise precoce de seus planos para o escopo, oramento e cronograma;
11 A reviso de decises de arquitetura e design;
11 Uma reviso quando o aplicativo est pronto para o sistema ou teste de aceitao
do cliente;
11 Uma reviso quando o produto pode ser entregue a uma organizao 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 no so adequados para o trabalho feito de forma iterativa.
O primeiro passo para conciliar a necessidade de governana do projeto e o desejo de
usar Scrum perceber que a governana do projeto e gerenciamento de projetos no

so a mesma coisa. No um problema separar a governana do projeto e a sua gesto.
68
Ao separ-los, na verdade estamos permitindo equipe alcanar a capacidade de ter pontos

de controle de alto nvel para fornecer a superviso necessria, permitindo ainda a liberdade de gerir a si mesmo e ao projeto de forma gil.
Passos para rodar o projeto Scrum com governana no gil:
1. Negocie e deixe claro quais so as expectativas desde o princpio.

2. Ajuste os seus relatrios s expectativas atuais.
3. Convide os membros do comit de governana para o processo Scrum.
4. Nada convence como sucesso quando obtiver sucesso, referencie o sucesso.
Conformidade a padres
Nem todas as equipes ou mesmo departamentos de desenvolvimento de software tm
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 Nvel 5, o que requer que os desenvolvedores
de software sigam algumas das melhores prticas estabelecidas.
Alm disso, alguns produtos de software so entregues em setores regulados e cumprem
com normas como a ISO 9001.
Nenhum desses padres prescreve um ciclo de vida que contraditrio como o Scrum.
Como cumprir normas na organizao raramente opcional, equipes Scrum devem preocupar-se com a melhor forma de cumpri-las, comeando em alguns casos com a questo de
saber se isso vai ser possvel com um processo Scrum. Nesta sesso, vamos estudar como
equipes de Scrum podem ficar em conformidade com ISO 9001 e CMMI, dois dos padres
mais comuns com que Scrum precisa coexistir. A partir deles, podemos generalizar algumas
estratgias de enfrentamento em outras situaes de conformidade.
ISO 9001
A Organizao Internacional de Normalizao (ISO) mantm o padro 9001, que normal-
mente designado em sua inteireza como ISO 9001:2000 ou ISO 9001:2008, ambos os
quais indicam o ano de uma verso especfica do padro. A certificao ISO 9001 no se
destina a garantir que os produtos de uma organizao atinjam um nvel de qualidade
especfico. Em vez disso, a certificao indica que a organizao segue um conjunto de
prticas formais no desenvolvimento de seus produtos. Uma grande parte do esforo
em conformidade com a ISO 9001 a criao de um sistema de gesto da qualidade, que
geralmente um longo documento ou conjunto de pginas da web que descrevem as
prticas de qualidade seguidas pela organizao.
Primavera Systems, desenvolvedora de sistemas de gerenciamento de projetos e portflio,
criou o seu sistema de gesto da qualidade ao longo de um perodo de dez meses.
workshop incluiu uma representao multifuncional dos desenvolvedores. Primavera
j tinha experincia substancial com prticas geis no momento em que iniciou o seu
esforo ISO 9001.
Em tal ambiente, seria natural para os funcionrios se preocuparem com a perda de agilidade com a introduo de ISO 9001. Bill McMichael, da Primavera, e Marc Lombardi, um
consultor com experincia em ISO 9001, trabalharam juntos por iniciativa e chegaram
concluso de que a documentao no diminuiu a sua agilidade. O mantra foi prover
apenas documentao suficiente e referncias que fossem realmente teis para ajudar
com a garantia do processo que j existisse.
A empresa realizou 30 oficinas para documentar seus processos existentes, e cada
69
CMMI
Desde que o primeiro projeto gil surgiu do lodo primordial, as empresas tm se pergun-
tado se as metodologias geis so compatveis com o Capability Maturity do Instituto de

Engenharia de Software Model Integration (CMMI). Como medida de algumas maneiras
de quanto processo de uma organizao tem (ou pelo menos como muito do que tem
sido definida), o CMMI e seu antecessor, o Capability Maturity Model Software (SWCMM), so muitas vezes vistos como formas de pesos pesados de desenvolvimento de
software e a anttese do desenvolvimento gil.
A incorporao de Scrum em um 5 processo CMMI Nvel mostra uma soluo para um
problema comum com implementaes do CMMI. Ao prosseguir com um nvel CMMI
particular, muitas organizaes se esquecem de que o objetivo final melhorar a forma
como eles constroem software (e, presumivelmente, portanto, quais os produtos vo
entregar), em vez de tornar-se com focos em preencher deficincias supostas acordo
com a documentao CMMI sem a preocupao de saber se as mudanas vo melhorar
o processo ou os seus produtos. Esse problema pode ser eliminado quando as metas do
CMMI so combinadas com o valor concentrado na mentalidade inerente Scrum, de
entregas constantes. O Scrum garante que os processos esto implementados eficientemente e o CMMI garante que todos os processos relevantes esto considerados.
Conseguindo conformidade
De maneira geral, conseguimos estabelecer que Scrum compatvel com ISO 9001 e
CMMI, tanto teoricamente quanto empiricamente. Para tornar Scrum conforme a sua
organizao, um passo a passo pode ser seguido:
1. Coloque esforo suficiente no Product Backlog.
2. Tente deixar o Product Backlog conforme padres previamente existentes
na organizao.
3. Considere o uso de checklists.
4. Automatize testes e a gerao de builds.
5. Use uma ferramenta de gerenciamento de projetos geis.
6. Mova-se devagar, mas de forma estvel.
7. Trabalhe com seu auditor no processo ao qual voc deseja ficar conforme.
8. Traga ajuda externa, se necessrio, como um Scrum Master.
Recursos humanos, instalaes e o PMO

Para alcanar o sucesso a longo prazo com Scrum, as implicaes de se tornar gil
devem ser transferidas para outras partes da organizao. Quando isso no for feito,
gravidade organizacional ou seja, as influncias organizacionais que formaram a orga Fundamentos do Scrum
nizao no formato em que ela estava antes do incio da transio se inicia. Transies
70
Scrum j foram interrompidas ou completamente paradas porque ignoraram o impacto

de se tornar geis em grupos de fora do desenvolvimento. Isso resulta em situaes
como essas:
11 Recursos humanos: equipes Scrum comeam a fazer muito bem at que chega o
tempo de reviso anual. De repente, todo mundo percebe que eles sero novamente
avaliados e a receber aumentos, com base exclusivamente no desempenho individual. A reviso anual pode ter um campo para avaliar se um indivduo se d bem com
os outros, mas no final do dia contribuies e o herosmo individual o que importante em termos de aumentos e promoes. impossvel pensar em adotar um processo fundado sobre uma preferncia por indivduos e interaes sobre processos
e ferramentas sem envolver o departamento de recursos humanos. Na organizao
tpica, esse grupo pode ter ainda mais influncia sobre como as pessoas percebem
seus trabalhos e atuar neles do que os gerentes funcionais desses indivduos;
11 Instalaes: muito mais fcil ser gil quando toda a equipe est no mesmo local.
Mas quando um grupo de instalaes torna to tudo mais difcil, ou quando se
impede que as equipes Scrum usem o espao da parede para os grficos de manejo
e outros dados importantes do projeto, as equipes se tornam desmoralizadas.
Torna-se mais difcil manter o impulso de se tornar melhor em Scrum quando
parece que todo mundo est contra. O ambiente fsico em que trabalhamos tem
uma influncia direta sobre ns. Considere as mensagens conflitantes enviadas
quando uma empresa proclama as pessoas so nosso maior patrimnio, enquanto
o conjunto de instalaes probe pendurar grficos de burndown nas paredes. A
verdadeira mensagem alta e clara:
As paredes so 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 organizao com Scrum. O PMO responde convencendo gerncia do departamento que no tem problemas com Scrum, desde que ele seja complementado por
um conjunto de documentos e prticas. O PMO muitas vezes tem um enorme peso
poltico e experincia do projeto. Ao conseguir que essa parte da organizao esteja
de acordo com Scrum, no s se evita uma possvel fonte de resistncia, mas tambm
se beneficia da sua experincia. Os membros do PMO podem se tornar guardies de
auto-organizao, melhoria contnua, propriedade, comunicao, experimentao,
colaborao e outros valores.
Quando Scrum erroneamente encarado apenas como uma mudana 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 comeou. possvel
ignorar as implicaes do Scrum sobre esses grupos e ser bem-sucedido, por algum
tempo. Eventualmente; porm, ser necessrio envolver com eles para criar uma tran-
fcil ver os recursos humanos, instalaes e do escritrio de gerenciamento de projeto

como obstculos a serem superados. Uma abordagem mais produtiva ver cada um
como um aliado para ser inscrito. Embora uma relao conflituosa possa funcionar por um
tempo, o sucesso a longo prazo requer o apoio de toda a organizao. O caminho para se
tornar gil pode ser longo; quando for possvel, melhor fazer amigos, em vez de inimigos.
sio bem-sucedida, a longo prazo.
71
Atividades
Cada Sprint um bloco de iterao que segue um ciclo PDCA e entrega um incremento de
funcionalidades prontas para serem incorporadas no software. Um ciclo PDCA, tambm
conhecido como o crculo de Deming, um mtodo de gerenciamento iterativo de quatro
passos usado em gesto para o controle e melhoria contnua de processos e produtos.
72
Rodrigo Alves Costa atualmente

professor efetivo do curso de Cincias
da Computao da Universidade Estadual da Paraba e doutorando em Cincias da Computao na Universidade
Federal de Pernambuco (UFPE). Possui
mestrado em Cincias da Computao
pela UFPE (2010), MBA em Gerenciamento de Projetos pela
Fundao Getlio Vargas (2007) e graduao em Cincias da
Computao pela UFPE (2005). certificado Project Management Professional (PMP) pelo Project Management Institute
(PMI) (2006). Tem vasta atuao profissional, destacando-se
em funes como executivo de projetos, analista de sistemas, engenheiro de sistemas, de segurana e de software
em empresas como IBM, Siemens, Motorola e C.E.S.A.R.
Tambm autor de livros na rea de administrao organizacional com foco em projetos, entre os quais Gerenciamento de Projetos de TI, e colaborador de cursos de gesto
empresarial em tecnologias da informao e comunicao
em diversas organizaes e instituies de ensino, sendo
um dos idealizadores do currculo de governana da Rede
Nacional de Pesquisa, vinculado ESR/RNP/CNPQ. Foi bolsista CNPQ durante o mestrado e a graduao (PIBIC), e atualmente est vinculado aos diretrios de pesquisa da
entidade, no grupo de estudos em Segurana Computacional da UFPE. Pesquisador na rea de Cincia da Computao, com nfase em segurana computacional e teoria da
computao, e na rea de Gerenciamento de Projetos, com
nfase em gerenciamento de projetos virtuais e planejamento estratgico orientado por TIC. membro entusiasta
do PMI, membro da Association for Computing Machinery
(ACM) e da Sociedade Brasileira de Computao (SBC).
LIVRO DE APOIO AO CURSO
O curso aborda os principais conceitos do Scrum, apresentando aos alunos os fundamentos do gerenciamento
de projetos geis, as vantagens e desvantagens da utilizao desta metodologia de trabalho e como o processo
de transio para esta prtica ocorre nas organizaes.
dologia Scrum, compreendendo seus processos, papis,
entregas acontecem.

Fundamentos Do Scrum

Încărcat de

Informații document

Titlu original

Drepturi de autor

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Fundamentos Do Scrum

Încărcat de

Drepturi de autor:

Fundamentos

Rodrigo Alves Costa

A RNP Rede Nacional de Ensino

Programa Interministerial RNP,

Rodrigo Alves Costa

Copyright 2016 Rede Nacional de Ensino e Pesquisa RNP

Jos Luiz Ribeiro Filho

Escola Superior de Redes

Leandro Marcos Oliveira Guimares

Edson Kowask Bezerra

Equipe ESR (em ordem alfabtica)

Reunio de planejamento da Sprint (Planning Meeting)38

Crise do Software. Processos geis e Motivao. Processos peso-pesado e transio

A importncia da informao e a crise do software

e oportunidades para a expanso e retrao do seu negcio, e que alimenta o processo

mudana e o aperfeioamento, propiciando o conhecimento necessrio para a tomada

Marcelo Costa, autor do livro Gesto Estratgica da Informao, significa a ao

de dados que cresam medida que a informao se transforma e se torna disponvel e

um problema leve, e agora temos computadores gigantescos, a programao tornou-se um

problema igualmente gigantesco.

As causas da crise do software esto ligadas complexidade geral do hardware e o pro-

cesso de desenvolvimento de software. A crise manifesta-se de vrias maneiras:

Por que se tornar gil vale a pena?

qualidade que atende s necessidades do usurio mais rapidamente e a um custo menor

no s por parte dos desenvolvedores, mas de toda a organizao. No se trata apenas de

As melhores prticas so arriscadas: como a maior parte de toda e qualquer

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

todas as caractersticas so do mesmo tamanho.

publicados at 2016, mostrada na tabela 1.1, h um aumento mdio de produtividade de

custos para os seus projetos.

Uma razo pela qual os

Time to Market mais rpido

Melhoria na satisfao das partes interessadas

Figura 1.2 Projetos

Alm disso, juntamente com a capacidade de mudar mais facilmente as prioridades, as

O que as organizaes tm feito no funciona

obtidos at determinado ponto, selecionar fatores de interesse da organizao e fazer

lCrie cartes para

O esqueleto de processo funciona da seguinte maneira: no incio de uma iterao, a

sidera a tecnologia disponvel, e avalia as suas prprias habilidades e capacidades. Em

Papis, fluxo e artefatos do Scrum

nibilidade. O Product Owner responsvel por se comunicar continuamente com o

civel. A equipe de desenvolvimento responsvel por se auto-organizar para

O Product Owner responsvel por garantir o financiamento do projeto e por entregar a

Selected Product Backlog

Backlog do Produto: Emergente,

scrum e so descritos a seguir.

listados no Product Backlog. O Product Owner responsvel pelo contedo, priorizao

Registrar requisitos na base de dados

Processar cenrio de saque simples

Aprovao de crdito muito lento

Clculo de comisso de venda

Captura de venda em ponto de venda

Processar cenrio de crdito PMT

Horas de trabalho restantes por dia

Incremento potencialmente utilizvel de funcionalidade de produto

Scrum est por trs do desenvolvimento de software complexo.

resultados so efmeros, consistindo apenas de sinais que controlam mquinas de estado.

resolver os problemas adaptativos complexos, ao mesmo tempo em que o realizam de

limites aceitveis e que o produto resultante ser inaceitvel, o processo ou o material a

Scrum e processos de desenvolvimento

Introduzindo um processo gil em uma organizao

os indivduos e as interaes que os processos e as ferramentas, trabalhar mais no

combinao de ceticismo, entusiasmo e otimismo cauteloso. Outros desenvolvedores,

Realizando a transio de um processo peso-pesado

Um nmero surpreendente de desenvolvedores enxerga o uso de um mtodo gil