Agile+Manifesto br25 01 1611705580749

UMA ANÁLISE DO MANIFESTO ÁGIL
Entendendo
os Valores e Princípios Ágeis
Understanding
Agile Values & Principles
Scott Duncan
Scott Duncan
Understanding Agile Values & Principles
© 2019 Scott Duncan. All rights reserved.
Published by C4Media, publisher of InfoQ.com.
ISBN: 978-0-359-52387-0
No part of this publication may be reproduced, stored in a retrieval
system or transmitted in any form or by any means, electronic,
mechanical, photocopying, recoding, scanning or otherwise except
as permitted under Sections 107 or 108 of the 1976 United States
Copyright Act, without the prior written permission of the Publisher.
Production Editor: Ana Ciobotaru
Copy Editor: Lawrence Nyveen
Design: Dragos Balasoiu
Contents
Prólogo.......................................................................................................................vi
Outros comentários do livro.................................................................................1
Prefácio........................................................................................................................2
Introdução à Edição Brasileira.............................................................................4
Prefácio à edição brasileira....................................................................................6
Visão geral...................................................................................................9
O Manifesto Ágil................................................................................................... 10
Declarações iniciais............................................................................................... 11
Declaração final..................................................................................................... 11
Mais que................................................................................................................... 11
Desde o manifesto................................................................................................. 12
Ágil além do software........................................................................................... 13
O próximo capítulo............................................................................................... 13
Algumas considerações...........................................................................15
Comunicação.......................................................................................................... 16
Colaboração............................................................................................................ 17
Comprometimento............................................................................................... 18
Melhoria Contínua............................................................................................... 19
Confiança................................................................................................................. 20
Excelência................................................................................................................ 20
Indivíduos e Interações..........................................................................21
IIndivíduos e interações...................................................................................... 22
Processos e ferramentas...................................................................................... 23
Comprometendo-se com a interação.............................................................. 24
Um experimento.................................................................................................... 24
Software Funcionando...........................................................................25
Comunicação com o software........................................................................... 27
Documentação Compreensiva.......................................................................... 29
Colaboração com o Cliente....................................................................31
Negociação de contratos..................................................................................... 33
Responder a Mudanças...........................................................................35
Seguindo um plano............................................................................................... 37
Satisfação do cliente................................................................................39
Nossa maior prioridade....................................................................................... 40
Entrega contínua e adiantada............................................................................ 41
Software com valor agregado............................................................................ 41
Abraçar as mudanças..............................................................................45
Vantagem competitiva para o cliente............................................................... 46
Mudanças nos requisitos são bem vindas....................................................... 46
Ao final do desenvolvimento............................................................................. 48
Entrega contínua......................................................................................51
Entregar frequentemente software funcionando......................................... 52
De poucas semanas a poucos meses................................................................. 52
Dar preferência a escalas de tempo mais curtas........................................... 52
Por que iterações curtas?..................................................................................... 53
Trabalho colaborativo.............................................................................55
Pessoas de negócios e desenvolvedores........................................................... 56
Trabalhar diariamente em conjunto................................................................ 57
Por todo o projeto................................................................................................. 58
Indivíduos motivados.............................................................................59
Pessoas motivadas................................................................................................. 60
O ambiente e o suporte........................................................................................ 61
Confiar na equipe.................................................................................................. 61
Conversa face a face.................................................................................65
Meios de comunicação......................................................................................... 66
Equipes distribuídas............................................................................................. 70
Gerenciando equipes distribuídas.................................................................... 71
Reuniões diárias..................................................................................................... 73
Revisões de iteração.............................................................................................. 74
Software em funcionamento… Outra vez?......................................... 77
Medindo o Progresso........................................................................................... 78
Gráfico Burn-up.................................................................................................... 79
Definição de pronto.............................................................................................. 81
Desenvolvimento Sustentável...............................................................83
Desenvolvimento Sustentável............................................................................ 84
Ritmo constante indefinidamente.................................................................... 85
Excelência Técnica...................................................................................87
Atenção Contínua................................................................................................. 88
Excelência Técnica................................................................................................ 88
Bom design.............................................................................................................. 89
Aumenta a agilidade.............................................................................................. 90
Simplicidade.............................................................................................91
Equipes auto-organizadas......................................................................93
As melhores............................................................................................................. 94
Equipes auto-organizadas................................................................................... 94
Reflexões da equipe.................................................................................97
Intervalos regulares.............................................................................................. 98
A equipe.................................................................................................................... 99
Tornar-se mais eficaz.........................................................................................100
Refinar e ajustar...................................................................................................100
Retrospectivas ineficazes..................................................................................101
Algumas ideias para retrospectivas................................................................102
Coletando Feedback...........................................................................................104
Os cinco porquês.................................................................................................105
Ferramentas para análise de dados.................................................................105
O que vem depois?..............................................................................................109
Epílogo.....................................................................................................110
Uma perspectiva antiga e duas recentes.......................................................110
Modern agile.........................................................................................................110
Heart of agile.........................................................................................................112
Leitura adicional....................................................................................116
Sobre o autor...........................................................................................118
Prólogo
A agilidade é baseada em um conjunto de valores e princípios descrito em

um documento conhecido como Manifesto Ágil. Para implementar esses
valores e princípios as equipes seguem certas práticas, como escrever
histórias de usuários ou programação em pares (pair programming).
Nos primeiros dias da agilidade, lembro-me de participar de muitas
discussões sobre se os princípios ou as práticas deveriam vir em primeiro
lugar. Ou seja, se uma equipe seguisse um conjunto de práticas por tempo
suficiente e de maneira consistente, os membros da equipe aprenderiam
os princípios intrínsecos dessas práticas?
Ou seria necessário que as equipes começassem com uma sólida
compreensão dos princípios de agilidade antes de implementar suas
práticas?
Esses eram os debates que geralmente aconteciam nas primeiras
conferências ágeis e no Scrum Gathering. Conheci Scott em uma dessas
conferências: o Agile Development Conference em Salt Lake City no ano
de 2004.
Nos 15 anos seguintes, fiquei constantemente impressionado com
o domínio de Scott sobre a agilidade. Quando ele avalia a questão dos
princípios versus as práticas, como faz neste livro, todos nos beneficiamos.
Em Entendendo os Valores e Princípios Ágeis, Scott analisa cada um dos
12 princípios e as quatro declarações de valor do manifesto ágil. Ao longo
do caminho, ele explica a intenção e a importância de cada um. Mas ele
também descreve como as equipes podem lutar para colocar em prática
um princípio ou valor. E ele oferece conselhos práticos e prontos para uso
sobre como viver os princípios e valores do Manifesto Ágil.
O Manifesto Ágil cabe em uma única página. Mas, por mais breve e conciso
que seja, muito está aberto ao debate e à interpretação. Esses debates nunca
deveriam, e provavelmente nunca irão parar. É discutindo o que significa
ser ágil que descobrimos maneiras melhores de desenvolver software.
Os pensamentos e conselhos de Scott neste livro representam um passo
significativo no encaminhamento dessa discussão.
Mike Cohn
Mike é cofundador da Scrum Alliance e autor de User Stories Applied,
Agile Estimating and Planning, e Succeeding with Agile.
www.mountaingoatsoftware.com
www.agilementors.com/
Outros comentários do livro
“Sempre que me envolvo com pessoas que desejam praticar a agilidade,

