SCRUM - Conceitos Metodo Agil

Sumário
O que é Desenvolvimento Ágil? – FAQ Scrum........................................................................3

1º Princípio do Manifesto Ágil – Entrega Contínua................................................................4
2º Princípio do Manifesto Ágil – Vantagem Competitiva......................................................5
3º Princípio do Manifesto Ágil – Software Funcionando.......................................................7
4º Princípio do Manifesto Ágil – Negócio e Desenvolvedores Juntos..................................8
5º Princípio do Manifesto Ágil – Motivação..........................................................................10
6º Princípio do Manifesto Ágil – Cara-a-Cara.......................................................................12
7º Princípio do Manifesto Ágil – Medindo o Progresso.......................................................13
8º Princípio do Manifesto Ágil – Ritmo Sustentável............................................................15
9º Princípio do Manifesto Ágil – Excelência Técnica...........................................................17
10º Princípio do Manifesto Ágil – Simplicidade....................................................................19
11º Princípio do Manifesto Ágil – Equipes auto-organizáveis............................................21
12º Princípio do Manifesto Ágil – Retrospectiva..................................................................23
Do bom para o ótimo Scrum..................................................................................................24
O que é Sprint? – FAQ Scrum................................................................................................26
Experiência prática de Scrum: Construindo Maquete 3D...................................................29
User Stories – O que são? Como Usar?................................................................................32
Histórias e o Product Backlog – FAQ Scrum.........................................................................35
Vantagens do controle de versão no desenvolvimento ágil...............................................37
Testes de aceitação no desenvolvimento ágil......................................................................39
Critérios de Aceitação das User Stories................................................................................41
BDD – Foco no comportamento do sistema.........................................................................43
Os 9 princípios de Agile Testing.............................................................................................45
História Preparada, o que significa?......................................................................................47
Pair Programming – Programação em Par...........................................................................48
Burndown chart – Mede o progresso da sprint e dá indicativos do processo de trabalho da
equipe........................................................................................................................................49
4 Dicas de Análise do Gráfico de Burnup..............................................................................56
O quadro de tarefas no Scrum...............................................................................................60
Práticas Ágeis de Projeto........................................................................................................62
Desenvolver projetos Scrum com ferramentas é um bom negócio?.................................64
Interseções dos Papéis no Scrum..........................................................................................66
Quais são os papéis do Scrum? – FAQ Scrum.....................................................................70
Importância Reunião Diária....................................................................................................72
Reunião de Planejamento da Sprint – Parte 1: Selecionando o Sprint Backlog..............74
6 motivos por que a Revisão da Sprint é importante..........................................................76
Dando prazos em projetos ágeis...........................................................................................79
A importância da visualização no gerenciamento de projetos...........................................83
Cuidando do Product Backlog................................................................................................86
Boas práticas da reunião de revisão......................................................................................88
Técnica para fazer uma Reunião de Retrospectiva no Scrum............................................90
Gerência de Requisitos no MPS.BR........................................................................................92
Filosofias de Projetos Ágeis....................................................................................................95
Scrum nos processos tradicionais..........................................................................................97
Diferenças entre valores ágeis e tradicionais.....................................................................100
Os princípios do Lean Startup..............................................................................................102
Até quando uma Equipe Scrum precisa de um Scrum Master?.......................................105
Quem cuida do Scrum Master? As Scrumetes!!!................................................................108
O Cliente Não Quer o Que Pede..........................................................................................111
Aprendendo os Termos Scrum – Glossário..............................................................................113
http://blog.myscrumhalf.com/2011/05/faq-scrum-o-
que-e-desenvolvimento-agil/
O que é Desenvolvimento Ágil? –

FAQ Scrum
série "FAQ do Scrum, sobre o que é Desenvolvimento Ágil.
O desenvolvimento ágil é qualquer processo de

desenvolvimento criado com base nos conceitos do Manifesto
Ágil. Tal Manifesto, assinado em 2001, foi elaborado por profissionais experientes e veteranos da indústria
de software. Embora cada um tivesse a sua forma de pensar e agir, todos estavam de acordo que os
projetos de sucesso tinham certos princípios em comum. Esses princípios servem como diretrizes para
equipes que procuram uma forma ágil de administrar seus processos de desenvolvimento.
Os principais valores do Manifesto Ágil são:
 Indivíduos e interações sobre processos e ferramentas;

 Software em funcionamento mais que documentação abrangente;
 Colaboração com o cliente sobre negociação de contrato;
 Respostas a mudanças mais que o acompanhamento de um plano.
Ou seja, embora haja valor nos itens à direita, valoriza-se mais os itens à esquerda.
A filosofia ágil sustenta que a melhor forma de atender às necessidades dos clientes é por meio da
colaboração de um grupo comprometido de pessoas, que se concentra na obtenção de resultados com
rapidez, com o mínimo de sobrecarga possível.
Um elemento-chave dessa filosofia é que devemos confiar nas pessoas e na sua capacidade de
colaboração mais do que em determinados processos. Nenhum processo pode ter sucesso sem as
pessoas, mas as pessoas podem ter sucesso sem um processo. Por isso, devemos criar um processo ágil
tendo como base as habilidades dos membros da equipe, e não depender de uma estrutura de processo
para garantir o seu sucesso.
No caminho ágil, a equipe passa a ter mais espaço para trabalhar a sua criatividade. Não há mais a
pressão de uma gerência pesada e rígida, que impõe o que deve ou não ser feito. Todos são incentivados
a aprender ao longo do trabalho e a tomar decisões que melhor representem o consenso da equipe. Ou
seja, o processo ágil não tem mais como base a antiga relação hierárquica, ou uma estrutura tradicional
de comando e controle como costumamos falar, mas é baseada na colaboração acima de tudo.
Ref.: http://www.cprime.com/about/scrum_faq.html
http://blog.myscrumhalf.com/2011/09/1º-principio-do-manifesto-agil/
1º Princípio do Manifesto Ágil –

Entrega Contínua
.
“Nossa maior prioridade é satisfazer o cliente

através da entrega contínua e adiantada de
software com valor agregado” (Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software)
essay writer
Este é o texto do primeiro princípio do Manifesto Ágil e nele fica claro o foco na satisfação do
cliente. Essa satisfação é alcançada entregando ao cliente o que ele deseja, ou seja, software
que traga soluções ou benefícios para o seu negócio. Entretanto, apenas isso não basta. Esse
software deve ser entregue de forma contínua e adiantada, para possibilitar a validação do
produto ao longo do desenvolvimento e iniciar o fluxo de retorno do investimento tão logo seja
possível.
Ninguém melhor do que o próprio cliente para avaliar se o software em desenvolvimento
agregará valor ao negócio e, considerando que o quanto antes isso for feito menores serão os
custos de possíveis alterações, não devemos aguardar o fim do desenvolvimento para entregar
software funcionando. Planeje o entregas contínuas de partes prontas do software. Essa
estratégia permite ao cliente avaliar a qualidade do produto para o seu negócio ao longo do
desenvolvimento e até iniciar a sua utilização, mesmo esse não estando com todas as
funcionalidades desejadas, mas já contando com um conjunto suficiente para trazer benefícios
antecipadamente.
Encontramos na área de software muita gente acreditando que o objetivo do desenvolvimento
de software é desenvolver software. Mas, na grande maioria das vezes, softwares são
desenvolvidos para resolver problemas complexos, reduzir custos e/ou otimizar lucros. Os
clientes estão atrás desses resultados e investem no desenvolvimento de software
exclusivamente por causa disso, não porque esperam como resultado uma arquitetura
fantástica, a criação de bibliotecas próprias ou preciosismos dos programadores. A qualidade
interna do produto deve ser uma preocupação da equipe, mas ela não é um entregável, o
cliente não pode tocá-la.
Ou seja, comece a entregar software funcionando o mais breve possível e mantenha um fluxo
contínuo de entregas. Assim, a sua chance de ter um cliente satisfeito será muito maior!
2º Princípio do Manifesto Ágil – Vantagem Competitiva

Postado em 8 de setembro de 2011 por José Rodrigues, CSP, Team ScrumHalf
"Mudanças de requisitos são bem-

vindas, mesmo que tardiamente no
desenvolvimento. Processos ágeis se
aproveitam das mudanças visando
promover vantagem competitiva para o
cliente" (Welcome changing requirements,
even late in development. Agile processes
harness change for the customer's
competitive advantage).
Palavras-chaves: humildade, flexibilidade,

prioridade, maximização
O Segundo princípio simplificado: Estamos

sempre dispostos a mudar se for para o bem
do negócio de nosso cliente. No mundo ágil o
foco é no valor sob a ótica do cliente. Ele é o
dono do negócio e deve saber o que é melhor
para o seu negócio. Aderência a um plano
existente ou a normas estabelecidas por metodologias ou processos de desenvolvimento
não podem ser justificativa para deixarmos de atender ao nosso cliente.
Mais do que isso: as mudanças surgem normalmente de alterações no mercado ou do

aumento do conhecimento do usuário sobre o assunto, fruto do próprio desenvolvimento.
Em ambos os casos a solução é mudar e agradecer, respectivamente, por ter a
possibilidade de sempre se ajustar às demandas do mercado e por ter um cliente que
cresce junto com o projeto, que participa junto com a equipe da criação do novo produto.
Resumindo… Se o cliente solicita alguma mudança é porque ele precisa. E ele é o dono do
negócio!!! O que podemos fazer de melhor é adaptar os planos e atendê-lo. Desenvolver
um produto que faça o nosso cliente obter sucesso é o nosso objetivo. E o quanto antes
isso ocorrer melhor.
Sei que todos os princípios são muito importantes, mas acho esse especialmente
importante… ele traz a essência do espírito ágil: maximizar o valor para o cliente! Assim,
para nunca nos esquecermos do segundo princípio, proponho uma oração ágil. rsrs…
Oração do 2º Princípio
Senhor,
dai-nos humildade para reconhecermos que o
cliente entende mais do negócio do que nós e que
ele estabelece as prioridades,
dai-nos flexibilidade para entendermos que sempre
há algum requisito que pode ser substituído por
outro que maximiza o valor do produto.
É assim que você desenvolve o produto para o seu cliente? Você tem recebido com
naturalidade ou até entusiasmo as mudanças de requisitos solicitadas?
E você cliente? Quando você muda os requisitos o fornecedor ou a equipe que te atendem
gostam? Você entende que escopo variável é para o seu bem? Conte-nos como funciona
no seu projeto.
http://blog.myscrumhalf.com/2011/09/3º-principio-do-
manifesto-agil/

Software Funcionando
“Entregar software funcionando com frequência, na escala de
semanas até meses, de preferência na menor escala de tempo
possível” (Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter timescale).
O terceiro princípio do Manifesto Ágil aborda que a frequência da

entrega de software funcional deve ser alta. Isso significa que a equipe
precisa ter em mente que após um curto período de tempo vai precisar
apresentar o software planejado funcionando.
Entregar software é a forma que a equipe tem de apresentar e receber um retorno sobre o que foi feito
nas últimas semanas de trabalho. Dessa forma, a entrega na menor escala de tempo possível permite que
o trabalho seja melhor avaliado, de modo que o produto final seja o esperado pelo cliente.
No Scrum, a cada período de desenvolvimento, chamado de Sprint, um incremento do produto é

apresentado na reunião de revisão para o Product Owner. É recomendado que esse período seja curto,
algo em torno de 2 semanas a 4 semanas no máximo, fazendo com que a frequência de entrega de
software seja alta.
Sprints longas possuem um risco maior de mudança de requisitos durante o desenvolvimento, o que
dificulta o controle do projeto e de sua previsibilidade. Quanto maior o período de desenvolvimento, maior
o risco adicionado. Mudanças em variáveis como tecnologia, planos de marketing, orçamento e
necessidades do cliente podem impactar completamente no que está sendo desenvolvido e fazer com que
uma Sprint seja cancelada para a criação de uma nova. O Scrum permite cancelar a Sprint, mas
recomenda a criação de iteração pequenas, para diminuir o risco de ter esses imprevistos e aumentar as
chances de sucesso.
Uma equipe precisa encontrar a duração ideal para seu período de desenvolvimento, de modo que o risco
seja baixo, mas que também seja possível apresentar software funcionando para o cliente ao final desse
período. Ao evitar problemas como a mudança de requisitos durante o desenvolvimento, o tempo total
para finalização do produto passa a ser cada vez menor e a probabilidade de sucesso desse produto passa
a ser cada vez maior.
4º Princípio do Manifesto Ágil – Negócio e

Desenvolvedores Juntos
Postado em 12 de setembro de 2011 por Felipe Madureira, CSM.
"Conhecedores do
negócio e
desenvolvedores
devem trabalhar
juntos diariamente
durante o projeto”
(Business people and
developers must work
together daily
throughout the project).
Integração é o ponto chave do quarto princípio do manifesto ágil. A ideia é reunir

as pessoas que precisam do produto com as pessoas que o desenvolvem. Dessa
forma, o produto vai sendo construído maximizando seu valor e minimizando o
retrabalho.
Os conhecedores do negócio devem interagir com os desenvolvedores não para
supervisionar e comandar, mas para facilitar a construção do produto. Com a
convivência dia-a-dia poderão perceber o trabalho da equipe de TI e fica mais fácil
vislumbrar soluções factíveis sem que o produto final perca valor.
Por outro lado, os desenvolvedores se encarregam de entender as necessidades,
os procedimentos e a mentalidade do negócio. Com essa visão, fica mais fácil
desenvolver o produto de maneira a atender as necessidades de negócio.
É importante notar que o princípio trata sobre "trabalhar juntos diariamente".
Conforme dito, a ideia não é criar uma pressão maior em cima dos
desenvolvedores. Trabalhar juntos significa dividir problemas, arquitetar soluções,
apresentar propostas e evoluir juntos. Essa interação não deve ser apenas
superficial ou resumida a pequenas reuniões. Ela deve ser construída diariamente,
de maneira que os grupos fiquem familizariados entre si. Após algum tempo, o
grupo deverá estar uníssono em relação ao produto final.
Não é fácil reunir dois grupos diferentes e fazê-los caminhar juntos a um objetivo
comum. Mas essa prática traz inúmeros benefícios para ambos. Os clientes terão
um produto que atende as suas necessidades e com uma infra-estrutura de TI
adequada. Os desenvolvedores terão um trabalho mais focado, diminuindo o
desperdício e o retrabalho e, assim, poderão garantir mais satisfação, aceitação do
produto e melhor preço para os clientes.
5º Princípio do Manifesto Ágil – Motivação

“Construir projetos com indivíduos
motivados. Dê a eles o espaço de trabalho
e apoio de que necessitam, e confie neles
para ter o trabalho pronto” (Build projects
around motivated individuals. Give them the
environment and support they need, and trust
them to get the job done)
Este princípio trata de mais um conceito para o
qual não existe uma bala de prata: a motivação
da equipe. A única certeza que temos sobre
esse tópico é que cada indivíduo é diferente do
outro e se motiva de forma distinta. Então, como resolver essa questão? Na
verdade, não vou propor uma solução ótima. A intenção aqui é apenas identificar
pontos que podem auxiliar as empresas a terem empregados mais motivados.
O primeiro deles é justamente a confiança dos superiores no trabalho

desempenhado pela sua equipe. É preciso dar autonomia aos seus empregados
para decidir como uma determinada tarefa será desempenhada e confiar que essa
decisão trará o melhor resultado possível. Essa atitude traz para a equipe auto-
confiança, estímulo a buscar sempre realizar o melhor e, em alguns casos, soluções
mais rápidas ao cliente.
O segundo é o relacionamento entre a equipe e entre ela e seus superiores. Os

sentimentos de equipe e de colaboração devem ser garantidos entre todos e de
forma uniforme. Não se pode influenciar no nível de relacionamento pessoal de
cada um, mas promover um senso de igualdade dentro do ambiente de trabalho é
importante e faz diferença. Nenhum membro da equipe pode se sentir de fora
dela, nem mesmo o líder. É preciso que ele se sinta parte da equipe e compartilhe
com ela, sempre que possível, os rumos do projeto. Expôr o porquê das decisões e
ouvir o que a equipe tem a dizer sobre elas faz com que a mesma se comprometa
com o projeto.
O ambiente de trabalho e os recursos disponíveis também são fatores de muita

influência na motivação da equipe. Os recursos necessários para o desempenho do
trabalho devem estar disponíveis e serem de um nível adequado às necessidades
da equipe. Vale também ressaltar que o espaço de trabalho deve tornar o tempo
de trabalho mais confortável e agradável e não o contrário.
Por último, mas não menos importante, o aprendizado. As pessoas atualmente

estão em busca de trabalhos que possam também lhes trazer retorno intelectual,
ou seja, querem aprender coisas novas. Então, sempre que possível, invista em
seus empregados. Promova treinamentos, debates, palestras e etc. Mostre que
você se importa com o desenvolvimento deles.
Como foi dito anteriormente, não há uma fórmula mágica para a motivação. No
entanto, algumas práticas, como as citadas acima, podem ajudar a melhorar a
satisfação da equipe. E lembre-se: não apenas ouça o que sua equipe tem a dizer.
Realmente preste atenção às suas opiniões e sempre que possível, tome atitudes
em relação a isso.

Cara-a-Cara
Postado em 16 de setembro de 2011 por Igor Araujo,
Desenvolvedor Java Pleno da empresa Match Latam
O método mais eficiente e efetivo de transmitir

informação para a equipe de desenvolvimento está
na conversa cara-a-cara (The most efficient and
effective method of conveying information to and within a development team is face-to-face
conversation).
Boa parte do conhecimento interno à uma equipe de desenvolvimento reside

exclusivamente na cabeça dos seus membros, na forma de conhecimento tácito.
Diferentemente de como ocorre com o conhecimento explícito (que pode ser
representado em livros, apostilas, sites, etc), a transmissão e captura do
conhecimento tácito é mais complexa e exige um intenso contato interpessoal. O
sexto princípio do manifesto ágil trata da importância da conversa cara-a-cara, do
contato interpessoal na transmissão de informação pra uma equipe de
desenvolvimento.
Em muitas equipes as pessoas abrem mão da conversa cara-a-cara para utilizar

ferramentas virtuais como chats, email, intranets, etc. Embora essas formas de
comunicação tenham grande importância, elas geram margem para interpretações
superficiais e até mesmo equivocadas, o que pode gerar retrabalho no futuro.
A comunicação direta é capaz de passar confiança. Nenhum texto, por melhor que tenha sido escrito,
substitui a conversa com seus tropeços e suas imperfeições. Aliás, estas imperfeições tornam a conversa
direta mais confiável, sem "maquiagem", onde o significado do que se fala não vem somente das palavras,
mas é enriquecido pela maneira de falar e pelas expressões corporais. O contato interpessoal permite que,
através das expressões dos seus membros, a equipe perceba fatores que em geral não são expressos em
textos, como dificuldade, insegurança, auto-estima e outras sensações que podem influenciar nas tomadas
de decisões. Além disso, vale ressaltar o ganho que se tem em objetividade através do contato
interpessoal.
A reunião diária é um exemplo de conversa cara-a-cara que tem grande importância nas
equipes de desenvolvimento ágil. Numa conversa rápida e informal, a equipe troca informações sobre o
processo de desenvolvimento de forma rápida e objetiva, dizendo apenas o que é preciso ser dito naquele
momento. A prática do contato direto entre os membros da equipe mantém os mesmos em sintonia, não
apenas em relação ao processo de desenvolvimento, mas também quanto ao ponto de vista da equipe em
relação ao projeto em desenvolvimento, o que pode influenciar decisões a serem tomadas futuramente.
7º Princípio do Manifesto Ágil – Medindo o Progresso

Postado em 19 de setembro de 2011 por Ester Lima de Campos, M.Sc., CSP, CSPO e CSM.
No primeiro post relacionado

ao aniversário de 10 anos do
manifesto Ágil, publicado aqui
no blog, sugeri a leitura do
artigo escrito por Martin Fowler
e Jim Highsmith, publicado em
2001, falando a cerca do
Manifesto Ágil e seus
princípios. Apresento então, o
que eles comentaram sobre o
7º princípio do manifesto:
Software funcionando é a
principal medida de
progresso (Working software
is the primary measure of
progress). Eles disseram o seguinte:
Muitas vezes, temos visto equipes de projeto que não percebem que estão com problemas até
pouco tempo antes da entrega. Eles fizeram os requisitos no prazo, o projeto em tempo, talvez até
mesmo o código no tempo previsto, mas os testes e a integração demorou muito mais do que eles
imaginavam.
Nós favorecemos primariamente o desenvolvimento iterativo porque proporciona marcos que não
podem ser falsificados, o que dá uma medida precisa do progresso e um profundo entendimento
dos riscos envolvidos em qualquer projeto. Como Chet Hendrickson, co-autor de Extreme
Programming Installed (Addison-Wesley, 2000), observa: "Se um projeto vai falhar, eu prefiro
saber disso depois de um mês do que depois de 15."
"Software funcionando é a medida de progresso, porque não há outra

maneira de captar as sutilezas dos requisitos: Documentos e diagramas são
demasiadamente abstratos para permitir que o usuário 'chute os pneus"(*)' ,
diz Dave Thomas, co-autor de The Pragmatic Programmer (Addison-Wesley,
1999).
A metodologia ágil, com suas curtas iterações permite ao cliente ter o conhecimento de como o projeto
está evoluindo, ou não. Ao final de cada iteração é esperado um incremento do produto, ou seja, software
funcionando. O trabalho de uma iteração não pode quebrar o que já está funcionando, ao contrário, deve
agregar mais valor ao que já se tinha. Portanto, o importante é entregar ao final de cada iteração o
produto funcionando com o que foi priorizado a ser feito.
O produto sendo incrementado a cada iteração, permite ao dono do produto avaliar se o que já se tem
está de acordo com o esperado ou não. Como Martin Fowler e Jim Highsmith disseram: "Software
funcionando é a medida de progresso, porque não há outra maneira de captar as sutilezas dos
requisitos…" Nem sempre a especificação do sistema consegue expressar de forma precisa e exata o que
se espera do software. Mas ao vê-lo funcionando cria-se uma dinâmica, onde o dono do produto e a
equipe possuem base para discutir o que ficou bom e o que não ficou e o que pode ser melhorado e
acrescentado.
Soma-se também o fato de que se o projeto tem risco de insucesso, é melhor saber
o quanto antes para que medidas sejam tomadas. O objetivo do desenvolvimento
de um projeto, acima de tudo, é ser bem sucedido. Não é desejo de ninguém
nadar, nadar e morrer na praia. Mas infelizmente é possível isso acontecer e por
diversas razões. Exemplos:
 Deixar os testes para o final e perceber que o que foi implementado está falhando e
não há mais tempo e orçamento para correção.
 O sistema implementado agrega pouco valor para o usuário final.
 O sistema tem a usabilidade baixa e com isso o sistema fica sem uso ou até mesmo
nem chega a ser implantado.
 O que foi implementado não era exatamente o que o dono do produto queria.
 O sistema está com diversos bugs dificultando o seu uso.
 O sistema já não tem mais valor, pois a conjuntura atual já é outra diferente de quando
o sistema foi encomendado.
 O orçamento do projeto estourou e o que se tem implementado para lançamento não é
o que de mais valor o sistema possui.
A lista é enorme, quem trabalha com desenvolvimento de software conhece.
Portanto, se queres avaliar como anda o progresso de seu projeto, comece avaliando como está o
funcionamento de seu software. A cada iteração a equipe entrega o software funcionando com mais valor
agregado? Se sim, estás no caminho certo. Continue nesse caminho de agilidade, que todos serão
beneficiados: equipe e dono do produto, que ao final de cada iteração se sentem satisfeitos por verem o
Retorno do Investimento em forma de produto.
(*) Chutar os pneus – tradução literal para a expressão 'kick the tires' originada da tendência das pessoas
em dar um pontapé no pneu frontal do carro usado que estão avaliando para compra, para ter certeza
que não são velhos e flácidos. Pneu é uma despesa extra que o consumidor não quer assumir.
http://blog.myscrumhalf.com/2011/09/8º-principio-do-manifesto-agil-ritmo-
sustentavel/

Ritmo Sustentável
Manter o ritmo constante é necessário, embora não seja simples
mantê-lo.
O oitavo princípio do manifesto ágil afirma que: Processos ágeis promovem o desenvolvimento
sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um
ritmo constante indefinidamente (Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely) .
E, realmente, os processos ágeis promovem um desenvolvimento que é capaz de se sustentar ao longo do

