O documento descreve as metodologias ágeis e o framework Scrum. Ele explica os conceitos-chave como Sprint, histórias, backlog, time, Scrum Master e Product Owner. Também compara o desenvolvimento antes e depois da cultura ágil e apresenta os princípios do Manifesto Ágil.

1. Metodologias Ágeis
Lucas Frossard

2. Lucas Frossard
Formação
• Bacharel em Ciência da Computação (UFMG)
• Pós graduação em Gestão (FDC)
Atuação
• Engenheiro de Software
• Mais de 6 anos de experiência com metodologias ágeis

3. O que é ser ágil?

4. Antes da cultura ágil
• Planejamentos longos.
• Escopo fixo.
• Custo estimado, na maioria das vezes errado, portanto o custo é variável e desconhecido.
• Escopo fixo
• Custo estimado, na maioria das vezes errado, portanto o custo é variável e desconhecido
• Entregas demoradas.
• Entregas únicas e monolíticas.
• Entregar sem valor para o negócio devido ao longo tempo entre surgimento da demanda e o seu suprimento.
• Entregar sem valor para o negócio devido ao longo tempo entre surgimento da demanda e o seu suprimento.
• Problemas evidenciados tardiamente.
• Aprendizagem sobre o negócio acontecia tardiamente.
• Toneladas documentos que ninguém utilizava e que ficavam desatualizados rapidamente
• Risco alto.
• Prejuízos.
• Aprendizagem sobre o negócio acontecia tardiamente
• Risco alto
• Prejuízos

5. Depois da cultura ágil
• Aumento no número de entregas.
• Redução de riscos:
• Custo fixo
• É possível antecipar problemas mais cedo.
• É possível resolver problemas mais cedo.
• O custo de produção de qualquer coisa é menor,
portanto descartar algo é mais barato.
• Entregas menores
• Entrega é contínua
• Flexibilidade e possibilidade para se alterar o escopo.
• Apenas o suficiente é gasto para produzir o necessário
quando necessário.

6. O manifesto ágil
• Indivíduos e interação entre eles mais que processos e ferramentas
• Produto/Serviço em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

7. SCRUM
Uma breve introdução

8. 8

10. SCRUM
Arcabouço/Framework iterativo para um processo ágil.
Os elementos básicos deste arcabouço são composto:
• Um time
• Backlog de histórias* a serem feitas
• Ciclo / Sprint
• Ritos
• Encontros diários / Daily Meetings
• Planejamento / Planning
• Revisão do Sprint / Sprint Review
• Retrospectiva / Restrospective meeting
• Outros ritos que possam contribuir para o processo.
• Elementos de gestão visual
• Melhoria contínua e métricas
*Por enquanto entenda histórias como um pedaço de trabalho
entregável. Ou simplesmente: coisa.

11. Alguns Conceitos básicos
... antes de introduzir o processo

12. SCRUM Master
O SCRUM Master é a pessoal responsável em ajudar e proteger o time como um todo a manter o foco no
objetivo do Sprint . É para ele que o time ou algum membro do time deve procurar em caso de
dificuldades.
Também é função do SCRUM Master proteger o time influências externas. Por exemplo, muito embora
qualquer membro do time possa conversar com quem for necessário para que o seu trabalho seja
executado, possíveis demandas adicionais devem ser conversadas com o Scrum Master e o Product Owner
para que sejam priorizadas e possivelmente executadas nos Sprint seguintes.
Portanto, pode ser entender que o SCRUM máster é o guardião das práticas do SCRUM, que impede
distúrbios no processo e no time. Aquele responsável por remover impedimentos ou obstáculos e que faz
o necessário para que o processo continue funcionando normalmente.
Outras responsabilidades comumente atribuídas ao SCRUM master incluem preparação do terreno dos
Sprints seguintes bem como acompanhamento de métricas internas e externas, podendo estas
responsabilidades serem compartilhadas também com outros membros do time.

13. SCRUM Master
SCRUM master é um papel e não uma pessoa. Portanto não há restrição quanto a pessoa ser unicamente
SCRUM master. Porém há algumas características desejáveis em um SCRUM master:
• Liderança
• Pro-atividade
• Comunicativo
• Disciplina
• Sensatez
• Trabalho em Time
• Maturidade
• Alta disponibilidade para o time