meu primeiro objetivo é garantir que elas entendam os principais valores
e princípios da agilidade. Esse é o “porquê” básico que fundamenta as
práticas em um framework como o Scrum. Sem estabelecer esse núcleo
inicial, os profissionais não estarão bem equipados para inspecionar e
adaptar suas abordagens à prática do Scrum. Scott forneceu comentários
importantes para a elaboração dos valores e dos princípios do Manifesto
Ágil. Esta é uma boa leitura, seja você um novato ágil ou um praticante
experiente.”
- Ken Rubin, autor do Scrum Essencial: um Guia Prático Para o Mais
Popular Processo ágil e criador do Visual AGILExicon® (https://
innolution.com/)
“Scott Duncan escreveu um livro interessante e valioso. Ele trabalha com
todos os valores e princípios do Manifesto Ágil, considerando cada frase
e suas implicações para um indivíduo ou organização interessada em
adotar uma abordagem Ágil em seu trabalho. Isso contrasta com quase
todos os outros conselhos do Ágil que você encontrará: Scott não possui
um framework ou produto em particular, nem uma ferramenta específica
para todas as ocasiões. O livro é essencialmente uma série de reflexões
curtas sobre cada uma das ideias do Manifesto. Ele nos conduz através
de uma visão clara e abrangente do Manifesto e o que realmente significa
para aqueles que tentam aplicá-lo em nosso trabalho e em nossas vidas.
Altamente recomendado!”
- Ron Jeffries, coautor do Manifesto Ágil e autor de The Nature of
Software Development: Keep It Simple, Make It Valuable, Build It Piece by
Piece (A Natureza do Desenvolvimento de Software: mantenha as coisas
simples, faça valiosas, construa peça por peça) (https://ronjeffries.com/)
Prefácio
Muitos anos atrás, comecei o que planejava ser um livro muito maior
com esse mesmo título. Eu senti que muitas organizações com as quais eu
trabalhava haviam iniciado sua jornada Ágil sem uma boa, ou nenhuma,
compreensão efetiva dos Valores e Princípios do Manifesto Ágil. O livro
foi um esforço muito grande e eu o deixei de lado. No entanto, ao longo
dos anos, minha preocupação com a falta de conhecimento organizacional
dos Valores e Princípios Ágeis não diminuiu, pelo contrário, ela cresceu.
Decidi, há um ano, publicar alguns ensaios no Medium.com e isso acabou
sendo o precursor deste livro. As pessoas falam de “ser” ágil em vez de
apenas “fazer” agilidade, esse é um assunto que poderia ser discutido de
forma mais ampla em um próximo livro. Este trabalho, no entanto, tenta
abordar esse comportamento com exemplos suficientes para “fazer” e
ilustrar como alguém poderia se comportar ao “ser” ágil.
Eu não teria chegado a esse ponto sem a influência de muitas pessoas
relacionadas com o desenvolvimento Ágil de software. Desde que li o
Programação eXtrema (Xp) Explicada (eXtreme Programming Explained)
pela primeira vez em 2002, muitos outros ajudaram na construção do
conhecimento, mas duvido que consiga listar todas elas. E antes disso, por
cerca de 25 anos, ainda mais pessoas influenciaram como eu via os temas
tradicionais de desenvolvimento / engenharia de software.
Reconhecimentos
Gostaria de agradecer a algumas pessoas, especificamente por lerem os
rascunhos deste livro e por seus comentários sobre ele:
Primeiramente, conhecendo-o há cerca de 15 anos e, como ele, junto com
Ken Schwaber, era meu treinador de CSM, quero agradecer a Mike Cohn.
Tive o prazer de estar em conferências com Mike, tendo aulas, trabalhando
com ele no Conselho de Administração da Scrum Alliance e participando
de sua comunidade de Agile Mentors. Também tive a oportunidade de
ler e comentar o rascunho do livro “Desenvolvimento de Software com
Scrum: Aplicando Métodos Ágeis com Sucesso” (Succeeding with Agile,
título original).
E conhecendo-o quase por tanto tempo quanto Mike, quero agradecer
a Ron Jeffries por examinar o rascunho deste livro. Ao longo dos anos,
gostei das apresentações que ele fez sobre as práticas do desenvolvimento
Agile e seus primeiros escritos sobre práticas de programação eXtrema.
Antes de aprender sobre o Scrum, o trabalho de Ron e Kent Beck no XP
foi minha introdução à prática Ágil, depois de encontrar o Manifesto Ágil.
Em terceiro, quero agradecer a Ken Rubin por ter lido o rascunho inicial
deste livro e por suas sugestões de melhorias (com as quais farei um
trabalho melhor no próximo livro) e por sua perspectiva geral sobre ele.
Existem muitos outros cujo trabalho e as ideias me ajudaram ao longo da
minha jornada Ágil pessoal como: Jurgen Appelo, Lyssa Adkins e Barry
Boehm e Richard Turner, que me deram oportunidade de dar uma rápida
olhada em seus livros;
Kent Beck, é claro, através de seu livro Programação eXtrema (Xp)
Explicada, me levou na direção que me trouxe a esse ponto da minha
carreira;
Sempre apreciei Alistair Cockburn por pensar de maneira ágil toda vez
que eu lia o que ele escreve ou fala;
Existem pessoas como Mary e Tom Poppendieck, Robert Galen, Roman
Pichler, Brian Marick, David Anderson, Ken Schwaber, Jeff Sutherland,
Scott Ambler e muitas pessoas cujos livros, palestras, blogs e vídeos vêm
oferecendo orientação ao longo dos anos.
E, antes de encontrar o Manifesto Ágil, durante meus dias ‘sequenciais
em fases’, especialmente 14 anos no ambiente da Bell, havia o trabalho
de Barry Boehm, Tom DeMarco, David Parnas, Gerry Weinberg e Fred
Brooks, para mencionar apenas alguns.
Finalmente, meus agradecimentos a: Ben Linders, que mostrou o interesse
inicial em publicar este livro e ofereceu muita ajuda ao longo do caminho;
Lawrence Nyveen por sua revisão editorial; Ana Ciobotaru e Dragos
Balasoiu por seu trabalho na capa deste livro e outros detalhes de
publicação.
Introdução à Edição Brasileira
Na ocasião em que escrevo essas linhas, o Manifesto para Desenvolvimento

Ágil de Software (ou simplesmente Manifesto Ágil) está próximo de
completar duas décadas de existência. Desde a sua criação em 2001 no
resort Snowbird nos EUA, as metodologias e frameworks ágeis tem se
tornado incrivelmente populares, mesmo fora da TI. Hoje é bem comum
encontrarmos livros sobre Scrum nas prateleiras “nobres” das livrarias e
não mais nas escondidas seções de informática.
Todo esse sucesso não é à toa: as metodologias ágeis vieram de encontro
a uma necessidade emergente de práticas de desenvolvimento que fossem
adequadas a um mundo onde a única certeza é a mudança. Já em 2011,
as pesquisas realizadas pelo The Standish Group apontavam uma taxa
de sucesso expressiva de projetos que utilizavam a abordagem ágil em
comparação com os que ainda adotavam as metodologias tradicionais,
resultados que tem se mantido relativamente constantes.
Apesar de todo esse “glamour”, implementar práticas e frameworks ágeis
de forma eficaz ainda tem sido um enorme desafio para muitas empresas e
equipes. Os próprios criadores do Scrum afirmam que seu framework
é “fácil de entender, mas extremamente difícil de dominar”. Parece
contraditório, não? Se mesmo o Manifesto Ágil tem valores e princípios
que cabem facilmente em uma única folha de papel, qual seria então o
grande segredo para dominar os métodos ágeis?
Minha experiência facilitando times ágeis nos últimos anos tem me
mostrado que um dos principais obstáculos tem a ver com a mudança de
mentalidade e cultura. De fato, o último relatório StateofAgile aponta a
“resistência à mudança” e a “cultura organizacional em conflito com os
valores ágeis” estando entre os maiores desafios para a adoção do Ágil.
Esses fatores explicam por que algumas organizações ainda se limitam
a praticar os papéis, cerimônias e artefatos de forma robotizada, sem
compreender ou mesmo praticar os princípios ágeis por trás deles,
comportamento conhecido como “ágil zumbi”. Assim, quando os
benefícios e resultados esperados do Ágil não chegam, é só uma questão
de tempo para que essas empresas retornem às antigas práticas.
Este livro chega ao Brasil em um momento de crescente interesse e
procura por treinamentos e certificações ágeis. Mas enquanto os holofotes
permanecem voltados para determinados frameworks e métodos, o
Manifesto Ágil ainda ocupa poucos slides das apresentações.
Nesta obra, Scott Duncan vem resgatar e dar a devida importância aos
quatro valores e doze princípios que representam a essência da mentalidade
e da cultura ágil. Entendê-los, assimilá-los e sobretudo, saber transmitir
esses valores e princípios é obrigatório para qualquer profissional
comprometido com a adoção do Ágil nas equipes e organizações.
Liney Reis, Agile Coach e Consultor de TI da Caixa Econômica Federal,
colaborou na revisão da edição brasileira. É pós-graduado em Engenharia
de Software pela Universidade Católica de Brasília e possui várias
certificações na área de agilidade, como PSM II (Scrum.org), TKP e
KMP (Kanban University). Tem atuado nos últimos anos como consultor
e facilitador de times ágeis na Caixa Econômica Federal, sendo um
entusiasta do Agile e do Lean. Também é instrutor de ações educacionais
de Scrum e mentalidade ágil.
Prefácio à edição brasileira
Como adicionar valor em um livro com explicações e comentários das

pessoas mais influentes da Agilidade? Para responder a essa pergunta
achamos melhor tentar causar reflexões e deixar algumas provocações. O
livro fala por si, não é preciso ler de forma linear. Além disso, assim como
o Manifesto Ágil, seu grande valor está na simplicidade.
Costumamos chamar esse tipo de bibliografia de back to basics (voltando
ao básico), ou seja, são obras que tem como objetivo explorar a essência
dos temas de uma forma mais direta para reativar os princípios no
cérebro. Princípios que, por vezes, se ofuscam na execução do dia-a-dia.
Conversamos com muitas pessoas que ainda compreendem as declarações
do manifesto como opcionais:
“[Valor importante] AO INVÉS DE [valor também importante].”
Quando, na verdade, o correto seria entendê-las como prioridades:
“[Valor importante] MAIS QUE [valor também importante].”
Seguindo uma das características da comunidade InfoQ, a de fomentar as
discussões como forma de estender os conteúdos publicados, propomos
os seguintes questionamentos para reflexão.
O que é mais fácil entender: pessoas ou código?
Cada pessoa em uma organização adiciona complexidade ao sistema.
Quanto mais complexo um sistema, mais imprevisível ele se torna. Um
software se torna mais complicado e, às vezes, mais complexo (princípio
da entropia) com o passar do tempo. Uma equipe de desenvolvimento
de software sempre se torna mais complexa com o passar do tempo.
Trabalhar com a agilidade, é ter essa consciência: boas pessoas agilistas são
obcecadas, invariavelmente, por comunicação, o que leva à colaboração e
que, consequentemente, possibilita resposta às mudanças.
Tudo isso é só para criar CRUDs mais rápidos?
O termo é muito simplista, sistemas CRUD (Create, Read, Update,
Delete) são para coleta de dados. Já as Enterprise Applications (Aplicações
Corporativas), não têm apenas essa função, uma vez que elas geram valor
para todas as partes envolvidas: clientes finais que contratam um serviço,
empresas prestadoras do serviço que utilizam o software, as pessoas que
utilizam, de fato, o software e as pessoas que desenvolvem - ou seja, não
apenas coletando dados, mas automatizando processos, adicionando
inteligência de mercado, facilitando a elaboração e a execução de
estratégias de negócios.
O manifesto funciona perfeitamente para aplicações corporativas, mas como ele
se comporta no mundo Open Source?
Em nosso entendimento, os objetivos e estruturas de grupos com essa
característica compreendem os princípios de comunicação de forma
implícita simplesmente pela dinâmica do projeto, fazendo com que se
organizem como uma comunidade. Neste ponto acreditamos que o
Software Craftsmanship (Manifesto das Pessoas Artesãs de Software), se
encaixaria melhor.
Por fim, acreditamos que a agilidade é aprendizado e aprendizado é prática.
Considerando a dinâmica das organizações, é altamente aconselhável que
as ideias sejam implementadas em doses pequenas, dando tempo para
medir o sucesso da estratégia - até mesmo na motivação da equipe - com
maior assertividade e difundindo uma cultura Ágil de forma orgânica e
cadenciada. Alguns exemplos de artigos no InfoQ Brasil que podem ajudar
a medir os resultados são: A importância das métricas para times ágeis,
Métricas de entrega para melhorar a previsibilidade e Valor e Métricas.
Desejamos uma boa leitura e uma excelente jornada Ágil!
Edeilson Silva e Eduardo Kuwakino
Tradutores da edição brasileira

Edeilson Silva é MBA em Gerenciamento de Projetos pela Universidade
de São Paulo, certificado associado em gerenciamento de projetos
(CAPM®) pelo PMI® e Professional Scrum Master (PSM®) pela Scrum.
org. Atualmente trabalha como analista de sistemas e projetos com
foco na melhoria de processos. É voluntário nos projetos Raspberry Pi
Foundation atuando com projetos cuja intenção é ensinar programação
para crianças, TEDx, TED Talks como tradutor e intérprete e colabora
com a equipe editorial InfoQ Brasil fazendo traduções Inglês/Português.
Eduardo Kuwakino é formado em Tecnologia em Informática pela

UNICAMP, atua no desenvolvimento de software há mais de 15
anos, teve contato com XP em 1999 quando ainda não programava
profissionalmente. Acredita que colaboração é fonte de valor. É editor no
InfoQ Brasil desde 2017.
CAPÍTULO 1
Visão geral
VISÃO GERAL
Tenho realizado sessões de coach e treinado equipes com abordagens ágeis

para desenvolvimento de software há mais de 13 anos. Neste período,
muitos frameworks e práticas foram propostas e utilizadas. Na minha
experiência, uma cena parece clara: ao mesmo tempo que as formações
sobre frameworks específicos aumentaram, muitas dessas pessoas
treinadas parecem ter pouca familiaridade com os valores e princípios do
Manifesto Ágil (http://agilemanifesto.org/iso/ptbr/manifesto.html).
Como resultado, as pessoas tendem a repetir comportamentos anteriores
quando as práticas apresentadas durante o treinamento ficam difíceis ou
impossíveis de implementar. Muitas vezes isso parece ocorrer pela falta de
referência aos valores e princípios que possibilitaria considerar algumas
alternativas mais aderentes aos mesmos. Dessa forma acredito que a
compreensão limitada dos valores e dos princípios limita o pensamento
na escolha de práticas alternativas.
Por essa razão compartilho meus pensamentos sobre o que a compreensão
dos valores e dos princípios podem significar para uma organização. Tal
compreensão facilitará o sucesso de uma abordagem ágil, uma vez que os
valores e os princípios podem ser utilizados como ponto de referência ao
considerar práticas alternativas. Como muitos apontam, as ideias ágeis
são bastante simples, mas não necessariamente fáceis de implementar.
Embora sejam baseadas em diretrizes que remontam a meados do século
passado, elas formam um conjunto de ideias que reforçam a intenção de
serem utilizadas juntas.
Cada valor e princípio será considerado e explorado da forma mais
relevante que acredito e ao longo do caminho será sugerida uma variedade
de práticas e considerações possíveis que podem ajudar a implementar
cada uma delas. Para começar, faremos um panorama geral do Manifesto
Ágil, no capítulo seguinte abordaremos os fundamentos básicos para
um modelo eficaz de trabalho em grupo, mas iremos focar no que é
importante para ser ágil: comunicação, colaboração, comprometimento,
melhoria contínua, confiança e excelência. Depois disso, cada valor e
princípio terão um capítulo dedicado.
O Manifesto Ágil
A seguir veremos três componentes do manifesto que apoiam como
compreendemos as declarações de valor: as duas primeiras declarações,
9
ENTENDENDO OS VALORES E PRINCÍPIOS ÁGEIS
a declaração final e a preposição. Reações iniciais ao manifesto muitas

vezes soavam como uma compreensão equivocada ou que ignoravam a
preposição e a declaração final.
Declarações iniciais
O primeiro parágrafo do Manifesto Ágil diz que “Estamos descobrindo
maneiras melhores de desenvolver software, fazendo-o nós mesmos e
ajudando outros a fazerem o mesmo. Através deste trabalho, passamos
a valorizar…”. Todas as pessoas presentes na reunião que resultou o
manifesto tinham experiência direta no desenvolvimento de software,
ninguém era puramente acadêmico ou pesquisador. O que se encontra
no manifesto, portanto, baseia-se na experiência prática, não teórica.
Segundo os presentes, essa experiência os levou a acreditar em quatro
pontos fundamentais: os valores.
Declaração final
Lembro-me de ter lido artigos no início dos anos 2000, nos quais as
pessoas sugeriam ou diziam abertamente que os autores do manifesto
não defendiam nenhum processo ou ferramentas, documentação,
contrato ou planejamento. Essas declarações mais explícitas pararam
há algum tempo, entretanto, podemos ouvir esse mesmo sentimento
expresso em declarações como: “Não se pode fazer <algum aspecto do
desenvolvimento> sem <alguns processos, ferramentas, documentações,
contratos ou planos específicos>”.
Claro, o manifesto não diz que você deve fazer sem essas coisas. A
declaração final diz: “Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda”. O manifesto reconhece o valor
dos processos, das ferramentas, da documentação, dos contratos e dos
planos, ao mesmo tempo em que afirma que os autores acreditam que
há maior importância em indivíduos e interações, software funcionando,
colaboração com o cliente e resposta a mudanças. Compreender os níveis
de prioridade são questões importantes.
Mais que
Perceba que as palavras que formam conexões entre cada declaração de
valor são “mais que”. Não significa “em vez de”, “excluindo”, “sem” ou
alguma outra forma de eliminação. As palavras “mais que” implicam uma
10
VISÃO GERAL
precedência, não uma relação excludente, dentro de cada declaração de

valor.
Se uma empresa tem dificuldades:
• Com a interação eficaz dos indivíduos, um maior rigor na adoção de
processos e ferramentas provavelmente não vai ajudar;
• Entregando regularmente software funcionando, uma documentação
detalhada ou super detalhada provavelmente não ajudará;
• Ao colaborar com os clientes de forma positiva, contratos mais
rigorosos provavelmente não ajudarão;
• Ao responder a mudanças diretamente, seguir os planos de forma
rigorosa provavelmente não ajudará.
Observando de outra perspectiva:
• Processos e ferramentas devem ajudar os indivíduos a interagir de
forma mais eficaz;
• A documentação deve ajudar a entregar software funcionando com
mais regularidade;
• Os contratos devem ser escritos para ajudar a colaborar com os
clientes de forma mais positiva;
• Planos e planejamento devem ajudar a capacidade de responder a
mudanças mais diretamente
Desde o manifesto
Ao longo dos anos as pessoas se propuseram a atualizar o Manifesto Ágil
tratando de pontos que a comunidade sentia que os autores originais
haviam perdido ou estavam desatualizados. Também ouvi afirmações
que diziam que o manifesto era “livre de conteúdo”, o que o torna fácil
em concordar pois não se compromete com nada específico. Quem não
deseja interação efetiva entre pessoas, software que funciona, colaboração
com clientes e capacidade de responder a mudanças? Mas como ouvi (e
li) pelo menos um autor do manifesto dizer, isso foi uma declaração do
que aquelas 17 pessoas na sala, durante aqueles quatro dias, em 2001
acreditavam na época. Como tal, o Manifesto Ágil (ou qualquer manifesto)
não é algo que você atualize. Novas ideias aparecerão, serão perseguidas e
podem oferecer uma orientação útil sobre o que considerar para se tornar
e buscar a agilidade. Em particular, duas maneiras interessantes de pensar
11
sobre o que significa ser ágil e buscar agilidade são o Heart of Agile, de
Alistair Cockburn, e o Modern Agile, de Joshua Kerievsky.
Voltarei a esses dois no final do livro e mencionarei os comentários feitos
por Kent Beck em 2010.
Ágil além do software

Um último ponto antes de concluir esta introdução é que os valores e
princípios do manifesto se aplicam facilmente a qualquer atividade em
que as pessoas precisem trabalhar juntas de alguma forma para produzir
algum produto ou serviço final. Se alguém substitui a palavra “software”
por “produto ou serviço”, acredito que os valores e princípios mantenham
sua validade.
Em uma conferência ágil realizada vários anos depois que o manifesto
alcançou uma visibilidade mais ampla, ouvi alguém lamentar a tentativa
de aplicar agilidade fora do domínio do software. Eles pareciam sentir que
o ágil, vindo do campo do software e tendo muitas práticas baseadas em
software, seria diluído nos esforços para aplicá-lo em outros domínios.
Acredito que a diluição de ideias ágeis ocorre não por aplicá-las em outros
domínios, mas por pessoas que não as utilizam como critério para se
tornarem ágeis, independentemente de frameworks e práticas.
O próximo capítulo
Espero que esta visão geral tenha despertado interesse para ler mais.
O próximo capítulo abordará as considerações fundamentais de
comunicação, colaboração, comprometimento, melhoria contínua,
confiança e excelência indicadas acima.
12
CAPÍTULO 2
Algumas considerações
No Capítulo 1, mencionei diversas ideias que chamei de “fundamentais”.

Parece difícil esperar que uma empresa, grupo ou indivíduo se torne
(mais) ágil sem elas. Como destacado no Capítulo 1, todas essas
considerações são importantes para qualquer situação de trabalho, mas
parecem particularmente essenciais para ser ágil. Ser ágil, como muitos
dizem, é mais importante que “fazer” o ágil. Isto é, entender como aplicar
os valores e princípios é mais importante do que práticas específicas. É
óbvio que as práticas devem existir e há muitas formas de “fazer” o ágil.
Apesar disso, há um limitado conjunto de escolhas ao “ser” ágil.
Comunicação
Cada valor no manifesto é afetado pela comunicação, apesar das formas
se diferenciarem:
• Parece impossível esperar interações positivas entre indivíduos sem
uma comunicação efetiva, isso requer receptividade e transparência
no relacionamento. Significa assumir o risco de estar errado na frente
de outras pessoas quando ideias e informações fluírem livremente
para todas as direções. Significa perguntar mais do que afirmar e ser
inclusivo (“nós”) mais que acusativo (“vocês”).
• Entregar software funcionando certamente requer comunicação
efetiva entre as pessoas, mas também entre o software e as pessoas.
Isso requer design, desenvolvimento e práticas de teste que expõe
o que está acontecendo com o software em qualquer estágio de sua
criação. Conhecer a estabilidade do seu sistema a qualquer momento
encoraja a experimentação, constrói a confiança, elucida a qualidade
e torna as mudanças menos arriscadas.
• A colaboração positiva com os clientes, ou qualquer outra parte
interessada, é apenas uma instância da interação entre indivíduos,
dessa forma, poderíamos prosseguir sem dizer que isso requer
comunicação efetiva. Mas é uma obrigação dos dois lados, os clientes
devem entender que para ter o benefício da abordagem ágil, devem
se envolver na abordagem em vários pontos, provendo feedback e
clarificação, e mesmo orientação quando necessária.
• Finalmente, é difícil imaginar como responder às mudanças de forma
satisfatória sem a comunicação efetiva entre todos os que conhecem
o produto, têm ideias de melhoria e serão afetados por essa mudança.
Discussões de escopo flexível e os impactos da mudança devem incluir
14
ALGUMAS CONSIDERAÇÕES
clientes e equipes de desenvolvimento. A maioria dos problemas de

desenvolvimento ocorrem porque a comunicação não é efetiva.
Colaboração
Colaboração é certamente um aspecto da comunicação eficaz. Muitas
pessoas que trabalham em equipe acreditam que estão colaborando
quando provavelmente estão apenas cooperando. Não há nada de errado
com a cooperação, mas colaborar vai além de cooperar. Alguém pode
cooperar sem colaborar.
“Cooperar” significa operar juntos, funcionar em conjunto. Ideia que
pode ocorrer com interação limitada. Indivíduos podem ter suas próprias
tarefas determinadas, trabalhar para concluírem-nas e querer ajudar
os outros quando puderem. Entretanto, os indivíduos podem focar
essencialmente na conclusão das tarefas individuais, esperando que os
outros façam o mesmo. Ou seja, as pessoas podem cooperar sem assumir
qualquer responsabilidade por outro trabalho além do seu.
“Colaborar” significa trabalhar juntos. Envolve deliberadamente
compartilhar o trabalho e a responsabilidade, é o comprometimento
para concluir algo. Isso significa estruturar as tarefas para que as pessoas
possam trabalhar próximas umas das outras realizando planejamentos,
estimativas, comprometimento, desenvolvimento e os testes. Também
significa que a comunicação deve ser mais direta e frequente, a qual não é
sempre necessária na cooperação.
A conexão da colaboração entre interações individuais e o trabalho
com os clientes parece óbvia. Conseguir software funcionando e
responder às mudanças são um pouco mais nebulosas, mas não muito.
Conquistar ambos é mais efetivo quando existe colaboração e não apenas
cooperação. Ter software funcionando pode ser mais difícil quando há
uma mentalidade de “não interferência” entre silos de habilidades.
Assim como responder à mudança pode ser menos efetivo sem uma
posição colaborativa, as pessoas podem, mesmo sem a intenção de
impactar negativamente os outros, subestimar a mudança de forma que
melhorem ou mantenham suas próprias situações enquanto pioram a
situação de outras. Por exemplo, em uma situação onde os departamentos
de uma empresa são ordenados a cortar seus orçamentos em certa
porcentagem para o próximo ano. Em uma de minhas experiências, o
15
suporte da TI apontou que uma grande soma de dinheiro estava sendo

gasta com suporte a diversas versões de computadores desktop usados
para desenvolvimento, atividades administrativas básicas e de escritório.
Ou seja, as pessoas do suporte administrativo estavam usando estações de
trabalho poderosas para o simples gerenciamento de arquivos, registros
de orçamento, apresentações e memorandos.
O suporte da TI observou que, a menos que fosse requisitado para
desenvolvimento, um desktop com configuração padrão deveria ser usado.
Computadores desktop relativamente baratos se tornaram a ferramenta
ideal quando o desenvolvimento não era necessário. Isso também reduziu
outros custos, uma vez que o suporte a esse ambiente era mais abundante
e menos caro que as configurações voltadas ao desenvolvimento. Após
converter diversas pessoas, inclusive todos as pessoas do suporte gerencial,
um sério e não documentado bug foi exposto, problema que levou duas
semanas para ser rastreado pela equipe técnica (diferente do Suporte
TI) e uma outra semana para que a mesma equipe técnica corrigisse as
consequências. Centenas de pessoas foram afetadas, incluindo gerentes
que tiveram os arquivos temporariamente “desaparecidos”, o custo nunca
foi registrado formalmente, mas o Suporte TI pôde mostrar a redução do
seu orçamento na porcentagem requisitada.
Comprometimento
A comunicação e a colaboração são mais facilmente melhoradas quando
as pessoas veem o comprometimento uns dos outros para realizar
o trabalho no menor tempo possível. Mas esse comprometimento é
de fato aceito quando a comunicação eficaz e a colaboração existem.
Um requisito para isso é que as pessoas assumam o trabalho que estão
realizando e se comprometam com as entregas; esses compromissos, por
sua vez, não devem ser impostos. Falarei mais sobre o assunto ao abordar
equipes autogerenciáveis em um capítulo mais à frente, mas para resumir
as pessoas devem:
• Fazer suas próprias estimativas do trabalho a ser concluído;
• Definir suas próprias tarefas de trabalho e quem pode/irá executá-las;
• Concordar com acordos de trabalho compartilhados, incluindo
padrões de qualidade e práticas;
• Gerenciar e rastrear seu próprio progresso para completar o trabalho.
16
ALGUMAS CONSIDERAÇÕES
Fazendo isso juntas, se comunicando de forma adjacente, as pessoas

irão facilmente sentir o verdadeiro comprometimento, motivando as
conquistas e até mesmo a superação do objetivo. As pessoas querem a
oportunidade de ter orgulho de seu trabalho para se comprometer
com ele. Deming destacou isso em seu trabalho com os japoneses após
a II Guerra Mundial e documentou no livro Quality, Productivity, and
Competitive Position em 1982, posteriormente renomeado para Out of
the Crisis (Saindo da Crise) em 1986.)
Melhoria Contínua
Possivelmente, ao nos tornar ágeis, nada é mais importante que a busca
pela melhoria contínua. Na verdade, o ciclo de vida básico do ágil inclui
isso através da retrospectiva ao completar cada iteração de trabalho.
Infelizmente, algumas vezes, essa é uma etapa pulada do ciclo de vida,
seguido do planejamento (planning) e das reuniões diárias de acordo com
pesquisas da Version-One.
Uma variedade de coisas pode contribuir para essa jornada, mas a chave
são as ideias de melhoria trazidas pelas pessoas. Infelizmente, após listar as
possibilidades de mudança, essas ideias não são tratadas como itens sérios
de trabalho. Elas não são priorizadas, estimadas ou incluídas no esforço
de trabalho para a próxima iteração. Com isso, a próxima retrospectiva
ocorre e as mesmas ideias são levantadas.
Outra razão é que as pessoas sentem que não há tempo para conduzir a
retrospectiva por conta da pressão de prosseguir com o próximo conjunto
de requisitos do cliente. Claramente, o tempo e o esforço que conduzem
às melhorias devem mostrar benefícios, mas provavelmente não irão se as
pessoas não sentirem que podem dispor de tempo para tentar.
Para finalizar, ouço as pessoas dizendo: “Tudo foi perfeito nessa iteração,
portanto não há nada para mudar”. A retrospectiva é sobre melhoria, não
apenas para “consertar” as coisas. A menos que uma equipe nunca gere
defeitos, que tenha estimativas sempre exatas e seja totalmente produtiva,
sempre há algo que pode ser melhorado. Não é necessária uma grande
mudança, a ideia é ter a melhoria contínua como um hábito, chamado de
kaizen no lean. Todos os valores e princípios do Manifesto Ágil podem ser
mais efetivamente implementados de uma forma ou de outra em qualquer
organização.
17
Confiança
É dito que a confiança se ganha aos centavos e perdida em dólares, ou
seja, é difícil de conseguir, mas fácil de perder. Provavelmente nada é mais
prejudicial para um grupo do que a falta de confiança dentro dele ou dos
outros ao redor dele. Infelizmente, as práticas comuns de gerenciamento
de projeto são sempre baseadas ou conduzidas em algum aspecto da falta
de confiança. Porém, sem confiança, a comunicação aberta e a colaboração,
simplesmente não acontecem. As pessoas não buscarão novas ideias ou
tentarão novas maneiras de trabalhar se não sentirem que podem esperar
apoio dos outros quando fizerem.
Existem frases como: “Confiamos em Deus, para todo o resto tragam-
me dados”, “Confie em Deus, mas amarre seu camelo” e “Confie, mas
confirme”. A confiança não acontece automaticamente entre as pessoas,
pode-se presumir confiança até algum problema surgir, então o
apontamento de dedos é iniciado. É realmente difícil confiar em alguém
que não se teve uma experiência de trabalho positiva, e que não tenha
“dados” sobre essa pretensão. Somente a efetividade, a comunicação
deliberada, a colaboração e o comprometimento de todas as pessoas
trabalhando juntas podem prover esses “dados”, contribuindo fortemente
para criar a confiança.
Excelência
Por fim, há o desejo de se atingir excelência e não podemos assumir
excelência de todo mundo, mas podemos esperar que persigam
colaborativamente utilizando a melhoria contínua. A verdadeira
excelência pode ser, ou pelo menos parece ser, um alvo distante, mas
buscá-la é certamente razoável. Um problema frequente é decidir o que
significa excelência em um grupo de trabalho e como buscá-la. Acordos
de trabalhos estabelecidos e práticas de qualidade junto com o uso de
retrospectivas devem tornar essas decisões mais fáceis, ao mesmo tempo
em que constroem confiança.
18
CAPÍTULO 3
Indivíduos e Interações
Este capítulo começa com um conjunto de quatro partes focadas em

valores do Manifesto Ágil.
Indivíduos e interações
Acredito que qualquer pessoa que tenha trabalhado com outras pessoas,
seja no dia-a-dia ou em projetos, para um grupo comunitário local ou
até mesmo em um esforço familiar, concordaria que as interações dos
indivíduos dentro do grupo impactaram significativamente no resultado.
Se houver comunicação eficaz, colaboração e confiança entre as pessoas
em tais situações, elas provavelmente conseguirão superar muitas
limitações no processo, do ambiente e das ferramentas. Aqueles que
supervisionam ou gerenciam tais esforços devem considerar prioritário
que tal comunicação, colaboração e confiança existam e que, como
supervisores ou gerentes, protejam e encorajem essa existência.
Entretanto, o grande desafio deste processo no ambiente de trabalho é
que muitas equipes são distribuídas. De fato, em todas as empresas que
trabalhei como coach ou treinador na última década tinham equipes
distribuídas. O sexto princípio diz que, “O método mais eficiente e eficaz
de transmitir informações para, e dentro de um time de desenvolvimento,
é através de uma conversa cara a cara”. No entanto, as equipes localizadas
no mesmo ambiente frequentemente não usam este modelo com padrão.
Embora aborde as equipes distribuídas nos próximos capítulos, este é
certamente um ponto apropriado para iniciar essa discussão, considerando
os desafios para a comunicação, a colaboração e a confiança gerados pela
distribuição das equipes.
A maioria das pessoas pensam na distribuição como uma questão de
tempo e distância. Alistair Cockburn, no Capítulo 3 do livro Agile
Software Development, observa que o que importa é “a quantidade de
energia necessária para as pessoas trocarem ideias”. A comunicação
direta entre pessoas, cara a cara, pode ser desencorajada a distâncias
surpreendentemente curtas, se houver mais de 30 metros por exemplo. Se
a energia e o tempo que leva para parar o que estamos fazendo, se levantar e
ir até a outra pessoa é percebido como sendo muito grande, simplesmente
não fazemos. Nos comunicaremos como se fossem quilômetros ou como se
tivéssemos em continentes separados usando várias ferramentas baseadas
em texto. Curiosamente, as pessoas que reconhecem a distribuição em
grandes distâncias e tempo usam tecnologias que permitem se comunicar
20
INDIVÍDUOS E INTERAÇÕES
visualmente, como Skype, Google Hangout, Webex etc., mas talvez nunca
pensem em fazer isso localmente quando não estão dispostas a se levantar
e visitar outra pessoa.
Cockburn mostra a Figura 1 no livro Agile Software Development,
representando a “descoberta” de pesquisadores como McCarthy e
Monk (1994) quando mediram a qualidade da comunicação mediada
por computador. Falaremos mais sobre isso no Capítulo 12 quando o
sexto princípio for discutido. Por enquanto é importante observar que o
eixo vertical indica a eficácia do modo de comunicação de informações,
enquanto o eixo horizontal indica o impacto da comunicação)
2 people
at whiteboard
COMMUNICATION EFFECTIVENESS
2 people
on phone
ER
S
W
AN
D
Videotape AN
N
TIO
UES
Q
2 people
on email
ER
Audiotape SW
- AN
Paper TION
NO QUES
(cold) RICHNESS (”TEMPERATURE”) OF COMMUNICATION CHANNEL (hot)
Figura 1: Comparação dos meios de comunicação por efetividade

