Apostila PM 83 F17.3.6

Conhea mais da Caelum.
Cursos Online
www.caelum.com.br/online
Casa do Cdigo
Livros para o programador
www.casadocodigo.com.br
Blog Caelum
blog.caelum.com.br
Newsletter
www.caelum.com.br/newsletter
Facebook
www.facebook.com/caelumbr
Twitter
twitter.com/caelum
Sumrio
1 Viso geral de agilidade 1

1.1 O que agilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 O que ligamos com agilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Sobre o curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Rumo agilidade 3
2.1 De onde viemos: Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Dinmica: comunicao indireta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 De onde viemos: RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 O que agilidade 11
3.1 Agilidade e o Manifesto gil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 O que um projeto de sucesso? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Vantagens da agilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Mitos e verdades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Overview de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Agilidade com Lean 17

4.1 O Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Exerccio: Lean Lego Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Sobre Lean: o mtodo Toyota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Push vs. Pull Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Systems Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7 Work Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8 Kaizen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 O framework Scrum 25
5.1 Histria do Scrum: adaptando Lean ao desenvolvimento de software . . . . . . . . . . . . 25
5.2 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Iteratividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Interaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5 Gerncia de time auto-gerencivel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6 Time-Boxes 31
6.1 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2 Durao de um Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
i
6.3 Quando sobra ou falta tempo no Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4 Planning meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.5 Review meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.6 Definio de pronto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.7 Na prtica: Demora no feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8 Retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.9 Daily scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7 Artefatos do Scrum 43
7.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Histrias e tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Exerccio prtico: criao de histrias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.4 Priorizando bem um Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.5 Na prtica: mudando o product backlog a qualquer instante . . . . . . . . . . . . . . . . . 49
7.6 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.7 Sprint Burndown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.8 Alternativas aos artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8 As pessoas no Scrum 55
8.1 O Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2 No h culpados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.3 Eles so pessoas! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.4 Time auto-gerenciado e os papis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.5 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.6 O P.O. parte do time? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.7 O dia-a-dia do Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.8 Problemas e impedimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.9 Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.10 O dia-a-dia do Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.11 Desenvolvedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.12 O dia-a-dia dos desenvolvedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.13 Gerncia de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9 Praticando Scrum 67
9.1 Scrum Lego Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
10 Scrum no mundo real 69

10.1 Migrao: medos e questes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
10.2 Problemas clssicos de cada papel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
10.3 Penalidades ldicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
10.4 Quando adaptar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
ii
10.5 Consultoria em desenvolvimento com scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.6 Discusso em sala: quais problemas voc j enxerga na adoo para seu time? . . . . . . 74
11 eXtreme Programming 75
11.1 Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
11.2 Prticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
11.3 Ferramental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.4 Mais mtricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
12 O que vem a seguir? 83

12.1 Leituras e pessoas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.2 Certificaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
ndice Remissivo 84
Verso: 17.3.6
iii
Captulo 1
Viso geral de agilidade
A coisa mais incompreensvel sobre o mundo que ele todo compreensvel.

Albert Eistein
1.1 O que agilidade

Adaptado da Wikipedia: "Agilidade a capacidade de executar movimentos rpido e ligeiros com mudan-
as nas direes necessrias para atingir um objetivo.
Isso quer dizer que rapidez diferente de agilidade e que, portanto, desenvolvimento gil diferente de
desenvolvimento rpido de aplicaes. A agilidade est em garantir a qualidade de forma que consiga
desviar ou resolver os problemas no meio do caminho.
Se todos conseguem desviar dos problemas, ento no h a necessidade de um gerente tradicional: o

time se auto-gerencia. A funo do gerente num time gil mais corporativa, lidar com burocracia.
Aqui, veremos muito do auto-gerenciamento, que marca registrada dos times realmente geis - como
alcan-lo e de que ele consiste.
1.2 O que ligamos com agilidade

Quando abordados sobre o que agilidade, a maior parte de ns pensa rapidamente em diversas carac-
tersticas como eficincia, flexibilidade, rapidez, valor, dinamismo, pessoas, comunicao e foco.
Tudo isso est de alguma maneira ligado ao meio que desenvolvemos nosso projeto e, consequente-
mente, metodologia.
1.3. Sobre o curso
Todas essas caractersticas aparecero durante o curso, como por exemplo quando a eficincia estar
diretamente ligado com a diminuio do trabalho desnecessrio, caractersticas extradas do Kaizen.
Ao mesmo tempo, a flexibilidade, capacidade de se adaptar as mudanas necessrias, resulta de no se

antecipar e preparar a priori o que achamos que ser utilizado posteriormente.
Atravs de mtodos geis, de meios geis, podemos alcanar maior rapidez, mas no uma verdade
absoluta. Rapidez entregar mais rpido, mais cedo. Como quebramos pedaos pequenos que entregam
valor para nosso cliente, ele mais rapidamente poder utilizar o sistema - e cada vez mais.
As entregas so feitas mais rapidamente, mas o projeto no termina necessariamente mais cedo.
1.3 Sobre o curso

Nesse curso, vemos os problemas que os processos tradicionais de projetos apresentam, o desenvolvi-
mento de novas formas de gerenciamento que resolvem aqueles problemas antigos. O Scrum terico, o
prtico, as adaptaes do mundo real e um pouco de engenharia de software, sem a qual a agilidade se
torna invivel.
Tudo contando com a experincia da Caelum e de parceiros em projetos geis.
Mas, durante todo o processo, o enfoque no auto-gerenciamento, porque toda a agilidade est intrin-
secamente baseada nele.
1.4 Bibliografia
Bibliografia recomendada para ingressantes no mundo da agilidade e do Scrum:
Agile Software Development with Scrum, Ken Schwaber
Scrum and XP from the Trenches, http://www.infoq.com/minibooks/

scrum-xp-from-the-trenches, Henrik Kniberg
Scrum Guide, http://www.scrum.org/scrumguides/, Ken Schwaber
Outras fontes de informao frequentemente atualizadas so blogs e listas de discusso:
Blog da Caelum, http://blog.caelum.com.br
Lista brasileira sobre mtodos geis: http://br.groups.yahoo.com/group/agile-brasil/
Lista brasileira sobre Scrum: http://br.groups.yahoo.com/group/scrum-brasil/
Agile no Mundo Real, http://agilenomundoreal.wordpress.com, Guilherme Silveira
2
Captulo 2
Rumo agilidade
Ns criamos a verdade, no a descobrimos.

Friedrich Nietzsche
Prticas e metodologias geis surgiram em resposta a problemas recorrentes no gerenciamento de proje-

tos de software que vinham acontecendo j h bastante tempo. Projetos atrasando, clientes insatisfeitos...
Em suma, dinheiro gasto sem retorno para o cliente.
Computao uma cincia nova e, com isso, muitas de suas tcnicas e processos foram espelhados das
engenharias mais antigas e adaptados realidade da produo de software.
Ficam algumas questes. Ser que as tcnicas h muito estabelecidas na construo civil so adequadas
na produo de sistemas? E ser que as expectativas de clientes de software so parecidas com s de
compradores de casas?
2.1 De onde viemos: Waterfall

Inspirado nas fases e processo da construo civil, o Waterfall um processo de gerenciamento de
software que foi documentado pela primeira vez em 1970 no paper de Winston W. Royce.
Nele, o autor descreve, j com ressalvas, o modelo waterfall, ou cascata, que ainda hoje frequentemente
adotado como padro em fbricas de software outras empresas, onde, fase aps fase, o projeto deixa de
ser uma ideia, passa a ser uma extensa documentao, ento cdigo e, aps os testes, est pronto para a
fase final: colocar em produo.
No prprio artigo original, o autor diz:

2.1. De onde viemos: Waterfall
I believe in this concept, but the implementation described above is risky and invites failure. (...) The
testing phase which occurs at the end of the development cycle is the first event for which timing, storage,
input/output transfers, etc., are experienced as distinguished from analyzed.
Quer dizer: se a equipe precisa esperar at o projeto inteiro estar pronto para testar o sistema desen-
volvido, fatidicamente encontrar diversos problemas, sejam eles bugs ou questes de performance e
escalabilidade.
Royce tambm defende que a documentao de um software deve ser extensa. Em seu artigo ele chega
a mencionar nmeros:
In order to procure a 5 million dollar hardware device, I would expect that a 30 page specification would
provide adequate detail to control the procurement. In order to procure 5 million dollars of software I would
estimate 1500 pages specification is about right in order to achieve comparable control.
E, de fato, a importncia da documentao no desenvolvimento tradicional de software refletida nas

fases do projeto dedicadas exclusivamente a ela.
Como funciona
O mtodo Waterfall caracterizado por fases bem definidas, com atividades especficas em cada uma
delas. Veja abaixo a descrio do mtodo retirada do paper de Royce:
4
Captulo 2. Rumo agilidade
A inteno que, terminada uma fase, o projeto siga para a prxima sem jamais retomar um trabalho
j feito - assim como a gua que corre numa cascata nunca volta para cima.
Essa idia parece bastante atraente, certo? Zero re-trabalho, tudo flui sempre para a frente e, se todos
fizerem sua parte corretamente, ao final da fase de Operaes, tudo estar funcionando perfeitamente
como o cliente pediu.
H duas fases totalmente dedicadas a ouvir o cliente e entender o ambiente no qual o sistema deve rodar.
Depois dessas, a anlise de tudo o que foi levantado, seguida da arquitetura geral do sistema. Tudo isso
para chegar melhor estratgia para tratar o sistema.
S ento, inicia-se a produo de cdigo. Enfim, depois de terminada a implementao, o sistema

inteiramente testado, empacotado e implantado no cliente.
Ser?
Todas essas suposies possuem diversas implicaes, pois falhas nelas causam os problemas que en-
contramos hoje em dia no desenvolvimento de software.
Suposio: Uma pessoa ou um grupo de pessoas fala com o cliente e descobre o que ele quer do software
a ser produzido.
Ser que entenderam tudo corretamente? Ser que o cliente precisava mesmo de tudo aquilo que ele
imaginou?
Suposio: O mesmo ou outro grupo de analistas fala com o pessoal tcnico do cliente para descobrir o
ambiente em que o sistema ser implantado.
Em um projeto de um ano, ser que o ambiente no ser outro no momento da entrega?
Suposio: Os analistas, ento, verificam a viabilidade do projeto e identificam suas partes mais arrisca-
das.
Se eles no esto envolvidos com cdigo, ser que eles entendem to perfeitamente as dificuldades de
cada deciso?
Suposio: Baseados nas informaes levantadas por analistas e descritas em documentao, os arqui-
tetos criam pilhas de UML para guiar os programadores.
As informaes estavam corretas? Eles entendem exatamente o que os analistas quiseram dizer em cada
documento? Ou acham que entendem?
Suposio: Lendo os UMLs e outros documentos que os arquitetos geraram, os programadores fazem o
cdigo de acordo com o que foi previamente especificado.
A interpretao dos UMLs vai ser igual dos arquitetos? E os programadores no terem poder de deciso
sobre seu cdigo, parece uma boa idia?
5
2.2. Dinmica: comunicao indireta
Suposio: Os testers, lendo a documentao inicial, testaro se o sistema se comporta como o combi-
nado com o cliente no incio do projeto
Novamente, quanto os testers vo entender do que os analistas anotaram sobre as necessidades do cli-
ente? Se os programadores no mexeram com a documentao inicial, os testers vo conseguir navegar
pelo sistema como o esperado? E eles vo pensar em todas as possibilidades mnimas de uso do sistema
como um todo?
O pessoal de implantao vai lidar com as mesmas mquinas vistas no ano anterior? E sobre o mesmo
software?
2.2 Dinmica: comunicao indireta

1) Telefone sem fio
Vamos ver o quo bem nos damos com essa comunicao indireta com uma variao da brincadeira
clssica do telefone sem fio. O instrutor explicar a brincadeira.
Por que desejamos algo mais que waterfall
A distncia do cliente durante todo o processo de construo do sistema muitas vezes faz perder o foco
no que realmente importante para ele. Por sua vez, o conhecimento sobre o sistema passando de equipe
especializada em equipe distorce o produto final a cada ponto em que a comunicao falha.
Alm disso, note que as quatro primeiras fases consistem apenas de documentao, sem nenhuma pro-
duo de valor para o cliente. Toda a documentao gerada nessas fases para consulta dos analistas,
arquitetos, desenvolvedores e testers do projeto - nada para o cliente.
Tambm preciso mencionar o Big Design Up Front - essa idia de que um sistema pode ser comple-
tamente planejado antes mesmo de come-lo e que, se for bem pensado, ser a frmula mais prxima
da perfeio criada para esse sistema.
Em um ano de desenvolvimento, muitas tecnologias novas surgem. Em um ano, as prprias necessidades

do cliente mudam, de acordo com a evoluo da empresa dele. Mas, se os arquitetos, os desenvolvedores
e os testers nunca falaram com o cliente, como sabero disso?
E os programadores? Eles so realmente incapazes de tomar qualquer deciso sobre o prprio cdigo a
ponto de os arquitetos terem que especificar como eles faro todo o sistema? Vale a pena manter na sua
equipe programadores que no podem e no sabem tomar decises?
A resposta no. Assim como paga-se bons arquitetos e bons analistas, bons desenvolvedores so es-
tritamente necessrios para o sucesso do seu projeto. Os chamados Code Monkeys no nos servem e
confiar a eles um projeto grande e importante fadar o sistema ao fracasso.
6
Por todos esses problemas e pelos diversos projetos que falharam, outras metodologias surgiram para
melhorar o desenvolvimento de projetos de software.
2.3 De onde viemos: RUP

Os frameworks mais conhecidos e utilizados para resolver os principais problemas causados pelo m-
todo Waterfall so os chamados Unified Processes, dos quais destaca-se o Rational Unified Process
(RUP).
Este processo, criado pela Rational e, mais tarde, englobado pela IBM, visa utilizar corretamente UMLs
(Unified Modeling Language) para criar uma documentao menor, mais rica e auto-explicativa para
todos que entendem essa linguagem de modelagem.
E, com razo, j no white-paper de apresentao do framework escrito em 1999, a Rational discretamente

critica a quantidade de documentao recomendada pelo seu predecessor:
The Rational Unified Process activities create and maintain models. Rather than focusing on the production
of large amount of paper documents, the Unified Process emphasizes the development and maintenance of
models - semantically rich representations of the software system under development.
Tambm diferentemente de seu predecessor, o RUP entende que no existe uma bala de prata capaz
de resolver os problemas de gerenciamento de sistemas de qualquer porte e estilo. Dessa forma, o fra-
mework adaptvel e traz diversos modelos que podem ser utilizados no seu projeto, conforme as ne-
cessidades. Do mesmo artigo:
The Rational Unified Process is a configurable process. No single process is suitable for all software develop-
ment. The Unified Process fits small development teams as well as large development organizations. The
Unified Process is founded on a simple and clear process architecture that provides commonality across a
family of processes. Yet, it can be varied to accommodate different situations.
Como funciona
O RUP tem como base as 6 melhores prticas, na viso da Rational:
Desenvolva software iterativamente;
Gerencie requisitos;
Use arquiteturas baseadas em componentes;
Modele visualmente o software;
Verifique a qualidade do software;
7
2.3. De onde viemos: RUP
Controle mudanas no software.
notvel a diferena desses preceitos com relao aos utilizados no Waterfall. Em vez de pilhas de docu-
mentao, o RUP prope modelagens mais simplificadas e visuais, seguindo um padro mundialmente
reconhecido. Mudanas acontecem e so esperadas, tratadas com mais naturalidade. Qualidade do
software e reuso de componentes so incentivados. E, o mais importante, o desenvolvimento iterativo.
Given todays sophisticated software systems, it is not possible to sequentially first define the entire problem,
design the entire solution, build the software and then test the product at the end. An iterative approach
is required that allows an increasing understanding of the problem through successive refinements, and to
incrementally grow an effective solution over multiple iterations.
O desenvolvimento iterativo, comeando sempre pelos pontos de maior risco no projeto, o ponto
chave para o sucesso do RUP. Decises de risco tomadas no incio do projeto so muito mais facilmente
corrigveis. Iteraes curtas com releases internos durante toda a construo do projeto permitem um
feedback mais rico do cliente e ajudam a manter uma melhor viso do tempo estimado para a concluso
do projeto.
Tambm, em vez de ciclos separados e definidos de atividades na construo do projeto, o RUP prev
uma mudana de importncia de cada tipo de atividade no decorrer de um projeto, isto , as fases se
sobrepem conforme a necessidade em cada momento.
O seguinte diagrama, comumente conhecido como o Diagrama da Baleia, mostra a porcentagem es-
perada de cada atividade no decorrer do projeto.
8
Imagem de domnio pblico, retirada de Wikimedia Commons
Por que RUP no nos serve
Definitivamente, o RUP estaria milhas frente de seu predecessor... no fosse o fato de que esse fra-
mework raramente aplicado iterativamente. Curiosamente, o mercado abandonou justamente a parte
que tornava o RUP mais interessante, isto , decidiu dar menos importncia ao feedback do cliente.
errado de princpio subestimar a importncia do cliente. O sucesso ou fracasso do projeto depende,