14. Product Owner (P.O.)
Product Owner é aquele responsável por um produto ou serviço. É a pessoa referência naquele assunto sob o
ponto de vista de negócio.
É importante que o P.O. esteja sempre disponível para o time para que possíveis dúvidas sempre sejam
resolvidas o mais rápido possível garantindo a fluidez do processo.
O P.O. não necessariamente precisa estar presente no dia-a-dia do time, mas sua disponibilidade deve ser a
maior possível, e o mesmo também é parte do time.
É o P.O. que aceita ou rejeita o resultado de um trabalho.
Um time pode ter que lidar com mais de um P.O.

15. Histórias
As histórias correspondem a descrições de um objetivo a ser
alcançado.
Esse objetivo pode ser um novo produto, uma função deste produto,
um serviço, ou qualquer pedaço de trabalho ou incremento que possa
ser entregue.
Algo similar ao formato ao lado é recomendado por identificar o
interessado (quem) naquele trabalho, o que se espera do mesmo (o
quê) e qual a razão daquele trabalho (por quê).
Adicionalmente é importante que se defina critérios de DONE e
critérios de aceite. O critério de DONE é aquele que define que uma
história foi realizada. O critério de ACEITE é aquele definido pelo P.O.
para considerar que o trabalho realizado está de acordo com o que foi
esperado.
O tamanho de uma história para outra é variável, porém é consenso
que uma história deva caber dentro de um Sprint. Caso ela seja
grande demais para cabe em um Sprint, recomenda-se que a mesma
seja quebrada em histórias menores.

16. Backlog de histórias
Em cada Sprint, as histórias mais prioritárias do backlog são
trabalhadas e entregues. Estas histórias devem ser priorizadas
de acordo com o valor que elas se propõe entregar.
Para isso é necessário uma engenharia de valor que
identifique os interessados naquela histórias, os beneficiados,
e qual o impacto daquela entrega. Essa engenharia não precisa
ser explícita, porém é interessante que a mesma seja refinada
ao longo do tempo.
O backlog de histórias é dinâmico, isto é, a medida que o
tempo vai passando, a prioridade das histórias mudam, assim
como novas histórias entram e novas histórias saem. É
responsabilidade do Product Owner manter o backlog de
histórias atualizado.

17. Time
Peça fundamental do SCRUM e de qualquer ambiente de trabalho, o time deve ser multidisciplinar e
possuir alta performance de forma equilibrada;
O time é responsável por tudo. Pela entrega, pela qualidade da entrega, pelas estimativa, pelo
processo, pelas métricas a serem coletadas e qualquer outro produto do trabalho do time.
O censo de que o time é uma unidade é fundamental para o sucesso do SCRUM.
Lembre-se, o P.O. e o S.M. são integrantes do time e devem agir como tal.
Não há um limite máximo para a quantidade de pessoas em um time, mas existe uma recomendação ou
consenso de que o tamanho de um time deve ser igual a quantidade de pessoas necessárias para comer
duas pizzas. Sério!
Caso o time fique maior do que isso, recomenda-se dividi-los em dois times.

18. SCRUM

19. Características do SCRUM
• Abraça a mudança, porém de forma
organizada.
• Preza pela comunicação ágil e
eficiente.
• Previsibilidade.
• Qualidade.
• Tempo fixo.
• Escopo variável.

20. Scrum em uma imagem

21. Gestão do Backlog
O Backlog de histórias deve ser mantido pelo P.O. (Product Owner).
No momento que o P.O. adiciona um ítem no backlog, este item não precisa estar descrito com muita
profundidade. Porém no momento em que o item está priorizado para ser realizado, é desejável que a
história esteja suficientemente refinada para que o entendimento do objetivo a ser alcançado seja
possível. Apesar disso, é de suma importância que no momento do planejamento, o P.O. esteja
presente, pois certamente dúvidas irão surgir.
Quando o P.O. coloca uma história no backlog, ela pode ser simplesmente uma frase como:
“Precisamos organizar um evento de integração para os professores de extensão para promover a troca
de conhecimento entre as diversas áreas da universidade”
No momento em que a história for ser desenvolvida, mais detalhes certamente deverão estar
presentes na história.

