Como contar Story Points (Pontos por

estória de usuário)
Postado em 2016/08/17 by Eli Rodrigues em Projetos Ágeis

User stories / Estórias de usuário

Estória de usuário é um conceito do mundo agile que consiste em descrever os requisitos de um
projeto na linguagem de quem vai usar. Por exemplo, se fosse um projeto para construir uma loja
(que já usamos no post sobre como fazer um mapa mental), poderíamos criar as seguintes estórias:
1. Como cliente, desejo comprar roupas de malhação
2. Quero um ambiente agradável, espaçoso, onde possa provar as roupas antes de adquiri-las
3. Desejo pagar com dinheiro, cartão e cheque
4. Desejo Poder receber os produtos que comprar na minha casa
A partir das estórias se faz o detalhamento das tarefas necessárias para cumpri-las, mas para planejar
um projeto, e poder fazer o acompanhamento depois, é preciso definir uma forma de medir.

Story Points / Pontos por estória de

usuário
Os story points são a forma de medir o tamanho de um projeto ágil. Basicamente, story points são
números abstrados que dão a ideia de proporcionalidade entre os requisitos (estórias). Sem muita
complicação, vamos ao passo a passo, usando a técnica do Planning Wall.

Estória mais simples

O cálculo de story points sempre começa pela identificação da estória mais simples. No nosso
exemplo, qual seria? Para definir a estória mais simples, é preciso refletir um pouco sobre como
serão implementadas. Analisemos uma a uma:
1. Bem, para comprar roupas é preciso ter produtos e um meio de pagamento. Há que se alinhar
com o Product Owner (PO) como se espera fazer a exposição dos produtos, caso contrário,
poderiam ser vendidos tanto pela internet quanto no porta malas de um carro. Digamos que
nosso cliente deseje apenas vender, sem especificar o local.
2. Para proporcionar um ambiente agradável, é preciso alugar/comprar um local e decorá-lo de
forma agradável (Provavelmente, num projeto real, seria melhor descobrir o que significa
“agradável”)
3. Para pagar com dinheiro não é preciso nada e com cheque também não, mas com cartão é
preciso uma máquina. Para isso, é preciso se cadastrar em algum banco e esperar o recebimento
do equipamento, pode demorar alguns dias.
4. Se o cliente quer receber em casa, é preciso fazer um cadastro e descobrir meios de entregar o
produto. Será entregue em todo o Brasil? apenas na cidade ou no bairro? Aqui também
falaríamos com o PO para descobrir e, para o exemplo, suponhamos que será feito apenas no
bairro e que o cliente aceita aguardar até 3 dias.
Ordenar por complexidade
Agora que já entendemos as estórias, vamos ordená-las por complexidade:

Acredito (e digo assim, pois o time teria que discutir em conjunto), ante a tudo que foi descrito, que
pela ordem de complexidade poderíamos ordenar as estórias como 1, 3, 4 e 2. 

Escala de complexidade
A escala mais comumente utilizada em projetos ágeis é a sequência de Fibonacci (Ahá, você achou
que não servia pra nada quando viu na escola, né?).

Ela é facilmente calculada, basta somar um número ao anterior, começando do número 1, veja só:

 1
 1+0 = 1 (quem vem antes do 1? é o zero)
 1+1=2
 2+1=3
 3+2=5
 5+3=8
 8+5=13
 E assim por diante.
Essa sequência é utilizada por ser uma escala não-linear, ou seja, quando você definir as pontuações
das estórias não poderá marcar uma estória com 4 dizendo que é o dobro de 2, ela só pode valer 3 ou
5.

Isso permite que haja variabilidade na estimativa e impede que se faça regras de três para estimar as
horas de trabalho, com isso, faz com que, ao longo do projeto, as pessoas se foquem mais no valor
agregado (em quantos pontos foram terminados) que no esforço empenhado em fazer o trabalho.
Afinal, esforço sem resultado não serve para nada.

Definindo a pontuação das estórias

Agora que já temos um sequenciamento entre as estórias, conhecemos a escala de Fibonacci
e entendemos o princípio das escalas não-lineares, vamos juntar isso tudo:

Explicando o raciocínio:

 A estória 1 é a mais simples, por isso ganha 1 ponto.

 A estória 2 tem o dobro de complexidade na minha opinião.
 Na estória 4, pensei que conseguir motoboys, pagar seguro das motos e de vida etc, poderia ser
bem complicado. Em relação à estória 3 que consiste em conseguir uma maquinha de cartão de
crédito, achei que seria 4x mais complexa.
 Já na estória 2, a última e mais complexa de todas,  pensei em todo o processo de alugar um
imóvel, documentação, corretor, decoração, móveis etc. E entendi que ela seria o dobro de
complexidade da anterior. Mas o dobro não existe, então me restaram as opções: 13 pontos ou
21. Achei que 21x mais complexa que a estória 1 seria demais… e, por fim, optei por marcar
com 13 pontos.
—
Como fazer um Mapa Mental (exemplo
da loja de roupas)
Postado em 2016/07/16 by Eli Rodrigues em Comunicações

Há algum tempo falei sobre o Freemind, um software gratuito para desenho de mapas mentais. Hoje,
vou falar sobre o processo de construção do mapa mental, por onde começar e como estruturar,
passo a passo.
O mapa mental começa com uma folha em branco e não há uma única forma de estruturá-lo. Antes
de mais nada, deve-se definir um propósito: sobre o que você deseja falar?

Para algumas pessoas, uma folha em branco é um paraíso, um campo onde as ideias podem brotar.
Para outras, um grande problema, pois sentem dificuldades no pensamento conceitual. Trazer à
realidade coisas que estão apenas na sua cabeça nem sempre é uma tarefa trivial.

Para exemplificar, pensar juntos sobre como construir uma loja de roupas?
Bem, eu não entendo muito sobre lojas de roupas, então teremos que pensar juntos. OK?

1 – A primeira coisa que eu gostaria de pensar é sobre onde vou conseguir as roupas para vender, o
que chamarei de Fornecedores.
Bem, eu acho que roupas podem ser compradas em fábricas ou em distribuidoras, então vou
adicionar esses itens aos mapas também.

Mas peraí… como vou saber quem são os fornecedores se ainda nem escolhi os produtos? Melhor
colocar os produtos no mapa então.
Puxa vida! Não sei quais produtos vender ainda, pois não sei o que as pessoas querem comprar. Para
definir isso, acho melhor fazer uma Pesquisa de Mercado, mas para fazê-la, preciso definir onde será
a loja. Vamos lá:

Defini que será uma loja de roupas na Zona Oeste de São Paulo e as ideias começaram a clarear…
no entanto, a ZO é uma área muito grande, que possui populações de todas as classes sociais. Então,
para cercar um pouco mais o escopo de atuação, resolvi atender à classe média.

Mas minha segmentação ainda não está completa, pois posso atender homens, mulheres e crianças,
vamos ter que fechar um pouco mais o escopo. Que tal atendermos ao público feminino?

Hum… agora já sei mais ou menos quem desejo atender, mas ainda falta definir qual das facetas de
uma mulher de classe média queremos atender. Que tal se atendermos às fitness, aquelas que gostam
de fazer academia e exercícios?
Bem, definido isso, acho que já podemos pensar nos produtos.
Como não sabia exatamente quais produtos vender, procurei no Google e olha só o que eu
encontrei: concorrentes, muitos concorrentes!

Caramba, com tanta gente concorrendo, acho melhor mapear algumas da minha região de atuação,
sejam eles players próximos, shoppings, grandes lojas ou lojas online.
Agora que já tenho uma ideia dos concorrentes, seria justo fazer um benchmarking para descobrir
quais podem ser meus diferenciais. O que posso oferecer que eles já não ofereçam? preço?
diversidade de peças? entrega em casa? atendimento?
Com tantas lojas grandes vendendo peças baratas e entregando em casa, acho melhor investir num
atendimento diferenciado…

Pensei em peças sob-medida, mas a maioria dessas peças já é elástica. Pensei também em roupas
para pessoas mais rechonchudas, mas talvez não seja uma boa ideia. Cheguei até a pensar em peças
para pessoas mais velhas ou que não queiram mostrar o corpo, mas para isso, basta uma camiseta e
uma toalha (opa, mais um produto).

Então resolvi fazer um atendimento diferenciado, vamos ver como ficou o mapa mental:

Legal, começou a tomar forma! Percebi também que precisaria de canais de vendas, que poderiam
ser feitos através de parcerias com academias, médicos, nutricionistas e até com vendedoras
autônomas, ideias que vou avaliar mais tarde.
Para que mais serve um mapa mental?
Bem, acho que você já entendeu. O mapa mental serve para auxiliar no processo de conceituação de
uma ideia, não precisa necessariamente ser o esboço de um plano de negócio, como fiz aqui, poderia
ser a estrutura de um projeto, livro, aula, produto, festa ou o que você quiser.
Vale a pena baixar o aplicativo SimpleMind no celular, já que o freemind não tem versão mobile.
Assim, sempre que tiver uma ideia nova, poderá estruturá-la e depois exportar para o computador,
enviar por e-mail ou imprimir.