Juntos, os eixos mostram o tempo e a energia consumida para se comunicar,
note o impacto da documentação puramente baseada em texto, descrito
como “papel” no diagrama, em comparação com a conversa cara a cara
mediada por um quadro branco.
Processos e ferramentas
Muitas ferramentas permitem que as pessoas as abram e analisem o
status do trabalho em equipe sempre que quiserem saber alguma coisa ou
quando a ferramenta emite alertas sobre as novidades.
21
Comprometendo-se
com a interação
O importante é que haja o comprometimento com a interação, a
comunicação e o clima de equipe como um todo. Caso essa seja uma
tarefa difícil talvez seja interessante recorrer à troca de documentos, pois
ao dividir o trabalho, as pessoas não precisam necessariamente interagir.
Buscar maneiras pelas quais as pessoas possam compartilhar o trabalho
é na verdade uma forma de colaborar ao invés de apenas cooperar. De
acordo com uma das pesquisas anuais da VersionOne, cerca de 20%
dos entrevistados dizem que procuraram a agilidade para ajudá-los a
gerenciar melhor as equipes distribuídas, enquanto 61% disseram que, de
fato houve benefício ao adotar o método ágil. Acredito que isso se deva
ao compromisso de trabalhar a comunicação entre os membros e entre as
equipes. É um desafio, estando distribuído ou colocalizado, mas ser ágil
faz com que isso seja esperado de nós.
Um experimento
Aqui temos um experimento mental, ou talvez um exercício prático que
pode ser aplicado em um grupo de pessoas. Pense em alguma experiência
muito positiva na qual trabalhou com um grupo e em seguida anote
as características que a tornaram positiva em sua memória. Por fim
categorize como:
• Pessoas - Interações entre você e os indivíduos do grupo;
• Cultura - As suposições, acordos, atitudes e expectativas gerais do
grupo/organização;
• Processo - O(s) caminho(s) organizados pelo grupo de trabalho que
você criou e configurou;
• Ambiente - O ambiente físico real em que trabalhou;
• Ferramentas - As ferramentas, manuais ou eletrônicas, que usou para
fazer o trabalho.
Agora precisamos procurar o padrão agrupando as memórias a partir dessa
experiência. Onde essas características se enquadram nos agrupamentos?
(Se fizermos isso com um grupo inteiro, precisaremos escrever as ideias
em post-its e os colocar em um quadro ou parede com os títulos listados
para que todos possam ver o conjunto total de agrupamentos). O que isso
nos diz sobre a razão da experiência ser memorável?
22
CAPÍTULO 4
Software Funcionando
Alguém quer software que não funciona? Mas o que significa estar
funcionando? Significa não ter defeitos, certo? Significa ter sido
completamente testado, correto? A abordagem ágil para a qualidade espera
que no final de cada iteração de trabalho a equipe perceba a qualidade no
software produzido. Isto é, que pode ser colocado em produção sem que
a equipe se preocupe com as falhas no software quando confrontado com
as expectativas do cliente. A equipe deve estar confiante no tocante da
qualidade acerca do que produziram e não apenas com base na ausência
de defeitos.
Para ser totalmente útil em produção, todos os guias de usuário,
procedimentos de instalação, sistemas de ajuda, entre outros, devem
também estar completos, já que, sem esses artefatos a utilização do
software pode ser impossível, mesmo sem defeitos. O software não irá
“funcionar” na perspectiva do usuário final se o mesmo não puder usá-
lo, independentemente de quão livre de defeitos o software esteja. Da
perspectiva ágil, o “software” inclui a documentação necessária para o
usuário. Essa documentação é parte do que deve “funcionar”, tanto quanto
o código.
Mas voltando ao código, o que deve funcionar? Vamos olhar para um
simples exemplo do que um cliente pode requisitar: “Como cliente do
banco, quero uma lista de todas as minhas contas e balanços, para que eu
possa gerenciar minhas finanças”
Parece um requisito bem simples, porém vamos adicionar alguns critérios
de aceitação. Serão referenciados como Condições de Satisfação (CoS -
Conditions of Satisfaction).
• Quero a lista como uma lista pop-up acionável de qualquer parte do
sistema;
• Se a lista exceder 20 itens, quero ter uma barra de rolagem;
• Quero a lista ordenada por tipo de conta ou por saldo;
• Quero poder escolher a ordenação por saldo e em seguida por conta,
se assim desejar;
• Quero poder ver datas limites e requisições de pagamentos em contas
de débito (ex.: cartões de crédito, empréstimos).
• Quero ordenar por data limite ou pagamento requerido, quando
forem exibidos;
• Quero adicionar outros campos em cada item como <imagine outros
campos>;
24
SOFTWARE FUNCIONANDO
• Quero filtrar a lista por tipo de conta, saldo, data limite ou pagamento
requerido para diminuir a lista exibida;
• Quero poder pesquisar dentro da lista..
O software “funciona” se quaisquer das Condições de Satisfação não
funcionarem ou não existirem? Se implementarmos o requisito básico
e funcional, verificarmos que funciona, e então implementarmos cada
um dos CoS, e verificando seu êxito conforme cada adição, o software
“funcionará”? Do ponto de vista da qualidade, pode ser dito que o software
é funcional. E se um cliente tivesse uma parcial utilizável de cada CoS já
que o conjunto como um todo irá “funcionar” no curto prazo? Os clientes
irão preferir um incremento útil mais cedo do que mais tarde. Nem todas
as solicitações iniciais estariam lá, mas eles teriam o suficiente para ser
utilizado. E mais tarde, teriam muito mais do que requisitaram.
Para começar a equipe pode, dependendo do tamanho da iteração,
entregar as três primeiras funcionalidades e então adicionar duas novas
funcionalidades na iteração seguinte, seis na próxima e assim por diante.
Ao final de cada iteração, uma nova funcionalidade pode ser colocada em
produção à medida que o cliente, incrementalmente, tem mais softwares
funcionando.
Discutir o que faz o software minimamente viável pode fazer com que o
cliente tenha algo útil em vez de esperar por tudo no final do processo.
Isso é parte da ideia ágil para ordenar o trabalho baseado em valor ao
cliente e trabalhar para entregar resultados de alto valor mais cedo, de
forma frequente, durante um ciclo de lançamento ou projeto. Isso coloca
a decisão sobre o que constitui um lançamento viável nas mãos do cliente
ou no negócio e não na equipe de desenvolvimento. A equipe apenas
adiciona a próxima funcionalidade de maior valor e o cliente diz quando
está funcionando o suficiente para ser lançado.
Comunicação com o software

A importância da comunicação efetiva entre cliente e desenvolvimento
é evidente, mas e a comunicação efetiva com o próprio software? As
pessoas podem se comunicar com o software simplesmente utilizando-o.
O software responde, ou não, executando o que é esperado. Isso começa
quando a equipe verifica e valida o software através de formulários
de inspeção e testes. Então a equipe de produto ou o cliente podem
25
testar o software para ver como funciona. Feito de forma frequente,

essa comunicação pode reduzir o risco de defeitos não cobertos ou de
novas funcionalidades antecipadas, antes de se tornarem muito caras,
aumentando a satisfação do cliente com os resultados.
A empresa Menlo Innovations gosta de ter um representante do cliente
junto com os desenvolvedores no processo de criação de software. Ao
fim de cada semana, quando a equipe mostra o que completaram, o
representante do cliente exibe uma demo do software funcionando.
Essa pessoa esteve toda a semana discutindo as funcionalidades do
software com os desenvolvedores, observando a construção e ajudando
na verificação. Se não puderem mostrar alguma funcionalidade, algo de
errado aconteceu neste relacionamento durante a semana e isso precisa
ser redirecionado.
Implementar pequenas partes de funcionalidade, verificar se estão
corretas e validar que satisfazem as expectativas do cliente é a essência
do desenvolvimento ágil. Ao começar a trabalhar de maneira ágil, esse
processo pode ser difícil porque as pessoas estão acostumadas a ciclos mais
longos de desenvolvimento e pensam em termos de conjuntos maiores de
funcionalidade. Fazer o cliente, ou o negócio, pensar em partes menores
de funcionalidade e ciclos de lançamento reduzidos toma tempo, mas é
essencial para ter o software funcionando em produção o quantos antes
em vez de esperar muito tempo para ter todas as características prontas.
Observei uma equipe que trabalhou duro para quebrar uma funcionalidade
em partes entregáveis, incluindo a documentação relevante para o
usuário, eles decidiram trabalhar em ciclos curtos de entrega ao invés de
entregar tudo em algumas semanas. Isso aumentou a colaboração entre os
desenvolvedores, analistas de qualidade e técnicos, tornando a colaboração
mais fácil. Isso também resultou na redução do tempo gasto pela equipe
para estimar o esforço. O esforço para cada tarefa era tão pequeno que
tudo foi estimado em 2 pontos (utilizando a escala de Fibonacci para story
points). Eles usaram o tempo quebrando as histórias, parte importante
para permitir o desenvolvimento, os testes e fazer entregas frequentes,
eliminando grande parte do esforço de estimar.
26
SOFTWARE FUNCIONANDO
Documentação Compreensiva
Manuais de usuário, guias de instalação, sistemas de ajuda, são
considerados parte do “software” na perspectiva ágil. A documentação
“compreensiva” mencionada por esse valor é interna, os formulários de
documentação de sistema geralmente não são usados uma vez que um
projeto ou lançamento é realizado. A justificativa que pode certamente ser
feita é que a documentação detalhada é importante para o histórico, mas
pode não ser a melhor forma de comunicação entre as pessoas ativamente
desenvolvendo o sistema. Essa documentação “compreensiva” pode
contribuir com o próximo projeto ou entrega, mas o objetivo imediato
é entregar os requisitos o mais rápido e o mais barato que o nível de
qualidade e confiabilidade possam permitir.
Muito anos atrás, estava em uma conferência e Barry Boehm falou sobre
as “bibliotecas de memória” que viu em diversas empresas, estantes e mais
estantes preenchidas com documentos e que as únicas pessoas interessadas
eram os auditores quando precisaram verificar o que aconteceu, isso
quando não estavam ali para ver com os próprios olhos. Se estamos
gerando qualquer volume de documentação, devemos aceitar o custo
total de propriedade (TCO - Total Cost Ownership) fazer o investimento
para manter a documentação atualizada. Como desenvolvedor, descobri
muitas vezes que não podia confiar na documentação, porque ela não
correspondia ao código. Utilizo uma semana, às vezes, tentando debugar
um problema ou adicionar uma funcionalidade, acreditando no texto da
documentação, utilizando tanto a de fora quanto a de dentro do código.
Uma vez trabalhei onde, ao invés de atualizar a documentação original para
corresponder ao novo trabalho, as pessoas criaram adendos que apenas
continham as alterações feitas. Após alguns anos, se você quisesse usar ou
confiar na documentação, teria de ler de 6 a 8 documentos, o original e
diversos adendos. Eventualmente, as pessoas apenas não se importavam
com isso, o que levava a não ligar para a documentação como um todo
depois de um tempo. A velha visão centrada no desenvolvimento, na qual
você precisava ler o código para saber o que o sistema faz, se perpetuava
como sendo a única “documentação” confiável.
Obviamente que a abordagem ágil não significa rejeitar toda
documentação, a ideia é trabalhar de forma que a documentação tenha
valor “sustentável”. Por “sustentável”, queremos dizer que a documentação
deve ser considerada com mesmo valor para quem cria, para os
desenvolvedores de software que prezam
27
a alta qualidade e para as pessoas que a manterão atualizada. O

desenvolvimento ágil prefere produtos executáveis (como os testes) aos
estáticos (como os tradicionais documentos escritos). Na realidade, um
forte conjunto de testes automatizados é na prática um conjunto de
requisitos executáveis.
Partir das histórias de usuário para software funcionando e testado, usando
fortes práticas de programação e convenções de nomes significativos,
implicará em menor necessidade de documentação tradicional. Há o risco
quando o código escrito não pode ser verificado de forma rápida para
uma possível correção. O intervalo entre escrever o código e verificar o
código contém riscos. No desenvolvimento tradicional, esse tempo pode
ser de semanas ou até mesmo meses. O objetivo é encurtar esse tempo o
máximo possível. Discutiremos mais sobre as abordagens de qualidade e
testes nos capítulos posteriores.
Uma vez trabalhei como coach de um projeto com três equipes,
aumentando para cinco equipes em dez meses de projeto. No início as
equipes podiam ter uma versão a cada quatro semanas, o tamanho da
iteração. Cada versão era feita por um grupo diferente, alocados em
outros estados, suportando todos os projetos da empresa. Podemos
imaginar o que isso significava na produtividade das equipes quando
tentavam honrar o software funcionando em cada iteração. Foram vários
meses de gerenciamento para que aquele projeto tivesse uma versão a
cada semana e posteriormente a cada dia, e então, um pouco depois disso,
tivesse duas versões por dia, uma pronta toda manhã para as equipes da
Costa Leste e uma no final do dia para os membros que trabalharam fora
do escritório. A habilidade, a confiança e a produtividade das equipes
cresceu substancialmente em cada uma das junções. Em cada etapa deste
processo a velocidade aumentou entre 10% e 15%.
O fator chave para lembrar é que a comunicação e não a documentação
deve ser o objetivo. Uma vez que a mesma solução não serve para todos
os problemas, cada lançamento ou projeto deve avaliar as necessidades
de comunicação, para quem será destinada e qual a melhor maneira de
ser feita. Aceitar “a forma que sempre foi feita” não irá ajudar a entregar
o software funcionando com frequência e que atenda às necessidades do
cliente. Na verdade, pode até impedi-la.
28
CAPÍTULO 5
Colaboração com o Cliente
Como mencionado no Capítulo 2, esse valor pode ser visto como uma das
formas de interação entre indivíduos, mas acredito que seja uma situação
diferente de como as pessoas, na organização interagem e qual deve ser
o conteúdo dessa interação. A colaboração com os clientes é focada na
perspectiva sobre “o quê” do trabalho ao invés do “como”. Ou seja, o
foco é no “o quê” os clientes querem como funcionalidade e o que vão
precisar ver como evidência para que a funcionalidade seja considerada
satisfatória.
Para isso, os clientes devem trabalhar mais no “como” na mesma proporção
que tentam definir “o quê”. É comum, com o tradicional documento de
requisitos, entrar em detalhes sobre “o quê” e “como”. Novos clientes com
a abordagem ágil podem requerer os dois, podendo considerar ainda
mantê-los separados para isolar sua habilidade de definir os requisitos. A
abordagem ágil recomenda não se aprofundar no “como” logo no início
dos trabalhos por algumas razões:
• Isso pode significar utilizar muito tempo em algo que não será
desenvolvido, pois os clientes mudam suas intenções no decorrer do
desenvolvimento;
• Mesmo que seja desenvolvido, as pessoas saberão mais sobre o que é
necessário conforme se aproximam da decisão que terão de tomar. A
abordagem ágil recomenda esperar até “o último momento” antes de
um comprometimento, assim teremos o máximo de conhecimento
possível no momento da decisão;
• Ao chegar no tempo de desenvolvimento, podemos encontrar
restrições desnecessárias nas decisões. Alguém pode, por exemplo,
espremer 5kg de batatas em um saco de 2kg, mas não podemos
esperar batatas fritas depois disso;
Todos esses pontos também são boas razões para não termos detalhamento
do “o quê” tão cedo.
É importante que os clientes enxerguem valor em uma comunicação
aberta e frequente sobre o que querem e aquilo que o desenvolvimento
pode mostrar em funcionamento como uma maneira de reduzir riscos e
aumentar a satisfação com os resultados..
Quando presenciei organizações forçadas a trabalhar com clientes, tanto
internos quanto externos, e que não aceitaram isso, houve um estresse
notável de ambos os lados. Mais de uma vez ouvi a equipe de negócios
dizer que não tinha tempo para reuniões frequentes, mas que “precisavam
de tudo pronto no prazo” e não queriam usar o tempo para priorização.
30
COLABORAÇÃO COM O CLIENTE
Nem sempre funciona, mas minha argumentação básica com eles é mais
ou menos assim:
“Vocês sempre conseguem tudo o que querem na data final do projeto?”
Eles olham para mim como um inocente e dizem, “Quase nunca.”
“Mas vocês sempre conseguem as coisas mais importantes nessa data
final, correto?”
Agora olhando como se eu fosse realmente inocente, “Não. Geralmente
não.”
“É por isso que pedimos priorização e feedback constantes, dessa forma,
se houver problemas todas as funcionalidades de maior valor possível e da
forma que querem serão entregues no prazo estabelecido.”
Algumas vezes a discussão cessa neste momento.
Negociação de contratos
Infelizmente muitos contratos parecem ser escritos, não para descrever
como o fornecedor e o cliente irão trabalhar juntos para o sucesso,
mas para definir punições para quando uma das partes falhar com suas
responsabilidades. Isso não parece uma maneira de estabelecer uma
relação de colaboração particular entre as pessoas. Os contratos também
parecem ser baseados na crença de que tudo o que é necessário deve
ser definido antecipadamente. Uma abordagem mais incremental para
definir como o trabalho será feito e como as pessoas irão trabalhar juntas,
colaborativamente, para produzir os resultados mais satisfatórios deve
ser a parte crítica de qualquer contrato.
De uma perspectiva ágil, o cliente e a fornecedora da solução devem
explorar as expectativas para a participação do cliente, nos seguintes
momentos:
• No processo iterativo de requisitos (ex.: user stories), definição e
refinamento;
• Na resposta rápida a questões durante o lançamento ou no projeto
para clarificar expectativas de funcionalidade;
• Na definição de critérios de aceitação (condições de satisfação) para
cada requisito;
31
• Em cada revisão de funcionalidades desenvolvidas durante aquela

iteração;
• Em oferecer feedback para confirmar a aceitação do que a equipe fez
ou o desejo de quaisquer mudanças;
• Na elaboração contínua de funcionalidades conforme a equipe avança
na priorização, da mais alta até a mais baixa;
• Em priorizar os requisitos do valor mais alto ao mais baixo para que a
equipe sempre trabalhe na funcionalidade pendente com maior valor
Se os clientes não estão preparados para realizar essas atividades, ou pelo
menos parte delas (o que depende do projeto), então um contrato mais
“preventivo” pode ser uma opção inteligente.
Há uma variedade de lugares para ver opiniões sobre estruturar
contratos ágeis. Apenas digite: “contratos de desenvolvimento ágil”
(“agile development contracts”) no seu navegador favorito. Algumas
possibilidades são:
• https://en.wikipedia.org/wiki/Agile_contracts (que fala basicamente
sobre contrato “ágil de preço fixo”);
• https://www.mountaingoatsoftware.com/articles/writing-
contracts-for-agile-development (que utiliza user stories e condições
de satisfação para documentar expectativas contratuais);
• https://www.scaledagileframework.com/agile-contracts/ (direciona
sobre o contrato de investimento-gerenciado do Scaled Agile);
• http://www.agilecontracts.org/ (44 páginas do livro Practices for
Scaling Lean & Agile Development por Craig Larman e Bas Vodde
sobre a definição de contratos ágeis).
32
CAPÍTULO 6
Responder a Mudanças
Talvez nada represente melhor a definição tradicional de “ágil” do que

esse valor. Uma definição típica diz: “capaz de se mover rápido e fácil”
com sinônimos sendo “veloz, maleável, flexível, acrobático, ligeiro, rápido,
leve, alerta, afiado, aguçado, esperto, astuto, perceptivo, perspicaz”. Todos
eles implicam uma habilidade de mudar com mínimo esforço, mas há
outra coisa implícita.
Aqui estão alguns pensamentos de um artigo intitulado “Mountaineering
Training | Body Awareness: Balance & Agility” (“Treinamento de
montanhismo | Consciência do Corpo: Equilíbrio e Agilidade”, tradução
livre). O primeiro artigo que me lembro sobre a abordagem ágil foi um
escrito por Jim Highsmith comparando desenvolvimento de software e
escalada.
Consciência corporal é a combinação de equilíbrio e agilidade que permite
nos mover confortavelmente e confiantemente através de terrenos difíceis e
desafiadores.
Equilíbrio em montanhismo nos permite escalar em condições desafiadoras…
enquanto mantemos o equilíbrio e evitamos usar a energia ou a concentração
excessiva para nos mantermos concentrados. De modo simples, é estar confortável
com seus pés mesmo quando atravessamos um terreno desconfortável.
Agilidade é poder se mover rápido e facilmente - ser veloz e reativo… para reagir
ao inesperado...
...Equilíbrio e agilidade são habilidades motoras e podem ser melhoradas com o
passar do tempo.
Portanto, não é apenas se mover rápido, mas manter a estabilidade
durante o movimento. Responder à mudança de forma responsável e
significativa não se trata apenas de mudança, mas direcioná-la a uma
maior estabilidade de resultados. Da perspectiva de software, isso significa
produzir entregas mais satisfatória e úteis ao cliente. Isso envolve utilizar
várias capacidades e habilidades, incluindo estar alerta e ter a percepção
para decifrar as implicações da mudança, em decidir mudar e basear essa
mudança na melhor informação disponível para a tomada de decisão.
Não é uma licença ad hoc ou para fazer algo quando “deveria saber mais”.
Falaremos mais sobre isso no Capítulo 15 no nono princípio.
Da perspectiva de implementação, isso significa construir um processo
de trabalho que permita mudanças com risco e custo reduzidos. Uma
abordagem iterativa e incremental tem sido aceita como a melhor forma
de fazê-la. Em junho de 2003, Victor Basili e Craig Larman publicaram
34
RESPONDER A MUDANÇAS
um artigo intitulado “Iterative and Incremental Development: A Brief

History” (Desenvolvimento Iterativo e Incremental: Uma Breve História,
tradução livre) no IEEE Computer, no qual apontaram que isso tem sido
aceito 13 anos antes do desenvolvimento em cascata definido em um artigo
por Winston Royce em 1970. Basili e Larman têm muito a dizer sobre o
modo cascata, incluindo o que o filho de Royce disse, que o próprio Royce
sentia que a abordagem em cascata “poderia não funcionar para todos,
mas na maioria de projetos diretos” e como o restante do artigo abordou
as “práticas iterativas”.
Seguindo um plano
Há uma abundância de literatura relacionada ao ágil sobre as dificuldades
e potenciais desperdícios de planejamentos detalhados de longo prazo ao
trabalhar em situações complexas em que mudanças são inevitáveis e a
habilidade de prever o resultado desejado exato é limitado.
Considere a abordagem típica de criação do plano do projeto de distribuir
um documento de requisitos detalhado e pedir às pessoas para estimar,
em horas, todas as tarefas necessárias para produzir o resultado descrito.
Esse processo leva muitas horas por si só. Eventualmente, todos esses
dados são enviados a um gerente de projetos que alimenta um sistema de
gerenciamento de projetos e, em um determinado momento, um plano
de projeto passa a existir. O plano diz, por exemplo, “Em sete meses, na
quarta-feira às 15h, a tarefa XPTO vai ser realizada”. Quem acreditaria
nisso? Quem garante que a pessoa que forneceu aquela informação vai
produzir o resultado daquela tarefa naquele dia? Todo mundo sabe que as
coisas mudam e o gerente de projetos usa um tempo considerável a cada
semana ajustando o planejamento.
Tudo isso pressupõe que todos entenderam o que está descrito e que o
plano descreve o que o cliente quer, porém é justo requisitar (ou presumir)
que as pessoas, especialmente o cliente, podem compreender tudo e como
deve funcionar antes de qualquer modelo ou trabalho funcionando?
Assim como presumir esse conhecimento futuro, também podemos
esperar que uma vez que o esforço considerado em fazer toda essa
definição e planejamento esteja completo (o que em algumas estimativas
pode consumir mais de 50% do cronograma do projeto), nada importante
pode ser alterado, ou ainda mais crítico, aprendido?
35
A partir de fontes da história do planejamento militar temos frases