22. Gestão do Backlog
Durante o decorrer do tempo, é comum que as prioridades mudem, que novas histórias entrem e
saiam. O SCRUM entende e abraça o fato de que a cada momento as pressões que um determinado
negócio sofre se altera, demandando estas mudanças. Porém a partir do momento que uma história
entrou para o Sprint, ela deverá ser desenvolvida, e se ele ficou de fora, ela deverá esperar.

23. Sprint
Um Sprint é simplesmente um ciclo. É desejável que cada ciclo tenha a mesma
quantidade de dias úteis para facilitar o calculo das métricas e para manter um
ritmo constante de entrega bem como de acomodação de mudanças.
Feriados, eventos e outras questões podem justificar a extensão ou redução de
determinados Sprints, porém é desejável que em geral todos eles tenham a mesma
duração.
Em geral um Sprint costuma ter entre 10 e 15 dias úteis, mas é decisão de cada
time ou organização o tempo que cada Sprint vai durar e como cada Sprint será
acomodado. Há organizações que gostam de planejar na segunda, para que na sexta
feira da semana seguinte realizar a revisão e retrospectiva do Sprint. Desta forma
tem se que o Sprint dura 10 dias, sendo 1 dia gasto com planejamento e 1 dia gasto
com revisão e retrospectiva.

24. Estimativas e Planejamento
Estamos aqui!

25. Estimando e Planejamento
• Na reunião de planejamento, o time seleciona as
histórias a serem desenvolvidas de acordo com a
sua prioridade.
• As histórias são estimadas utilizando-se a
sequência de Fibonacci: 1, 2, 3, 5, 8, 13, 21, 33,
54, 87 e assim por diante. Chamamos o número
atributo a história de pontos.
• Estes pontos deve ter um significado comum
para o time. Ele mede a complexidade e não
necessariamente está atrelada a um tempo.
• EU PARTICULARMENTE GOSTO QUE ELA ESTEJA
ATRELADA A UM TEMPO PELO MENOS
INICIALMENTE, POR EXEMPLO, DIAS INTEIROS! =)
#ProntoFalei
• Como se joga Scrum Poker?

26. Estimando e Planejamento
Como utilizar a sequência de Fibonacci de
forma sábia?
• Se o time aproximou nas estimativas, é um
indício que o entendimento está similar.
• Se está se convergindo para um número
muito alto (>13), maiores as chances de que
a estimava não esteja correta.
• Quanto maior a história, entende-se que maior
a probabilidade que vários detalhes tenham
ficado de fora na hora de se estimar.
• Neste caso é recomendável avaliar quebrar a
história em história menores ou
• se preparar para um risco de desvio (para mais
ou menos naquelas histórias)

27. Estimando e Planejamento
• O objetivo da reunião de planejamento é garantir o entendimento do que
deve ser feito e obter um estimativa aproximada do tempo que isso leva
para ser feito.
• As estimativas devem ser feitas considerando a atuação geral do time.
• O Scrum Poker é APENAS uma ferramenta auxiliar neste processo.
• O Scrum Poker não serve para medir conhecimento, capacidade produtiva
ou qualquer coisa do tipo. Não há vencedor no Scrum Poker.
• Lembre-se, o planejamento é do time, e o sucesso do planejamento e do
Sprint depende da unidade do time em todos os momentos.

28. Estimando e Planejamento
• Depois que a história foi estimada, a mesma deve ser quebrada em tarefas
menores e que possam ser feitas em no máximo um dia.
• Isto é importante para que se perceba o progresso no dia-a-dia.
• As tarefas devem ser estimadas em horas. A sequência de Fibonacci
novamente é recomendada.
• Não é recomendável que as tarefas sejam direcionadas, muito embora o
time possa combinar como elas serão dividas. Isto porque
• se determinadas tarefas forem sempre direcionadas para as mesmas pessoas, o
conhecimento e o aprendizado não será disseminado.
• Devido as circunstâncias do Sprint, isto pode acabar ocorrendo, mas isto deve ser
exceção.
• Se essa justificativa for utilizada rotineiramente, pode ser um sintoma de que algo
está errado.