Calculando o prazo de um projeto Scrum

Postado em 2016/06/19 by Eli Rodrigues em Projetos Ágeis

A grande pergunta de todo projeto: Quando vai terminar?

É comum as partes interessadas quererem saber quando o projeto vai terminar, por isso constroem-se
cronogramas nas metodologias tradicionais.

Sabe-se, no entanto, que a maioria dos projetos não cumpre os prazos e isso se dá a várias “doenças”
e erros que os projetos trazem consigo, geralmente ligados ao comportamento ou a estrutura (Leia
mais no livro 21 erros clássicos da gestão de projetos).
O Scrum, no entanto, se atém ao que é realmente possível fazer, sem sambarilove. Se não é possível
calcular com exatidão a data final de um projeto, por que tentar? Por isso, o Scrum usa o conceito
de timebox, em que o tempo é fixo e o escopo é variável.
Esse conceito tem a ver com o estudo que mostra que, no mundo dos softwares, apenas 20% das
funcionalidades são realmente utilizadas. O cliente pede sempre muitas coisas, mas no final utiliza
somente algumas.

Cabe a nós, como Scrum Masters, auxiliarmos nossos clientes na priorização do que é mais
importante para seu negócio, ao invés de apenas cumprir prazos (e sofrer pressões) para criar
coisas que sequer serão utilizadas.

Doenças do prazo
Alguns diriam que têm metas a cumprir, datas de lançamento de produtos, que os projetos já estão
começando atrasados e que, por isso, é necessário ter um controle rígido de prazo. Mas todos
sabemos que um recurso sob pressão sempre colocará “gordura” no prazo quando estimar e, quanto
mais pressionarmos, mais gordura colocará.

Lei de Parkinson

Sabe-se, pela lei de parkinson, que o esforço sempre se enquadra ao tempo disponível. De modo que
se um programador estimar 3 dias para fazer um trabalho, o fará em, no mínimo, 3 dias, ainda que
pudesse fazer em menos tempo.
Em contrapartida, se for pressionado a assumir uma estimativa de 1,5 dia (metade do tempo), ainda
que pudesse fazer em 1 dia, levará, no mínimo, o tempo que foi obrigado a estimar.

E como se não bastasse isso tudo, na próxima estimativa, sabendo que será pressionado a cortar o
tempo pela metade, estimará 6 dias (o dobro) para que você – “espertalhão” – possa pedir a redução
sem tirá-lo da zona de conforto.

É um jogo de gato e rato que mais lembra os desenhos do Tom e Jerry.

Por isso, as metodologias ágeis usam escalas não-lineares para calcular o tamanho do projeto e, a
partir dele, seu prazo. Em outras palavras, o prazo se calcula pela velocidade média do time, livre
das pressões que modificam os comportamentos de forma nociva.

É o que chamo de “liberdade no cercadinho”, a “criança” pode brincar com o que quiser, desde que
seja dentro do espaço que lhe foi delimitado. Em outras palavras, o programador poderá determinar
a ordem de complexidade, mas a gestão do tempo se dará diariamente, sem que ele fique no controle.

Calculando o prazo de um projeto

ágil

Estimando o tamanho do projeto

Uma das técnicas para cálculo dos story points é o Planning Wall. Nela, você deve
primeiramente listar as estórias de usuário,  geralmente numa parede usando post-its.
Em seguida, devem ordená-las por complexidade, ignorando-se o fator tempo (não se atenha se os
itens que escolhi são realmente mais complexos, é apenas um modelo ilustrativo).

Por último, deve usar uma escala não-linear para pontuar cada estória, como a sequência de

Fibonacci, por exemplo.

Com isso, você terá o tamanho do projeto: 1+2+5+8+13+21+34 = 84. Este número será utilizado
para medir o progresso.

Progresso x Velocidade
Mede-se o tamanho do projeto e não o prazo, pois, no Scrum, não importa quanto tempo passou e
sim o quanto foi concluído (Leia mais em Como saber se a entrega está pronta mesmo).
Daqui nasce a diferença entre progresso e velocidade:
 Quanto mais estórias o time terminar, mais o projeto PROGREDIU. Ou seja, mais próximo está
de terminar todas as estórias.
 Quanto mais rápido o time terminar, mais VELOCIDADE  ele está alcançando.

Calculando a Velocidade do time e o Prazo do projeto

Então, digamos que foi definida uma duração de 2 semanas para cada sprint e que é provável que o
time faça as 2 primeiras estórias na sprint 1, mas que, se sobrar tempo, podem começar a trabalhar
na terceira estória.
As duas primeiras estórias são, portanto, a meta da sprint e devem cumprir o objetivo traçado para a
primeira sprint. A terceira estória é desejável, se der tempo, o projeto avançará (terá progresso) mais
rapidamente.

Usando o tempo como medida

No planejamento da sprint, o time desdobra as atividades necessárias para finalizar cada estória. O

quadro (sprint backlog) fica mais ou menos assim.

Aqui temos um primeiro insight: Duas semanas têm 40 horas por pessoa. Se consideramos 3 pessoas
no projeto, já começou a sobrar tempo.
Simulando sprint 1
Então, duas semanas depois, chega-se ao seguinte sprint burndown:

Pergunto: Terá o time avançado na velocidade esperada? Houve dificuldades no meio do caminho?

O que fez com que a primeira semana fosse mais rápida que a segunda?

Pois é, na prática as coisas são um pouco diferentes.

Nesse projeto, já se conhecia um fornecedor de móveis, então as etapas de seleção de fornecedor e

contrato foram mais rápidas. As aprovações da sala de espera (segunda estória) demoraram mais que
o previsto, pois o Product Owner  não havia passado informações detalhadas do que gostaria de
fazer. Por isso é importante o conceito de definition of ready, para que só se aceitem estórias que já
tenham suas definições bem planejadas. Passar o trabalho do PO para o time reduz a produtividade.
Qual foi a velocidade do time?
3 story points (das duas estórias) por sprint. Sendo assim, o projeto terminará em:

 84 sp / (3sp/sprint) = 28 sprints
 Como cada sprint leva duas semanas => 56 semanas ou 14 meses.
Pergunto: Mas, será que a velocidade será constante nas demais sprints? Será que as atividades mais
demoradas já não foram cumpridas? Será que a integração do time melhorará nas próximas rodadas?

Não se sabe.

Por isso, é importante acompanhar algumas sprints para se ter uma ideia mais concreta de qual será a
velocidade média. Vamos simular?
Simulando as sprints 2 e 3
Digamos que na segunda sprint, o time tenha concluído a estória  “Sala de reunião” e na terceira
tenha concluído a estória  “elevador”. Como ficaria a velocidade média?
 Sprint 1 = 3 story points
 Sprint 2 = 5 story points
 Sprint 3 = 8 story points
 Média = (3+5+8)/3 = 5,33 sp/sprint
Perceba como é mais coerente considerar a variação de produtividade ao longo de várias sprints, por
isso se considera sempre a média (ou média móvel, se preferir) para estimar o projeto.

Como ficaria o prazo do projeto considerando a perspectiva da

velocidade média?

 Quantidade total de story points = 84

 Quantidade de story points já realizados = (3+5+8) = 16
 Quantidade restante de story points = (84-16) = 68
 Tempo total do projeto, após a revisão = 68 / 5,33 = 12 sprints
 Em termos de prazo, ficaria em = (12 sprints * 2 semanas para cada) / 4 semanas por mês = 24
semanas ou 6 meses.
Pois é, num ambiente convencional, ao término da primeira sprint já se estariam fazendo reuniões de
melhoria, o time teria levado muitas broncas e provavelmente alguém acabaria saindo da equipe, o
que derrubaria ainda mais a produtividade.
Como acompanhar a velocidade do time?
A velocidade do time é medida por quantos story points aquela equipe conseguiu fazer num período
fixo. Os story points, no entanto, são medidas comparativas entre estórias de usuário, que usam
escalas não-lineares.
Deste modo, ao comparar uma estória de usuário com outra, o time é obrigado a escolher, por
exemplo, entre 8 e 13, de modo que uma estória que valha 8 story points pode acabar levar mais
tempo que outra com o mesmo valor. Isso serve para que o time “perca a noção do tempo exato”
para fazer uma estória e acabe focando-se nos resultados.
Esse é um dos grandes segredos do acompanhamento ágil, foco nos resultados.

Para acompanhar a velocidade, deve-se usar um gráfico de controle, como o exemplo a seguir.
As linhas em vermelho mostram os limites superior e inferior, apenas como alerta para que o Scrum
Master avalie se houve um potencial desvio. Basicamente, o gráfico de velocidade serve para dar
uma noção do prazo do projeto, mas sem certezas, afinal, o Scrum foca em resultados não em
estimativas.

Usando a quantidade de tarefas como medida