tempo, desde que todos os envolvidos no projeto sejam capazes de perceber os benefícios de manter um
ritmo constante, para que se esforcem nesse sentido.
Vamos analisar como os processos ágeis promovem esse desenvolvimento sustentável:
Iterações curtas (2 a 4 semanas) e software funcionando
A equipe se compromete com uma quantidade de trabalho X, possível de ser realizada e entregue
no tempo da iteração. Mas por que a equipe se compromete com a quantidade X e não Y?
Porque com iterações curtas, após 3 ou 4 iterações, a equipe adquire o conhecimento de sua
velocidade, ou seja, a equipe sabe o quanto de trabalho é possível entregar em uma iteração. Ela
sabe que as chances de sucesso em entregar a quantidade X são muito maiores do que as chances
de entregar Y.
Velocidade constante da equipe
A equipe sabe sua velocidade e o quanto pode se comprometer a cada iteração. Mas como é
possível a equipe manter sua velocidade constante em todas as iterações?
Ter uma velocidade constante é resultado de estimativas de esforço mais precisas. Com iterações
curtas é possível avaliar ao final de cada iteração se a estimativa de esforço para cada trabalho
implementado foi acertada ou não. Esse conhecimento permite ajustar as estimativas para os
próximos trabalhos a serem estimados. Com isso, após 3 a 4 iterações, a equipe adquire o
conhecimento da relação esforço X estimativa para pontuar os trabalhos a serem
implementados.
Esforço X Estimativas
Como a equipe consegue ao longo do tempo estimar melhor o esforço para

cada trabalho a ser realizado?
Com iterações curtas o trabalho tem que ser quebrado em mais partes, onde
as partes sejam de tamanho suficiente para serem implementadas no tempo
de uma iteração. Esse processo de quebrar o trabalho macro em trabalhos
menores, favorece o melhor entendimento por parte da equipe do que deve
ser implementado, pois a descrição do trabalho passa a ser mais clara e
objetiva.
Descrições mais claras e objetivas favorecem estimativas melhores, que por

sua vez favorecem à equipe manter uma velocidade constante dentro de
uma iteração com tempo fixo. O ciclo se fecha e o ritmo constante pode ser
mantido.
Ritmo constante
A equipe sabendo estimar bem o trabalho a ser feito e conhecendo sua velocidade (o quanto ela
pode se comprometer em uma iteração), reduz a cada iteração a chance de insucesso na entrega.
E recebendo software funcionando ao final de cada iteração o dono do produto percebe o

comprometimento da equipe e passa a confiar em seu trabalho, especialmente em suas
estimativas, que segue num ritmo constante com o produto sendo incrementado ao final de cada
etapa.
A equipe também se sente mais motivada quando trabalha numa levada constante. Pois ela sabe
que o trabalho de uma iteração foi estimado e combinado para caber dentro de seu horário de
trabalho, não sendo necessário horas extras para finalizar a entrega.
Scrum promovendo o ritmo constante
No framework Scrum percebemos que tudo é favorável para mantermos o ritmo constante:
1. Inicia-se a iteração planejando o que será entregue ao final da mesma
2. Desenvolve-se o produto e diariamente a equipe se comunica na "reunião diária" do

projeto
3. Apresenta-se o produto incrementado
4. Avalia-se o processo de trabalho para adaptação do que ainda pode ser melhorado
5. Dá-se início a outra iteração.
Essa é a levada, esse é o ritmo que é mantido com timebox de 2, 3 ou 4 semanas ininterruptas de
trabalho.
Recomendo a leitura do post já publicado aqui no blog: Mantenha o Ritmo – de 9 às 5. Esse post é
finalizado com uma frase ótima:
Trabalho saudável é outra forma de ler ritmo sustentável

E você, mantém um ritmo constante de trabalho saudável?
http://blog.myscrumhalf.com/2011/09/9º-principio-do-manifesto-agil-excelencia-tecnica/
9º Princípio do Manifesto Ágil – Excelência Técnica

Postado em 23 de setembro de 2011 por Glauco Primo, Analista de Sistemas na AMRTEC
Atenção contínua à excelência

técnica e bom design aumenta a
agilidade ("Continuous attention to
technical excellence and good design
enhances agility.")
O nono princípio do manifesto agil

mostra como o acompanhamento
incremental do desenvolvimento do
produto aliado à um bom e intuitivo
design tornam o processo mais ágil.
A escolha correta da tecnologia

também é importante, mas não é necessariamente fundamental. Uma tecnologia
modular poderá fornecer soluções que se adequam a confecção do produto e ainda
nos provê uma certa facilidade em modificá-lo caso um dia se faça necessário. Não
podemos esquecer que devemos sempre manter o foco no cliente e no produto, e
se para tal a tecnologia tiver que ser modificada, isto será feito para que a
adaptação dos requisitos seja atendida.
Quando falamos de tecnologia, precisamos falar também de excelência técnica.

Mas devemos salientar que há um grande abismo entre excelência técnica e
complexidade técnica. Muitos desenvolvedores e designers fazem complexos
padrões, codificações confusas que mostram superioridade técnica, mas que em
nada acrescentam ao desenvolvimento do produto. A tecnologia escolhida, aliada
ao bom design, deve beneficiar a equipe como um todo, e toda a sua aplicação, e
não somente a alguns indivíduos. A escolha certa de frameworks que auxiliem no
desenvolvimento do produto aliada a um design claro e intuitivo podem tornar o
objetivo mais fácil de alcançar do que em projetos onde a escolha dos frameworks,
ferramentas e design patterns é indefinida ou inexistente.
A equipe deve ser capaz de monitorar a implantação correta do design e a escolha

correta das tecnologias. O projeto deve ser continuamente revisado para fazer
essas verificações. E não configura-se um problema quando a tecnologia deve ser
reavaliada, e ocasionalmente, modificada. Isto pode ser fruto, por exemplo, do
crescimento natural da aplicação.
Por fim, bom design e excelência técnica são os pontos altos do seu ambiente de
desenvolvimento. Certifique-se continuamente de estar implantando o design
corretamente e se a tecnologia está adequada aos requisitos do produto. As
escolhas que você faz devem apoiar o valor do negócio e não apenas a curiosidade
ou a satisfação de experts em tecnologia. Com o design correto e a tecnologia
correta, você está apto a desenvolver e entregar o produto mais rapidamente e
com maior qualidade.
No seu projeto funciona assim ou a tecnologia é inadequada? O design é
exagerado?
http://blog.myscrumhalf.com/2011/09/10º-principio-do-manifesto-agil-–-
simplicidade/
10º Princípio do Manifesto Ágil – Simplicidade

Postado em 26 de setembro de 2011 por Ricardo Barros, D.Sc., CSM, Diretor-Executivo GPE Ltda.
“Simplicidade – a arte de maximizar a

quantidade de trabalho não feito – é
essencial.” (Simplicity—the art of maximizing the
amount of work not done—is essential.)
Palavras-chaves: Simplicidade, valor agregado,

Manifesto Ágil, processos ágeis.
Numa rápida busca na Web encontramos boas

definições para o termo simplicidade. Peguei
algumas delas para abrir este post, por considerá-
las bastante apropriadas. Senão vejamos, simplicidade é: a qualidade daquilo que
é simples; a ausência de complicação; a naturalidade; a ausência de artifícios, de
extravagâncias e de excessos.
Há, portanto, um forte apelo minimalista em todos os métodos ágeis. Tais métodos
buscam incluir apenas “o que todo mundo precisa” e não “o que alguém precisa”,
para tornar mais fácil às equipes acrescentarem algo para atender as suas
necessidades mais específicas. “Nenhuma metodologia poderá jamais endereçar
toda a complexidade de um projeto de software moderno”.
Sob a ótica de processo, "Maximizar a quantidade de trabalho não feito" não
significa que o método ágil vá simplesmente ignorar etapas essenciais ou
tradicionais de desenvolvimento de software. Voltando às definições do início do
post, o que se pretende aqui é concentrar-se na redução ou na ausência de
complicação; na ausência de artifícios, extravagâncias e excessos , em benefício da
criação de um processo enxuto com foco na naturalidade e naquilo que é simples.
O Manifesto Ágil fala da existência dos inúmeros métodos, metodologias e
processos que podem apoiar as tarefas de desenvolvimento de software. Porém,
num Projeto Ágil é particularmente importante o uso de abordagens simples por
serem mais facilmente mudadas e/ou adaptadas. É mais fácil incluir alguma coisa
em um processo mais simples do que tirar algo de um processo muito complicado.
Dee Hock, ex-CEO da Visa International, sustenta no Manifesto Ágil que:
"Propósitos e princípios simples e claros dão origem a um comportamento
complexo e inteligente" e que "Regras e regulamentos complexos dão origem a um
comportamento elementar e estúpido". Em resumo, “Software em funcionamento
mais que documentação abrangente”, um valor básico do Manifesto Ágil.
Já pensando em produto, o interesse é manter essa visão minimalista de forma
que estejamos sempre desenvolvendo o mínimo possível, configurado como o
essencial para a existência do produto. Dessa forma, reduzimos as chances de
insucesso, atendendo ao nosso cliente através da implementação do que ele
realmente precisa e não recusará, ao mesmo tempo que minimizamos a
necessidade de retrabalho. Essa filosofia nos permite manter o foco em criar real
valor para o cliente, controlando o custo, visto que não tratamos de nada que não
seja realmente essencial, "maximizando o que falta ser feito".
A aplicação desse princípio ao processo e ao produto irá reduzir o trabalho ao

mínimo e irá permitir o foco da equipe na solução mais simples possível para criar
valor ao negócio.
Mas, vejam que implementar a agilidade nas organizações, via de regra, causa
muita discussão. Nesse sentido, temos trabalhado bastante com o objetivo de
ajudar aos nossos clientes na definição de seus processos ágeis. O que procuramos
enfatizar é se o trabalho realizado agrega ou irá agregar valor ao negócio, em
comparação às outras tarefas. Quando o valor agregado não existe ou não está
suficientemente claro, esses são fortes sintomas de complexidades e/ou excessos.
“Dando às pessoas um simples conjunto de regras e encorajando a sua

criatividade elas irão produzir resultados muito melhores do que aqueles
impostos por regulamentos complexo e rígidos”. (Dee Hock)
E você? Tem ou já teve dificuldades com a arte da simplicidade em seus projetos?

Conte-nos as suas experiências.
http://blog.myscrumhalf.com/2011/09/11º-principio-do-manifesto-agil-equipes-auto-
organizaveis/
11º Princípio do Manifesto Ágil – Equipes auto-

organizáveis
Postado em 28 de setembro de 2011 por Bruno Adam Osiek M.Sc., Diretor-Executivo GPE Ltda.
O 11 princípio por trás do Manifesto Ágil diz que "As melhores
o
arquiteturas, requisitos e designs emergem de equipes auto-

organizáveis" (The best architectures, requirements, and designs
emerge from self-organizing teams). Nesse "post" responderei a duas
perguntas:
1. O que é uma equipe auto-organizável; e
2. Por que as melhores soluções emergem dessas equipes.
O sintagma "equipe auto-organizável" foi cunhado por Takeuchi e
Nonaka e publicado em 1986 em um artigo intitulado "The New New Product Development Game" na
conceituada revista "Harvard Business Review". Esse sintagma consistia em uma das 6 características do
processo de desenvolvimento de novos produtos em empresas líderes. O estudo desse novo jogo no
processo de desenvolvimento de novos produtos foi motivado pelos resultados alcançados por empresas
como Canon, Honda e Xerox que perceberam serem necessárias velocidade e flexibilidade, em adição à
alta qualidade, baixo custo e diferenciação, para se sobressaírem em mercados competitivos.
Não é propósito desse "post" descrever sucintamente as outras 5 características, entretanto as listo:
instabilidade inerente; fases de desenvolvimento sobrepostas; “multiaprendizagem”; controle sutil; e
transferência de conhecimento organizacional.
Uma equipe adquiri uma "personalidade" auto-organizável quando é direcionada para um estado de "zero
informação", ou seja, um estado onde conhecimento e paradigmas existentes não se aplicam. Os autores
fazem uma analogia dessa "personalidade" comparando-a com a de uma empresa "start-up". Essas
equipes caracterizam-se por 3 condições:
1. Autonomia: após receberem uma missão com objetivos claramente definidos, o time está livre para
definir sua própria direção. A alta gerência limita-se a dar orientação, recursos e apoio moral;
2. Auto-transcedência: a equipe busca continuamente estender seus limites. Partem da diretriz recebida
da alta gerência, estabelecem objetivos iniciais, elevando-os constantemente durante o processo de
desenvolvimento. Ao perseguir objetivos aparentemente contraditórios a equipe supera seu "status
quo" e faz descobertas incríveis; e
3. Fertilização cruzada: uma equipe multidisciplinar, com variados padrões de comportamento, processos
conhecidos e especialização funcional conduz o desenvolvimento do novo produto. A referida
fertilização acontece na iteração entre essas pessoas. Ao compartilharem um mesmo ambiente de
trabalho o processo de transferência de conhecimento entre seus membros acontece naturalmente,
caracterizando o termo fertilização cruzada.
Portanto uma equipe auto-organizável é aquela com comportamento parecido de uma empresa "start-up",
que parte para desenvolver um novo produto com autonomia para decidir o que fazer, quando fazer e o
porquê fazer, que busca ampliar constantemente seus limites, emergindo dessa busca descobertas
incríveis, e onde pessoas com competências distintas trocam conhecimento. Mas por que as melhores
soluções emergem dessas equipes?
Sinergia, onde o total é maior do que a soma das parcelas. Uma equipe multidisciplinar funciona como um
único organismo. Suas limitações são muito menores do que a dos seus constituintes e o seu
conhecimento é muito maior do que aquele que cada indivíduo detém. Adicionalmente um especialista por
não tolerar erros em sua área de competência está muito menos propenso a desafiar o "status quo"
enquanto o não especialista está constantemente motivado a fazê-lo.
Penso que essas são as razões por trás do princípio "As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis".
http://blog.myscrumhalf.com/2011/09/12º-principio-do-manifesto-agil-retrospectiva/
Retrospectiva
Ao longo desse mês todos os post do blog do ScrumHalf foram

dedicados aos princípios do Manifesto Ágil em comemoração e
homenagem aos 10 anos que já se passaram desde sua
elaboração.
Fechamos hoje esse ciclo de comemoração, falando sobre o 12 o

e último princípio do
Manifesto Ágil: Em intervalos regulares, a equipe reflete sobre como se tornar mais eficiente,
depois aprimora e ajusta seu comportamento em conformidade (At regular intervals, the team
reflects on how to become more effective, then tunes and adjusts its behavior accordingly).
Nada mais justo! Já que estamos no final desse ciclo de comemoração fecharmos
falando sobre retrospectiva.
Em intervalos regulares é importante que seja feita uma reflexão de tudo que aconteceu para
aprimoramento e ajuste do processo de trabalho. Adotar uma metodologia ágil não é trivial, cada projeto
terá suas barreiras para implantação e necessidade de adaptação para adequação, portanto é a reflexão
que permitirá que seja dado o ajuste necessário para melhoria do processo.
Falando em termos de Scrum, é fundamental que ao final de cada sprint além de

software funcionando a equipe avalie o que correu bem ao longo da sprint
finalizada e quais são os pontos que devem ser focados para melhoria na próxima
sprint. Fazer uma retrospectiva ao final de cada sprint contribui para que o projeto
mantenha o ritmo sustentável, pois caso contrário os problemas acabam por
sucumbir qualquer esforço na tentativa de ser ágil. É preciso que o processo seja
ajustado em conformidade com a cultura do ambiente de trabalho para prover
meios adequados e que facilitem a execução do trabalho pela equipe.
Os três pilares que sustentam o Scrum são: Transparência, Inspeção e Adaptação.

E a reunião de retrospectiva fortalece esses três pilares ao final de cada iteração,
pois é preciso transparência para inspecionar o que deve ser adaptado.
Fazendo uma retrospectiva desse mês dedicado a comemoração dos 10 anos do

Manifesto Ágil, podemos dizer que o trabalho de preparo dos posts que foram
publicados aqui no blog por cada membro da equipe de desenvolvimento da GPE
só agregou benefícios, fortalecendo ainda mais os conceitos e valores do
desenvolvimento ágil e também provendo aos nossos seguidores um material
completo de estudo sobre o Manifesto Ágil e seus princípios. Agora vai ser difícil
não adotar essa metodologia, não é não?!
http://blog.myscrumhalf.com/2011/10/do-bom-para-o-otimo-scrum/
Do bom para o ótimo Scrum
Postado em 3 de outubro de 2011 por Cláudio Pires, CSM, Consultor ProMove
Estabelecendo as bases
Não pretendo, nesse post, debater os

agrupamentos administrativos de
pessoas ou estágios para a
construção de times…formação,
conflito, normalização, desempenho.
Meu foco são os times aos quais uma
empresa recorre para tratar seus
projetos de maior complexidade,
urgência e riscos… os reais times de alta performance.
Fina estampa
Entretanto, na "reinvenção nossa de cada dia", já é comum esbarrarmos com

desenvolvedores auto-entitulados "ninja" ou "jedi", em substituição aos tradicionais
termos de analista de sistemas ou engenheiro de software. Não surpreende que
muitos adotem o Scrum numa simples leitura do Scrum Guide… achando-se
professores daquilo que ainda não vivenciaram.
Um rumo e uma direção
Assim, acredito no real valor das pessoas e dos processos que nos forçam para
longe das zonas de conforto, das triviais resistências e modismos… do "ScrumBut".
Sorry, Jurgen!
Somente com a aderência às cerimônias, papeis e artefatos do Scrum é que se

estabelecem os inquestionáveis diferenciais de produtividade, confiança e
comunicação! Quem viveu, sabe.
A ignorância é uma benção
Eu achava que fazia um ótimo Scrum… tirei 6 na primeira avaliação do Nokia Test. Recorri às avaliações
do restante do time… ainda 6 em consenso. Repensamos nossa práticas, percebemos melhorias e
atingimos o marco para uma nova avaliação… nota 7!
Foi impressionante perceber como um simples teste pode ser tão revelador ao evidenciar deficiências e
oportunidades…lições aprendidas na veia!
Convite
Entenda os checklists (p.ex.: Bafômetro Ágil Parte 1) e busque os níveis mais altos dos modelos de
maturidade, mas aceite que, nesse ponto, as melhorias são contínuas… de verdade!
Como disse um novo amigo, "o prazer do professor é quando o aluno tira 10 numa prova bem difícil"!
Desse espírito é que nascem as melhores relações de networking profissional, quando o processo é
"institucionalizado" na cabeça das pessoas por escolha própria e quando o time de alta performance passa
a ser reconhecido como um valoroso "ativo organizacional"… prata da casa!
http://blog.myscrumhalf.com/2012/02/o-que-e-sprint-–-faq-scrum/
O que é Sprint? – FAQ Scrum
Continuando com a série FAQ Scrum, no post de hoje falaremos sobre a Sprint. Veremos o que é a Sprint,
como é criada e o que é feito antes, durante e depois de uma Sprint.
Na metodologia Scrum, o processo de desenvolvimento é dividido em ciclos regulares ao longo do tempo.

Sprint é cada um destes ciclos. De acordo com a definição que podemos encontrar no post Aprendendo os
termos Scrum – Glossário, temos que a Sprint “Representa um ciclo de trabalho no Scrum. Esse ciclo pode
ser de 2 semanas, 3 ou 4 semanas, que é o Timebox das Sprints. As Sprints devem ter sempre a mesma
duração.” A cada Sprint um conjunto de requisitos é implementado, tendo como resultado um incremento
do produto que está sendo desenvolvido.
Na figura abaixo temos um esquema representando a dinâmica de uma Sprint.

Antes de começar a Sprint – Planejamento
Primeiramente, antes de iniciar a Sprint, é preciso definir que histórias do Product Backlog serão
implementadas no ciclo que está para ser iniciado. Para isso as histórias no Product Backlog devem estar
em uma ordem de prioridade definida pelo PO e devem estar estimadas pela equipe de desenvolvimento.
Uma vez que o Product Backlog esteja priorizado e estimado, a equipe de desenvolvimento realiza uma
reunião de planejamento(Planejamento 1) para selecionar as histórias que serão incluídas na Sprint de
modo a acomodá-las dentro do tempo da Sprint e respeitando a priorização definida pelo PO. Este
conjunto de histórias incluídas na Sprint é chamado de Sprint Backlog.
Uma vez definido o Sprint Backlog, a Sprint pode então ser iniciada! Neste momento a equipe de
desenvolvimento parte para um segundo planejamento(Planejamento 2), no qual cada história é
subdividida em tarefas menores a fim de se ter um maior controle sobre o desenvolvimento de cada
história individualmente.
Agora é mãos à obra! Temos as histórias a serem implementadas e as tarefas a serem realizadas para a
implementação de cada história.
Execução da Sprint
Durante a execução da Sprint, a equipe executa as tarefas para a realização das histórias seguindo a
ordem de prioridade definida pelo PO. Ao longo da Sprint a equipe pode utilizar o gráfico de Burndown
para ter noção se está atrasada ou adiantada em relação ao objetivo da Sprint e tomar providências se for
necessário.
Diariamente a equipe de desenvolvimento se reúne para falar o que foi feito no dia anterior, quais são
seus impedimentos e o que será feito no dia atual. Caso hajam impedimentos, o SM busca resolvê-lo o
mais rápido possível para que a equipe possa dar prosseguimento aos trabalhos da Sprint. O SM também
participa desta reunião diária se for possível.
Recomenda-se que não haja qualquer alteração no tempo da Sprint nem nas tarefas do Sprint Backlog.
Após a Sprint – Reunião de Revisão e Reunião de Retrospectiva
Ao final da Sprint é realizada a reunião de Revisão. Nesta reunião, a equipe apresenta as histórias
implementadas na Sprint, mostrando o seu resultado para o PO. O PO então analisa a resolução de cada
história junto à equipe de desenvolvimento e decide se aprova ou não cada uma delas. As histórias
reprovadas retornam para o Product Backlog e ficam disponíveis para serem incluídas em uma nova
Sprint. Nesta reunião, aproveitando que PO e equipe estão juntos, também podem ser discutidas histórias
do Product Backlog que não tenham sido bem compreendidas pela equipe de desenvolvimento.
Após a reunião de revisão a equipe de desenvolvimento junto ao SM fazem a reunião de Retrospectiva.

Nesta reunião a equipe compartilha a sua opinião e reflete sobre o que funcionou e o que não funcionou
ao longo da Sprint. É feita uma discussão sobre os pontos positivos e negativos da Sprint, com o objetivo
de reforçar o que foi bom e levantar soluções para o que foi ruim. Assim, a cada Sprint a equipe vai
aprendendo e melhorando o seu processo de desenvolvimento.
Aproveite e dê uma passada na Universidade Scrum e assista ao vídeo sobre o Trabalho na Sprint
http://blog.myscrumhalf.com/2011/10/experiencia-pratica-de-scrum-construindo-maquete-
3d/
Experiência prática de Scrum: Construindo Maquete 3D

Postado em 7 de outubro de 2011 por Geraldo Xexéo, D.Sc., CSM, Professor do PESC/COPPE/UFRJ e do
DCC/IM/UFRJ, membro do Conselho Técnico da GPE.
Uma questão importante em cursos de SCRUM é como
fazer uma simulação interessante e que permita aos alunos
aprender como o método funciona. Apesar da grande parte
dos alunos que tenho ensinado trabalhar na área de
desenvolvimento de software, é muito difícil aplicar o
SCRUM em um projeto de software durante um curso de
poucas horas.
Quando fiz meu curso para a certificação CSM o exercício

era fazer um cartaz de convite para um evento. Era um bom exercício, porém como o cartaz é
basicamente um objeto único, ele tem problemas na hora de permitir o paralelismo. Após usar esse
exercício em algumas aulas, mesmo com excelente resultado na dinâmica e na reação dos alunos,
comecei procurar um exercício mais parecido com algumas necessidades que eu via como necessárias:
 Cada grupo deveria possuir um P.O. que tivesse alguma liberdade na decisão do que fazer. No
exercício do pôster, como eu trabalhei, a liberdade era muito pequena, para permitir que o instrutor
tivesse uma boa definição do conceito de valor.
 O valor de cada parte deveria ficar bem claro.
 Cada parte deveria poder ser feita aos poucos. Outro defeito do pôster é que cada parte basicamente
tem que ser feita inteiramente ou não ser feita.
 Deveria ser possível a criação de histórias e tarefas.
 O trabalho deveria poder ser paralelizável.
 Deveria ser divertido.
