Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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
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
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
ndice Remissivo 84
Verso: 17.3.6
iii
Captulo 1
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.
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.
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.
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:
2
Captulo 2
Rumo agilidade
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?
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.
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.
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.
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.
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?
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.
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.
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
Captulo 2. Rumo agilidade
Por todos esses problemas e pelos diversos projetos que falharam, outras metodologias surgiram para
melhorar o desenvolvimento de projetos de software.
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.
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
Gerencie requisitos;
7
2.3. De onde viemos: RUP
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
Captulo 2. Rumo agilidade
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.
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
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
Os Princpios geis
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.
Construa projetos com pessoas motivadas. D a eles o ambiente e o suporte que precisarem e
confie que eles faro o trabalho.
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.
Seguindo os princpios que acabamos de ver, vamos construir nossa definio. Um projeto de sucesso
um projeto que:
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.
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.
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.
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.
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.
15
Captulo 4
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.
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/
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...
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.
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
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.
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
Captulo 4. Agilidade com Lean
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
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.
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.
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
Captulo 4. Agilidade com Lean
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...
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.
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.
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.
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.
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
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.
32
Captulo 6. Time-Boxes
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.
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.
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.
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.
"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:
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.
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.
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
Captulo 6. Time-Boxes
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.
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:
Apresentao das histrias: o P.O. apresenta a viso de negcio do item mais prioritrio do
Product Backlog aos desenvolvedores;
35
6.5. Review meeting
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.
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:
A definio da meta acontece no momento mais apropriado, em qualquer uma das reunies.
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
Captulo 6. Time-Boxes
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:
2) Idealmente, pede-se para o prprio usurio experimentar as novas funcionalidades entregues pelos
desenvolvedores. Para cada histria, o resultado pode ser:
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
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.
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
Captulo 6. Time-Boxes
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:
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.
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.
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 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;
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
Captulo 6. Time-Boxes
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.
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.
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
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.
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
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.
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
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
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.
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:
46
Captulo 7. Artefatos do Scrum
3) busca de 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?
Vamos tentar, agora, uma abordagem um pouco diferente de priorizao. Note que tambm possvel
priorizar as mesmas histrias de uma forma um pouco diferente:
47
7.4. Priorizando bem um Product Backlog
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.
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.
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
Captulo 7. Artefatos do Scrum
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.
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.
"Receba bem a mudana de requisitos, mesmo tardias no desenvolvimento. Processos geis enca-
ram mudanas para vantagem competitiva do cliente.
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
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.
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
Captulo 7. Artefatos do Scrum
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.
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.
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/
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
Captulo 7. Artefatos do Scrum
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
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:
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?
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.
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
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:
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.
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.
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.
58
Captulo 8. As pessoas no Scrum
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.
responder s dvidas dos desenvolvedores sobre o que est sendo desenvolvido ou indicar quem
poderia respond-las melhor;
59
8.7. O dia-a-dia do Product Owner
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.
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?
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.
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
Captulo 8. As pessoas no Scrum
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.
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.
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.
assegurar que a equipe faz o Daily Scrum no horrio certo e de modo produtivo;
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
Captulo 8. As pessoas no Scrum
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
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.
64
Captulo 8. As pessoas no Scrum
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
Este um captulo prtico no qual utilizaremos, em um projeto desenvolvido em Lego, as regras, papis
e artefatos do Scrum em prtica.
Faremos, ento, nosso primeiro Planning Meeting. Dessa reunio, sair o Sprint Backlog, com as tarefas
mais prioritrias separadas para serem executadas.
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.
Prontos?
Mos obra!
Captulo 10
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.
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.
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.
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.
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.
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.
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.
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.
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
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?
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.
74
Captulo 11
eXtreme Programming
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.
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.
Uma leitura muito recomendada sobre essa prtica The costs and benefits of pair programming por
Laurie Williams.
77
11.2. Prticas
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).
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.
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.
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;
Refatora;
78
Captulo 11. eXtreme Programming
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/
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.
Deploy contnuo
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/)
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
Captulo 11. eXtreme Programming
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.
81
11.4. Mais mtricas
Satisfao com projeto: entre ruim, mdio e timo, qual a satisfao pessoal de cada um com o
projeto;
etc...
82
Captulo 12
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.
Em portugus:
Em ingls:
InfoQ: http://www.infoq.com/agile/
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
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