Uma outra forma de controlar o andamento da sprint é por quantidade de atividades. Ela é mais
rápida e mantém as pessoas focadas no que deve ser feito e não em quanto tempo levará para fazer.

O burndown tem o mesmo formato do gráfico baseado em horas, mas, retrataapenas atividades

concluídas.
Se lembrarmos da diferença entre progresso e velocidade, notaremos que “terminar uma atividade
não significa finalizar o trabalho (a estória), afinal, a atividade pode não ter dado certo.
Talvez lhe incomode não saber as horas que o time gastou com cada tarefa, mas isso é realmente
mais importante que o resultado?

O andamento do projeto é acompanhado na daily meeting e o tempo que se investe estimando horas

é desperdiçado em relação ao tempo de execução.

Usando story points como medida

Para os mais radicais, nem mesmo estimar a quantidade de tarefas é justificável. Preferem apenas
listar as estórias de usuário daquela sprint e seguir para a execução.

Quando se têm um grande número de estórias, o gráfico faz mais sentido. Mas, de qualquer forma,
só haverá progresso quando uma estória for 100% concluída, ou seja, quando atender a definition of
done.

Acompanhando o Progresso do projeto

Agora voltando ao product backlog: Como o Product Owner deve acompanhar o progresso do
projeto?
Ao final de cada sprint, deve atualizar o gráfico de burndown, mostrando quantos story points foram
finalizados, conforme o exemplo.
Replanejamento a cada sprint

Seria sensacional se os projetos seguissem uma linha reta, mas na prática, o PO (Product Owner)
decidirá, a cada planejamento de sprint (sprint planning), quais estórias permanecem, quais serão
simplificadas e quais serão adicionadas.
Em termos práticos, a estória “Negociação” poderia ser “repriorizada” para entrar na quarta sprint.
Ela também poderia ser “simplificada”, reduzindo sua complexidade para caber no prazo. Tudo pode
acontecer, afinal, é um projeto ágil!

Finalizando o projeto no Scrum

Então chegou o grande dia, o tempo do projeto acabou. Chegou 3/9/16 e na segunda-feira que vem
será o lançamento do produto.

Mas, peraí… o escopo não foi totalmente concluído! Quem é responsável por isso? A quem vamos
demitir?

Embora esse seja o pensamento tradicional, presume-se que no Scrum, o PO tenha colaborado com o
time durante todo o projeto e teve a visão exata do que havia sido concluído a cada sprint. Foi ele
quem decidiu, com base no seu conhecimento de negócio, quais estórias eram prioritárias e também
foi ele quem avaliou cada entrega.
Deste modo, espera-seque esteja satisfeito com o resultado, ainda que o escopo inicial do projeto não
tenha sido concluído. Pois, se não estivesse, teria apontado isso durante o projeto.
O mais comum é que o product burndown finalize com algumas estórias não implementadas, seja
porque o prazo terminou ou porque não houve interesse em seguir com elas. Mas, não se preocupe,
na segunda-feira tudo que foi produzido irá ao ar e não haverá surpresas no último dia.

Uma mudança de paradigma

Para que o Scrum funcione adequadamente é preciso, principalmente, a definição clara dos

papéis atuantes no projeto e para que o resultado seja satisfatório é preciso um acompanhamento
muito próximo do PO e muito realismo em relação ao que é possível ser feito. Isso é o que chamo de
“parceria”.
Se qualquer dos papéis não se adaptar a esse novo modelo de trabalho, seja pela necessidade de
microgerenciamento, seja pelo desejo de participar de todas as reuniões ou simplesmente pela
atitude de fechar os olhos e buscar culpados quando o impossível não for concluído, é melhor não
tentar usar o Scrum como bode expiatório.
Muitas e muitas empresas pelo mundo têm usado Scrum. Se nesta ou naquela não funcionou, está na
hora de rever os conceitos e mudar o paradigma de trabalho. Quando houver foco em resultados e
confiança mútua, certamente qualquer modelo de trabalho funcionará melhor.
Como organizar o Product Backlog
Postado em 2016/09/04 by Eli Rodrigues em Projetos Ágeis

Product Backlog / Backlog de Produto

O Backlog de Produto (Product Backlog) é um artefato utilizado em projetos Scrum que serve para
listar, descrever, priorizar, organizar e medir o desenvolvimento de um produto.
A base de sua estrutura são as estórias de usuário (user stories), que nada mais são que requisitos na
visão do usuário. Ex:
1. Como cliente, desejo comprar roupas de malhação
2. Quero um ambiente agradável, espaçoso, onde possa provar as roupas antes de adquiri-las
3. Desejo pagar com dinheiro, cartão e cheque
4. Desejo Poder receber os produtos que comprar na minha casa
Os estórias são escritas na visão do usuário para que, ao final do desenvolvimento, se tenha algo útil
ao usuário e não apenas uma funcionalidade com uso técnico. Por exemplo: uma “API de conexão
com um sistema de contas-correntes” não tem valor direto para o negócio, ao passo que “buscar
clientes com contas negativas” pode ter algum.

Prioridade de negócio
Imagine que deseja montar uma loja de roupas de artes marciais, qual o primeiro passo?

Normalmente as pessoas respondem: Alugar um local. No entanto, o primeiro objetivo da loja é

vender e para fazer isso não é preciso um local, mas as roupas.

Na primeira sprint, o objetivo deveria ser comprar roupas, colocar no porta-malas do carro e parar
em frente a alguma academia para começar, imediatamente, a venda. Isso é valor!
Na segunda, já com algum dinheiro em caixa, poder-se-ia procurar fornecedores com maior
qualidade por um menor preço. E na terceira, começar a procurar um local bacana para fazer a loja,
já conhecendo o mercado e suas peculiaridades.

Portanto, o valor de negócio é diretamente relacionado ao objetivo final e, para ter o maior retorno
no menor tempo possível, o projeto deve ser estruturado para testar o conceito primeiro, antes de
fazer maiores investimentos. É o que o mercado chama de MVP (minimum viable product).
Se o dono do produto (product owner) descobrir que seu objetivo é inviável, poderá parar o projeto
sem tantos prejuízos. Num projeto tradicional, as primeiras semanas seriam de planejamento,
enquanto num projeto ágil, seriam de venda. Isso tem mais a ver com a filosofia que com a
metodologia utilizada.

Organização em Sprints
Uma vez que tenha listado as estórias de usuário, é preciso medir os pontos por estória de
usuário (story points) para encontrar o tamanho do projeto e organizá-lo em sprints.
No começo do projeto, não se sabe ao certo quantos story points o time será capaz de fazer por
sprint. Deve-se, portanto, passar uma meta e verificar o quanto conseguem fazer ao longo de
algumas sprints e, só então, se poderá calcular a velocidade do time. Apenas com a velocidade real
do time, o product owner passará a ter algum nível de previsibilidade.
No Scrum, ao invés de fazer um cronograma, usa-se o conceito de Time Box, em que o tempo é fixo
e o escopo é variável. Com esse conceito, pode-se economizar bastante tempo de planejamento, mas
perde-se a sensação tradicional de controle do tempo. Em outras palavras, o time vai fazer o melhor
possível no tempo disponível.

Medindo a evolução do Product

Backlog
Para acompanhar o projeto é preciso um quadro que mostre os pontos previstos x realizados em cada
sprint e a velocidade do time. Com esses dados é possível medir quando o projeto terminará (ETC –
Estimate to complete), o que embasará o PO sobre a adição, redução ou modificação de estórias ao
longo do projeto.

Explicação dos campos:

 A linha cinza mostra quantos pontos estão previstos para cada sprint
 A linha rosa mostra quantos foram realizados
 Os SPs (story points) acumulados serve como base para o cálculo das sprints restantes
 As horas nesse exemplo totalizam 5 pessoas trabalhando 8 horas/dia em sprints de 10 dias
 A produtividade serve para avaliar a distribuição da carga de trabalho
 As Sprints Restantes mostram quanto falta para o projeto acabar (em sprints)

Product Burndown
Outra ferramenta bastante utilizada é o product burndown, que mostra o trabalho restante em story
points  e deve mostrar a relação entre o previsto e o realizado.

Com esse gráfico, pode-se acompanhar avaliar riscos do projeto não cumprir a data e tomar ações
preventivas (e corretivas) para mantê-lo nos eixos.
Cerimônias e papéis do Scrum: Quem
faz o que e quando
Postado em 2016/09/30 by Eli Rodrigues em Projetos Ágeis

Nos projetos em que tenho atuado com Scrum, tenho visto frequentes confusões sobre
as responsabilidades de cada papel e sobre o tempo em que devem atuar.
São product owners que não escrevem as estórias de usuário e não determinam a prioridade
de negócio, times  que não contam story points  e scrum masters sem visão do prazo do projeto.
Não bastasse isso, tenho visto implantações confusas em que os pilares do Scrum não
são observados.
Tudo isso leva as iniciativas a “morrerem na praia” e causa descrenças sobre a filosofia
ágil que poderiam ser evitadas se o entendimento ficasse mais claro. Por isso, no intuito
de resumir as responsabilidades e o tempo em que as tarefas devem ser executadas,
construí dois infográficos que facilitarão a lembrança e, por consequência, a execução dos
projetos Scrum.