Pesquisando um pouco eu encontrei algo que me pareceu um ótimo exemplo: construir uma cidade de
Lego®. Ótimo exercício, divertido e trazendo a criatividade, porém com um grande defeito: muito caro!
Como conseguir dezenas de peças de Lego®, suficiente para exigências de várias cidades, aos preços que
pagamos no Brasil por um caixa desse brinquedo? Pensei mesmo em "assaltar" a caixa de Lego® de meu
filho, mas nem assim teria tantas peças quanto necessário para vários grupos.
Nesse momento entrou o famoso jeitinho. Baseado no mesmo exercício eu comprei um "kit de
criatividade": papel de desenho branco, papel "criativo" colorido, papel cartão (um pouco mais duro), cola,
tesoura, régua, lápis preto, borracha, apontador e lápis de cor. Além do "kit de criatividade", ainda
coloquei post-its (genéricos, que são mais baratos) e uma pasta para guardar tudo facilmente. Custo total:
R$ 65,00!
O desafio: construir uma maquete 3D de uma cidade.

Como um dos meus problemas com o exercício do pôster era o excesso de limitações, fiz um exercício
sem muitos parâmetros fixos, os POs receberam apenas uma descrição do que eu desejava da maquete
de uma cidade:
 Uma folha de papel A4 era o terreno que podia ser desenhado para algumas características,
 Os prédios deveriam ser 3D, e
 Deveriam existir pelo menos 3 prédios públicos e 1 prédio residencial no final do projeto.
O resultado do exercício uma ótima sessão de treinamento, onde o melhor elogio foi dado por um aluno:
"Durante a aula eu não entendi muito bem como funcionava. O exercício foi essencial".
Como lição da primeira experiência, pude observar:
 Foi muito mais divertido para os grupos fazer a maquete do que o pôster.
 O paralelismo funcionou bem.
 Soluções criativas apareceram e foram copiadas. Um grupo usou papel cinza para fazer as ruas em
paralelo, sem necessidade de desenhar no "terreno". Vários grupos usaram papel vermelho para um
prédio de bombeiros. Um grupo criou árvores (em paralelo) e fez um parque em 3D.
 O exercício foi dado no final, talvez fosse melhor dar o exercício aos poucos, para que os alunos
tivessem mais interação durante a aula, mas isso diminuiria o impacto do desafio. Quando receberam
a instrução de fazer a maquete eles ficaram surpresos e aceitaram bem o desafio. A perda da surpresa
pode ser um fator de desmotivação.
 O tempo curto que deixei para o exercício, só 75 minutos no final da aula, prejudicou principalmente o
discussão crítica do que está sendo feito.
 Duas sprints de com 25 minutos de execução são suficientes para construir a maioria dos exemplos
necessários. Mas não tivemos tempo de fazer a retrospectiva de forma "oficial" ou um "scrum diário".
Trabalhamos mais no planejamento e review.
 Um grupo planejou muito e fez pouco no primeiro sprint. Isso também acontecia no exercício do
pôster e é facilmente corrigido na segunda sprint.
 Um grupo adicionou pouco valor na segunda sprint e chamei a atenção disso.
 Ao fazer a revisão ela deve ser feita em relação ao planejado e não em relação a beleza do modelo.
 Os grupos tendem a "roubar", fazer sem executar a reunião de planejamento e o product backlog e
sprint backlog. É importante vigiar e exigir tanto o product backlog quanto o sprint backlog antes que
eles comecem a trabalhar.
 Quando um grupo "roubou" eu mudei o projeto deles, pedindo um aeroporto e não uma cidade. Eles
tiveram que jogar fora o trabalho anterior, que tinha sido feito sem planejamento, e começar de novo.
No final fizeram um belo trabalho, inclusive com melhorias no modelo do avião na segunda sprint.
 Quando o grupo não consegue entregar uma história deve se mostrar como poderiam entregar
histórias se tivessem dividido a história incompleta em histórias menores. Por exemplo, um prédio
pode ser dividido em "corpo do prédio" e "telhado do prédio".
 O kit de criatividade apresenta quantidade limitada de recursos, o que obriga os scrumasters a
negociar itens como tesouras e réguas, dando um exemplo de tratar impedimentos.
 Um grupo conseguiu calcular a velocidade do primeiro sprint para planejar o segundo. Tenho que
lembrar de chamar a atenção de todos para isso.
Como só tenho 6 horas para fazer essa introdução ao Scrum, Na próxima aplicação vou guardar mais
tempo e fazer todas as reuniões possíveis. Para isso terei que cortar algum material teórico, mas está
claro que a prática deixa tudo muito mais claro.
Tudo certamente ficaria melhor se eu tivesse como fazer os alunos usarem o ScrumHalf nessa aula!
Alguém pode contar outras experiências de treinamento?

http://blog.myscrumhalf.com/
2011/10/user-stories-o-que-sao-
como-usar/
User Stories – O que

são? Como Usar?
Podemos definir e organizar os requisitos

de um sistema utilizando User Stories
(histórias de usuário). User Stories são artefatos de desenvolvimento utilizados em sistemas geridos
segundo metodologias ágeis.
Muitas perguntas são levantadas na hora de escrever User Stories, por exemplo:
* User Stories são iguais Casos de Uso?
* Como descrevo minhas User Stories?
* Que tipo de informações podemos inserir nas User Stories?
* De quem e pra quem são feitas?
As respostas para essas perguntas são amplamente discutidas na comunidade Scrum e vamos tentar
analisá-las abaixo.
Casos de Uso e User Stories são similares, como é apresentado por Martin Fowler em seu texto User
Cases and User Stories. Ambos são utilizados para organizar requisitos. Porém, enquanto Casos de Uso
descrevem ações de interação segundo uma narrativa impessoal entre o usuário e o sistema, User Stories
focam nos objetivos do usuário e como o sitema alcança esses objetivos.
User Stories fracionam os requisitos para que seja possível (e mais fácil) estimar o esforço para realizar
aquele objetivo. Resumindo, User Stories são descrições simples que descrevem uma funcionalidade e é
recomendável que sejam escritas segundo o ponto de vista do usuário.
User Stories devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um simples e pequeno
cartão (conhecidos como User Index Cards). Se não há espaço para escrevê-la em um cartão é porquê
devemos refiná-la mais, e as dividir em outras User Stories.
Podemos construir User Stories como mostrado na figura abaixo. Especificando o

ator, a ação e a funcionalidade desejada.
Ator – O proprietário da User Story. De forma simplista é o usuário, o interessado naquela funcionalidade.
Mas é recomendado descrever de forma específica quem é o ator para ser mais fácil identificar o contexto
da história dentro do sistema.
Ação – É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo dentro do
sistema.
Funcionalidade – É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de
executar a ação segundo a ótica do ator. Também pode ser visto como justificativa.
Alguns aspectos importantes podem ser notados no uso de User Stories:
 Validar se a funcionalidade é realmente necessária antes de incluí-la
 Análise das necessidades reais do usuário
 Ajuda a priorizar o que deve ser feito
 É mais fácil estimar o esforço que será necessário para implementar a funcionalidade
O interessante no uso de User Stories é o foco nas necessidades reais e práticas do usuário.
Imagine um sistema de aluguel de filmes pela internet, onde uma das funcionalidades do sistema é
visualizar os filmes disponíveis para locação. Então a User Story para esse caso seria:
Agora, imagine o seguinte: além de visualizar os filmes disponíveis para locação, seria interessante que o
cliente pudesse reservar também o filme desejado. Nesse caso a User Story seria:
A pergunta é: será que essa User Story é realmente útil agora de forma a atender ao que os usuários
desejam mais nesse momento?
Perguntas como essa surgem constantemente no processo de planejamento das sprints e cabe ao PO
pensar sobre a necessidade de implementar ou não tal funcionalidade nesse momento.
O cenário descrito acima apresentou como criar User Stories, mas quais são as
vantagens em utilizar User Stories? Na próxima sessão segunda daremos
continuidade ao assunto – "User Story"- falando também sobre como escrever os
critérios de aceitação das User Stories.
http://blog.myscrumhalf.com/2011/11/historias-e-o-product-backlog-faq-scrum/
Histórias e o Product Backlog –

FAQ Scrum
Dando continuidade a série FAQ Scrum, hoje falaremos de

Histórias e Product Backlog. No post Aprendendo os termos
Scrum – Glossário, nós já aprendemos a definição desses dois
termos, mas não nos custa relembrar:
“Histórias – São itens do Product Backlog que representam parte

do produto a ser implementado. As Histórias devem conter uma descrição detalhada do que deve ser
implementado.”
“Product Backlog – Lista de itens, ou Histórias, que devem ser implementados para a criação do produto
desejado ou desenvolvimento do projeto.”
Ok, mas como funciona essa coisa de História e Product Backlog na realidade?
Vamos começar pelas Histórias:
Como dito acima, elas representam uma parte do produto a ser implementado, uma necessidade que foi
levantada e que o Product Owner (PO)* do projeto deseja que seja implementada. Geralmente, as
Histórias são levantadas durante uma reunião entre equipe, Scrum Master e PO e não existe nenhum nível
de granularidade pré-estabelecido para elas. Uma história pode descrever desde a alteração de um label
na tela até a criação de uma nova funcionalidade do sistema. O importante é verificar se o que deve ser
implementado ao realizar aquela história foi realmente compreendido pela equipe.
É possível que em algumas Histórias a equipe sinta a necessidade de dividir o trabalho previsto para que
se tenha maior controle do que deve ser feito. Não há problemas. Durante a reunião, a equipe pode e
deve sugerir ao PO que determinada história seja dividida em várias ou tenha sua descrição alterada. A
função da equipe não é apenas desenvolver a funcionalidade desejada, mas também encontrar, junto com
o PO, a melhor maneira de concluir as Histórias levantadas.
Agora vamos falar do Product Backlog:
Todas as Histórias levantadas pelo PO compõem o Product Backlog. Nele estão listadas todas as
necessidades já identificadas para o projeto, ordenadas por prioridade pelo PO. É importante ressaltar que
o Product Backlog nunca está completo, ele se atualiza a medida que o desenvolvimento do projeto vai
avançando e novas necessidades são encontradas. A cada iteração do projeto, é possível que novas
Histórias entrem no Product Backlog e novas prioridades sejam estabelecidas.
Antes de iniciar o desenvolvimento, cada história deve ser dividida em tarefas. Cada tarefa deve
representar um passo, que deve ser concluído em até 1 dia de trabalho, para finalizar a funcionalidade
contemplada naquela história. Um ponto importante a ser considerado ao estabelecer as tarefas de uma
história é que, idealmente, toda a equipe deve trabalhar no desenvolvimento dela. Dessa forma, todos
podem compartilhar o conhecimento relacionado àquela história e a produtividade da equipe também
aumenta.
E na sua equipe? Os conceitos de História e Product Backlog já estão bem compreendidos? Aproveite para
assistir ao tutorial sobre Product Backlog da Universidade Scrum.
* Para saber mais sobre os papéis do Scrum, veja o post Quais são os papéis do Scrum? – FAQ Scrum
http://blog.myscrumhalf.com/2011/10/vantagens-do-controle-de-versao-no-
desenvolvimento-agil/
Vantagens do controle de versão no desenvolvimento

ágil
Postado em 5 de outubro de 2011 por Igor Araujo, Desenvolvedor Java Pleno da empresa Match Latam
Os sistemas de controle de
versão, comumente utilizados
no desenvolvimento de
software, são ferramentas cujo
objetivo é gerenciar as
diferentes versões dos
documentos produzidos ao
longo do processo de
desenvolvimento.
Atuando como uma espécie de

“máquina do tempo” dos
desenvolvedores, as ferramentas de controle de versão permitem retornar múltiplos arquivos de múltiplos
autores a qualquer versão anterior.
Dentre as características oferecidas pelas ferramentas de controle de versão destacarei neste post
algumas das que conferem vantagem aos projetos desenvolvidos através de métodos ágeis.
Primeiramente, destaco o suporte à colaboração.
As ferramentas de controle de versão permitem que vários desenvolvedores trabalhem em paralelo

sobre os mesmos arquivos sem que um sobrescreva o código de outro, facilitando o trabalho em
equipe. Todo o gerenciamento do que foi alterado em cada arquivo por cada um dos usuários fica
a cargo da ferramenta de controle de versão.
Isto confere maior agilidade ao processo de desenvolvimento, uma vez que vários usuários podem
trabalhar em uma mesma funcionalidade ao mesmo tempo, pois a responsabilidade de realizar o
“merge” entre o que foi feito por cada usuário em um documento é feito pela ferramenta de
controle de versão.
O suporte à marcação (criação de tags) é também uma vantagem oferecida pelas ferramentas
de controle de versão.
A maioria das implementações permite a marcação dos documentos que estão em uma versão
estável, de forma que este pode ser resgatado no futuro. Enquanto em processos convencionais
de desenvolvimento a entrega acontece em etapas avançadas do processo de desenvolvimento,
as metodologias ágeis buscam a capacidade de implantar uma nova versão do software ao final de
cada iteração. Portanto é preciso que a cada iteração a equipe de desenvolvimento esteja
preparada para, em caso de algum problema com uma versão recém implantada, retorná-la para a
última versão estável. Este procedimento é facilitado pelo recurso de marcação das ferramentas de
controle de versão.
Além da agilidade conferida pelo fato de vários desenvolvedores poderem manipular um mesmo
arquivo concomitantemente sem perder informações (primeira vantagem), o uso do controle de
versão confere uma maior segurança ao desenvolvimento, uma vez que mantém um histórico com
as versões estáveis do software desenvolvido.
O controle de versão traz a possibilidade de se rastrear todo o processo de evolução dos

arquivos por elas manipulados.
Ao criar uma nova versão de um documento, as ferramentas de controle de versão tratam de

identificá-la unicamente, de forma que esta versão possa ser recuperada a qualquer momento.
Além de atribuir um identificador, os softwares de controle de versão também armazenam o
responsável pela criação da nova versão e a data em que ela foi criada. Opcionalmente, ao criar
uma nova versão de um documento, o usuário pode adicionar um comentário, descrevendo o que
foi alterado em relação à versão anterior do arquivo.
Em projetos ágeis é comum que vários membros da equipe de desenvolvimento trabalhem

paralelamente em cima de uma mesma funcionalidade. Como consequência, é comum, também,
que realizem alterações sobre os mesmos documentos, o que pode gerar conflitos entre as suas
versões. Assim a possibilidade de rastrear o que foi alterado em cada versão do documento figura
como uma vantagem, uma vez que permite saber o que foi alterado, quem alterou e quando
alterou. Estas informações auxiliam na resolução dos conflitos e permitem que se faça uma análise
da evolução do documento em questão ao longo do tempo.
Este post abordou algumas das muitas vantagens oferecidas pelas ferramentas de controle de versão.
Vale lembrar que para usufruir de tais vantagens é preciso que estas ferramentas sejam utilizadas de
maneira correta. Mas o que é usar o controle de versão de maneira correta? Algumas questões como o
controle de acesso, layout do repositório, dentre outras devem ser abordadas com cuidado para que o uso
do controle de versão não seja fonte de problemas no processo de desenvolvimento.
Buscaremos em futuros posts abordar estas e outras questões relacionadas às boas práticas a serem
adotadas para um controle de versão eficiente.
http://blog.myscrumhalf.com/2011/10/testes-de-aceitacao-no-desenvolvimento-agil/
Testes de aceitação no desenvolvimento ágil

Postado em 13 de outubro de 2011 por Felipe Madureira, CSM.
O post de hoje irá tratar sobre

testes de aceitação (TDA), um
dos tipos de testes usados
para validar e verificar se o
produto desenvolvido está de
acordo com o que foi
estabelecido nos requisitos.
Esses testes são construídos a
partir de situações de uso do
sistema, estabelecendo valores
de entrada, saída, tempo de
resposta, etc. O objetivo do TDA é garantir que o sistema seja capaz de executar a funcionalidade
acordada da forma desejada, e, consequentemente, garantir a qualidade do produto em desenvolvimento.
Os testes de aceitação envolvem testar uma funcionalidade do início ao fim, dando entradas para o
sistema e observando o comportamento de saída. O resultado deve estar compatível com os requisitos do
sistema em termos de tempo de resposta, validade do resultado, facilidade de uso e qualquer outro
critério que o cliente tenha estabelecido.
É possível executar testes de aceitação de forma automatizada. Nós, utilizamos o

JUnit e o Selenium para automatizar nossos testes. Dessa forma, a reprodução dos
testes pode ser feita automaticamente, sem a necessidade de uma pessoa executar
todos os passos manualmente a cada vez que tiver que retestar uma
funcionalidade. Vale lembrar que, automatizados ou não, os testes de aceitação
devem ser baseados em casos de testes elaborados pelo cliente, porque só o dono
do negócio pode decidir se a funcionalidade está adequada para seu uso.
O TDA envolve um tipo de teste chamado "Teste de caixa preta", onde a importância do teste se encontra
apenas no resultado obtido. Se o sistema apresentar a resposta esperada para uma determinada entrada,
aquela parte do software pode ser considerada válida. É importante ressaltar que tão importante quanto
testar a operação normal é testar também as situações em que o sistema deverá apresentar erro ou
impedir uma ação do usuário. Se o produto responde corretamente a uma entrada válida não significa que
ele irá responder negativamente a um valor incorreto. Cabe ao dono do negócio priorizar quais as
operações que são mais importantes no sistema e quais as possibilidades de entrada que serão testadas.
Em métodos ágeis, utilizamos esse tipo de teste a cada porção de software

funcionando entregue ao cliente. Dessa forma, podemos garantir que todas as
funcionalidades entregues estão de acordo com a solicitação do cliente e o
retrabalho é evitado. Uma vez que o desenvolvimento de uma User Story é
finalizado, ela estará em pleno acordo com as funcionalidades que foram
solicitadas.
Testar seu produto permite verificar e validar se o desenvolvimento do mesmo está

convergindo para o idealizado pelo cliente. Quanto antes as divergências forem
encontradas, mais barato é corrigi-las. O teste de aceitação é particularmente
importante porque sua execução é feita na própria interface do software, validando
o sistema para o cliente da maneira que ele será usado.
http://blog.myscrumhalf.com/2011/10/criterios-de-aceitacao-das-user-stories/
Critérios de Aceitação das User Stories
Os Critérios de Aceitação são representados por uma

lista de itens de negócio que expressam formas de usar a
funcionalidade implementada em uma História. O objetivo dessa lista é
validar se a História foi implementada de acordo com o que o PO queria,
por isso o nome Critério de Aceitação.
Ao final da sprint, na reunião de Revisão, a equipe apresentará História

a História para o PO e com base nos Critérios de
Aceitação, que foram definidos para cada História, que
será realizada a apresentação e validação quanto ao funcionamento da mesma.
Aceitos os critérios estabelecidos a História já está em parte aprovada, faltando

apenas validar se a mesma também atende a definição de História Pronta (mas
isso é assunto para um próximo post…).
Agora, como surgem e como escrevemos os Critérios de Aceitação de uma

História?
Esses Critérios (itens) surgem de perguntas que a equipe faz ao PO, no momento em que a História está
sendo descrita, na busca por obter mais detalhes do que deve ser implementado.
Vejamos a História descrita abaixo:
Algumas perguntas podem ser feitas ao PO, quanto a usabilidade dessa funcionalidade, como por
exemplo:
 Como o usuário fará essa busca no sistema?
 Como o usuário deseja que seja apresentada a informação solicitada?
 O que deve ser feito se o livro não for encontrado?

Para o exemplo acima possíveis critérios de aceitação seriam:
Como base nos Critérios de Aceitação a equipe deve escrever os Testes de aceitação,
também abordado no post “Testes de Aceitação no desenvolvimeno ágil” semana passada aqui no blog do
ScrumHalf.
Ao final do desenvolvimento são esses testes que dirão se a funcionalidade foi

implementada de forma a ser aceita ou não pelo PO. Se os testes forem criados com uso de
ferramentas específicas para automatização da execução dos mesmos, isso garantirá maior agilidade e
qualidade do produto.
Incluir os critérios de aceitação como parte da história só vem a agregar vantagens, como:
1. Prover material para a equipe pensar em como uma funcionalidade será executada pelo ponto de vista
do usuário.
2. Eliminar ambiguidades quanto aos requisitos.
3. Confirmar que a história está completa e funcionando.
4. Garantir maior satisfação do usuário.
Resumindo… escrever Histórias, é muito mais do que apenas descrevê-las. É também especificar a
usabilidade da mesma, com base nos Critérios de Aceitação.
http://blog.myscrumhalf.com/2011/10/bdd-–-foco-no-comportamento-do-sistema/
BDD – Foco no comportamento do sistema

Postado em 20 de outubro de 2011 por Paula Nascimento, CSM, Scrum Master, Analista de Sistemas em SERPRO
BDD – Behaviour Driven Development – é uma

técnica ágil que está bastante relacionada aos
posts publicados na semana passada: User
Stories – O Que São? Como Usar? e Critérios de
Aceitação das User Stories.
Segundo Dan North, seu criador, BDD é uma

evolução de outra técnica ágil chamada TDD –
Test Driven Development. Ela foi criada com o
objetivo de facilitar o entendimento de TDD para
aqueles que estão começando a lidar com o desenvolvimento dirigido por testes e, ao meu ver, acabou se
tornando mais eficaz que a técnica que a originou. Isso porque BDD é uma técnica cujo foco está em
avaliar o comportamento do sistema e não em gerar testes apenas. Esta nova visão faz com que os testes
sejam apenas uma consequência necessária para garantir que o seu sistema esteja de acordo com as user
stories e com os critérios de avaliação levantados pelo PO.
O primeiro benefício de BDD para o desenvolvimento ágil está em direcionar os programadores na criação
dos testes. Não existirão mais dúvidas como: Como devo chamar o teste criado? O que devo testar? Até
quando devo testar?. O foco agora está em testar o que realmente importa para o usuário e verificar que
o que ele espera do sistema esteja de fato acontecendo. Não será mais necessário buscar o que deve ser
testado, as user stories e os critérios de avaliação dirão isso para os desenvolvedores.
Outro ponto positivo é que seus testes estarão focados no que realmente tem valor para o usuário e,
portanto, será mais fácil convencer o PO de que o tempo utilizado na criação de testes não é tempo
perdido. A qualidade do seu sistema melhorará e impactará diretamente na experiência do usuário, o que,
sem dúvida, será bastante valorizado pelo PO.
O processo de BDD é simples e se assemelha bastante ao fluxo de TDD. A partir da user story, como a
apresentada abaixo, é possível identificar o papel que executará uma funcionalidade em busca de um
resultado.
A partir daí, o próximo passo é criar o teste que garantirá que o código implementado está de acordo com
o que foi especificado. Lembrem-se que o foco deve estar no comportamento, então nada além do que
está previsto na user story e nos critérios de aceitação deve ser levado em consideração. Com os testes
criados, é o momento de codificar a funcionalidade de forma que ela passe no teste gerado previamente.
Vale também ressaltar que esses testes não devem ser esquecidos em algum lugar do projeto. A cada
novo release é necessário rodar todos os testes para verificar se as funcionalidades continuam
funcionando corretamente. Em alguns casos, a especificação pode mudar. Caso isso aconteça, o teste
também deve ser atualizado.
Esse processo pode ser apoiado por frameworks como o JBehave. Focado para desenvolvimento de BDD
em Java, ele permite criar os testes a partir da descrição textual do que deve ser testado. No entanto,
nada impede que os testes sejam criados com o que já conhecemos, como o JUnit. É apenas uma questão
de opção da equipe.
No fim, a pergunta que fica é: BDD resolverá todos os meus problemas? Não. É preciso avaliar se outras
técnicas de testes já conhecidas se adequam melhor aos seus projetos. Em alguns casos, será necessário
criar testes mais focados na implementação e na verificação de determinada parte do código. No entanto,
acredito que BDD pode sim agregar mais valor ao produto e evidenciar para o PO as melhorias que as
equipes já sabem que os testes trazem. Além disso, ele pode tornar o desenvolvimento dirigido por testes
mais amigável para os desenvolvedores.
Referências: Bevahiour Driven Development

http://blog.myscrumhalf.com/2011/08/os-9-principios-de-agile-testing/
Os 9 princípios de Agile Testing

Postado em 30 de agosto de 2011 por Paula Nascimento, CSM, Scrum Master, Analista de Sistemas em SERPRO
Agile Testing, em poucas palavras, é

uma prática de testes de software que
segue os princípios ágeis para entregar
ao usuário um produto com maior
qualidade. A maior diferença entre
Agile Testing e os métodos tradicionais
é apenas filosófica: os testes deixam
de ser uma forma de evitar a entrega de um sistema ruim para passarem a fazer
parte de uma política de desenvolver um bom produto desde o início do projeto.
Neste post, apresentamos os 9 princípios de Agile Testing.
O primeiro deles diz que um processo de desenvolvimento que inclui testes resulta em
um produto melhor. Os testes têm que ser vistos como uma forma de criar um produto de
qualidade desde o início e não apenas como uma forma de prevenir bugs na hora que o
sistema é entregue ao cliente. Visando apoiar esta estratégia, o segundo princípio diz que os
testes não podem ser vistos como apenas uma fase do projeto, eles devem ser
considerados requisito para a conclusão de cada história da sprint.
O terceiro princípio diz que todos testam, não apenas o especialista em testes. Já o
quarto princípio diz que uma história só é considerada pronta se forem realizados os
testes necessários. Esses dois princípios se relacionam entre si. Se apenas o especialista em
testes é o responsável por testar todos os artefatos gerados em uma sprint, essa atividade se
tornará um gargalo e diminuirá a velocidade da equipe. Além disso, os tipos de testes
realizados pela equipe e pelo especialista serão distintos e farão uma cobertura melhor do
sistema. Por isso, todos devem testar sem esquecer que o teste deve estar presente em cada
história.
Outro princípio de Agile Testing é diminuir o tempo entre a implementação de uma