em ltima instncia, do quo feliz o cliente ficou com o resultado alcanado. Sem o feedback contnuo,
apenas uma aposta de que o produto vai atender s necessidades e expectativas do cliente.
Mas mesmo o RUP em sua forma iterativa, apesar de esperar que mudanas aconteam, no tem tanto
jogo de cintura para trat-las. Veja mais um trecho do paper:
While the process must always accommodate changes, the elaboration phase activities ensure that the ar-
chitecture, requirements and plans are stable enough, and the risks are sufficiently mitigated, so you can
predictably determine the cost and schedule for the completion of the development. Conceptually, this level
of fidelity would correspond to the level necessary for an organization to commit to a fixed-price construc-
tion phase.
Em termos claros, o que isso quer dizer : mudanas so aceitveis desde que no comprometam o
tempo prometido para entrega do projeto e no fujam muito do que foi decidido no incio do projeto.
Uma mudana um pouco maior j implica em re-negociao do contrato original.
Isso ainda causado pelo acmulo de documentao no incio do projeto. Embora menor do que no
Waterfall, o problema persiste e o cliente s comea a ver seu projeto tomando forma aps diversas
iteraes de papel: construo de documentao que no agrega valor para o cliente.
Tambm persiste, pelo mesmo motivo, a falta de liberdade dos desenvolvedores em escolher caminhos
durante o processo.
Outra deficincia que, apesar das iteraes produzirem produtos com algumas funcionalidades com-
pletas, o processo supe que a implantao real do software acontece apenas a partir do final do perodo
de desenvolvimento. At ento, as releases internas eram apenas demonstradas ou brevemente experi-
mentadas pelo representante do cliente, no pelos usurios finais em si.
Considere, contudo, que os problemas de comunicao explorados na seo Waterfall dessa apostila
tambm acontecem do lado do cliente. A chance de o representante dos clientes no entenda perfeita-
mente o uso que ser feito do sistema imensa.
As idias apresentadas pelo Rational Unified Process foram excelentes e representaram uma resposta na-
tural aos problemas causados pelo Waterfall e sua cultura. Da mesma forma, os mtodos geis surgiram
para resolver os problemas deixados pelo RUP. So, tambm, uma evoluo natural.
9
Captulo 3
O que agilidade
Simplicidade o grau mximo da sofisticao

Leonardo Da Vinci
3.1 Agilidade e o Manifesto gil

Em resposta aos problemas encontrados no mercado de software internacional, diversas metodologias
foram criadas e comumente chamadas de "lightweight processes, em oposio aos seus predecessores e
suas diversas ferramentas e exigncias.
Entendendo que havia algo em comum entre essas novas metodologias, organizou-se um encontro ao
qual 17 proeminentes idealizadores puderam comparecer. Desse evento, concordou-se em quatro valo-
res fundamentais comuns aos participantes - e assim surgiu o Manifesto gil.
Um pouco mais tarde, os mesmos autores e mais outros participantes enriqueceram o manifesto in-
cluindo os princpios geis, isto , o conjunto de prticas que engrandecem e tornam possveis aqueles
quatro valores.
Para entender qualquer das metodologias geis, entre elas o Scrum, necessrio entender os valores
e princpios por trs delas. Aprender uma metodologia sem absorver seus princpios desnecessaria-
mente difcil e leva a essa tendncia de chamar de Scrum o ferramental e no a cultura.
Acima de tudo, agilidade uma cultura que permeia toda a equipe. Isso fica bastante claro nos textos
a seguir. Examine-os com cuidado, releia s vezes, repense e melhore. Isso tambm faz parte do nosso
trabalho.
3.1. Agilidade e o Manifesto gil
O Manifesto gil
"Estamos descobrindo formas melhores de desenvolver

software ao fazer e ajudar outros a fazerem software.
Por esse trabalho, passamos a valorizar:
Indivduos e Interaes sobre processos e ferramentas

Software Funcionando sobre documentao extensiva
Colaborao do Cliente sobre negociao de contrato
Responder a mudanas sobre seguir um planejamento
Isso quer dizer que, embora haja valor nos itens

direita, valorizamos mais os itens esquerda."
Os Princpios geis
Ns seguimos esses princpios:
Nossa maior prioridade satisfazer o cliente atravs de entregas frequentes e desde cedo de soft-
ware de valor.
Receba bem a mudana de requisitos, mesmo tardias no desenvolvimento. Processos geis enca-
ram mudanas para vantagem competitiva do cliente.
Entregue software funcionando com frequncia, em intervalos de semanas ou meses, dando pre-
ferncia para perodos mais curtos.
Pessoas de negcios e desenvolvedores devem trabalhar juntos diariamente durante o projeto.
Construa projetos com pessoas motivadas. D a eles o ambiente e o suporte que precisarem e
confie que eles faro o trabalho.
O mtodo mais eficiente e efetivo de agregar informaes para e de um time de desenvolvimento

conversa cara-a-cara.
Software funcionando a primeira medida de progresso.
Processos geis promovem desenvolvimento sustentvel. Patrocinadores, desenvolvedores e usu-

rios deveriam ser capazes de manter um ritmo constante indefinidamente.
Ateno contnua a excelncia tcnica e bom design engrandecem a agilidade.
Simplicidade -- a arte de maximizar a quantidade de trabalho no necessrio -- essencial.
As melhores arquiteturas, requisitos e design emergem de times auto-organizados.
12
Captulo 3. O que agilidade
Em intervalos regulares, o time reflete sobre como se tornar mais efetivo e, ento, sintoniza e ajusta
comportamentos de acordo.
3.2 O que um projeto de sucesso?

Antes de comearmos a discutir como melhorar as chances de sucesso de um projeto, na viso gil,
preciso definir o que um projeto de sucesso.
Seguindo os princpios que acabamos de ver, vamos construir nossa definio. Um projeto de sucesso
um projeto que:
Atende s necessidades do cliente;
Mantm a equipe feliz: sem hora-extra, sem tempo inativo;
Cdigo bem feito: permite manter o ritmo, facilita manuteno;
Lucro: tanto para o cliente, quanto para o time.
Sempre que falamos de projetos de sucesso, preciso notar que, embora a satisfao do cliente seja
importante, a motivao e satisfao da equipe tambm de grande importncia. O contato direto com
o cliente permite que a equipe entenda o valor do que esto fazendo e, dessa forma, naturalmente a
motiva.
Ento quer dizer que...
S d pra fazer projetos de sucesso com mtodos geis?
No. Basta ver os tantos projetos criados no passado que foram considerados bem-sucedidos. Certo?
Quase. Considerando nossa definio de sucesso, quantas equipes desses projetos ditos bem- sucedidos
ficaram travados esperando uma resposta de outros silos ou mesmo, em vsperas de entrega, viraram
noites e trabalharam em finais de semana? E o cdigo desses projetos? Ser que houve a preocupao
tcnica durante o desenvolvimento?
Claro que um projeto ou outro, mesmo no significado de sucesso definido acima, foram bem sucedidos.
Ento a resposta dessa pergunta : no, mas mais fcil faz-los usando agile.
Ento, usando agile meus projetos com certeza vo dar certo?
E, nessa pergunta, a resposta continua sendo No. Contudo, mais provvel que eles dem certo,
segundo os relatrios de diversas avaliaes do Standish Group em seu anual Chaos Report.
Contudo, imprevistos continuam acontecendo e, mesmo equipes acostumadas com a cultura gil e o
ferramental, podem ter problemas impeditivos num projeto. Problemas como cortes oramentrios em
13
3.3. Vantagens da agilidade
clientes ou clientes que mudam de ideia a cada momento e no aceitam sugestes. Impossvel prev-los,
claro, e so problemas que afetariam tambm projetos tradicionais.
Alm disso, comum vermos equipes novas em agilidade que acabam por disfarar mtodos tradicio-
nais de agile e, no fim, culpar o processo. Falaremos desses problemas em sees mais a diante.
3.3 Vantagens da agilidade

A agilidade traz em seu cerne diversos aspectos de melhoria com relao a seus predecessores. Aes
simples que ajudam a nivelar para cima o conhecimento de uma equipe e manter a motivao e o foco
do trabalho sempre em mente.
Feedback rpido: tanto para clientes, quanto para equipe e o relacionamento entre essas partes, o
feedback constante e rpido permite tomar decises e corrigir problemas antes que eles se tornem
crnicos.
Motivao da equipe: o contato direto com o cliente torna mais fcil entender o valor do trabalho
do time para o cliente. No ter o sistema todo pr-modelado, poder tomar decises, tambm
valoriza o desenvolvedor.
Sem corpo mole: as prticas de engenharia de software incentivadas pelas metodologias tambm
so importantssimas. Quanto mais comunicao dentro do time, mais aprendizado. Quando
mais aprendem, tm-se mais membros melhores.
Ver problemas mais cedo: prticas como pareamento e reunies dirias explicitam problemas na
equipe mais cedo, possibilitando resolv-los mais cedo.
3.4 Mitos e verdades

Muito se fala de agilidade. Muitos pontos positivos, outros tantos negativos. necessrio discutir, no
entanto, logo de incio, o que e o que no verdade.
No h documentao: Mito. O quanto de documentao for necessria, ser feita. No h regras

em agile contra documentao, mas sim contra trabalho desnecessrio e contra planejar todo o
projeto no incio.
Agile s para times pequenos: Mito. As prprias metodologias provam o contrrio. H Scrum
of Scrums, h Cristal Orange. So formas de se trabalhar com agile em muitas pessoas que prezam
por manter, tanto quanto possvel, a simplicidade na comunicao.
Agile s para times experientes: Mito. Vimos h pouco que prticas geis nivelam pra cima. O
crescimento pessoal fomentado pela agilidade.
14
Captulo 3. O que agilidade
Agile no d certo pra qualquer time: Verdade. Para funcionar, preciso que a equipe abrace
a mudana cultural. E, para isso, preciso que seja explicado equipe o que vai mudar e as
motivaes.
Agile mais difcil: Verdade, em termos. Trabalhar de forma gil muito menos burocrtico e,
para que d certo, exige-se disciplina. Disciplina em seguir o processo e em se auto-gerenciar. Os
ganhos pessoais, entretanto, so visveis.
3.5 Overview de Scrum

Para melhorar nossa comunicao durante os prximos dias de curso e j, desde cedo, fazermos parale-
los entre Lean e Scrum, vamos aprender o vocabulrio padro do Scrum. O instrutor apresentar, ainda
sem detalhes, as palavras-chave desse framework.
15
Captulo 4
Agilidade com Lean
Aperfeioar-se tanto desaprender quanto aprender.

Edsger Dijkstra
4.1 O Lean
Muito se fala de Scrum no Brasil mas, antes de chegarmos a esse framework, estudemos um sistema
industrial que foi uma grande inspirao para essa metodologia. O sistema Lean de Produo foi de-
senvolvido pela Toyota e tem um princpio claro e simples: reduzir o desperdcio.
Em 2009, a Toyota vendeu mais carros nos Estados Unidos do que a nacional e tradicional Ford,
tornando-se a segunda maior vendedora de carros naquele pas. Mas como uma marca japonesa ul-
trapassou a gigante americana que popularizou o automvel e revolucionou o sistema de produo de
veculos com o conceito de linha de montagem?
Simplificando.
Nesse captulo, aprenderemos sobre esse processo de produo que, hoje, se aplica no s indstria
automotiva, mas a outras indstrias variadas, inclusive de software.
4.2 Exerccio: Lean Lego Game

Para entendermos melhor as idias do Lean e as vantagens que elas trazem num sistema de produo,
seja ele de automveis ou de software, faremos um exerccio prtico que ilustra a reduo de desperdcios
por mudanas simples no processo e na cultura.
4.3. Sobre Lean: o mtodo Toyota
Esse workshop foi criado em 2008 por Danilo Sato e Francisco Trindade, da Thoughtworks de Londres,
como uma forma de ensinar e promover discusses sobre Lean de forma divertida.
Ele j foi apresentado em diversas conferncias pelo mundo e a pgina de referncia sobre o jogo :
http://www.dtsato.com/blog/work/lean-lego-game/
O instrutor explicar o jogo em sala.
4.3 Sobre Lean: o mtodo Toyota

Lean est intrinsecamente ligado minimizao dos desperdcios, sejam eles no processo, no desenvol-
vimento ou no produto final.
Considere como desperdcio tudo aquilo que no traz valor para o cliente e, como ganho, tudo o que
agrega valor. O lucro , ento, uma conta trivial: ganho - desperdcio. No contexto de produo
de software, podemos ser mais objetivos no que so considerados desperdcio e ganho.
Desperdcio tudo o que no feito para o cliente, seja a j discutida documentao excessiva, tempo de
desenvolvimento parado por falta de informaes (ou falta de clareza nelas), ou cdigo e funcionalidades
no-requisitadas.
Ganho tudo o que agrega valor e reduz retrabalho: funcionalidades novas, entregas frequentes para o
cliente, cdigo de qualidade, testes, etc...
Desperdiando desenvolvimento de software
E o que desperdcio no desenvolvimento de software?
Funcionalidades que so desenvolvidas pela metade e as que esto completamente funcionais so exem-
plos de desperdcio de desenvolvimento ligados a quantidade de trabalho em andamento, incompleto.
Minimizar esse tipo de desperdcio fundamental para aumentar a eficcia e, consequentemente, o

retorno em valor do software desenvolvido.
Outros exemplos esto ligados com o planejamento e o trabalho do dia a dia, excessos que cometemos,
como produzir uma funcionalidade ainda desnecessria, aguardar ordens etc.
Os tipos de desperdcio
Lean divide os desperdcios em trs categorias de igual importncia:
Mura: desperdcios por tentar prever possveis necessidades futuras. Evitar Mura significa reduzir
ao mximo o inventrio, isto , as partes paradas no meio do processo, isto , trabalho comeado
e no terminado.
18
Captulo 4. Agilidade com Lean
Muri: desperdcios que podem ser evitados por planejamento. Nessa categoria enquadra-se o
excesso de burocracia ou de complexidade num processo de produo.
Muda: desperdcios do dia-a-dia, criados por uma cultura anterior de trabalho. Os sete Mudas
geralmente destacados so:
Superproduo
Transporte desnecessrio
Inventrio
Locomoo
Defeitos
Superprocessamento
Espera
Durante o Lean Lego Game, vimos como aes simples podem reduzir drasticamente os desperdcios
supracitados.
4.4 Push vs. Pull Systems

No sistema Ford de produo, cada estao da linha de produo trabalha enquanto houver matria-
prima para tal. A quantidade do que ser produzido regulada com base a previses feitas sobre o
mercado num determinado perodo e no h ligao entre os pedidos reais e a linha de produo.
Naturalmente, uma estao de trabalho mais simples mais eficiente em realizar sua tarefa. Contudo,
assim, dois desperdcios so criados:
1) as muitas peas produzidas, esperando para serem usadas em outras estaes, sem sequer saber se
h demanda pelo produto. Chamamos essas peas de inventrio;
2) o tempo livre dos trabalhadores superespecializados que trabalham nas funes terminadas mais
cedo.
Esses so exemplos de Mura. Uma soluo possvel para tais desperdcios trabalhar com sistemas pull
em vez dos tradicionais push, como o descrito.
Sistemas pull trabalham com o mnimo possvel de inventrio que ainda permita atender s demandas
de clientes rapidamente. Sua concepo e prtica so simples: h apenas o nmero suficiente de peas
em inventrio para um produto (ou um lote) ser completo.
19
4.5. Kanban
Perceba que, em vez do planejamento pouco malevel baseado em previses de mercado utilizado por
sistemas push, em sistemas pull a produo acontece de acordo com a demanda, reduzindo custos de
armazenamento de peas intermedirias e de produtos no vendidos, alm de flexibilizar a produo.
Quando de fato h demanda, a estao final consome as peas necessrias. A anterior, ento, trabalha
para repor o que foi consumido, e assim acontece sucessivamente, at a primeira estao.
4.5 Kanban
Se entendermos a linha de produo como uma sequncia de passos para produzir algo, a representao
bvia para o processo o, j consagrado em diversas teorias da rea de Administrao, Kanban.
Nele, os produtos por fazer ficam esquerda e migram para a direita conforme os passos para sua cons-
truo vo sendo terminados.
Em sistemas push, cada estao de trabalho faz sua parte sem considerar as fases anteriores e posteriores.
O Kanban abaixo permite ver com mais clareza o acmulo de inventrio:
20
J no Kanban que representa o sistema pull de produo, h um limite de inventrio claramente delimi-
tado. Dessa forma, peas s so produzidas quando de fato h demanda e gasta-se menos em peas que
no sero utilizadas ou em estoque de inventrio.
O Kanban uma excelente forma de visualizar o andamento da produo, mas importante lembrar
que ele apenas uma ferramenta. E, como qualquer ferramenta, deve ser empregada para reforar e
auxiliar na aplicao da metodologia.
21
4.6. Systems Thinking
4.6 Systems Thinking

Voltando ao cenrio proposto, aps reduzir o Mura, pudemos ver mais claramente como nossa linha de
produo funciona. E ento foi possvel notar que havia trabalhos redundantes.
No caso do workshop, havia uma estao a mais do que o realmente necessrio e no reparamos antes
porque, focados na nossa tarefa, no nos preocupamos em sequer saber o que as outras estaes faziam.
Ou, pior, notamos a duplicao de trabalho, mas no sinalizamos essa deficincia.
E quantas vezes no vimos consagrados processos de produo de software atrapalhando uma equipe
em vez de ajud-la? Todas as fases do seu processo so realmente necessrias para o sucesso final?
Ainda que todas as fases sejam necessrias no comeo de um projeto, frequentemente, em algum ponto,
alguma delas deixa de ser necessria e outras, antes no pensadas, podem passar a ser teis.
importante sempre pensar no processo, no simplesmente aceit-lo. Um processo de produo de

software, uma metodologia ou um framework. Todos eles foram planejados para auxiliar na produo
- se esto fazendo o oposto, precisam ser mudados.
Pensar sempre no sistema, Systems Thinking, pensar e repensar durante todo o andamento do projeto
no que poderia ser melhorado no prprio processo de desenvolvimento e nas interaes entre as pessoas
envolvidas.
4.7 Work Cells