29. Estimando e Planejamento
Quantas histórias estimar?
• Quantas forem possíveis fazer dentro do Sprint. Considerando que as histórias são
estimadas em dias por uma única pessoa e que há 13 dias de desenvolvimento, já
desconsiderando os dias gasto em planejamento, revisão e retrospectiva e com um
time de 4 pessoas temos:
4 x 13 = 52 dias. Neste caso, portanto devem ser estimadas histórias até que as
mesmas preencham 52 dias. Portanto cabem nesse Sprint, por exemplo 8 histórias
de 5 dias mais 4 histórias de 3 dias ( = 52 o/).
• O time não precisa comprometer a entregar todas elas, mas devem se
comprometer a entregar a maior parte delas. As histórias que o time se
compromete a entregar são chamadas de Sprint Goals .
• Quanto maior a maturidade e unidade do time, mais fácil será esta tarefa.
• Estimativas vs Comprometimento.

30. Estimando e Planejamento
Quanto tempo investir no planejamento?
• Não há regra. Mas a recomendação é que não se gaste mais do que um ou
dois dias.
• Planejamentos longos podem ser tornar tediosos.
• O planejamento deve ser suficiente. Qualquer coisa além disso pode ser
considerado desperdício.
Tarefas recorrentes devem ser incluídas no Sprint?
• A recomendação é que no Sprint esteja presente todas as atividades, já
que elas que possibilitarão a percepção de progresso, carga de trabalho e
etc.
E se houver atividades não previstas? (Cenas do próximo capítulo)

31. Planejamento – Atividades do P.O.
Uma dúvida comum é se as atividades do P.O., como as de refinamento das histórias
devem ser incluídas no Sprint. Para responder esta pergunta primeiro é importante
saber quem irá realizar a tarefa.
Este refinamento da história é de responsabilidade do P.O., porém nada impede que
algum membro do time execute esta tarefa. Se a tarefa é para ser executada pelo
time, certamente ela deverá estar dentro do Sprint.
Se a tarefa for executada pelo P.O., isto depende da forma de atuação do P.O.. Já
que as vezes o mesmo esta envolvido em diversos projetos, e nem sempre é eficaz
manter suas tarefas espalhadas por diversos projetos. Porém caso seja possível
manter a atividade dentro do Sprint para ser executada pelo P.O., é recomendável
que se faça assim. Isso pode ser uma ferramenta ótima para auxiliar o Scrum Master
na preparação do Sprint seguinte.

32. Planejamento – Atividades do SCRUM master
Assim como no caso do P.O., o mesmo se aplica ao caso do SCRUM master,
porém como o SCRUM master também é um membro do time, também é
importante que suas atividades sejam incluídas no Sprint, contribuindo para
que o time tenha visibilidade dos acontecimentos daquele Sprint.

33. Execução
O Sprint foi planejado e é chegada a
grande hora! É hora de colocar a mão
na massa!
Como que faz?
1. Vá até as tarefas que foram
planejadas
2. Selecione uma tarefa
3. Faça! =)

34. Execução Estamos aqui!

35. Acompanhamento da Execução
Para acompanhar o andamento
do Sprint, recomenda-se 2
gráficos:
• Hour burn down chart
(acompanhamento das horas
executadas)
• Tasks burn down chart
E também recomenda-se a
construção de um Scrum Board

36. Gráfico de queima em horas

37. Daily Meetings
Todos os dias, em um horário específico deve ocorre as daily meetings. A daily meeting é uma reunião diária, curta, em que
cada integrante geralmente possui de meio a um minuto para falar:
• Qual foi a última atividade em que atuou
• Qual atividade em que se está atuando
• Qual a próxima atividade que pretende atuar
O objetivo destas meetings é alinhar expectativas, ficar atento aos movimentos do time para assim ser capaz de buscar a
melhor formação ótima para entregar o máximo de histórias possíveis. Como acontece em um time de um esporte qualquer.
Os interessados nesta meeting é o time. A finalidade não é reportar para o SCRUM master, e sim conhecer e entender o
posicionamento tático do time naquele momento.
Nas daily meetings também é recomendável avaliar os burn down que devem estar atualizados até aquele momento, para
que se possível o time possa se reorganizar ou tomar qualquer ação necessária para atender os objetivos do Sprint.
Atenção:
• Qualquer discussão deve ser feita antes ou após a meeting, nunca durante. A daily meetings devem ser curtas.
• A daily meeting não é o momento para se avisar sobre algum problema. Qualquer problema na execução de alguma
tarefa deve ser explicitada o mais cedo possível, para que se obtenha auxílio do time ou do SCRUM master o quanto
antes. Não espere a situação ficar crítica para se manifestar.