atribuídas a pessoas como von Moltke: “Nenhum plano sobrevive ao
contato do inimigo.”. Em outras palavras: “Nenhuma operação perdura
com qualquer certeza antes do primeiro encontro com o grupo inimigo.” -
apesar de a primeira versão parecer mais fácil de entender. Também temos
Eisenhower dizendo: “Na preparação para a batalha, sempre descobri que
planos são inúteis…”, as reticências, porém representam “mas planejar é
indispensável”. O que nos leva à abordagem ágil do planejamento que,
como o próprio desenvolvimento, acontece cedo, com frequência e é
iterativo.
Planejar com toda a equipe envolvida é o que importa, não o plano em
um determinado tempo. O planejamento nos faz comunicar, colaborar,
construir a convicção e a confiança em como iremos trabalhar na direção
do atual entendimento. Todos os dias, uma equipe ágil tem a chance de
ver onde cada um está e determinar, se onde estão e para onde estão indo,
precisa ser ajustado baseado em uma nova informação.
Equipes ágeis contribuem para construir um plano de lançamento
baseado na funcionalidade desejada, o quanto dela a equipe acredita que
pode entregar em cada iteração e em quantas iterações serão necessárias
para entregar toda essa funcionalidade. Mas as coisas mudam: as equipes
podem encontrar melhores formas de entrega; o cliente pode mudar o
que requisitou, baseado em uma versão anterior do software; às vezes
o negócio pode sentir que pode lançar uma alteração de valor antes do
planejado; e, é claro, pode ser que nem tudo originalmente desejado pode
ser feito com o orçamento e tempo disponíveis. Ao usar uma abordagem
ágil, pelo menos o que está sendo feito deve ser a funcionalidade de maior
valor. No Capítulo 5, por exemplo, há uma discussão sobre esse tópico
com um gerente de projetos.
36
CAPÍTULO 7
Satisfação do cliente
“Nossa maior prioridade é satisfazer o cliente através da entrega contínua e

adiantada de software com valor agregado.”
Este capítulo começa com os 12 princípios encontrados em http://
agilemanifesto.org/principles.html.
Nossa maior prioridade

Ser ágil significa inicialmente ser dedicado e satisfazer as expectativas do
cliente. Não significa que “o cliente está sempre certo”, mas significa que o
cliente merece ser levado a sério, sempre. Isso também significa que tentar
satisfazer as expectativas do cliente é considerar que o cliente e a equipe
de desenvolvimento sejam cientes disso e que ambos podem colaborar
para atingir esse nível de satisfação. Com isso voltamos à comunicação,
colaboração, comprometimento, melhoria contínua, confiança e
excelência. Nem todos conseguirão atingir isso satisfatoriamente sem
considerar esses fundamentos.
Suponho que a seguinte frase, ou semelhante, seja comum: “É difícil
lembrar que deveríamos estar drenando o pântano quando estamos
constantemente lutando contra os jacarés.” Há muitas coisas que podem
tirar o foco do nosso principal objetivo: satisfazer as expectativas do
cliente. Existem outras prioridades e burocracias nos silos organizacionais.
Existem dependências entre equipes, desafios tecnológicos e os requisitos
em si, que, nos muitos detalhes, podem realmente obscurecer o que é
realmente necessário. É preciso lembrar que o pensamento lean é uma
das raízes da abordagem ágil. Uma ideia chave do lean é a eliminação do
desperdício, ou seja, a eliminação de qualquer coisa que não contribua
diretamente para a criação e a entrega de valor ao cliente. Fazer um
mapeamento do fluxo de valor do seu processo pode trazer visibilidade
para onde residem os desperdícios, além de atribuir impacto quantitativo
a eles. Isso geralmente é calculado como o tempo gasto em cada etapa do
processo, mais o tempo gasto, aguardando, entre as etapas.
Embora as áreas de desperdício possam parecer óbvias, isso talvez não
esteja claro para todos. Muitos dos desperdícios de uma organização
não apareceriam em um diagrama de processo formal. Honestidade na
comunicação é fundamental para isso. Você deve ser capaz de mostrar
o que está realmente acontecendo, não o que todo mundo acha que está
acontecendo. Isso provavelmente significa que será preciso falar sobre o
38
SATISFAÇÃO DO CLIENTE
“elefante na sala” e o “peixe morto embaixo da mesa”: aquelas coisas que

todo mundo ignora quando realizam seu trabalho apesar do “cheiro”.
Entrega contínua e adiantada

Entregar o software funcionando para o cliente o mais rápido possível.
Manter isso a cada iteração e trabalhar de forma colaborativa com o
cliente para obter feedback que permita saber se ele está satisfeito com
o que foi entregue e/ou com as alterações requisitadas. Normalmente
desejamos entregar algo rápido para que o cliente esteja imediatamente
envolvido conosco. Não há como desaparecer por semanas ou meses para
fazer o trabalho de ‘infraestrutura’ sem exibir nenhuma funcionalidade
real ao cliente. Podemos perder o compromisso do cliente em participar
do processo e de fornecer feedback.
Espera-se que uma iteração ágil ofereça valor reconhecido pelo cliente.
Essas iterações não podem ser consideradas ágeis se não o fizerem.
Desejamos fazer isso continuamente para manter o engajamento do
cliente e garantir que não haja desvios em relação ao que o cliente deseja,
mesmo que ele queira alterações (na verdade, ainda mais se ele quiser
alterações). Isso exige comunicação, colaboração e melhoria contínua,
reforçando o compromisso, a confiança e a excelência.
Em um capítulo futuro, exemplos e demonstrações sobre a criticidade
da participação ativa do cliente em análises/demonstrações em iterações
serão tratados.
Software com valor agregado

Quem não deseja um software que entrega valor? Mas há muitos fatores
que podem ser utilizados para agregar valor ao software, e alguns fatores
que trazem mais valor do que outros. Em última análise, o valor está
referenciado no cliente e é por isso que a colaboração com o cliente se
torna tão importante para alcançar a satisfação. O que torna uma parte da
funcionalidade valiosa para eles? O que eles esperam conseguir com essa
funcionalidade? Como as coisas funcionarão melhor com essa entrega?
Entender sua proposição de valor para uma parte da funcionalidade pode
39
transmitir seu senso de urgência/prioridade, bem como informar melhor

a equipe de desenvolvimento sobre a melhor forma de implementar essa
funcionalidade.
Apesar disso, algumas vezes outros fatores podem afetar a prioridade,
mais que o valor para o cliente. Por exemplo, certa vez trabalhei com uma
equipe cujos produtos eram usados em usinas nucleares (entre outros
lugares). Eles precisavam atender aos requisitos da Comissão Nuclear
Reguladora, que solicitava substancialmente mais documentação do que
outras equipes da mesma empresa.
Essa documentação também teve que ser criada com as funcionalidades
descritas e aprovada antes do trabalho começar. Embora as
funcionalidades tenham maior valor para o cliente, havia uma prioridade
para essa equipe criar e aprovar a documentação antes da funcionalidade.
Às vezes, a prioridade de várias formas de regulamentos de conformidade
pode substituir outro valor funcional mais diretamente. Mesmo que você
não queira adiar o trabalho em itens de valor para o cliente, as restrições
de tecnologia e infraestrutura podem exigir que algumas coisas devam
existir antes que se possa mostrar um software totalmente funcional e que
satisfaça o cliente. Por exemplo, se alterações no banco de dados forem
necessárias para dar suporte à funcionalidade necessária para o cliente,
durante o andamento desse trabalho interno, uma funcionalidade de
visualização para que o cliente pudesse obter feedback mais cedo poderia
ser desenvolvida. Uma simulação o banco de dados seria suficiente para
mostrar ao cliente o que funciona.
Uma outra equipe com a qual trabalhei tinha que fazer exatamente
isso. Um requisito do cliente especificou inserir novos formatos de
dados e fazer com que o banco de dados respondesse com alguns dados
correspondentes. O trabalho no banco de dados tinha que ser realizado
por um grupo fora da equipe, entretanto, estes não estavam disponíveis.
Mas a prioridade do cliente era ver a funcionalidade como o próximo
item de maior prioridade. A equipe decidiu dividir essa funcionalidade
em três histórias separadas: uma para obter os dados do cliente e enviá-
los ao banco de dados, outra para recuperar os dados do banco de dados e
exibi-los como o cliente desejasse e a terceira para integrar as outras duas
partes quando o grupo de banco de dados decidisse fazer as atualizações
necessárias.
A equipe poderia ter movido todas as funcionalidades, mas eles achavam
que isso teria forçado o cliente a lidar com seus problemas organizacionais.
Portanto, eles concluíram as duas primeiras histórias, simularam o back-
40
SATISFAÇÃO DO CLIENTE
end do banco de dados e mostraram o resultado ao cliente na revisão da

iteração, certificando-se de que o cliente entendeu que levaria dois ou três
meses antes que o trabalho de back-end pudesse ocorrer. Mas o cliente
conseguiu ver o que precisava e teve algumas sugestões para pequenas
alterações, que a equipe fez na iteração seguinte. Duas iterações depois,
o trabalho do banco de dados foi concluído e a “história de integração”
foi concluída com êxito. A funcionalidade totalmente ativa foi então
demonstrada.
Não foi a maneira mais lógica para trabalhar, mas mantinha a prioridade
do cliente sobre o que eles queriam ver, sem enganar o cliente sobre o que
estava ou não funcionando. A equipe e o cliente sentiram que essa foi a
abordagem de maior valor.
41
CAPÍTULO 8
Abraçar as mudanças
ABRAÇAR AS MUDANÇAS
“Mudanças nos requisitos são bem-vindas, mesmo tardiamente no

desenvolvimento. Processos ágeis tiram vantagem das mudanças visando
vantagem competitiva para o cliente.”
Vantagem competitiva
para o cliente
É apropriado que este seja o segundo princípio listado. Parte da satisfação
dos clientes envolve fazer coisas que ofereçam vantagem competitiva aos
seus negócios. Construir sistemas corretos, que seguem os requisitos por
exemplo, é o jeito mais básico de realizar isso, porém o que é o “correto”
pode mudar a todo momento e isso geralmente significa ter que alterar o
sistema em algum ponto. Vale lembrar que alterar um sistema, incluindo
a implementação do requisito, fornece valor ao cliente. O ponto desse
princípio é considerar seriamente os pedidos de mudança, ao invés de
simplesmente contestar, o foco é possibilitar maior vantagem competitiva
ao cliente.
Mudanças nos requisitos

são bem vindas
Provavelmente ninguém que desenvolve aceite totalmente requisitos que
mudam. Algumas discussões com alguns dos que ajudaram a escrever
o Manifesto sugeriram que a essência desse princípio significa que a
equipe de desenvolvimento não deve criar barreiras desnecessárias
para a mudança, como simplesmente resistir a esses pedidos. Sim, eles
consomem bastante tempo e orçamento tentando fazer o sistema o mais
correto possível baseado nas respostas do cliente, mas o cliente quer uma
alteração. Se o cliente entender e aceitar as consequências dessa alteração,
a equipe deve trabalhar para tornar aquela alteração possível.
É claro que as consequências de tal mudança podem ser:
• Estender a data limite planejada, se o cliente ainda quiser os demais
requisitos na data limite original;
43
• Aumentar o orçamento, mesmo que ainda desejem manter o que já

foi feito;
• Adiar alguma funcionalidade para além da data limite atual e/ou
orçamento, para continuar dentro da data limite e orçamento;
• Impactar na arquitetura e no design para limitar opções futuras, o
que é menos fácil de explicar, pelas consequências técnicas que
representam.
No entanto, se o cliente entende e aceita esses impactos, a equipe de
desenvolvimento deve fazer as alterações. Já me relataram que isso não
é diferente de projetos regulares e dos impactos das alterações. Isso é
verdade, exceto que a opção de aceitar todas as alterações sem impacto
ao custo, ao planejamento, ou outros escopos definidos, não é suportada
como uma abordagem ágil razoável.
A habilidade de acolher mudança, no entanto, pode depender de uma
grande negociação sobre a excelência no design do sistema existente. Se
as pessoas não puderem confiar em alterar o sistema, porque o código
não é bem estruturado e os testes existentes são inadequados ou caros (e
lentos) para rodar, as pessoas podem se tornar resistentes, ou ao menos
avançar mais lentamente, em fazer alterações. Se sentirmos que não
podemos explorar o sistema para entender o que ele faz atualmente e
fazer alterações sem medo de causar novos defeitos, ou ainda, descobrir
defeitos existentes que não podem ser facilmente encontrados, teremos
que ser mais cautelosos ao fazer alterações. No final, a velocidade pode
diminuir por causa dessa cautela.
É claro que mudanças são mais fáceis quando o sistema é mais
compreensível de se alterar. Uma tautologia, certamente, mas boas
práticas tornam as mudanças mais fáceis. Alguns exemplos rápidos de
episódios de desenvolvimento e testes robustos podem ser úteis.
Uma empresa para qual prestei consultoria foi capaz de compilar e testar
seu sistema de quarenta milhões de linhas todas as noites, isso porque
investiram significativamente em testes automatizados. Inclusive, não
presenciei nenhum grande esforço de desenvolvimento obter os resultados
de produtividade esperados do ágil sem um robusto teste automatizado.
Uma equipe no centro do sistema tinha mais de vinte mil testes que
rodavam todas as noites, deixando-os confiantes todas as manhãs de que
seu trabalho não impediria outras partes do sistema.
Outra empresa tinha um sistema menor, mas não menos complexo, de 1,5
milhão de linhas. Eles compilavam e testavam a cada duas horas. Se um
44
ABRAÇAR AS MUDANÇAS
desenvolvedor fizesse o check-in de um código e o teste associado (que

deveria estar incluído) dentro de duas horas e a cada duas horas, o sistema
automaticamente compilava e executava todos os testes prévios e novos.
Se essa execução automática ficasse quatro horas sem rodar, um gerente
poderia aparecer e perguntar o porquê. A equipe esperava pequenos
incrementos de nova funcionalidade frequentemente e seguros de um
sistema estável. Se ele não estivesse, identificar o código com problema
era fácil. (Lembro-me do personagem do filme “Os Guerreiros Pilantras”
que descrevia quão rápido seu tanque podia ir em marcha ré, ele dizia
“Gostamos de saber que podemos sair de um problema mais rápido do
que entramos.”)
Ambas as organizações, a cada manhã, ou ciclo de duas horas, sabiam
da estabilidade de seus sistemas. Podemos fazer alterações ainda mais
confiantes se esse tipo de visibilidade for possível. Quanto mais longo o
tempo entre a compilação do código e seu teste, maior será o risco e mais
lento será o desenvolvimento.
Ao final do desenvolvimento
Se os desenvolvedores não gostam de alterações, gostam menos ainda ao
final de um lançamento/projeto. Um sistema bem desenhado e facilmente
testado significa que, mesmo com mudanças tardias (considerando
o entendimento e a aceitação das consequências) não deverão causar
grandes preocupações. A natureza iterativa do desenvolvimento
ágil permite oportunidades consideráveis para revisar o estado do
sistema e fazer mudanças mais cedo, ao invés de mais tarde, através da
oportunidade de ver e fornecer feedback sobre o software funcionando
no fim de cada iteração. Esse geralmente não é o caso em uma abordagem
mais “sequencialmente faseada” (um termo bonito para “cascata”) em que
o verdadeiro estado e adequação do sistema não é visualizado até o fim do
desenvolvimento.
A aversão às alterações e principalmente alterações tardias, deriva da forma
tradicional de desenvolvimento, e mudanças acontecem. Muito tempo e
orçamento foram gastos criando e implementando requisitos detalhados.
Muitas suposições de design têm sido baseadas em entendimentos iniciais
dos requisitos. Mudanças tardias geralmente significam que bastante
tempo e orçamento será gasto para retornar e atualizar e corrigir entregas
intermediárias, não apenas o código em si. Enquanto isso acontece, o
45
trabalho técnico pode parar, no mínimo em algumas partes do sistema, e

as pessoas precisarão realizar outras tarefas para se manterem ocupadas.
Elas serão então requisitadas a voltarem onde estavam e realizar as
alterações. Fazer muitas coisas ao mesmo tempo e interrupções no fluxo
de trabalho leva à perda de produtividade
Obviamente, sob pressão para fazer alterações rapidamente, as pessoas
podem realizar o trabalho pulando certas práticas de qualidade, por
exemplo, code review e testes unitários, trabalhar muito, além do tempo
normal, além de pular a atualização de documentação. Naturalmente,
todas essas podem ser más ideias, essa última já foi mencionada no
Capítulo 4 e as outras duas comentarei nos próximos capítulos.
46
CAPÍTULO 9
Entrega contínua
“Entregar frequentemente software funcionando, de poucas semanas a poucos

meses, com preferência à menor escala de tempo.”
Entregar frequentemente
software funcionando
O Capítulo 7 discutiu a “entrega contínua e adiantada” e no Capítulo
4 falamos sobre o software em funcionamento. A “frequência” está
implícita na entrega contínua quando falamos: “Entregar o software
em funcionamento para o cliente o mais rápido possível e continuar a
fazer isso a cada iteração...”. O que não comentamos foi quanto tempo
uma iteração teria. Grande parte dos líderes e agile coaches que conheço
incentivam os clientes a considerar iterações de no máximo duas semanas.
O que não era o caso quando o Manifesto Ágil foi escrito.
De poucas semanas
a poucos meses
Quando o Manifesto Ágil foi escrito, as várias abordagens consideradas
“leves” tinham ciclos de uma semana até três meses. Dessa forma, isso
me parece mais um compromisso entre todas as pessoas envolvidas.
Considerando que metade dos participantes trabalhassem com Extreme
Programming (XP), Scrum e outras abordagens, podemos acreditar
que uma frase como “de uma a quatro semanas” poderia ser algo que os
deixasse todos felizes. No entanto, isso não deve ter funcionado para
todos.
Dar preferência a escalas

de tempo mais curtas
Essa frase, encerrando o princípio, representa os defensores de um prazo
mais curto e talvez o reconhecimento de que essa parecia ser a direção que
se seguia. Atualmente, não existem muitas referências sobre as abordagens
48
ENTREGA CONTÍNUA
com ciclos de tempo maiores. Aparentemente o último livro sobre Design

Orientado a Recursos (Feature-Driven Design - FDD) foi escrito em 2002,
embora o artigo da Wikipédia pareça ter recebido inúmeras atualizações
ao longo dos anos. O método dinâmico de desenvolvimento de sistemas
(Dynamic Systems Development Method - DSDM) continua sendo uma
comunidade ativa que recomenda prazos mais curtos, embora tenha
documentação online bastante volumosa em dois conjuntos: DSDM e
Atern. Este último é descrito como “um framework baseado nas melhores
práticas e lições aprendidas pelos membros do DSDM Consortium” e é a
forma atualizada da abordagem do DSDM. Os livros comerciais datam
de 2002.
Por que iterações curtas?

Para algumas pessoas a ideia de entregar o software em funcionamento
para a revisão do cliente em poucas semanas (ou em ainda menos, a
cada semana, como nas equipes que usam XP) parece inconcebível. Isso
significa dizer: “incapaz de ser imaginado ou compreendido mentalmente;
inacreditável”. Recomendaria que a maioria das equipes ágeis iniciasse
com iterações de duas semanas, mas acredito que são necessárias de três a
quatro iterações para que as equipes comecem a entender o que significa
trabalhar em conjunto de maneira ágil. Uma equipe provavelmente pode
realizar entregas em dois meses ao invés vez de quatro, o importante é
lembrar que sempre podemos alterar para três ou quatro semanas, caso
seja necessário.
Mike Cohn, um dos coaches de CSM junto com Ken Schwaber, disse que
quando as equipes Scrum o procuraram pedindo para estender as Sprints
de quatro semanas para seis semanas por exemplo, ele dizia: “Por que não
tentamos Sprints de duas semanas ao invés disso.” Enquanto a equipe
acreditava que não poderia fazer a entrega em quatro semanas e que
precisava de mais tempo, a ideia de Mike era tentar descobrir o quanto
realmente podia ser feito em duas semanas. A concepção era de que se não
pudermos prever razoavelmente o que pode ser feito em quatro semanas,
quais são as probabilidades de prever o potencial de fazer mais em seis
semanas?
Certa vez trabalhei com uma equipe que deveria trabalhar em Sprints de
quatro semanas, por causa da política da empresa que era a de seguir o
que estava no livro original do Scrum e o que os coaches estavam dizendo
49
há uma década. Entretanto, a equipe queria estabelecer um prazo mais