No possvel, no entanto, encontrar possveis melhorias no processo se cada envolvido est focado
exclusivamente em uma tarefa, na qual especialista.
Por isso, Lean entende que as pessoas envolvidas em um projeto no podem ser superespecialistas, isto
, no podem se limitar a conhecimentos apenas de sua etapa. Deveriam conhecer todas elas e saber
executar pelo menos algumas delas.
Cada membro da equipe , dessa forma, uma Work Cell: uma pessoa capaz de trabalhar no projeto
como um todo, em algumas ou todas as suas partes. E o conhecimento mais amplo sobre o projeto
incentivado, j que, quanto melhor algum conhece o todo, melhor sabe critic-lo - e, dessa forma,
melhor-lo.
Tambm, se um trabalhador consegue chegar sozinho ao produto final, todo o custo com locomoo,
tanto de pessoas quanto de mquinas ou peas, extinto. Menos desperdcio.
Em uma planta industrial, a possibilidade de um s trabalhador fazer o produto por completo muito
mais difcil, portanto a work cell formada por um grupo de pessoas, em vez de uma pessoa apenas. J
em desenvolvimento de software essa barreira bem menor.
22
Um arquiteto, um tester ou um desenvolvedor, seja ele jnior ou snior, podem produzir cdigo e de-
veriam entender essa atividade como algo de valor para o projeto, colaborando com o time.
4.8 Kaizen
Ainda na dcada de 1970, Frederich Brooks publicou um artigo chamado No Silver Bullet. Apesar de
tanto tempo passado, o artigo no perde sua veracidade e , juntamente com The Mythical Man-Month,
leitura obrigatria para todos aqueles na rea de Engenharia e Gerenciamento de Software.
Em Lean, acredita-se que no exista, tambm para o processo, uma bala de prata capaz de resolver
todos os problemas. Dessa forma, preciso que cada equipe adapte a metodologia e ferramentas sua
necessidade, a todo momento.
Finalmente, a ltima prtica dessa breve introduo a Lean o Kaizen, palavra japonesa para melhoria.
E melhoria significa maximizar aquela funo: ganho - desperdcio. Melhorias no processo, na
forma de produo e no produto final so parte do dia-a-dia de quem trabalha com Lean.
O Kaizen amplamente apoiado pelos conceito previamente vistos. Perceba: como cada work cell da
equipe tem uma viso mais geral da produo e so incentivados a pensar no sistema (system thinking),
conseguem enxergar melhorias mais facilmente.
23
Captulo 5
O framework Scrum
A tragdia da vida que nos tornamos velhos cedo demais e sbios tarde demais.
Benjamin Franklin
Embora hoje ele dispute a cena com outros mtodos, certamente o mais proeminente processo gil no
mercado de software brasileiro o Scrum. impressionante a quantidade de projetos novos e empresas
inteiras que esto migrando para essa forma de gerenciamento de software. A magnitude desse movi-
mento apenas reflete o sucesso da adoo do Scrum e suas prticas em diversos projetos.
Facilmente adaptvel em ambientes que j utilizavam anteriormente processos como o RUP ou variaes
dele, podemos dizer que o Scrum um processo gil mais regrado em termos de gerenciamento. E o
fato de existir mais regras facilita a transio para esse framework, j que, seguindo corretamente os
moldes do Scrum, a tendncia que a cultura gil seja adotada.
Contudo, no so os papis, os artefatos e os time-boxes que traro o sucesso do seu projeto, mas sim
essa cultura. Dessa forma, importantssimo que lderes do projeto incentivem essa mudana cultural:
o auto-gerenciamento, o sentimento de time, a ausncia de culpados, o foco na meta...
Nesse captulo, apresentaremos o Scrum e, nos prximos, aprofundaremos os conhecimentos particu-

lares de cada uma das partes que compem esse framework.
5.1 Histria do Scrum: adaptando Lean ao desenvolvi-

mento de software
Com a mesma inteno de reduzir desperdcio e aprimorar processos e j no contexto de construo
de software, o Scrum surgiu. Discusses sobre quem criou o framework so muitas: Ken Schwaber, Jeff
5.1. Histria do Scrum: adaptando Lean ao desenvolvimento de software
Sutherland ou Takeuchi & Nonaka, et al.
No , contudo, possvel apontar um pai nico. O motivo simples: assim como tudo o que vimos at
agora, Scrum uma evoluo do que j vinha acontecendo na indstria e, dessa forma, difcil dizer a
partir de que momento pode-se chamar o processo de Scrum. E, verdadeiramente, no relevante.
No paper explicando Scrum publicado nos anais da OOPSLA de 1995, Ken Schwaber explica a essncia
do progresso que Scrum trazia, quando comparado aos processos tradicionais de desenvolvimento de
software: Scrum , acima de tudo, um processo emprico.
Waterfall and Spiral methodologies set the context and deliverable definition at the start of a project.
SCRUM and Iterative methodologies initially plan the context and broad deliverable definition, and then
evolve the deliverable during the project based on the environment. SCRUM acknowledges that the un-
derlying development processes are incompletely defined and uses control mechanisms to improve flexibi-
lity.
The primary difference between the defined (waterfall, spiral and iterative) and empirical (SCRUM) ap-
proach is that The SCRUM approach assumes that the analysis, design, and development processes in the
Sprint phase are unpredictable. A control mechanism is used to manage the unpredictability and control
the risk. Flexibility, responsiveness, and reliability are the results.
Ainda em 1995, o processo era um tanto diferente da forma como hoje descrito o Scrum. A termi-
nologia mudou, alguns detalhes antes apenas recomendados tornaram-se obrigatrios, detalhes antes
obrigatrios se tornaram recomendaes e os dados so mais embasados. E tambm interessante notar
que j desde esse documento, fala-se em projetos com durao, custo e produto final variveis, impli-
cando inevitavelmente em discusses sobre contratos.
Tambm nessa poca, entre 1995 e 2000, publicaes sobre Scrum contavam no s com o processo
de gerenciamento, mas tambm com prticas de engenharia de software que hoje foram melhoradas e
habitam as prticas de eXtreme Programming (XP). Apenas mais tarde, tais prticas foram separadas
do Scrum.
Desde ento e at hoje, a presena do Scrum no mercado de desenvolvimento de software s cresceu. Em

2001, quando o Manifesto gil foi escrito, Scrum ainda estava em fase inicial de adoo, nas primeiras
ondas de interesse.
Em 2005, j estava presente em diversas empresas de produo de software e comeando a ser adotado
em reas de informtica em empresas cujo objetivo final no era a produo de software. Em 2007,
chegava, ainda tmido, no mercado nacional e, em 2009, a grande exploso, j to esperada, aconteceu.
Todavia, ainda h muito espao para crescer. Apesar de atualmente a maioria das empresas brasileiras j
terem ouvido falar de Scrum, boa parte delas ainda est ensaiando o uso desse framework em projetos
pilotos ou apenas introduzindo prticas geis de engenharia de software aos seus processos.
26
Captulo 5. O framework Scrum
Em 2009, Ken Schwaber, um dos idealizadores do Scrum, se desligou da Scrum Alliance e criou o
Scrum.org. Atualmente, esse site conta com um Scrum Guide, atualizado quase que anualmente com
o que Schwaber e Sutherland acreditam ser o estado da arte no que diz respeito ao Scrum. O motivo da
ruptura com a Scrum Alliance pode ser lido em um documento chamado The Genesis of Scrum.
No Scrum Guide, h outra frase que representa a essncia do framework:
Scrum: A framework within which people can address complex adaptive problems, while productively and
creatively delivering products of the highest possible value. (...) Scrum makes clear the relative efficacy of
your product management and development practices so that you can improve.
Isto , a funo do Scrum evidenciar os problemas do projeto, mostr-los mais cedo para que possam
ser resolvidos mais cedo.
5.2 Artefatos
Com o intuito de acompanhar o andamento do projeto e evidenciar de forma mais visual o que ainda
h para ser feito e o que j est pronto, os artefatos foram introduzidos ao Scrum.
Originalmente, apenas a lista do que ainda h por ser feito, apelidada Backlog, era descrita como parte
da metodologia. O Backlog serve tanto para armazenar o que ainda deve ser feito num projeto ou
Sprint, quanto para saber qual o prximo item a ser trabalhado, j que nele as tarefas so ordenadas por
prioridade.
Nas verses de 2009 e 2010 do Scrum Guide mais um artefato passou a figurar no framework: o grfico
de BurnDown. Em 2011, ele foi, novamente, removido das regras. Falaremos sobre uso desse grfico e
de outras mtricas nos captulos sobre Artefatos.
5.3 Iteratividade
Vimos que desde o RUP, e at mesmo antes dele, o desenvolvimento iterativo era recomendado e havia
demonstrado resultados melhores do que o mtodo linear proposto pelos modelos mais tradicionais.
Ao contrrio desses, desde sua concepo inicial, o Scrum acredita que no possvel prever com preci-
so, logo no incio do projeto, qual ser o produto final. Acredita-se que as necessidades mudam e que
desperdcio gastar tempo planejando aos mnimos detalhes, o que deve ser feito a mdio prazo.
Scrum preza por atender o cliente da melhor forma possvel, adaptando-se a qualquer mudana que
agregue mais valor ao produto e, mais do que isso, tratando-as de forma natural.
Entretanto, para no atordoar a equipe com mudanas a todo tempo, uma regra estabelecida: mudan-
as so bem-vindas para qualquer item do Backlog do projeto, mas no para os itens j planejados para
27
5.4. Interaes
a iteraao atual.
Isso quer dizer, estritamente, que algo com que a equipe se comprometeu para a iterao atual no
pode ser mudado pelo cliente durante essa iterao. Note, porm, que qualquer item marcado para o
futuro, qualquer necessidade nova ou qualquer mudana em algo j desenvolvido podem ser mudados
livremente.
Scrum no existe sem suas iteraes, e elas devem ser curtas.
Iteraes em Scrum so denominadas Sprints. Mas ele no , contudo, o nico evento de tempo limitado
e do Scrum. Veremos mais sobre esse assunto no captulo de time boxes.
5.4 Interaes
To importantes quanto as iteraes, so as interaes entre pessoas de um time de Scrum.
Um time de Scrum tem trs papis diferentes que devem ser distribudos entre os seus membros: Scrum
Master, Product Owner e Desenvolvedor. Mais especificamente, h um Scrum Master, um Product
Owner e diversos desenvolvedores. Esclarecendo a terminologia, consideramos todos os que agregam
para o crescimento do projeto como desenvolvedor, independentemente da sua especialidade.
Mais de um papel pode ser atribudo a uma mesma pessoa e, em alguns casos, pode haver rodzio dos
papis entre os membros de um time - por exemplo, pode-se eleger, de tempos em tempos, o desenvol-
vedor a receber o papel de Scrum Master da vez.
Porm, o que realmente caracteriza uma equipe de Scrum seu auto-gerenciamento. Isso significa que,
em um time gil, no h uma pessoa distribuindo tarefas, e sim pessoas escolhendo e executando suas
prprias tarefas. Tambm significa que a equipe um organismo s e no h um culpado por algum
problema, mas todos so igualmente responsveis pelo projeto - seja nos bons ou nos maus momentos.
O auto-gerenciamento no est restrito aos desenvolvedores do time. O Product Owner tambm deve
estar sempre atento aos prximos itens a serem desenvolvidos e s necessidades dos desenvolvedores.
crucial que o Product Owner entenda que ele parte da equipe e, dessa forma, o sucesso ou fracasso do
projeto tambm sua responsabilidade.
Outras interaes
Menos frequentes, mas tambm importantes para o bom resultado do projeto, so as interaes com
os usurios reais do sistema. Entregando cedo e sempre, possvel obter um feedback riqussimo dos
verdadeiros usurios do sistemas e, assim, focar no que realmente ser usado.
O Product Owner ter mais contato com os usurios finais, mas interessante que a equipe tambm o
tenha, pelo menos uma vez por Sprint, no Review Meeting. Tambm veremos os Meetings no captulo
28
Captulo 5. O framework Scrum
de time boxes.
5.5 Gerncia de time auto-gerencivel?

Mas... se o time auto-gerenciado, qual , ento, a funo do Scrum Master?
O Scrum Master tem como funo permitir que os desenvolvedores foquem nas suas tarefas, removendo
impedimentos e promovendo, atravs da educao, a aplicao do framework durante todo o decorrer
do projeto.
Nem ele e nem o Product Owner so como um gerente tradicional: algum a quem se presta contas.
O Scrum Master parte da equipe e funciona como um escudo para as intervenes ou impedimentos
que apaream na equipe. Ele est comprometido com o projeto tanto quanto qualquer outro membro
do time.
29
Captulo 6
Time-Boxes
Tempo o que mais queremos e o que pior usamos.

William Penn
Seja para planejamento financeiro ou para aprovao de um projeto, frequentemente somos obrigados
a prover um planejamento prvio do que se espera que esteja pronto em cada momento na construo
de um sistema.
Embora no to rgido quanto em mtodos tradicionais, o Scrum se adequa bem a esse modelo ao usar
o conceito de time-boxes - perodos invariveis de tempo nos quais atividades especficas so feitas.
Nesse captulo, apresentaremos os time-boxes do Scrum: reunies, cerimnias e para que servem cada
um deles.
O diagrama clssico
A maioria de ns foi apresentada ao Scrum pelo seguinte diagrama, que representa os dois principais
time-boxes do Scrum. Um ciclo maior, indicando a durao de um Sprint, e um outro menor, com a
durao de um dia.
6.1. Sprint
O maior ciclo representa um dos time-boxes sobre os quais o Scrum trabalha. O menor traz, dentro
dele, outro dos time-boxes do framework. Alm desses, ainda h as reunies de planejamento, reviso
e retrospectiva.
6.1 Sprint
Um Sprint consiste em tempo destinado ao desenvolvimento de incrementos no produto e reunies. Sua
durao costuma a ser de uma a quatro semanas e ela definida no incio do projeto. O limite superior
de um ms de durao no deve ser ultrapassado, j que precisamos de feedback rpido pelo cliente.
A durao dos Sprints pode ser repensada e alterada, conforme a necessidade, mas essa alterao nunca
pode acontecer dentro do prprio Sprint. As mudanas passam a valer a partir do Sprint seguinte
mudana.
No incio de um Sprint, h o Sprint Backlog contendo tarefas com as quais o time se comprometeu para
esse perodo e uma meta clara e bem definida para direcionar os esforos e prover uma viso melhor da
importncia que as histrias tm para o cliente. Por conta do conceito de meta de outros processos, h
times que preferem traduzir Goal como objetivo
O time responsvel por prover a meta de um Sprint e, muitas vezes, a pessoa com mais condies para
isso o Product Owner. O time e, em particular, o Scrum Master devem cobrar uma meta, caso ela no
seja definida.
Ao final de um Sprint, idealmente, a meta alcanada e cada uma das histrias do Sprint Backlog foi
transformada em incrementos ao sistema, agregando valor a ele e entregando para o cliente uma verso
que pode ser colocada em produo do software.
Veremos mais sobre escrever boas metas no captulo de Artefatos.
32
Captulo 6. Time-Boxes
6.2 Durao de um Sprint

Um Sprint deve ser longo o bastante para produzir incrementos significantes para o cliente e, dessa
forma, uma nova verso de produo implantvel. E, ao mesmo tempo, deve ser curto o bastante para
que o cliente traga direcionamentos melhores e mais ricos. Tambm para que bugs e problemas sejam
resolvidos rapidamente.
A relao de dualidade entre agregar valor e receber feedback importante e deve ser levada em consi-
derao enquanto decidimos a durao de um Sprint.
Na prtica: durao do Sprint
Por experincias e observaes da Caelum na produo de software, comum que projetos gran-
des passem por redues na durao do Sprint conforme a maturidade do sistema cresce.
Isto , no incio de um projeto grande, antes da primeira implantao e uso real pelos usurios
finais do sistema, usa-se Sprints grandes porque no necessrio mais esforo para produzir algo
de valor para o cliente.
Na fase intermediria do projeto, com feedback dos usurios, mas ainda adicionando funciona-
lidades novas a cada Sprint, comum que a durao seja mdia, para responder melhor a bugs
reportados pelos usurios, mas ainda haver tempo para produzir novos incrementos de valor ao
sistema.
Finalmente, quando o nmero de funcionalidades novas decai e manuteno a principal ativi-

dade, a resposta rpida a bugs ou pequenas melhorias passa a ser mais valiosa do que as grandes
funcionalidades seguintes. Dessa forma, Sprints semanais (ou mesmo mtodos no-iterativos)
costumam agradar mais equipe de desenvolvimento e aos clientes.
Seja qual for a durao escolhida, o desenvolvimento consome cerca de 85% do tempo de um Sprint. Os
15% restantes so divididos nas reunies de Planejamento, Reviso e Retrospectiva e nos Daily Scrums.
Entregar cedo estar na frente
Analize o que acontece se o cliente deve esperar 6 meses para utilizar o produto pela primeira vez. Se o
projeto interno empresa, o cliente fica 6 meses parado, sem poder se atualizar, acelerar seus processos.
Se o projeto um produto, a empresa est fora do mercado - ou com um produto desatualizado - por 6
meses. Nos dias de hoje, ficar 6 meses parado impensvel.
Alm disso, durante esses 6 meses o que o cliente e a empresa desejam j mudou substancialmente: uma
empresa que no muda durante 6 meses uma empresa rgida, que frequentemente ficou para trs.
O principal para nossos clientes entregar sempre e estar na frente de seus concorrentes. Para isso
33
6.3. Quando sobra ou falta tempo no Sprint
necessrio sempre entregar valor; importante que a cada Sprint o cliente final tenha algo utilizvel,
no somente algo testvel.
Esse um dos princpios do Agile:
"Nossa maior prioridade satisfazer o cliente atravs de entregas frequentes e desde cedo de software de
valor.
Finalmente, no entregar por tempos extensos implica em pacotes grandes de entrega, o que dificulta ao
usurio receber a mudana e avaliar do que foi feito. Isso, por sua vez, causa problemas ao projeto, que
pode estar caminhando na direo errada desavisado, e ao time, que ter que responder a bugs causados
muito tempo antes, isto , relembrar a funcionalidade, revisar o cdigo e, a sim, criar os testes e corrigir
o bug.
Entregar software de forma que todos os envolvidos consigam acompanhar seu crescimento funda-
mental e tambm aparece em um dos princpios geis:
"Processos geis promovem desenvolvimento sustentvel. Patrocinadores, desenvolvedores e usurios deve-

riam ser capazes de manter um ritmo constante indefinidamente.
Entregar de pouco em pouco ajuda o usurio a manter esse ritmo, em vez de passar por perodos de
calmaria seguidos de uma exploso de funcionalidades novas.
6.3 Quando sobra ou falta tempo no Sprint