38. Daily Meetings Estamos aqui agora!

39. Execução – Fique atento
• Atividades não planejadas/mapeadas
• Devem ser registradas para ajudar em estimativas futuras e para ajudar a
renegociar prazos
• Impedimentos
• Devem ser removidos o quanto antes.
• Hora extras
• Pode ser necessário, mas deve ser exceção.
• Entregar o que foi comprometido é essencial ...
• mas nem sempre possível. As vezes é necessário renegociar.

40. Performance
• Ramp up
• É necessário alguns Sprints até que o time encontre o equilíbrio.
• É normal que o início seja um pouco caótico. Seja precavido.
• O time precisa se conhecer e confiar uns nos outros.
• Happy hours são bem vindos!
• Depois que o time se conhece e entende o contexto que está inserido e consegue ser
produtivo ali, pode se dizer que a velocidade de vôo foi alcançada.
• Mantenha a unidade do time.
• Colocando mais pessoas, vamos conseguir produzir mais?
• Falácia! Ao adicionar novas pessoas no time, alguém terá que parar para orientar esta
pessoa até que ela alcance a velocidade de cruzeiro. Para alcançar esta velocidade, será
necessário alguns Sprints (depende da complexidade do projeto), até lá, é esperado que
a produtividade caia.
• Novas pessoas causam perturbações nas métricas
• One-piece-flow sempre que possível
• Compartilhar conhecimento
• Atividades em dupla pode aumentar a produtividade. Teste de vez em quando!

41. Execução
• É comum que no final do Sprint um tipo de atividade tenha se
acumulado, por exemplo atividades de Q.A.. Fique atento a esses
gargalos. Eles devem ser trabalhados para que não existam.
Antecipar estas atividades ou envolver mais pessoas na execução
destas pode facilitar. Mude sua tática para evitar estes gargalos.
• Histórias não finalizadas, automaticamente devem ser incluídas no
Sprint seguinte. Porém como ficam as métricas nesse caso?

42. Execução
Estamos aqui!

43. Sprint Review
• A review do Sprint serve para apresentar aos interessados e ao P.O. o
resultado do trabalho desenvolvido.
• Deve ser simples e informal.
• Sem necessidade de slides, mas também não são proibidos.
• Fale um pouco sobre o Sprint, o objetivo e apresente o trabalho
desenvolvido.
• O P.O. deve aceitar ou rejeitar o trabalho.

44. Retrospectiva
A retrospectiva serve para responder 3 perguntas
básicas:
• Quais práticas que foram incorporadas que
devemos manter?
• Quais práticas devemos descartar?
• Pois não estão funcionando.
• Pois produzem algo inútil ou pouco utilizado.
• Pois é muito onerosa.
• Quais práticas poderíamos incorporar?
As retrospectivas produzem muitas sugestões sobre as
quais o time deve buscar o consenso. Depois algumas
poucas sugestões devem ser selecionadas para que
sejam incorporadas buscando a melhoria contínua.
• Foco no processo e no time
• Questões individuais devem ser
tratadas em outro momento ... mas o
Scrum não define um momento para
isso.
• Nada na retrospectiva deve ser levada
de forma pessoal. Lembre-se de manter
o profissionalismo. O objetivo é buscar
jogar melhor como um time.

45. Como fazer a retrospectiva (sugestão)
• Ao longo da Sprint, lembre o time constantemente de anotar pontos para serem levados para retrospectiva
considerando as três perguntas básicas sobre as práticas (Quais são?)
• Reúna o time em uma sala
• Analise as métricas daquele Sprint.
• Distribua post-its
• Cada um escreve em um post um ponto anotados previamente e pontos que possam aparecer naquele momento.
• Agrupe os post its por assunto.
• Trabalhe primeiro naqueles assuntos que houveram mais post-its.
• Não escreva vários post-its sobre o mesmo assunto só para que ele seja discutido.

46. SCRUM e a Cultura Enxuta (Lean)
O SCRUM tem tudo a ver com a Cultura Enxuta:
• Eliminar o desperdícios
• Focar no essencial e no que precisa ser feito
• Melhoria contínua
• Demanda puxada e não empurrada
• Flexibilidade
• Lotes pequenos
O SCRUM tem tudo a ver com a Cultura Enxuta:
• Eliminar o desperdícios
• Focar no essencial e no que precisa ser feito
• Melhoria contínua
• Demanda puxada e não empurrada
• Flexibilidade
• Lotes pequenos

