Apresantação inicial para introdução do Scrum comom Framework para entrega do valor mais alto possível nos projetos.

1. Gerenciamento de Projetos Ágeis
William Lima
Avanti Agência Digital

2. “- Como um projeto atrasa 2 anos?
- Um dia de cada vez!”
– Fred Brooks (The Mythical Man-Month)

3. Scrum, O que é?
• Não é uma sigla para nada
• É o momento do jogo de Rugby quando a equipe está toda unida
com um único propósito em uma formação específica onde a
participação de todos é essencial, a falta de comprometimento de
um membro pode fazer a formação cair, então a união e o foco no
objetivo (mover a bola em direção ao gol) é primordial.

5. Scrum, O que é?
Em desenvolvimento de software é uma metodologia usada para uma
gestão dinâmica de projetos.
Um processo de desenvolvimento iterativo e incremental para
gerenciamento de projetos e desenvolvimento ágil de software.
É utilizado para trabalhos complexos nos quais é impossível predizer
tudo o que irá ocorrer.

6. Manifesto Agil
O início do manifesto para desenvolvimento ágil de software se teve com um grupo de profissionais
e pesquisadores de TI com o objetivo de criar uma nova forma de melhor o desempenho de seus
projetos, surgindo então o seguinte manifesto:
"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e
ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:
• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software 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.
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

7. Princípios
O manisfesto ágil traz doze princípios de um processo ágil:
• Nossa maior prioridade é satisfazer o cliente, através da entrega
adiantada e contínua de software de valor;
• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.
Processos ágeis se adequam a mudanças, para que o cliente possa
tirar vantagens competitivas;
• Entregar software funcionando com freqüencia, na escala de
semanas até meses, com preferência aos períodos mais curtos;

8. Princípios
• Pessoas relacionadas à negócios e desenvolvedores devem
trabalhar em conjunto e diáriamente, durante todo o curso do
projeto;
• Construir projetos ao redor de indivíduos motivados. Dando a eles o
ambiente e suporte necessário, e confiar que farão seu trabalho;
• O Método mais eficiente e eficaz de transmitir informações para, e
por dentro de um time de desenvolvimento, é através de uma
conversa cara a cara;

9. Princípios
• Software funcional é a medida primária de progresso;
• Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser capazes de
manter indefinidamente, passos constantes;
• Contínua atenção à excelência técnica e bom design, aumenta a
agilidade;

10. Princípios
• Simplicidade: a arte de maximizar a quantidade de trabalho que não
precisou ser feito;
• As melhores arquiteturas, requisitos e designs emergem de times
auto-organizáveis;
• Em intervalos regulares, o time reflete em como ficar mais efetivo,
então, se ajustam e otimizam seu comportamento de acordo.

11. Características do Scrum
• Trabalha de forma iterativa e incremental
• As equipes são mutli-funcionais (cross-functional) e auto-organizadas
(self-organizing)
• Foca em prioridade: equipe sabe por onde começar e o que é mais
prioritário para o cliente
• Objetividade: metas menores (por sprints) atingíveis e claras.

12. Características do Scrum
• Visibilidade: clara visibilidade do que está completo e as pendências o
que reduz os riscos e as incertezas associadas ao projeto
• Aumento do ROI*: entregando funcionalidades antes para a validação
do cliente.
• Maior flexibilidade a agilidade: permite rever o planejamento, mudar de
direção ou fazer adaptações para as próximas iterações.
• Não há prática de engenharia prescrita (o Scrum adequa-se a todas)
*Retorno sobre investimento

13. Ciclo um projeto sem Scrum
Requerimento
Projeto
Implementação
Verificação
Manutenção

14. Ciclo de um projeto com Scrum
Requerimento
Projeto
Implementação
Verificação
Manutenção
N Vezes

15. Ciclo de Vida Scrum
O ciclo de vida do Scrum é baseado em três fases principais, divididas em subfases. Sãoo
estas o pré-planejamento, desenvolvimento e pós-planejamento.
• O pré-planejamento é a fase no qual são feitas estimativas de esforço para o
desenvolvimento de cada requisito, bem como a definição da equipe de desenvolvimento,
as ferramentas que serão utilizadas e a real necessidade de treinamento.
• Na segunda fase - denominada de desenvolvimento - são identificados previamente as
inúmeras variáveis técnicas e do ambiente para serem observadas e controladas durante o
desenvolvimento, aumentando assim a flexibilidade para acompanhar as mudanças.
• Por fim, na fase de pós-planejamento, são realizadas reuniões para analisar o progresso
do projeto e demonstrar o software atual para os clientes.

16. Ciclo de Vida Scrum
Quer que eu desenhe?

17. O Framework Scrum
Ok, Ok, vamos por partes!
• Papéis e Responsabilidades
• Artefatos
• Cerimônias

18. Papéis e Responsabilidades
Product Owner - Scrum Master - Equipe/Time de Desenvolvimento