Vez ou outra, uma histria estimada com erro muito grande e sobra ou falta tempo em um Sprint para
a concluso das histrias do Sprint Backlog atual. Nesse caso, o time deve conversar e negociar com o
Product Owner a retirada ou adio de uma histria do Sprint Backlog.
No caso de adio de histria, os desenvolvedores devem alertar o Product Owner sobre a capacidade
extra e este deve escolher alguma tarefa prioritria que caiba nesse Sprint. Se os desenvolvedores perce-
berem que ainda haver tempo sobrando, repete-se o procedimento.
Entretanto, erros de subestimao de histrias ou impedimentos particularmente complicados tambm

podem acontecer. Nesse caso, assim que os desenvolvedores perceberem que no sero capazes de ter-
minar todas as histrias do Sprint, devem se reunir com o P.O. e avisar a situao. O P.O. deve, ento,
verificar se possvel remover uma histria sem comprometer a meta.
Se for possvel, uma histria removida e o trabalho continua normalmente. Contudo, h casos em
que removendo qualquer uma das histrias do Sprint compromete-se a meta. Nesse caso, o P.O. deve
reduzir o escopo e redifinir a meta para algo menor, porm vivel.
Note que uma equipe gil no trabalha mais horas do que pode quando um erro acontece.
34
Em vez disso, negocia o que pode ser adiado. Lembremos que um dos princpios do Manifesto gil
que Processos geis promovem desenvolvimento sustentvel.
Isso no apenas para preservar a qualidade de vida do time, mas tambm porque h implicaes na
prpria qualidade quando acontecem as fatdicas horas-extra: quanto mais presso e mais m-vontade,
pior fica a qualidade do software -- i.e., mais bugs so introduzidos, mais gambiarras, etc.
Cancelamento de Sprint
H algumas situaes especiais em que um Sprint pode perder seu propsito enquanto em anda-
mento. Sua meta pode se tornar repentinamente obsoleta para o negcio da empresa e, a partir
desse momento, no faz mais sentido continuar trabalhando nesse Sprint.
O P.O. a nica pessoa da equipe com poder de cancelar um Sprint e, se o fizer, novas reunies de
reviso, planejamento e retrospectiva devem ser convocadas imediatamente e um novo Sprint,
com uma meta atualizada, deve comear.
Apesar de o mecanismo existir, cancelamentos de Sprints costumam ser traumticos para a

equipe e so muito incomuns, dado que um Sprint no tem longa durao e, portanto, rars-
simas sero as ocasies em que a meta deixa de fazer sentido no intervalo de um Sprint.
6.4 Planning meeting

No incio de um Sprint, a primeira atividade o Planning Meeting, comumente abreviado para Plan-
ning. O Planning meeting time-boxed e deve ocupar no mais do que 5% do tempo do Sprint - isto ,
num Sprint de duas semanas, essa reunio no deve consumir mais do que 4 horas.
O objetivo dessa reunio definir as histrias, isto , itens do Product Backlog, a serem feitas no Sprint
que acaba de comear. Ela funciona da seguinte forma:
1) Enquanto no passar da velocidade do time:
Apresentao das histrias: o P.O. apresenta a viso de negcio do item mais prioritrio do
Product Backlog aos desenvolvedores;
Dvidas de negcio: os desenvolvedores tiram suas dvidas sobre a histria, em termos da

lgica de negcios - no entram em questes tcnicas;
Discusso tcnica: os desenvolvedores discutem a parte tcnica envolvida na construo desse

item, sem muito detalhe. Essa discusso serve apenas para que todos entendam as complexida-
des envolvidas e possam dar uma estimativa. Nesse momento, a funcionalidade comea a ser
quebrada em tarefas tcnicas;
35
6.5. Review meeting
Pontuao: os desenvolvedores estimam a histria corrente. Usualmente, para auxiliar na pon-

tuao, utiliza-se o Planning Poker, a ser visto no captulo de Artefatos;
Repete: se ainda no passamos um pouco da velocidade do time, repetimos as instrues para

a prxima histria mais importante.
2) Sprint Backlog: baseando-se na pontuao feita e na mdia de pontos que o time faz por Sprint, o
P.O. e os desenvolvedores negociam o que deve entrar no Sprint Backlog.
3) Definio da Meta: se no tiver sido definida durante o processo, o time define a meta do Sprint.
Normalmente, essa atividade feita pelo P.O..
Durante a reunio, o papel do Scrum Master de facilitador: seu trabalho manter o foco dos partici-
pantes na discusso e monitorar o tempo. Ao fim de um Planning Meeting, a meta deve estar definida
e uma quantidade adequada de histrias, selecionadas. A equipe poder, ento, iniciar o trabalho de
desenvolvimento.
Planning em duas partes
A forma recomendada pelo Scrum Guide mais atual (2011) que o Planning seja quebrado em
dois momentos: o O qu e o Como. Nesse caso, os itens so separados da seguinte forma:
Planning 1: na primeira parte da reunio, o P.O. apresenta os itens da viso de negcios e o

time vota no esforo das histrias - conversas tcnicas se atm ao estritamente necessrio
para julgar o esforo.
Planning 2: na segunda parte, o P.O. pode deixar a sala e os desenvolvedores quebram as

histrias em tarefas, os itens tcnicos menores que so parte da construo de uma histria.
A definio da meta acontece no momento mais apropriado, em qualquer uma das reunies.
6.5 Review meeting

Ao final de um Sprint, espera-se que exista uma nova verso, incrementada, do sistema pronta para en-
trar em produo. Sejam grandes ou pequenas mudanas, fundamental agregar feedback dos clientes
sobre o que foi produzido.
Essa reunio tambm time-boxed e deve consumir no mais do que 2.5% do tempo de um Sprint,
segundo o Scrum Guide. Isto , para um Sprint de duas semanas, duas horas.
O Review Meeting a oportunidade que a equipe tem em cada Sprint para mostrar para o cliente
as mudanas. Ele importante tanto para que o cliente saiba das novidades que estaro disponveis
36
para uso, quanto para que o time de desenvolvimento receba o feedback real dos usurios do sistema e
entenda melhor suas necessidades.
A troca de experincias entre desenvolvedores e clientes positiva tambm para diminuir a distncia
entre as partes. Essa breve interao se mostra positiva quando, durante um Sprint, os desenvolvedores
precisam tirar dvidas com os clientes. A comunicao muito facilitada.
Alm disso, como nossa inteno construir confiana entre time e cliente, personificar a outra parte
causa mais um benefcio: menos difcil acreditar na boa vontade da outra parte quando interagimos
com ela. Com o tempo, o time aprende a confiar no cliente e vice-versa.
Uma implementao que recomendamos da Review Meeting corre da seguinte forma: um grupo dos
usurios finais convidado para conhecer as mudanas recentes e pede-se a esse grupo que pergunte e
palpite sobre o que houver de novo. Ento:
1) Leva-se somente as histrias prontas para a reunio;
2) Idealmente, pede-se para o prprio usurio experimentar as novas funcionalidades entregues pelos
desenvolvedores. Para cada histria, o resultado pode ser:
Aprovada. A histria atende as necessidades do usurio;
Reprovada. A histria no resolve o problema proposto;
Ideias novas. A histria pode ser melhorada com itens novos a serem desenvolvidos
3) Cada histria reprovada ou cada ideia nova transformada em uma nova histria, que entrar no
Product Backlog, na prioridade que lhe couber.
4) Por fim, acontece a definio do sucesso do Sprint. Um Sprint bem sucedido aquele que bateu a
meta proposta. Se ele no bem sucedido, ele falhou: no h meio termo nesse aspecto.
Lembre-se, apenas: falhar uma Sprint no uma catstrofe, uma situao natural. Apenas, durante a
retrospectiva analisaremos as razes para tal fracasso e colocaremos aes para que ele no se repita.
Importante: em uma Review Meeting s so mostrados os itens que estiverem prontos nesse momento.
E pronto no simplesmente implementado, mas sim implementado com uma qualidade que consi-
deramos aceitvel e realmente elegvel para um deploy. O critrio do que pronto importantssimo e
precisa estar claro para todo o time. A prxima seo explica esse conceito mais a fundo.
37
6.6. Definio de pronto
A pressa em corrigir os bugs
prtica comum em diversas empresas resolver os bugs encontrados o mais breve possvel,
mesmo em detrimento de funcionalidades novas mais importantes. Essa pressa para corrigir
bugs prejudicial para o time e para o cliente.
H bugs e bugs. H aqueles que impedem que o sistema funcione e h aqueles que acontecem,
incomodam, mas pode-se viver com eles por mais um tempo. Dessa forma, eles tm que entrar
na disputa de prioridade no Product Backlog como qualquer outro incremento.
Avaliar bugs dessa forma igualitria ajuda a focar no valor real a ser entregue para o cliente, o
chamado Return of Investment, ou simplesmente RoI.
6.6 Definio de pronto

A definio de pronto uma estipulao do time de quais atividades devem estar feitas para uma his-
tria ser considerada como pronta. Ela pode ser to minimalista quanto:
Pronto quando existe a histria foi desenvolvida e vimos funcionando
Embora vlidas, definies minimalistas tendem a deixar pontas soltas no projeto e, dessa forma,
quando o cliente testa, diversos bugs podem aparecer. Se o cliente no aprova as histrias, no h incre-
mento de valor e o Sprint foi mal-sucedido.
Contudo, no se pode ir ao outro extremo. Uma definio mais completa do que o necessrio pode
limitar a possibilidade de entrega do time:
Pronto quando a arquitetura est aprovada e documentada, o cdigo e o teste esto feitos, o P.O. deu ok,
foi para homologao, o cliente aprovou e entrou em produo.
H tantos pontos onde outras pessoas so necessrias nessa definio que terminar uma histria um
processo mais sofrido do que recompensador - principalmente quando uma histria no puder ser mar-
cada como pronta porque ficou travada em algum desses passos. Vale lembrar que apenas histrias
prontas so levadas para a Review.
preciso escolher uma definio de pronto vivel, que ajude a equipe a aprovar o mximo possvel de
histrias nas Reviews, mas mantendo a segurana da qualidade do que ser apresentado. E, uma vez
definida, preciso seguir essa definio de pronto risca.
Uma histria s pode ser considerada feita se cumprir o critrio de pronto. Todos do time precisam
saber a definio de pronto e aplic-la. Se necessrio, funo do Scrum Master lembrar equipe o
critrio escolhido.
38
Colunas do quadro do time
Mais adiante, veremos com mais detalhes o quadro branco do time - frequentemente chamado
de kanban, por ser uma ferramenta de sinalizao visual. comum que a sequncia de passos
que compem a Definio de Pronto do time se transforme em colunas do quadro.
Por exemplo, um time que adote a definio de pronto: pronto quando est desenvolvido,
testado e aprovado pelo P.O. ter um quadro com cinco colunas:
A fazer | Desenvolvendo | Testando | Aprovando (P.O.) |
6.7 Na prtica: Demora no feedback

Uma falha comum demorar para receber feedback do usurio final e isto pode ocorrer por diversos
motivos, at mesmo durante a adoo de prticas geis.
Se no testamos ou no obtemos feedback do usurio final - aquele que vai usar o produto - temos uma
diferena de viso entre quem aprovou a histria e o que ser realmente necessrio. Com isso aparece
um acmulo de bugs ou funcionalidades estranhas ao usurio, que, provavelmente, no sero utilizadas.
Por isso a recomendao fazer todo o possvel para que as aprovaes sejam feitas pelos usurios ou
clientes e no pelo Product Owner.
Algumas empresas tm dificuldades em fazer reviews com todos os clientes interessados no que foi
construido em uma iterao porque o nmero de clientes muito grande. Nesses casos, tente trabalhar
com equipes de clientes beta, que acessam a funcionalidade primeiro e do feedback antes de liber-la
para todos os usurios.
Para esse grupo de beta-testers escolha clientes reais e no alguns que usaro o sistema somente com o
intuito de test-lo. O feedback de usurios reais o que procuramos nessa reunio.
Alm das reviews, mais interessante ainda que o software que est sendo produzido entre em produo
o mais rapidamente possvel e que o time apenas v incrementando ele. No lado tcnico, uma prtica que
auxilia muito nessa entrega a continuous delivery. H diversos artigos tcnicos sobre o tema e um livro
recomendado sobre o tema tem o nome da prtica e voc pode ver mais sobre ele no livro homnimo
tcnica, escrito por Jez Humble e David Farley.
39
6.8. Retrospectiva
6.8 Retrospectiva
A Retrospectiva a ltima atividade de um Sprint. Ela tambm tem durao limitada em aproximada-
mente 3.75% do tempo total do Sprint, segundo a verso mais nova do Scrum Guide. Isto , para um
Sprint de duas semanas, a retrospectiva leva 3 horas. Nas verses anteriores do texto, o time-box era de
5% e, dada a importncia dessa reunio, opinio da Caelum que os 5% originais poderiam se manter.
Frequentemente negligenciada, a retrospectiva o momento de reflexo e exposio de problemas de

um time e, portanto, o momento no qual se melhora o processo, evidencia-se e resolve-se problemas
que afligem a equipe.
um erro grave considerar que essa reunio menos importante.
Conhecer o que incomoda a equipe e discutir os problemas uma excelente forma de reduzir os des-
perdcios e prevenir que problemas pequenos se tornem crnicos e se arrastem at o fim do projeto - ou
at a infortuna sada de membros do time.
Resolver os problemas positivo para a moral da equipe. Conforme os problemas se acumulam e se

arrastam pelo tempo de desenvolvimento do projeto, o time se desmotiva cada vez mais. Vendo-os
serem resolvidos, no entanto, o time ganha um novo nimo.
H diversas maneiras e tcnicas para realizar boas retrospectivas. A mais comum e simples funciona da
seguinte maneira:
(exceto na primeira retrospectiva) Uma releitura das aes levantadas na retrospectiva passada
feita para que todos se lembrem do que foi planejado.
Cada membro do time ganha caneta e post-its;
Cada um, sem olhar opinies alheias ou conversar, escreve os pontos que achou negativos e posi-
tivos nesse Sprint. Cada pessoa escrever diversos post-its, um por assunto levantado;
Quando todos escreverem, colam-se os post-its em um lugar visvel para todos, j tentando agru-
par os itens semelhantes;
Um membro do time revisa os post-its, melhorando o agrupamento de assuntos parecidos e narra

o que foi escrito. Naturalmente, problemas mais srios aparecero em grupos com mais post-its;
A equipe discute como resolver os problemas apontados j no prximo Sprint. Dessa discusso
vir ao menos uma ao que esteja ao alcance do time para solucionar ou reduzir o problema;
O mesmo feito com os pontos positivos. Apenas, s anotamos os lembretes realmente necess-
rios juntamente s aes.
Anota-se as aes discutidas e mantem-se em local visvel durante o Sprint, como lembrete.
40
Sugerimos que narrao das opinies sempre comece pelos problemas, j que eles precisam ser discuti-
dos e resolvidos - e o Scrum nos coloca um time-box fixo a ser respeitado. Os post-its positivos tm como
funo lembrar quais prticas devem ser mantidas ou comemorar aprendizados novos. Os negativos,
para encontrar pontos de melhoria e reduzir riscos e desperdcios.
No h culpados
A retrospectiva uma ferramenta de melhoria para a equipe e os post-its podem ser escritos anoni-
mamente inclusive para que todos os erros e problemas sejam relatados. Mas vale lembrar aqui que
problemas so da equipe, no de um membro em particular - e apela-se ao bom senso de cada um do
time para no escrever ofensas pessoais.
A retrospectiva no um momento de acusaes, mas sim de reflexo e melhoria.
Dessa forma, tambm, no se deve levar para o lado pessoal as crticas feitas ao grupo. Por mais que
algum se identifique com o que est sendo criticado e tenha uma razo para tal, o objetivo da retros-
pectiva encontrar solues para o problema - no colecionar razes ou desculpas.
papel do Scrum Master lembrar a equipe disso sempre que necessrio.
6.9 Daily scrum

Durante todo o Sprint, diariamente e com durao mxima de 15 minutos, acontece o Daily Scrum. Essa
breve e informal reunio acontece sempre nos mesmos horrio e local combinados e dela participam
apenas os membros do time, isto , desenvolvedores, Scrum Master e Product Owner.
Elas funcionam da seguinte maneira:
No horrio determinado, cada membro do time se levanta e vai ao local combinado;
Todos em p, um por vez, respondem s seguintes perguntas:
1) O que fiz desde o ltimo Daily Scrum?
2) O que farei at o prximo?
3) Quais problemas esto me atrapalhando?
Se algum tiver uma sugesto breve, se identifica para que, aps o daily scrum, os interessados se
reunam para resolver o problema juntos. Isso porque o Daily Scrum tem limite de tempo de 15
minutos.
O objetivo dessa reunio melhorar a comunicao na equipe e dar para todos uma viso mais clara
do andamento do time no Sprint. Alm disso, ela facilita a identificao e resoluo de problemas e
impedimentos.
41
6.9. Daily scrum
Outra forte razo para o Daily acontecer o fato de que no h a definio prvia de que desenvolvedor
vai fazer cada tarefa. Para que cada um tenha a liberdade de escolher tarefas onde pode colaborar mais
e no acontea trabalho repetido, necessrio que cada um saiba os que os outros esto fazendo e o que
pretendem comear em breve.
Da mesma forma, o objetivo do Daily Scrum no prestar contas ao cliente. O time pode permitir ou
no que o cliente participe do Daily Scrum e, se permitir, comum que o cliente participe apenas como
ouvinte.
A brevidade do Daily Scrum tambm tem bons resultados documentados em melhorar a capacidade de
expresso dos membros do time e na tomada rpida de deciso, quando necessrio.
Respeitar o time-box de 15 minutos dirios no somente possvel mas tambm bastante importante.
Pense a respeito: estamos consumindo o tempo de todos os membros do time para que eles estejam
presentes. uma questo de respeito com o time, o cliente e o produto fazer essa reunio eficientemente
e no divagar.
Lembre-se: os problemas sero resolvidos aps a reunio, apenas pelas pessoas que tm algo a acrescen-
tar na resoluo deles, evitando entediar e ocupar desnecessariamente o tempo dos outros.
42
Captulo 7
Artefatos do Scrum
A sabedoria comea na reflexo