curto e fazer as coisas por si mesmos. Enquanto trabalhavam em Sprints
de quatro semanas, no que dizia respeito a todos os outros, estabeleceram
uma abordagem de planejamento que visava ter metas semanais para ter
software funcionando.
Como também foi mencionado no Capítulo 4, havia uma equipe que
trabalhava para dividir a funcionalidade em partes que podiam ser
concluídas a cada dois ou três dias. E embora a tarefa que se comprometeram
não fossem de baixo esforço, nenhuma das equipes falhou em cumprir os
objetivos da Sprint. Na verdade, eles pareciam achar mais fácil fazer mais
definindo pequenas quantidades de trabalho.
Outra vantagem das iterações mais curtas, mas que também são um
desafio, é a oportunidade de feedback mais frequente dos clientes com
relação ao que a equipe fez nas últimas semanas. O problema é que os
clientes (e as partes internas interessadas) provavelmente não estão
acostumados a demandas tão frequentes para interagir com a equipe.
Falaremos mais sobre isso no próximo capítulo.
50
CAPÍTULO 10
Trabalho colaborativo
“Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto

por todo o projeto”
Pessoas de negócios e
desenvolvedores
O termo “pessoas de negócio”, pode incluir pessoas que estão interessadas
no projeto, como cliente, usuário final, product owner, gerente de
projetos, gerente de produtos, executivos, analistas de negócios ou
especialistas no assunto. Às vezes chamamos genericamente de “cliente”.
É alguém que deseja criar uma certa quantidade de funcionalidades
e que comunica as ideias para aqueles que criarão essa funcionalidade.
Essas pessoas possuem a visão e o roadmap do projeto, criam e reúnem
requisitos, ajudam a gerenciar o backlog de requisitos, fornecem critérios
de aceitação, elaboram detalhes dos requisitos e fornecem feedback sobre
o trabalho realizado pela equipe de desenvolvimento.
As equipes ágeis mais antigas consistiam principalmente, quando não
completamente, de desenvolvedores de software que faziam o design,
escreviam o código, testavam e documentavam os resultados. Portanto,
o termo “desenvolvedor” passou a representar qualquer pessoa em
uma equipe que contribua com esforço real para algum aspecto da
funcionalidade da entrega. O Guia Scrum costumava dizer que o único
título em uma equipe de desenvolvimento era “desenvolvedor” para
enfatizar a prevenção de comportamentos isolados na equipe. A versão
mais recente diz: “O Scrum não reconhece títulos para os membros da
equipe de desenvolvimento, independentemente do trabalho que estão
realizando”.
Seria de se esperar que os membros da equipe tivessem títulos como:
desenvolvedor, analista de negócios, analista de qualidade ou testers,
escritor técnico ou especialista em documentação, designer de
experiência do usuário ou analista de banco de dados. Essas pessoas
têm a responsabilidade de estimar as histórias do usuário, ajudar no
refinamento da história (o que alguns chamam de “grooming de backlog”),
participar do planejamento da iteração, confirmar e cumprir as metas
da iteração, revisar e demonstrar as realizações de cada iteração com o
cliente e executar a melhoria contínua..
52
TRABALHO COLABORATIVO
Trabalhar diariamente em conjunto

Se o esforço ágil significa focar no “software funcionando mais
que documentação abrangente”, a expectativa é que muito do que é
representado na documentação de requisitos tradicional seja comunicado
verbalmente e atendido logo em seguida. Se uma equipe estiver
trabalhando em iterações de uma a quatro semanas, não há muito tempo
para esperar pelas respostas às dúvidas.
No melhor cenário, as respostas podem chegar, digamos, em menos de 24
horas. Qualquer atraso maior pode significar que a funcionalidade não
possa ser executada durante a iteração ou, pior, as equipes supõem o que
pode ser pretendido ou necessário e gastam tempo desenvolvendo a coisa
errada.
Os clientes podem não ter experimentado, antecipado ou se preparado
para esse nível de comprometimento com as equipes. Nesse caso, pode ser
necessário existir algum intermediário, por exemplo, o papel de product
owner do Scrum (ou PO). Essa pessoa deve saber o suficiente sobre o que se
deseja fornecer e obter respostas rapidamente, com base no entendimento
da funcionalidade desejada, conforme expresso nas histórias.
Às vezes, essa função é preenchida por mais de uma pessoa de acordo
com a demanda, entretanto, a equipe deve ouvir apenas uma “voz”. Será
um impedimento para a eficácia da equipe se tiverem que esclarecer
as opiniões de muitas pessoas para compreender o que é desejado. O
trabalho do intermediário é fornecer essa única voz.
Equipes proativas e POs incluem planos para comunicação regular
durante as iterações, se a comunicação diária ad hoc for um problema.
Observei equipes e POs se encontrarem semanalmente para revisar
o trabalho atual e futuro para evitar tempo de comunicação real. A
necessidade de comunicação ad hoc certamente ocorrerá, mas se o PO
está longe da equipe por tempo e distância substanciais, será necessária
uma comunicação mais formalmente planejada. O objetivo, no entanto, é
evitar simplesmente voltar a enviar a comunicação baseada em texto para
tudo, porque a conversa cara-a-cara é muito difícil.
53
Por todo o projeto

Embora fortemente associado à comunicação diária, envolver o cliente
durante todo o andamento do desenvolvimento pode ser um desafio para
muitas empresas. O diagrama a seguir sugere que um cliente ou gerente
de projetos pode esperar um compromisso de atenção em vários projetos
cascata sobrepostos. Essas pessoas passam bastante tempo durante a
definição e o esclarecimento dos requisitos, depois desaparecem durante
a implementação e desenvolvimento e, finalmente, retornam ao final do
projeto para revisar os resultados.
Figura 2: Expectativa de atenção dos clientes, com base na

experiência em cascata
As pessoas provavelmente reconhecem o perigo inerente a períodos tão
longos com pouca ou nenhuma comunicação. No entanto, a abordagem
tradicional em cascata pressupõe um comportamento como o exemplo
anterior, confiando na adequação da documentação totalmente definida
para servir como a principal abordagem de comunicação.
54
CAPÍTULO 11
Indivíduos motivados
“Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o

suporte necessário e confie neles para fazer o trabalho.”
Antes de entrarmos nos elementos desse princípio, é preciso dizer como
ouço as pessoas reagindo a ele. Por diversas vezes já palestrei e treinei
pessoas sobre valores e princípios. Quando conversei sobre esse assunto,
ouvi diversas vezes, comentários como “Se pudéssemos fazer tudo isso, as
coisas seriam ótimas”. Pergunto a eles porque, sob uma perspectiva ágil,
não podem ou simplesmente não fazem. Fazer essas coisas acontecerem
é um objetivo importante na melhoria contínua, especialmente para a
gerência.
Pessoas motivadas
A ideia aqui não é falar sobre como motivar as pessoas”, você provavelmente
já ouviu frases assim. Eu mesmo dei palestras como essas e quando me
pediram para fazer essa palestra certa vez em uma empresa, ouvi o melhor
comentário sobre esse tipo de abordagem.
Normalmente me sentava ao lado de um vice-presidente de
desenvolvimento de software, um dia depois de receber a solicitação para
fazer uma palestra como essa, e costumava ouvir algo como: “Scott, não
precisamos de palestras para motivar as pessoas. Precisamos descobrir
como parar de desmotivá-los. As pessoas não vêm trabalhar desmotivadas.
Contudo, o que fazemos após eles chegarem para trabalhar é fazê-los
acreditar que precisamos, de alguma forma, motivá-los.” Ele estava certo,
e embora ainda tenha feito a apresentação, ela se transformou mais em
um workshop sobre como evitar comportamentos desmotivacionais.
W. Edwards Deming, no livro Out of the Crisis escrito em 1986, comentou
que uma das partes de um dos 14 Pontos de Gerenciamento da Qualidade
Total, era “[...] remover as barreiras que roubam o orgulho do trabalho
das pessoas...” Caso não esteja familiarizado com o trabalho desse autor,
é necessário analisá-lo e entender o seu impacto na qualidade e na
produtividade. Os japoneses fizeram e respeitaram o que Deming lhes
ensinou e em 1951, o Japão nomeou seu prêmio nacional de qualidade em
homenagem a ele, o Prêmio Deming.
56
INDIVÍDUOS MOTIVADOS
O ambiente e o suporte
Se for solicitado às equipes que forneçam resultados de alta qualidade
aos clientes, às equipes devem receber tudo o que for necessário e todas
as oportunidades possíveis para fazer isso, simples assim. Entretanto,
costumava ouvir: “Mas você não conhece a nossa realidade”.
Tornar-se ágil significa mudar essa realidade, não apenas tentar introduzir
um monte de novas práticas que são quadradas, em uma abordagem
organizacional que é “redonda”. Essa é a razão pela qual acredito que uma
análise crítica sobre o que têm a dizer os valores e princípios ágeis é tão
importante para a empresa que está contemplando uma transformação
para ser (e fazer) ágil. Parte dessa análise já é uma transformação, não
apenas uma transição. Não se trata de uma simples introdução de novos
títulos e cerimônias, é uma mudança no ambiente e no sistema em que as
pessoas trabalham.
Às vezes, quando as pessoas pensam na expressão “ambiente”, imaginam
essas questões na estrutura física, mudando o espaço para locais de
trabalho sem paredes e mobília totalmente móvel. Existem várias críticas
a essas estruturas, já observei situações que funcionaram de forma
fantástica e outras que não tiveram tanto sucesso. Mas também observei
este tipo de organização em estruturas mais comuns de escritórios em
cubo. A ideia do espaço aberto era derrubar barreiras tornando a interação
e as comunicações mais frequentes, premissa básica nas equipes ágeis.
Nem todos se sentem confortáveis trabalhando em espaços abertos, mas
existem equipes que trabalham muito bem dessa forma. Se a motivação
para se comunicar, colaborar, melhorar, confiar e buscar a excelência
existe, as pessoas podem trabalhar em espaços físicos variáveis.
Confiar na equipe
Dentro dos princípios da agilidade, confiar na equipe talvez seja a
coisa mais difícil de se conseguir. Muito da estrutura e do processo
organizacional, como observado no Capítulo 2, parece existir porque a
confiança não está presente.
Antes de me envolver com métodos ágeis, trabalhei em um local onde
a visão de qualidade do presidente da empresa era a seguinte: “Algumas
57
pessoas simplesmente não fazem o trabalho corretamente. Se pudéssemos

encontrá-las e mandá-las embora, a empresa estaria melhor”.
Sua opinião era de que a baixa qualidade era motivada pelo fracasso
moral individual em desempenhar adequadamente uma atividade. Ele
transformou o que Deming décadas antes tratou como um objetivo:
Sistemas de engenharia são objetos de questões morais, subjetivas e
pessoais.
Muitos anos antes, palestrei sobre qualidade e processo no programa
de engenharia de software de uma universidade local. Perguntaram-me,
quão barato seria contratar as pessoas se o processo fosse suficientemente
rigoroso.
Ou seja, o objetivo não era confiar ou esperar muitas competências das
pessoas e sim o quão inexperiente e barata uma equipe poderia ser para
que o processo pudesse prosseguir?
A maneira como muitos processos organizacionais crescem ao longo
dos anos geralmente se deve a pensamentos semelhantes. Quando algo
dá errado em um projeto, muitas vezes se decide por impedir que o fato
aconteça novamente, criando-se regras e procedimentos de supervisão
mais rigorosos. Pouco a pouco, a burocracia do processo vai aumentando
até que se gaste mais tempo aderindo ao processo com suas regras e
procedimentos, do que desenvolvendo o produto.
Kent Beck disse (parafraseando um pouco) que o desenvolvimento de
software é como “dirigir um carro, não apontar uma bala para o alvo”.
As leis de trânsito e a sinalização existem como uma estrutura na qual
esperamos que a maioria das pessoas possa dirigir com segurança.
Esperamos que as pessoas adotem uma abordagem de constante análise
e adaptação, pois as coisas podem acontecer inesperadamente exigindo
uma resposta imediata ao invés de seguir conforme o planejado. Por outro
lado, ao dispararmos uma bala, perdemos o controle sobre ela após puxar
o gatilho, por isso, é necessário muito planejamento antecipado.
Agora, poderíamos tentar restringir os erros das pessoas construindo os
carros e as estradas, como no kart, onde temos um único percurso, com
para-choques grossos ao redor do carro e barreiras que canalizam o único
caminho que podemos seguir. Alguns processos organizacionais parecem
muito com isso. Acredito que os métodos devem ser projetados para
pessoas que sabem dirigir e não para aqueles que não sabem. Deming disse
que, na maioria dos casos, era o sistema onde as pessoas trabalham que
58
INDIVÍDUOS MOTIVADOS
precisava ser reformado, não as pessoas. Obviamente, algumas pessoas

precisam mudar a forma como trabalham, e Deming abordou-as dizendo
que precisavam de treinamento para terem um desempenho melhor.
Muito se pode dizer sobre confiança. Mas observe os processos existentes
(faça um mapa do fluxo de valor como mencionado no Capítulo 7) e
pergunte-se qual seria o impacto se as equipes pudessem se autogerenciar
ou gerenciar-se entre si. Talvez tudo isso seja uma questão de confiança,
se você achar isso impossível.
59
CAPÍTULO 12
Conversa face a face
CONVERSA FACE A FACE
“O método mais eficiente e eficaz de transmitir informações para e entre uma

equipe de desenvolvimento é através de conversa face a face.”
Este capítulo aborda os meios de comunicação comentando os problemas
das equipes distribuídas, as reuniões diárias e as revisões de iteração como
exemplos de “conversas” que podem acontecer.
Meios de comunicação
Esse diagrama foi mostrado no capítulo 3, mas vamos falar mais sobre
ele. Alistair Cockburn estudou as equipes e criou esse espectro dos meios
de comunicação e mostrou o que considerava ser a eficácia comparativa.
Existem outras versões do diagrama, que rotulam as duas linhas como
“interativas” e “não-interativas”. Claramente, os modelos com “perguntas
e respostas” são mostrados como tendo maior eficácia e riqueza de
comunicação.
2 people
at whiteboard
COMMUNICATION EFFECTIVENESS
2 people
on phone
ER
S
W
AN
D
Videotape AN
N
TIO
ES
QU
2 people
on email
ER
Audiotape SW
- AN
Paper ION
UEST
NO Q
(cold) RICHNESS (”TEMPERATURE”) OF COMMUNICATION CHANNEL (hot)
Figura 3: Comparação dos meios de comunicação por efetividade.

Talvez a maioria das pessoas possa concordar com a intenção deste
diagrama, mas algumas irão dizer: “Legal, mas temos equipes distribuídas”.
Iremos conversar sobre isso, mas antes é interessante salientar que na
pesquisa anual do VersionOne, em sua décima segunda edição, cerca de
40% dos entrevistados consideraram que, ao invés de prejudicar, a adoção
de uma abordagem ágil melhorou a experiência da equipe distribuída. E
61
apenas 17% dessas pessoas consideraram inicialmente que a busca ao ágil

ajudaria nesse sentido.
Vejamos alguns dos meios e o que representam. É interessante que as
formas textuais de documentos sejam o mais baixo nessa escala, mas é
o modo tradicional e a abordagem mais utilizada para a comunicação e
para o arquivamento de informação. Os projetos gastam muito tempo
e dinheiro gerando especificações de requisitos, projetos de arquitetura
e projetos detalhados de baixo nível antes de implementar qualquer
coisa. Cada uma delas geralmente envolve muitas pessoas para coletar as
informações e posteriormente revisá-las e aprová-las, acreditando que a
diligência é a maneira necessária e responsável de planejar e executar um
projeto.
Obviamente, uma suposição importante neste caso é que as pessoas
conseguem pensar em tudo antecipadamente e não irão mudar de ideia
mais tarde. Essa é a filosofia clássica do modelo cascata ou do modelo
sequencial em fases, consagrada no gerenciamento de projetos tradicional.
A abordagem ágil acredita que isso não é verdade e que não é muito
inteligente esperar que as pessoas sejam capazes de fazer isso. E isso de
forma alguma caracteriza uma falha moral ou profissional.
Um modelo de ciclo de vida que ilustra e combina essa abordagem com
a verificação e validação esperada em cada fase é chamado de modelo V,
que pode ser encontrado nas discussões no StackExchange. Cada fase da
especificação do sistema é combinada com uma abordagem de testes que
indica o foco dos testes realizados para concluir o sistema nesse nível.
No outro extremo do diagrama, estão “duas pessoas no quadro branco”,
representando a interação cara a cara em tempo real, altamente valorizada
por ser ágil.
As pessoas se veem, o que aumenta drasticamente a riqueza de
informações transmitidas, já que o que vemos é mais fixado do que
aquilo que ouvimos (incluindo poder desenhar no quadro branco e fazer
mudanças rapidamente). Quando estamos na frente do quadro com as
demais pessoas podemos perceber se alguém tem uma pergunta ou se algo
não está explícito o suficiente. Também evitamos a maioria dos conflitos
ao explicar o que estamos tentando mostrar, o que provavelmente seria
melhor do que tentar conduzir essa discussão nas seguintes situções:
62
Requirements Acceptance Acceptance

Analysis Test Design Testing
System System System

Design Test Design Testing
Architecture Integration Integration

Module Unit Unit

Coding
Figura 4: Fluxo de trabalho

• Quando não podemos ver o interlocutor;
• Quando esquecemos que estamos com o microfone mudo e então
precisamos explicar tudo novamente;
• Quando fazemos outras coisas enquanto deveríamos estar ouvindo e
então perguntamos o que acabaram de dizer;
• Quando tentamos falar ao mesmo tempo, ficamos em silêncio,
tentamos ser educados solicitando ao interlocutor que comece sua
fala e então aguardamos em silêncio até que alguém finalmente diga
algo.
O e-mail, deveria ser igual a qualquer outra forma de mensagem de
texto, e poderia ser o último meio para perguntas e respostas. Embora
seja interativo, esse formato não garante uma conversa em tempo
real e também possui seus problemas peculiares. Algumas pessoas
gostam de discussões via e-mail para serem utilizadas como modelo de
documentação, normalmente porque garante que todos leram o que foi
dito, sugerindo maior segurança. Outras preferem este meio porque não
precisam lidar diretamente com outras pessoas, temos um exemplo logo
abaixo que chamamos de “baias de trabalho”.
63
Quanto aos meios pelos quais não envolvem perguntas e respostas,

gostaria de descrever o exemplo de uma fita de vídeo usada em um
local onde trabalhei. Em vez de ter alguém fazendo anotações durante a
discussão de design, apontando características para alteração e aprovação
para então, enviar o documento aos clientes para revisão, nós filmamos a
sessão. Isso faz bastante tempo. Certamente existem opções melhores do
que videocassetes nos dias de hoje. Copiamos a fita e enviamos uma para
cada stakeholder do projeto.
Eles assistiam a fita e posteriormente enviavam os feedbacks de volta para
nós, dessa forma poderíamos incorporar as ideias na documentação de
design, já que ainda era necessária. O importante era que os stakeholders
pudessem ouvir tudo, não apenas aquilo que imaginamos ser importante
estar na documentação.
Isso incluía momentos divertidos, nos quais os stakeholders nunca
teriam ouvido se tivéssemos enviado nossa versão escrita daquilo que
deveriam saber. Isso levou a mudanças que só poderiam ser observadas
meses depois, quando muito trabalho já teria sido feito e os stakeholders
estivessem vendo o software implementado.
É preciso decidir quais e quando os modos funcionam para cada situação,
mas precisamos sempre nos perguntar se seria possível estarmos cada vez
mais na parte superior à direita do diagrama de Cockburn.
Equipes distribuídas
Este princípio não fala sobre onde as pessoas devem estar, apenas mostra
onde a comunicação mais eficaz ocorre. Se precisar conversar com
pessoas que não estão presentes no mesmo local, é mais interessante usar
algum tipo de vídeo chamada. Hoje em dia, não custa muito adicionar uma
câmera USB caso as pessoas não tenham um computador com webcam.
Tive uma experiência trabalhando com equipes que passaram meses sem
ao menos conhecer o rosto das pessoas com quem trabalharam. Minha
primeira sugestão foi que todos tirassem ao menos uma foto. Quando
essas equipes começaram a fazer vídeo chamadas, as mudanças nas
discussões se tornaram claras e observáveis. As pessoas perceberam que
estava tudo bem em se conectar, reconhecendo os olhares intrigados ou
preocupados. A atenção das pessoas, ou a falta dela, durante a reunião
podem ser notadas e elas podem ser convidadas a voltar sua atenção
64
na discussão. Assimilar o rosto com as vozes conversando por telefone

ajudou a elevar o espírito de equipe, e da confiança como um todo.
O principal imperativo é nunca deixar ninguém no escuro, ou seja,
garantir que todos se sintam incluídos na equipe e que tenham a chance
de contribuir. Não voltamos a utilizar os itens que estão à esquerda do
diagrama de Cockburn, o que é mais fácil de se fazer. Isso significa que
podemos ter insumos e feedbacks usando abordagens baseadas em texto,
mas sempre com moderação.
Uma equipe com sede nos EUA com a qual trabalhei nunca tinha tido
membros distribuídos até que um dia dois membros na Índia foram
incluídos na equipe. A equipe americana realizava reuniões diárias às 8h
no horário local, e não podiam adiantá-la devido a questões de cuidados
em relação aos filhos dos funcionários. Fora do horário de verão, seria
por volta das 19h30 na Índia. A maioria das empresas indianas que
trabalham com empresas norte-americanas, muda o horário de trabalho,
das 10h às 19h, então ficar um pouquinho mais até às 19h30 não era algo
problemático para os dois membros na Índia. As revisões de Sprint eram
realizadas às 8h e costumavam durar até às 20h30 na Índia, mas isso
acontecia somente uma vez a cada quatro semanas, o que era razoável.
Como as retrospectivas eram feitas após a revisão das sprints depois de
meia hora de pausa, que começava às 21h na Índia, o pessoal sediado nos
Estados Unidos e o Scrum Master, concordaram que os membros indianos
não precisavam ficar conectados, pois normalmente a retrospectiva
acabaria por volta das 22h na Índia.
Quando soube disso orientei o Scrum Master e os membros da equipe
local para que não continuassem deste modo. Mesmo acostumados a
trabalhar comigo, receberam a declaração com estranheza. Quando me
perguntaram o motivo, expliquei que não poderiam excluir os membros
da Índia do processo da retrospectiva. Eles deveriam pelo menos receber
a opinião dessas duas pessoas antes da reunião, caso elas não pudessem
estar na retrospectiva.
Às vezes, sendo coach, tenho sorte, pois foi exatamente o que aconteceu
na retrospectiva seguinte. Um e-mail dos indianos foi enviado para os
membros nos EUA e as ideias foram incluídas nos tópicos da reunião. No
final da retrospectiva, o item de melhoria de maior prioridade selecionado
foi devido aos insumos enviados pelos indianos. Os membros dos EUA
reconheceram que não teriam pensado nisso sozinhos, mas durante as
discussões concordaram que realmente precisavam trabalhar nesse item.
65
Gerenciando equipes distribuídas