19. Product Owner
• Encomenda o projeto e define os requisitos e as prioridades para
o produto.
• Representa o cliente ou um grupo deles.
• Define o produto.
• Conhecedor das necessidades do cliente.
• Organiza o backlog de produto.
• Cria as estórias de usuários.
• Tira duvida da equipe de desenvolvimento.
• Aceita ou não o incremento.

20. Scrum Master
• Deve ser um dos membros da equipe de
trabalho.
• Tem a responsabilidade de orientar o time
para que sejam atendidos os valores e as
práticas do Scrum.
• Participa ativamente das reuniões propostas.
• Assegura o entendimento do Scrum.
• Remove conflitos e impedimentos.
• Imparcial / Neutro.

21. Time/Equipe de Desenvolvimento
• Uma equipe Scrum tem tipicamente de 6 a 9
membros úteis.
• Caso haja mais membros do que o
administrável, o projeto deve ser dividido em
vários sub-projetos.
• Os membros do time são responsáveis por
negociar com o PO os requisitos que serão
trabalhados em cada Sprint.
• Trabalham nas produtividades definidas
pelo PO.

22. Product Owner - Scrum Master - Time de Desenvolvedores
Em resumo é isso!

23. Artefatos do Scrum
Visão - Estórias - Backlog: Product Backlog / Sprint Backlog - Burndown -
Taskboard / Kanban

24. Visão
Todo Produto necessita de uma visão,
um objetivo, uma meta. A visão do
produto nos faz parar e pensar, porque
vamos construir este software? Qual o
real propósito deste trabalho que será
realizado?
Começar o projeto pelo Product
Backlog sem a visão é como fazer
compras com fome. Tudo parece uma
boa idéia, uma boa funcionalidade.

25. Estórias
É um descritivo claro e objetivo, porém
resumido, da funcionalidade que será
desenvolvida.
Muitas vezes uma estória cabe em um
post-it por conta da sua objetividade;

26. Backlog
É a lista de requisitos da aplicação que
será necessária para o seu
entendimento e desenvolvimento. O
responsável por ela é o Product Owner.
O backlog é dividido em duas partes
sendo elas o Product Backlog e o Sprint
Backlog.

27. Product Backlog
O product backlog é uma lista de tudo o
que possa ser necessário no produto, e
é a única fonte de requisitos para que
sejam feitas alterações no produto.
Nessa lista contém todas as
funcionalidades - que são visíveis ao
cliente - e também requisitos técnicos
para poder desenvolver o produto onde
os itens da lista devem estar definidos
em 10 dias para iniciar o
desenvolvimento.

28. Sprint Backlog
O sprint backlog é uma lista de tarefas
identificadas pela equipe de Scrum para ser
concluída durante o sprint.
Durante a reunião de planejamento do
sprint, a equipe seleciona um determinado
número de itens do product backlog,
geralmente sob a forma de histórias de
usuários, e identifica as tarefas necessárias
para que estas seja completadas.
A maioria das equipes também estimam
quantas horas cada tarefa vai levar para ser
concluída.

29. Gráfico de Brundown
É um gráfico que mostra a linha de
esforço frente aos trabalhos que
precisam ser realizados.
Os eixos que forma esse gráfico
analisam a quantidade de trabalho a ser
completado (eixo y) e as datas ou dias
de execução (eixo x).
O Burndown, assim como o Backlog,
também é divido em duas partes, um
gráfico para o Produto e outro para o
Sprint.

30. Taskboard - Kanban
É uma espécie de quadro onde cada
estória é colada, a partir dele dá para
saber quais atividades ainda estão na
fila de desenvolvimento, quais foram
feitas e quais estão sendo
desenvolvidas.
Utilizando-o dá para se ter uma visão
geral em poucos segundos de como o
projeto está.
Pode ser utilizado com tarefas no lugar
de estórias.

31. Cerimonias Scrum
Release Planning - Sprint Planning - Daily Scrum - Sprint Review -
Retrospectiva do Sprint

32. Release Planning
No início de um projeto o time criará um Release Plan em alto nível.
Não é possível que o time conheça tudo no início, portanto, um plano
detalhado não é necessário.
Esta reunião está a cargo do Time de Desenvolvimento, deve ter a
participação ativa do Scrum Master e Product Owner.

33. Release Planning
O Release Plan deverá abordar:
• A quantidade e a duração dos Sprints
• Quantas pessoas ou times deverão participar do projeto
• O número de Releases
• O valor a ser entregue em cada Release
• A data de liberação do(s) Release(s)

34. Release Planning
As principais informações para o Release Planning são:
• A priorização dos Product Backlogs
• A estimativa da velocidade
• O Product Owner deve atender as datas importantes (time-to-market)
impostas pelo mercado.