Sneca
Para manter uma melhor visibilidade do que ainda h para fazer e do que j foi feito tanto no projeto
como um todo quanto em um Sprint, algumas ferramentas so sugeridas pelo prprio framework.
A essas ferramentas que j vm do prprio Scrum, d-se o nome de artefatos. Eles so duas ferramentas,
eventualmente usadas para mais de um fim. So elas: Product Backlog e Sprint Backlog.
Mas antes de comear a v-las, vamos relembrar uma das frases do Manifesto gil:
Indivduos e interaes mais que processos e ferramentas
Essas ferramentas esto presentes para ajudar a organizar o desenvolvimento e obter mtricas potenci-
almente importantes para a equipe. Se, em algum momento, elas passarem a atrapalhar a equipe, elas
podem ser deixadas de lado - no por preguia, mas sim por estarem no caminho do time.
7.1 Product Backlog

Tradicionalmente, o levantamento de requisitos de um projeto feito antes mesmo da avaliao da
viabilidade de um projeto, j que ele parte dessa avaliao. Em aplicaes de Scrum no mundo real,
isso no diferente.
A diferena comea quando, em mtodos tradicionais, limitamo-nos lista inicial de requisitos e nunca
ou raramente a atualizamos. Mtodos geis aceitam que mudanas sejam feitas aos requisitos inici-
almente levantados. O Scrum utiliza esse levantamento inicial como uma verso inicial do Product
Backlog.
7.2. Histrias e tarefas
O Product Backlog uma lista nica, ordenada, do que ainda h a ser feito no projeto. Ele prov uma
viso melhor ao Product Owner do que ainda h para ser feito e o que tem mais valor na produo de
um projeto de sucesso.
O Product Owner o responsvel por manter o Backlog alinhado com as necessidades do cliente em
cada momento e disponvel para consultas dos desenvolvedores e clientes.
Note que todos, clientes e desenvolvedores, podem opinar sobre o Product Backlog, mas apenas o P.O.
pode alter-lo.
7.2 Histrias e tarefas

Usualmente, os itens listados no Backlog so escritos em forma de User Stories, ou simplesmente His-
trias. Essas, so pedidos de itens de valor para o projeto que se est desenvolvendo e contm trs
informaes importantes:
por que importante que o sistema tenha essa funcionalidade;
que tipo de usurio se beneficia mais com essa funcionalidade;
objetivamente, o que se quer que o software faa.
Sabendo da motivao e importncia de cada histria, o P.O. consegue prioriz-las melhor. O pedido
objetivo de uma parte nova facilita aos desenvolvedores entenderem o que deve ser produzido. O tipo de
usurio que utilizar o sistema facilita tanto ao P.O., que pode balancear os usurios atendidos durante
os Sprints e aos desenvolvedores, que sabero com quem tirar dvidas, se essas surgirem e mesmo qual
o foco dessa funcionalidade.
44
Captulo 7. Artefatos do Scrum
Escrevendo boas histrias
Uma boa story deve poder ser lida fluentemente, como uma historinha mesmo. Tome cuidado
para no escrever a motivao para a construo da histria da viso de uma pessoa e dizer que
o maior interessado outro.
Veja um mau-exemplo de histria:
PAGAMENTO EM BOLETO
Para que o comprador possa pagar sem carto de crdito
Como comprador
Quero que o sistema d suporte emisso de boletos
Uma pequena alterao da grafia faz muito mais sentido e torna a leitura mais fluente:
PAGAMENTO EM BOLETO
Para que eu consiga comprar produtos nessa loja
Como comprador que no tem carto de crdito
Quero que o sistema d suporte ao pagamento em boleto
7.3 Exerccio prtico: criao de histrias

No prximo exerccio, ensaiaremos o processo de criao de histrias para o projeto proposto pelo
instrutor. As histrias devem ser coerentes com o sistema em cada momento.
Siga as instrues do instrutor no Workshop de histrias e construo de um Product Backlog inicial.
7.4 Priorizando bem um Product Backlog

Quando o Product Owner pergunta pela primeira vez: o que mais importante para entregar nesse
primeiro ciclo de release? a resposta clssica de qualquer cliente seria Tudo!. papel de um bom P.O.
ajudar o cliente a ver potenciais entregas parciais que j sero utilizveis, mas mesmo ele, se tiver vindo
de tcnicas mais tradicionais, pode no ver valor em trabalhar de forma incremental.
Uma das principais dificuldades que um P.O. encontra ao priorizar seu backlog nas primeiras vezes est
ligado ao seu desejo de apresentar o produto completo para seus clientes. preciso, no entanto, manter
em mente que mtodos geis promovem a construo do software aos poucos, agregando o maior valor
45
7.4. Priorizando bem um Product Backlog
possvel a cada momento e recebendo feedback no caminho.
Imagine a situao de um produto que controla venda de tickets de eventos musicais. O sistema pen-
sado e acessado da seguinte maneira:
Um administrador cadastra eventos, o usurio final busca um evento, se cadastra no site, escolhe a cadeira
- se possvel, efetua o pagamento e finalmente imprime o ingresso.
Priorizao sem objetivo de utilizvel
Dado esse fluxo, a abordagem tradicionalmente utilizada a de priorizao do backlog de acordo com a
ordem de acesso do sistema - seguindo exatamente a ordem das funcionalidades que o cliente acessar
em sua interface:
1) cadastro de administrador do sistema
2) gerenciamento de eventos (cadastra, remove, atualiza, cadastra cadeiras marcadas)
46
3) busca de eventos
4) cadastro de usurios e comentrios para eventos
5) escolha de cadeiras
6) receber pagamentos
7) emisso de bilhetes
Para fins didticos, supondo uma necessidade uniforme de 3 semanas para a execuo de qualquer
histria, o P.O. s possui um site que agrega valor a sua empresa no final de 4 meses e 2 semanas, e com
suporte a emisso automtica aps 5 meses e 1 semana.
Somente no final desse perodo ele ter feedback dos usurios finais, aqueles que se comportam de
maneira imprevisvel e detectam bugs que no imaginvamos existir.
O que aconteceu? As histrias foram priorizadas de acordo com o momento em que elas aparecem no
fluxo de acesso ao software. Mas... precisamos mesmo de todas essas histrias completas para entregar
valor e permitir o uso do software pelo cliente?
Priorizando para minimizar o tempo de entrega
Vamos tentar, agora, uma abordagem um pouco diferente de priorizao. Note que tambm possvel
priorizar as mesmas histrias de uma forma um pouco diferente:
1) criao e atualizao de eventos com senha master (1.5)
2) busca de eventos (3)
3) cadastro de usurios e comentrios para eventos (3)
4) receber pagamentos (3)
5) emisso de bilhetes (3)
6) cadastro de cadeiras para eventos (1.5)
7) escolha de cadeiras (3)
8) cadastro de administrador do sistema (-)
9) remoo de eventos (-)
Com essa priorizao, temos:
`ms: um site de busca de eventos
`meses: um site colaborativo de eventos
47
7.4. Priorizando bem um Product Backlog
`meses e meio: as vendas online iniciam
`meses: emisso de bilhetes online revoluciona o mercado
3 meses e meio: escolha de cadeiras online revoluciona o mercado
Note que o prprio desenvolvimento passa a poder ser pago pelas vendas que foram geradas aps dois
meses e meio.
Por no tentar seguir o fluxo do usurio em um sistema, mas sim entregar funcionalidades que ele pode
utilizar desde o incio, o P.O. e sua empresa ganham uma enorme vantagem competitiva no mercado de
venda de ingressos online.
Se duas empresas comearam a desenvolver sistemas com as histrias citadas, cada um usando uma das
priorizaes sugeridas, quando a primeira entregar o sistema, a empresa que utilizou a segunda priori-
zao j possui uma comunidade de usurios forte, um sistema com menos bugs e gerando dinheiro h
algum tempo. A segunda empresa obteve retorno real 50% mais rpido que a primeira.
Ainda poderamos estender essa discusso mais um pouco. Note que a segunda empresa tem algo entre-
gvel e disponvel j desde o primeiro ms e, desde ento, agrega feedback rico dos usurios do sistema,
entendendo suas necessidades e se adaptando de acordo.
Alm disso, e por causa das entregas desde cedo, note que dois itens do backlog, que pareciam necess-
rios de princpio, foram deixados de lado porque percebeu-se que eles no eram realmente necessrios.
Uma boa priorizao est perfeitamente de acordo e traz consigo o primeiro princpio gil:
"Nossa maior prioridade satisfazer o cliente atravs de entregas frequentes e desde cedo de software
de valor.
Backlog eletrnico ou manual?
Diversas empresas que adotam Scrum utilizam uma das muitas solues em software para guardar e
administrar seu Backlog. Outras, preferem utilizar papel e caneta e guardar seu backlog em cartes de
papel ordenados.
Qual a melhor soluo? Como qualquer outra questo, depende.
As vantagens de um backlog em software que fcil guardar histrico da data de criao e de execuo
de tarefas. Dessa forma, possvel programar a extrao de mtricas como, por exemplo, qual o tempo
de resposta para histrias que passem pelo backlog.
Ele tambm pode auxiliar no caso de uma equipe geograficamente distribuida, que realidade em di-
versas empresas, muito embora tal prtica adicione uma complexidade de comunicao.
48
Em compensao, histrias em papel so mais fceis de visualizar e replanejar. Basta uma mesa grande
o bastante para espalhar as histrias mais prioritrias. Clientes que queiram escrever histrias tambm
costumam ter mais facilidade com papel.
Alm disso, o Backlog em papel particularmente prtico se a equipe utilizar um Kanban (quadro
branco com histrias) para visualizar o que est sendo feito num Sprint. Basta transportar as histrias
diretamente do Backlog para o quadro.
H, tambm, diversas empresas que decidem implantar o Scrum e comeam pela adoo (ou compra)
de uma ferramenta online para armazenar o backlog. Essa prtica fundamentalmente errada. As ferra-
mentas devem surgir conforme a necessidade, e no mesmo antes dos mtodos geis serem assimilados.
7.5 Na prtica: mudando o product backlog a qualquer

instante
Permitir reorganizar o backlog a todo instante - e manter o backlog sempre priorizado - uma necessi-
dade que abre caminho para adaptaes s novas necessidades do mercado. Ela permite obter resultados
mais significativos mais rpido.
O que acontece quando o que foi definido no primeiro levantamento sobre o produto seguido como
regra at o trmino do projeto? Tudo o que mudou na empresa fica para trs, o software j nasce me-
ses atrasado com relao ao processo que a empresa usa ou necessita hoje. Para responder rpido s
mudanas do mercado e da empresa, estritamente necessrio poder adaptar suas prioridades.
Lembre-se do princpio gil:
"Receba bem a mudana de requisitos, mesmo tardias no desenvolvimento. Processos geis enca-
ram mudanas para vantagem competitiva do cliente.
Definio da viso do projeto
Frequentemente, interessante que ainda no comeo do projeto, uma viso do que sucesso para esse
projeto em especfico seja formulada junto ao cliente.
Essa viso pode ser algo mais vago e mudar com o tempo, mas incomum que ela mude muito. Um
exemplo de viso de um projeto poderia ser: Facilitar o processo do pessoal de vendas, permitindo que
vendam mais por pessoa.
49
7.6. Sprint Backlog
7.6 Sprint Backlog

A cada Sprint, o subconjunto mais prioritrio do Backlog separado para ser feito pelos desenvolvedo-
res. A esse subconjunto, dado o nome de Sprint Backlog. Vimos tambm que, no Planning, histrias
so quebradas em itens tcnicos, as tarefas. O Sprint Backlog composto das tarefas e suas respectivas
histrias.
A mdia de granularidade das histrias do Sprint Backlog usualmente mais fina do que a do Product
Backlog. Isso necessrio porque os desenvolvedores no poderiam se comprometer com histrias
grandes e mal definidas. Se essas so as histrias mais prioritrias, elas devem estar melhor especificadas
e quebradas.
Essa quebra acontece em diversos momentos: o P.O. pode pedir ajuda dos desenvolvedores para quebrar
as histrias mais importantes do prximo Planning, durante o planejamento o time pode achar melhor
quebrar uma histria grande em algumas menores, na negociao com o cliente podemos descobrir que
parte da histria no to prioritria (ou sequer necessria), etc.
Diferentemente do Product Backlog, o cliente no tem voz sobre o Sprint Backlog: no recebemos novos
itens nesse Sprint. Pedidos entraro no Product Backlog e, se forem de fato as histrias mais importantes,
sero apresentadas no prximo Planning. Pode-se, com ressalvas, alterar a ordem importncia entre os
itens, mas mesmo essa mudana no recomendada.
Mas... eu preciso mudar o Sprint!
A necessidade de mudana do um Sprint Backlog por parte do cliente no algo que deveria acontecer
e uma sinalizao de que h algo errado na relao que envolve o P.O., o Product Backlog e o cliente.
Nessa situao, algumas das partes no esto se entendendo e o custo envolvido alto: o tempo do time
todo foi desperdiado no somente em comear tarefas que perderam importncia, mas tambm com a
mudana de contexto, replanejamento e no Planning anterior. Outro preo que se paga a desmotivao
do time que sente, com direito, que seu tempo e esforo foram em vo.
Manter um backlog bem priorizado e o cliente alinhado a todo tempo so as formas mais comuns de
evitar esse custo.
A escolha da meta
Baseado no Sprint Backlog, o P.O., com ajuda do restante do time, define qual ser o objetivo maior do
Sprint e define sua meta. Ela ficar exposta durante todo o Sprint para lembrar aos desenvolvedores pelo
que esto trabalhando neste momento.
A meta uma frase concisa que exprime o maior valor daquilo que est sendo desenvolvido para o
cliente. Boas metas exprimem o que o cliente ser capaz de atingir atravs dos incrementos planejados
50
para esse Sprint. Um exemplo de sequncia de metas para o projeto de venda de tickets descrito mais
cedo nesse captulo :
"Lanar uma central de eventos bsica, permitindo o incio das campanhas de marketing;
"Estimular a divulgao para amigos atravs de estratgias sociais;
"Aproveitar a massa de usurios para vender ingressos;
"Prover uma experincia diferenciada para os usurios, com reservas especiais.
Exemplos sem sentido, embora muito mais frequentes do que gostaramos, de metas seriam fazer todos
os itens do Sprint Backlog ou, pior ainda, entregar tantos porcento do Sprint Backlog. Oras! Quando
entramos em um Sprint, sempre pretendemos fazer todos os itens do Sprint Backlog.
7.7 Sprint Burndown

Uma forma bastante usada para acompanhar o andamento de um Sprint um grfico simples de pontos
com os quais o time se comprometeu por dia til do Sprint. A figura abaixo um BurnDown chart de
um Sprint de 10 dias no qual a equipe se comprometeu com 77 pontos.
A linha vermelha representa a velocidade esperada com a qual a equipe finaliza os pontos com os quais
se comprometeu. A linha azul, a quantidade real de pontos executados a cada momento.
Sempre que a linha azul fica abaixo da vermelha, a equipe sabe que est indo melhor do que o esperado
e terminando tarefas num ritmo maior do que o prometido. Quando fica acima, no entanto, quer dizer
51
7.8. Alternativas aos artefatos
que est mais devagar do que o esperado e corre o risco de no conseguir terminar todas as tarefas com
as quais se comprometeu.
O grfico em lugar visvel uma forma de comunicao passiva que ajuda a equipe a prever mais cedo
se sobrar ou faltar tempo no Sprint. O burndown tambm evidencia alguns problemas de estimao
de histrias e, por vezes, outros problemas como cliente inacessvel.
O detalhe mais importante sobre o grfico de Burndown que linha azul s cai quando as histrias feitas
passam pela definio de pronto da equipe.
Por histria ou por tarefa?
O ltimo Scrum Guide que mencionava o grfico de Burndown propunha tra-lo com relao
s tarefas, em vez de histrias. Pela nossa experincia, basear o grfico em tarefas pode dar muita
importncia para informaes menos relevantes para um time gil.
Terminar uma tarefa no traz benefcio para o usurio e, portanto, para o projeto. O perigo em
traar tal grfico em termos de tarefas distrair o time do real propsito de um Sprint: agregar
valor para o cliente.
Leia mais sobre esse assunto e outras mtricas teis no blog da Caelum: http://blog.caelum.com.
br/pensando-em-metricas-para-times-ageis/
7.8 Alternativas aos artefatos

Existem Product Owners que no se adaptam idia de Product Backlog e tm grandes dificuldades
em mant-lo completo e priorizado. frequente que essas pessoas tenham, no entanto, uma sugesto
prpria de forma de organizao do que ainda h para ser feito no projeto. E no h problema nisso.
Um P.O. tem a liberdade de se organizar da maneira como preferir desde que as informaes que cons-
tariam no backlog figurem em algum lugar igualmente acessvel aos desenvolvedores.
Da mesma forma, h equipes que no se adaptam ao Burndown recomendado pelo Scrum por diversas
razes. Essas equipes podem optar por mtricas diferentes que tragam as mesmas informaes e/ou
outras mais relevantes.
Algumas mtricas que podem ser interessantes so: Bugs resolvidos x Bugs reportados, interrupes,
sensao de produtividade (ou felicidade) do time, quadro de pareamentos, etc. Cada uma delas foi
criada para evidenciar problemas especficos. Lembre-se: se uma mtrica deixou de ser til, elimine-a!
52
Quadro do time
A ferramenta mais comumente utilizada por times geis, independentemente do processo adotado, o
quadro branco do time. Ele uma ferramenta de gesto visual e, por isso, costuma ser chamado tambm
de kanban.
Quando usado por times Scrum, o quadro do time costuma ter os passos da Definio de Pronto como
colunas por quais cada tarefas ou histrias passam, na horizontal, e ser populado com o Sprint Backlog
na vertical, do item mais prioritrio ao menos importante.
Tambm comum guardar um canto do quadro para escrever a meta do Sprint e as aes levantadas na
retrospectiva anterior - ou, pelo menos, as que precisam de lembretes mais frequentes.
Se sua equipe estiver toda co-localizada, experimente centralizar as informaes do andamento do seu
Sprint em um quadro branco! Ento, atravs das retrospectivas, permita que o time mude a forma de
us-lo - essa uma experincia enriquecedora para o time.
53
Captulo 8
As pessoas no Scrum
Quase sempre minorias criativas e dedicadas tornam o mundo melhor.