Para motivar conversas cara a cara no mesmo ambiente, uma empresa
adotou a seguinte regra: Depois de enviar e receber três vezes o mesmo
e-mail ou mensagens de texto, as pessoas tinham que se levantar e ir
conversar com o destinatário. Caso a distância fosse um impedimento, as
pessoas deveriam ligar ou usar alguma tecnologia baseada em vídeo para
fazer o contato em tempo real. Se o fuso-horário fosse muito diferente,
as pessoas deveriam agendar um horário em que a comunicação por
vídeo pudesse acontecer. A ideia era se esforçar para simular um contato
próximo, em vez de recorrer somente à comunicação puramente textual.
Gostaria de mencionar um grande exemplo de equipe distribuída que
testemunhei mais de uma vez. Estive em ambientes de “baias”, onde as
pessoas sentavam-se em fileiras em cubículos isolados.
Ao se levantar era possível ver as repartições, porém quando as pessoas
estavam sentadas, parecia que as demais não existiam. Nestes ambientes,
via pessoas enviando e-mails e mensagens de texto ao invés de levantar-se
e ir até uma baia próxima. Não havia nem 30 metros entre elas, às vezes
nem 30 centímetros.
Outra consideração deste processo é nunca deixar as pessoas no escuro,
ou seja, garantir que todos os membros da equipe distribuída saibam o
que está acontecendo assim como aconteceria em uma reunião presencial.
Certa vez trabalhei com uma equipe onde:
• O PO estava sozinho na Dinamarca;
• Um desenvolvedor estava sozinho na costa leste dos EUA;
• Um desenvolvedor e um tester estavam juntos na costa oeste;
• Alguns desenvolvedores e testers estavam juntos na Índia;
• O Scrum Master estava sozinho em Cingapura.
Foi a equipe mais distribuída com a qual já trabalhei, ainda sim, foi uma
das mais eficazes e que estavam satisfeitas com seu formato distribuído.
O Scrum Master e eu (como coach) fazíamos duas reuniões por dia: Uma
pela manhã e outra à noite, ambas no fuso horário do Pacífico.
No final de cada reunião, o Scrum Master enviava um breve conjunto
de anotações sobre os tópicos discutidos em cada sessão para todos os
membros da equipe. Em seguida, de forma proativa, os membros da equipe
entravam em contato quando precisavam de informações mais detalhadas.
Não era o ideal, mas funcionou porque todos se comprometeram a tentar
66
se comunicar de maneira eficaz, em vez de cair na ideia de criar e enviar

documentos formais.
No meu ponto de vista, as pessoas deveriam minimamente se ver sempre
que se comunicam à distância. O uso do vídeo chamadas melhora
drasticamente o relacionamento entre as pessoas de uma equipe. Ver um
ao outro coloca um rosto e uma pessoa real na voz das pessoas, ao invés de
uma voz sem corpo e sem rosto quando fazemos uma ligação telefônica.
Isso aumenta a nossa sensação de termos uma equipe real, que melhora
a colaboração e a confiança entre todos os membros. Hoje, não há razão
para não termos um vídeo chamada nas reuniões.
Reuniões diárias
Existe muito material sobre o objetivo da reunião diária e o que ela não se
propõe a fazer, ou seja, o objetivo não é ser uma sessão de status reporting
e nem de solução de problemas. Pessoalmente, vejo como a oportunidade
de a equipe garantir que todos saibam o que está acontecendo dentro
da equipe e que ao ouvirmos possamos decidir se há a necessidade de
fazer alterações no planejamento da Sprint. No final da reunião, seria
interessante que todos os membros se sentissem confortáveis com o
plano até o final da iteração. Os tipos de informações que a equipe pode
coletar nestas reuniões são:
• O que cada pessoa fez desde a última reunião, o que planejam para o
dia e tudo que estiver impedindo os trabalhos (três itens clássicos e
recomendados para essa reunião);
• O estado do progresso da equipe usando alguma avaliação quantitativa
(por exemplo, um gráfico de burndown);
• Contribuições que podem solicitar de pessoas de fora da equipe,
estando ou não presentes na reunião.
Por fim, levantamos a questão de quem participa da reunião diária.
Normalmente é específica para a equipe de desenvolvimento, em conjunto
com o Scrum Master ou facilitador ajudando e principalmente mantendo
um “conjunto” de itens a ser discutido depois de atingir o limite de 15
minutos da reunião diária. As reuniões não são secretas, portanto, o PO e
demais pessoas de outras equipes que estejam presentes e até a gerência
podem participar.
67
Contudo, todos que não fazem parte da equipe de desenvolvimento,

deveriam permanecer em silêncio, a não ser que as respectivas opiniões
sejam solicitadas é claro. Se realmente for necessário abordar a equipe
com uma demanda, é necessário entrar em contato com o Scrum Master
com antecedência, que irá com a equipe decidir se tal solicitação deve
ser atendida na reunião ou posteriormente a ela. Caso decidam dizer
algo durante a reunião, é necessário perguntar se haverá tempo para os
comentários no final.
Após a reunião, o Scrum Master ou facilitador pode apontar para os itens
a serem discutidos, se houver alguma nota ou adendo, e a equipe decidir
quem deve estar presente e como resolver os problemas levantados. Com
uma equipe distribuída, o convite para a chamada pode indicar uma
reunião de 30 a 60 minutos, sendo os 15 primeiros reservados para a
reunião diária. O restante do tempo visa permitir outra discussão quando
e se necessário, contudo, isso não deve ser uma indicação de que a reunião
diária irá levar todo esse tempo.
Conheço uma empresa com cerca de 50 pessoas em que todos os
funcionários participam da reunião diária. Eles trabalham em pares,
portanto é como se fossem 25 pessoas falando. Completam a reunião
diária dentro desse prazo de 15 minutos. As pessoas cobrem as três
declarações principais em 15 a 20 segundos cada uma, em média,
facilitando a conclusão de 25 pessoas em 15 minutos.
Revisões de iteração
Esta reunião é realizada no último dia da iteração, nela a equipe de
desenvolvimento mostra a todos os stakeholders o que realizaram
durante a iteração. É uma oportunidade para os stakeholders ouvirem da
equipe e darem feedback para os desenvolvedores. A equipe pode ouvir
diretamente dos stakeholders como se sentem em relação ao trabalho
apresentado. Qualquer alteração necessária pode ser identificada e
colocada no backlog do produto para iterações futuras. No entanto,
há algumas coisas que sugiro que as pessoas tenham em mente sobre a
reunião.
Geralmente, os membros da equipe demonstram seu trabalho, mas pode
haver ocasiões em que seja apropriado que o PO apresente, supondo que
tenha um contato direto e contínuo com a equipe e saiba como demonstrar.
68
Isso pode acontecer devido a diferenças de idioma entre membros da

equipe e os stakeholders ou porque o PO sabe explicar melhor utilizando
as expressões corretas. Caso esta premissa seja verdadeira sugiro,
como sendo um item de melhoria, a equipe aprender como envolver os
stakeholders em seu nível de trabalho, para que nenhum intermediário
seja necessário nas reuniões seguintes.
A reunião não é para pessoas internas, como gerentes da empresa,
participarem de debates na frente dos stakeholders ou pedirem, por terem
perdido algumas análises anteriores, que questões já discutidas sejam
apresentadas e explicadas novamente a elas. Vi as duas coisas acontecerem
diversas vezes. O PO, o Scrum Master ou o facilitador, precisa intervir e,
de forma educada, interromper esse tipo de coisa e resolver a questão fora
da reunião, em um fórum público, quando o tema não for a revisão da
iteração.
Às vezes, especialmente quando as pessoas estão conectadas por vídeo
chamadas durante a revisão, a resposta dos stakeholders no final de uma
demonstração específica de funcionalidade ou ao final da revisão pode ser
pouco mais do que um “bom trabalho”. Se não for, talvez seja um silêncio
matador. O que não é um feedback interessante para a equipe. O PO,
que supostamente conhece os stakeholders, deve tentar incentivar um
feedback mais substancial.
O PO pode pedir a certos stakeholders que comentem sobre o que é de
maior interesse para eles, colocando-os educadamente em destaque, para
que digam algo. A discussão na revisão é importante. Não deve ser uma
sessão unidirecional, apenas para a equipe mostrar e falar sobre o trabalho
que fizeram.
69
CAPÍTULO 13
Software em
funcionamento… Outra vez?
SOFTWARE EM FUNCIONAMENTO… OUTRA VEZ?
“Software funcionando é a medida primária de progresso.”

Um momento… software em funcionamento não é um dos valores do
Manifesto Ágil? Sim.
Então estão repetindo. Sim, estão.
Perguntei a um dos autores do Manifesto sobre isso e o primeiro
comentário foi: “Enfim, concluímos que era importante o bastante para
repeti-lo.”
É claro que não era exatamente uma repetição. Os valores declaram
somente a preferência de ter o software em funcionamento mais que
uma documentação abrangente. Este princípio declara que software em
funcionamento é a principal métrica de progresso.
Medindo o Progresso
O progresso em projetos tradicionais é medido em tarefas resolvidas do
plano de projeto e quão perto esta medida está da esperada finalização,
por exemplo, o número de tarefas concluídas e se foram finalizadas
na estimativa de tempo original. Em um projeto cascata, um número
substancial de tarefas serão cumpridas antes de ter qualquer software
em funcionamento, antes mesmo de uma funcionalidade ser desenhada,
codificada, revista, testada e documentada. Além disso, um cronograma
de projeto pode estar de dois terços a três quartos completo, com todas as
tarefas associadas, antes de qualquer software ser verificado e validado.
Uma abordagem de acompanhamento tradicional que relaciona tarefas
concluídas ao valor de projeto é a análise de valor agregado. De forma
simples, alguém atribui um valor em dólar para tarefas baseadas em horas
estimadas e um custo estimado para essas horas. Algo como decidir o
custo por hora paga a uma pessoa que executa tais tarefas multiplicado
pela quantidade de horas daquela tarefa. Ou algo como pegar o custo
total estimado do projeto, já calculado, e dividi-lo igualmente por todas
as tarefas com base no percentual de horas que cada uma representa no
projeto. Em todo caso, temos um valor para cada tarefa realizada. Assim
que uma tarefa é concluída, o valor é agregado ao projeto.
Porém isso não é, e não deveria ser sugerido, como valor entregue ao
cliente. Isso apenas significa que, dado que toda tarefa seja necessária, às
71
tarefas e horas gastas podem ser usadas para acompanhar a porcentagem

de conclusão do projeto. Consequentemente, é uma medida de progresso,
uma vez que mostra quanto do projeto foi completo em um determinado
momento. Podemos verificar na Wikipédia, há uma variedade de números
que podem ser calculados e usados para comparar o progresso planejado
e o realizado. A abordagem ágil simplesmente atesta que o progresso deve
ser medido somente enquanto software em funcionamento existe em um
determinado momento. Alguém pode usar story points como base, por
exemplo, ao invés de horas ou dólares. Conforme a equipe completa os
requisitos, o valor é expresso em pontos completos que podemos usar
para comparar com o total de pontos de todo o projeto ou da entrega, e
calcular o percentual de conclusão.
Gráfico Burn-up
Uma forma de acompanhamento visual comum para isso é o diagrama de
burn-up. Abaixo, um exemplo simples.
35
30 Story points Done
25
20
15
10
0
day day day day day day day day day day
1 2 3 4 5 6 7 8 9 10
Figura 5: Burn-up
O eixo vertical representa story points enquanto o horizontal tempo, nesse
caso dias da iteração. A linha verde é um ideal ou linha base partindo de
zero story points no início da iteração ao total de pontos planejado para
a iteração, 35 pontos nesse exemplo. A linha azul acompanha o número
atual de pontos completados acumulados dia a dia na iteração.
72
SOFTWARE EM FUNCIONAMENTO… OUTRA VEZ?
A partir disso, a equipe e o product owner, e qualquer outra pessoa que

interessar, podem ver o progresso da equipe através da conclusão de
todas as user stories planejadas para a iteração. Estar abaixo da linha ideal
(verde) significa que a equipe está atrasada na conclusão das histórias.
Estar acima da linha ideal significa que a equipe está adiantada. O gráfico
não explica por que uma equipe está atrasada ou adiantada.
De uma perspectiva de PO no longo prazo, o gráfico poderia mostrar o
total de pontos de um projeto ou lançamento com o tempo sendo marcado
em iterações no projeto/lançamento mais do que dias em uma única
iteração. Ambas as formas podem ser usadas. Se uma equipe tem histórias
relativamente pequenas e que completam regularmente, um gráfico de
iterações diárias resulta em um gráfico visualmente fluído. Se a equipe tem
grandes histórias e que levam muitos dias para serem concluídas, teremos
um gráfico mais escalonado, o que significa que o gráfico fica estático por
dias seguidos até que as histórias sejam concluídas e, em seguida, salta
à medida que os story points dessas histórias são registrados. A versão
completa do projeto/lançamento produzirá um gráfico escalonado, pois
os pontos são registrados apenas no final de cada iteração, mas será um
salto de aparência menor, pois o gráfico acompanha uma linha de base
geral com mais story points.
Um adendo é que simplesmente contar histórias completas comparadas
ao total de histórias da iteração ou entrega é uma outra abordagem
utilizada sem o uso de pontos. Essa ideia pode ser encontrada em:
• O Do You Need to Use Story Points to Track Velocity (Precisamos de
Story Points para acompanhar Velocidade? tradução livre) – artigo
da IBM.
• How estimating with story counts worked for us (Como estimar
em story counts funcionou para nós, tradução livre) - artigo da
ThoughtWorks.
• Story Counting - post do Martin Fowler.
• Stop Using Story Points (Pare de Usar Story Points, tradução livre) -
post do Joshua Kerievsky.
• How to Enable Estimate-Free Development (Como possibilitar
desenvolvimento sem estimativas, tradução livre) - post do Dave
Rooney
73
Definição de pronto
De forma breve, para afirmar que temos software em funcionamento,
é esperado que todos os critérios de qualidade estabelecidos sejam
cumpridos. Este conjunto de critérios é tipicamente chamado de
Definição de Pronto (Definition of Done). Se todos os critérios forem
cumpridos, todos da equipe concordarão que o requisito está concluído.
As equipes devem ter acordado esse conjunto de critérios (ao menos uma
versão inicial) antes de iniciar qualquer trabalho. Durante um projeto ou
lançamento, provavelmente a equipe ou alguns stakeholders vão querer
ajustar os critérios, no entanto, devemos revê-los formalmente como
parte da retrospectiva.
Exemplos de itens encontrados em definições de pronto devem focar em:
• Projetar tarefas a serem realizadas;
• Código necessário e padrões de código a serem usados;
• Testes unitários esperados;
• Revisões de pares ou outras a serem feitas;
• Documentação de usuário para criar e atualizar;
• Builds bem sucedidas e execução de testes;
• Critérios de aceitação dos clientes - muitas vezes chamados de
condições de satisfação;
• Expectativas de requisitos não funcionais, como performance e
segurança;
• Internacionalizações e preocupações de localização.
Esses critérios devem ser usados em qualquer requisito, apesar de alguns
não necessitarem de todos os pontos, e outros de critérios adicionais.
Atendendo aos critérios, o trabalho deve ser mostrado na próxima revisão
de iteração (review) para a aprovação dos clientes e das partes interessadas,
assim como os story points devem ser contados como concluídos. Essa
deve ser a medida de progresso, independentemente de outros possíveis
entregáveis que podem ter sido gerados para chegar nesse ponto.
74
CAPÍTULO 14
Desenvolvimento
Sustentável
“Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,

desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente.”
Desenvolvimento Sustentável
O desenvolvimento sustentável é uma abordagem que é conduzida sem
esgotar as pessoas com o tempo. O Ágil defende que se evite a realização
de horas extras por obrigação. Caso isso esteja ocorrendo, significa que
as pessoas não estão abordando o planejamento da maneira mais sensata.
Alguns podem dizer que isto está fora da realidade, pois não conhecem
a organização. Como citado no Capítulo 11, o modelo ágil não ignora a
realidade, mas tem a intenção de mudá-la.
Ter muitas horas extras na rotina para cumprimento do prazo não é um
bom sinal, isso não é uma peculiaridade da visão ágil. Em 1997 um dos
principais proponentes de metodologias de software clássicas apontou
quão comum era a então chamada “marcha da morte” dos projetos.
O Project Management Institute (PMI) também identifica que tais
abordagens não são desejáveis, citando um artigo que descreve diversos
sinais de problemas nos projetos relacionados à mentalidade da “marcha
da morte”.
De forma mais específica, um péssimo sinal é quando um projeto já
começa contando com horas extras para cumprir o prazo com todas as
funcionalidades esperadas. O que fazer quando o inesperado acontece
durante o projeto? De onde virá o tempo para lidar com isso? Incluindo
mais horas extras?
Tom DeMarco escreveu um livro interessante em 2001: Slack: Getting
Past Burnout, Busywork, and the Myth of Total Efficiency (Slack:
Superando o Burnout, a Falta de Tempo, e o Mito da Eficiência Total,
tradução livre), quando o movimento ágil estava apenas começando, onde
DeMarco discute carga e sobrecarga de tempo das pessoas e o que isso
significa para a eficácia, incluindo o impacto das multitarefas.
76
DESENVOLVIMENTO SUSTENTÁVEL
Ritmo constante indefinidamente

A ideia de ritmo constante (ou cadência) é o conceito de trabalhar em
um ritmo previsível em que as iterações ágeis e os vários elementos
oferecem, por exemplo, planejamento iterativo, reuniões diárias, revisões
e retrospectivas. Trabalhei com equipes que continuaram juntas, sem
muitas mudanças de pessoal, por quase uma década. Essas equipes têm
trabalhado muito bem após diversas iterações, sendo 13 iterações por
ano (considerando uma iteração de quatro semanas) e já tendo passado
por mais de 125 iterações. A habilidade dos membros da equipe de
trabalharem juntos, de forma regular e efetiva, é um ativo muito valioso
para a empresa. Por outro lado, dividir as pessoas deliberadamente e
alocá-las em outras iniciativas as trata como um recurso inanimado que
pode ser realocado sem nenhuma perda da essência do que aquele recurso
representa.
O desafio de uma organização é conseguir manter equipes trabalhando
juntas. É uma tarefa muito mais fácil em uma empresa orientada a produtos
do que em uma orientada a projetos. No final da maioria dos projetos,
as equipes podem se dividir rotineiramente à medida que as pessoas são
designadas para novos projetos. Em um ambiente produtivo, a equipe
foca no produto, release após release, construindo uma importante base
de conhecimento sobre o domínio ao mesmo tempo em que desenvolvem
as habilidades de trabalharem juntos. Presenciei alguns planejamentos de
equipes que tiveram somente algumas dezenas de palavras sendo trocadas,
além daquelas que ajudam a esclarecer a funcionalidade que devem criar
para a próxima sprint. Alguém pode dizer, “eu cuido disso” e a discussão
está finalizada. Essas equipes aprenderam que quando alguém diz algo,
essa pessoa vai realmente fazer o que disse, assim como sabem também
que quando precisarem de ajuda, os outros estarão lá. Nessas equipes é
altíssima a comunicação e a confiança. Apesar da quantidade de palavras
trocadas ser muito pequena, as ações falam muito mais. O que pode ser
mais desafiador é a habilidade dos patrocinadores e usuários de manterem
essa cadência, pois esse comprometimento de trabalho estável com uma
equipe de desenvolvimento geralmente não é algo que estão acostumados
a fazer, como vimos nos Capítulos 9 e 10.
77
CAPÍTULO 15
Excelência Técnica
EXCELÊNCIA TÉCNICA
Os primeiros oito princípios descrevem de várias formas como as