35. Sprint Planning
A reunião Sprint Planning é realizada com a presença do Product Owner, Scrum Master e de todo Scrum
Team, e quaisquer interessados, diretores ou representantes do cliente.
Durante a reunião Sprint Planning, o Product Owner explica as funcionalidades de maior prioridade para o
Scrum Team. Durante esta reunião o Scrum Team faz perguntas que sejam suficientes para que eles
possam, depois da reunião, definir quais atividades eles irão mover do Product Backlog para o Sprint
Backlog.
Juntos, o Scrum Team e o Product Owner definem um objetivo para o Sprint (Sprint Goal), que é uma breve
descrição do que pretende-se atingir no Sprint. O sucesso do Sprint será verificado posteriormente durante a
reunião Sprint Review, baseado no Sprint Goal em vez de em itens específicos do Sprint Backlog.
Depois da reunião Sprint Planning, o Scrum Team reune-se separadamente para discutir o que foi dito e
decidir o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá
negociações com o Product Owner, mas será sempre prerrogativa do Scrum Team determinar o quanto eles
podem se comprometer.

36. Sprint Planning
• É definido o objetivo do sprint.
• A lista de membros da equipe (e seus níveis de comprometimento, se não
100%) – capacidade da equipe.
• O sprint backlog uma lista de atividades que deverão ser executadas para
concluir cada item do backlog (estória ou caso de uso).
• Estimativas para cada item/atividade do sprint backlog.
• Uma data definida para a apresentação do sprint.
• Data e local definidos para a reunião diária.

37. Daily Scrum
Todos os dias do Sprint, o Scrum Team realiza reuniões diárias. Essas reuniões geralmente são realizadas no
mesmo local e horário todos os dias. O ideal é que as Reuniões de Daily Scrum sejam realizadas pela manhã, uma
vez que ela apoia a determinar as atividades do dia.
Todos os membros do time devem participar da Reunião de Daily Scrum. Outras pessoas (por exemplo, a gerência
de um departamento, um vendendor ou um desenvolvedor de outro projeto) podem estar presentes, mas apenas
como ouvintes. Isso torna as Reuniões de Daily Scrum uma excelente forma do Scrum Team comunicar a situação
atual - se você está interessado em saber em que ponto o projeto está, frequente esta reunião diária.
A Reunião de Daily Scrum não é uma reunião usada para solucionar problemas ou dúvidas. As dúvidas que
surgirem deverão ser postergadas e, de modo geral, serem tratadas pelo grupo envolvido imediatamente após a
Reunião de Daily Scrum. Durante a reunião, cada membro do Scrum Team responde às seguintes perguntas:
1. O que você fez ontem?
2. O que você vai fazer hoje?
3. Existe algum impedimento?

38. Daily Scrum
O Scrum Master é responsável por solucionar quaisquer impedimentos identificados o mais
rapidamente possível. Geralmente são impedimentos:
• Meu _____ quebrou e eu preciso de um novo hoje.
• Eu ainda não recebi o software que pedi um mês atrás.
• Eu preciso ajudar ao(à) ________ a depurar um problema.
• Eu estou me esforçando para aprender ________ e gostaria de fazer isto em par com alguém.
• Não consigo retorno da equipe de suporte técnico do fornecedor.
• O grupo _______ não tem tempo para se reunir comigo.
• O diretor da área me pediu para trabalhar em outra coisa por um dia ou dois.

39. Sprint Review
Ao final de cada Sprint, uma Reunião Sprint Review é realizada. Durante esta reunião, o
Scrum Team apresenta o que foi realizado durante o Sprint. Tipicamente, esta
apresentação é feita na forma de uma demonstração das novas funcionalidades.
Participantes da Reunião Sprint Review, tipicamente inclui o Product Owner, o Scrum
Team, o Scrum Master, a diretoria, clientes e engenheiros de outros projetos.
Durante a Reunião Sprint Review o projeto é avalidado baseado no Sprint Goal,
determinado durante a Reunião Sprint Planning. O ideal é que a equipe tenha concluído
todos os itens do Product Backlog alocados para o Sprint, mas é mais importante que
eles alcancem Sprint Goal.
Força a equipe a realmente terminar as coisas e liberá-las (mesmo que seja apenas em
um ambiente de teste)

40. Retrospectiva
É a reunião de lições aprendidas (Lessons Learned) – o que podemos fazer melhor no próximo
sprint?
O ScrumMaster se reúne com a equipe de desenvolvimento e revisa os altos e baixos do ciclo. O
time conversa para saber o que foi bom e como se pode melhorar ainda mais o ambiente, as
ferramentas e o convívio entre o time e suas funções. Esta parte é basicamente um aprimoramento
interno.
Depois que esta reunião é finalizada, um novo ciclo Sprint pode começar até que todo o produto
seja implementado/finalizado e o Product Backlog esteja limpo de pendências.
• Bom: se pudéssemos faríamos do mesmo modo;
• Poderia ter sido melhor: faríamos tal item de maneira diferente;
• Melhorias: idéias concretas de como melhorar o processo / ferramentas, etc no próximo sprint.

41. Ciclo de Vida Scrum
E agora? Entendeu?

42. Referências
• https://www.scrumalliance.org/
• http://www.codeproject.com/Articles/4798/What-is-SCRUM
• http://unifenas.br
• https://www.scrum.org/Scrum-Guide
• http://scrummethodology.com/