Responsabilidades – Quem faz o que?

A imagem abaixo, você poderá encontrar as principais etapas de um projeto Scrum e
os papéis do product owner  (PO), scrum master  (SM) e do time.
Para cada etapa, foram separados “momentos” na intenção de demonstrar que existe
um overlap  no tempo de execução, que espero clarear no tópico seguinte.

Responsabilidades – Quando?
O  próximo infográfico (gantt-like) mostra onde há sequenciamento e onde há paralelismo
nas cerimônias (rotinas) do projeto.
Os papéis do Scrum e suas facetas
Postado em 2016/06/01 by Eli Rodrigues em Projetos Ágeis

O porco e a galinha
Muito se discute sobre os papéis e responsabilidades das pessoas comprometidas (e envolvidas) num
projeto Scrum e para começar a explicação, vale relembrar a velha estorinha do porco e da galinha:

A galinha (envolvida) dará seus ovos para construir o restaurante, enquanto o porco (comprometido)
terá que dar sua carne.

Essa piadinha antiga demonstra que num projeto há pessoas que têm responsabilidade pelo resultado
do projeto e outras que apenas participam. Sendo mais direto: Se o projeto não der certo, você será
demitido ou, na verdade, você apenas participou dando sugestões?

Um exemplo para ilustrar:

Jonathas, Pedro e José são programadores de um único projeto. Seu trabalho é construir um
aplicativo mobile dentro de determinado escopo e parâmetros de qualidade. Como é um projeto
Scrum, há um prazo estimado, mas a velocidade do time dependerá do acompanhamento diário para
gerar uma projeção mais realista de prazo. Isso, é claro, se não houver impedimentos pelo caminho
que impactem nessa velocidade.

Carlos é o Scrum Master. Ele dedica todo seu tempo, da hora que acorda até dormir, pensando no
projeto. Seu trabalho é proteger a equipe de intervenções externas e garantir que o escopo
(estórias) de cada sprint virem realidade toda sexta-feira.
Manuel é o PO do projeto. Ele vendeu a ideia internamente na empresa, conseguiu a verba para fazê-
lo e tem uma visão bem clara de onde deseja chegar. Suas metas são atreladas ao resultado daquele
produto que, quando pronto, deverá economizar 5 milhões para sua empresa. Se tiver sucesso, será
promovido. Se fracassar, será demitido.

Miguel, Orlando e Roberto são do departamento de marketing. Eles adicionaram várias ideias ao

projeto. Pretendem utilizar o app quando ficar pronto para fazer uma campanha publicitária e foram
provedores de 30% do orçamento. Se tudo der certo, vai ser ótimo para eles, mas se não der…
coitado do Manuel… que não entregou.
Pois é, alguém tem que pôr o pescoço na mesa para garantir que algo dê certo. E nesse caso, seriam a
equipe, o Scrum Master e o PO. Os demais são apenas envolvidos (partes interessadas
ou stakeholders, como preferir).
Essa separação é importante para as explicações que virão a seguir.

Por que os papéis do Scrum existem?

A figura abaixo ilustra os papéis citados na parte anterior. Observe a separação, os envolvidos ficam
fora das decisões do projeto, eles apenas influenciam e sugerem. É claro que um envolvido
superpoderoso será capaz de impor sua opinião, mas essa gestão política é exatamente trabalho do
PO.

Com um único PO, o projeto tem apenas um objetivo, um conceito, um senso de prioridade e de
qualidade. O Scrum Master e a equipe podem abstrair toda complexidade das discordâncias normais
que existem em grupos de pessoas e enfocarem-se apenas em executar o combinado o melhor
possível.

Um projeto pode ter mais de um PO se estiver construindo vários produtos, o que alguns chamam de
sub-POs. Mas quando há mais de um PO sobre o mesmo produto, a complexidade política recai
sobre o Scrum Master (e por consequência sobre o time) e a produtividade cai.

É como um jardineiro que recebe a missão de podar as árvores do jardim sul e, quando está lá,
recebe ordens para regar as plantas do jardim leste. Ao chegar lá, leva uma bronca porque ainda não
cuidou das flores do jardim norte e assim por diante, perde-se o senso de prioridade.

Será possível que duas ou mais pessoas concordem com requisitos, parâmetros de entrada (definition
of ready) e de qualidade (definition of done)? É claro que sim. Desde que as regras sejam
combinadas no início do jogo e que a visão do produto seja a mesma entre todos. Particularmente,
nunca vi funcionar.
Continuando na análise da figura, observe que o Scrum Master está junto com o time e que todos
eles têm interface com o PO. O SM atua como um facilitador, ele orienta o uso do processo, reporta
os status, mede velocidade e negocia com o PO. Mas o time inteiro participa das estimativas, da
definição de atividades e das estimativas.

Logo, se um projeto recebe estimativas “de cima pra baixo” não está usando uma das grandes
vantagens do Scrum, que é o comprometimento do time com o resultado. Afinal, eles se
comprometem porque discutiram a solução e porque eles próprios estimaram o projeto.

Papéis do Scrum

Product Owner

 Representante do Cliente
 Ponto focal das demandas
 Entende do negócio
 Define a visão e requisitos do produto (escreve as estórias de usuário)
 Define prioridades
 Decide o que faz parte do projeto
 Responsável pelo aceite das entregas

Scrum Master

 Garante a comunicação da equipe

 Garante que o Scrum seja seguido
 Remove impedimentos
 Protege a equipe de interferências externas (garantir produtividade)
 Facilita/ modera as reuniões diárias
 Auxilia na priorização dos requisitos

Scrum Team (Time ou Equipe)

 É composto pelas pessoas diretamente ligadas ao projeto

 Garante que o projeto seja entregue com todas as funcionalidades necessárias
 Participa da definição do objetivo da Sprint
 Faz aquilo que é necessário dentro das diretrizes do projeto para alcançar o objetivo da Sprint

Confusões de papéis e suas consequências

Quando um PO não tem autonomia para definir (e aprovar) o projeto, há retrabalho e perda de
produtividade. A equipe terá uma definição do PO que depois poderá ser desaprovada e acabará
perdendo o engajamento.

Quando um Scrum Master não resolve impedimentos ou ignora a definition of ready, aceitando
requisitos que ainda não estão prontos para trabalhar,  perde-se produtividade.
Quando o time não participa da discussão técnica e nem da estimativa, não se tem comprometimento
com o resultado (É como seu chefe lhe dizer o tempo que você levará para fazer uma tarefa sem ter
real noção do tempo necessário).

Os papéis do Scrum são muito bem desenhados. Note:

Uma pessoa retém toda complexidade da organização para dar uma visão única ao produto. Essa
mesma pessoa determina o que será feito, em que ordem e como a qualidade será avaliada. Ela
também escreve exatamente como espera que as coisas sejam implementadas, essa pessoa é o PO.

Outra pessoa planeja o que será feito a cada ciclo, verifica se todas as premissas necessárias estão
presentes (definition of ready) para começar o trabalho e garante que o time participe da estimativa,
dê status diários (daily meeting) e aponte seus impedimentos, os quais ela própria deverá resolver.
Este é o Scrum Master.
Por fim, um grupo de pessoas tem apenas uma preocupação: Produzir. Todo trabalho já foi
priorizado, toda discussão técnica já foi realizada, todas as necessidades estão presentes e, se algo
impedir o trabalho, sua única preocupação é apontar para o Scrum Master. Esse é o Scrum Team.

É muito óbvio que esse ciclo de trabalho seja altamente produtivo, mas para tal, é preciso que cada
papel exerça suas responsabilidades. Se um deles falhar, todo ciclo falhará. Se apenas um “elo da
corrente” estiver desalinhado, a corrente quebrará e, com ela, todas as vantagens que se espera obter
com o uso do Scrum.
Calculando o prazo de um projeto Scrum
Postado em 2016/06/19 by Eli Rodrigues em Projetos Ágeis

A grande pergunta de todo projeto: Quando vai terminar?

É comum as partes interessadas quererem saber quando o projeto vai terminar, por isso constroem-se
cronogramas nas metodologias tradicionais.

Sabe-se, no entanto, que a maioria dos projetos não cumpre os prazos e isso se dá a várias “doenças”
e erros que os projetos trazem consigo, geralmente ligados ao comportamento ou a estrutura (Leia
mais no livro 21 erros clássicos da gestão de projetos).
O Scrum, no entanto, se atém ao que é realmente possível fazer, sem sambarilove. Se não é possível
calcular com exatidão a data final de um projeto, por que tentar? Por isso, o Scrum usa o conceito
de timebox, em que o tempo é fixo e o escopo é variável.
Esse conceito tem a ver com o estudo que mostra que, no mundo dos softwares, apenas 20% das
funcionalidades são realmente utilizadas. O cliente pede sempre muitas coisas, mas no final utiliza
somente algumas.