organizações podem ajudar a tornar o trabalho das equipes mais eficiente
e menos estressante. Os últimos quatro princípios, vistos de forma
isolada, falam sobre ações específicas para as equipes buscarem responder
de maneira ágil.
“Contínua atenção à excelência técnica e bom design aumenta a agilidade.”
Atenção Contínua
Parte da urgência que as equipes ágeis são encorajadas a buscar inclui
o foco na melhoria contínua. As equipes ágeis e indivíduos devem
sempre pensar sobre o que podem fazer para melhorar a forma com que
trabalham e isso pode ocorrer a qualquer momento durante a iteração.
A retrospectiva é apenas uma forma de incluir esse foco como uma
parte formal no ciclo ágil. A ideia da atenção contínua significa sempre
um olhar mais abrangente, ou seja, analisar o que está acontecendo na
equipe sempre considerando como as coisas podem ser melhoradas. Por
exemplo, ao fim de cada dia de trabalho, os membros da equipe podem
reservar cinco minutos para considerar o dia e perguntar a si mesmos
o que podem fazer amanhã para ajudar mais a equipe. Podemos esperar
esse tipo de pensamento do facilitador da equipe, do Scrum Master, ou do
Product Owner, mas é algo que qualquer colaborador pode fazer.
Excelência Técnica
Uma melhoria crítica a considerar é como aumentar as habilidades
técnicas dos membros da equipe. Em uma das equipes em que trabalhei,
decidimos que gostaríamos de melhorar o desenvolvimento orientado
a objetos e para isso, decidimos usar o livro Código Limpo do Robert
Martin. No entanto o livro possui 464 páginas (na versão em inglês),
ou seja, não iríamos conseguir ler tudo isso de uma só vez, portanto
decidimos que cada membro da equipe iria pegar um capítulo, e durante
a iteração, preparasse uma apresentação com a essência daquele capítulo
no momento da retrospectiva. A equipe poderia utilizar a ideia na prática
durante a iteração seguinte, enquanto a próxima pessoa abordaria o
capítulo seguinte. Levamos diversas Sprints para cobrir os 17 capítulos
do livro, mas sentimos que esse tempo era muito valioso.
79
As práticas com testes são outra área onde se tornar melhor leva a maior
agilidade. Conseguir testar com mais facilidade e mais frequência encoraja
maior cobertura dos testes e ajuda a garantir que novas mudanças não
causem bugs no funcionamento existente. (Lembrando as duas empresas
usadas como exemplo sobre testes frequentes no Capítulo 8.) Com as
atuais IDEs, há um considerável suporte para as equipes, que podem
reduzir as possibilidades de defeitos escaparem da iteração e causarem
problemas e retrabalhos no projeto ou na release.
Bom design
Um “bom” design pode significar coisas diferentes para pessoas diferentes.
Uma forma da equipe buscar isso e evitar discussões sobre o que seria o
significado de “bom” é desenvolver e adotar um conjunto de padrões de
código para a equipe. Uma característica do que “bom” pode significar é
ter um código fácil de ser mantido com o passar do tempo - ou seja, as
pessoas podem ir ao código e fazer mudanças sem dificuldades devido
à estrutura e à forma como as coisas estão nomeadas. Elas terão então
menos preocupações em fazer tais alterações. Uma outra característica
do que é “bom” pode ser dado através da aderência a certos princípios de
design de orientação a objetos, os princípios SOLID que o Martin comenta
no livro “Código Limpo”. Por exemplo, há o princípio da responsabilidade
única, citado na Wikipédia como: “uma classe deve ter apenas uma única
responsabilidade (mudanças em apenas uma parte da especificação do
software, devem ser capazes de afetar a especificação da classe)”. Antes
da orientação a objetos se popularizar costumávamos falar sobre isso
preocupados com a coesão, que pode ser alta quando todas as partes do
módulo estão relacionados a fazer uma única coisa. Um princípio SOLID
relacionado é a inversão de dependência, o que costumávamos chamar de
acoplamento. O acoplamento é baixo quando um módulo não depende de
outros para realizar o trabalho. Isso permitiu mudanças nos módulos sem
impactar outras partes do sistema.
Independentemente de quais são os padrões, ter a equipe toda concordando
e constantemente observando e analisando as melhorias que podem ser
feitas, é algo muito importante.
80
EXCELÊNCIA TÉCNICA
Aumenta a agilidade
A forma como tudo isso aumenta a agilidade é refletida em como tais
padrões e ideias melhoram a qualidade do produto e a facilidade com que
pode ser alterado com segurança. Quando não temos que nos preocupar
sobre quando as mudanças podem ser feitas com segurança, nos
tornamos mais propenso a fazer mais mudanças. Portanto, podemos agir
rapidamente enquanto mantemos um equilíbrio, ou seja, a estabilidade
do sistema.
81
CAPÍTULO 16
Simplicidade
SIMPLICIDADE
“Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é

essencial”
O princípio é bem direto. Todos os engenheiros que encontrei acreditam
nessa ideia. O objetivo é não enxergar tudo com o olhar da engenharia.
Ward Cunningham fala sobre o tempo que trabalhou com Kent Beck, em
um momento em que estavam estagnados, Ward perguntou: “Kent, qual a
coisa mais simples que poderia funcionar?” Ao invés de sentar e discutir
por horas, o conselho ágil é tentar fazer o código funcionar, por exemplo,
produzindo algum trecho de software e determinar se o resultado atende,
ou não, o objetivo esboçado.
Minha mãe me ensinou algumas ideias básicas sobre cozinhar quando
eu ainda era um pré-adolescente. A ideia chave era: “você sempre pode
adicionar mais um ingrediente, mas geralmente é difícil removê-lo”.
Determinar se a combinação de ingredientes é boa, adicionando um a um,
permite testar a mistura até certo nível. Porém, se formos longe demais
adicionando vários ingredientes sem testar, podemos acabar jogando
tudo fora ou ainda tendo que adicionar mais ingredientes para balancear
o excesso de outro, produzindo mais do que o planejado, o que seria um
desperdício.
Uma abordagem incremental em um design mais complexo tornará mais
fácil de verificar se o ponto atual está funcionando, permitindo também
manter o estado estável anterior mais facilmente, além de evitar o efeito
“banhado a ouro”, em outras palavras, a tendência de adicionar mais do
que é necessário ou pedido.
Fazer as coisas sempre de forma simples não é uma regra. Podemos nos
perguntar se ainda não temos certeza do que temos que fazer, como disse
Cunningham em uma nota de rodapé, mas pensar em termos simples
sempre que possível é essencial na prática de um bom design.
83
CAPÍTULO 17
Equipes auto-organizadas
EQUIPES AUTO-ORGANIZADAS
“As melhores arquiteturas, requisitos e designs emergem de equipes auto-

organizáveis”
As melhores
Há muita controvérsia sobre este princípio pois algumas pessoas acreditam
que uma equipe sem especialistas pode apresentar ideias e soluções
melhores do que um grupo de especialistas qualificados e experientes.
As ideias dos especialistas certamente seriam incluídas, fato pelo qual o
especialista é membro da equipe. Isso remete ao princípio de fornecer à
equipe o ambiente e o apoio necessários para realizar o trabalho esperado.
Quanto aos pré-requisitos, aproximadamente 14 anos atrás, foi publicado
um livro chamado “A Sabedoria das Multidões”, que discute como um
grupo pode ter uma melhor decisão em comparação a um indivíduo
do grupo, incluindo um especialista. No entanto, não é qualquer grupo
que poder fazer isso. Há alguns pré-requisitos que irei relacionar da
metodologia ágil:
• Todos no grupo podem ter perspectivas e ideias individuais. Ter uma
equipe multifuncional de pessoas motivadas para encontrar uma boa
solução.
• As opiniões pessoais não devem ser influenciadas (indevidamente)
por outras pessoas. É preciso evitar o pensamento em grupo.
• É possível recorrer a conhecimentos diversificados. A base das
informações não é gerada apenas dentro do grupo.
• Existem formas de todas as opiniões serem agregadas para se chegar a
uma decisão colaborativa. As pessoas podem se comunicar livremente.
A crença é que, uma decisão coletiva baseada nesses pré-requisitos,
acabaria melhor do que se um especialista sozinho encontrasse a solução.
Equipes auto-organizadas
A expressão “equipes autogerenciadas ou auto-organizadas” é usada para
indicar quando as equipes se organizam da maneira que consideram
adequada para realizar o trabalho em cada iteração e depois se gerenciam
85
para executar esse trabalho. Tudo o que está dentro do escopo da equipe é
decidido e executado por ela.
Isso significa que as equipes fazem as próprias estimativas, determinam
as próprias tarefas, trabalham juntas e individualmente para executá-las,
apresentam o trabalho ao final de cada iteração e verificam com outros
fora da equipe de desenvolvimento, como o PO, outras equipes, o pessoal
de gestão e os clientes, que o trabalho atende às expectativas.
Pode levar um tempo para uma equipe entender como fazer isso, pois
muitas pessoas estão acostumadas a seguir ordens de outras pessoas. Por
exemplo, quando o gerente decide ou é consultado para aprovar algo que
as equipes ágeis deveriam decidir por si mesmas. Isso não significa que
os gerentes não tenham lugar em um ambiente ágil (embora algumas
antigas publicações ágeis promovessem essa ideia). Muito pelo contrário,
o objetivo dos gerentes é adotar uma abordagem de um “líder servidor” e
estar preocupado em fornecer à equipe tudo o que precisam para o sucesso
da empreitada, em vez de esperar que a equipe aja como se o gerente fosse
o único responsável pelo sucesso.
Certa vez tive um gerente que sabia muito bem o que era ser ágil. No
entanto, ele era muito perspicaz e estava acostumado a ser direto na
maneira como abordava as equipes. Um dia ele me disse: “Eu sei que não
devo interromper a equipe e dizer a eles o que fazer, mas estou preocupado
que a equipe não esteja seguindo bem a metodologia ágil. Não acho que
eles usam a retrospectiva de maneira efetiva”. Essa é uma preocupação
legítima, pois uma equipe deveria estar tentando usar a retrospectiva de
maneira efetiva. Sugeri o seguinte: “Da próxima vez que a equipe tiver
uma retrospectiva, assim que for finalizada, pergunte ao Scrum Master
se existe algo que a equipe comentou na retrospectiva no qual ele possa
ajudar?”. Isso alcança três coisas sem ser direto ou intrusivo:
• Deixa clara a expectativa de que a equipe realize a Retrospectiva;
• Deixa clara a expectativa de que a equipe apresente alguns itens de
melhoria a serem perseguidos;
• Ajuda a equipe a alcançar as melhorias sempre que possível.
Se a resposta sugerir que ele “foi pego de surpresa”, o gerente pode explorar
um pouco mais o assunto perguntando: “Houve alguma dificuldade ao
realizar a retrospectiva ou no momento de decidir sobre quais itens de
melhoria deveriam ser trabalhados?”
86
Dessa forma, ao invés de dizer o que fazer, o gerente estaria perguntando
e possivelmente recebendo uma resposta razoável.
As equipes ainda podem ser incentivadas a se auto-organizar e gerenciar
com essa abordagem, mas deve estar claro que, é esperado que elas façam
isso.
CAPÍTULO 18
Reflexões da equipe
REFLEXÕES DA EQUIPE
“Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e
então refina e ajusta seu comportamento de acordo”
De alguma forma, é apropriado que esse seja o último princípio, dado que o
primeiro valor é sobre indivíduos e interações. Acredito que este princípio
está significativamente associado a esse primeiro valor. Retrospectivas são
um aspecto essencial de como os indivíduos interagem em um contexto
ágil. Infelizmente, as retrospectivas, devido às pressões do cronograma,
podem ser ignoradas quando a equipe sente (ou é comunicada) que não há
tempo para realizar a retrospectiva.
Este último capítulo será um pouco mais longo que os anteriores, pois
acredito que há muitas coisas importantes a dizer sobre retrospectivas.
Intervalos regulares
O objetivo da retrospectiva é a melhoria contínua. Ser contínuo significa
melhorar com alguma frequência. A frequência mínima está no final de
cada iteração. As sessões clássicas de “lições aprendidas” ou “post mortem”
normalmente ocorreriam somente após o final de um projeto ou de um
lançamento inteiro e existem vários problemas com isso:
• No final de um projeto ou lançamento, as pessoas são frequentemente
dispersas para novos projetos, dificultando a reunião delas para uma
sessão;
• Como essas sessões ocorrem geralmente meses após o início do
projeto, algumas pessoas podem nem estar por perto para participar,
e aqueles que estão podem não se lembrar das coisas que pensavam
meses atrás e que poderiam ser mencionadas na sessão;
• Muito do que é discutido nessas sessões fala sobre as coisas que deram
errado e como corrigi-las para o próximo projeto ou lançamento,
assim essas sessões não ajudam quando o projeto terminou;
• As sessões costumam ser eventos organizados pela gerência, nos
quais algumas pessoas podem não querer se manifestar devido à
preocupação com a forma como podem ser vistas se levantarem um
problema que as pessoas preferem não enfrentar.
Essas são algumas das razões pela qual espera-se que a frequência (e a
participação dos papéis abaixo) das retrospectivas sejam mantidas como
são.
89
Por outro lado, a reflexão e a adaptação não precisam esperar até o final da
iteração. Existem oportunidades diárias para que isso ocorra em equipe e
individualmente. A reunião diária pode levantar problemas que a equipe
deve resolver imediatamente, em vez de adicioná-los a uma lista para o
final da iteração. No final do dia de cada pessoa, eles podem se perguntar:
“O que posso fazer amanhã para tornar nossa equipe mais eficaz?” Isso é o
que minimamente se espera do facilitador de uma equipe.
A equipe
Quem deve participar da retrospectiva? O Guia Scrum afirma que esta é
uma reunião da equipe Scrum e define os seguintes membros: um PO, a
equipe de desenvolvimento e um Scrum Master. Os dois últimos são vistos
universalmente como participantes, mas isso nem sempre é verdade para
o PO. Às vezes, as equipes de desenvolvimento consideram o PO como
um gerente. Como os gerentes não são incluídos na retrospectiva, o PO
também é excluído. Isso é lamentável, pois eles têm conexão direta com o
trabalho realizado e claramente têm opiniões como qualquer outra pessoa
da equipe Scrum sobre como as coisas foram durante a sprint.
Acredito que possa haver abordagens para envolver o PO na retrospectiva,
ou que não o exclua completamente:
• Ele poderia assistir ao início da retrospectiva, pontuar situações
relevantes em alguma discussão e depois sair;
• Ele poderia oferecer sua perspectiva ao Scrum Master antes da
retrospectiva, dessa forma essas ideias poderiam ser fornecidas para
consideração na retrospectiva.
Nenhuma dessas opções seria ideal, mas é melhor que a exclusão total.
Em ambos os casos o PO deve receber feedback sobre o que aconteceu
com suas ideias e o que a equipe de desenvolvimento apresentou como
melhorias.
Em minha experiência percebi que algumas equipes podem ter problemas
particulares nos quais desejam trabalhar, mas deve haver algumas
melhorias que podem ser compartilhadas publicamente.
90
Tornar-se mais eficaz

A ideia de melhoria contínua remonta os primeiros trabalhos lean após
a segunda guerra mundial no Japão. Neste contexto o termo é conhecido
como kaizen. A melhoria não precisa ser uma grande mudança, apenas
uma mudança contínua para melhor. Mesmo algo que parece funcionar
bem pode funcionar ainda melhor e talvez ser aprimorado.
Certamente, a retrospectiva não se trata apenas de “consertar” coisas que
não foram bem. Ouvi equipes dizerem que não precisam realizar uma
retrospectiva porque tudo correu bem na iteração. Isso indica que eles
veem a retrospectiva como uma reunião de solução de problemas. Ou
seja, sem problemas, sem reunião. Como o objetivo é melhorar, a menos
que uma equipe acredite que é perfeita em ser previsível, produtiva e em
produzir um trabalho sem defeitos, sempre há algo a melhorar.
Um foco típico dessa reunião inclui:
• O que funcionou bem e que a equipe gostaria de continuar fazendo,
ou seja, tornar parte de seu trabalho regular?
• O que não funcionou tão bem e deve ser alterado para melhor (ou
talvez descartado porque não é útil)?
• O que ainda pode ser testado e que a equipe ainda não tenha tentado,
por exemplo, aprender algo novo ou experimentar uma nova ideia?
Se a equipe sente que não tem nada a dizer sobre a segunda categoria,
ainda assim deveriam considerar as outras duas.
Refinar e ajustar
Um problema comum que muitas vezes predispõe as equipes a abandonar
retrospectivas é quando fazem listas de ideias para melhoria, mas acabam
não fazendo nada para melhorar. Depois de fazer isso algumas vezes, a
equipe se perguntará por que eles deveriam se importar.
É imperativo que as equipes deixem de elaborar listas e passem a priorizar
suas ideias, selecionando apenas uma ou algumas delas, determinando
o que será necessário para buscar as melhorias (nas tarefas ou nas
estimativas de esforço, por exemplo) e comprometendo-se a seguir uma
ou mais dessas ideias. Tenho visto algumas equipes criarem um backlog
de melhorias em que as ideias de melhoria são tratadas como requisitos.
91
Nas reuniões diárias da próxima iteração, o facilitador da equipe pode

perguntar sobre os itens que a equipe citou e que tentariam buscar como
melhorias. Isso pode ajudar a equipe a lembrar quais itens devem receber
atenção durante a iteração.
Na próxima retrospectiva, esses itens devem fazer parte das entradas da
reunião, com a seguinte pergunta: Como a equipe trabalhou nesses itens
durante a iteração?
Retrospectivas ineficazes
Além de uma lista interminável que não leva a lugar algum, vejamos outras
coisas que podem desencorajar uma equipe a conduzir retrospectivas ou
usá-las de maneira eficaz:
• Processo maçante/repetitivo - Realizar a retrospectiva da mesma
maneira toda vez pode se tornar entediante. A abordagem clássica
de brainstorming percorrendo a sala coletando as ideias de cada
participante, anotar e fazer isso até que todos acreditem que não
têm mais o que dizer me parece um pouco entediante. No mínimo,
a prática não engaja toda a equipe logo de início, pois as pessoas
precisam esperar que cada participante diga algo antes que mais
alguém fale. Se alguém tem muitas ideias, muitas pessoas ficarão
lá sentadas até que essa pessoa repasse sua lista. Além disso, ouvir
o que uma pessoa diz pode levar os participantes a não repetirem
uma ideia semelhante uma vez que as pessoas não querem parecer
redundantes, embora seja útil ouvir a diferença na forma como a ideia
é apresentada.
• Vitimismo, a culpa é dos outros - Às vezes a maioria das coisas das
quais uma equipe fala são problemas que vêm de pessoas de fora da
equipe, que embora possam ser legítimos, podem resultar na sensação
de que a equipe não tem muito o que fazer para mudá-las, isso porque
são os outros que precisam mudar/melhorar. Mesmo reconhecendo
e legitimando o que é dito, o facilitador precisa perguntar: O que
poderíamos fazer sobre isso? Quem pode nos ajudar com esse
problema? Como podemos nos ajudar?
• Sessão de culpados - Isso ocorre com mais frequência se não houver
um espírito de confiança e colaboração o suficiente na equipe. As
pessoas vão procurar os culpados pelos vários problemas. Queremos
resolver as questões, mas não para que as pessoas sejam colocadas
92
na defensiva. É sugerido evitar palavras acusatórias como “você” ou

“eles(as)”, substituí-las por “nós” ajuda bastante. Lidar com isso pode
exigir o uso de uma coleta de dados anônima (veja abaixo), pois as
pessoas podem simplesmente não levantar os problemas para evitar a
culpa, mas os problemas provavelmente precisam ser ouvidos.
• Questões difíceis de falar - Ainda que sejam importantes, as pessoas
podem evitar levantar questões específicas para os indivíduos da
equipe porque é desconfortável fazê-lo. Abordar esse tipo de questão
pode acabar promovendo defensivas ou discussões destrutivas.
Embora a retrospectiva seja uma atividade importante para a equipe,
também pode ser a mais difícil para que os integrantes se envolvam
efetivamente. As considerações fundamentais de comunicação,
colaboração, comprometimento, melhoria contínua, confiança e
excelência discutidas no Capítulo 2 são particularmente importantes no
contexto da retrospectiva.
Algumas ideias para retrospectivas

Tenho algumas estratégias para aplicar na retrospectiva que já utilizei
com algumas equipes. Para permitir que o facilitador da equipe/Scrum
Master participe como membro da equipe e não precise trocar de chapéu
nessa função para contribuir com ideias, basta pedir a um facilitador
externo para executar a sessão. Poderia ser o facilitador/Scrum Master de
outra equipe, se for o caso, ambos poderiam facilitar a retrospectiva um
do outro. Também poderia ser alguém da equipe de treinamento (ou do
RH) que fosse capacitado em facilitação de reuniões. Isso também serve
a um propósito útil na introdução de pessoas fora do esforço ágil para
conhecer um pouco mais sobre o processo.
Tive equipes que alternaram a facilitação entre os membros da equipe. A
cada iteração, um membro diferente da equipe se preparava procurando
maneiras novas e diferentes de executar a facilitação. A vantagem aqui é
incentivar todos a autogerenciar essa atividade.
Como observado acima, a abordagem tradicional de brainstorming tem
problemas em potencial na coleta de feedback. Uma maneira simples de
superar muitas delas é pedir às pessoas que anotem suas ideias em um
bloco de anotações ou notas adesivas.
93
Isso permite que todos estejam ocupados ao mesmo tempo e que possam
ter quantas ideias quiserem, sem precisar esperar sua vez de fazê-lo.
Quando as pessoas tiverem esgotado as ideias, todos são convidados a
levar e colocá-las em uma parede, quadro, etc. Uma possibilidade é
dividir em categorias como “Pessoas”, “Cultura”, “Processo”, “Ambiente”
e “ Ferramentas”. Isso inicia o processo de agrupamento de ideias para
discussões mais aprofundadas. Também facilita para que as pessoas
voltem um passo, observando os padrões gerais e refletindo sobre isso
antes de mergulhar nos detalhes de cada ideia específica. Quando faço
isso, geralmente segmento as categorias no seguinte formato:
• Pessoas - interações entre indivíduos;
• Cultura - as crenças da organização sobre interações;
• Processos - a maneira como as pessoas trabalham para fazer as coisas;
• Ambiente - o ambiente físico em que as pessoas trabalham;
• Ferramentas - as coisas que as pessoas usam, manual ou eletrônico,
para realizar seu trabalho.
Normalmente o volume maior de ideias recai sobre as categorias Pessoas