história e a validação com o usuário. Para as equipes ágeis este princípio é fácil de ser
alcançado já que possuem a vantagem de entregar produtos para o cliente em pequenos ciclos
de tempo.
O sexto princípio diz que os erros encontrados devem ser resolvidos assim que possível
para que o código permaneça limpo, sem bugs.
O sétimo princípio diz que testes têm o potencial de descobrir requisitos não
explicitados. Ao testar um produto, diversas expectativas sobre o seu comportamento diante
de situações adversas são levantadas. A pergunta é: seria essa expectativa um requisito
implícito ou apenas uma preocupação não justificada? O ideal é ter a resposta para essa
pergunta antes de gastar tempo testando cenários que podem ser encarados como
dispensáveis pelo product owner.
O oitavo princípio de Agile Testing é a redução da documentação de teste. Não é preciso

escrever longos documentos com scripts a serem seguidos durante o teste. O uso de checklists
e documentações leves já resolvem o problema. O importante é manter o foco na essência do
teste e não nos detalhes envolvidos.
O último princípio de Agile Testing envolve a técnica de Test Driven Development (TDD).
Definir os testes junto com a criação dos artefatos de cada história e usá-los como apoio do
processo de desenvolvimento auxilia a criação de um projeto limpo e bem feito.
Então, resumindo, os 9 princípios de Agile Testing são:
1. Um processo de desenvolvimento que inclua testes resulta em um produto melhor;
2. Os testes não podem ser vistos apenas como uma fase do projeto;
3. Todos testam, não apenas o especialista em testes;
4. Uma história só é considerada pronta se forem realizados os testes

necessários;
5. Diminua o tempo entre a implementação de uma história e a validação com o usuário;
6. Erros encontrados devem ser resolvidos assim que possível;
7. Testes descobrem requisitos não explicitados;
8. Reduza a documentação de teste;
9. Adote, sempre que possível, a técnica de Test Driven Development (TDD).
Referência: Agile Testing: Nine Principles and Six Concrete Practices for Testing on Agile Teams – Elizabeth Hendrickson
http://blog.myscrumhalf.com/2011/10/historia-preparada-o-que-significa/
História Preparada, o que significa?

Postado em 24 de outubro de 2011 por Diego Marins, membro Equipe ScrumHalf, GPE Ltda.
O conceito "História Preparada" indica que uma história

já pode ser estimada pela equipe de desenvolvimento, a
fim de poder ser incluída em uma sprint.
A definição de "preparada" é elaborada em comum

acordo entre a equipe de desenvolvimento e o PO e
pode variar de equipe para equipe e também entre
projetos.
O acordo entre equipe e PO é necessário para que exista

a preocupação de preparar a história antes do planejamento da Sprint.
Em alguns projetos mais simpes, é possível que as histórias sejam compreendidas apenas com seu título e
sua descrição. Porém, em outros projetos pode ser necessário o preparo diagramas de classes, casos de
uso e outros artefatos. Caso a equipe precise desse tipo de documentação para poder estimar uma
história, é recomendável que essa documentação seja elaborada antes do planning poker, para que a
história seja bem pontuada e, dessa forma, ter menos riscos de ser reprovada no final da sprint.
Se, nesse caso, o acordo de "História Preparada" incluir a apresentação de tais documentos (casos de uso,
descrição dos requisitos, etc) isso passa a ser responsabilidade do PO e para isso é possível que o PO
precise de uma equipe especializada para atender esse acordo. Essa equipe deve trabalhar no preparo da
história antes da equipe de desenvolvimento implementá-la.
Um exemplo disso é a necessidade de designers responsáveis pela elaboração de telas, ícones e outras
imagens que possam ser úteis durante o desenvolvimento de algumas histórias. Nesse caso, é possível
que eles também formem uma equipe Scrum, adotando uma estratégia onde eles fiquem responsáveis
pela construção dos artefatos em uma sprint que anteceda a sprint de desenvolvimento. Com isso, a arte
elaborada numa sprint pela equipe de designers pode ser aproveitada em seguida na realização da
história. Com o planejamento adequado é possível fazer com que essas duas equipes trabalhem na
mesma história em sprints seguidas, agilizando a construção do produto.
Resumindo, definir os critérios que indiquem que as histórias estão preparadas é importante, pois auxilia a
equipe na estimativa das histórias e também auxilia o PO no planejamento das sprints.
Iniciar uma sprint sabendo exatamente o que deve ser feito em cada história é fundamental para uma
produtividade alta da equipe de desenvolvimento. Quanto maior o conhecimento sobre cada história, seja
a partir de modelos ou simplesmente de uma descrição bem feita, maior a probabilidade de sucesso no
final da sprint.
http://blog.myscrumhalf.com/2011/10/pair-programming-–-programacao-em-par/
Pair Programming – Programação em Par

Postado em 26 de outubro de 2011 por Marcelo Arêas, M.Sc.
A Programação em Par é definida por Williams e

Kessler como um estilo de programação no qual dois
programadores trabalham lado a lado em um
computador, continuamente colaborando no mesmo
design, algoritmo, código e teste.
Quando um programador desenvolve em par, ele

conta com a presença de outro desenvolvedor que
faz uma inspeção imediata de todo o código que é
produzido. Como o olho humano tem uma tendência de ver o que ele espera ver, esta inspeção imediata é
uma oportunidade de identificar problemas cedo. Rotina que reflete na redução de incidências de bugs
no projeto.
O ideal em uma programação em par é estabelecer um rodízio onde as duplas são constantemente
trocadas. Essa prática favorece ao aprendizado e compartilhamento de informação dos
desenvolvedores, além de que, em geral, duas pessoas pensando sobre um mesmo problema conseguem
criar soluções e cenários mais simples e eficazes.
Essa troca constante de informações contribui com a robustez da equipe, pois com a grande troca de
conhecimentos a perda de um membro da equipe tem os seus impactos amenizados.
Existe um termo chamado Peer Pressure, que pode

ser traduzido como Pressão do Par. Este termo foi
criado para representar a responsabilidade
compartilhada com a outra pessoa. Williams e Kessler
afirmam que esta “pressão” faz com que o
desenvolvedor trabalhe com mais dedicação e
atenção porque não quer decepcionar o seu
parceiro. Ou seja, a programação em par também ajuda a recuperar um tempo que seria improdutivo,
pois evita momentos de distração e o famoso “ih, deu branco!”.
Por fim, a programação em par também torna o trabalho muito mais divertido e facilita a comunicação
entre todos da equipe. Isso com certeza é um benefício, pois tudo o que é feito com alegria e afinco tende
a ser mais produtivo e gerar melhores resultados.
Referências: Williams e Kessler

http://blog.myscrumhalf.com/2012/01/burndown-chart-medindo-o-progresso-de-sua-sprint-
e-trazendo-indicativos-do-processo-de-trabalho-da-equipe/
Burndown chart – Mede o progresso da sprint e dá

indicativos do processo de trabalho da equipe
Postado em 9 de Janeiro de 2012 por Ester Lima de Campos, M.Sc., CSP, CSPO e CSM.
O Burndown chart ou gráfico de Burndown é o gráfico utilizado pelas equipes Scrum para
representar diariamente o progresso do trabalho em desenvolvimento. Ou seja, após cada dia de
trabalho o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho total
planejado.
É comum a Equipe de Desenvolvimento usar esse gráfico ao longo da Sprint, para medir os pontos das
histórias finalizadas ao longo dos dias da Sprint e ter uma visibilidade do seu ritmo de trabalho, verificando
se o ritmo está adequado para atingir a meta da sprint, cumprindo com o que foi planejado.
O Burndown é o gráfico mais simples que há no Scrum e que muitas equipes nem sempre dão o devido
valor as informações referente ao processo de trabalho que ele apresenta, indiretamente.
Simplesmente traçar o gráfico pelo simples fato de traça-lo é desperdício, o importante é identificar nele o
que há de errado com a estratégia, o processo de trabalho, adotado pela Equipe Scrum. E quando digo
Equipe Scrum, é pelo fato de que embora ele represente porção de trabalho desenvolvido,
que é de responsabilidade direta da equipe, todos estão comprometidos e ligados ao
resultado final que o grafico apresentará: Equipe de Desenvolvimento, Scrum Master e PO.
O fato de uma equipe não finalizar as histórias ao final da sprint pode ser não por falta de
comprometimento da equipe de desenvolvimento, mas pela indisponibilidade do PO em
ajudar a equipe no momento que ela mais precisa, ou do Scrum Master que não resolve
em tempo os impedimentos que surgem em uma sprint.
Nesse post vou explicar como montar e traçar o gráfico Burndown ao longo da sprint, para aqueles que
estão iniciando no Scrum e apresentarem alguns dos indicativos que ele nos mostra para avaliarmos nas
reuniões diárias e também após a sprint na reunião de retrospectiva do projeto.
O gráfico Burndown marca:
 no eixo horizontal os dias da sprint, do 1o dia ao último e

 no eixo vertical os pontos que foram planejados para compor a sprint, partindo do máximo de pontos
da sprint (velocidade da equipe) até zero.
O intervalo de pontos será definido pela equipe. Nos exemplos apresentados nesse post todos os gráficos
possuem como intervalo 5 pontos.
Desenhado os eixos do gráfico com os dias da sprint e os pontos da sprint de 5 em 5 pontos, vamos para
a segunda etapa que é a marcação da 1a linha do gráfico.
A 1a linha do gráfico é traçada como uma diagonal que tem início no ponto máximo até o ponto zero do
eixo vertical, e do 1o dia da sprint até o último dia da sprint. Nos gráficos apresentados nesse post essa
diagonal está representada pela linha vermelha.
Essa linha diagonal serve de guia para mostrar se a equipe está atrasada ou adiantada no
desenvolvimento de seu trabalho. Quando a equipe está atrasada no desenvolvimento a linha azul,
correspondente ao andamento dos trabalhos, estará a direita da linha vermelha e quando a equipe estiver
adiantada nos trabalhos a linha azul estará a esquerda da linha vermelha.
Com essa simples informação já é possível visualizar ao longo da sprint se a equipe está adotando uma
estratégia para chegar ao final com todas as histórias meio prontas, como todas as histórias prontas, ou
com pelo menos algumas prontas.
Vamos analisar o caso de estudo apresentado a seguir:
 Sprint com timebox de 1 semana de duração, ou seja, 5 dias úteis de trabalho.
 Sprint Backlog está composto por 8 histórias com as seguintes pontuações e na ordem de
implementação definida pelo PO:
o História 1 – 5 pontos
Total = 60 pontos.
O gráfico que teremos no início do projeto pode ser observado no 1o gráfico apresentadado abaixo. Ele
possui apenas a linha diagonal partindo da soma total de pontos das histórias da sprint (60 pontos) e do
1o dia da sprint até zerar a pontuação, chegando ao último dia da sprint com todas as histórias
implementadas.
Após o primeiro dia de trabalho, em cada reunião diária, a equipe calcula o total de pontos das histórias
concluídas para descer a reta azul no gráfico.
E como é feita essa conta? A equipe levanta as histórias que foram finalizadas e subtrai do total de pontos
o somatório de pontos das histórias finalizadas.
No 2o gráfico, apresentado acima, temos o seguinte:
 No 1o dia de trabalho a equipe finalizou 5 pontos, logo do 1o dia para o 2o traçamos a reta
diminuindo 5 pontos do total de 60 pontos da sprint.
 No 2o dia de trabalho a equipe finalizou 25 pontos, como podemos observar, que representam (dado
o caso de estudo em análise) as histórias, 2, 3, 4 e 5.
 No 3o dia de trabalho a equipe não finalizou nenhuma história, portanto a linha azul é traçada na
horizontal, mantendo os 30 pontos que ainda restam serem implementados na sprint.
Resta ainda dois dias de trabalhos para equipe finalizar 30 pontos referentes as histórias 6, 7 e 8, com 20,
8 e 2 pontos, respectivamente. Como falei anteriormente tudo vai depender da estratégia que a equipe irá
adotar. Nas reuniões diárias a equipe deve avaliar a melhor tática a seguir para chegar ao final com todas
as histórias prontas. Pois ao contrário a equipe pode chegar ao final com algumas prontas e outras não ou
com todas histórias as restantes meio prontas. Vamos analisar os três casos:
No 1o caso apresentado abaixo a equipe chega ao final da sprint sem finalizar as últimas 3 histórias.
Possíveis cenários que podemos levantar para esse caso:
 as 3 histórias foram iniciadas, mas nenhuma foi finalizada, ou seja, 3 histórias meio prontas.
 apenas a história 6, de 20 pontos, foi iniciada e as demais nem foram tocadas. Ou seja, duas histórias
não iniciadas e uma meio pronta.
Possíveis causas para explicar os cenários levantados acima:
1. A equipe não traçou bem sua estratégia de ataque as histórias para chegar ao final com o máximo de
histórias prontas.
2. A equipe pode ter focado em finalizar a história 6, de 20 pontos, seguindo a prioridade do que era de
mais valor para o PO, mas no entanto a história pode ter sido subestimada. Ou seja, não é uma
história de 20 pontos, mas algo maior. Se essa causa levantada for verdadeira isso pode indicar que
histórias com 20 pontos de estimativa, para essa equipe, sejam histórias que precisam ser mais
detalhadas e quebras em duas ou mais histórias menores.
3. Sugiram diversos impedimentos que o Scrum Master não foi capaz de resolvê-los em tempo de não
afetar a equipe e consequentemente a sprint.
4. A história de 20 pontos precisava de mais detalhes e o PO não estava acessível para esclarecer
dúvidas da equipe em tempo do término do prazo da sprint.
Vários outros pontos podem ser levantados. Cada equipe deverá analisar seu caso particular na reunião de
retrospectiva e chegar a causa do problema para consequentemtente dar uma solução para o problema,
evitando que esse cenário se repita nas próximas sprints.
No 2o caso apresentado abaixo a equipe chega ao final da sprint com mais 10 pontos finalizados. Esses
pontos, para o caso de estudo em análise, são referentes as histórias 7 e 8, de 8 e 2 pontos
respectivamente. Possíveis causas podem explicar esse cenário:
1. A equipe no 4o dia de trabalho achou por bem adotar a estratégia de interromper o trabalho da
história 6 e concentrar os esforços nas outras, para chegar ao final com o máximo de histórias
prontas. Mesmo fugindo a ordem.
2. A equipe insistiu mais um dia trabalhando na história de 20 pontos e no 5o dia que resolveram
interromper e atacar as outras duas histórias, que para felicidade de todos foram iniciadas e finalizada
em um dia.
3. A equipe desde o 3o dia de trabalho já estava trabalhando nas duas últimas histórias e a história 6
nem foi tocada. Ou seja a equipe finalizou 30 pontos em dois dias e nos 3 dias seguintes finalizou
apenas 10 pontos. Possivelmente há problemas de estiamtivas nas histórias que devem ser discutidos
na retrospectiva e acertados para a próxima sprint.
O 3o caso é o cenário onde a equipe chega ao final com tudo pronto. O que foi planejado foi entregue.
Mas ainda assim cabe uma reflexão para esse cenário, pois o que está bom também pode ser melhorado.
Vamos a alguns pontos:
 A equipe tem plena noção de sua velocidade, ou seja, o planejado é realmente o que a equipe
consegue se compromenter em entregar.
 Para essa equipe histórias com 20 pontos de estimativa não representam riscos para a sprint. São
histórias grandes, mas que estão em um nível de detalhe suficiente para a equipe seguir com o
trabalho sem grandes ameaçãs a sprint.
 Um dia sem finalizar história pode ter sido por conta de impedimentos, mas impedimentos que o
Scrum Master conseguiu removê-los em tempo de não impactar o término da sprint.
 Por outro lado… um dia sem finalizar história pode ter sido por conta da equipe ter se disperçado em
outras atividades que não pertence a sprint, nesse caso a equipe tem uma velocidade de produção
maior que 60 pontos, mas que são empregados em atividades fora da sprint. É preciso analisar esse
caso.
 Por outro lado, também… um dia sem finalizar história alguma pode ter sido por conta da equipe ter
tido a necessidade de ter mais esclarecimentos do PO para uma certa história, mas o PO não estava
acessível. Novamente a equipe pode ter uma velocidade de produção maior que 60 pontos, mas que
não são alcançados pelo relacionamento do PO com o projeto. É preciso também analisar esse caso
em busca de melhoria.
Resumindo, o burndown é muito mais do que um simples gráfico que ao longo da sprint decresce o total
de pontos da sprint indicando apenas o trabalho que resta a ser implemetado no total de dias restantes da
sprint.
Ele fornece indicativos que todos da equipe Scrum (PO, SM e equipe de desenvolvimento)
devem estar atentos para melhorar a cada sprint o ritmo de produção e assim trabalhar de
forma ágil, como a metodologia nos provê.
Observação: Clique nos gráficos para vê-los ampliados
http://blog.myscrumhalf.com/2014/01/4-dicas-de-analise-do-grafico-de-burnup/
4 Dicas de Análise do Gráfico de Burnup

Postado em 8 de Janeiro de 2014 por Igor Araujo, Desenvolvedor Java Pleno da empresa Match Latam
Um recurso muito utilizado pelas equipes Scrum

para a visualização do progresso de um Sprint é o gráfico de burndown. Através deste gráfico é possível
acompanhar como a equipe está em relação às entregas previstas para o Sprint em questão. Assim,
diariamente é possível prever possíveis problemas na entrega e assim tomar ações a fim de minimizá-los,
conforme pode ser visto no post "Burndown Chart: Medindo o Progresso de sua Sprint". Mas e quanto ao
andamento do projeto como um todo? Como é possível verificar se o projeto está “andando pra frente”?
Como fundamentar ou se adaptar a possíveis mudanças no escopo? No post de hoje, apresentamos como
outro gráfico, o gráfico de burnup, pode ajudar a responder estas perguntas, através de 4 dicas de
análises sobre este gráfico.
O gráfico de burnup oferece informações do progresso do projeto como um todo e não apenas de um
sprint como no caso do gráfico de burndown. Ele mostra claramente em que ponto a equipe está
(Entregas) e onde ela deve chegar (Demandas).
Conforme podemos visualizar na figura abaixo, o gráfico de burnup é construído sobre dois eixos: no eixo
horizontal tempos o fator tempo e no eixo vertical temos o fator que representa o montante de trabalho.
Este montante de trabalho pode ser representado em pontos, medidas de esforço, horas, etc, de acordo
com o que é utilizado no dia a dia de trabalho pela equipe.
Neste gráfico temos 2 linhas:
 Azul: representa o montante de trabalho entregue ao cliente. Ou seja, representa o total de histórias
(ou item do backlog) entregues ao longo do projeto.
 Vermelha: representa o montante de trabalho que está sendo pedido pelo cliente. Ou seja,
representa o total de histórias (ou item de backlog) criadas para o projeto.
A distância entre estas duas linhas representa, a cada dia (ou outra unidade de tempo
utilizada), o montante de trabalho que falta ser entregue para que se atinja o objetivo do
projeto naquele momento.
Com este breve resumo sobre o gráfico de burnup, apresentamos 4 análises interessantes que podem ser
feitas através dele.
1. Escopo X Entregas
A análise mais imediata que podemos fazer sobre este gráfico é a comparação do quanto o escopo do
projeto evoluiu com o quanto de trabalho foi entregue ao longo do tempo.
Se o escopo do projeto começa a crescer muito mais do que a quantidade de trabalho entregue, então
podemos ter um problema! Pois o projeto está crescendo em demandas, mas a velocidade de entregas da
equipe não está acompanhando o ritmo de crescimento destas demandas.
Pontos de atenção:
 Talvez seja o momento de estudar um possível aumento na equipe, a fim de aumentar a velocidade
das entregas
 Ou um estudo sobre o que pode estar impactando a velocidade das entregas.
 Ou ainda um estudo sobre a razão pela qual as demandas estão crescendo tão rapidamente.
Além disso, a comparação do montante de trabalho entregue com o montante de trabalho a fazer ao
longo do tempo nos permite medir a distância entre o que se quer com o que se está atendendo através
do projeto.
2. Regularidade das entregas frente ao objetivo do projeto
Outra análise interessante é sobre a regularidade das entregas do projeto frente ao objetivo.
Para esta análise traçamos uma linha desde a origem do gráfico até o ponto que representa o total de
demandas no ultimo dia representado no gráfico, conforme a linha verde apresentada na figura abaixo.
Se a linha azul está sempre próxima da linha verde, mais equilibrado está o andamento do
projeto.
Além disso, com essa linha é possível avaliar se estamos adiantados ou atrasados com as entregas. Caso a
linha azul esteja acima da linha verde, estamos adiantados. Caso a linha azul esteja abaixo da linha verde
estamos atrasados. É claro que essa ideia de atrasado ou adiantado depende das características do
projeto, até porque dificilmente as entregas diárias seguirão rigorosamente uma regularidade.
3. Classificação dos montantes de trabalho em categorias
Outra análise interessante que pode ser feita com o gráfico de burnup é a separação dos montantes
(demandados e entregues) em categorias. Por exemplo, em um projeto de software podemos ter as
categorias Bug, Histórias técnicas e Novas Features.
Assim teríamos uma linha do montante demandado e uma linha do montante entregue para cada
categoria. Estas informações poderiam ser visualizadas em um único gráfico de forma que para a
classificação do exemplo teríamos 6 linhas no nosso gráfico de burnup.
Ou poderíamos também separar em três gráficos, um para cada categoria com uma linha do montante
demandado e uma linha do montante entregue em cada um. Esta análise permite estudar não somente o
quanto está sendo entregue como um todo, mas também, a natureza do que está sendo entregue.
Podemos analisar em que períodos entregaram-se mais correções de bugs ou em que período liberamos
mais novas features, por exemplo. Ou talvez estudar quando estão surgindo mais demandas de correções
de bugs…É após muitas entregas de novas features? É antes?
Enfim, com a separação dos montantes de trabalho representados no gráfico em categorias podemos
fazer uma correlação entre as entregas e demandas das diferentes categorias e buscar estratégias a fim
de otimizar as entregas a fim de que se alcance o objetivo do projeto.
4. Análise da qualidade das entregas
Uma análise que fiz recentemente em um projeto que participo, e que pode até ser vista como uma
análise decorrente da separação dos montantes de trabalho em categorias, é um estudo sobre o
crescimento das demandas de correções de bugs frente às demais demandas do projeto. Ou seja, uma
análise que nos ajuda a medir a qualidade do trabalho que está sendo entregue.
Se a quantidade de bugs encontrados começa a crescer muito mais do que as outras demandas ou se a
quantidade de bugs começa a crescer mais do que a quantidade de trabalho entregue, pode ser sinal de
problema, provavelmente relacionados à qualidade do que está sendo entregue através do projeto. Além
disso, esta situação mostra que o trabalho que a equipe está entregando está ao mesmo tempo gerando
mais trabalho (correção de bugs) pra própria equipe. Assim a distância entre as linhas azul e vermelha do
gráfico de burnup será cada vez maior, quando na verdade o que se deseja é que estas linhas se
aproximem e ao final do projeto se cruzem.
A partir destas 4 análises podemos extrair importantes informações sobre a evolução do projeto em
questão, não só avaliando o total de trabalho entregue, mas também a natureza do está sendo entregue.
Outras análises também podem ser feitas de acordo com as características do projeto. Portanto o gráfico
de burnup fornece uma ferramenta poderosa e ao mesmo tempo flexível para que se possa avaliar o
andamento de um projeto como um todo ao longo do tempo, permitindo que sejam tomadas ações a fim
de que se atinja o objetivo do mesmo
http://blog.myscrumhalf.com/2012/01/o-quadro-de-tarefas-no-scrum/
O quadro de tarefas no Scrum
Hoje iremos falar sobre o quadro de tarefas do Scrum. Apesar de largamente utilizado e
considerado um símbolo da metodologia ágil, com seus post-its coloridos, esse quadro não é parte do
framework Scrum. No guia do Scrum, não encontramos nenhuma referência a sua utilização. O Kanban,
nome dado a esse quadro, que a tradução do japonês significa literalmente registro ou placa visível, é
apenas uma maneira que muitas equipes usam para gerenciar o andamento das tarefas.
Mas, se ele não é referenciado pela guia do Scrum, por que muitas equipes usam? Por que ele é
tão famoso?
Simplesmente porque ele cai como uma luva para gerenciar o andamento do trabalho. Os itens
do product backlog que foram selecionados em uma sprint precisam ser quebrados em tarefas para que a
equipe de desenvolvimento consiga transformá-lo em um incremento para o produto. Nesse momento é
que entram os post-its, as linhas e as raias do famoso quadro.
Como o quadro de tarefas não faz parte do framework Scrum, não há nenhuma recomendação
especificada no guia. Nesse post tentarei explicar basicamente o que ele é e como organizá-lo, para que
você possa entender melhor os conceitos e a dinâmica envolvida.
Cada linha do quadro de tarefas representa uma história e nela deverá ser incluída todas as
tarefas necessárias para que aquela história esteja pronta. Inicialmente, as tarefas são inseridas na
primeira coluna do quadro e, a medida que vão sendo desenvolvidas, vão avançando até chegarem na
última.
As raias do quadro, que são as colunas traçadas, são os estados em que uma determinada tarefa
pode estar. A quantidade e a descrição de cada uma pode variar de acordo com seu processo de
desenvolvimento. Normalmente, são usadas 3 colunas:
 “A fazer” (TO DO),
 “Em Execução” (DOING) e
 “Feito” (DONE)