Cabe a nós, como Scrum Masters, auxiliarmos nossos clientes na priorização do que é mais
importante para seu negócio, ao invés de apenas cumprir prazos (e sofrer pressões) para criar
coisas que sequer serão utilizadas.

Doenças do prazo
Alguns diriam que têm metas a cumprir, datas de lançamento de produtos, que os projetos já estão
começando atrasados e que, por isso, é necessário ter um controle rígido de prazo. Mas todos
sabemos que um recurso sob pressão sempre colocará “gordura” no prazo quando estimar e, quanto
mais pressionarmos, mais gordura colocará.

Lei de Parkinson

Sabe-se, pela lei de parkinson, que o esforço sempre se enquadra ao tempo disponível. De modo que
se um programador estimar 3 dias para fazer um trabalho, o fará em, no mínimo, 3 dias, ainda que
pudesse fazer em menos tempo.
Em contrapartida, se for pressionado a assumir uma estimativa de 1,5 dia (metade do tempo), ainda
que pudesse fazer em 1 dia, levará, no mínimo, o tempo que foi obrigado a estimar.

E como se não bastasse isso tudo, na próxima estimativa, sabendo que será pressionado a cortar o
tempo pela metade, estimará 6 dias (o dobro) para que você – “espertalhão” – possa pedir a redução
sem tirá-lo da zona de conforto.

É um jogo de gato e rato que mais lembra os desenhos do Tom e Jerry.

Por isso, as metodologias ágeis usam escalas não-lineares para calcular o tamanho do projeto e, a
partir dele, seu prazo. Em outras palavras, o prazo se calcula pela velocidade média do time, livre
das pressões que modificam os comportamentos de forma nociva.
É o que chamo de “liberdade no cercadinho”, a “criança” pode brincar com o que quiser, desde que
seja dentro do espaço que lhe foi delimitado. Em outras palavras, o programador poderá determinar
a ordem de complexidade, mas a gestão do tempo se dará diariamente, sem que ele fique no controle.

Calculando o prazo de um projeto

ágil

Estimando o tamanho do projeto

Uma das técnicas para cálculo dos story points é o Planning Wall. Nela, você deve
primeiramente listar as estórias de usuário,  geralmente numa parede usando post-its.

Em seguida, devem ordená-las por complexidade, ignorando-se o fator tempo (não se atenha se os

itens que escolhi são realmente mais complexos, é apenas um modelo ilustrativo).

Por último, deve usar uma escala não-linear para pontuar cada estória, como a sequência de

Fibonacci, por exemplo.

Com isso, você terá o tamanho do projeto: 1+2+5+8+13+21+34 = 84. Este número será utilizado
para medir o progresso.
Progresso x Velocidade
Mede-se o tamanho do projeto e não o prazo, pois, no Scrum, não importa quanto tempo passou e
sim o quanto foi concluído (Leia mais em Como saber se a entrega está pronta mesmo).
Daqui nasce a diferença entre progresso e velocidade:
 Quanto mais estórias o time terminar, mais o projeto PROGREDIU. Ou seja, mais próximo está
de terminar todas as estórias.
 Quanto mais rápido o time terminar, mais VELOCIDADE  ele está alcançando.

Calculando a Velocidade do time e o Prazo do projeto

Então, digamos que foi definida uma duração de 2 semanas para cada sprint e que é provável que o
time faça as 2 primeiras estórias na sprint 1, mas que, se sobrar tempo, podem começar a trabalhar
na terceira estória.
As duas primeiras estórias são, portanto, a meta da sprint e devem cumprir o objetivo traçado para a
primeira sprint. A terceira estória é desejável, se der tempo, o projeto avançará (terá progresso) mais
rapidamente.

Usando o tempo como medida

No planejamento da sprint, o time desdobra as atividades necessárias para finalizar cada estória. O

quadro (sprint backlog) fica mais ou menos assim.

Aqui temos um primeiro insight: Duas semanas têm 40 horas por pessoa. Se consideramos 3 pessoas
no projeto, já começou a sobrar tempo.
Simulando sprint 1
Então, duas semanas depois, chega-se ao seguinte sprint burndown:
Pergunto: Terá o time avançado na velocidade esperada? Houve dificuldades no meio do caminho?
O que fez com que a primeira semana fosse mais rápida que a segunda?

Pois é, na prática as coisas são um pouco diferentes.

Nesse projeto, já se conhecia um fornecedor de móveis, então as etapas de seleção de fornecedor e

contrato foram mais rápidas. As aprovações da sala de espera (segunda estória) demoraram mais que
o previsto, pois o Product Owner  não havia passado informações detalhadas do que gostaria de
fazer. Por isso é importante o conceito de definition of ready, para que só se aceitem estórias que já
tenham suas definições bem planejadas. Passar o trabalho do PO para o time reduz a produtividade.
Qual foi a velocidade do time?
3 story points (das duas estórias) por sprint. Sendo assim, o projeto terminará em:

 84 sp / (3sp/sprint) = 28 sprints
 Como cada sprint leva duas semanas => 56 semanas ou 14 meses.
Pergunto: Mas, será que a velocidade será constante nas demais sprints? Será que as atividades mais
demoradas já não foram cumpridas? Será que a integração do time melhorará nas próximas rodadas?

Não se sabe.

Por isso, é importante acompanhar algumas sprints para se ter uma ideia mais concreta de qual será a
velocidade média. Vamos simular?
Simulando as sprints 2 e 3
Digamos que na segunda sprint, o time tenha concluído a estória  “Sala de reunião” e na terceira
tenha concluído a estória  “elevador”. Como ficaria a velocidade média?
 Sprint 1 = 3 story points
 Sprint 2 = 5 story points
 Sprint 3 = 8 story points
 Média = (3+5+8)/3 = 5,33 sp/sprint
Perceba como é mais coerente considerar a variação de produtividade ao longo de várias sprints, por
isso se considera sempre a média (ou média móvel, se preferir) para estimar o projeto.
Como ficaria o prazo do projeto considerando a perspectiva da
velocidade média?

 Quantidade total de story points = 84

 Quantidade de story points já realizados = (3+5+8) = 16
 Quantidade restante de story points = (84-16) = 68
 Tempo total do projeto, após a revisão = 68 / 5,33 = 12 sprints
 Em termos de prazo, ficaria em = (12 sprints * 2 semanas para cada) / 4 semanas por mês = 24
semanas ou 6 meses.
Pois é, num ambiente convencional, ao término da primeira sprint já se estariam fazendo reuniões de
melhoria, o time teria levado muitas broncas e provavelmente alguém acabaria saindo da equipe, o
que derrubaria ainda mais a produtividade.
Como acompanhar a velocidade do time?
A velocidade do time é medida por quantos story points aquela equipe conseguiu fazer num período
fixo. Os story points, no entanto, são medidas comparativas entre estórias de usuário, que usam
escalas não-lineares.
Deste modo, ao comparar uma estória de usuário com outra, o time é obrigado a escolher, por
exemplo, entre 8 e 13, de modo que uma estória que valha 8 story points pode acabar levar mais
tempo que outra com o mesmo valor. Isso serve para que o time “perca a noção do tempo exato”
para fazer uma estória e acabe focando-se nos resultados.
Esse é um dos grandes segredos do acompanhamento ágil, foco nos resultados.

Para acompanhar a velocidade, deve-se usar um gráfico de controle, como o exemplo a seguir.

As linhas em vermelho mostram os limites superior e inferior, apenas como alerta para que o Scrum
Master avalie se houve um potencial desvio. Basicamente, o gráfico de velocidade serve para dar
uma noção do prazo do projeto, mas sem certezas, afinal, o Scrum foca em resultados não em
estimativas.

Usando a quantidade de tarefas como medida

Uma outra forma de controlar o andamento da sprint é por quantidade de atividades. Ela é mais
rápida e mantém as pessoas focadas no que deve ser feito e não em quanto tempo levará para fazer.
O burndown tem o mesmo formato do gráfico baseado em horas, mas, retrataapenas atividades
concluídas.
Se lembrarmos da diferença entre progresso e velocidade, notaremos que “terminar uma atividade
não significa finalizar o trabalho (a estória), afinal, a atividade pode não ter dado certo.

Talvez lhe incomode não saber as horas que o time gastou com cada tarefa, mas isso é realmente
mais importante que o resultado?

O andamento do projeto é acompanhado na daily meeting e o tempo que se investe estimando horas

é desperdiçado em relação ao tempo de execução.

Usando story points como medida

Para os mais radicais, nem mesmo estimar a quantidade de tarefas é justificável. Preferem apenas
listar as estórias de usuário daquela sprint e seguir para a execução.
Quando se têm um grande número de estórias, o gráfico faz mais sentido. Mas, de qualquer forma,
só haverá progresso quando uma estória for 100% concluída, ou seja, quando atender a definition of
done.