e Cultura, diminui um pouco para Processos e fica ainda menor para as
duas últimas. Podemos imaginar o tipo de discussão que se segue quando
as pessoas veem isso, independentemente de quão óbvio possa ser. Ver o
“óbvio” apresentado fisicamente apenas enfatiza a impressão.
Certa vez usei essa abordagem com categorias quando um Scrum Master
me pediu para fazer uma retrospectiva, isso porque havia um sentimento
de que a última Sprint não havia saído como o esperado. Comecei a
retrospectiva reconhecendo que a última Sprint tinha sido difícil. Ao
invés de escrever ideias sobre as coisas que deram errado, pedi a eles
que escrevessem como gostariam que as coisas tivessem acontecido e
que as categorizassem. Em seguida, pedi que discutissem sobre como
eles achavam que poderiam fazer essas coisas acontecerem. Isso se
transformou em uma retrospectiva muito mais positiva do que o Scrum
Master, provavelmente com razão, temia.
Coletando Feedback
Realizar a coleta de feedback de forma muito aberta pode não gerar os
resultados desejados. Se as pessoas relutam em levantar questões por
qualquer motivo, talvez alguma forma de coleta de dados anônima possa
funcionar. As pessoas ainda podem escrever as coisas como mencionado
94
acima, mas talvez todas elas devam ser entregues e embaralhadas antes de
lidar com elas.
Em uma de minhas experiências, um Scrum Master pediu que eu
facilitasse uma retrospectiva porque ele queria levantar a questão sobre
como as pessoas se sentiam com o trabalho em equipe. Entretanto, ele
não tinha certeza se as pessoas falariam e estava preocupado que os
sentimentos fossem de alguma forma negativos. Pedi às pessoas que
classificassem seu senso de espírito de trabalho em equipe em uma escala
de 1 a 5, escrevessem esse número em um bloco de notas e em seguida me
entregassem para embaralhar. O “1” significava que eles sentiam que o
espírito era ruim e um “5” significava que eles sentiam que era excelente.
X
X
X
X X
X X X X X
1 2 3 4 5
Figura 6: Gráfico de barras a partir do espírito de equipe.
Gráfico de barras
Enquanto lia os números, o Scrum Master criava um “gráfico de barras”
como o da figura anterior, colocando um “x” quando um número
específico era lido e empilhando outro “x” quando o mesmo número era
lido novamente. Perguntei a todos o que eles achavam dos dados gerais
da equipe e algumas pessoas ficaram surpresas por não ser mais negativo.
Todos podiam ver que algo poderia ser feito, mas não era tão ruim quanto
muitos temiam. Inclusive um dos membros que frequentemente estava
desmotivado falou bastante.
95
Os cinco porquês
Uma técnica para lidar com os dados coletados é chamada de “5 porquês”,
trata-se de uma abordagem de análise da causa raiz. Pegamos um problema
e perguntamos por que isso aconteceu, depois perguntamos por que o fato
que gerou o problema aconteceu. Repetimos isso até achar que atingimos
a causa raiz e não apenas os sintomas. Por exemplo, uma equipe poderia
dizer: “Temos problemas para concluir histórias em todas as Sprint.” Em
resposta ao motivo pelo qual pensam que isso acontece, eles poderiam
dizer: “Porque outras equipes das quais dependemos não entregam o que
precisamos.” Perguntado por que pensam que isso acontece, uma resposta
hipotética poderia ser: “Porque é difícil de trabalhar com a coordenação.”
As perguntas poderiam continuar sendo feitas até que o sentimento de
que algo que foi declarado poderia ser mudado. Uma solução alteraria a
linha de problemas para ajudar o problema geral.
Ferramentas para análise de dados

Há também uma variedade de ferramentas que ajudam a coletar, organizar
e visualizar dados. Um livro chamado The Quality Toolbox (sem tradução
para o português do Brasil), publicado pela Sociedade Americana de
Qualidade (ASQ), está repleto de exemplos e explicações sobre tais
ferramentas. Usei muitos exemplos, que incluem alguns tipos de gráficos
tradicionais, como os disponíveis em planilhas eletrônicas e coisas mais
sofisticadas, como gráficos de controle estatístico.
96
Application Architecture
Version Control Usability
Timeliness Reliability
Efficiency Interoperability
Effectiveness
Current State
Desired State
Figura 7: Diagrama de Kiviat com o estado atual e desejado pela

equipe
Um dos que mais gosto é o diagrama Kiviat, também conhecido como
diagrama de teia ou radar. Os tópicos que necessitam de feedback são
listados na borda externa.
As linhas radiais geralmente têm marcas de escala, sendo as mais próximas
do centro a extremidade inferior. Para cada tópico é solicitado às pessoas
que forneçam valores numéricos. No exemplo acima, dois desses valores
são solicitados: onde as pessoas gostariam de estar (linha azul) e onde elas
sentem que estão (linha verde). Em seguida podemos calcular a média dos
dados ou plotar os dois valores de cada pessoa, conectando as linhas como
foi mostrado. Mais uma vez, se distanciar do quadro permite que todos
vejam o que o gráfico informa sobre as áreas em que o estado desejado
está mais distante do real. Em seguida, inicia-se uma discussão sobre o
que fazer a partir do que é visto no gráfico.
97
Outra ideia é usar algo como o exercício do veleiro, criado originalmente

por Luke Hohmann. Esse diagrama específico está no site de Luis
Gonçalves e também pode ser encontrado no livro que ele escreveu
com Ben Linders ‘Obtendo Valor de Retrospectivas Ágeis’, que começou
como um mini livro no InfoQ: https://www.infoq.com/minibooks/agile-
retrospectives-value/ (disponível também em português). Além dessa
representação, também vi imagens de um sol e um tubarão adicionados a
esse diagrama.
Figura 8: A dinâmica do veleiro

As pessoas escrevem suas ideias em blocos de notas adesivas e as colocam
onde pensam que pertencem ao diagrama. O significado das imagens
individuais pode ser:
• Palmeiras - qual era o objetivo / visão da equipe para a iteração;
• Rochas - os riscos que a equipe enfrentou e pode ter atingido (neste
caso o adesivo fica nas pedras) ou evitadas (aqui o adesivo não fica
exatamente nas pedras);
• Âncora - algo que reteve ou deixou a equipe mais lenta;
• Vento - algo que fez com que a equipe avançasse;
• Tubarão - algo que “mordeu” a equipe durante a iteração, ou seja,
resultou em problemas;
98
• Sol - algo que “iluminou o dia” para alguém.

Novamente, depois que todos os adesivos estiverem no quadro, todos se
afastam para ter uma ideia geral do que a imagem sugere. Dessa forma
pode ser decidido onde o foco mais detalhado pode começar.
Finalmente, existe o que chamo de “retrospectiva corrente”, acredito que
seja uma invenção minha, pois, conscientemente, não copiei de ninguém
quando a criei há vários anos. Pegamos um pedaço de papel longo e largo
e desenhamos uma linha horizontal que representa a iteração. Cada marca
de seleção na linha representa um dia na iteração.
Figura 9: Retrospectiva corrente.

Durante a iteração, a qualquer momento, uma pessoa pode escrever
uma nota e colá-la na marca daquele dia. Apresentei isso a uma mesa de
workshop no Scrum Gathering e Alistair Cockburn fazia parte da mesa.
Sua sugestão era que as pessoas colocassem os adesivos: a) acima da linha
se fosse uma experiência positiva (quanto mais positiva, mais acima), b)
abaixo da linha, se negativo (quanto mais negativo, mais abaixo), ou c) na
linha se era apenas uma observação que a pessoa queria fazer sem nenhum
sentimento forte de um jeito ou de outro.
Na retrospectiva, já haveria muitos dados (e mais poderiam ser
adicionados) e isso poderia levar a retrospectiva diretamente à discussão
e seleção de ideias de melhoria que valem a pena. Obviamente, as pessoas
podem ver padrões se formando ao longo da iteração e podem querer
abordar algo que enxergam antes da próxima retrospectiva agendada, já
que a necessidade/decisão de melhorar não precisa esperar até o final da
iteração.
99
De modo geral o objetivo é que a coleção de ideias seja feita em toda a

iteração.
O que vem depois?

Certamente há muito mais coisas que podem ser ditas sobre retrospectivas.
Basta digitar no navegador “exercícios e jogos de retrospectivas ágeis”
ou alguma outra combinação dessas palavras para encontrar muitas
ideias. Também existem livros como o Agile Retrospectives e Project
Retrospectives (ambos sem tradução para o Português do Brasil) que você
pode pesquisar. Independente da estratégia não devemos permitir que as
pessoas desistam da retrospectiva.
100
EPILOGUE
Epílogo
Acredito que este livro tenha oferecido algumas perspectivas interessantes

sobre os valores e os princípios do Manifesto Ágil. O próximo passo é seu:
tentar colocá-los em prática na sua organização ou ambiente. Use-os para
refletir, em vez de simplesmente se apressar e executar.
Se você ou sua equipe não receberam nenhum treinamento formal sobre
o ciclo de vida ágil básico, recomendo fortemente que realizem um. Em
seguida, incentivamos que procure um treinamento inicial para ajudá-lo a
avançar em direção ao sucesso. Nenhuma dessas dicas deve custar muito.
Uma perspectiva antiga

e duas recentes
Como observado no Capítulo 1, houve uma variedade de propostas para
atualizar o manifesto. Kent Beck, em 2010, falou de uma evolução das
declarações de valor do Manifesto Ágil:
Visão de equipe e disciplina mais que indivíduos e interações;
Aprendizado validado mais que software em funcionamento;
Descoberta do cliente mais que colaboração com o cliente;
Iniciar a mudança mais que responder à mudança;
Pensamento que parece se encaixar bem em duas perspectivas recentes.
Quatro valores e 12 princípios, além de muitos métodos, frameworks
e práticas - é muita coisa para absorver. Uma pergunta comum é
exatamente sobre o que é a essência de ser ágil. Algumas pessoas criaram
definições simples e fáceis de pensar sobre isso que achei particularmente
interessantes.
Modern agile
Alguns anos atrás, Joshua Kerievsky apresentou suas ideias de uma forma
que ele chama de modern agile para abordar o que ele considera como
101
UNDERSTANDING AGILE VALUES & PRINCIPLES
“agilidade antiquada”. Deixarei as palavras dele, com algumas edições,

falarem por si mesmas e sugiro que, se soarem interessantes, sejam
investigadas mais a fundo.
Figura 10: Modern Agile.

Kerievsky disse:
• Torne Pessoas Sensacionais - no Modern Agile, perguntamos como
podemos tornar as pessoas em nosso ecossistema sensacionais. Isso
inclui as pessoas que usam, fabricam, compram, vendem ou financiam
nossos produtos ou serviços. Aprendemos o contexto e os pontos
problemáticos, o que os impede e o que aspiram alcançar.
• Faça da segurança um pré-requisito - Tornamos ativamente a
segurança um pré-requisito estabelecendo a segurança antes de iniciar
qualquer trabalho perigoso. Protegemos o tempo, as informações, a
reputação, o dinheiro, a saúde e os relacionamentos das pessoas. E
nos esforçamos para tornar nossas colaborações, produtos e serviços
resilientes e seguros.
• Experimente e aprenda rapidamente - você não pode tornar as
pessoas sensacionais ou tornar a segurança um pré-requisito se não
estiver aprendendo. Aprendemos rapidamente experimentando com
frequência. Como fazemos com que nossos experimentos sejam
seguros para falhar, não temos medo de realizar mais experimentos.
Quando ficamos presos ou não estamos aprendendo o suficiente,
102
EPILOGUE
consideramos isso um sinal de que precisamos aprender executando

mais experiências.
• Entregue valor continuamente - pergunte como um trabalho valioso
pode ser entregue mais rapidamente. Entregar valor continuamente
exige que dividamos grandes quantidades de valor em pedaços
menores que podem ser entregues com segurança agora em vez de
mais tarde.
Heart of agile
Alguns anos antes de encontrar o modern agile, ouvi falar sobre o Heart
of Agile proposto por Alistair Cockburn como uma maneira sucinta de
“voltar ao centro do ágil” depois do que ele achava ter sido muitos anos
de ideias e práticas “excessivamente decoradas”. Ele sente que as quatro
palavras no diagrama associado “não precisam de muita explicação. Elas
não precisam de muita instrução. Com exceção do “Reflect” (Refletir), que
é feito muito pouco em nossos dias, os outros três são conhecidos pela
maioria das pessoas. Você sabe se os está fazendo ou não.
Deliver
Collaborate Reflect
Improve
Figura 11: Heart of Agile.
103
Essas quatro palavras podem ser expandidas da seguinte maneira:
Learning Income
Collaboration Deliver Insights
Collaborate Reflect
Trust Improve Improvements
Experiment Change
Figura 12: Expansão de primeiro nível do Heart of Agile.
104
EPILOGUE
E ainda mais:
SOCIAL TECHNICAL
BUSINESS COST EARLY REVENUE
MANAGE
QUEUES
Learning Income
GOALS
LISTEN
Collaboration Deliver Insights

STEP FORWARD
RESULTS
Collaborate Reflect
LET SOMEONE INCLUDE
ELSE DO IT EMOTIONS
Trust Improve Improvements

ALLOW FAILURE FOCUS
FORWARD
Experiment Change
LIMIT CONCRETELY
EMOTIONAL CHANGES (SOLUTION FOCUS)
SAFETY AGGRESSIVELY
Figura 13: Expansão de segundo nível do Heart of Agile.

Cockburn nos lembra que “o objetivo do Heart of Agile não é fingir que
complexidades e sutilezas não existem; é para nos lembrar de encontrar e
afastar todas as complexidades de tempos em tempos e sempre recomeçar”.
Ao longo dos anos, sempre achei as ideias de Cockburn e a apresentação
dessas ideias significativas. O primeiro livro que li dele, Agile Software
Development (revisado em 2006), abrange um amplo escopo não apenas
de ideias ágeis, mas como elas se relacionam e podem ser cruzadas com
outras ideias. Outro de seus livros, Crystal Clear, aborda suas próprias
opiniões sobre a implementação de uma abordagem ágil e contém muitas
ideias interessantes.
Uma dessas ideias é que há mais de um conjunto de práticas que um
o projeto pode precisar com base no impacto percebido (perda) se um
105
projeto não for bem-sucedido, combinado com o número de pessoas que

devem estar envolvidas no projeto. Maior potencial de perda sugeriria
verificações mais rigorosas e validações práticas. Um maior número de
pessoas implica considerações de comunicação mais formais.
Outra é que ele defende construir sua abordagem, em vez de ir
remendando-a. Ou seja, começar com uma abordagem que seja a coisa
mais simples que poderia funcionar e adicionar rigor onde parece
necessário, em vez de começar com uma abordagem muito rigorosa e
complexa e jogar fora as coisas que você sente que não precisa. É melhor
incentivar as pessoas a acrescentar rigor do que encorajar a mentalidade
de sair com menos.
106
Leitura adicional
Espero que o livro tenha sido interessante o suficiente para que você
considere algumas das ideias descritas em sua jornada ágil. Aqui estão
alguns livros que acho interessantes para explorar ainda mais o Ágil e as
ideias da agilidade:
O Extreme Programming Explained por Kent Beck explica as práticas
de desenvolvimento e a abordagem XP para “gerenciar” um projeto
pela equipe. Balancing Agility and Discipline (Equilibrando Agilidade
e Disciplina) de Barry Boehm e Richard Turner, um livro que trata de
desenvolvimento mais tradicional e rigoroso ao buscar ideias ágeis.
O Management 3.0 (Gerenciamento 3.0) e o Managing for Happiness
(Gerenciando para a Felicidade), ambos de Jurgen Appelo abordam a
complexidade e o gerenciamento em situações complexas e um livro sobre
técnicas, exercícios etc. para usar no trabalho com pessoas e equipes.
O livro Treinamento de equipes ágeis (Coaching Agile Teams, no original)
de Lyssa Adkins que é exatamente o que parece, oferecem conselhos a
coaches, Scrum Masters, gerentes e qualquer pessoa que queira ajudar
as equipes a crescer e se desenvolver, incluindo os próprios membros da
equipe.
O Desenvolvimento de Software com Scrum: Aplicando Métodos Ágeis
com Sucesso (Succeeding with Agile, no original) por Mike Cohn, conselhos
de implementação ao trabalhar em uma abordagem Scrum.
O Scrum Essencial (Essential Scrum, no original) de Ken Rubin, outro “guia”
para implementar o Scrum.
Kanban de David Anderson, um livro-chave sobre a aplicação do Kanban,
especialmente em um contexto de software.
Scrumban por Corey Ladas, combinando as abordagens Scrum e Kanban
para gerenciar o trabalho e o fluxo de trabalho.
Lean Software Development, Implementando Lean Software Development
e Lean Software Development por Mary e Tom Poppendieck, aplicando
conceitos Lean ao desenvolvimento de software.
107
A ponte para a agilidade do gerente de projetos de software de Michelle

Sliger e Stacia Broderick (Michelle foi uma das pessoas que aconselhou o
PMI na criação de seu programa PMP-ACP).
Gestão de Produtos com Scrum por Roman Pichler e Scrum Product
Ownership: Balancing Value from the Inside Out por Bob Galen (Roman
talvez seja mencionado com mais frequência, mas Bob também é bom).
The Quality Toolbox de Nancy R. Tague (a publicação da ASQ mencionada
após o exemplo do diagrama Kiviat).
O Guia do Scrum (The Scrum Guide) de Ken Schwaber e Jeff Sutherland
(basta digitar “O Guia do Scrum” no seu navegador para encontrar o site
(scrum.org) onde você pode baixar a versão mais recente da definição
“definitiva” do que é o Scrum)
108
Sobre o autor
Scott Duncan está na indústria de software há 47 anos como

desenvolvedor, pesquisador de transferência de tecnologia, consultor de
processos, treinador e agile coach. Ele trabalhou em áreas como vendas e
distribuição de livros, governos estaduais, banco de dados de mainframe
e produtos de consulta em linguagem natural, telecomunicações (mais
de 14 anos nos Laboratórios Bell, Bellcore, Telcordia), processamento de
transações com cartão de crédito e serviços bancários.
Seu cargo mais recente em tempo integral foi como coach e treinador
corporativo de uma organização que desenvolveu software para o design,
construção e operação de usinas de energia (incluindo nuclear), plantas de
processamento (por exemplo, refinarias de petróleo, produtos químicos)
e navios. Lá, ele ajudou a expandir a organização para 144 equipes Scrum
nos EUA, Índia, Israel, Reino Unido, Alemanha, França e Canadá.
Ao longo do caminho, ele foi treinado como Auditor da ISO 9001 e
assessor da CMM, foi membro dos Comitês de Normas ISO & IEEE por
15 anos e foi membro do Conselho de Administração da Scrum Alliance
por 2 anos.
Atualmente, ele faz treinamento e coaching como instrutor certificado
pela ICAgile para fundamentos do ágil, coaching, testes, business agility
e liderança, além de vários cursos não certificados de scrum master,
product owner, gerente e membro da equipe.
Scott tem um site em www.agilesoftwarequalities.com e pode ser
contactado em agileswqual@gmail.com.
109

Agile+Manifesto br25 01 1611705580749

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Agile+Manifesto br25 01 1611705580749

Enviado por

Direitos autorais:

Formatos disponíveis

UMA ANÁLISE DO MANIFESTO ÁGIL

A agilidade é baseada em um conjunto de valores e princípios descrito em

“Sempre que me envolvo com pessoas que desejam praticar a agilidade,

Na ocasião em que escrevo essas linhas, o Manifesto para Desenvolvimento

Como adicionar valor em um livro com explicações e comentários das

Tradutores da edição brasileira

Eduardo Kuwakino é formado em Tecnologia em Informática pela

Tenho realizado sessões de coach e treinado equipes com abordagens ágeis

a declaração final e a preposição. Reações iniciais ao manifesto muitas

precedência, não uma relação excludente, dentro de cada declaração de

Ágil além do software

No Capítulo 1, mencionei diversas ideias que chamei de “fundamentais”.

clientes e equipes de desenvolvimento. A maioria dos problemas de

suporte da TI apontou que uma grande soma de dinheiro estava sendo

Fazendo isso juntas, se comunicando de forma adjacente, as pessoas

Este capítulo começa com um conjunto de quatro partes focadas em

(cold) RICHNESS (”TEMPERATURE”) OF COMMUNICATION CHANNEL (hot)

Figura 1: Comparação dos meios de comunicação por efetividade

Comunicação com o software

testar o software para ver como funciona. Feito de forma frequente,

a alta qualidade e para as pessoas que a manterão atualizada. O

• Em cada revisão de funcionalidades desenvolvidas durante aquela

Talvez nada represente melhor a definição tradicional de “ágil” do que

um artigo intitulado “Iterative and Incremental Development: A Brief

A partir de fontes da história do planejamento militar temos frases

“Nossa maior prioridade é satisfazer o cliente através da entrega contínua e

Nossa maior prioridade

“elefante na sala” e o “peixe morto embaixo da mesa”: aquelas coisas que

Entrega contínua e adiantada

Software com valor agregado

transmitir seu senso de urgência/prioridade, bem como informar melhor

end do banco de dados e mostraram o resultado ao cliente na revisão da

“Mudanças nos requisitos são bem-vindas, mesmo tardiamente no

Mudanças nos requisitos

• Aumentar o orçamento, mesmo que ainda desejem manter o que já

desenvolvedor fizesse o check-in de um código e o teste associado (que

trabalho técnico pode parar, no mínimo em algumas partes do sistema, e

“Entregar frequentemente software funcionando, de poucas semanas a poucos

Dar preferência a escalas

com ciclos de tempo maiores. Aparentemente o último livro sobre Design

Por que iterações curtas?

há uma década. Entretanto, a equipe queria estabelecer um prazo mais

“Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto

Trabalhar diariamente em conjunto

Por todo o projeto

Figura 2: Expectativa de atenção dos clientes, com base na

“Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o

pessoas simplesmente não fazem o trabalho corretamente. Se pudéssemos

precisava ser reformado, não as pessoas. Obviamente, algumas pessoas

“O método mais eficiente e eficaz de transmitir informações para e entre uma

(cold) RICHNESS (”TEMPERATURE”) OF COMMUNICATION CHANNEL (hot)

Figura 3: Comparação dos meios de comunicação por efetividade.

apenas 17% dessas pessoas consideraram inicialmente que a busca ao ágil

Requirements Acceptance Acceptance

System System System

Architecture Integration Integration

Module Unit Unit

Figura 4: Fluxo de trabalho

Quanto aos meios pelos quais não envolvem perguntas e respostas,

na discussão. Assimilar o rosto com as vozes conversando por telefone

Gerenciando equipes distribuídas

se comunicar de maneira eficaz, em vez de cair na ideia de criar e enviar

Contudo, todos que não fazem parte da equipe de desenvolvimento,