Dessa forma, ao olhar o quadro, a pessoa é capaz de facilmente perceber como está o andamento
do trabalho.
Para cada tarefa, um post-it é afixado ao quadro. Cores diferentes podem ser usadas para
diferentes atividades, como por exemplo: Uma cor diferente pode ser usada para tarefas que são correção
de bugs. Isso ajuda ainda mais a inspeção do quadro. Um quadro que possua muitas tarefas que
envolvem retrabalho pode indicar problemas nos testes das funcionalidades, por exemplo.
O quadro Kanban caiu como uma luva para o Scrum porque garante a transparência e a
inspeção, dois dos pilares que suportam o framework. A transparência é garantida no momento em que
todos os comprometidos com o projeto podem acompanhar, a qualquer momento, como está o
desenvolvimento de cada história, os problemas encontrados nelas. A inspeção é possível na
interpretação do mesmo: muitos post-its representando impedimentos podem indicar problemas, assim
como uma tarefa que está há muito tempo sendo feita. A interpretação do quadro pode levar a
diagnosticar problemas complexos muito facilmente, de forma visual e intuitiva.
http://blog.myscrumhalf.com/2012/01/praticas-ageis-de-projeto/
Práticas Ágeis de Projeto

Postado em 25 de Janeiro de 2012 por Fabrício Pereira, M.Sc., CSM.
No desenvolvimento de
software, ao iniciar o projeto
você pode ter uma visão clara
sobre o sistema e o que você
quer que ele seja, uma vez que
os requisitos já foram
levantados. Entretanto, em
algum momento durante o
projeto os seus requisitos
podem mudar, devido
principalmente à solicitações do
cliente, e a sua imagem sobre
ele pode não ser mais clara.
Especialmente em métodos ágeis, sempre são esperadas mudanças nos requisitos

do sistema. Por tudo isso, deve-se ter um bom projeto para o sistema desde o
início, e ainda o arquiteto e desenvolvedor precisam estar preparados para as
mudanças. Para isso, o projeto do sistema deve ser preciso para que seja claro a
todos que estejam trabalhando nele. Também é preciso ter um método eficaz para
as mudanças de projeto, de forma que todos sejam atualizados com as
informações. Desta forma, a concepção do software em métodos ágeis ocorre em
todo ciclo de vida.
Antes das metodologias ágeis, ao projetar um software era necessário um

documento extenso e detalhado sobre as possíveis necessidades para o
desenvolvimento do software. Dessa forma, corre-se o risco dos desenvolvedores
não lerem este documento completamente, e assim não compreenderem
exatamente como o sistema será. De forma ágil, a concepção é feita de
maneira simples no início, e espera-se que uma comunicação estreita e
constante durante todo o processo de desenvolvimento sempre mantenha os
desenvolvedores atualizados. Então, aqui estão algumas práticas de projeto do
software utilizadas em métodos ágeis:
 Previsão da arquitetura – leve modelagem no início de um projeto para identificar e

pensar de forma crítica nas questões de nível arquitetural.
 Modelagem por iteração – leve modelagem por alguns minutos no início de uma
iteração/sprint para ajudar a identificar a estratégia da sua equipe para essa iteração.
 Modelo à prova – leve modelagem por alguns minutos de forma prática para pensar a
respeito da sua solução prática.
 Teste anterior ao design (TFD) – Escrever um único teste, antes de escrever código
de produção suficiente, para testá-lo.
 Refatoração – Faça pequenas alterações em uma parte da sua solução que melhore a
qualidade sem alterar a semântica dessa parte.
 Integração contínua – Automaticamente compilar, testar e validar os componentes
de sua solução sempre que houver uma dessas alterações nos componentes.
Percebam que estas práticas correspondem sequencialmente a práticas desde o

alto nível arquitetural, até o baixo nível de programação.
Referências:
 Agile software development: principles, patterns, and practices. Upper Saddle River.
(Martin, R. – 2003)
 Agile Design Practices: Lean Requirements Practices for Teams, Programs, and the
Enterprise, Pearson Education, http://www.agilemodeling.com/essays/agileDesign.htm.
(Leffingwell, D. – 2012)
http://blog.myscrumhalf.com/2011/08/desenvolver-projetos-scrum-com-ferramentas-e-um-
bom-negocio/
Desenvolver projetos Scrum com ferramentas é um bom

negócio?
Postado em 26 de agosto de 2011 por Luiz Tomaz, M.Sc., CSM, CSD, CSPO, membro Equipe ScrumHalf, GPE
Ltda.
Uma das grandes discussões
em torno de metodologias
ágeis, como por exemplo o
Scrum, é a seguinte:
É válido ou não adotar

o uso de uma
ferramenta para apoiar
o desenvolvimento de
projetos Scrum?
Existem dois grupos de

pessoas, de um lado estão os
"puristas", que pregam que o Scrum deve ser aplicado da forma mais simples possível, utilizando cartões
para as histórias, e, quando necessário, quadro branco e post-its para as tarefas, e, do outro lado, estão
os que são a favor do uso de uma ferramenta, pois alegam que a utilização de ferramentas sempre serão
bem vindas, e com o Scrum não será diferente.
Nesse post iremos contribuir com essa discussão, apresentando algumas vantagens que são percebidas
com a utilização de uma ferramenta para gerenciamento de processos Scrum.
A discussão apresentada aqui terá como base os seguintes conceitos chave do Scrum:
AGILIDADE, COLABORAÇÃO, TRANSPARÊNCIA e ADAPTAÇÃO.
Com a utilização de uma ferramenta, principalmente se a mesma for web, existe a possibilidade de todos
os participantes do projeto proporem histórias e do PO aprovar histórias remotamente, evitando assim que
ideias sejam esquecidas por não terem sido registradas em tempo. Essa facilidade aumenta a agilidade,
a colaboração dentro da equipe e a transparência com relação ao que deve ser feito.
Outro ponto é a facilidade de poder consulta tudo que já foi desenvolvido dentro do projeto, pois com
uma ferramenta, é possível realizar buscas por termos, aumentando novamente a transparência para a
equipe do que foi realizado dentro do projeto.
Ainda, com a utilização de uma ferramenta, o andamento da sprint pode ser consultado a qualquer hora e
de qualquer lugar, ajudando o Scrum Master a detectar os impedimentos o quanto antes e, novamente,
aumentando a transparência para a equipe com relação ao que foi combinado antes da sprint.
Por fim, com uma ferramenta é possível ter armazenado todo o histórico do projeto, concentrando todo o
conhecimento do projeto em um mesmo lugar. Isso permite a todos os membros do projeto:
 consultar histórias já implementadas,

 verificar o desempenho da equipe em sprints anteriores,
 analisar o conteúdo das reuniões de retrospectiva e etc.
Com a facilidade de consultar os resultados passados das reuniões de retrospectiva, a adaptação ao

Scrum é melhorada, bem como a transparência da equipe, com a disponibilização de todos os dados do
projeto atuais e históricos.
Como pôde ser visto, a utilização de uma ferramenta pode trazer diversos benefícios para seu projeto.
Para projetos onde a equipe fica distribuída geograficamente, a adoção de uma ferramenta faz-se
necessária, entretanto, para um projeto onde todos da equipe trabalham no mesmo lugar físico, a adoção
de uma ferramenta não é obrigatória, mas pode ser considerada como uma grande melhoria no seu
processo Scrum.
E você, o que pensa disso tudo? Deixe seu comentário e nos traga sua experiência com a utilização ou
não de ferramentas de gerenciamento em projetos Scrum.
http://blog.myscrumhalf.com/2011/08/intersecoes-dos-papeis-no-scrum/
Interseções dos Papéis no Scrum

Postado em 23 de agosto de 2011 por Ester Lima de Campos, M.Sc., CSP, CSPO e CSM.
Nunca é demais falarmos da Equipe

Scrum, que é composta pelo Product
Owner, pelo Scrum Master e pela
Equipe de Desenvolvimento. É
sempre bom, também, reforçar as
responsabilidades de cada um desses
papéis, representados no Scrum.
Nesse post falaremos dos papéis no

Scrum com base no novo Guia Scrum
2011:
Equipes Scrum são auto-

organizadas e multidisciplinares. Equipes auto-organizadas escolhem a
melhor forma de desenvolver seus trabalhos ao invés de serem comandadas
por outros de fora da equipe. Equipes multidisciplinares possuem todas as
competências necessárias para desenvolverem seus trabalhos sem
dependerem de outros que não fazem parte da Equipe Scrum. O modelo da
Equipe Scrum é desenvolvido para otimizar a flexibilidade, criatividade e
produtividade.
Equipes Scrum entregam produtos iterativamente e incrementalmente

maximizando a oportunidade de feedback. Entregas incremetais de produto
"pronto" garantem que uma versão do produto potencialmente utilizável está
sempre disponível para uso.
Sendo assim, vamos falar das responsabilidades de cada papel da Equipe Scrum e
suas interseções de forma a garantir o funcionamento do Scrum. O que significa o
Scrum Master apoiar a Equipe de Desenvolvimento ou o PO. Como o PO e a Equipe
de Desenvolvimento se relacionam?
Como o Scrum é uma metodologia ágil que requer o comprometimento de todos

com o projeto, não importando o seu papel, é imprescindível que ocorram
interseções nesses papéis.
Essas interseções não acontecem no sentido de absorver responsabilidades do

outro papel, por exemplo, Scrum Master desempenhando algumas das funções do
Product Owner ou atuando junto da Equipe de Desenvolvimento. Não. Essas
interseções representam a colaboração, o apoio mútuo, entre os papéis para
garantir o uso do Scrum.
O Product Owner é o responsável pelo produto, tendo como meta maximizar o

valor do produto e do trabalho da Equipe de Desenvolvimento. Como isso será
alcançado dependerá de cada organização, Equipe Scrum e dos indivíduos que
compõem a Equipe Scrum.
O Product Owner é representado por apenas uma pessoa e não um comitê. No

entanto, ele pode representar os desejos de um comitê, que pode ser o cliente,
stakeholders… mas é responsabilidade do Product Owner manter o product
backlog, que incluem:
 Descrever claramente os itens do product backlog;

 Ordernar os itens do product backlog da melhor forma a atingir os objetivos e metas;
 Garantir o valor do trabalho produzido pela Equipe de Desenvolvimento;
 Garantir que o product backlog esteja sempre visível, transparente e claro para todos e
apresentando o que a Equipe de Desenvolvimento irá trabalhar na próxima iteração;
 Garantir que a Equipe de Desenvolvimento entenda os itens do product backlog no nível
necessário.
O Product Owner pode fazer o trabalho listado acima ou tê-lo feito pela Equipe de
Desenvolvimento. No entanto, ele ainda permanece como o responsável pelo
product backlog.
Para que o Product Owner seja bem sucedido, toda a organização deve respeitar
suas decisões. As decisões do PO estão visíveis no conteúdo e ordenação do
product backlog. Ninguém está autorizado a dizer que a Equipe de
Desenvolvimento trabalhará em um conjunto diferente de requisitos e a Equipe de
Desenvolvimento não deve trabalhar no que ninguém externo solicitar, mas
somente no que for definido pelo PO.
A Equipe de Desenvolvimento é a responsável pelo desenvolvimento do

produto. As características da Equipe de Desenvolvimento são:
 Auto-organizada. Ninguém, nem mesmo o Scrum Master, diz como transformar o

product backlog em incrementos do produto;
 Multidisciplinar. Possuem todas as habilidades, capacidades, para transformar o product
backlog em produto;
 Scrum não reconhece nenhum título para os membros da Equipe de Desenvolvimento,
que não seja o de desenvolvedor, independente do trabalho executado pelo membro; e
 A Equipe de Desenvolvimento não possui sub-equipes dedicadas a domínios
particulares, como testes e análise de negócios.
À Equipe de Desenvolvimento que cabe a responsabilidade de estimar o esforço
para implementação das histórias descritas no product backlog.
O Scrum Master é responsável por garantir que o framework Scrum seja

compreendido e praticado por todos. O Scrum Master faz isso garantindo que a
Equipe Scrum adira a teoria, a prática e as regras do Scrum. O Scrum Master é o
servo-líder para a Equipe Scrum.
Ele também é responsável por ajudar aos que estão fora da Equipe Scrum a
compreenderem quais de suas interações com a Equipe Scrum são válidas e quais
não são. Ele ajuda-os a adaptarem a forma de interagirem com a Equipe Scrum
para maximizar o valor criado para a Equipe Scrum.
O Product Owner se relaciona com a Equipe de Desenvolvimento para

dar esclarecimentos quanto ao trabalho que deve ser implementado, garantindo
que a Equipe de Desenvolvimento entenda os itens do product backlog no nível de
detalhes necessário.
Uma vez comprometido com o projeto ele deve fornecer à Equipe de

Desenvolvimento, sempre que requisitado e necessário, informações para tornar as
histórias claras o suficiente para que a Equipe de Desenvolvimento possa
desenvolver um produto em conformidade com o desejado. Portanto, o PO deve
estar acessível ao longo das iterações sempre que houver dúvida por parte da
Equipe de Desenvolvimento, que por sua vez tem total liberdade para consultá-lo
no momento em que for preciso.
O Scrum Master se relaciona com a Equipe de Desenvolvimento quando

a apoia garantindo o progresso dos trabalhos. Isso acontece da seguinte forma:
 Apoiando a Equipe de Desenvolvimento a ser auto-organizada e multidisciplinar;

 Ensinando e liderando a Equipe de Desenvolvimento para criar produtos de alto valor;
 Removendo os impedimentos para que a Equipe de Desenvolvimento possa progredir;
 Facilitando eventos do Scrum conforme requisitado ou necessário; e
 Treinando a Equipe de Desenvolvimento em ambientes organizacionais em que o Scrum
ainda não está totalmente aprovado e compreendido.
O Scrum Master se relaciona com o Product Owner quando o apoia a
aperfeiçoar o planejamento dos trabalhos a serem executados. Isso acontece da
seguinte forma:
 Encontrando técnicas para a gestão eficaz do product backlog;

 Comunicando claramente a visão, metas e itens do product backlog para a Equipe de
Desenvolvimento;
 Ensinando a Equipe de Desenvolvimento a como criar itens claros e concisos no product
backlog;
 Fazendo entender e praticar a agilidade; e
 Facilitando os eventos do Scrum conforme requisitado ou necessário.
E quando os três papéis se relacionam de forma harmônica e constante ao longo

das iterações aí sim nós temos o Scrum sendo implementado. Essa é mais uma
medida que temos para saber se estamos aderente ao uso do Scrum ou não. Se
precisamos melhorar e no que temos que melhorar.
E nos seu projeto? Os papéis estão se relacionando de forma a estarem

implementando o Scrum? Alguam intereseção não funciona bem? Se é o caso,
quais são as consequências indesejáveis?
http://blog.myscrumhalf.com/2011/07/quais-sao-os-papeis-do-scrum-faq-scrum/
Quais são os papéis do Scrum? – FAQ Scrum

Postado em 19 de julho de 2011 por Luiza Rodrigues, Comunicação
Os três papéis definidos no Scrum são:
* Scrum Master
* Product Owner
* Equipe
As pessoas que preenchem estes papéis

trabalham em conjunto, numa base diária, para
assegurar o bom fluxo de informações e resolução
rápida de mudanças.
Scrum Master
O Scrum Master é o guardião do processo. Ele é responsável por fazer o processo correr bem removendo
os obstáculos que atrapalham a produtividade da equipe, organizando e facilitando as reuniões.
As responsabilidades do Scrum Master incluem:
• Remover as barreiras entre a equipe e o Product Owner.

• Ensinar o Product Owner como maximizar o retorno sobre o investimento (ROI), e cumprir seus
objetivos através do Scrum.
• Facilitar o trabalho da equipe removendo impedimentos que impeçam a equipe de trabalhar.
• Melhorar a produtividade da equipe da forma que for possível.
• Melhorar as práticas de engenharia e ferramentas para que cada incremento de funcionalidades

seja potencialmente entregável.
• Manter as informações sobre o progresso da equipe visível a todos de uma forma clara e
organizada.
Em termos práticos, o Scrum Master precisa entender bem do Scrum para treinar e orientar os outros
papéis, e educar e ajudar as outras partes interessadas que estão envolvidas no processo. Ele deve
manter atenção constante ao status do projeto em relação ao progresso esperado. Investigar e facilitar a
resolução de quaisquer obstáculos que imobilizam o progresso e, geralmente, ser flexível o suficiente para
identificar e lidar com quaisquer problemas que surjam. Ele deve proteger a equipe de perturbações
externas.
O Scrum Master não atribui tarefas aos membros da equipe, isso é uma responsabilidade da equipe. Sua
abordagem geral para a equipe é incentivá-la e facilitá-la na capacidade de tomada de decisões e
resolução de problemas relacionados ao desenvolvimento, de modo que eles possam trabalhar com maior
eficiência sem a necessidade de supervisão. Seu objetivo é ter uma equipe auto-organizável.
Product Owner
O Product Owner é dono do produto. Ele fornece o conhecimento do negócio em forma de requistos para
a equipe assim como sua ordem de aplicação. Na prática, o Product Owner é a interface entre a empresa
e os clientes.
Ele alimenta a equipe com requisitos e correções solicitadas por diversas fontes. É ele o ponto de contato
para esclarecimento das dúvidas da equipe sobre os requisitos do produto.
Trabalha em conjunto com a equipe definindo as necessidades dos usuários, os requisitos técnicos,
documentando-os conforme a necessidade, e determinando a ordem de sua execução. Ele gerencia o
Product Backlog (que é o repositório de todas essas informações), mantendo-o ao nível de detalhe e
qualidade que a equipe necessita.
O Product Owner também define o cronograma para liberação das releases, e faz a validação final para
saber se as implementações têm as características e qualidade necessárias para a liberação.
Equipe
A equipe, no framework Scrum, deve ser auto-organizada e multidisciplinar, composta por pessoas que
fazem o trabalho de desenvolvimento e teste do produto.
Uma vez que a equipe é responsável pelo desenvolvimento do produto, ela também deve ter a autonomia
para tomar decisões sobre como executar o seu trabalho. A equipe possui, portanto, auto-organização: os
membros da equipe decidem como dividir o trabalho em tarefas, e ao longo da sprint decidem a ordem de
execução das tarefas em função da história que está sendo desenvolvida, respeitando sempre a
prioridade.
O tamanho da equipe deve ser mantido até nove pessoas, se possível. Um número maior pode dificultar a
comunicação e afetar a produtividade.
Fonte: http://www.cprime.com/about/scrum_faq.html
http://blog.myscrumhalf.com/2011/07/importancia-reuniao-diaria-por-um-membro-da-
equipe/
Importância Reunião Diária
A reunião diária é uma

reunião que muitos
membros da equipe
podem considerá-la
desnecessária de ser
realizada já que a
equipe trabalha toda no
mesmo ambiente. No
entanto, como membro
da equipe ScrumHalf,
destaco aqui pontos que
ressaltam a importância
do comprimisso que a
equipe deve ter com a realização da reunião diária.
Auxílio à auto-organização da equipe
No desenvolvimento ágil é esperado que a equipe seja auto-organizável. Sendo

assim, é imprescindível que todos da equipe saibam o que os outros estão fazendo,
facilitando assim a tomada de decisões pela equipe, com todo mundo podendo ter
uma visão mais embasada sobre o que está ocorrendo. A reunião diária é o
momento da equipe se cobrar, entender o por quê das tarefas de alguns membros
estarem demorando mais do que o esperado para ser concluída, identificar
caminhos errados que possam estar sendo seguidos e propor soluções o quanto
antes.
Transparência no trabalho da equipe
Conforme apresentado no ponto anterior, é o momento onde se apresenta o que
foi feito no dia anterior e se "combina" o que será feito no dia, evitando assim a
ociosidade por parte de algum membro da equipe.
Foco na sprint
Com a cobrança mútua entre os membros, o foco de toda a equipe tende a estar
alinhado, tende a todos focarem na sprint, em acabar as histórias e alcançar a
meta. O que está sendo feito e que não diz respeito à sprint fica transparente na
reunião diária, quando é exposto o que foi feito no dia anterior. A equipe como um
todo detecta esses desvios de tarefas que não tem a ver com as histórias da sprint,
podendo comprometer a finalização da sprint com a entrega do que foi combinado
entre Equipe e PO.
Compromisso com a equipe
Como na reunião diária é acordado o que cada um fará no dia, todos se

comprometem a realizar suas tarefas combinadas para o dia, aumentando assim o
seu compromisso com a equipe e aumentando também o foco no entregável.
Por esses e outros motivos que faz-se necessário a reunião diária no desenvolvimento ágil,
respondendo basicamente três perguntas:
 O que você fez ontem?

 O que você fará hoje?
 Quais são seus impedimentos?
E vocês, membros de equipe, têm feito diariamente essa reunião?

http://blog.myscrumhalf.com/2012/05/reuniao-de-planejamento-da-sprint-parte-1-
selecionando-o-sprint-backlog/
Reunião de Planejamento da Sprint – Parte 1:

Selecionando o Sprint Backlog
Postado em 23 de Maio de 2012 por Marcelo Arêas, M.Sc.
Oi pessoal, o post de hoje é sobre a seleção das histórias que compõem o Sprint Backlog.
O Sprint Backlog é o conjunto de todas as histórias que foram selecionadas para serem desenvolvidas na
Sprint que está para começar. Esse post procura auxiliar o leitor a responder perguntas como " Quantas
histórias minha equipe é capaz de desenvolver?".
A Reunião de Planejamento da Sprint é dividido em duas partes. Na primeira é feita a seleção das
histórias que deverão fazer parte do Sprint Backlog, e é o que veremos nesse post. A segunda parte, que
veremos num post futuro, trata de como cada história será dividida para ser implementada pelos membros
da equipe de desenvolvimento.
No final da Sprint anterior ocorreu a Reunião de Revisão, onde o PO priorizou as histórias do Product
Backlog. A equipe de desenvolvimento deve estimar as histórias mais prioritárias (se ainda não estimou,
esse é o momento! E pode ser feito utilizando o Planning Poker!) e em seguida, as histórias vão entrar no
Sprint Backlog de forma que a soma de seus pontos não ultrapassem a velocidade da equipe.
Bem, para esse processo funcionar é preciso conhecer a velocidade da equipe. Esta medida pode ser
obtida através da média dos pontos das histórias aprovadas nas últimas Sprints. Por exemplo, vamos
considerar que a soma dos pontos das histórias aprovadas nas últimas 5 Sprints foram: 18, 20, 16, 23, 21
(nesse exemplo consideramos as últimas 5 Sprints, porém isso não é uma regra, esse número pode
variar). Para esse caso a velocidade média da equipe foi (18 + 20 + 16 + 23 + 21) / 5 = 19,6.
Isso significa que, baseado nas últimas 5 Sprints, a equipe tem capacidade de desenvolver até 19 pontos
na Sprints. Com base nesse número as histórias mais prioritárias vão sendo introduzidas no Sprint
Backlog até que se alcance o valor mais próximo deste número.
Novamente utilizando um exemplo, vejamos a situação onde temos as seguinte histórias no

Product Backlog, já ordenadas por sua prioridade:
 História 1: 5 pontos