Acompanhando o Progresso do projeto

Agora voltando ao product backlog: Como o Product Owner deve acompanhar o progresso do
projeto?
Ao final de cada sprint, deve atualizar o gráfico de burndown, mostrando quantos story points foram
finalizados, conforme o exemplo.

Replanejamento a cada sprint

Seria sensacional se os projetos seguissem uma linha reta, mas na prática, o PO (Product Owner)
decidirá, a cada planejamento de sprint (sprint planning), quais estórias permanecem, quais serão
simplificadas e quais serão adicionadas.
Em termos práticos, a estória “Negociação” poderia ser “repriorizada” para entrar na quarta sprint.
Ela também poderia ser “simplificada”, reduzindo sua complexidade para caber no prazo. Tudo pode
acontecer, afinal, é um projeto ágil!
Finalizando o projeto no Scrum
Então chegou o grande dia, o tempo do projeto acabou. Chegou 3/9/16 e na segunda-feira que vem
será o lançamento do produto.

Mas, peraí… o escopo não foi totalmente concluído! Quem é responsável por isso? A quem vamos
demitir?

Embora esse seja o pensamento tradicional, presume-se que no Scrum, o PO tenha colaborado com o
time durante todo o projeto e teve a visão exata do que havia sido concluído a cada sprint. Foi ele
quem decidiu, com base no seu conhecimento de negócio, quais estórias eram prioritárias e também
foi ele quem avaliou cada entrega.
Deste modo, espera-seque esteja satisfeito com o resultado, ainda que o escopo inicial do projeto não
tenha sido concluído. Pois, se não estivesse, teria apontado isso durante o projeto.

O mais comum é que o product burndown finalize com algumas estórias não implementadas, seja

porque o prazo terminou ou porque não houve interesse em seguir com elas. Mas, não se preocupe,
na segunda-feira tudo que foi produzido irá ao ar e não haverá surpresas no último dia.

Uma mudança de paradigma

Para que o Scrum funcione adequadamente é preciso, principalmente, a definição clara dos

papéis atuantes no projeto e para que o resultado seja satisfatório é preciso um acompanhamento
muito próximo do PO e muito realismo em relação ao que é possível ser feito. Isso é o que chamo de
“parceria”.
Se qualquer dos papéis não se adaptar a esse novo modelo de trabalho, seja pela necessidade de
microgerenciamento, seja pelo desejo de participar de todas as reuniões ou simplesmente pela
atitude de fechar os olhos e buscar culpados quando o impossível não for concluído, é melhor não
tentar usar o Scrum como bode expiatório.
Muitas e muitas empresas pelo mundo têm usado Scrum. Se nesta ou naquela não funcionou, está na
hora de rever os conceitos e mudar o paradigma de trabalho. Quando houver foco em resultados e
confiança mútua, certamente qualquer modelo de trabalho funcionará melhor.
Como saber se a entrega está completa
mesmo?
Postado em 2011/10/07 by Eli Rodrigues em Escopo

Olá Gerentes de Projeto,

Esta discussão tem sido recorrente nos treinamentos e workshops que tenho trabalhado: Como saber
se uma tarefa está realmente concluída? Como saber se terminei o escopo de um projeto? Como
definir o “done”? A assinatura do cliente é suficiente? Como saber se a entrega está completa
MESMO?

O mesmo cenário têm ocorrido na indústria, serviços e comércio, a dificuldade para definir quando
um trabalho está pronto. Esses dias mesmo passei um “causo” trocando de apartamento, enquanto
para a corretora o fato de eu ter escolhido o imóvel significava “done”, para a área administrativa
receber minha documentação era “done”, cada um fazendo um excelente trabalho com seu umbigo e
eu sem as chaves para mudar.

Isto ocorre geralmente por dois motivos: cada departamento enxerga somente sua “parte” ou pelos
diferentes entendimentos em relação ao trabalho. Um entende que o trabalho está pronto quando o
faturamento foi recebido, outro no pós-venda; um acredita que feito o serviço está terminado, outro
entende que só termina após o período de garantia.

Como resolver esse impasse? Antes de responder, permitam-me mostrar algumas situações do
mundo real no ambiente de projetos:

 João assumiu a tarefa de especificar um novo produto, na data final ele entregou um documento.
Está concluído? Foi revisado? Tem aprovação da gerência? A área de engenharia avaliou a
viabilidade? O cliente aceitou?
 Pedro trabalha numa empresa de software como desenvolvedor (programador). Ele terminou a
interface de cadastro de vendas. Está concluído? Houve teste unitário? houve teste funcional?
teste integrado? os bugs originários dos testes foram corrigidos? foram verificados? A interface
foi disponibilizada para homologação? foi disponibilizada com sucesso em produção? todos os
acessos foram garantidos? o cliente deu o aceite final?
 Carlos fez um projeto que ampliava a capacidade da rede (de computadores) do cliente, “virou”
dois fins de semana para terminar o trabalho. Na data final do projeto, tudo pronto e funcional,
um sucesso! Até que… o cliente informou que, no seu entendimento, o trabalho só estaria
finalizado após duas semanas de monitoramento e suporte. E agora GP, tem orçamento para isso?
Todos estes são casos reais. Mas que característica comum poderia nos ajudar a definir se o trabalho
“está pronto” ou não?

A resposta é: ESTADOS!

Nestas situações, o GP (ou a área de processos) precisa definir claramente que Estados existem, qual
a sequência entre eles e quais os critérios para troca de Estado. Sim, isso é uma máquina de estados.
Não é preciso ter profundas bases matemáticas e nem ferramentas sofisticadas, veja o exemplo de
tabela postado na Wikipedia:

De uma forma gráfica, poderia-se fazer assim:

Também poderia ser usado um fluxo simples com os estados em sequência obrigatória:

Outra configuração
bastante utilizada é o “ciclo”:
E ainda, para casos em que os estados são condicionais, uma espécie de Fluxograma usando Estados:

Obs: Existem notações para construção de Diagramas de Estados, para mais informações consulte
a UML (Unified Modeling Language).
Após haver definido os estados para os pontos críticos do projeto, é hora de “divulgar” a máquina de
estados a todos os envolvidos. Esta é a parte mais complicada, pois geralmente é difícil obter a
concordância de todos e também é dificil que todos entendam o que o autor (da máquina de estados)
quis dizer com cada um deles. Para evitar esse tipo de problema, recomendo que faça um “manual”
especificando cada estado com: descrição, condições de troca e exemplos de aplicação. Recomendo
ainda que envolva as pessoas na definição dos estados, isso garante o comprometimento com o que
foi definido.

Se precisar de um software para apoiar o controle dos estados, indico o Mantis Bug Tracker. Ele é
gratuito e tem suporte a vários idiomas e é bem customizável. Baixe aqui. Pronto, agora estamos
aptos a reduzir a condição de dúvida sobre as entregas. Desejo sucesso a todos!
Como gerenciar o escopo de um projeto
Postado em 2013/08/07 by Eli Rodrigues em Escopo
O Escopo é a ferramenta que delimita O QUE será feito no projeto. Segundo MOLENA (2009), existem
dois problemas relacionados ao gerenciamento de escopo que correspondem a 23% dos problemas mais
comuns em projetos: Mudanças constantes de escopo e escopo não definido adequadamente.

Seríamos tendenciosos ao deduzir que as mudanças foram causadas pela definição inadequada, pois
muitas vezes as mudanças são motivadas por fatores externos. Da mesma forma, a definição
inadequada nem sempre é causada pela falta de tempo, como muitos acreditam. Poderia ser causada
por inabilidade ou por imaturidade organizacional, por exemplo, na tomadora do serviço.O que
temos de concreto são as boas práticas descritas no guia PMBOK®, que nos apresentam, na área de
Gerenciamento de Escopo, os processos abaixo:

1. Coletar requisitos
Realiza o levantamento das necessidades e desejos do cliente, tanto funcionais (relacionadas ao
produto) quanto não-funcionais (acessórias).

As principais técnicas são as seguintes:

 Entrevista – Realizar sessões de perguntas e respostas com pessoas-chave do processo em

questão.
 Questionário – Montar um questionário para aplicação em grande quantidade de pessoas.
 Análise de documentação – Revisar, avaliar e analisar documentação disponibilizada pelo
cliente.
 Observações (shadowing) – Acompanhar a operação do trabalho que é objeto do projeto.
 Dinâmicas de grupo – Realização de dinâmicas de grupo como brainstorming, grupo nominal,
grupos de foco etc.
2. Definir o escopo
Delimita o que faz parte do projeto através de entregas. A Declaração de Escopo é o documento
base, que determina o que está dentro e fora do escopo, além das premissas e restrições.

Ferramentas:

 Análise de produto – Conversão da descrição do produto (necessidades do cliente) em entregas e

requisitos.
 Identificação de alternativas – Busca de diferentes estratégias para implementação do produto.>
