2. Gerente de Projetos e Scrum Master
Alessandro_rodrigues@terra.com.br
ALESSANDRO RODRIGUES, CSM
3. COMO SURGIU O ÁGIL?
• O ágil surgiu dado a necessidade de
melhorarmos a forma como estamos
desenvolvendo SW e nosso foco principal é
satisfazer o cliente.
5. PRINCÍPIOS Á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 frequência, na escala de semanas
até meses, com preferência aos períodos mais curtos.
• Pessoas relacionadas à negócios e desenvolvedores devem trabalhar
em conjunto e diariamente, 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.
6. PRINCÍPIOS ÁGIL
• 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.
• 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.
7. TRADICIONAIS X ÁGIL
• TODAS metodologias de projetos existem
planejamento antes da execução.
• Tradicionais (PMI e PRINCE, podia usar a palavra
burocracia) se planeja muito com antecedência.
• Plano de Projeto.
• Cronograma detalhado de atividades.
• ...
• Ágeis (SCRUM, DSDM, XP e FDD) se planeja de
forma iterativa e incremental, descobrindo o
percurso no caminho.
8. TRADICIONAIS X ÁGIL
• Tradicionais: As especificações são mais importantes
que o prazo e custo: o cliente pode querer um carro
com 140 HPs, 5 portas, completo e não menos do
que isso.
• Ágeis: Focam em resolver o problema com um
orçamento e prazo fixo. O cliente precisa de um
veículo e está disposto a aceitar uma bicicleta, uma
moto um carro
10. O QUE É SER ÁGIL?
• Ágil é uma nova forma de gestão e desenvolvimento
de Software que usa uma abordagem de
planejamento e execução iterativa e incremental
• Divide o problema em produtos menores e que visa
entregar software funcionando regularmente
• Visa a aproximação e maior colaboração do time de
desenvolvimento com os experts de negócios
11. O QUE É SER ÁGIL?
• Então quer dizer que ser Ágil não é entregar mais
rápido?
12. QUAL O MOTIVO DE SER ÁGIL?
• Maior produtividade e menores custos.
• Projetos ágeis são no mínimo 16% mais produtivos.
• Maior engajamento e satisfação no trabalho da
equipe.
• Melhoria mínima de 10% e média de 63%.
• Maior qualidade
• Maior satisfação dos envolvidos.
13. QUAL O MOTIVO DE SER ÁGIL?
• Ágil é tão apaixonante quanto um bebe panda.
• Uma gestão transparente e participativa
(management 3.0)
• Porque ser ágil não é simplesmente rodar sprints,
fazer daily meeting ou então montar um kanban
na parede, e sim saber ser transparente, dar e
receber feedback, conflitar, confiar, sempre
enxergar o valor além do código escrito e
entender que o seu melhor amigo é o cliente.
• É por isso que foi tão fácil se apaixonar pelo ágil:
ele te move, te energiza e acima de tudo é
inovação.
14. VANTAGENS PARA O CLIENTE.
• Foco e maximização do ROI (Retorno do Investimento) e do
Valor de Negócio;
• Entregas do produto + rápida, frequentes e regulares;
• Aceleração do Time-to-market o que se traduz em ganho de
competitividade;
• Foco no que é prioritário e traz mais valor para o usuário, o
que se traduz em ganho de usabilidade;
• Transparência e visibilidade do status do projeto;
• Flexibilidade para mudanças de requisitos e prioridades além
de maior agilidade na tomada de decisões;
• Melhoria da Qualidade do produto final;
• Produtividade;
• Redução dos riscos e das indesejáveis surpresas.
15. VANTAGENS PARA O EQUIPE.
• Escopo e objetivos claros e priorizados;
• Equipes auto gerenciáveis, maior autonomia, disciplina e
regularidade;
• Maximização do comprometimento;
• Melhoria na comunicação. A comunicação intensa com o
cliente e a gestão de suas expectativas são parte do processo;
• Inspeção e Adaptação constantes do processo em busca da
melhoria contínua e a redução dos desperdícios;
• Antecipação dos problemas e maior agilidade na tomada de
ações.
16. SCRUM
• Desenvolvimento Incremental
• Que aumenta gradualmente
• Entrega de Valores
• Desenvolvimento Iterativo
• reiterado, repetido
• Teoria da Complexidade
• Timebox
• Lean
21. O QUE É SCRUM?
Scrum é uma estrutura processual (framework) para suportar o
desenvolvimento e manutenção de produtos complexos. O Scrum
consiste em Equipes do Scrum associadas a seus papéis, eventos,
artefatos e regras. Cada componente dentro do framework serve
a um propósito específico e é essencial para o uso e o sucesso do
Scrum.
É um framework ágil para gestão e planejamento de projetos de
software que permite manter o foco na entrega do maior valor de
negócio, no menor tempo possível;
Permite a rápida e contínua inspeção do software em produção;
22. O QUE É SCRUM?
FRAMEWORK
FRAMEWORKFRAMEWORKFRAMEWORK
- Kanban
- Burndow
SCRUM BUT
23. O QUE É SCRUM?
Fluxo Papéis
Artefatos Eventos
Valores
e
Princípios
24. SCRUM E SEUS VALORES
• Foco
• Vamos concentrar em apenas em um pouco de coisas. Nós entregamos
itens valiosos mais cedo
• Coragem
• Trabalhamos como equipe. Coragem para assumir desafios maiores
• Abertura
• A medida que trabalhamos juntos, expressamos como estamos fazendo,
o que está em nossos caminhos e as nossas preocupações.
• Compromisso
• Temos grande controle sobre os nossos compromissos, estamos
comprometidos com o sucesso.
• Respeito
• A medida que trabalhamos juntos, compartilhamos os sucessos e
fracassos.
28. PRODUCT OWNER
Composição: 1 PO 1 DEV TEAM
Habilidades:
• Negócio
• Análise de Negócio
• Gestão do Projeto e/ou Produto
Responsabilidades:
• Dono do Product Backlog
• Dono das prioridades
• Sabe o que deve ser feito e o porque deve ser feito
• Gestão da Visão
• Escreve, Refina e Prioriza os Requisitos
• Gestão dos Releases
• Aceitar ou Rejeitar as entregas do DEV Team
• Forte comunicação com o DEV Team
• Gestão do BUDGET
• Comunica Status Report para os Envolvidos
29. DEV TEAM
Composição: (3) 5 – 9 pessoas
Habilidades:
• Possuir todo conhecimento técnico necessário
para entregar incremento de produto pronto.
• Auto-Organização (Gestão)
• Comunicação
Responsabilidades:
• Planejar e Gerenciar a Sprint
• Se comprometer e entregar uma meta ao PO.
• Apontar os Impedimentos
• Resolver seus próprios problemas
• Definir soluções técnicas para o produto.
31. SCRUM MASTER
Composição: 1 SM 1 DEV TEAM
Habilidades:
• MAIOR conhecedor de Scrum naquele projeto.
• Conhecer outros processos.
• Gestão de Pessoas (Soft Skills)
Responsabilidades:
• Ensinar o processo / Manter o processo funcionando
• É um facilitador
• Garante o correto uso dos processos
• Remove os impedimentos do DEV Team
• Energiza as pessoas mantendo-as focadas e
comprometidas
• Facilita as reuniões e discussões
• Fornece coaching aos envolvidos no projeto
32. SPRINT
SPRINT: O coração do Scrum é a Sprint, um time-box de um mês ou menos, durante o
qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado
33. SPRINT
Produto / Serviço (Valor):
• Cliente / Usuários-Alvo
• Problemas
• Benefícios
• Diferenciais
• Macro Funcionalidades
(Product Backlog)
Projeto (Restrições)
• Custo / Prazo
• Contratos e Aquisições
• Arquitetura e Tecnologia
• Riscos
• ...
Processos (Conformidades)
• Governança
• Certificações, Modelos
• CMMI2...
• Primeiras definições
• Tamanho do Sprint
• Def. of Ready
• Def. of Done
• ...
Participantes: PO, SM, DEV TEAM e Outros Interessados
Reunião de Visão (Pre Game)
35. SPRINT
Meta
Reunião de Planejamento (Planning)
Objetivo:
• Primeira Parte (O que?): Apresentação dos Product Backlog Priorizado e
Definir a Meta
• Durante o Sprint Planning Meeting, o Product Owner descreve as
funcionalidades de maior prioridade para a equipe.
• A equipe faz perguntas durante a reunião de modo que seja capaz de
quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas
tarefas irão dar origem ao Sprint Backlog.
• Define o Sprint Backlog Inicial.
• Jogas-se o Planning Poker.
• Define um objetivo para o Sprint, que é uma breve descrição daquilo que
se tentará alcançar no Sprint.
• Segunda Parte (Como): Equipe discute para definir o que cabe o Sprint.
• Depois do Sprint Planning Meeting, a equipe Scrum se encontra
separadamente para conversar sobre o que eles escutaram e decidir
quanto eles podem se comprometer a fazer no Sprint que será iniciado.
Participantes: PO, SM, DEV TEAM e Outros Interessados
36. SPRINT
Meta
Reunião de Planejamento (Planning)
Objetivo:
• Segunda Parte (Como): Equipe discute para definir o que cabe o Sprint.
• Depois do Sprint Planning Meeting, a equipe Scrum se encontra
separadamente para conversar sobre o que eles escutaram e decidir
quanto eles podem se comprometer a fazer no Sprint que será iniciado.
• Cria-se as atividades
• Cria-se o quadro Kanban
• Cria-se o Burndow.
Participantes: PO, SM, DEV TEAM e Outros Interessados
37. SPRINT
Reunião de Planejamento (Planning)
Meta
PO
PO
DEV Team
DEV Team
3 5
3
Def. Of Done
• Codificado seguindo o padrão X
• Testado.
• Documentado
• Liberado em ambiente de QA
• Reduz dívidas técnicas
• Ajuda nas “Alterações de 2
minutos”
39. SPRINT
Burndow
O Burndown chart ou gráfico de Burndown é o gráfico utilizado pelas equipes Scrum
(somente para o Dev Team) para representar diariamente o progresso do trabalho em
desenvolvimento. Saber o quanto falta de trabalho. Ou seja, após cada dia de trabalho
o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho
total planejado.
40. SPRINT
Objetivo:
• Disseminar conhecimento sobre o que foi feito no dia anterior, identificar
impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
• Ocorre no mesmo lugar, no mesmo horário com duração máxima de 15
minutos. REALIZADA EM PÉ.
• Daily Scrum não deve ser usado como uma reunião para resolução de
problemas.
• Cada membro da equipe provê respostas para cada uma destas três
perguntas:
• O que você fez ontem?
• O que você fará hoje?
• Há algum impedimento no seu caminho?
• O Daily Scrum não é uma reunião de status report na qual um chefe fica
coletando informações sobre quem está atrasado. É uma reunião na qual
membros da equipe assumem compromissos perante os demais.
• Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum
Master o mais rapidamente possível.
Participantes: SM e DEV TEAM. PO se necessário
Reunião Diária (Daily)
41. SPRINT
Sprint – Reunião de Revisão do Sprint (Review)
Objetivo:
• O Dev Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso
tem o formato de um demo das novas funcionalidades.
• Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do
Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe
completou cada um dos itens do Product Backlog trazidos para fazer parte do
Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do
Sprint.
• Não deve ocorrer surpresa, pois houve a DAILY com todos os envolvidos.
• Atualizar o status do projeto.
• Os itens que deram problemas será tratados no próximo Sprint.
Participantes: PO, SM, DEV TEAM e Outros Interessados
42. SPRINT
Sprint – Reunião de Retrospectiva (Retrospective)
Objetivo:
• Ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o
que pode ser melhorado e que ações serão tomadas para melhora.
• Apontar quais foram os pontos críticos do Sprint para discutir com todos os
envolvidos na intenção de melhorar no próximo Sprint.
• Utilizar o método de o que foi BOM, RUIM e o que pode MELHORAR criando
planos de ação para os itens que foram ruins e as melhorias apontadas.
• As melhorias podem virar item no Sprint Backlog
Participantes: PO, SM, DEV TEAM e Outros Interessados
44. SPRINT
Definição de Pronto (Def. Of Done)
Def. Of Done
• Codificado seguindo o padrão X
• Testado utilizando as técnicas X e Y
• Documentado.
• Liberado em ambiente de QA
• Reduz dívidas técnicas
• Ajuda nas “Alterações de 2
minutos”
Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”,
todos devem entender o que o “Pronto” significa.
Com um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja expandida
para incluir critérios mais rigorosos de alta qualidade.
Desenvolvimento Incremental
Que aumenta gradualmente
Desenvolvimento Iterativo
reiterado, repetido
Então quer dizer que não posso usar Scrum em sistemas Complicado (Esforço Definido).
Cliente não fica esperando meses para ver os sistema. No final do Sprint ele tem um Sistema funcionando (PRONTO)>
SCRUM É UM FRAMEWORK... VC PODE ACRESCENTAR SUAS NECESSIDADES. MAS NÃO PODE TIRAR
As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a restrospectiva da Sprint.
Não serve para status report. Mostra por time
Problemas: Demora, Pessoas Atrasadas, Resposta mecânica as perguntas, Não são levados impedimentos.