Martin Luther King Jr.
8.1 O Time
No apenas o Scrum, mas qualquer metodologia gil, entende que um projeto depende profundamente
das pessoas envolvidas nele. No texto do Manifesto gil, j lemos:
Indivduos e Interaes sobre processos e ferramentas
Enquanto nos mtodos tradicionais o processo tentava restringir escolhas ao mximo para evitar pro-
blemas, os mtodos geis prezam pelo exato contrrio: acreditamos que, confiando na equipe, teremos
solues melhores, com arquiteturas ricas e mais adequadas s necessidades do cliente.
E essa confiana permeia todo o processo e todos os papis. Vendo resultados rapidamente, o cliente
passa a confiar na equipe. Scrum Master e Product Owner, participando dos esforos dirios como
membros do time, vem o projeto crescer. E os desenvolvedores sabem a quem recorrer para tirar im-
pedimentos do caminho.
por isso, tambm, que comumente chamamos equipes geis de time: assim como num esporte,
preciso confiar no outro para alcanar um objetivo comum.
8.2. No h culpados
8.2 No h culpados
Infelizmente, prprio da nossa cultura procurar culpados quando algo d errado, em vez de buscar
solues. E, apesar desse comportamento ser absolutamente improdutivo, a forma com que estamos
acostumados a reagir - no h espao para isso num time gil.
Um time gil responde como um organismo nico. Se foi bem sucedido, o sucesso de todos. Se houve
falhas, as falhas foram de todos. A razo que se algum teve dificuldades e ningum o ajudou, foi uma
falha do time.
Assim como em Lean, tudo o que no traz valor para o cliente desperdcio. Ento, em vez de gastar
tempo procurando a quem culpar, o foco do time outro: encontrar uma ao vivel que resolva ou
diminua o problema. a tal proatividade, buzzword que explodiu alguns anos atrs.
Mas, ento, o que fazer quando h algum no time que atrapalha a produtividade?
O Scrum promove a transparncia e tanto o Daily Scrum quanto o quadro de acompanhamento so

mecanismos que deixam vista tudo o que acontece no time - tanto coisas boas, quanto as ruins.
Se h realmente uma pessoa atrapalhando, isso estar visvel e certamente ser discutido nas retrospec-
tivas do time. Se for necessrio expelir a tal pessoa do time, o time tomar essa deciso. interessante
que o time tenha a liberdade para tomar esse tipo de deciso. Lembre-se do princpio gil que diz:
Construa projetos com pessoas motivadas. D a eles o ambiente e o suporte que precisam e confie
que faro o trabalho.
8.3 Eles so pessoas!

H muitos rtulos aplicados a pessoas no desenvolvimento de software. H o gerente, o lder de projeto,
o lder tcnico, o desenvolvedor, o testador, o arquiteto, o analista... E muitas vezes h quem se refira a
membros da equipe como recurso, um termo considerado pejorativo e bastante desmotivador.
Uma caneta, um computador, cartes e post-its so recursos: quando eles no servem mais, jogamos
fora e trocamos por outro sem perda alguma. Eles so instantaneamente substituidos.
No podemos dizer o mesmo de pessoas! H diversas reaes do time quando algum membro vai
embora. Por pior que fosse o funcionrio, ele leva consigo o conhecimento de negcios. Tirar uma
pessoa do time, ou mesmo adicionar uma, tambm quebra o equilbrio geral.
Essa quebra de equilibrio no necessariamente ruim, mas algo que precisa ser levado em conside-
rao na escolha do momento para uma demisso ou contratao. Evite mudar a equipe em sprints
particularmente conturbados, principalmente sem conversas prvias com todos.
56
Captulo 8. As pessoas no Scrum
Tratar pessoas com respeito fundamental em qualquer ambiente e, particularmente no contexto de

agilidade, imprescindvel para que todos se sintam comprometidos e responsveis pelo ambiente, pro-
cesso e produto.
8.4 Time auto-gerenciado e os papis

Proatividade , de fato, uma palavra importante em um time de Scrum. No nosso contexto, ela significa
no esperar ordens para fazer uma determinada tarefa, escolher o que fazer, tirar empecilhos do caminho
quando eles acontecem, entre outras atitudes. Essa a habilidade fundamental de um agilista e o que
faz do auto-gerenciamento algo natural.
importante perceber que poder gerenciar a si prprio uma vantagem para o desenvolvedor, para o
gerente do time e, em ltima instncia, para o projeto e para todas as pessoas envolvidas nele.
O desenvolvedor tem mais espao para crescer e pode implementar boas idias que tiver ao longo do
caminho. Seu superior pode focar nas coisas que realmente importam para ele, no panorama mais
geral da empresa. E o projeto se beneficia das melhorias pessoais, sempre melhorando em qualidade.
Relembre o princpio:
As melhores arquiteturas, requisitos e design emergem de times auto-organizados.
possvel trabalhar de forma gil numa equipe completamente horizontal - e implantar agilidade em tais
equipes muito mais fcil. pr-requisito para ambientes horizontais as pessoas se auto-gerenciarem.
Contudo, tais ambientes so raros no mundo corporativo atual.
Inserido em um mundo acostumado com hierarquias, o Scrum se adaptou dando ttulos aos membros
do time que mais precisam resolver situaes e falar com clientes. Tais ttulos seriam desnecessrios
em uma equipe completamente auto-gerenciada - por exemplo, conforme um impedimento surgisse,
qualquer um se proporia e teria os meios para resolv-lo.
Tal modelo funcionaria perfeitamente se todos os membros da equipe tivessem igual liberdade na hi-
erarquia da empresa. Os ttulos de Scrum Master e Product Owner facilitam a vida de quem precisa
resolver esses problemas, independentemente do estilo da empresa.
Nas prximas sees, veremos o que e o que no responsabilidade de cada um dos papis do Scrum.
8.5 Product Owner

O Product Owner (P.O.) o representante do cliente dentro da equipe de desenvolvimento de software.
Isto , ele o responsvel por entender o que o cliente precisa, montar um plano que faa sentido para
o projeto e transport-lo para conhecimento dos desenvolvedores.
57
8.6. O P.O. parte do time?
Por mais simples que possa parecer, essa uma tarefa bastante complexa porque envolve entender como
o sistema ser utilizado pelos usurio finais e priorizar o que ainda h para ser feito de forma a trazer o
mximo possvel de valor para o cliente a cada entrega.
Pensando como o cliente
Pense, por exemplo, em um sistema de administrao de uma pequena farmcia: o vendedor usa
o sistema para procurar e verificar disponibilidade de medicamentos, enquanto o caixa d baixa
no sistema na venda de algum item.
Considere agora, se houver uma parte de manipulao nessa farmcia e, portanto, o farmacutico
que desenvolve os remdios, marca pedidos como prontos e administra o estoque de frmacos.
Tambm h o dono da farmcia, que precisa comprar novos medicamentos conforme o estoque
se esgota e se assegurar de que medicamentos vencidos no sejam vendidos.
Todos esses personagens falam com o P.O. e, cada um tem a certeza de que sua parte a mais
importante. Cabe ao Product Owner decidir a quem atender em qual momento de forma a
sempre trazer valor aos clientes e tornar o projeto to satisfatrio quanto possvel.
Por esse mesmo conflito de interesses, importante notar que o Product Owner uma pessoa e
no um grupo de pessoas, um comit. E ningum, nem de dentro nem de fora da equipe, pode
passar por cima de suas decises.
Quando trabalhando com Scrum na produo de projetos internos, o Product Owner idealmente um
dos usurios finais do sistema, alocado para guiar a equipe de desenvolvimento e tirar suas dvidas
durante a construo do sistema.
J em projetos de consultoria onde o cliente no pode disponibilizar uma pessoa para auxiliar na cons-
truo, a pessoa que tem uma viso mais geral do projeto e das necessidades do cliente deve ser eleita
para essa funo.
Usualmente, em transies dos mtodos tradicionais de desenvolvimento para o Scrum, gerentes de

projeto ou analistas ficam com esse papel. Eles so as pessoas que usualmente entendem o horizonte do
projeto e a direo a seguir e, dessa forma, so indicados para essa importante funo.
8.6 O P.O. parte do time?

Muitas so as vezes que ouvimos frases como o time e o P.O. fizeram algo. Tal frase apenas explicita o
sentimento geral das pessoas de que somente desenvolvedores formam o time. Mas... o P.O. parte do
time?
58
Sim! O Product Owner faz parte da equipe e, como tal, deve participar do dia-a-dia da equipe e acom-
panhar a produo do sistema.
Tanto para garantir que o sistema saia da forma esperada quanto para entender as decises da equipe e,
eventualmente, o porqu de um atraso ou alguma outra falha, o P.O. precisa estar comprometido com
o projeto, no apenas envolvido.
Na tirinha acima, amplamente conhecida na comunidade de Scrum, a galinha est apenas envolvida com
o processo: ela sempre pode produzir mais ovos e perder alguns ovos no lhe trazem grande prejuzo.
J o porco est ligado ao restaurante de forma vital: para haver presunto, ele precisa investir algo no
reprodutvel.
Todos os membros do time devem ser pigs, isto , devem estar comprometidos com o sucesso do projeto,
sentindo-se responsveis por ele. Product Owner, Scrum Master e Desenvolvedores so pigs - clientes
so os apenas envolvidos com o projeto, frequentemente chamados de chickens por causa da mesma
tirinha.
8.7 O dia-a-dia do Product Owner

Em seu dia-a-dia, o Product Owner deve:
participar dos Daily Scrums;
responder s dvidas dos desenvolvedores sobre o que est sendo desenvolvido ou indicar quem
poderia respond-las melhor;
prover uma meta clara para cada Sprint;
obter feedback e expectativas dos clientes e extrair delas as necessidades;
59
8.7. O dia-a-dia do Product Owner
manter o Product Backlog atualizado, isto :
adicionar itens novos;
remover itens desatualizados;
revisar a priorizao do backlog constantemente.
E, ao mesmo tempo, o P.O. no deve:
saber a resposta para qualquer pergunta, mas sim a quem recorrer;
dizer aos desenvolvedores como, tecnicamente, fazer uma tarefa;
cobrar os desenvolvedores como gerentes tradicionais cobravam;
acumular, tambm, o papel de Scrum Master.
Enquanto o Product Owner tem como objetivo maior cuidar dos interesses do cliente e torn-lo mais
acessvel equipe, outra pessoa precisa atentar para as necessidades do time.
Na prtica: barreira semi-permevel
Acontece com alguma frequncia de o Product Owner no saber responder uma pergunta do desenvol-
vedor. O que fazer nesse caso?
Muitos respondero que ento o P.O. deve perguntar para o cliente e trazer a resposta para seu desenvol-
vedor to logo quanto possvel. Mas... considere bem: isso no exatamente voltar quela to perigosa
comunicao indireta?
O desenvolvedor, em caso de dvida, deve perguntar os detalhes ou informaes pontuais diretamente

ao usurio do sistema. Dessa forma, evitamos a perda ou modificao de informaes na comunicao
entre as partes.
Isso quer dizer que, embora os clientes no podem pedir funcionalidades direto aos desenvolvedores,
os desenvolvedores podem livremente tirar dvidas com os clientes.
Vale lembrar que o cliente pode, a qualquer momento, pedir para o Product Owner incluir histrias no-
vas no Product Backlog. Desenvolvedores que vo falar com clientes podem, ento, levar o P.O. consigo
ou mostrar exercitar a disciplina de no aceitar pedidos para o Sprint atual, mas sim redirecion-los
para o P.O.
Na prtica: Os clientes precisam de algo urgentemente
Mas por que no podemos deixar os clientes terem acesso direto aos desenvolvedores tambm? O maior
problema est na terrvel verdade de que todo cliente precisa disso ou daquilo pra ontem - e sempre vai
precisar.
60
Tambm preciso notar que rarssimos so os casos em que um projeto tem apenas um tipo de cli-
ente com necessidades especficas. Normalmente, haver vrios clientes diferentes, com necessidades
diferentes, usando o mesmo sistema.
E se todo pedido urgente, algum precisa centralizar os pedidos de todos os clientes e decidir o que
ser resolvido primeiro e o que vir depois. Essa exatamente a funo do P.O.!
Atualizar o backlog e mant-lo atualizado deve resolver cada problema em um tempo aceitvel e preju-
dicando o mnimo possvel o software produzido e seus usurios como um todo.
um erro grave passar por cima das prioridades que o P.O. coloca: isso anula o trabalho feito por ele:
falta de respeito e, acima de tudo, viola o plano de projeto que havia sido preparado.
8.8 Problemas e impedimentos

Usamos, frequentemente, a terminologia impedimento e raramente falamos aqui de problemas. Para o
Scrum, problemas e impedimentos so conceitos diferentes.
Problemas so eventos do dia-a-dia que atrapalham a equipe e que os prprios membros podem resol-
ver sozinhos. Entre eles, podemos citar: decises de cdigo, problemas no build, reinstalao de uma
mquina, horrios conflitantes, dvidas de negcios, etc.
Via de regra, todas as dificuldades so problemas e elas s passam categoria de impedimentos quando
um ou mais membros do time efetivamente tentaram resolv-lo e no conseguiram.
Impedimentos so problemas cuja soluo no est ao alcance dos desenvolvedores. Tais problemas
so exemplificados por problemas que exigem a contratao de um servio ou compra de recursos -
como problemas de infraestrutura: internet instvel, mquinas ruins, falta de espao - ou problemas
recorrentes como clientes inacessveis, entre outras possibilidades.
Para resolver esses impedimentos o papel de Scrum Master surge. Para ele, de suma importncia
manter a equipe funcionando e, com esse objetivo, ele deve procurar solues para os impedimentos
da equipe e, nos casos em que realmente no houver soluo vivel, explicar o porqu para a equipe - e
buscar uma melhor alternativa para ameniz-lo.
8.9 Scrum Master

O Scrum Master tambm a pessoa responsvel por assegurar que o time siga o framework correta-
mente e desenvolva mantendo um ritmo sustentvel. ele que tem o dever de, durante a migrao
para o framework, lembrar ao time os valores e regras do Scrum e do Manifesto gil e fazer com que
as prticas sejam seguidas at que elas se tornem naturais para os membros do time. Tambm sua
responsabilidade manter a equipe motivada.
61
8.10. O dia-a-dia do Scrum Master
Prticas geis favorecem a motivao da equipe mas, por vezes, alguns eventos podem desmotiv-la,
como, por exemplo, impedimentos que fazem a equipe ficar parada, problemas repetitivos ou interven-
es externas frequentes.
Um bom Scrum Master funciona como um escudo para o time, impedindo que fatores externos desviem
o foco da equipe e resolvendo impedimentos conforme eles se tornam evidentes.
Por outro lado, o papel de liderana desenvolvido pelo Scrum Master tambm tem o objetivo de fazer
com que o time se torne cada vez mais auto-gerenciado e independente. Com isso em mente, um bom
Scrum Master no age como bab do time, mas sim como mentor ou, idealmente, coach.
8.10 O dia-a-dia do Scrum Master

Em seu dia-a-dia, o Scrum Master deve:
educar time e clientes sobre agilidade e o processo;
assegurar que a equipe faz o Daily Scrum no horrio certo e de modo produtivo;
resolver os impedimentos da melhor maneira possvel;
manter o foco das reunies;
identificar pontos de melhoria no processo e no ferramental.
E, ao mesmo tempo, o Scrum Master no deve:
gerenciar o time, distribuindo tarefas ou escolhendo solues tcnicas;
cobrar resultados do time;
ser a pessoa que atualiza as mtricas e as cria;
acumular tambm o papel de Product Owner.
Lder servidor no escravo
Uma das funes do Scrum Master resolver esses impedimentos, mas um erro comum de times
que comeam a usar o Scrum no atentar para a diferena entre problema e impedimento.
O Scrum Master no tem a funo de resolver problemas tcnicos que surgirem ao executar
uma tarefa. Assim como ele no tem a funo de monitorar produtividade e tambm no o
responsvel por ir buscar caf para o time.
62
A tal dualidade Product Owner vs. Scrum Master
Os papis de Scrum Master e Product Owner tm funes complementares em um time de Scrum e

provm uma dualidade saudvel, que incentiva melhorias no processo. Quando uma pessoa acumula
as duas funes, a tendncia que uma delas seja deixada de lado e que o Scrum se desbalanceie.
Isso no quer dizer que eles devem batalhar um contra o outro no dia-a-dia, mas sim que devem manter
em mente o que favorece cada parte e achar, junto aos desenvolvedores, um meio termo que agrada ao
time todo e favorece a entrega de valor para o cliente.
Muitas vezes ouvimos sobre o confronto Scrum Master x Product Owner, mas importante que no se
leve essa palavra ao p da letra. O Scrum Master e o Product Owner devem tambm trabalhar como
parte do time e procurar entender o lado defendido pelo outro.
Assim, apenas para lembrarmos que ambas as partes importam, temos dois papis que devem ser ocu-
pados por pessoas diferentes. Isto , o Scrum Master no pode ser tambm Product Owner.
O Scrum Master pode ser, no entanto, e comum que ele seja, parte da equipe de desenvolvimento do
projeto. O papel pode ou no ser rotativo e ele raramente consome todo o tempo do Scrum Master.
Assim, ele pode se dedicar ao desenvolvimento aps suas tarefas de Scrum Master. Lembre-se: acima
de tudo, o Scrum Master um lder.
8.11 Desenvolvedores
Novamente, a principal caracterstica de desenvolvedores geis seu auto-gerenciamento. Desenvolve-
dores que trabalham com Scrum tm as ferramentas e o ambiente propcio para dispensar as ordens e a
superespecificao de uma tarefa e ainda realizar seu trabalho satisfatoriamente.
O Scrum estimula o crescimento pessoal de cada membro do time e espera que a oportunidade seja
aproveitada. Isto , os desenvolvedores tm maior autonomia no projeto, mas espera-se deles que evo-
luam com o tempo.
A tendncia que, com o tempo, a equipe passe a desenvolver solues cada vez melhores e mais flex-
veis. claro que haver decises que se mostram no to positivas. Em momentos ruins, pe-se prova
o j estudado conceito de time.
Relembremos: em um time de Scrum no h pessoas culpadas por erros. O time errou como um todo.
Se dois desenvolvedores, pareando, acharam que uma soluo seria boa e outros que passaram por ela
no julgaram necessrio repens-la, o erro no de quem teve a idia, mas de todos os que no tiveram
a iniciativa de resolv-lo antes.
63
8.12. O dia-a-dia dos desenvolvedores
8.12 O dia-a-dia dos desenvolvedores