3.       Criar a EAP (Estrutura Analítica do Projeto) 
Criar a EAP é transformar a Análise de Produtos em uma representação hierárquica das entregas. A
EAP deve estar sempre associada ao seu dicionário, que descreve o que significa cada caixa. Leia
mais.
4. Controlar o escopo
Controlar o escopo é checar se ele está em concordância com o planejamento. Deve responder à
pergunta: Tudo foi executado conforme o planejado?

Técnicas: Análise de variação, que é a revisão dos produtos desenvolvidos frente a declaração do
escopo, buscando identificar gaps e corrigi-los.
5. Verificar o escopo
Trata a obtenção do aceite do cliente sobre o produto (ou fase) desenvolvido(a). Para que funcione
adequadamente devem ser definidos “critérios de aceite” na fase de planejamento.

Técnicas: Inspeção (revisão) técnica do produto pelo cliente.

Os pilares do Scrum
Postado em 2016/06/08 by Eli Rodrigues em Projetos Ágeis
Agora que já conhece mais aprofundadamente a definição do Scrum, vou falar sobre seus três
pilares: Transparência, Inspeção e Adaptação.
Os pilares são os princípios fundamentais sobre os quais o Scrum foi construído, são eles que fazem
a diferença numa implantação e criam o ambiente propícios para projetos realmente ágeis.
O primeiro pilar é a transparência, que significa que todo trabalho deve claramente definido e
conhecido por todas as partes envolvidas no projeto.
A transparência se dá através da comunicação (verbal ou escrita) e ocorre em diversos momentos,
por exemplo:

 Quando o cliente (Product Owner) descreve as funcionalidades esperadas para o produto;

 Quando o cliente informa as prioridades das entregas;
 Quando o Scrum Master apresenta o planejamento e o andamento das sprints;
 Quando a equipe comunica diariamente o andamento do trabalho;
 Quando a equipe atualiza um kanban deixando claro o andamento do desenvolvimento do
produto (progresso físico);
 Quando a entrega parcial (incremento do produto) é realizada e o cliente tem a oportunidade de
dar um feedback antes do final do projeto;
 etc

O segundo pilar é a Inspeção, que significa que todo trabalho deve ser inspecionado com a
frequência necessária para garantir a qualidade na primeira tentativa.
A inspeção é um princípio tão forte que o Scrum considera que o processo de testes está dentro da
própria sprint. Isso nos remete aos conceitos de integração contínua, test driven development  e pair
programming, que são formas de garantir a qualidade enquanto o produto está sendo produzido, ao
invés de controlar a qualidade só no final.
A inspeção se dá, por exemplo, através dos seguintes itens:

 No conceito de ready (definition of ready)

 No conceito de done (definition of done)
 Na reunião de grooming
 Quando se estima os story points  de uma estória de usuário
 Reunião de revisão (review meeting) com o cliente (product owner)
 Diariamente, quando alguém termina um estória e um membro do grupo faz a verificação do
DoD
 Na verificação de bugs e sua respectiva correção
O terceiro pilar é a adaptação, que significa a capacidade de adaptar o projeto à necessidade de
negócio.
A adaptação é a grande vedete dos projetos Scrum, pois ele pode começar com um conjunto de
estórias e terminar relativamente diferente. O PO pode constituir, modificar e excluir estórias ao
término de cada sprint.

A adaptação se dá, por exemplo, através dos seguintes itens:

 No planejamento do projeto, quando o PO prioriza as estórias

 No review de uma sprint, quando o PO reprioriza as estórias (itens do backlog)
 No conceito de meta da sprint, quando o time tem a liberdade de realizar mais ou
menos estórias do que estava planejado
 No conceito de velocidade – que difere de progresso, quando, após algumas sprints se tem a
velocidade real do time e se pode calcular o tempo necessário para terminar o projeto.
 etc
O Scrum é uma ferramenta maravilhosa, muito poderosa se usada corretamente. Se os pilares forem
bem observados, mesmo um scrum adaptado (conhecido como Scrum-but) dará bons resultados.
10 erros na implantação do Scrum que
você não quer cometer
Postado em 2011/11/11 by Eli Rodrigues em Projetos Ágeis
Muitas empresas de software tem buscado a “solução mágica” no Scrum, mas não estão obtendo o
resultado esperado. A maioria delas, após alguns meses, desiste do framework e volta ao ad-hoc,
culpando-o pelo fracasso. Mas será que essas empresas estão implantando corretamente?
Pelo que tenho visto, a maioria tem feito “adaptações” no framework que tiram algumas de suas
características essenciais. Por exemplo, o intenso ciclo de comunicação garante alinhamento de
expectativas; a constante revisão de escopo garante coesão no projeto; as entregas
intermediárias buscam atendimento da necessidade do cliente e correção de falhas antes do final do
projeto; o conceito de timebox força a equipe a ter o que entregar, evitando o prolongamento de
atrasos. Ora, esses benefícios são provenientes dos princípios embutidos no Scrum e adaptar o
processo pode trazer resultados desastrosos.
Mas quais são os erros mais frequentes? Fiz um levantamento de erros comuns e que levam a
implantação do Scrum ao fracasso:

1. Vestir a capa de scrum, mas trabalhar cascata

Sprints são timeboxes, ou seja, um tempo fechado em que se realizam entregas parciais do
projeto. As entregas são priorizadas para que, ao final do tempo, exista uma “saída”, “alguma”
entrega.
Montar sprints como etapas ou fases de um projeto é um erro. Dessa forma perdem-se os
benefícios do ciclo de melhoria contínua (que muito lembra o PDCA), mais conhecido como
iterativo-incremental, que grosso modo significa entregar parcialmente e agregar valor ao
produto a cada ciclo, através da melhoria contínua. Portanto, é importante que as entregas sejam
parciais e evolutivas.
2. Impor prazo de “cima para baixo”
A definição de “prazos arbitrários” é uma prática condenada também pelo PMI, deve-se
envolver os executores das atividades na fase de Planejamento. O Scrum não precisa de nada
disso, ele trabalha com sprints e invés de um prazo fechado. Precisam-se de entregas priorizadas
para que a equipe “decida” o que vai ser entregue, caso no prazo não seja possível terminar
tudo.
Existe muita polêmica em relação a essa questão, pois as pessoas se sentem desconfortáveis em
afirmar que a equipe “poderá não entregar tudo”, mas no mundo real muitas equipes não
realizam as entregam na data combinada e atrasam os projetos. O Scrum não quer dizer que a
equipe vai fazer “corpo-mole” e deixar de entregar as coisas, pois existe um monitoramento
diário das atividades e as entregas são parciais. Desse modo, não haverá aquela pressão do
último dia, mas uma pressão a cada sprint, reduzindo o risco de um atraso maior. Além do mais,
a equipe fica ciente de que deve fazer primeiro o que for prioridade e que SE for preciso,
entreguem parcialmente, mas jamais deixem de entregar no prazo.
3. Realocar membros da equipe para outros projetos “mais prioritários”
A mudança de prioridade entre projetos não combina muito bem o com o agile, pois ele tem
como premissa o trabalho integrado, colaborativo e priorizado. A principal motivação da equipe
no Scrum vem do agrupamento, do cumprimento de metas e da cobrança mútua, parâmetros
estimulados pelo Scrum de um modo geral. Além disso, lições aprendidas, sincronia e alto
desempenho serão perdidos com a troca de “componentes” (de pessoas).
4. Não fazer reunião diária
É na reunião diária que se faz a gestão da equipe, do desenvolvimento das entregas, da
qualidade e dos problemas. Não cumprir essa prática rompe com os ciclos de comunicação,
acompanhamento e põe em risco a entrega da Sprint. Além disso, o relato de desempenho diário
faz com que a equipe se cobre mutuamente impulsionando a produtividade.
5. Não endereçar e resolver os impedimentos
No Scrum, as pessoas são incentivadas a comentar o trabalho que estão fazendo diariamente
(como descrito acima) e também qualquer impedimento que esteja causando impacto em suas
atividades. Se você não resolver os impedimentos com muita seriedade, elas simplesmente vão
 parar de reportar, não cumprirão os prazos e eventualmente até boicotarão o processo. Neste