A nossa equipe do exemplo, que possui uma velocidade média de 19,6 pontos, ao selecionar as histórias
para o Sprint Backlog, inclui as Histórias 1, 2, 3 e percebe que a soma da pontuação dessas histórias é
igual a 16 pontos. A próxima história a ser incluída, pela ordem de prioridade, seria a História 4, mas isso
acarretaria numa pontuação total de 24 pontos. Pelo histórico da equipe a chance dessa Sprint ser
comprometida com a reprovação de alguma história seria muito alta e por isso essa História deve ficar de
fora do Sprint Backlog.
Para casos como esses o ideal é contatar o PO e informar o atual estado do planejamento. Pode ser que,
para o PO, a História 5 tenha uma prioridade similar a História 4 (e não dependa desta) e, então, ela
poderia entrar na Sprint. Nesse caso o Sprint Backlog seria constituído pelas Histórias 1, 2, 3, 5 e a soma
da pontuação dessas histórias seria 18 pontos, dentro da velocidade da equipe.
E você, como tem feito o seu planejamento? Sinta-se a vontade de compartilhar sua experiência conosco!
Até o próximo post!
6 motivos por que a Revisão da Sprint é importante
Postado em 29 de Janeiro de 2014 por Paula Nascimento, CSM, Scrum Master, Analista de Sistemas em SERPRO
A revisão da Sprint já foi tratada aqui no blog em alguns posts,

como em O que é Reunião de Revisão? – FAQ Scrum, Boas Práticas da Reunião de Revisão e Como tornar
a revisão da sprint um sucesso?. Também não é para menos. Apesar de às vezes a reunião de Revisão ser
vista como uma cerimônia não tão necessária quanto outras, ela é na verdade uns dos pontos de inspeção
e adaptação mais importantes do ciclo Scrum, principalmente do ponto de vista do produto.
Uma das razões para a reunião de Revisão ser menos valorizada é porque, em alguns casos, a visão que
se tem é de que sua utilidade é apenas fazer uma homologação da versão entregue e, na verdade, isso
pode ser feito apenas pelos testadores do produto, sem a presença de stakeholders, PO e time
desenvolvedor. No entanto, o erro está em crer que a reunião de Revisão serve para homologar a
entrega. E é justamente para desmistificar essa cerimônia do Scrum que veremos porque ela é tão
importante assim.
#1: É a hora de olhar e ver se o que foi feito te atende e te agrada!
O principal objetivo da reunião de Revisão é mostrar ao PO e aos demais envolvidos no projeto o que foi
realizado durante a Sprint, não realizar uma homologação inicial do produto. Quando um item de backlog
é incluído no Sprint Backlog, cria-se uma expectativa de que ao final do ciclo de desenvolvimento aquele
problema será resolvido e de acordo com o nível de qualidade desejado. É por isso que durante a Revisão
o PO tem o poder de aprovar ou reprovar os itens do Sprint Backlog. Ele precisa avaliar se o valor
esperado com a execução de um determinado item foi realmente entregue. Se foi, ele aprova o item. Se
não, reprova.
#2: Ok. Atendeu e agradou. Mas é esse o caminho que você quer mesmo seguir?
A reunião de Revisão também é o momento que você consegue reunir PO, equipe e stakeholders para que
todos possam ver a situação atual do produto e discutir se ele está no caminho certo. O planejamento da
Sprint seguinte será realizado em outro momento, mas é na reunião de Revisão que surgem sugestões de
novos itens de Backlog e é bom mesmo que surja. Isso demonstra que todos estão envolvidos com o
projeto, buscando o sucesso do produto e conversando sobre o melhor direcionamento para ele.
#3: Nhé… agradou não. Temos que mudar alguma coisa aí.
Já dizia a sabedoria popular que “Nem tudo são flores”. Em alguns momentos itens do Sprint Backlog
serão reprovados, mas não porque não foram finalizados ou porque tem bugs, por exemplo. Eles serão
reprovados simplesmente porque não foram aceitos pelo PO. E é importante que isso seja realizado
presencialmente durante a reunião de Revisão para que a equipe entenda porque aquele item não foi
aprovado e o que precisa mudar para as próximas Sprints para que isso não volte a acontecer.
#4: Está bem… também é o momento de uma homologação inicial da versão.
Ok, realmente é possível fazer uma homologação inicial da versão durante a reunião de Revisão, mas é
importante saber que esse não é o objetivo da reunião e que, na realidade, o que será realizado é uma
validação do requisito implementado. O teste do funcionamento será apenas de maneira superficial.
Se dermos uma olhada no livro Agile Testing, veremos que esta validação se enquadra justamente do
quadrante 3 do Agile Testing Quadrants, como podemos ver abaixo.
Esses quadrantes tem por objetivo representar as maneiras de se testar um sistema de forma ágil. No
caso dos testes que fazemos na reunião de Revisão, nosso objetivo é crititar o produto do ponto de vista
do negócio. Sendo assim, nossos testes durante a reunião criticarão os cenários, a usabilidade, a aceitação
do usuário, validando o produto e o negócio e não o funcionamento do requisito.
#5: E também um momento de aprendizagem…

Outra vantagem da reunião de Revisão é que ela também é uma oportunidade de mostrar ao PO e
stakeholders como é o funcionamento do que foi desenvolvido e explicar o passo a passo necessário para
executar a ação esperada. Esta prática evita ruídos e falsos alarmes de erros, além de acabar avaliando
também a usabilidade do que foi realizado. Se não houver dúvida de como proceder, sabe-se que a
usabilidade está ok e será de fácil entendimento. Se surgir alguma dúvida, vale considerar se não é uma
boa ideia fazer alguma alteração na solução implementada.
#6: Pelo fim das surpresas, desapontamentos e frustrações!
Por fim, a reunião de Revisão evita que lá na frente os mais interessados no projeto acabem tendo
surpresas desagradáveis com o rumo que o produto levou. Se o acompanhamento do projeto for realizado
toda Sprint, durante 1 ou 2 horas, ao final do projeto o produto estará da maneira desejada, entregando o
valor esperado e evitaremos aqueles casos em que após anos de desenvolvimento o produto acaba por
ficar encostado, porque não atendeu a necessidade para o qual ele foi criado. É na reunião de Revisão que
alinhamos as expectativas com o produto e o direcionamos para alcançar o objetivo estabelecido.
E nos projetos de vocês? Como a equipe vê a Revisão da Sprint? Compartilhe com a gente as suas
experiências!
Referências:
 Essential Scrum: A Practical Guide to the Most Popular Agile Process
 Using the Agile Testing Quadrants
http://blog.myscrumhalf.com/2012/06/dando-prazos-em-projetos-ageis-2/
Dando prazos em projetos ágeis

Postado em 13 de junho de 2012 por Thiago da Costa, Coordenador de equipe na Acotel do Brasil, Certified Scrum
Master (CSM) e desenvolvedor.
Quem nunca foi obrigado a responder àquela

ingrata pergunta “Quanto tempo você leva pra desenvolver isso?”
Essa pergunta é mais comum do que se imagina. Eu mesmo já tive que respondê-la inúmeras vezes. A
resposta na maioria das vezes é um chute, claro.
O que acontece é que, infelizmente, a realidade é um pouco diferente daquela que costumamos ver
equivocadamente em alguns livros, blogs
e até cursos.
No mundo real as empresas cobram prazos. Fato! Mas se você pensar bem, isso é totalmente
compreensível, não acha? Você como uma empresa, aceitaria desenvolver um projeto sem ter uma idéia
estimada de quanto tempo ele vai durar, por quanto tempo irá precisar alocar as pessoas e quanto isso irá
custar?
É claro que você pode trabalhar com contratos de escopo aberto (variável) e certamente você não terá
alguns desses problemas, mas isso é assunto para outro post. 🙂
“Prazos impelem à ação. Sem um prazo, não há objetivo, apenas uma solicitação nebulosa
que se acrescenta à confusão geral em andamento.” – Steve Chandler/Scott Richardson
Mas como criar um plano ágil que nos ajude a responder a essa pergunta?
Antes de mais nada, vamos supor que eu tenha pedido emprestado um livro a um amigo.
Ele é uma pessoa que não gosta muito de emprestar as coisas, mas como sou muito amigo dele, ele
acaba me emprestando, mas com uma condição: que eu diga mais ou menos quando eu poderei devolvê-
lo.
Eu poderia simplesmente chutar uma data qualquer, mas não quero fazer isso. Como ele é muito chato,
prefiro dar uma informação um pouco mais embasada.
Então eu pego o livro nas mãos, analiso, dou uma olhada em algumas páginas e vejo que ele tem umas
100 páginas. Esse é o tamanho do livro.
Pela minha experiência, sei que normalmente consigo ler 10 páginas de um livro por dia, cinco páginas no
caminho indo para o trabalho e outras cinco no caminho de volta. Essa é a minha velocidade estimada.
Agora eu divido o número de páginas (100) pela minha velocidade (10) e descubro que levarei
aproximadamente 10 dias para ler o livro todo. Essa é minha primeira estimativa de duração.
Tamanho -> Velocidade -> Duração
“Estimar a duração de um projeto começa com a estimativa do seu tamanho” – Mike Cohn
Equipes ágeis normalmente estimam dessa forma como vimos acima, ou seja, primeiro estimamos o
tamanho das histórias, depois estimamos a velocidade da equipe e por último estimamos (derivamos) a
duração do projeto.
A partir de hoje, guarde essas 3 palavras: tamanho, velocidade e duração. Elas são a chave para uma
estimativa e planejamento ágil.
Agora vejamos como isso funcionaria com um projeto de verdade
Vamos supor que a empresa que eu trabalho foi escolhida para desenvolver um projeto e o cliente pediu
que enviássemos uma estimativa de prazo.
Nós poderíamos chutar uma data qualquer, mas não queremos fazer isso, certo? Mas também não
podemos perder muito tempo nisso porque o cliente quer uma resposta logo e não queremos perdê-lo.
Como a Product Owner já tem uma lista inicial de histórias, já podemos começar a estimar o tamanho de
cada uma.
A equipe então espalha os cartões na mesa e seleciona a história que aparenta ser a mais fácil e atribui
uma estimativa de 2 pontos a ela. A partir daí, começamos a estimar cada história restante comparando-a
com as estimativas anteriores, sempre fazendo perguntas como: "Essa história é duas vezes maior que a
história que estimamos em 1 ponto? Então podemos estimá-la em 2 pontos?", "Essa história é mais fácil
que a história estimada em 5 pontos? Concordam em estimá-la em 3 pontos?".
Após estimar todas as histórias, somamos os pontos de cada uma e chegamos num total de 100 pontos.
Esse é o tamanho do projeto.
Pela nossa experiência em projetos parecidos e com a mesma formação de equipe, sabemos que
normalmente conseguimos fazer 10 pontos por Sprint de 2 semanas. Essa é a nossa velocidade
estimada.
Agora dividimos o tamanho do projeto (100) pela nossa velocidade (10) e descobrimos que vamos levar
aproximadamente 10 Sprints para desenvolver todo o projeto, o que dá um total de 20 semanas. Essa é
nossa primeira estimativa de duração.
Mas essa estimativa de duração pode mudar?
Pode, claro, tanto pra mais quanto pra menos. Tudo vai depender da velocidade; se ela vai aumentar ou
diminuir durante esse tempo.
No exemplo do livro emprestado, a minha velocidade poderia aumentar caso eu começasse a passar mais
tempo no trânsito e assim tivesse mais tempo de ler mais páginas por dia. Ou ainda poderia diminuir caso
eu fosse acometido por uma dor de cabeça incoveniente durante uma semana e não conseguisse ler
sequer uma página por dia.
A velocidade é o grande equalizador!

Mas porque chamamos de plano ágil?
Chamamos de plano ágil porque estamos falando de um plano criado a partir de um planejamento
contínuo, um plano que está preparado para mudar e responder às mudanças.
A velocidade da equipe pode mudar, o escopo pode aumentar ou diminuir, mas o plano será sempre
atualizado e comunicado ao cliente a cada Sprint; tudo de forma bastante transparente.
Algumas considerações:
 A reunião de estimativa do tamanho do projeto pode demorar mais do que o esperado dependendo da
quantidade de histórias a serem estimadas. Sendo assim, é uma boa prática dividir essa reunião em
sessões de no máximo 3 horas diárias cada.
 Na hora de selecionar a história mais fácil, não se preocupe se está realmente selecionando a história
mais fácil de todas. O Product Owner também não precisa ler e detalhar todas as histórias pra você
chegar a essa decisão. Use o sentimento aqui e siga em frente. Essa estimativa serve apenas de base
para as outras. Lembre-se também que se você identificar outra história mais fácil, você ainda tem o 1
para usar.
 Não se atenha a todos os detalhes na reunião de estimativa de tamanho. Provavelmente o Product

Owner não terá todas as respostas para todos os cenários possíveis. Isso é normal e aceitável em um
projeto ágil. Sei que você deve imaginar que é impossível estimar uma história sem ter todos os
detalhes, sem um wireframe, sem um documento com todos os cenários, mas acredite que isso é
possível sim. Por exemplo, quando estimei que lia 10 páginas de um livro por dia, não considerei o
tamanho da fonte. Se a fonte for muito pequena, provavelmente só vou conseguir ler 6 páginas por
dia. Ou seja, se você perceber que estimou mal uma história, deixe que a velocidade conserte isso. A
sua velocidade vai diminuir e você vai reestimar o projeto com base na nova velocidade.
 Quase nunca somos capazes de usar a experiência para estimar a velocidade da equipe, como fizemos
no exemplo acima. Normalmente os projetos nunca são tão parecidos e a formação da equipe nunca é
igual. Sendo assim, uma boa prática é fazer o primeiro Sprint Planning e somar os pontos das histórias
que a equipe selecionou. O total dessa soma será a velocidade estimada.
Bem, espero ter contribuído de alguma forma com o seu aprendizado e qualquer dúvida, é só entrar em
contato. Até a próxima! 🙂

Thiago Costa é coordenador de equipe de novos projetos na Acotel do Brasil, Certified Scrum Master
(CSM) e desenvolvedor.
http://blog.myscrumhalf.com/2012/06/a-importancia-da-visualizacao-no-gerenciamento-de-
projetos/
A importância da visualização no gerenciamento de

projetos
Postado em 20 de junho de 2012 por Daniel Pereira, sócio-fundador da LUZ Empreendedora
A ciência afirma que nós, seres humanos,

captamos mais de 80% das informações através da nossa visão. Todos os dias, passamos horas olhando
telas de computadores para analisar e interpretar fluxos de informação. Mas, apesar disso, acredito que o
melhor uso da visualização é algo que falta em muitas disciplinas e gerenciamento de projetos não é uma
exceção.
Felizmente, as últimas tendências em gerenciamento de projetos ágeis demonstram preocupação

crescente com a visualização! O sucesso do Kanban depende fortemente de visualização. E o mesmo
acontececom o quadro de tarefas e o burn down chart do Scrum. Sim, exsite algum progresso, mas será
uma ênfase que buscamos ou apenas um efeito colateral de outras atividades?
Seria fascinante criar um movimento na comunidade ágil que se concentra na visualização para gerenciar
melhor seus projetos. Ao adotar metodologias visuais passamos a trabalhar melhor em equipe, além de
revelar problemas, a situação atual e as tendências mais facilmente. Imagine diagnosticar quase que de
imediato problemas do projeto, como:
 Equipe sobrecarregada
 Histórias problemáticas
 Problemas de qualidade
 Velocidade geral de desenvolvimento lenta
Você talvez não possa solucionar todos esses pontos rapidamente, mas a velocidade do diagnóstico é
passo fundamental para corrigir problemas no projeto. E isso só se torna possível se você visualiza o
projeto ao invés de uma simples lista de tarefas.
O ultrapassado Project
Os quadros ágeis
A utilização de ferramentas visuais já começa a invandir outras áreas de negócio com força, um bom
exemplo é o Business Model Canvas que é atualmente a ferramenta mais utilizada para pensar novos
negócios e refletir sobre negócios atuais em busca de inovação. Ao reduzir texto e aumentar a visualização
todos trabalhamos melhor em equipe, diagnosticamentos e encontramos soluções mais rapidamente.
Eu me pergunto por que ainda não temos boas ferramentas de visualização para o gerenciamento de
projeto. Acho que a resposta é que os gerentes de projetos não são fortes no design, e os designers não
são fortes em gerenciamento de projetos. A combinação ideal é uma equipe onde Gerente de Projetos
sabe design e Designer sabe gerenciamento de projetos.
Daniel Pereira é sócio-fundador da LUZ Empreendedora e autor do livro "O Analista de Modelos de
Negócio – 75 exemplos para você dominar a ferramenta".
http://blog.myscrumhalf.com/2012/08/cuidando-do-product-backlog/
Cuidando do Product Backlog

Postado em 1 de agosto de 2012 por Igor Araujo, Desenvolvedor Java Pleno da empresa Match Latam
Ao longo do tempo requisitos levantados em algum momento do projeto acabam se tornando defasados
antes mesmo de serem implementados. Algumas vezes histórias do Product Backlog podem acabar sendo
esquecidas e até mesmo perdendo o sentido devido às mudanças que ocorrem no projeto. Por isso é
importante cuidar do Product Backlog para mantê-lo sempre alinhado à situação atual do projeto, evitando
que ele fique cheio de histórias que talvez não façam mais sentido. Além disso, é importante também que
a equipe participe do Product Backlog com a criação de histórias, tornando-o mais versátil e dinâmico.
O post de hoje trata exatamente da manutenção do Product Backlog expondo algumas práticas que
podem ajudar a mantê-lo mais limpo, coeso e sempre alinhado às necessidades do projeto.
Equipes adotam metodologias ágeis justamente pelas incertezas associadas ao projeto em questão. Muitas
vezes, os objetivos do projeto ainda não são completamente conhecidos e os requisitos não estão
totalmente definidos de antemão. Essa é uma das razões que levam ao uso de metodologias ágeis. As
histórias vão sendo criadas no Product Backlog e ao longo do tempo vão sendo selecionadas para serem
implementadas dentro de uma Sprint. Porém podem ocorrer mudanças nas prioridades e nos requisitos do
projeto de forma que em algum momento o Product Backlog possua histórias que não são mais
necessárias. Isso muitas vezes ocorre com histórias menos prioritárias que vão sendo deixadas pra depois
e nunca entram em uma Sprint.
O problema é que ao longo do tempo poderemos ter um Product Backlog cheio de histórias que não serão
implementadas e que talvez sejam até conflitantes com outras histórias que tenham surgido ao longo das
Sprints e não façam mais sentido para o projeto. Assim teremos um Product Backlog que não representa
as reais demandas do projeto. Portanto uma prática interessante é a de estar atento às histórias que
nunca entram em um Sprint Backlog, pois isto é um forte indício de que esta história talvez não seja mais
necessária para o projeto. Isto pode ser feito no Planejamento 1, onde equipe e PO decidem juntos quais
histórias entrarão no próximo Sprint Backlog. Percebendo que alguma história sempre fica de fora a
equipe pode mostrar isso para o PO e discutir se não seria o caso de remover ou alterar a história. Outra
prática interessante é, ao ter uma nova história criada, verificar se existe alguma relação entre ela e
qualquer outra história do Product Backlog. Isso ajuda a identificar histórias conflitantes ou até mesmo
histórias que devem ser agregadas em uma história só.
Vale lembrar que os cuidados com o Product Backlog não devem ser voltados apenas para as histórias que
já estão lá! A equipe, percebendo necessidades no projeto, também pode e deve propor histórias para
serem discutidas com o PO e então decidirem se devem ou não ser aprovadas. Pois algumas necessidades
nem sempre são percebidas pelo PO. Esta prática ajuda a manter o Product Backlog sempre populado e
permite que a equipe use sua criatividade não só na implementação das histórias, mas também para a
criação de requisitos para o projeto em questão.
Enfim, não existem regras pré-definidas para a manutenção do Product Backlog. Porém as práticas
expostas neste post podem ajudar uma equipe a manter seu Product Backlog mais limpo, coeso e
permanentemente alinhado às necessidades do projeto.
E você, como cuida do seu Product Backlog?

http://blog.myscrumhalf.com/2012/05/boas-praticas-da-reuniao-de-revisao/
Boas práticas da reunião de revisão

Postado em 30 de Maio de 2012 por Felipe Madureira, CSM.
Para todos que estão familiarizados com a metodologia Scrum, o nome reunião de revisão já aparece
como rotina no desenvolvimento. O Scrum nos diz qual o objetivo de um reunião de revisão. Mas como
ela pode ser feita? Existe uma maneira ideal de fazê-la? Considerando que o Scrum é um processo
empírico, buscamos evoluir constantemente nossas reuniões e métodos para uma maior eficácia.
A maneira ideal de executar a reunão varia de acordo com cada equipe. Apresento algumas dicas que
executamos nas nossas reuniões e que tem nos trazidos grandes benefícios.
Ao longo de todo nosso desenvolvimento, levantamos os pontos que podiam ser melhorados e adaptamos
nosso processo de acordo. Hoje temos alguns passos que consideramos importantes para serem
executados antes e durante a reunião de revisão.
Roteiro de apresentação: Antes de ir para a reunião, é necessário se preparar. No caso de sprints que
possuam muitas histórias, o roteiro se torna ainda mais fundamental para você não se perder na sua
apresentação. Nele inclua todas as histórias, os passos a serem executados e os resultados esperados
exigidos pelo PO na descrição da história.
Teste a aplicação: Parece óbvio, mas muitas vezes é negligenciado. Faça o teste da aplicação no
ambiente em que ela será apresentada. A mudança de máquina, a velocidade da conexão ou uma
configuração diferente podem fazer com que a aplicação não funcione corretamente. Se você tiver
construído um roteiro, execute-o antes de apresentar de verdade. Esse procedimento simples evita
situações constrangedoras.
Execute seus testes automatizados: Se você possui testes automatizados, você deve executá-los
antes de apresentar. Na verdade, a melhor prática é executar seus testes periodicamente. No entanto, se
isso não é possível por algum motivo, antes da reunião de revisão, executá-los se torna essencial. As
novas funcionalidades que foram implementadas podem ter causado alguma alteração indesejada na
aplicação e podem ter alterado o comportamento de uma funcionalidade que já existia.
Utilize a aplicação durante a reunião: Evite a todo custo apresentar as funcionalidades usando slides
ou vídeo. A apresentação deve ser feita utilizando o próprio software funcionando. Assim, o PO terá mais
autonomia para solicitar ver um determinado comportamento da aplicação e terá mais confiança no
produto, já que a versão que está sendo utilizada para a apresentação é a versão que está sendo
entregue.
Tenha papel e caneta a mão: Durante a reunião de revisão, muitas idéias surgem. Sejam melhorias das
histórias implementadas ou funcionalidades novas da aplicação, essas idéias devem ser anotadas para que
possam ser introduzidas no product backlog e priorizadas pelo PO. Com o auxílio do Scrumhalf, colocamos
a história diretamente no backlog, agilizando ainda mais essa etapa.
Evite a reunião de planejamento no mesmo dia: Não misture o planejamento da sprint seguinte com
a reunião de revisão da sprint atual. Essas reuniões devem ficar em dias separados. Assim, durante a
retrospectiva o PO terá tempo de amadurecer as idéias que ocorreram durante a revisão e, ao final do dia,
a equipe terá a sensação de dever cumprido, sentindo-se revigorada para a próxima sprint.
Com esses passos, notamos uma melhora significativa nas nossas reuniões de revisão, aumentando o
número de histórias aprovadas, reduzindo o retrabalho e diminuindo o tempo perdido. Esse processo, é
claro, não está estagnado e estamos sempre buscando a melhoria do nosso processo. Deixe um
comentário com sua sugestão e aplicaremos na nossa próxima reunião!
http://blog.myscrumhalf.com/2012/05/tecnica-para-fazer-uma-reuniao-de-retrospectiva-no-
scrum/
Técnica para fazer uma Reunião de Retrospectiva no