Em seu dia-a-dia, desenvolvedores devem:
Decidir a abordagem tcnica para os problemas apresentados;
Trocar informaes e ajudar os companheiros de time;
Estimar as histrias durante o planning;
Escolher sua prxima tarefa a ser feita, considerando as prioridades da Sprint;
Buscar a qualidade do projeto e a reduo de erros.
E, ao mesmo tempo, desenvolvedores no devem:
Considerar dvidas tcnicas como impedimentos - elas so apenas problemas;
Esperar que algum decida as atividades a serem feitas por eles;
Se recusar a aprender um pouco sobre outras reas de desenvolvimento.
O superespecialista
Em mtodos tradicionais, comum encontrar pessoas que fazem apenas anlise de requisitos, apenas
diagramas de arquitetura, apenas testes, apenas implantao, etc. Tal separao no saudvel e nem
possvel no conceito de time que se adota em Scrum.
Em um time de Scrum, todos devem aprender a fazer mais do que sua atividade de especialidade.
No se espera, claro, que uma pessoa cuja nica funo nos ltimos 10 anos tenha sido testador con-
siga produzir cdigo to bem quanto um desenvolvedor. Mas isso no pode imped-la de aprender a
programar partes simples do sistema, pareando com algum mais experiente nessa atividade.
A troca de experincias enriquece o produto final e evita o ressentimento que se v entre especialistas
de reas diferentes. Trabalhando lado a lado, as dificuldades dirias e solues criativas ficam mostra,
permitindo que um entenda o lado do outro.
No h lugar em agile para o tal superespecialista, que far apenas tarefas de sua especialidade.
8.13 Gerncia de projetos

Todo projeto de software precisa ser gerenciado. At projetos pequenos, de uma ou duas pessoas, tm
algum tipo de processo e de gerenciamento, seja ele prescrito ou apenas verbalmente combinado. Equi-
pes mdias e especialmente as grandes tm, contudo, uma tradicional demanda por uma gerncia que
organize o desenvolvimento e guie o projeto em direo ao sucesso.
64
Mas, em um contexto gil, como exercer o papel de gerncia?
Falar de gerncia no contexto de mtodos geis causa estranheza tanto a agilistas quanto a gerentes
tradicionais.
Muitos gerentes tradicionais acreditam na mstica que existe de que mtodos geis so anrquicos e
revolucionrios. E os agilistas estranham porque a figura do gerente tradicional no faz sentido para
mtodos geis.
O fato que gerncia necessrio e presente em ambos os mundos, apenas de formas diferentes. En-
quanto nos mtodos tradicionais a gerncia est concentrada em uma pessoa com muitas responsabili-
dades (inclusive a de gerenciar o dia-a-dia das pessoas), em mtodos geis, todos so responsveis por
gerenciar o projeto e cada um cuida de si - quase que eliminando a necessidade de gerenciar pessoas.
65
Captulo 9
Praticando Scrum
A maior tristeza no a derrota, mas no ter a oportunidade de tentar de novo.

Bernardinho
Este um captulo prtico no qual utilizaremos, em um projeto desenvolvido em Lego, as regras, papis
e artefatos do Scrum em prtica.
9.1 Scrum Lego Game

Durante a explicao do Product Backlog no captulo de Artefatos, fizemos um backlog inicial e o prio-
rizamos. A partir dele, comearemos o projeto prtico no qual exercitaremos o Scrum.
Faremos, ento, nosso primeiro Planning Meeting. Dessa reunio, sair o Sprint Backlog, com as tarefas
mais prioritrias separadas para serem executadas.
O desenvolvimento se dar em turnos de 4 minutos, representando os dias e, o ltimo minuto de cada

turno ser dedicado a um Daily Scrum.
Ao fim do Sprint, uma Review Meeting apresentar ao cliente o que foi feito e ela seguida de uma Re-
trospectiva da equipe, onde devemos pensar no que aconteceu e aplicar o conceito de melhoria contnua
proposto desde a primeira aula do curso.
Volta-se ento ao incio: planejamento do prximo Sprint e o restante, sucessivamente.
Prontos?
Mos obra!
Captulo 10
Scrum no mundo real
Saber o que certo e no faz-lo a pior covardia.

Confcio
Agora que j vimos toda a teoria sobre Scrum e pusemos nosso conhecimento em prtica no Scrum
Lego Game, vamos focar no que hoje visto e aceito em times geis que utilizam Scrum.
O contedo desse captulo foi elaborado baseado na vivncia da Caelum com Scrum em projetos inter-
nos, projetos para clientes, comerciais ou open source, e consultorias. Soma-se a essa vivncia, algumas
prticas documentada em papers apresentados nas maiores conferncias mundiais e experincias de
colegas da rea.
uma troca de experincias que enriquece esse framework que estudamos at ento.
10.1 Migrao: medos e questes

Migrao uma palavra que sempre traz medos: ela implica em abandonar o que j se estava acostumado
a fazer e tentar algo novo.
O medo o mesmo quando se migra de uma linguagem de programao procedural para uma orientada
a objetos, ou dessa para uma linguagem funcional. o mesmo medo de quando tiramos as rodinhas da
bicicleta. Estamos saindo da zona de conforto.
O que no se pode esquecer que, nesse caso, a mudana s acontece porque acreditamos que ela trar
melhorias ao status quo.
Das perguntas mais frequentes, destacamos:

10.2. Problemas clssicos de cada papel
E se a equipe no se adaptar?
A resposta dessa, volta em forma de pergunta: quando escolheram o processo anterior, a equipe teve
alternativa? Com Scrum a mesma coisa. Com a vantagem de que esse framework tem as tantas van-
tagens para o desenvolvedor j mencionadas, como o poder de deciso sobre o prprio cdigo, o auto-
gerenciamento e o nivelamento de conhecimento para cima.
Essa pergunta frequentemente sucedida por:
Mas os meus desenvolvedores no sabem decidir! Preciso que Fulano os guie.
Supondo que a equipe seja composta apenas por pessoas inexperientes, no h problema em algum
gui-los se eles sentirem necessidade, mas um guia e no uma muleta. preciso que os desenvolvedores
aprendam e pensem no que esto desenvolvendo.
Tambm acontece de subestimarmos pessoas que tm menos experincia, quando elas teriam a capa-
cidade de tomar diversas decises por conta prpria. Quando sentir essa necessidade, interessante se
policiar. Se a necessidade for real, o prprio desenvolvedor buscar ajuda.
No raro, quando se inicia o uso de Scrum, a seguinte constatao surge:
Joozinho est apresentando problemas de baixo rendimento.
Boa parte da beleza do Scrum que difcil de se esconder atrs da performance de uma equipe e
trabalhar menos. O Scrum pe os problemas em evidncia e se seu problema uma pessoa, pode-se
chegar a um ponto em que no haja meios sutis de resolv-lo.
Dificilmente, esse problema recente ou causado pela metodologia. Usualmente, o problema sempre
esteve l e apenas no pode mais ser escondido depois do Scrum. A questo se interessante pra sua
equipe, independente de metodologia, manter uma pessoa assim.
10.2 Problemas clssicos de cada papel

A principal dificuldade que os clientes da Caelum encontram na migrao para mtodos geis est ligada
com a adoao da metologia parcialmente, mas nenhuma mudana na atitude em relao a como resolver
os problemas enfrentados pela equipe.
A principal caracterstica do Scrum o time auto-gerenciado, mas exatamente essa idia frequente-
mente negligenciada.
Alguns erros so cometidos diversas vezes em determinados papis de Scrum. Destacamos os abaixo.
70
Captulo 10. Scrum no mundo real
Product Owner
Pode ser que um P.O. tcnico, durante a explicao das histrias mais prioritrias, tente influenciar nas
decises tcnicas e no deixar a equipe escolher e crescer sozinha. Alm disso, frequente ver um P.O.
tcnico quebrando histrias em partes muito pequenas para mais controle do que devia.
J um Product Owner mais desleixado pode no manter o backlog realmente atualizado e priorizado,
atrasando reunies ta. dever do P.O. manter essa lista devidamente atualizada e lev-la ao Planning
Meeting - e esse seu trabalho no tempo dedicado produo de incrementos para o projeto..
Scrum Master
comum que o papel de Scrum Master seja dado ao antigo lder tcnico de uma equipe ou a um ex-
gerente. Nesse caso preciso polici-lo para que ele no cobre a equipe como o fazia em pocas anteri-
ores.
No caso de o Scrum Master ser algum tcnico, ele deve se lembrar de que tambm no deve palpitar
em cdigo alheio se no foi requisitado. Ele deve ajudar a equipe a crescer, no segur-la para trs.
Tambm so bastante frequentes casos em que Scrum Masters tcnicos, que tambm desenvolvem no
projeto, focarem em uma histria em detrimento de suas funes de Scrum Master. O papel de Scrum
Master tem precedncia sobre qualquer outro que seja atribuido mesma pessoa. Dessa forma, asse-
gurar que se est cumprindo o processo e preenchendo as mtricas, encontrar pontos de melhoria e
facilitar as reunies primeira responsabilidade de quem tem esse papel.
Desenvolvedores
Pode ser um choque, na transio de tradicionais para agile, a liberdade que o desenvolvedor ganha e
natural que alguns demonstrem certo medo de tomar as prprias decises e levar a culpa.
importante lembr-lo de que no h culpados num time de Scrum, o time igualmente responsvel
por todo o projeto.
Raramente, mas ainda presente, h ocasies em que o desenvolvedor no quer fazer parte de uma equipe
e sim deseja somente acabar meu trabalho: o dos outros dos outros. Tal forma de pensar dificulta o
compartilhamento do conhecimento e diminui o esprito de time. Ao sentir essa dificuldade, o Scrum
Master precisa tomar atitudes rpidas.
10.3 Penalidades ldicas

Agile est intrinsecamente ligado a comida e comum us-la para motivar a equipe em alguma prtica.
71
10.4. Quando adaptar?
Comumente usada como penalidade para trabalhar problemas recorrentes, o pagamento de doces ou
bebidas uma forma ldica de resolver questes prejudiciais para a equipe.
frequente em times geis a determinao de que pessoas ausentes no Daily Scrum devem pagar algum
tipo de pedgio. No a nica. Existem outras situaes em que a mesma idia se aplica, como: enviar
cdigo que no compila ou no passa em testes de unidade para o repositrio de cdigo.
Apesar de ser uma brincadeira, h um propsito nela de melhorar deficincias da equipe. Mas eventu-
almente a brincadeira se desvirtua e os castigos educacionais deixam de influenciar: pagar um doce
deixa de custar e passa a ser natural. Nesse momento, o propsito se perdeu e todos passam a dever
muitos doces, sem se importar com isso.
Se a brincadeira chegar nesse ponto, ela deve ser imediatamente cancelada e outras medidas, tomadas.
10.4 Quando adaptar?

Scrum out-of-the-box bonito, mas em diversos casos, no s ele como qualquer metodologia pode no
se adaptar de imediato realidade de sua empresa e seu negcio.
Uma adoo parcial de Scrum, logo no incio de sua implantao em uma empresa e sem um planeja-
mento bem feito de gradativos complementos ela, podem acabar dando a impresso para as equipes
envolvidas de que a metodologia de fato no to importante para o resultado final desejado: o valor
entregue ao cliente.
Sendo assim, a indicao pela adoo total das prticas e, depois de um projeto j bem encaminhado,
a anlise do que pode ser alterado para que aumente ainda mais o retorno ao cliente - moda do Lean.
Outra opo traar um plano de adoo, que uma estratgia amplamente utilizada em consultorias
de implantao de Scrum: primeiramente adota-se o trabalho de iteraes, histrias e as reunies.
Depois de um tempo, existe a previso de implantar o conceito de tarefas. Novamente, em mais um

tempo algum outro trabalho, tudo isso para que em um prazo determinado, a metodologia esteja ro-
dando corretamente l dentro.
Nada disso impede, aps algum tempo utilizando uma determinada prtica, de abandonar esse primeiro
approach e optar por uma outra tcnica. O mais importante que seja estipulada alguma mtrica (con-
siderando o valor retornado ao cliente e qualidade do codigo) para que a remoo de algo do hall de
prticas adotadas possa ser mensurado em comparao ao funcionamento anterior. necessrio que a
avaliao no fique puramente subjetiva.
72
Captulo 10. Scrum no mundo real
10.5 Consultoria em desenvolvimento com scrum

Aplicar Scrum internamente em uma empresa excelente na implantao de uma metodologia gil, que
preza por clientes prximos e participativos. A adoo de Scrum em projetos internos muito mais fcil
por essa razo e pelo risco do uso do Scrum cair sobre a prpria empresa.
Outra histria ligada com o medo que uma empresa tem ao contratar uma consultoria de desenvolvi-
mento que utilizar uma metodologia qualquer.
Por precisar de uma data especfica de entrega e no desejar se responsabilizar por atrasos nessa data,
a empresa tenta criar contratos que a protegem e jogam a responsabilidade para a desenvolvedora. O
problema dessa abordagem e que o contratante se envolve mas no se compromete com a entrega do
projeto. Isso no faz sentido algum, j que a empresa onde o contratante trabalha que ser prejudicada
pelo possvel fracasso.
Escopo fechado
Hoje em dia, com contratos de escopo fechado, valor fechado e data de entrega fechada (com uma mar-
gem de erro), fracassos viram disputas onde o objetivo principal deixado de lado: em vez de entregar
um produto que resolve o problema do cliente, o objetivo entregar o que o contrato pediu, atenda ou
no s necessidades do cliente.
A grande pergunta est em: sua empresa deseja seu problema resolvido ou a garantia de o que est no
contrato seja cumprido?
A deciso dificil e por isso mesmo o mercado no salta rapidamente para consultoria nesse modelo,
apesar dos diversos casos de sucesso desse modelo no exterior. Isso se deve ao fato de o risco que o
contratante assumir ser maior. Se o projeto der errado, o contratante tambm tem sua poro de res-
ponsabilidade.
Escopo aberto
Por outro lado, em projetos de escopo aberto, as histrias podem ser definidas medida que o tempo
passa.
Dentre os trs: equipe, data fixa e escopo fechado, o escopo o que mais adiciona risco ao projeto.
Conseguimos prever o que possvel desenvolver para uma data qualquer e sabemos que conseguimos
colocar desenvolvedores, se mais forem necessrios, mas do escopo nao temos nenhuma certeza certeza.
73
10.6. Discusso em sala: quais problemas voc j enxerga na adoo para seu time?
Para saber mais: lidando com dbito tcnico
Eventualmente, sobra tempo em um Sprint e os desenvolvedores pedem ao Product Owner que

adicione uma nova histria ao Sprint.
Diversos times experientes em Scrum tm utilizado esse tempo extra para trabalhar em possveis
dbitos tcnicos que surgem durante o projeto. Essas histrias tcnicas no devem ser feitas sem
a aprovao do P.O., mas podem ser discutidas com ele para chegar a um consenso razovel para
ambas as partes.
Vale lembrar que, embora mais difcil de mensurar, essas melhorias tcnicas tambm promovem
economia para o cliente, j que mudanas se tornam mais fceis e, portanto, menos custosas.
10.6 Discusso em sala: quais problemas voc j enxerga

na adoo para seu time?
74
Captulo 11
eXtreme Programming
Sucesso no o fim, fracasso no fatal: a coragem de continuar que conta.