caso, a frase mais comuns nos corredores é: “Eu já falei, mas ninguém faz nada!”.
6. Fazer a reunião diária sem o quadro de acompanhamento
Sem o quadro de acompanhamento fica impossível controlar o andamento do trabalho. Todo
tipo de Controle precisa de uma linha de base de comparação, no caso do Scrum essa linha de
base é o quadro de acompanhamento.
7. Não gerar o gráfico de burndown
O gráfico de burndown é uma das ferramentas mais poderosas de comunicação do Scrum.
Permite que clientes, gestores e equipe tenham uma visão real e atualizada do projeto todo. Ele
pode ser feito tanto para as Sprints quanto para os itens do Product Backlog e ajuda a prever a
data final do projeto. Lembre-se, sem linha de base não existe controle, sem controle não existe
sucesso.
8. Criar sprints estanques
Toda sprint deve ter um objetivo, mas não entregas fixas e invidivisíveis, pois há perda
de agilidade. Quando uma entrega está travada (com dificuldade para ser implementada), 
a equipe pode decidir passar para a próxima entrega, enquanto os impedimentos são resolvidos,
ou montar uma força-tarefa para resolver o impedimento . Isso ajuda a chegar no prazo final
com alguma entrega pronta, apesar dos percalços. Sem flexibilidade, a chance de atrasos é muito
maior.
9. Atrasar o prazo final das sprints
Scrum é timebox,  é “quanto consigo fazer até o final da sprint”. Isso força a equipe a pensar
sempre em entregas funcionais e aceitas pelo cliente, a buscar alternativas, a se superar. Mudar
essa perspectiva para “quando consigo entregar um grupo de funcionalidades” pode levar a
equipe a atrasos. A pressão deve estar totalmente voltada para a entrega.
10. Ter um Scrum Master sem autoridade (grupos matriciais)
O Scrum Master precisa de autoridade suficiente para fazer o fluxo do Scrum ser executado na
empresa. Se uma autoridade externa influenciar na alocação, impuser prioridades ou
simplesmente retirar membros da equipe fica muito difícil o SM conseguir formar uma equipe
de alto desempenho. Mas quando a equipe+SM não tem autoridade para determinar as
atividades e prioridades dentro da sprint, o resultado é totalmente fora do esperado.
A maior dificuldade para as organizações tem sido mudar o dilema: é melhor ter um prazo ou
entregar um produto funcional ao final de um período? É melhor ter um escopo congelado ou
entregar um produto que corresponde às necessidades do cliente? É melhor ter atas de reunião e
relatórios ou fazer uma comunicação simples e entregar o produto no final do projeto?

Esses princípios têm dado bons resultados em vários lugares ao redor do mundo, analise se sua
empresa está realmente seguindo os princípios certos, o melhor indicador são os resultados (entregas
e clientes satisfeitos), a metodologia pouco importa.
Este post faz parte da Série – Como fazer um Cronograma.

Agora que você já sabe tudo sobre a utilidade da EAP, podemos partir para o MS-Project.
Este primeiro exercício é bem simples e tem o objetivo de mostrar os passos para
construção do cronograma. Vamos começar!
Passo 1 – Inserir a EAP
O MS-Project tem uma interface que lembra o Excel e trata, inicialmente,
qualquer entrada como uma atividade. Deve-se inserir primeiro o nome do Projeto e abaixo
as partes da EAP.

EAP do projeto (por fases)

Para aninhar as “Fases’ dentro do “Projeto”, utilize a tecla <TAB>.

Passo 2 – Inserir as Atividades

Para inserir as atividades prossiga da mesma forma. Clique na tecla <Insert> e vá
adicionando as atividades conforme o exemplo abaixo:

Atividades do Projeto

Recomendação: Neste primeiro momento, não convém pensar em Duração ou em

Recursos, a prática mostra que é mais proveitoso listar as atividades do projeto inteiro
antes de planejar de fato suas durações e quem irá executá-las.
Passo 3 – Sequenciar as atividades
Para isso use o campo “Predecessora”. Mas antes de tudo, o que é uma “Predecessora”?

Para calcular o prazo de um projeto é preciso concatenar as atividades umas nas outras.
Predecessora é a atividade anterior, àquela a qual a atividade se conecta para gerar a
sequência de passos.

Ex: Na sequência de atividades x, y e z. A predecessora de y é x, de z é y.

Agora vamos inserir as Predecessoras deste projeto (Se o campo “Predecessoras” não
estiver disponível, clique com o botão direito sobre a barra de título e escolha “Inserir
Campo”)
Vá até o campo “Predecessoras”e insira os números correspondentes ao índice da
atividade (número que fica na primeira coluna – a “cinza”).

Cada atividade pode ter várias predecessoras, basta inserir os números separados por
vírgula.

Recomendação: Lembrando que o cronograma é composto de fases e atividades, a

prática mostra que inserir a ordem de predecessão na atividade dá maior controle sobre a
sequência. Pois a duração da fase é a soma das durações de duas atividades.

Existem mais detalhes para lidar com Predecessoras, que comentarei em posts futuros.

Passo 4 – Definir recursos

Neste passo você irá alocar o recursos nas suas atividades correspondentes. No exemplo
abaixo foram definidos dois colaboradores: João e Pedro.

Existem duas formas para atribuir um recurso à uma atividade. A primeira é inserindo
diretamente no campo “Nomes dos Recursos”.

A segunda, mais segura, é acessando a “Planilha de Recursos”, através do menu “Exibir >
Planilha de Recursos”. E em seguida, usando o list box para selecionar os nomes,
conforme a figura abaixo:
Isto evita que você duplique um recurso, por exemplo, chamando um de João outro de
Joao, J. da Silva e assim por diante.

Passo 5 – Definir data de Inicio do Projeto

Vá até a opção do menu “Projeto > Informações do Projeto” e insira a data inicial do
projeto, no exemplo foi utilizada a data de 1 de agosto de 2011.

A data inicial será importante para Definição do Calendário, para calcular os dias não-úteis
dentro período real do projeto.

Passo 6 – Definir Calendário

O calendário é essencial para que se chegue a um cronograma realista. Nele você vai
inserir:

 Feriados e pontes
 Férias e Folgas programadas
 Períodos de trabalho diferenciados
Os “Períodos de trabalho diferenciados” são usados quando o recurso humano não
trabalha o período padrão, que é de 8 horas diárias de segunda a sexta. Às vezes um
recurso pode trabalhar apenas 4 horas, ou somente aos sábados. Todas as variações são
aceitáveis.

No exemplo, os dois recursos trabalharão 8 horas diárias de segunda a sexta e o dia 3 de

agosto de 2011 será feriado.

Para inserir um feriado, siga as ações:

 Primeiro vá até o menu Ferramentas > Alterar período útil

 Vá até a aba “Exceções”
 Insira todas as exceções conforme seu calendário.

Passo 7 – Inserir a Duração/Trabalho das Atividades

Agora vamos inserir a Duração/Trabalho das atividades. Na configuração-padrão, Duração é
a quantidade de DIAS úteis que a atividade irá levar e Trabalho é a quantidade de horas.
Quando você insere a Duração, o MS-Project  calcula o Trabalho em Horas (3 dias x 8hs
diárias = 24 horas).

Se você fizer o contrário, colocando o Trabalho, ele calcula a Duração (40 horas / 8hs
diárias = 5 dias).

Existem mais detalhes para lidar com Duração x Trabalho, que comentarei em posts

futuros.
Passo 8 – Analisar Super-alocação
Analisar a Super-alocação significa observar se algum dos recursos humanos está
programado para trabalhar mais do que sua capacidade (em horas). Embora seja uma
prática comum em muitas empresas, em um planejamento isso não é recomendável, pois
dá uma visão equivocada do prazo alcançável.

Existem duas visões que podem facilitar essa análise. A primeira é o “Gráfico de
Recursos”, que você pode acessar pelo menu “Exibir > Gráfico de Recursos”. Nela você
consegue visualizar rapidamente a super-alocação pelas barras, que ficam vermelhas,

conforme o exemplo abaixo.

Outra visão é o “Uso dos Recursos”, que pode ser acessada através do menu “Exibir >
Gráfico de Recursos”. Esta visão mostra dia a dia, quantas horas o recurso está
trabalhando em cada atividade. (Particularmente acho bem mais fácil de manipular!)
Passo 9 – Identificar o caminho crítico
E finalmente, chegamos ao momento principal, que é a Identificação do Caminho Crítico.

Agora vamos a visualização do Caminho Crítico no MS-Project. Vá para a tela do gráfico

de Gantt, usando o menu “Exibir > Gráfico de Gantt” e siga os passos abaixo:

Clique no “Assistente de Gráfico de Gantt”

Escolha a opção “Caminho Crítico” e em seguida “Concluir”

Clique em “Formatar”

Abaixo o Gráfico de Gantt com o Caminho Crítico pintado com a cor vermelha:
 Gráfico de Gantt com o Caminho Crítico

Algumas perguntas comuns sobre caminho crítico:

 O que é Caminho crítico? É a sequencia de atividades com a maior duração.

 Pode haver mais de um? Pode!
 É um problema ter caminho crítico no projeto? Não, todo projeto tem pelo menos um.
 Quando resolvo o caminho crítico, o que acontece? Surge sempre outro caminho crítico.
 Para que serve? Serve para que você identifique as atividades que podem atrasar o projeto.
 Então existem atividades que podem atrasar? Sim, todas as atividades que não estão no caminho
crítico possuem alguma “folga”, que significa que podem atrasar alguns dias.
 Eli, tem exemplos aí? Tenho vários, veja a página de exemplos.
Leia mais na Parte 4 – Como estruturar um cronograma integrado.
—