Scrum
Postado em 21 de Maio de 2012 por Ester Lima de Campos, M.Sc., CSP, CSPO e CSM.
A retrospectiva, última reunião de uma sprint no Scrum, tem como objetivo avaliar
o processo de trabalho em uma sprint. Avaliar significa olhar com atenção tudo que ocorreu na sprint e
promover soluções para adaptar o que não estiver bom em busca de melhorar o que está impactando o
bom fluir do trabalho. Ou seja, adaptar o que não estiver permitindo a agilidade.
A técnica mais famosa e utilizada para promover uma reunião de retrospectiva é a técnica do WWW.
WWW quer dizer: What Went Well (o que deu certo) e What Went Wrong (o que deu errado) na sprint.
Essa técnica, para os que ainda não a conhecem, funciona da seguinte forma:
Primeiro momento da reunião
Cada membro da equipe anota em post-its os pontos positivos e pontos negativos de um sprint.
Pode-se usar cores diferentes para diferenciar os pontos positivos dos pontos negativos.
O Scrum Master é responsável por dar um limite de tempo para que a equipe fique focada no
objetivo de avaliar individualmente o que considerou bom e o que considerou ruim na sprint em
avaliação. 10 minutos é um bom tempo para manter a equipe concentrada nessa primeira etapa
da reunião. Claro que deavaliar o tempo necessário em função do tempo total que foi estipulado
para a retrospectiva.
Segundo momento da reunião
Cada membro da equipe apresenta os pontos positivos que levantou e a equipe discute sobre os
pontos levantados.
Após terem sido apresentados todos os pontos positivos, de todos da equipe, são os pontos
negativos que são apresentados um a um e a equipe discute sobre o problema em si e busca para
cada ponto uma solução a ser implementada para melhoria do problema.
O Scrum Master é quem apoia a equipe a concentar no objetivo principal da reunião: Levantar
soluções para melhorias.
A importância de dar soluções para os problemas
Não adianta a equipe discutir a reunião toda sobre os problemas de uma sprint e terminá-la sem
nenhuma proposta de solução para os problemas levantados. Os problemas permanecerão. O
Scrum Master deve conduzir a equipe para que ao final da reunião haja soluções concretas do que
será feito para melhorar cada ponto negativo. Claro que percebendo que a equipe não está
madura ainda o Scrum Master pode propor ideias para a equipe trabalhar, discutir e melhorá-las
de acordo com o que a equipe julgar melhor para a melhoria do trabalho deles.
Na reunião seguinte os pontos de melhorias acordados na reunião anterior devem ser revistos para
serem validadas as soluções que haviam sido propostas. Caso algo no processo tenha permanecido
da mesma forma é preciso pensar em novas soluções e tentar novamente na próxima sprint.
Técnicas para retrospectiva
Essa técnica apresentada é simples e eficaz, desde que não se perca de mente que o importante
de uma reunião de retrospectiva é avaliar o processo e ter propostas para melhorá-lo/adaptá-lo.
Há diversas outras técnicas para fazer uma reunião de retrospectiva, principalmente conforme o
projeto for avançando. O próprio Scrum Master percebe o momento de fazer outras dinâmicas e
promover uma reunião diferente em busca de fazer a equipe trabalhar melhor o processo da
retrospectiva.
Em outros posts, aqui no blog, apresentarei outras técnicas, para conduzir uma retrospectiva, que já usei
com as equipes em que sou Scrum Master.
Enquanto isso, pergunto a você: qual é sua avaliação referente a essa técnica de retrospectiva?
Compartilhe suas impressões com os demais, seja você Scrum Master ou membro da Equipe de
Desenvolvimento
http://blog.myscrumhalf.com/2012/06/gerencia-de-requisitos-no-mps-br/
Gerência de Requisitos no MPS.BR

Postado em 1 de junho de 2012 por Cláudio Pires, CSM, Consultor ProMove
Acredito que o maior desafio da Engenharia de Requisitos não está na

elicitação, na definição dos requisitos do cliente, do produto de software e de seus componentes.
Além do desenvolvimento dos requisitos, existe um esforço incansável de controlar sua evolução ao longo
de todo o projeto!
Assim, com base no Guia de Implementação Parte 1, Fundamentação para Implementação do Nível G,
procuro, nesse post, incentivar o debate e o alcance da competitividade pela qualidade, associando os
resultados esperados do processo de Gerência de Requisitos (GRE) com minha experiência de uso da
ferramenta ScrumHalf… perdoem minha curva de aprendizado e qualquer sugestão de melhoria
descabida, hehehe! 😉
Ao longo das práticas descritas a seguir, o mais importante é a percepção dos conceitos de
rastreabilidade, de impacto das mudanças, de critérios para aceitação e controle da mudança em
requisitos, garantindo um consistente alinhamento entre agilidade e maturidade.
GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de

requisitos.
Está lá, no painel "Participantes", a clara definição dos papeis, onde deve ser explicitado quem define e
altera os requisitos… os fornecedores de requisitos!
Daí, basta alternar para a aba "Product Backlog" para perceber a situação de cada história: proposta,
aprovada, concluída e a realizar.
Importante também é evidenciar a contínua comunicação dessa evolução! Fica, então, a dica para a
ferramenta incorporar, num ambiente totalmente integrado, a troca de mensagens associada a cada
história, sem recorrer à guarda externa de emails ou atas de reunião.
Por fim, a funcionalidade oferecida pelo Relatório de Product Backlog garante enorme ganho de
produtividade, pela economia do esforço manual na geração de qualquer documentação.
GRE 2. Os requisitos são avaliados com base em critérios objetivos e um

comprometimento da equipe técnica com estes requisitos é obtido.
Revisão por par é sempre boa prática… e rápida na detecção antecipada de defeitos!
Assim, além do desejado uso intensivo dos relatórios pré-configurados mencionados na prática acima, vale
também valorizar o uso de "checklists"… assunto discutido em vários artigos desse blog.
Que tal estender a situação "aprovada", diferenciando-a em demais comprometimentos: de revisão técnica
e de todo o time Scrum?
GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de

trabalho é estabelecida e mantida.
Os índices de identificação das histórias do Product Backlog são fundamentais para manter a desejada
rastreabilidade, desde as necessidades do cliente até o código-fonte… passando pelas evidências de
aderência à definição de história pronta do projeto (p.ex.: testes unitários, funcionais e de integração).
Em qualquer sistema de configuração, basta associar o "commit" ao ID da funcionalidade que está sendo
implementada.
Opcionalmente, uma integração do ScrumHalf com APIs do Subversion e Git, pode ser uma funcionalidade
"matadora", estabelecendo um "log" de plena visibilidade das atividades de construção relacionadas!
GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas

visando identificar e corrigir inconsistências em relação aos requisitos.
Adoro a marcação "bug", no formulário de edição da história!
Falta só associar qual critério (de revisão ou de aceitação) levou à tal marcação (viva os "checklists") e
incluir, no Relatório de Product Backlog, esse específico filtro…pra ficar 10!
GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
Aqui, a premissa evolutiva do Scrum já facilita a prática do modelo, pois só se planeja o horizonte
conhecido…não há mudança pro que ainda não está definido.
Mas, considerando os iniciais requisitos do cliente e eventuais alterações de rumo durante uma Sprint, o
bom uso das "tags" e da descrição podem satisfazer o resultado esperado, evidenciando uma "solicitação
de mudança" e sua respectiva análise de impacto para a história proposta.
Concluindo,
está claro por que recomendo a adoção da ferramenta, por que acredito em sua melhoria contínua e por
que admiro o trabalho de todos da GPE: o apoio a demais áreas de processo (como Gerência de Projetos,
Qualidade, Medição etc ) também é
http://blog.myscrumhalf.com/2012/05/filosofias-de-projetos-ageis/
Filosofias de Projetos Ágeis

Postado em 25 de Maio de 2012 por Fabrício Pereira, M.Sc., CSM.
Como em outro post já falamos de práticas ágeis de projeto, achei importante falar também das questões
filosóficas que norteiam tais práticas. Então vamos a algumas delas:
Projetos ágeis são emergentes, eles não são definidos de imediato. A visão completa de todo o
projeto será evoluída ao passo em que são levantados novos requisitos, e a medida que surjam novas
tecnologias que possam ser úteis. Assim, não se faz necessário criar uma documentação completa do
projeto antes de iniciar a implementação.
Os testes de unidade formam grande parte da documentação detalhada do projeto, ou seja,

são especificações executáveis. É também por esse motivo que o TDD (desenvolvimento dirigido a testes)
torna-se fundamental em projetos ágeis.
Basta que os modelos de projeto seja bons o suficiente, e que os detalhes de projetos sejam
ajustados à medida que se codifica.
Diversos modelos. Devido à complexidade inerente ao desenvolvimento de software, os

desenvolvedores necessitam de um amplo conjunto de modelos que permitam ter várias visões sobre o
mesmo projeto.
Normalmente, só é necessário um subconjunto dos modelos para cada parte do trabalho a ser
realizado durante a codificação do projeto.
Cada modelo pode ser usado para uma variedade de finalidades no processo de codificação.
Projetistas também deveriam codificar. Separar a fase de especificação do projeto da fase de

codificação do projeto é arriscado, e isso também inclui as pessoas envolvidas em cada fase.
Modelo à prova. Sempre que possível, é importante por o modelo à prova, antecipando possíveis
impactos ou obstáculos.
O feedback é seu amigo. Ser receptivo ao feedback, ou mesmo buscar ativamente o feedback, analisá-
lo e agir em conformidade tornará o sistema melhor (de forma reflexiva, será melhor recebido pelos
usuários), e provavelmente você irá aprender algo durante esse processo.
Às vezes, a ferramenta mais simples é uma ferramenta CASE complexa. Quando se trata de
formalizar os requisitos levantados em modelos, às vezes é melhor usar ferramentas sofisticadas que
possam gerar código.
Iterar repetidamente. Iterar entre as etapas, de forma que seja feito um pouco do trabalho em cada
uma delas, de acordo com o necessário, ou mesmo iterar de frente para trás trabalhando em vários
artefatos, cada um no momento certo.
Projetar é tão importante que deve ser feito todos os dias. Projetar não é apenas uma fase que se
realiza no início do projeto antes de se chagar ao “trabalho real” de codificação.
Projetar no ambiente de implementação com bastante sensatez. É importante fazer uso das
facilidades e recursos do ambiente de implementação, mas isso deve ser feito com muito cuidado para
que não faça o sistema perder a portabilidade e tenha problemas quando o mesmo for instalado ou
quando já estiver em produção.
Documentar o que for complicado. Se é complicado, então documente completamente, e invista um

tempo para projetar bem um modelo.
Sem excessos na documentação. Como existe uma linha tênue entre documentar e se exceder nisso,
apenas a prática lhe dirá como e até que ponto documentar.
Não se deixe enganar pelo pessoal tradicional em banco de dados. É importante compreender
que a estrutura da base de dados também irá evoluir com o projeto, ela não será estática.
Referências:
 Agile Design Practices: Lean Requirements Practices for Teams, Programs, and the
Enterprise, Pearson Education, http://www.agilemodeling.com/essays/agileDesign.htm.
(Leffingwell, D. – 2012)
http://blog.myscrumhalf.com/2012/08/scrum-nos-processos-tradicionais/
Scrum nos processos tradicionais

Postado em 6 de agosto de 2012 por Rafael Amaral - Analista de Sistemas / PSM I / Desenvolvedor web
Sabemos que utilizar e acompanhar um desenvolvimento de software numa metodologia é extremamente

importante para o sucesso do projeto. Melhor ainda é quando vemos que tudo está caminhando conforme
o planejado, isso acontece principalmente no início do projeto.
Porém, este "mar de rosas" raramente é o tal "felizes para sempre" dentro do ciclo de vida do projeto. As
opiniões mudam, a visão sobre o negócio muda, os stakeholders dificilmente concordam/aceitam o que
lhes são apresentados, e, em consequência disso, os requisitos também mudam, tudo muda. Sem falar
nos casos em que várias pessoas dentro da organização opinam (de forma diferente até sobre a mesma
visão) sobre o produto, deixando a equipe do projeto de cabelos em pé!
A partir desta situação, começa então gerar o caos dentro do processo que antes parecia tão "organizado"
e alinhado ao projeto e que agora se tornou um pesadelo gerenciar as estimativas, cronograma que não
pode estourar, custos, replanejamento, recursos humanos, etc.
Normal, não? Porém, as metodologias tradicionais podem não ter o suporte necessário para o
"gerenciamento" dessas mudanças. Isto ocorre devido às burocracias que fazem parte deste contexto, em
que na maioria das vezes, dão ênfase a tantos artefatos e deixam de lado a parte mais importante, o
porquê de sua existência, o produto em si.
Onde está o socorro?

No Scrum!
O manifesto ágil diz que:
 Software funcionando vem antes de documentação abrangente

 Colaboração do cliente vem antes de negociação de contrato
 Resposta às modificações vem antes de um plano em andamento
Ao contrário de que muitos pensam, o sinônimo de "Agilidade" não fará com que seu produto seja
entregue na metade do tempo de uma metodologia tradicional, ou de um dia para o outro. Ser ágil dentro
do Scrum, por exemplo, quer dizer à (não se limita):
 Responder rapidamente a modificações e solicitações

 Aperfeiçoar a previsibilidade
 Controlar/limitar os riscos
 Ser auto-organizável, sem depender de terceiros, o que pode ser dito como ser proativo, e
 Buscar uma contínua perfeição de trabalho para entrega de produto de mais alto valor possível
Os processos ágeis valorizam as modificações (mesmo que tardia) para vantagem competitiva do cliente.
Se você consegue responder rapidamente às mudanças de requisitos, provavelmente consegue retorno
mais rápido, em consequência, obtém como resultado um produto de mais valor para seu cliente.
O Scrum não é um processo e sim um framework onde se pode empregar vários processos ou técnicas.
Sendo assim, é possível aplicá-lo dentro de um processo já existente na sua organização, aderindo para as
novas terminologias.
Como exemplo, colocar em prática os eventos Scrum. Tais eventos são projetados para garantir a
previsibilidade e a transparência, de modo a criar uma rotina que garante reuniões centralizadas reduzindo
a necessidade de outras e o desgaste de tempo desnecessário dentro do processo. Também, promovem a
inspeção de modo que o Time Scrum avalie com frequência o progresso em rumo ao objetivo, adaptando-
se (como equipe auto-organizada) sempre que necessário, o que faz com que o Scrum seja totalmente
adequado para a solução dos problemas mencionados no segundo parágrafo.
O Scrum é leve e por isso não é preciso abandonar um processo já em uso, basta fazer uma adaptação
abrindo mão da tal "da cultura". Essa mudança diz respeito à (o que não se limita):
 Mais cooperação por parte de todos envolvidos e menos formalismo

 Proatvidade da Equipe de Desenvolvimento e autorização para gerenciar seu próprio trabalho
 Apoio e contato direto da participação do stakeholder de forma centralizada e representada por um
único integrante na pessoa do Product Owner
Seu processo atual não está dando conta do recado? Que tal transformar cada porção do tradicional
modelo de "Ciclo de vida" numa Sprint?
Você pode "inventar" o Scrum de várias formas, aplicando os papéis, eventos, artefatos e regras do
mesmo, enriquecendo seu processo tradicional com a eficácia das práticas Scrum.
Ser Scrum é desprender-se das coisas que engessam o processo e valorizar os pontos positivos de forma
que eles evoluam cada vez mais.
É criar e conduzir de forma produtiva o trabalho necessário para construção do produto.

http://blog.myscrumhalf.com/2012/08/diferencas-de-valores-ageis-e-tradicionais/
Diferenças entre valores ágeis e tradicionais

Postado em 15 de agosto de 2012 por Felipe Madureira, CSM.
Converso com muitas pessoas sobre o Scrum e obtenho as mais diferentes reações. Desde
entusiastas aos mais céticos, uma reação muito comum é “Meu chefe nunca vai concordar com isso”. Fico
pensando porque essa reação é maioria e uma das explicações que eu acredito é a drástica mudança de
desenvolvimento que o Scrum propõe quando comparados as outras metodologias, chamadas de
tradicionais. Quando colocadas lado a lado, encontramos focos e valores diferentes.
Uma grande dificuldade na implantação do Scrum é a mudança de hábito e de cultura da

empresa. Muitas vezes, a cultura existente é centrada no plano, ou seja, dá mais valor aos procedimentos
e métodos bem aplicados do que o valor gerado pelo resultado. Essa filosofia é chamada de
desenvolvimento movido ao plano, onde é dada muita importância aos artefatos bem construídos e etapas
bem realizadas. Esse tipo de desenvolvimento é muito difundido por diversas metodologias e existem
diversos motivos para elas continuarem existindo.
O Scrum se encaixa em outro tipo de desenvolvimento: O desenvolvimento centrado em valor. O

seu objetivo está em agregar valor ao cliente. Toda a estrutura do framework está montada para permitir
responder rapidamente a mudanças e se ajustar ao desejo do cliente.
No Scrum, o planejamento é considerado muito importante: Ter uma visão do produto é
essencial. No entanto, o plano, a maneira que será executado para atingir o objetivo esperado, não é.
Esse plano pode, e deve, ser alterado caso o objetivo mude, buscando atender melhor aos desejos do
cliente. Dessa maneira, ele está mais preocupado em fazer o software certo do que fazer certo um
software.
Podermos perceber nesse ponto que uma grande dificuldade na implantação do Scrum é essa
mudança da maneira de pensar da organização. No manifesto ágil é descrito o que as metodologias ágeis
consideram mais valiosos. É importante perceber qual o grau de concordância que a sua empresa tem
com esses valores para antecipar a dificuldade que será adotar o Scrum
A primeira adoção do Scrum é sempre traumática. Nesse ponto, acredito que seja melhor adotar
em pequenos projetos ou até mesmo dentro de um pequeno setor como experiência. A supervisão de
pessoas que já adotaram a metodologia antes com sucesso é muito importante para aumentar a chance
de êxito e tornar a metodologia bem vista diante toda a empresa.
http://blog.myscrumhalf.com/2013/08/os-principios-do-lean-startup/
Os princípios do Lean Startup

Postado em 21 de agosto de 2013 por Igor Araujo, Desenvolvedor Java Pleno da empresa Match Latam
Um termo muito comentado na comunidade

ágil é o Lean Startup. Esta filosofia vem ganhando espaço desde que foi criada, em 2008, e vem
aumentando o seu número de adeptos em muitas empresas de tecnologia. No post de hoje, apresentamos
uma breve discussão sobre os princípios do Lean Startup.
A ideia do Lean Startup surgiu a partir das experiências de Eric Ries como empregador, fundador e
assessor de startup. Esta filosofia é baseada no lean manufacturing, adotada nos anos 80 na indústria
automobilística japonesa, onde os esforços deviam ser concentrados na criação de valor para o cliente
final, evitando ao máximo os desperdícios. De uma forma mais prática, é uma forma das empresas
aprenderem com o cliente final, produzindo o que ele precisa e deseja.
O próprio ambiente de startup é um ambiente de incerteza sobre o cliente e sobre o produto final.
Portanto as chances de desperdício são grandes, pois não se tem certeza do que o cliente quer nem de
como vai ser a versão final do produto. Diante deste cenário, o Lean Startup atua como uma filosofia
interessante, principalmente para as empresas que ainda não conhecem bem seu cliente final nem como
vai ser o seu produto final.
O ciclo básico do Lean Startup pode ser visto na Figura 1. A partir de ideias é construído um produto. Uma
vez que este produto esteja construído, são feitas métricas sobre ele, gerando dados que serão analisados
trazendo aprendizado para a organização. A partir deste aprendizado as ideias são novamente
trabalhadas, reiniciando o ciclo.
Figura 1. Loop fundamental do Lean Startup
De acordo com Ries, o Lean Startup está baseado nos seguintes princípios:
Mínimo Produto Viável
É a versão mínima de um novo produto que permite que o time de desenvolvimento possa capturar mais
informações e aprender sobre as necessidades e expectativas do cliente final. Assim, o time aprende com
o cliente evitando esforços na criação de recursos desnecessários ou que não sejam do interesse do
cliente final. O mínimo produto viável é o V0, é a versão mínima de um produto final que vai sendo
concebido iterativamente.
Deploy Contínuo
O trabalho do time é continuamente disponibilizado para o cliente final. A ideia é que o período entre a
finalização da construção de um recurso e sua disponibilização em produção seja reduzido. Desta forma, o
trabalho do time pode ser mais rapidamente avaliado pelo consumidor final.
No contexto de desenvolvimento de software podemos encontrar diversas ferramentas para a

automatização do processo de deploy contínuo como Jenkins, por exemplo. Desta forma, o build do código
e o deploy em uma máquina de homologação ou produção poderiam ser feito automaticamente, sem a
necessidade de intervenção manual do time.
Estas ferramentas minimizam os esforços com tarefas operacionais, liberando o time para as tarefas mais
relacionadas ao negócio.
Teste A/B
É uma forma de disponibilizar diferentes versões do produto a determinados grupos de clientes.

A ideia é ter um feedback de como os clientes reagem sobre as diferentes versões do produto. Desta
forma a organização pode aprender mais sobre o que é melhor para os clientes e como estes vão reagir
diante dos novos recursos disponibilizados no produto.
Por exemplo, podemos testar duas possibilidades de tela de cadastro de uma aplicação, onde um grupo de
usuários verá uma tela com todos os campos do cadastro e o outro grupo visualizará uma tela de cadastro
reduzida, contendo apenas os campos básicos.
A partir da reação dos usuários diante destas diferentes possibilidades, a organização pode aprender o
que é melhor para o usuário, o que ele prefere. Poderia, por exemplo, perceber que no cadastro reduzido
mais usuários se inscrevem na aplicação e então passar a usar sempre a tela de cadastro reduzido.
Métricas Acionáveis
São métricas relativas aos pontos chave do negócio. São métricas que quando acionadas oferecem
informação necessária para que a organização possa tomar decisões sobre o negócio. Um exemplo de
métrica acionável seria a quantidade de acessos a um site a partir de um link de um parceiro. Esta é uma
métrica que permite avaliar o impacto que determinado parceiro tem sobre o site visitado, indicando para
a área de negócio se é interessante ou não manter a parceria. Estas métricas são importantes na medida
em que oferecem base para tomada de decisões de uma forma mais imediata .
Pivot
É uma correção de curso estruturada projetada para testar uma nova hipótese sobre o produto, negócio,
etc. O pivot pode ser visto como uma nova hipótese estratégica que requer um novo MPV para ser
testado. Pivots bem sucedidos levam a organização ao caminho de um negócio sustentável. É o pivot que
faz as organizações que utilizam o Lean Startup resilientes diante dos “erros”. Se a empresa estava em um
caminho errado, os pivots oferecem a ferramenta que ela precisa para corrigir e agilidade para encontrar
novos caminhos.
No post de hoje, discutimos os princípios básicos do Lean Startup. Vimos que seguindo estes princípios,
uma organização evita desperdício com esforços que não geram valor para o cliente final. Além disso,
vimos que com o uso do Lean Startup, as empresas aprendem a cada iteração, podendo inclusive mudar
de estratégia a fim de se manter sempre num caminho de crescimento.
E a sua empresa, usa a filosofia do Lean Startup? Segue algum(ns) dos seus princípios?
http://blog.myscrumhalf.com/2014/04/ate-quando-uma-equipe-scrum-precisa-de-um-scrum-
master/
Até quando uma Equipe Scrum precisa de um Scrum

Master?
Postado em 9 de Abril de 2014 por Paula Nascimento, CSM, Scrum Master, Analista de Sistemas em SERPRO
Esta é uma questão polêmica, de difícil resposta e que divide opiniões. Será que uma Equipe Scrum pode
realmente viver sem um Scrum Master? Há os que defendam que sim e os que imaginam que isso só é
possível na teoria. Mas já que é possível na teoria, por que temos tantas dúvidas de que na prática
também é possível?
A ideia de que o Scrum Master é "dispensável" pode ser concluída a partir da própria definição do seu
papel. Essa definição diz que o Scrum Master é um líder-servidor e sua responsabilidade se resume em
manter a Equipe Scrum no trilho do processo, buscando sempre alcançar melhorias que aumentem a
qualidade do trabalho e, por consequência, a satisfação da Equipe Scrum com o produto que está sendo
construído. Se o Scrum Master for espetacular, teoricamente, ele conseguirá levar sua Equipe a trabalhar
sem a necessidade do seu apoio e, logo, se tornará dispensável. Essa é a teoria.
Na prática, esse objetivo de tornar a Equipe independente do Scrum Master encontra impedimentos que
podem ser explicados pelo teoria de construção de um time, de Bruce Tuckman. Nessa teoria, a tarefa de
construir um time passa por 4 estágios, são eles:
1. Forming: neste estágio, o time está começando a se conhecer, todos estão animados, positivos e
querem construir um bom relacionamento com os demais. Nesse momento, o papel de um líder é
essencial porque ainda há muita incerteza em relação à papéis e responsabilidades de cada um.
2. Storming: neste estágio, é normal surgir questionamentos aos objetivos estabelecidos, além de
conflitos. Esses conflitos podem aparecer porque as características de cada membro da equipe começam a
florescer e podem começar a surgir frustrações com o andamento do projeto ou com o processo de
trabalho. Neste ponto, é preciso estabelecer claramente os processos de trabalho, os combinados e, de
fato, começar a construir a relação de confiança que deve existir em um time.
3. Norming: agora o time começa a se ajustar, a resolver seus conflitos e estabelecer uma relação de
respeito. As pessoas começam a se socializar mais, se ajudar mais e o compromisso com os objetivos do
projeto aumenta. Neste momento, é bom começar a delegar atividades e deixar que as pessoas do time
comecem a tomar responsabilidade pelo progresso atingido.
4. Performing: neste estágio é fácil ser parte do time, mudanças de equipe não alteram muito o
desempenho e novos desafios são bem recebidos e vistos como mais um degrau a subir para alcançar o
objetivo do time. É neste momento que o líder pode começar a se distanciar e focar em outros objetivos
de trabalho. O time já está pronto para seguir com o bom trabalho que está sendo realizado.
Há ainda um último estágio, Adjourning, que é quando a Equipe é desfeita, seja porque o projeto
acabou ou porque a Equipe foi desmembrada.
O que fica claro através dessa teoria é que, a medida que uma Equipe avança e amadurece, a
necessidade da existência de um líder para direcionar o trabalho e lidar com problemas e conflitos é cada
vez menor, porque a própria Equipe consegue se ajustar e se sair bem de situações inesperadas. Sendo
assim, ainda na teoria, se temos uma Equipe que está "performando", ela pode sim sobreviver sem um
Scrum Master porque ela será um time tão sólido e bem formado, que conseguirá seguir o processo
Scrum e produzir valor sem o apoio de um líder-servidor.
Depois de tudo que foi exposto, eu volto a perguntar: dado que temos uma Equipe que já trabalha
junto há bastante tempo, que já tem "no sangue" todos os conceitos do processo Scrum, que
já está performando, será que essa Equipe pode viver sem um Scrum Master?
Na teoria sim, mas na minha opinião não. É claro que essa Equipe terá um nível de independência do
Scrum Master muito maior e conseguirá seguir performando sozinha. O problema é que novos desafios
sempre aparecem e, acima de tudo, a Equipe está comprometida com o produto e não com o processo. O
processo é o meio que permite que eles atinjam o objetivo final estabelecido. O fato de não ter ninguém
na Equipe com este foco pode fazer com que situações inesperadas desvirtuem a Equipe do processo de
trabalho que está sendo bem realizado, e é possível até que isso leve a Equipe a regridir e deixe de
performar.
É claro que essa é a minha opinião e opiniões divergentes sobre este assunto podem existir. Por exemplo,
para você, até quando uma Equipe precisa de um Scrum Master?
Referências:
Scrum Guide
Forming, Storming, Norming, and Performing – Understading the stages of a team formation
Quem cuida do Scrum Master? As Scrumetes!!!
O Scrum Master é o cuidador do processo ágil Scrum. O Scrum Master