Winston Churchill
O Scrum, com seus artefatos, permite o acompanhamento e o gerenciamento do projeto, mas no auxilia
a equipe de desenvolvedores a entregar software de qualidade. Por isso, Scrum sozinho no suficiente
para garantir um produto final de qualidade.
Para suprir essa falha do framework, comumente somamos ao Scrum os valores e prticas de eXtreme
Programming (XP).
Assim como o Scrum, XP uma metodologia gil. XP foca na qualidade do software desenvolvido e na
produtividade dos desenvolvedores. Uma das frases que mais conectamos a XP Embrance changes.
11.1 Valores
Os valores de XP so conceitos no tangveis que acredita-se fazer uma grande diferena na qualidade
final do produto e na motivao do time. Eles so: Comunicao, Feedback, Coragem e Simplicidade.
Comunicao
O valor da comunicao visto dentro do time, entre seus membros, e entre o time e os clientes. Ambos
tm igual importncia.
Ela importantssima para que clientes e membros do time compartilhem a viso do produto, isto ,
entendam bem as necessidades de quem o utiliza e prograssivamente mais entendam corretamente uns
aos outros.
11.2. Prticas
Feedback
Feedback um valor que engloba as relaes interpessoais, mas tambm se refere ao feedback que o
prprio cdigo do projeto devolve aos membros do time.
Para que o feedback do cdigo funcione bem, so necessrios testes automatizados de unidade e um
servidor de integrao contnua para que os testes mais longos sejam rodados com frequncia e, se
quebrarem, sinalizem uma inconsistncia.
Coragem
Outro ponto com o qual testes esto intrinsecamente conectados o valor da coragem. Extreme Pro-
gramming prega que desenvolvedores precisam ter coragem para refatorar um cdigo em prol de me-
lhorias em clareza e design - e nada melhor para dar essa coragem do que testes automatizados.
Mas coragem no se limita s melhorias num cdigo. Coragem tambm apagar cdigo, mesmo funcio-
nalidades inteiras, no importa o trabalho que tenha sido empregado a esse cdigo. Coragem, tambm,
para no tentar prever o futuro, mas sim focar no que realmente necessrio nesse momento - XP
associa a essa idia a sigla YAGNI (You aint gonna need it)
Simplicidade
Considere que, na mdia, o tempo de construo de um software cerca de 30% do tempo investido
nele. Os outros 70% so dedicados manuteno do sistema.
Num cenrio como esse, a simplicidade essencial para tornar esse perodo maior muito mais agrad-
vel. Outra sigla est associada a esse princpio: KISS (Keep it simple, stupid!)
Respeito
Falamos de respeito desde a primeira aula e repetidamente, quando falamos do Manifesto gil e, depois,
quando falamos de Lean e ento, novamente, conforme comentamos sobre Scrum. Respeito a base de
um time e um ciclo saudvel e vicioso.
Respeito, em XP, tambm faz referncia ao cdigo. Segundo a metodologia, por exemplo, respeitar o
cdigo faz-lo da melhor forma possvel sempre.
11.2 Prticas
As prticas associadas a XP so muitas, cada uma tem sua razo de existir e, para mais informaes
sobre cada uma delas, recomendamos ler o livro Extreme Programming Explained do Kent Beck ou o
nacional Extreme Programming do Vincius Teles.
76
Captulo 11. eXtreme Programming
Comentaremos, na sequncia, as prticas que consideramos mais importantes, dentre as citadas nos
livros.
Propriedade coletiva de cdigo
muito comum nos projetos de software no geis ter desenvolvedores trabalhando isoladamente, cada
um em sua parte. A consequncia disso que, na maioria das vezes, o desenvolvedor se sente o pro-
prietrio do cdigo que escreveu ao mesmo tempo que julga no ter responsabilidade pelo cdigo que
outro escreveu.
J vimos que o Scrum e os mtodos geis pregam o sentimento de equipe, a formao de um time onde
todos so responsveis pelo projeto todo. Mas, na prtica, como isso se reflete no cdigo do sistema?
XP prega a ideia da Propriedade coletiva de cdigo, onde todos so responsveis. Isso deixa qualquer
desenvolvedor livre para interferir em qualquer parte do cdigo sem medo de irritar o dono daquele
pedao.
E, ao mesmo tempo, traz para o cdigo a prtica da responsabilidade de todos pelo projeto. Se um
cdigo est errado, todos so responsveis.
Programao pareada
comum que algum numa equipe saiba mais de um determinado assunto que seus colegas ou que
tenha mais prtica com alguma ferramenta. Mas, como a equipe deve sempre evoluir, importante
que o conhecimento seja distribudo entre os membros da equipe. Para que isso ocorra, XP prope a
programao em pares (pair programming).
Na hora de programar uma nova funcionalidade, dois desenvolvedores sentam-se juntos na mesma
mquina para fazer uma feature. Um deles fica no controle do computador, enquanto outro observa e
opina sobre o que est sendo feito. Os papis de piloto (quem fica no teclado) e co-piloto (quem observa)
devem ser alternados entre os membros da equipe.
Apesar de parecer desperdcio apenas metade dos programadores digitarem, esta prtica pode chegar
a at aumentar a produtividade da equipe, j que ajuda na deteco precoce de problemas no cdigo e
no foco dos membros da equipe: com algum te observando, voc fica menos vontade para se distrair
com bate-papos, blogs e jogos.
H tambm a vantagem de que as decises tomadas na programao de uma funcionalidade serem

tomadas por dois programadores, o que diminui as chances de uma deciso ruim ser tomada durante o
desenvolvimento do software. E, finalmente, o pareamento incentiva a propriedade coletiva de cdigo,
que discutimos acima.
Uma leitura muito recomendada sobre essa prtica The costs and benefits of pair programming por
Laurie Williams.
77
11.2. Prticas
Testes automatizados e test first
Um problema que cresce com o tamanho do software o medo de mexer em cdigo antigo. Uma das
prticas apoiadas por XP a refatorao constante, ou seja, altere o cdigo existente se voc souber um
jeito melhor de fazer uma determinada tarefa ou se precisar implementar uma nova funcionalidade.
Mas, quanto maior o projeto, maior a quantidade de cdigo que no foi escrita por ns e/ou antigo.
Isso gera o medo de mexer no cdigo e acaba impedindo a evoluo do projeto e da equipe.
Para combater esse problema, XP prope o uso extensivo de testes automatizados que descrevem o com-
portamento de uma funcionalidade, preferencialmente escritos antes mesmo do cdigo que eles testam,
prtica que recebe o nome de desenvolvimento dirigido por testes (em ingls, test-driven development,
ou simplesmente TDD).
Os testes automatizados tm duas funes importantes:
Permitir refatoraes: com testes automatizados para uma funcionalidade, podemos refatorar o
cdigo com mais segurana. Podemos alterar o cdigo e verificar imediatamente se o software
continua funcionando como esperado.
Documentar: os testes devem ter nomes que explicam qual funcionalidade eles testam. Assim, se
voc rodar o teste, voc sabe quais funcionalidades foram implementadas e qual o comportamento
esperado do cdigo.
TDD - Test Driven Design
Levando os testes automatizados ao prximo nvel, chegamos a uma sigla cada vez mais conhecida no
mundo, o TDD. A sigla quer dizer Test Driven Design e j nos informa a inteno da prtica: queremos
que os nossos testes guiem o prprio design das classes do sistema.
O processo do TDD funciona da seguinte maneira:
Faz-se o teste automatizado para o caso mais simples;
Roda-se o teste (que no deve passar porque a funcionalidade ainda no foi implementada);
Implementa-se atravs da mudana mais simples possvel que faa o teste passar;
Se o cdigo no estiver o melhor possvel:
Refatora;
Certifique-se que os testes continuem passando;
Se o cdigo j estiver bom:
Volte para o primeiro item com o prximo teste mais simples.
78
O processo repetido, focando sempre no caso mais simples que ainda no foi implementado at que
tudo o que a funcionalidade precisa fazer esteja implementado.
Note que essa prtica traz diversos benefcios. Por exemplo, cdigo implementado cdigo testado.
Mas, muito mais importante do que isso, se possvel (e fcil) de test-lo bastante provvel que esse
seja um cdigo com menor acoplamento.
O blog do Mauricio Aniche tem diversos posts em portugus sobre TDD: http://www.aniche.com.br/
Integrao contnua e deploy contnuo
Com o uso extensivo de testes, o conjunto de todos os testes de um produto tende a crescer bastante
com a evoluo deste. Isso faz com que a execuo de todos os testes do produto demore cada vez mais
para ser concluda.
Quando os testes comeam a demorar muito para serem executados, os desenvolvedores se sentem
desmotivados a execut-los o tempo todo e a produtividade cai. Isso tambm tem como consequncia
o aparecimento de testes que no passam, cdigo mal escrito, bugs, etc.
Para amenizar este problema, uma soluo utilizar um servidor de testes. Este servidor verifica cons-
tantemente atualizaes no cdigo do projeto e, quando detecta alguma alterao, executa todos os
testes.
Com um servidor de testes, os desenvolvedores podem continuar trabalhando enquanto os testes so

executados em cima do ltimo cdigo que foi integrado.
Deploy contnuo
Hoje em dia, falar de integrao contnua no o bastante.
O feedback rpido dos testes de fato importante, mas ainda precisamos ir alm, fazendo o
prprio deploy da aplicao automaticamente ou, onde no for possvel, preparar um deploy em
um clique (One-click deploy).
E j comum que ferramentas de Integrao Contnua sejam capazes de faz-lo. Basta configur-
las corretamente.
Refatorao constante
natural que, conforme um projeto cresa, pequenos trechos aparentemente inofensivos de cdigo
mal-feito se acumulem e, quando menos se espera, todo o projeto est comprometido.
Mesmo quando preza-se pela excelncia tcnica e se tem uma equipe de desenvolvimento engajada e
79
11.3. Ferramental
experiente, a tendncia que o cdigo se torne o que Joe Yoder chama da Grande Bola de Lama (Big
Ball of Mud), sobre o qual difcil e sofrido trabalhar.
A forma mais fcil de evitar que o cdigo se torne intrabalhvel atravs de refatoraes pequenas e
constantes. Segundo Martin Fowler:
Refatorao uma tcnica controlada para reestruturar um trecho de cdigo existente, alterando sua es-
trutura interna sem modificar seu comportamento externo.
Uma simples prtica pode, ento, salvar um projeto: todo cdigo feio por onde a equipe passa enquanto
desenvolvendo uma histria, refatorado. Dessa forma, a soluo corrente ser sempre a melhor poss-
vel.
11.3 Ferramental
Servidor de testes e de integrao contnua
Existem diversos servidores de integrao por a. Entre eles, podemos citar os seguintes:
Jenkins (http://hudson-ci.org/)
RunCodeRun (http://runcoderun.com/)
CruiseControl (http://cruisecontrol.sourceforge.net/)
TeamCity (http://www.jetbrains.com/teamcity/index.html)
Cruise (http://www.thoughtworks-studios.com/cruise-release-management/)
Alguns desses inclusive tm a capacidade de executar os testes de um projeto de modo distribudo,

diminuindo consideravelmente o tempo total para rodar todos os testes.
Quadro branco
Um estudo de 2009 dizia que o quadro branco a forma de comunicao indireta mais eficiente, com-
parada a diversas outras ferramentas como o e-mail, arquivos compartilhados, bilhetes e avisos.
80
Vimos, em Lean, a utilizao do Kanban para acompanhar as tarefas que devem ser feitas, esto em
andamento ou j esto prontas. Chama-se kanban a tcnica de gerenciamento das tarefas, mas a imple-
mentao dela costuma se dar num quadro branco.
Se as histrias de um Sprint estiverem presentes no quadro e ele estiver sempre atualizado, mesmo equi-
pes cujos membros trabalham em horrios discrepantes conseguem se manter atualizadas e integradas.
Usualmente coloca-se no quadro branco o Kanban, a meta do Sprint e a definio de pronto, enquanto
essa ainda no est clara para toda a equipe.
11.4 Mais mtricas

Conforme a equipe cria experincia na metodologia, novos problemas e novas necessidades surgem.
Com o tempo, a prpria equipe consegue sugerir mtricas para ajudar a combater problemas especficos.
As mtricas mais comumente utilizadas so:
Cobertura de testes: qual procentagem do cdigo acessada por testes;
81
11.4. Mais mtricas
Quadro de pareamentos: quais pessoas parearam e quanto trocam de pares;
Satisfao com projeto: entre ruim, mdio e timo, qual a satisfao pessoal de cada um com o
projeto;
Commits por dia: avaliar se os commits so realmente pequenos;
etc...
82
Captulo 12
O que vem a seguir?
Aps o curso, temos toda a base terica necessria para comear a implantao de Scrum em um projeto
de software. Temos tambm as experincias trocadas durante o treinamento e o que foi aprendido nas
discusses sobre Scrum no mundo real.
Mas, como estudar nunca demais, veja as indicaes de boas fontes de conhecimento para o futuro.
12.1 Leituras e pessoas

Boas fontes de leitura, sempre atuais, so os blogs e listas da comunidade gil e agregadores de notcias
relacionada produo de software.
Em portugus:
Scrum Brasil: scrum-brasil@yahoogrupos.com.br
Agile Brasil: agile-brasil@yahoogrupos.com.br
InfoQ Brasil: http://www.infoq.com/br/agile/
Fragmental: http://blog.fragmental.com.br/ (blog do Phillip Calado)
Blog Caelum: http://blog.caelum.com.br
Em ingls:
Scrum Development: scrumdevelopment@yahoogroups.com
Agile Project Management: agileprojectmanagement@yahoogroups.com

12.2. Certificaes
InfoQ: http://www.infoq.com/agile/
Danilo Sato: http://www.dtsato.com/ (blog do Danilo Sato)
Fragmental: http://fragmental.tw/ (blog do Phillip Calado)
12.2 Certificaes
A Scrum Alliance e a Scrum.org emitem certificaes de capacitao em Scrum. Voc pode encontrar
mais informaes a respeito delas nos respectivos sites:
Scrum.org: atual organizao do Ken Schwaber, com certificaes voltadas tambm para a linguagem
de programao escolhida
http://www.scrum.org/
Scrum Alliance: primeira a emitir os certificados, foi fundada nos primrdios do Scrum e promove
eventos anuais por todo o mundo.
http://scrumalliance.org/
No mundo gil, certificaes podem ser atrativos para currculo, mas a experincia particularmente
valorizada nessa comunidade. Dessa forma, um ScrumMaster com experincia costuma ser mais valo-
rizado do que um Certified ScrumMaster ou Professional Scrum Master.s
84
ndice Remissivo
Artefato opcional: Sprint Burndown, 51 Review meeting, 36
Auto-gerenciamento, 28 RoI, 38
RUP, 7
Backlog, 27
BurnDown, 27 Scrum Master, 28, 61, 71
Scrum.org, 25
Cascata, 3
ScrumAlliance, 25
Dbito tcnico, 74 Sprint, 32
Daily Scrum, 41 Sprint Backlog, 32, 50
Desenvolvedor, 28 Sprints, 27
Desenvolvedores, 63, 71
Tarefas, 44
Desperdcio, 18
TDD, 78
Escopo aberto, 73 Testes, 78
Escopo fechado, 73 Time, 55
Extreme Programming, 75 Time-Boxes, 31
Toyota, 17
Histrias, 44
Unified process, 7
Impedimentos, 61 User stories, 44
Integrao contnua, 79
Iterativo, 27 Waterfall, 3
Ken Schwaber, 25 XP, 75
Lean, 17
Meta, 32, 50
Migrao, 69
Papis do Scrum, 28
Planning meeting, 35
Proatividade, 57
Problemas, 61
Product Backlog, 43
Product Owner, 28, 57, 71
Pronto, 38
Rational, 7
Refatorao, 79
Retrospectiva, 40
85

Apostila PM 83 F17.3.6

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Apostila PM 83 F17.3.6

Загружено:

Авторское право:

Доступные форматы

Conhea mais da Caelum.

1 Viso geral de agilidade 1

4 Agilidade com Lean 17

10 Scrum no mundo real 69

12 O que vem a seguir? 83

Viso geral de agilidade

A coisa mais incompreensvel sobre o mundo que ele todo compreensvel.

1.1 O que agilidade

Se todos conseguem desviar dos problemas, ento no h a necessidade de um gerente tradicional: o

1.2 O que ligamos com agilidade

Ao mesmo tempo, a flexibilidade, capacidade de se adaptar as mudanas necessrias, resulta de no se

1.3 Sobre o curso

Tudo contando com a experincia da Caelum e de parceiros em projetos geis.

Agile Software Development with Scrum, Ken Schwaber

Scrum and XP from the Trenches, http://www.infoq.com/minibooks/

Scrum Guide, http://www.scrum.org/scrumguides/, Ken Schwaber

Outras fontes de informao frequentemente atualizadas so blogs e listas de discusso:

Blog da Caelum, http://blog.caelum.com.br

Lista brasileira sobre mtodos geis: http://br.groups.yahoo.com/group/agile-brasil/

Lista brasileira sobre Scrum: http://br.groups.yahoo.com/group/scrum-brasil/

Agile no Mundo Real, http://agilenomundoreal.wordpress.com, Guilherme Silveira

Ns criamos a verdade, no a descobrimos.

Prticas e metodologias geis surgiram em resposta a problemas recorrentes no gerenciamento de proje-

2.1 De onde viemos: Waterfall

No prprio artigo original, o autor diz:

E, de fato, a importncia da documentao no desenvolvimento tradicional de software refletida nas

S ento, inicia-se a produo de cdigo. Enfim, depois de terminada a implementao, o sistema

Em um projeto de um ano, ser que o ambiente no ser outro no momento da entrega?

2.2 Dinmica: comunicao indireta

Por que desejamos algo mais que waterfall

Em um ano de desenvolvimento, muitas tecnologias novas surgem. Em um ano, as prprias necessidades

2.3 De onde viemos: RUP

E, com razo, j no white-paper de apresentao do framework escrito em 1999, a Rational discretamente

O RUP tem como base as 6 melhores prticas, na viso da Rational:

Desenvolva software iterativamente;

Use arquiteturas baseadas em componentes;

Modele visualmente o software;

Verifique a qualidade do software;

Controle mudanas no software.

Imagem de domnio pblico, retirada de Wikimedia Commons

Por que RUP no nos serve

errado de princpio subestimar a importncia do cliente. O sucesso ou fracasso do projeto depende,

Simplicidade o grau mximo da sofisticao

3.1 Agilidade e o Manifesto gil

"Estamos descobrindo formas melhores de desenvolver

Indivduos e Interaes sobre processos e ferramentas

Isso quer dizer que, embora haja valor nos itens

Ns seguimos esses princpios:

Pessoas de negcios e desenvolvedores devem trabalhar juntos diariamente durante o projeto.

O mtodo mais eficiente e efetivo de agregar informaes para e de um time de desenvolvimento

Software funcionando a primeira medida de progresso.

Processos geis promovem desenvolvimento sustentvel. Patrocinadores, desenvolvedores e usu-

Ateno contnua a excelncia tcnica e bom design engrandecem a agilidade.

Simplicidade -- a arte de maximizar a quantidade de trabalho no necessrio -- essencial.

As melhores arquiteturas, requisitos e design emergem de times auto-organizados.

3.2 O que um projeto de sucesso?

Atende s necessidades do cliente;

Mantm a equipe feliz: sem hora-extra, sem tempo inativo;

Cdigo bem feito: permite manter o ritmo, facilita manuteno;

Lucro: tanto para o cliente, quanto para o time.

Ento quer dizer que...

S d pra fazer projetos de sucesso com mtodos geis?