47. Kanban – Uma outra alternativa
O Kanban é similar ao SCRUM, talvez pelo fato de que o SCRUM pegou o quadro de Kanban emprestado.
Porém ao se utilizar o Kanban, a estratégia é diferente. O objetivo do Kanban é maximizar o throughtput.
Ao invés de fazer um plano para um ciclo, a história mais prioritária é estimada, planejada, executada e
revisada. Ao finalizar esta história, a mesma coisa é feita para a próxima história. O Backlog é dinâmico
da mesma forma. A retrospectiva pode ser feita regularmente ao final de cada história, ou em um
intervalo de tempo maior.
O Kanban pode ser interessante nas seguintes situações:
• cenários em que não é possível acumular histórias para serem desenvolvidas
• ao se formar uma nova equipe, para que ela se compreenda antes de partir para uma abordagem como
SCRUM
O Kanban é similar ao SCRUM, talvez pelo fato de que o SCRUM pegou o quadro de Kanban emprestado.
Porém ao se utilizar o Kanban, a estratégia é diferente. O objetivo do Kanban é maximizar o throughtput.
Ao invés de fazer um plano para um ciclo, a história mais prioritária é estimada, planejada, executada e
revisada. Ao finalizar esta história, a mesma coisa é feita para a próxima história. O Backlog é dinâmico
da mesma forma. A retrospectiva pode ser feita regularmente ao final de cada história, ou em um
intervalo de tempo maior.
O Kanban pode ser interessante nas seguintes situações:
• cenários em que não é possível acumular histórias para serem desenvolvidas
• ao se formar uma nova equipe, para que ela se compreenda antes de partir para uma abordagem como
SCRUM

48. Dicas gerais
• Time box pra tudo! Daily, Planning, Retrospectiva, Review!
• Foque no essencial!
• Melhore aos poucos e o que for mais prioritário, no máximo meia de dúzia de
coisas de cada vez, mesmo que se tenha centenas de pontos para atuar. Se
tentar melhorar tudo de uma vez, será difícil ver progresso.
• Priorize sempre.
• Abandone aquilo que não funciona, que seja muito oneroso e/ou que não traga
retorno.
• Evite troca de contextos
• Evite hand-offs
• Evite interrupções (POMODORI ?)
• Participe ou crie comunidades de pessoas da sua área para trocar
conhecimento.
• Ritos devem ser sagrados!
• Somente inicie o desenvolvimento quando o trabalho já estiver maduro o
suficiente para ser iniciado.

49. Dicas gerais
• Defina métricas que façam sentido para o seu projeto/produto/serviço.
• Defina métricas internas e externas (coletadas daquele que usufruem do
seu trabalho)
• Colete as métricas
• Analise as métricas
• Não burle as métricas
• Não melhore as métricas, o objetivo é melhorar o processo, as métricas
são apenas insumos para se avaliar o processo. Melhorar as métricas é
consequência de amadurecimento no processo.
• Automatize o que for possível (coleta de métricas, geração de gráficos e
etc)
• Se vocês não estão melhorando, vocês não estão utilizando o SCRUM.

50. Desafios comuns ao se adotar SCRUM
• É importante que a empresa, ou setores que façam interface com
àqueles que adotam o SCRUM entendam o processo e,
principalmente, seus benefícios para que esta interface seja
aderente ao processo.
• Dizer não para mudanças de escopo no meio do Sprint. O processo
já acomoda mudanças em intervalo de tempo razoável, se precisar
mudar, ou colocar algo novo, espere um pouco, a próxima Sprint
está logo ali.
• Superar resistências relacionadas a mudança de paradigma
• Superar resistências relacionadas a mudança de papel
• Superar resistências relacionadas ao trabalho em equipe.

51. O que vocês podem
aplicar agora?
Vamos fazer uma planning? Ou uma retrospectiva?

52. Referências
• Agile Estimating and Planning (Mike Cohn)
• Succeeding with Agile: Software Development Using Scrum (Mike
Cohn)

53. Obrigado!