cuida do Time, cuida do PO, facilita o trabalho de todos da Equipe Scrum em prol da agilidade, qualidade
e entrega de valor para o cliente. Porém quem cuida do Scrum Master? Será que de fato ele
precisa de um vigia?
Essa frase: “Quem vigia os vigilantes?” é interessante e podemos usar sua essência para trabalhar o post
de hoje.
Vigiar não! – Confiar sim!
De um vigia certamente o Scrum Master não precisa. Afinal de contas, com a agilidade temos a
descentralização de gerências e autonomia para os membros da equipe ágil. Logo pra que vigia? O
objetivo não é vigiar, mas sim confiar.
O ponto é: a Equipe Scrum tem um cuidador dedicado para lhe apoiar no processo Scrum e seguindo a
essência da frase "Quem vigia os vigilantes?" será que o Scrum Master poder ter alguém de fora dessa
Equipe Scrum, ajudando-o a melhor olhar a "big picture" e lhe abrindo os olhos e dando apoio? Não será
algum efetivo e produtivo?
Pegando a essência da frase e aplicando ao Scrum teríamos algo do tipo: Quem apoia o que sempre apoia
a equipe?
Quem apoia o que sempre apoia?
Então, compartilho aqui com vocês um trabalho que vimos fazendo há um tempo e que tem trazido bons
resultados.
Semanalmente os Scrum Masters se reuniem com o objetivo de se apoiarem nos seus respectivos
trabalhos. Por um acaso os Scrum Masters das Equipes Scrum da empresa são todos mulheres. Logo
nosso grupo foi entitulado de “As Scrumetes”.
Como fazem as Scrumetes
Timebox
Como todo bom processo ágil nossas reuniões são timeboxed: semanalmente, no mesmo horário e por 1
hora. Isso favorece nos prepararmos previamente, ter uma pauta definida e sermos eficientes nos
assuntos que queremos discutir.
Claro, não somos de ferro, e quando nos juntamos temos 5 minutinhos para papos de "Laurinha"
(maquiagem, filmes, moda, etc). Tem sido uma boa forma lúdica e descontraída de abrir as reuniões.
Assuntos do mundo feminino são sempre motivantes! : )
Planejamento
Ao final de cada reunião confirmamos o agendamento da reunião seguinte e combinamos os itens previsto
para discussão na próxima.
Eventualmente, alguns dos itens da pauta podem mudar ao longo da semana, caso surja uma demanda
bem específica de ser trabalhada, porém ter um planejamento é sempre importante para direcionar e dar
foco ao trabalho.
Mais uma lição do Scrum aplicada ao nosso grupo.
Organização
Temos um grupo de email que nos ajuda a trocar figurinhas ao longo da semana, trocando material de
estudo e apoio ao nosso trabalho, além de ninguém ficar de fora das conversas. Todas as scrumetes
recebem o email.
O grupo de email também nos ajuda a concentrar nossas informações facilitando o acesso rápido quando
preciso.
Colaboração
Além do grupo de email uma wiki para os Scrum Mastes também é bem vinda. Começamos a nossa essa
semana! Como já é boa prática, entre todos os projetos da empresa, compartilhar conhecimento por meio
da wiki que temos, por que ficaríamos de fora?
Compartilhar conhecimento é uma ação desprendida e descentralizadora que agrega valor para quem dá e
para quem recebe.
A sessão das Scrumetes também terá por objetivo organizar material para capacitar futuros Scrum
Masters da empresa. Para quê começar do zero sempre que um novo Scrum Master entrar na empresa?
As informações contidas na wiki servirão de repositório para apoiar a empresa nesse processo de
capacitação.
Auto-organização
Como toda e boa equipe ágil a auto-organização também é um valor bem explorado no time das
Scrumetes. Nós definimos como trabalhar, como entregar, quem vai fazer, tudo entre a gente. Não tem
chefe nessa reunião : )
Todos ganham!
Essas reuniões foram iniciadas há cerca de um ano atrás apenas com 2 scrum masters. No início desse
ano ganhamos mais uma Scrumete para o grupo.
Scrum masters
O ritmo sustentável que imprimimos nessa reunião nos ajuda a não perder o foco do trabalho.
É comum o Scrum Master acumular outras funções e esse trabalho nos ajuda a não perdermos de vez o
foco no papel de Scrum Master, nos ajudando a melhor dividir o tempo entre nossas
atividades/responsabilidades.
Equipe Scrum
A equipe Scrum, com certeza, afinal essas reuniões são para melhorar o apoio a ser dado a equipe.
Um dos itens que permeia nossas pautas é uma Scrum Master trazer uma nova técnica de retrospectiva e
a experimentarmos entre a gente antes de fazer com nossas equipes. É uma forma de melhor
entendermos a técnica proposta para adaptarmos em função da necessidade de cada equipe e do
momento em que estão passando no projeto.
A Empresa
Passamos a conhecer também as outras equipes o que facilita na eventual substituição de Scrum Master,
quando um deles sai de férias ou fica doente.
Além do trabalho individual que fazemos com cada equipe temos material para também fazer um trabalho
maior que envolva a grande equipe que são todos da empresa em que trabalhamos. Podemos assim,
trabalhar mais as motivações de cada um sem perder o grande contexto.
E vocês Scrum Masters? Como coordenam o trabalho de vocês e como buscam apoio para a melhoria
contínua? Essa é uma das formas que fazemos, temos outras também e certamente há outras que você
pode compartilhar com a gente. Que tal?
http://blog.myscrumhalf.com/2014/06/o-cliente-nao-quer-o-que-pede/
O Cliente Não Quer o Que Pede

Postado em 25 de junho de 2014 por Geraldo Xexéo, D.Sc., CSM, Professor do PESC/COPPE/UFRJ e do
DCC/IM/UFRJ, membro do Conselho Técnico da GPE.
Esse é o segundo artigo inspirado na leitura do

livro "Conversations For Action and Collected Essays: Instilling a Culture of Commitment in Working
Relationships", Fernando Flores e Maria Letelier.
No primeira artigo (O Scrum Coordena Ações de Forma Completa) discutimos como os quatro ato de fala
essenciais para o sucesso de uma conversação para ação aparecem no SCRUM.
Lembramos que esses quatro atos de fala são:
1. o pedido do cliente,
2. a promessa do executor,
3. a entrega pelo cliente e
4. a aceitação pelo executor.
Uma questão importante no livro é sobre como os interesses do cliente devem ser endereçados pelo
executor quando tenta completar as condições de satisfação do cliente em relação à ação sendo tomada.
É importante entender que um cliente, quando solicita um objeto ou serviço, não está diretamente
interessado naquele objeto ou serviço, o que eu chamo em sala de aula como o "objetivo" do cliente, mas
sim em atingir alguma meta de negócio, o que eu normalmente defino como o "interesse do cliente".
Assim, quando um cliente solicita um relatório, por exemplo, não está propriamente interessado no objeto
relatório, mas sim na forma como vai usar as informações do relatório.
A questão importante é que os pedidos são normalmente feitos de forma objetiva, muitas vezes
escondendo deliberadamente as preocupações ou interesses do cliente. Assim, se um cliente deseja poder
estudar quais seus melhores clientes ele provavelmente vai pedir para a equipe um "Relatório de Venda
por Cliente, ordenado pelo valor comprado". A equipe, desconhecendo o verdadeiro interesse, vai fazer
exatamente esse relatório, atendendo as condições de satisfação explícitas, mas não atendendo condições
implícitas.
A solução para isso é não só entender O QUE deve ser feito, mas PORQUE deve ser feito.
Uma história do usuário bem definida deve dar essa informação ao desenvolvedor.
Consultando a página de Wikipedia para "user stories" é possível encontrar pelo menos quatro formatos
básicos. Não é de se espantar que três desse formatos não se preocupem apenas com o que deve ser
feito, mas também o porquê de estar sendo feito.
O formato original de uma User Story é:
Como <papel>, eu quero <objetivo/desejo> de forma a <benefício>
Assim nosso pedido deveria ser inicialmente:
— Como gerente, eu quero o relatório de vendas ordenado por valor, de forma a conhecer
meus melhores clientes.
Já podemos ver que a equipe poderia perguntar um pouco mais e propor outros relatórios, ou outras
formas de entregar a informação "melhor cliente", ou questionar qual é esse valor (receita total, lucro
total, período de tempo, etc…). Porém, como a verdadeira função do desenvolvimento é entregar valor,
Criss Matt sugere uma inversão:
Para <receber benefício> como <papel>, eu quero <objetivo/desejo>
No nosso exemplo:
— Para conhecer meus melhores clientes, como gerente, eu quero o relatório de vendas
ordenado por valor.
A diferença é pequena, mas podemos entender que o foco da frase muda do relatório para o motivo.
Finalmente, minha preferida usa o conceito do 5W.
Como <quem> <quando> <onde>, eu quero <o que> porque <porque>
No nosso exemplo:
— Como gerente, até o dia 30 de julho, para usar durante a reunião de vendedores, eu quero o
relatório de vendas por cliente ordenado por valor porque quero conhecer meus melhores
clientes.
E, após uma discussão hoje em uma reunião de projeto poderia ainda adicionar:
Como <quem> <quando> <onde>, eu quero <o que> porque <porque>, por
<quanto>
No nosso exemplo:
— Como gerente, até o dia 30 de julho, para usar durante a reunião de vendedores, eu quero o
relatório de vendas por cliente ordenado por valor porque quero conhecer meus melhores
clientes, por até 8 pontos de esforço.
Dessa forma, conhecendo os verdadeiros interesses do PO, a equipe pode realmente agir para melhorar o
projeto ao fazer sua promessa.
http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-scrum-glossario/
Aprendendo os Termos Scrum – Glossário

Postado em 3 de agosto de 2011 por Ester Lima de Campos, M.Sc., CSP, CSPO e CSM.
Product
Backlog?
Scrum
Master?
Gráfico de
Burndown? O
que
siginificam
todos esses termos?
Sou novo no Scrum e já esbarro com tantos termos novos! Preciso ter um
dicionário em mãos para entender todos esses novos termos?
Para facilitar a vida daqueles que estão se iniciando no Scrum, preparei um glossário com a explicação dos
termos mais comuns, utilizados no dia-a-dia do trabalho ágil.
Esse glossário pode ser usado para consultas rápidas, como também pode ser usado para dar uma visão
geral da metodologia Scrum que tanto vem sendo falada e utilizada nas comunidades ágeis de
desenvolvimento de software.
Aproveite o…
Glossário Scrum
Burndown Chart – O objetivo de um gráfico burndown é apresentar a porção de trabalho

finalizada em comparação com o trabalho planejado. Esse gráfico apresenta duas linhas: uma
representando o trabalho planejado caso fosse executado de maneira uniforme ao longo da Sprint
e outra apresentando o trabalho realmente já realizado pela Equipe de Desenvolvimento. É comum
a Equipe de Desenvolvimento usar esse gráfico ao longo da Sprint, para medir os pontos das
histórias finalizadas ao longo dos dias da Sprint e ter uma visibilidade do ritmo, verificando se está
adequado para atingir a meta da sprint, cumprindo com o que foi planejado.
Burnup Chart – O objetivo de um gráfico burnup é apresentar a evolução do trabalho em direção

ao produto final. Nesse gráfico são traçadas duas linhas, uma apresentando a evolução do
Product Backlog (esse pode aumentar a medida que o projeto vai sendo desenvolvido) e a outra
apresentando a evolução do que já foi realizado pela equipe durante as Sprints já realizadas. Ele
dá a visibilidade do andamento do projeto.
Dono do Produto – Ver Product Owner.

Equipe de Desenvolvimento – É um dos três papéis no Scrum. A equipe de desenvolvimento é
a responsável pelo desenvolvimento da Sprint, trabalhando nas Tarefas de cada História para a
finalização dos trabalhos.
Estimativa – Pontuação estimada do esforço necessário para implementação de uma História. As

estimativas podem ser em story points, seguindo a pontuação usada no planing poker.
Histórias – São itens do Product Backlog que representam parte do produto a ser
implementado. As Histórias devem conter uma descrição detalhada do que deve ser
implementado.
História Preparada – É uma História que já está preparada para ser estimada pela
Equipe de Desenvolvimento, a fim de poder ser incluída em uma Sprint. A definição
de "preparada" é elaborada em comum acordo entre Equipe de Desenvolvimento e PO.
História Pronta – Uma "História Pronta" é uma História executada na Sprint, pronta
para ser apresentada ao PO, para a sua avaliação. A história pronta é apresentada
ao PO na Reunião de Revisão, quando o mesmo pode aceitá-la ou não. A definição
de "pronta" é elaborada em comum acordo entre Equipe de Desenvolvimento e PO.
Impedimentos – Problemas que surgem durante a Sprint e que impedem a equipe de trabalhar
em ou finalizar alguma História. Os impedimentos são responsabilidades do Scrum Master, que
deve providenciar a remoção dos mesmos.
Meta da Sprint – A meta da Sprint é o que o PO espera conseguir ao final da Sprint e

que deve orientar o trabalho e os esforços da Equipe de Desenvolvimento durante
toda a Sprint.
Planning Poker -Técnica de para a estimação das Histórias do Product Backlog. É baseada no
uso de cartas, como no poker, que tem a seguinte numeração, adaptada da Série de Fibonacci: 0,
1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Pontos de História – Representa em pontos o esforço da Equipe de Desenvolvimento para

realizar uma História. Ver quais são os pontos em Planning Poker.
Product Backlog – Lista de itens, ou Histórias, que devem ser implementados para a criação do
produto desejado ou desenvolvimento do projeto.
Product Owner – É um dos três papéis no Scrum. O Product Owner é o responsável pelo Product
Backlog. Ele que define e prioriza as funcionalidades desejadas para o produto, ou as atividades
necessárias ao projeto, descrevendo-as em forma de Histórias no Product Backlog.
Quadro de Tarefas – Artefato utilizado pela equipe para apresentar o trabalho que deve ser
implementado pela Equipe de Desenvolvimento. A divisão mais comum desse quadro se dá
como uma matriz de 3 colunas que são: Tarefas a Fazer, Tarefas em andamento e Tarefas
Concluídas; e onde cada linha representa uma História do Sprint Backlog. No início da Sprint todas
as Tarefas estão concentradas na primeira coluna (Tarefas a fazer) e é esperado que ao final da
Sprint todas as Tarefas estejam na última coluna (Tarefas concluídas). O quadro de tarefas dá a
visibilidade do andamento dos trabalho ao longo da Sprint, pois é atualizado diariamente ou toda
vez que um membro da Equipe de Desenvolvimento assume a responsabilidade por dar
andamento a uma Tarefa de uma História.
Reunião de Planejamento 1
Reunião realizada no início da Sprint, para planejá-la.
Com participação obrigatória do Product Owner, do Scrum Master e da Equipe de

Desenvolvimento.
Duração máxima de 2 horas para Sprints de Timebox de 2 semanas.
Nessa reunião são apresentadas as Histórias Preparadas na sequência em que se

encontram no Product Backlog, e Equipe de Desenvolvimento e Product Owner
discutem a respeito de cada uma dessas Histórias, para esclarecimento dos detalhes do
que deve ser implementado e, se necessário, permitir o ajuste dos pontos estimados pela
Equipe de Desenvolvimento.
Ao final da reunião temos a Sprint criada com data de início e término, respeitando o
Timebox das Sprints e temos selecionadas as Histórias que farão parte do Sprint Backlog.
Normalmente as Histórias são incluídas baseadas nos pontos estimados e limitadas à
velocidade da Equipe de Desenvolvimento.
Reunião de Planejamento 2
Ocorre após a Reunião de Planejamento 1.
Reunião de planejamento dos trabalhos da Equipe de Desenvolvimento na Sprint.
Nessa reunião a Equipe divide cada História em Tarefas.
Essas tarefas podem ser anotadas em post-its e fixadas no Quadro de Tarefas para maior
transparência do andamento dos trabalhos ao longo da Sprint. Ou lançadas em software
que suporte o Scrum.
Reunião Diária
Reunião realizada diariamente, preferencialmente no início da manhã ou ao final do dia.
Com participação da Equipe de Desenvolvimento e do Scrum Master.
A reunião é realizada com todos os participantes de pé.

Com duração máxima de 15 minutos.
O objetivo dessa reunião é comunicar o andamento dos trabalhos deixando-o transparente

para todos da Equipe de Desenvolvimento.
É uma reunião curta para manter o foco na transparência e não na discussão técnica de
problemas e soluções.
É uma reunião onde os membros da equipe assumem compromissos com os demais.

Respondendo a 3 perguntas:
1. O que você fez ontem?
2. O que você fará hoje?
3. Há impedimentos no seu caminho?
Reunião de Retrospectiva
Realizada após a Reunião de Revisão.
Com participação da Equipe de Desenvolvimento e Scrum Master. O PO

participa apenas se convidado.
O objetivo é inspecionar a Sprint encerrada para permitir a adaptação.
Nessa reunião a Equipe deve levantar os pontos positivos e negativos da

Sprint e ao final da discussão deve-se ter como resultado final uma lista de
ações para melhoria do processo como um todo.
Reunião de Revisão
Realizada ao final de cada Sprint.
Com participação da Equipe de Desenvolvimento, Scrum Master e PO.
O objetivo dessa reunião é a Equipe de Desenvolvimento apresentar ao PO o que foi

realizado na Sprint.
O PO aceita ou não as histórias apresentadas, com base no que foi combinado no

planejamento da Sprint e na definição de História Pronta.
Scrum Master – É um dos três papéis no Scrum. O Scrum Master atua como facilitador da
Equipe de Desenvolvimento e auxiliar do Product Owner, ajudando na manutenção do Product
Backlog, removendo impedimentos e protegendo a Equipe de Desenvolvimento de
interferências externas, para garantir a produtividade e a eficiência do trabalho. É o Scrum Master
que procura assegurar o uso das práticas e valores do Scrum.
Scrum – É uma Metodologia Ágil para gestão e planejamento de projetos. Para mais
informações leia o post O que é Scrum? – FAQ Scrum.
Sprint – Representa um ciclo de trabalho no Scrum. Esse ciclo pode ser de 2 semanas, 3 ou 4
semanas, que é o Timebox das Sprints. As Sprints devem ter sempre a mesma duração.
Sprint Backlog – Lista de Histórias selecionadas para ser trabalhada em uma Sprint, de acordo
com a Velocidade da Equipe de Desenvolvimento.
Stand-Up Meeting – See Dailly Meeting.
Story Points – See Points of Stories.
Tasks – The Stories in each Sprint should be broken down into tasks that represents
a maximum of 1 working day of a member of Team Development. Therefore, Stories
should be broken down into smaller, one-day (maximum) Tasks .
TimeBox – The time scale set for the Sprint project.
Speed – Total points of Stories that the development team can run in a Sprint

SCRUM - Conceitos Metodo Agil

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

SCRUM - Conceitos Metodo Agil

Enviado por

Direitos autorais:

Formatos disponíveis

Sumário

O que é Desenvolvimento Ágil? – FAQ Scrum........................................................................3

O que é Desenvolvimento Ágil? –

O desenvolvimento ágil é qualquer processo de

Os principais valores do Manifesto Ágil são:

 Indivíduos e interações sobre processos e ferramentas;

1º Princípio do Manifesto Ágil –

“Nossa maior prioridade é satisfazer o cliente

2º Princípio do Manifesto Ágil – Vantagem Competitiva

"Mudanças de requisitos são bem-

Palavras-chaves: humildade, flexibilidade,

O Segundo princípio simplificado: Estamos

Mais do que isso: as mudanças surgem normalmente de alterações no mercado ou do

cliente entende mais do negócio do que nós e que

ele estabelece as prioridades,

dai-nos flexibilidade para entendermos que sempre

há algum requisito que pode ser substituído por

outro que maximiza o valor do produto.

3º Princípio do Manifesto Ágil –

O terceiro princípio do Manifesto Ágil aborda que a frequência da

No Scrum, a cada período de desenvolvimento, chamado de Sprint, um incremento do produto é

4º Princípio do Manifesto Ágil – Negócio e

Integração é o ponto chave do quarto princípio do manifesto ágil. A ideia é reunir

5º Princípio do Manifesto Ágil – Motivação

O primeiro deles é justamente a confiança dos superiores no trabalho

O segundo é o relacionamento entre a equipe e entre ela e seus superiores. Os

O ambiente de trabalho e os recursos disponíveis também são fatores de muita

Por último, mas não menos importante, o aprendizado. As pessoas atualmente

6º Princípio do Manifesto Ágil –

O método mais eficiente e efetivo de transmitir

Boa parte do conhecimento interno à uma equipe de desenvolvimento reside

Em muitas equipes as pessoas abrem mão da conversa cara-a-cara para utilizar

7º Princípio do Manifesto Ágil – Medindo o Progresso

No primeiro post relacionado

"Software funcionando é a medida de progresso, porque não há outra

A lista é enorme, quem trabalha com desenvolvimento de software conhece.

8º Princípio do Manifesto Ágil –

E, realmente, os processos ágeis promovem um desenvolvimento que é capaz de se sustentar ao longo do

Vamos analisar como os processos ágeis promovem esse desenvolvimento sustentável:

Iterações curtas (2 a 4 semanas) e software funcionando

Velocidade constante da equipe

Como a equipe consegue ao longo do tempo estimar melhor o esforço para

Descrições mais claras e objetivas favorecem estimativas melhores, que por

E recebendo software funcionando ao final de cada iteração o dono do produto percebe o

Scrum promovendo o ritmo constante

1. Inicia-se a iteração planejando o que será entregue ao final da mesma

2. Desenvolve-se o produto e diariamente a equipe se comunica na "reunião diária" do

3. Apresenta-se o produto incrementado

5. Dá-se início a outra iteração.

Trabalho saudável é outra forma de ler ritmo sustentável

9º Princípio do Manifesto Ágil – Excelência Técnica

Atenção contínua à excelência

O nono princípio do manifesto agil

A escolha correta da tecnologia

Quando falamos de tecnologia, precisamos falar também de excelência técnica.

A equipe deve ser capaz de monitorar a implantação correta do design e a escolha

10º Princípio do Manifesto Ágil – Simplicidade

“Simplicidade – a arte de maximizar a

Palavras-chaves: Simplicidade, valor agregado,

Numa rápida busca na Web encontramos boas

A aplicação desse princípio ao processo e ao produto irá reduzir o trabalho ao

“Dando às pessoas um simples conjunto de regras e encorajando a sua

E você? Tem ou já teve dificuldades com a arte da simplicidade em seus projetos?