1.
ELABORADO POR: ROLF VON CZEKUS JUNIOR, Me..

2.
 MANIFESTO ÁGIL
◦ O MANIFESTO
◦ OS PRINCÍPIOS
SCRUM
 PRINCÍPIO CHAVE ◦PRINCIPAIS ELEMENTOS
◦FLUXO BÁSICO
 ORIGEM ◦PRINCIPAIS
 SURGIMENTO CARACTERÍSITCAS
 CONCEITO ◦OUTROS ASPECTOS
IMPORTANTES
 FUNÇÃO ◦CLIENTES

3.
Important More important
• processes and tools • individuals and interaction
Important More important
• detailed documentation • functioning software
Important More important
• collaboration with the
• contract negotiations
customer
Important More important
• following a plan • adapting to changes
(Source: Manifesto for Agile Software Development http://agilemanifesto.org/

4.
 Envolve a quebra de paradigmas
◦ Busca estabelecer uma nova escala de valores, na
qual a flexibilidade e a colaboração são mais
relevantes do que a rigidez de processos e
planejamento clássicos.

5.
 Colaboração com clientes mais do que negociação de contratos;
 Responder a mudanças mais do que seguir um plano.
 Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
 Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;
 Projetos surgem através de indivíduos motivados, e que deve existir uma relação de
confiança.
 Simplicidade;
 Rápida adaptação às mudanças;
 Indivíduos e interações mais do que processos e ferramentas;
(Source: Manifesto for Agile Software Development http://agilemanifesto.org/

6.
o Garantir a satisfação do consumidor  Garantir a satisfação do consumidor
entregando rapidamente e entregando rapidamente e
continuamente softwares funcionais; continuamente PRODUTOS E /OU
SERVIÇOS
o Softwares funcionais são entregues  PRODUTOS E /OU SERVIÇOS são
frequentemente (semanas, ao invés de entregues frequentemente (semanas,
meses); ao invés de meses);
o Softwares funcionais são a principal  PRODUTOS E /OU SERVIÇOS funcionais
medida de progresso do projeto; são a principal medida de progresso
do projeto;
 (Source: Manifesto for Agile Software Development http://agilemanifesto.org/)

7.
o Design do software deve prezar pela  A QUALIDADE DOS PRODUTOS E /OU
excelência técnica; SERVIÇOS devem prezar pela excelência
técnica;
o Software funcional mais do que  PRODUTOS E /OU SERVIÇOS
documentação extensa; OPERACIONAIS mais do que
documentação extensa;
(Source: Manifesto for Agile Software Development http://agilemanifesto.org/)
 O conceito central é a adaptação as mudanças dos fatores externos.
 Não há busca por prever e antecipar todos os possíveis obstáculos;
 Busca ser flexível e se adaptar rapidamente às mudanças e a novas
demandas;

8.
 Reconhecer que desafios fundamentalmente
empíricos não podem ser resolvidos com sucesso
utilizando uma abordagem tradicional de
"controle".
 O Scrum adota uma abordagem empírica,
aceitando que o problema não pode ser totalmente
entendido ou definido, focando na maximização da
habilidade da equipe em responder de forma ágil
aos desafios emergentes.

9.
 Concebido como um estilo de gerenciamento
de projetos em empresas de fabricação de
automóveis e produtos de consumo, por
Takeuchi e Nonaka no artigo "The New Product
Development Game" (Harvard Business Review,
Janeiro-Fevereiro 1986).
 Observaram que equipes pequenas e
multidisciplinares (cross-functional)
apresentavam melhores performances;
 Associaram estas equipes altamente eficazes à
formação Scrum do Rugby;

10.
 Jeff Sutherland, John Scumniotales e Jeff
McKenna
◦ Conceberam, documentaram e implementaram o
Scrum na empresa Easel Corporation em 1993;
 Ken Schwaber
◦ Em 1995, formalizou a definição de Scrum e ajudou
a implantá-lo no desenvolvimento de softwares em
todo o mundo.

11.
 Conceito
◦ É uma framework para desenvolvimento ágil e
Gerenciamento de Projetos.
 Função
◦ Originalmente concebido para gerenciar projetos de
desenvolvimento de software;
◦ Aplicável em qualquer contexto no qual um grupo
de pessoas necessitem trabalhar juntas para atingir
um objetivo comum;

12.
 O Time SCRUM
◦ O time normalmente é composto por 5 a 9 pessoas;
◦ Composto por indivíduos altamente comprometidos
com o resultado;
◦ A própria equipe decide como o trabalho será
realizado e quem será designado para cada tarefa;
◦ A composição adequada do time é fundamental
para que o time possa se auto-organizar e manter
os compromissos;

13.
 O PRODUCT OWNER
◦ É o responsável:
 pelo Return On Investment (ROI);
 por conhecer as necessidades do cliente;
 por levantar os requisitos e priorizá-los;
 por re-priorizar a lista de requisitos;
◦ Gera e administra o Product Backlog;
◦ Representa a voz do cliente;
◦ Assegura que o time trabalhe com a perspectiva de
negócios correta;

14.
 O SCRUM MASTER
◦ É o responsável por remover qualquer obstáculo a
habilidade da equipe de entregar o objetivo do
Sprint;
◦ Combina as funções de:
 Coach
 Motivar o time;
 Manter o foco do time na meta do Sprint;
 Controller
 Assegurar que o time esteja utilizando corretamente as
práticas de Scrum;
 Guardião
 Atuar como o mediador entre a equipe e qualquer
influência desestabilizadora;
 Não é o Líder do Projeto;

15.
 O SCRUM MASTER
◦ Funções
 Reunir-se diariamente com o time;
 Adotar a perspectiva de trabalho do AQUI-E-AGORA;
 Prover o time com as melhores circunstâncias
possíveis para potencializar o atendimento das tarefas
estabelecidas no Sprint;
 Realizar a Sprint Retrospective Meeting após o término
de cada Sprint;

16.
 Product Backlog
◦ É uma lista de itens priorizados a serem
executados;
◦ É produzida pelo Product Owner;
◦ Contém os requisitos de alto nível;
 Sprint Planning Meeting
◦ Breve sessão de planejamento, na qual os itens do
Product Backlog são definidos para um Sprint
(iteração);
◦ Momento quando as prioridades do Backlog podem
ser re-priorizadas;
◦ Ocorre no primeiro dia do ciclo de vida do Sprint

17.
 Sprint Backlog
◦ É uma lista de tarefas concretas que serão
realizadas durante o próximo Sprint;
◦ Contém as informações detalhadas sobre como a
equipe irá implementar os requisitos do produto;
 Sprint
◦ É uma iteração que segue um ciclo (PDCA) e entrega
um produto e/ou serviço pronto;
◦ Deve ter um ciclo de vida de 2 a 4 semanas (aprox.
1.000 horas úteis);
◦ Etapa de execução das tarefas definidas no Sprint
Backlog;

18.
 Daily Meeting / Stand Up Meeting
◦ Breve reunião diária em que cada participante fala
sobre o progresso conseguido, o trabalho a ser
realizado e/ou o que o impede de seguir avançando
◦ Os membros da equipe geralmente ficam em pé
para não prolongar a reunião;
◦ Deve ter duração de aproximadamente 15 minutos;
◦ Sugere-se que sejam realizadas após o almoço,
pois permite ao time estar mais focado no trabalho;

19.
 Daily Meeting / Stand Up Meeting
◦ Cada membro da equipe responde às seguintes
perguntas:
 O que fiz desde ontem?
 O que estou planejando fazer até amanhã?
 Existe algo me impedindo de atingir minha meta?
 Demostration and Evaluation Meeting
◦ Cada Sprint é concluído com uma reunião onde o
produto ou serviço produzido é apresentado em
operação a um grupo de usuários, gestores e ao
Product Owner;

20.
 Sprint Review Meeting
◦ Retrospectiva, na qual todos os membros da equipe
refletem sobre a Sprint passada;
◦ É o ponto de partida para o início de um novo ciclo
de Sprint;
 Aprendizagem Organizacional
 Ferramentas
 Gerar massa crítica para discussão;
 Discutir os resultados;
 Elaborar relatório com o resultado da discussão;
 Publicar e Apresentar o relatório;

21.
 Spring Review Meeting
 Burn-down Chart

22.
 Clientes se tornam parte da equipe de desenvolvimento
(os clientes devem estar genuinamente interessados na
saída);
 Entregas frequentes e intermediárias de
funcionalidades 100% desenvolvidas;
 Planos frequentes de mitigação de riscos desenvolvidos
pela equipe;
 Transparência no planejamento e desenvolvimento;
 Reuniões frequentes com os stakeholders (todos os
envolvidos no processo) para monitorar o progresso;
 Problemas não são ignorados e ninguém é
penalizado por reconhecer ou descrever qualquer
problema não visto;

23.
 Curso oferecido pela PMTECH, conhecida
empresa Porto Alegre de treinamento e
consultoria em gestão de projetos que utiliza
a metodologia do PMI;

24.
 É o processo chamado na programação de
repetição de uma ou mais ações (WIKIPÉDIA,
2010).
 É um período de tempo definido dentro de
um projeto em que você produz uma versão
estável e executável do produto, junto com
toda a documentação de apoio, scripts de
instalação e similares, necessários para usar a
liberação. É também conhecida como ciclo ou
tempo definido (ECLIPSE.ORG, 2010).

25.
 MUITO OBRIGADO !
 Contatos do autor
◦ Nome: Rolf von Czekus Junior
◦ Email: rolfvcj@gmail.com
◦ projecta.bi@gmail.com