SlideShare uma empresa Scribd logo
1 de 132
Entregando Software
com “Valor”
Maicon Carlos Pereira
Maicon Carlos Pereira
• Graduado em Ciência da Computação
• MBA em Gerenciamento de Projetos
• + 12 anos desenvolvendo software
Objetivos
Ciclos de Vida de um
projeto
Cascata
Início
do Projeto
Término
do Projeto
planejamento acontece no início e a execução ocorrendo
em uma única vez, num processo sequencial.
Estudo
Análise
Projeto
Execução
Testes
Implantação
Cascata - Waterfall
Incremental
fornece entregáveis finalizados que o cliente poderá usar
imediatamente
Início
do Projeto
Término
do Projeto
Iterativo
permite o feedback sobre trabalho inacabado através de
protótipos para melhorar o produto final
Início
do Projeto
Término
do Projeto
Ágil – Iterativo e Incremental
Feedback e entregas frequentes.
Início
do Projeto
Término
do Projeto
Ágil ou Cascata?
Funciona?
Em produção de produto, carro, eletrodoméstico...
Onde os procedimentos Claros.
Um projeto passado é de fácil reprodução e sucesso
Funciona?
Resumindo,
Cascata no desenvolvimento de software, Funciona?
Por que não funciona?
• Desenvolver software é um processo criativo
• É um processo artesanal
• É um processo empírico (o conhecimento vem da experiência)
• Exige pesquisa
• ...
E como se faz??
Metodologia Ágil
Manifesto Ágil
 Desenvolvedores e consultores de software se juntaram
para compartilhar valores e princípios que eram utilizados
em suas práticas
 Agile Software Development Alliance
Ward
Cunningham
2001
Robert C.
Martin
...
Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a fazerem o
mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações 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
http://www.manifestoagil.com.br/
Princípios Ágeis
1. Nossa maior prioridade é satisfazer o cliente, através da
entrega adiantada e contínua de software de valor.
2. 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.
3. Entregar software funcionando com freqüencia, na escala de
semanas até meses, com preferência aos períodos mais curtos.
Princípios Ágeis
4. Pessoas relacionadas à negócios e desenvolvedores devem
trabalhar em conjunto e diáriamente, durante todo o curso do
projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a
eles o ambiente e suporte necessário, e confiar que farão seu
trabalho.
6. 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.
Princípios Ágeis
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser
capazes de manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta
a agilidade.
Princípios Ágeis
10. Simplicidade: a arte de maximizar a quantidade de trabalho
que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de
times auto-organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais
efetivo, então, se ajustam e otimizam seu comportamento de
acordo.
Espere ai... Vamos calma...
Ser Ágil
não é ser
Rápido ou
Veloz
Ser ágil é:
É entregar valor com frequência,
gerando feedback e
adaptando-se (rapidamente)
às mudanças.
Entrega de valor com frequência...?
Não é o mais forte que sobrevive,
nem o mais inteligente,
mas o que melhor
se adapta às mudanças
Charles Darwin
Adaptando-se às mudanças...
“
Ágil é
falhar rápido
Falhar rápido???
Ágil não é uma bala de prata.
Não é a solução de todos os problemas.
Quando ser ágil?
• Exigem pesquisa e
desenvolvimento;
• Têm altas taxas de mudança;
• Têm requisitos, incerteza ou
risco pouco claros ou
desconhecidos; ou
• Têm um objetivo final difícil de
descrever
Agile Practice Guide
Como ser ágil?
E ágil combina com T.I.?
Ou apenas empresas de Software?
TI vs Core Business da Empresa
https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/
TI Bimodal = Maratonista + Velocista
Diferentes, mas essenciais
https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/ https://www.gartner.com/it-glossary/bimodal/
https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/
Modo 1 – Maratonista Modo 2 – Corredor/Velocista
Confiabilidade Objetivo Agilidade
Desempenho Valor
Retorno, marca, valor ao
cliente, UX
Cascata, ITIL, Cobit, ISO, ... Abordagem
Ágil, Kanban, Lean IT, DevOps,
...
Dirigida por planos e níveis de
aprovação
Governança
Empírica, contínua, baseada
em processos
Fornecedores corporativos e
relações a longo prazo
Parceiros
Fornecedores novos,
pequenos e curto prazo
Bom em processos
convencionais e em projetos
Talento
Bom em projetos novos e
incertos
Centralizada em TI Cultura
Centralizada no negócio e
próxima aos usuários
Longo (meses) Ciclo Curto (dias, semanas)
TI Bimodal = Maratonista + Velocista
Diferentes, mas essenciais
https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/ https://www.gartner.com/it-glossary/bimodal/
TI Bimodal é o caminho para a transformação digital...”
As empresas precisam desenvolver ações inovadoras e
disruptivas
ao mesmo tempo em que continuam a fazer
negócios como sempre
https://www.gartner.com/it-glossary/bimodal/
“
http://cio.com.br/opiniao/2016/09/27/bimodal-ja-era/
“O modelo de TI bimodal reforça a mensagem que os
clientes corporativos querem ouvir,
que as disrupções podem ser controladas e adotadas gradualmente.
Mas acaba gerando procrastinação e atrasando a
velocidade da empresa em fazer sua transformação de negócios.
Cezar Taurion
Head & Partner Digital Transformation at KICK
“
“Estamos desconstruindo a nossa TI Bimodal.
Eu mesmo a implementei.
Ela foi importante e hoje já não basta.
Não existe transformação digital sem velocidade,
sem mudar a cultura do meu time e da própria empresa.
É uma nova TI, pronta para o futuro”
Cristiano Barbieri,
CIO da SulAmerica
https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/
“
... na nossa visão, foi vital usar a metodologia ágil,
com ciclos curtos, entregas rápidas.
Isso exigiu uma reestruturação do time.
É fundamental somar competências,
muito treinamento, alinhamento e capacitação.
Cristiano Barbieri,
CIO da SulAmerica
https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/
“
https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/
“A TI Bimodal hoje não faz parte do novo cenário
composto por exemplo
pela metodologia Ágil,
que tem novos propósitos.
Estamos na migração do 100% Ágil”
Viviane Lusvarghi
CIO da Santher
“
https://epocanegocios.globo.com/Empresa/noticia/2018/07/transformacao-digital-leva-itau-mudar-avaliacao-de-desempenho.html
A tecnologia estudava aquilo, fazia um road map e dois anos depois tínhamos a solução
implantada”,
O problema é que 50% de todos os projetos produzidos acabavam descartados.
Quando ficavam prontos, já não faziam sentido.
Não dá pra falar que você vai fazer uma
transformação digital sem mudar o jeito como faz as coisas,
70% da avaliação agora é feita com base em indicadores coletivos
O foco é muito mais na colaboração e menos na competição
Lineu Andrade
Diretor Itau Unibanco
“
Resistência
Opções
é um framework para
desenvolver
e manter produtos
complexos
Por quê SCRUM?
• Devido as constantes mudanças nos requisitos do projeto, o
modelo tradicional (cascata) não tende a ter o mesmo sucesso
que um modelo iterativo;
• Quando é indicado o Scrum:
• Mudanças constantes;
• Aprendizado durante o desenvolvimento;
• Complexidade e incerteza reduzem a visibilidade;
• Colaboração é importante;
Pilares
SCRUM
Pilares
Diferença entre comprometimento e
envolvimento
Como funciona?
Framework
Product Backlog
• Lista ordenada de tudo que é necessário
para criação do produto
• Única fonte dos requisitos
• É dinâmico; mudando para ser mais apropriado,
competitivo e útil.
• Normalmente escritos no formato de Histórias de
Usuário
Product Owner (Dono do Produto, ou PO)
• Representa a voz do cliente e dos envolvidos ao time
• Gerenciar o Product Backlog
• Expressar claramente os itens do Backlog do Produto;
• Ordenar os itens do Backlog do Produto para alcançar melhor as
metas e missões;
• Garantir o valor do trabalho realizado pelo Time de
Desenvolvimento;
• Garantir que o Backlog do Produto seja visível, transparente, claro
para todos, e mostrar o que o Time Scrum vai trabalhar a seguir;
e,
• Garantir que a Equipe de Desenvolvimento entenda os itens do
Backlog do Produto no nível necessário.
Time de Desenvolvimento (Dev Team)
• São auto-organizáveis
• escolhem qual a melhor forma para completarem seu trabalho, em vez
de serem dirigidos por outros de fora da equipe.
• São multifuncionais
• possuem todas as competências necessárias para completar o trabalho
sem depender de outros que não fazem parte da equipe.
• O modelo de equipe no Scrum é projetado para aperfeiçoar a
flexibilidade, criatividade e produtividade.
Time de Desenvolvimento
• Um grupo de pessoas com cargos diferentes que vai trabalhar
junto para cumprir as metas estabelecidas.
• É a galera que vai por a mão na massa e entregar um produto
“pronto” ao final do ciclo de desenvolvimento.
• Desenvolvedor, Analista de Sistema, ... Não importa o seu cargo
todos tem o mesmo título: desenvolvedor.
Time de Desenvolvimento
Indivíduos e interações mais que processos e ferramentas
• Tamanho: 3-9 membros
• São Especialistas/Generalistas (T-Shaped, Por exemplo, Programar e Testar)
• Comprometimento
• Membros dedicados a equipe
Dedicado?
...”A multitarefa reduz a produtividade do trabalho da equipe e
afeta a capacidade da equipe de prever a entrega de forma
consistente”...
...”porque os membros da equipe perdem tempo mudando de
contexto e/ou esperando uns aos outros para a conclusão de
outros trabalhos”...
Scrum Master
• Facilitador
• Conhecedor do Scrum
• Coach e Agente de mudança, capaz de disseminar o mindset
ágil
• Protege a equipe de interferências externas
• Remove impedimentos, garantindo o fluxo e andamento da
sprint
• Garantir o SCRUM
• Convidar pessoas apropriadas para as reuniões de
acompanhamento
Scrum Master
• Não é:
• Chefe
• Secretário
• Super-herói
http://www.barryovereem.com/stances-of-a-scrum-master-high-quality/
Liderança Servidora
• Servir o time
• Ajudar o crescimento das pessoas
• Disseminar o ágil
• Facilitar a comunicação
• Identificar e remover gargalos e
impedimentos
• Educar as partes interessadas sobre o por
que e como ser ágil.
Gerente de Projeto
O valor dos gerentes de projeto não está na sua posição, mas na
capacidade que têm de melhorar as outras pessoas.
Gerente de Projeto
Equipes Multifuncionais e Auto-Organizadas
“projetos commuitas mudanças, há mais complexidade do que uma pessoa pode
gerenciar.
Em vezdisso,
as equipes multifuncionais coordenam seu próprio trabalho e colaboram com o
representante de negócios”...
Gerente de Projeto
...“Aotrabalhar em um projeto ágil, os gerentes de projeto deixam uma posição central para servir a equipe e a
gerência”...
• são líderes servidores
• coaching de pessoas
• promovem maior colaboração na equipe
• alinham as necessidades das partes interessadas.
• incentivam a distribuição de responsabilidades
Eventos
• Quem nunca perdeu tempo em uma reunião longa e sem
propósito?
• As vezes conversar demais (e fazer de menos) pode ser
prejudicial para qualquer empresa.
• Pensando nisso todos os eventos Scrum são time-boxed, ou
seja, tem uma duração fixa de tempo.
• Desta forma a comunicação é sempre mais clara, objetiva e ágil.
Sprint
• O coração do Scrum é a Sprint
• É um time-box de um mês ou
menos, onde se obtêm uma
versão incremental
potencialmente utilizável do
produto
• Cadência
Sprint
• Durante a Sprint:
• Não são feitas mudanças que podem afetar o objetivo
da Sprint;
• A composição da Equipe de Desenvolvimento
permanecem constantes;
• As metas de qualidade não diminuem; e,
• O escopo pode ser clarificado e renegociado entre o
Product Owner e a Equipe de Desenvolvimento quanto
mais for aprendido
Reunião de Planejamento
Sprint Backlog
Product Backlog
Velocidade do Time
Último incremento
Capacidade projetada
4hs para Sprint de 2 semanas
Objetivo da Sprint
Reunião de Planejamento
• Planejamento das atividades da Sprint que se
inicia;
• Avaliar capacidade considerando feriados,
folgas, férias, ...
• Quem deve estar:
• Todo Time Scrum
• AN (se necessário para esclarecimento de
determinado assunto)
• Defina um objetivo da Sprint
Reunião de Planejamento
• 4 horas para uma Sprint de 2 semanas
• Em cada metade da reunião duas perguntas
devem ser respondidas:
• O que será entregue como resultado?
• Seleção da histórias
• Como o trabalho necessário para entregar o produto
será realizado?
• Quebra em tarefas
• A quantidade de histórias que podem ser
realizadas na Sprint é definida pelo Dev.Team.
Estimativas
• A Equipe de Desenvolvimento é responsável por todas as
estimativas dos itens do Backlog
• O Product Owner deve influenciar o Time, ajudando no
entendimento e nas decisões conflituosas de troca, mas as
pessoas que irão realizar o trabalham fazem a estimativa final.
Sprint Backlog
• é um conjunto de itens do Backlog do
Produto selecionados para a Sprint Sprint
Backlog
Reunião Diária
• A idéia da reunião diária, ou stand-up meeting, é juntar a
equipe para um bate-papo de 15 minutos no máximo para
revisar o andamento do projeto.
• Objetivo é estabelecer o comprometimento, descobrir
problemas e garantir que o Scrum funcione;
• Não é uma reunião de status;
Reunião Diária
• Quem deve estar:
• Time de Desenvolvimento
• Scrum Master
• Cada membro da equipe deve responder as
seguintes perguntas:
• O que eu consegui completar ontem?
• O que farei hoje?
• Quais obstáculos estão impedindo o meu
progresso?
Reunião Diária
• Não é hora de discussões; apenas de apontar
necessidades de conversas, impedimentos;
Reuniões podem ser marcadas para discutir
os temas posteriamente;
• Questão extra:
• Alguém está trabalhando em algo que não esteja
no quadro?
Revisão da Sprint
• Revisar todos os itens desenvolvidos e demonstrar as partes que
foram entregues com o objetivo de coletar feedbacks;
• O PO pode aceitar ou rejeitar histórias;
• A duração desta reunião considerando um sprint de um mês é 4
horas.
• Quem?
• Time Scrum
• Interessados: Suporte, PMO, ...
Retrospectiva da Sprint
• A sprint acabou!
• Kaizen – Melhoria contínua
• Agora é hora de olhar para trás e repensar o que deu certo, o
que deu errado e planejar o que pode ser melhorado no futuro.
Como funciona?
Burndown Chart
• É um gráfico que tem a função de monitorar o desenvolvimento
da equipe.
• Funciona da seguinte maneira:
• todos os dias você anota quantas tarefas do seu Sprint Backlog foram
efetivamente cumpridas.
• Desta maneira você pode saber com antecedência a velocidade que
sua equipe trabalha.
Burndown Chart
Grooming session
• Preparação das histórias da próxima iteração;
• + - 1 hora por iteração
• O PO apresenta as ideias
• O Trio (Dev + Tester + AN) discutem e
detalham os cenários de aceitação;
• Refinam e quebram as histórias quando
necessário;
Aumentando a Qualidade
do que entra e do que saí....
Definition of Ready (DoR)
• Define uma lista de critérios que as histórias precisam
atender para fazerem parte do Sprint Backlog
• Exemplos:
• Aprovada pelo Gestor da Área
• Deve ser escrita em formato de história de usuário
• Foi estimada? O tamanho é menor que X?
• Deve conter cenários de aceitação
• A responsabilidade de atender as definições é do PO
• Não pode ser rígida a ponto de tornar o processo
Cascata
SECURITY
https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready
Definition of Done (DoD)
• Define uma lista de critérios que as histórias precisam atender
para serem consideradas entregues
• Exemplos:
• Código foi revisado
• Passar pela pipeline de integração continua
• Passado pelo SonarQube
• Conter testes automatizados
• A responsabilidade de atender as definições é do Dev Team.
Estimativas e Métricas
• As estimativas são feitas durante o Grooming/Planning, ou seja, só
são estimados as histórias que estão próximas de irem para o Sprint
Backlog;
• Medições empíricas e baseadas no valor;
• É medido o que se entrega e não o que se prevê que irá entregar;
• Algumas técnicas:
• Planning Poker
• 3 Pontos
• Ideal day
• P M G
Estimativas e Métricas
• ...”Os patrocinadores geralmente querem saber quando o
projeto estará pronto. Uma vez que a equipe estabelece uma
velocidade confiável (histórias médias ou pontos de história por
iteração) ou o tempo médio do ciclo, pode prever quanto
tempo o projeto levará.”... (p.55)
• Acompanhamento com o Burndown/Burnup Chart
• Velocidade do Time
https://targetteal.com/pt/blog/metodo-kanban/
Kanban
• Sistema Toyota de Produção (TPS) na década de 60
• kanban significa Cartão/Sinalização
• Kanban é o método
• David J. Anderson trouxe para o mundo de Software
Pare de começar,
e comece a terminar!
Foco na entrega contínua.
As equipes estão focadas no fluxo de trabalho até a conclusão e não iniciam
novos trabalhos até que o trabalho em andamento esteja concluído.
é mais importante completar o trabalho do que começar um novo trabalho
Princípios
• Comece com o que você tem hoje
• Mapeie seu processo
• Busque mudanças incrementais e evolucionárias
• Faça hipóteses e faça pequenas mudanças
• Respeite o processo atual, papéis, responsabilidades e títulos
Práticas
Visualizar o Fluxo de Trabalho
• Da esquerda para
Direita
• Cada etapa
acrescenta valor ao
item
Limitar o trabalho em progresso (WIP)
Entendendo o WIP...
Backlog Usando Ag. Lavar Lavando Ag. Guardar Guardado
Backlog Usando
WIP [2]
Ag. Lavar
WIP [2]
Lavando
WIP [1]
Ag. Guardar
WIP [2]
Guardado
Medir e gerenciar o fluxo
Torne as políticas de processo explícitas
• Se usar cores para diferenciar, deixe explicito o que cada cor
representa
• Explicite os WIPs
• Regras de priorização
Implemente ciclos de feedback e
• Certifique-se que está entregando o produto certo;
• Procure a melhoria contínua do processo (KAIZEN)
Melhore colaborativamente
Squads
• 3-10 pessoas
• P.O. dedicado
• Estão próximos;
• Tem uma missão a longo prazo.
• Autônomos
• Auto organizados
• Responsáveis por realizar tudo que é necessário para entrega
do produto; tendo as qualificações e ferramentas necessárias
para desenvolver, testar, colocar em produção...
Tribes
• Um conjunto de Squads da mesma área de
negócio;
• Geralmente compostos por umas 100 pessoas;
• Estão em uma mesma área física;
• Há espaço físico para colaboração e troca de
informações;
• Há um “Chefe da Tribo”
Chapter
• Pessoas da mesma área técnica
• Ideal para pulverizar o conhecimento
através de encontros frequentes
• Divisão horizontal
• Exemplo Divisão de Devs,
• Reunião para apresentar/discutir o
release do C# 8, ...
Guild
• Comunidade de interesses
• Pessoas de toda a organização e diferentes habilidades técnicas;
http://www.full-stackagile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
Sendo ágil...
Como ser ágil?
Contamos com vocês!
Bora ser
ágil?
Obrigado!
Entregando Software
com “Valor”
Maicon Carlos Pereira

Mais conteúdo relacionado

Mais procurados

Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Clavius Tales
 
Gestão Ágil e Lean - Circuito de treinamentos AddTech
Gestão Ágil e Lean - Circuito de treinamentos AddTechGestão Ágil e Lean - Circuito de treinamentos AddTech
Gestão Ágil e Lean - Circuito de treinamentos AddTech.add
 
Gestao agil de projetos com Scrum
Gestao agil de projetos com ScrumGestao agil de projetos com Scrum
Gestao agil de projetos com ScrumIgor Macaubas
 
Conceitos e Certificações de Gerenciamento Ágil de Projetos
Conceitos e Certificações de Gerenciamento Ágil de ProjetosConceitos e Certificações de Gerenciamento Ágil de Projetos
Conceitos e Certificações de Gerenciamento Ágil de ProjetosVitor Massari
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilIsrael Santiago
 
Mudanças de Consumo nos Novos Tempos - Tendências para os próximos anos sob a...
Mudanças de Consumo nos Novos Tempos - Tendências para os próximos anos sob a...Mudanças de Consumo nos Novos Tempos - Tendências para os próximos anos sob a...
Mudanças de Consumo nos Novos Tempos - Tendências para os próximos anos sob a...Allan Cardozo
 
Aplicando Scrum na prática para times ágeis
Aplicando Scrum na prática para times ágeisAplicando Scrum na prática para times ágeis
Aplicando Scrum na prática para times ágeisfayrusm
 
Apostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumApostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumMindMasterBrasil
 
Gerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempre
Gerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempreGerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempre
Gerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempreLeandro Faria
 
Metodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de ProjetosMetodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de ProjetosLeandro Faria
 
O que é e como obter a certificação PMI-ACP
O que é e como obter a certificação PMI-ACPO que é e como obter a certificação PMI-ACP
O que é e como obter a certificação PMI-ACPLeandro Faria
 

Mais procurados (20)

Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009
 
Gestão Ágil e Lean - Circuito de treinamentos AddTech
Gestão Ágil e Lean - Circuito de treinamentos AddTechGestão Ágil e Lean - Circuito de treinamentos AddTech
Gestão Ágil e Lean - Circuito de treinamentos AddTech
 
Requisitos ageis para times sem tempo
Requisitos ageis para times sem tempoRequisitos ageis para times sem tempo
Requisitos ageis para times sem tempo
 
Gestao agil de projetos com Scrum
Gestao agil de projetos com ScrumGestao agil de projetos com Scrum
Gestao agil de projetos com Scrum
 
Conceitos e Certificações de Gerenciamento Ágil de Projetos
Conceitos e Certificações de Gerenciamento Ágil de ProjetosConceitos e Certificações de Gerenciamento Ágil de Projetos
Conceitos e Certificações de Gerenciamento Ágil de Projetos
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento Ágil
 
Teste Ágeis para todo o time
Teste Ágeis para todo o timeTeste Ágeis para todo o time
Teste Ágeis para todo o time
 
Mudanças de Consumo nos Novos Tempos - Tendências para os próximos anos sob a...
Mudanças de Consumo nos Novos Tempos - Tendências para os próximos anos sob a...Mudanças de Consumo nos Novos Tempos - Tendências para os próximos anos sob a...
Mudanças de Consumo nos Novos Tempos - Tendências para os próximos anos sob a...
 
Aplicando Scrum na prática para times ágeis
Aplicando Scrum na prática para times ágeisAplicando Scrum na prática para times ágeis
Aplicando Scrum na prática para times ágeis
 
LEAN x Ágil
LEAN x ÁgilLEAN x Ágil
LEAN x Ágil
 
Apostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumApostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do Scrum
 
Agile Management
Agile ManagementAgile Management
Agile Management
 
Lean software
Lean software Lean software
Lean software
 
Desmistificando Agile & Scrum
Desmistificando Agile & ScrumDesmistificando Agile & Scrum
Desmistificando Agile & Scrum
 
Gerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempre
Gerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempreGerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempre
Gerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempre
 
Metodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de ProjetosMetodologias Ágeis de Gestão de Projetos
Metodologias Ágeis de Gestão de Projetos
 
Scrum na Prática
Scrum na PráticaScrum na Prática
Scrum na Prática
 
Metodos Ageis
Metodos AgeisMetodos Ageis
Metodos Ageis
 
O que é e como obter a certificação PMI-ACP
O que é e como obter a certificação PMI-ACPO que é e como obter a certificação PMI-ACP
O que é e como obter a certificação PMI-ACP
 
Gestao Ágil de Projeto - Reunião Diária
Gestao Ágil de Projeto - Reunião DiáriaGestao Ágil de Projeto - Reunião Diária
Gestao Ágil de Projeto - Reunião Diária
 

Semelhante a Entregando valor com agilidade

Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do ConhecimentoMétodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do ConhecimentoClaudia Hofart Guzzo
 
People Centric IT
People Centric ITPeople Centric IT
People Centric ITAldo Pires
 
O papel do an na agilidade
O papel do an na agilidadeO papel do an na agilidade
O papel do an na agilidadeCamila Capellão
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos ÁgeisAldo Pires
 
Scrum - Introdução Interna para o Núcleo de Arquitetura de Informação
Scrum - Introdução Interna para o Núcleo de Arquitetura de InformaçãoScrum - Introdução Interna para o Núcleo de Arquitetura de Informação
Scrum - Introdução Interna para o Núcleo de Arquitetura de InformaçãoAlessandro Novais
 
Leadership Mindset Anti Patterns - Scrum Gathering Rio 2018
Leadership Mindset Anti Patterns - Scrum Gathering Rio 2018Leadership Mindset Anti Patterns - Scrum Gathering Rio 2018
Leadership Mindset Anti Patterns - Scrum Gathering Rio 2018Raphael Molesim
 
Leadership Mindset Anti Patterns - Agile Brazil 2018
Leadership Mindset Anti Patterns - Agile Brazil 2018Leadership Mindset Anti Patterns - Agile Brazil 2018
Leadership Mindset Anti Patterns - Agile Brazil 2018Raphael Molesim
 
Lean Thinking e Agile para desenvolvimento de software
Lean Thinking e Agile para desenvolvimento de softwareLean Thinking e Agile para desenvolvimento de software
Lean Thinking e Agile para desenvolvimento de softwareTiago França
 
Mini curso testes ágeis
Mini curso testes ágeisMini curso testes ágeis
Mini curso testes ágeisQualister
 
Metodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de softwareMetodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de softwareUniversidade Tiradentes
 
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4André Vidal
 
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Agile Think® Share
 
Agilidade em startups, Aplicação de práticas ágeis para a criação de MVPs par...
Agilidade em startups, Aplicação de práticas ágeis para a criação de MVPs par...Agilidade em startups, Aplicação de práticas ágeis para a criação de MVPs par...
Agilidade em startups, Aplicação de práticas ágeis para a criação de MVPs par...Leandro Faria
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumMarcos Garrido
 
Technical Product Management at Nubank
Technical Product Management at NubankTechnical Product Management at Nubank
Technical Product Management at Nubankalexandre freire
 
Desenvolvimento ágil pensando além
Desenvolvimento ágil   pensando alémDesenvolvimento ágil   pensando além
Desenvolvimento ágil pensando alémilegra
 

Semelhante a Entregando valor com agilidade (20)

Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do ConhecimentoMétodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
 
People Centric IT
People Centric ITPeople Centric IT
People Centric IT
 
O papel do an na agilidade
O papel do an na agilidadeO papel do an na agilidade
O papel do an na agilidade
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Scrum - Introdução Interna para o Núcleo de Arquitetura de Informação
Scrum - Introdução Interna para o Núcleo de Arquitetura de InformaçãoScrum - Introdução Interna para o Núcleo de Arquitetura de Informação
Scrum - Introdução Interna para o Núcleo de Arquitetura de Informação
 
Leadership Mindset Anti Patterns - Scrum Gathering Rio 2018
Leadership Mindset Anti Patterns - Scrum Gathering Rio 2018Leadership Mindset Anti Patterns - Scrum Gathering Rio 2018
Leadership Mindset Anti Patterns - Scrum Gathering Rio 2018
 
O Mal do Produtismo
O Mal do ProdutismoO Mal do Produtismo
O Mal do Produtismo
 
Leadership Mindset Anti Patterns - Agile Brazil 2018
Leadership Mindset Anti Patterns - Agile Brazil 2018Leadership Mindset Anti Patterns - Agile Brazil 2018
Leadership Mindset Anti Patterns - Agile Brazil 2018
 
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
JORNADA DE TRANSFORMAÇÃO ÁGIL NAS EMPRESAS
 
20 anos Manifesto ágil - o que aprendemos?
20 anos Manifesto ágil - o que aprendemos?20 anos Manifesto ágil - o que aprendemos?
20 anos Manifesto ágil - o que aprendemos?
 
Lean Thinking e Agile para desenvolvimento de software
Lean Thinking e Agile para desenvolvimento de softwareLean Thinking e Agile para desenvolvimento de software
Lean Thinking e Agile para desenvolvimento de software
 
Mini curso testes ágeis
Mini curso testes ágeisMini curso testes ágeis
Mini curso testes ágeis
 
Metodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de softwareMetodologia agil no desenvolvimento criativo de software
Metodologia agil no desenvolvimento criativo de software
 
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
 
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
 
Agilidade em startups, Aplicação de práticas ágeis para a criação de MVPs par...
Agilidade em startups, Aplicação de práticas ágeis para a criação de MVPs par...Agilidade em startups, Aplicação de práticas ágeis para a criação de MVPs par...
Agilidade em startups, Aplicação de práticas ágeis para a criação de MVPs par...
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
 
Technical Product Management at Nubank
Technical Product Management at NubankTechnical Product Management at Nubank
Technical Product Management at Nubank
 
Desenvolvimento ágil pensando além
Desenvolvimento ágil   pensando alémDesenvolvimento ágil   pensando além
Desenvolvimento ágil pensando além
 

Entregando valor com agilidade

  • 2. Maicon Carlos Pereira • Graduado em Ciência da Computação • MBA em Gerenciamento de Projetos • + 12 anos desenvolvendo software
  • 4.
  • 5. Ciclos de Vida de um projeto
  • 6. Cascata Início do Projeto Término do Projeto planejamento acontece no início e a execução ocorrendo em uma única vez, num processo sequencial.
  • 8. Incremental fornece entregáveis finalizados que o cliente poderá usar imediatamente Início do Projeto Término do Projeto
  • 9. Iterativo permite o feedback sobre trabalho inacabado através de protótipos para melhorar o produto final Início do Projeto Término do Projeto
  • 10. Ágil – Iterativo e Incremental Feedback e entregas frequentes. Início do Projeto Término do Projeto
  • 13. Em produção de produto, carro, eletrodoméstico... Onde os procedimentos Claros. Um projeto passado é de fácil reprodução e sucesso Funciona?
  • 14. Resumindo, Cascata no desenvolvimento de software, Funciona?
  • 15. Por que não funciona? • Desenvolver software é um processo criativo • É um processo artesanal • É um processo empírico (o conhecimento vem da experiência) • Exige pesquisa • ...
  • 16. E como se faz??
  • 18. Manifesto Ágil  Desenvolvedores e consultores de software se juntaram para compartilhar valores e princípios que eram utilizados em suas práticas  Agile Software Development Alliance Ward Cunningham 2001 Robert C. Martin ...
  • 19.
  • 20. Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações 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 http://www.manifestoagil.com.br/
  • 21. Princípios Ágeis 1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. 2. 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. 3. Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
  • 22. Princípios Ágeis 4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto. 5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. 6. 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.
  • 23. Princípios Ágeis 7. Software funcional é a medida primária de progresso. 8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. 9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
  • 24. Princípios Ágeis 10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. 11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. 12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
  • 25. Espere ai... Vamos calma...
  • 26. Ser Ágil não é ser Rápido ou Veloz
  • 27. Ser ágil é: É entregar valor com frequência, gerando feedback e adaptando-se (rapidamente) às mudanças.
  • 28. Entrega de valor com frequência...?
  • 29. Não é o mais forte que sobrevive, nem o mais inteligente, mas o que melhor se adapta às mudanças Charles Darwin Adaptando-se às mudanças... “
  • 32.
  • 33. Ágil não é uma bala de prata. Não é a solução de todos os problemas.
  • 34. Quando ser ágil? • Exigem pesquisa e desenvolvimento; • Têm altas taxas de mudança; • Têm requisitos, incerteza ou risco pouco claros ou desconhecidos; ou • Têm um objetivo final difícil de descrever Agile Practice Guide
  • 36. E ágil combina com T.I.? Ou apenas empresas de Software?
  • 37. TI vs Core Business da Empresa
  • 38. https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/ TI Bimodal = Maratonista + Velocista Diferentes, mas essenciais https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/ https://www.gartner.com/it-glossary/bimodal/
  • 39. https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/ Modo 1 – Maratonista Modo 2 – Corredor/Velocista Confiabilidade Objetivo Agilidade Desempenho Valor Retorno, marca, valor ao cliente, UX Cascata, ITIL, Cobit, ISO, ... Abordagem Ágil, Kanban, Lean IT, DevOps, ... Dirigida por planos e níveis de aprovação Governança Empírica, contínua, baseada em processos Fornecedores corporativos e relações a longo prazo Parceiros Fornecedores novos, pequenos e curto prazo Bom em processos convencionais e em projetos Talento Bom em projetos novos e incertos Centralizada em TI Cultura Centralizada no negócio e próxima aos usuários Longo (meses) Ciclo Curto (dias, semanas) TI Bimodal = Maratonista + Velocista Diferentes, mas essenciais https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/ https://www.gartner.com/it-glossary/bimodal/
  • 40. TI Bimodal é o caminho para a transformação digital...” As empresas precisam desenvolver ações inovadoras e disruptivas ao mesmo tempo em que continuam a fazer negócios como sempre https://www.gartner.com/it-glossary/bimodal/ “
  • 41. http://cio.com.br/opiniao/2016/09/27/bimodal-ja-era/ “O modelo de TI bimodal reforça a mensagem que os clientes corporativos querem ouvir, que as disrupções podem ser controladas e adotadas gradualmente. Mas acaba gerando procrastinação e atrasando a velocidade da empresa em fazer sua transformação de negócios. Cezar Taurion Head & Partner Digital Transformation at KICK “
  • 42. “Estamos desconstruindo a nossa TI Bimodal. Eu mesmo a implementei. Ela foi importante e hoje já não basta. Não existe transformação digital sem velocidade, sem mudar a cultura do meu time e da própria empresa. É uma nova TI, pronta para o futuro” Cristiano Barbieri, CIO da SulAmerica https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/ “
  • 43. ... na nossa visão, foi vital usar a metodologia ágil, com ciclos curtos, entregas rápidas. Isso exigiu uma reestruturação do time. É fundamental somar competências, muito treinamento, alinhamento e capacitação. Cristiano Barbieri, CIO da SulAmerica https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/ “
  • 44. https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/ “A TI Bimodal hoje não faz parte do novo cenário composto por exemplo pela metodologia Ágil, que tem novos propósitos. Estamos na migração do 100% Ágil” Viviane Lusvarghi CIO da Santher “
  • 45. https://epocanegocios.globo.com/Empresa/noticia/2018/07/transformacao-digital-leva-itau-mudar-avaliacao-de-desempenho.html A tecnologia estudava aquilo, fazia um road map e dois anos depois tínhamos a solução implantada”, O problema é que 50% de todos os projetos produzidos acabavam descartados. Quando ficavam prontos, já não faziam sentido. Não dá pra falar que você vai fazer uma transformação digital sem mudar o jeito como faz as coisas, 70% da avaliação agora é feita com base em indicadores coletivos O foco é muito mais na colaboração e menos na competição Lineu Andrade Diretor Itau Unibanco “
  • 46.
  • 49.
  • 50. é um framework para desenvolver e manter produtos complexos
  • 51. Por quê SCRUM? • Devido as constantes mudanças nos requisitos do projeto, o modelo tradicional (cascata) não tende a ter o mesmo sucesso que um modelo iterativo; • Quando é indicado o Scrum: • Mudanças constantes; • Aprendizado durante o desenvolvimento; • Complexidade e incerteza reduzem a visibilidade; • Colaboração é importante;
  • 54.
  • 58.
  • 59. Product Backlog • Lista ordenada de tudo que é necessário para criação do produto • Única fonte dos requisitos • É dinâmico; mudando para ser mais apropriado, competitivo e útil. • Normalmente escritos no formato de Histórias de Usuário
  • 60.
  • 61. Product Owner (Dono do Produto, ou PO) • Representa a voz do cliente e dos envolvidos ao time • Gerenciar o Product Backlog • Expressar claramente os itens do Backlog do Produto; • Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões; • Garantir o valor do trabalho realizado pelo Time de Desenvolvimento; • Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, • Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.
  • 62.
  • 63. Time de Desenvolvimento (Dev Team) • São auto-organizáveis • escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora da equipe. • São multifuncionais • possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. • O modelo de equipe no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade.
  • 64. Time de Desenvolvimento • Um grupo de pessoas com cargos diferentes que vai trabalhar junto para cumprir as metas estabelecidas. • É a galera que vai por a mão na massa e entregar um produto “pronto” ao final do ciclo de desenvolvimento. • Desenvolvedor, Analista de Sistema, ... Não importa o seu cargo todos tem o mesmo título: desenvolvedor.
  • 65. Time de Desenvolvimento Indivíduos e interações mais que processos e ferramentas • Tamanho: 3-9 membros • São Especialistas/Generalistas (T-Shaped, Por exemplo, Programar e Testar) • Comprometimento • Membros dedicados a equipe
  • 66. Dedicado? ...”A multitarefa reduz a produtividade do trabalho da equipe e afeta a capacidade da equipe de prever a entrega de forma consistente”... ...”porque os membros da equipe perdem tempo mudando de contexto e/ou esperando uns aos outros para a conclusão de outros trabalhos”...
  • 67.
  • 68. Scrum Master • Facilitador • Conhecedor do Scrum • Coach e Agente de mudança, capaz de disseminar o mindset ágil • Protege a equipe de interferências externas • Remove impedimentos, garantindo o fluxo e andamento da sprint • Garantir o SCRUM • Convidar pessoas apropriadas para as reuniões de acompanhamento
  • 69. Scrum Master • Não é: • Chefe • Secretário • Super-herói http://www.barryovereem.com/stances-of-a-scrum-master-high-quality/
  • 70. Liderança Servidora • Servir o time • Ajudar o crescimento das pessoas • Disseminar o ágil • Facilitar a comunicação • Identificar e remover gargalos e impedimentos • Educar as partes interessadas sobre o por que e como ser ágil.
  • 71. Gerente de Projeto O valor dos gerentes de projeto não está na sua posição, mas na capacidade que têm de melhorar as outras pessoas.
  • 72. Gerente de Projeto Equipes Multifuncionais e Auto-Organizadas “projetos commuitas mudanças, há mais complexidade do que uma pessoa pode gerenciar. Em vezdisso, as equipes multifuncionais coordenam seu próprio trabalho e colaboram com o representante de negócios”...
  • 73. Gerente de Projeto ...“Aotrabalhar em um projeto ágil, os gerentes de projeto deixam uma posição central para servir a equipe e a gerência”... • são líderes servidores • coaching de pessoas • promovem maior colaboração na equipe • alinham as necessidades das partes interessadas. • incentivam a distribuição de responsabilidades
  • 74. Eventos • Quem nunca perdeu tempo em uma reunião longa e sem propósito? • As vezes conversar demais (e fazer de menos) pode ser prejudicial para qualquer empresa. • Pensando nisso todos os eventos Scrum são time-boxed, ou seja, tem uma duração fixa de tempo. • Desta forma a comunicação é sempre mais clara, objetiva e ágil.
  • 75.
  • 76. Sprint • O coração do Scrum é a Sprint • É um time-box de um mês ou menos, onde se obtêm uma versão incremental potencialmente utilizável do produto • Cadência
  • 77. Sprint • Durante a Sprint: • Não são feitas mudanças que podem afetar o objetivo da Sprint; • A composição da Equipe de Desenvolvimento permanecem constantes; • As metas de qualidade não diminuem; e, • O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido
  • 78.
  • 79. Reunião de Planejamento Sprint Backlog Product Backlog Velocidade do Time Último incremento Capacidade projetada 4hs para Sprint de 2 semanas Objetivo da Sprint
  • 80. Reunião de Planejamento • Planejamento das atividades da Sprint que se inicia; • Avaliar capacidade considerando feriados, folgas, férias, ... • Quem deve estar: • Todo Time Scrum • AN (se necessário para esclarecimento de determinado assunto) • Defina um objetivo da Sprint
  • 81. Reunião de Planejamento • 4 horas para uma Sprint de 2 semanas • Em cada metade da reunião duas perguntas devem ser respondidas: • O que será entregue como resultado? • Seleção da histórias • Como o trabalho necessário para entregar o produto será realizado? • Quebra em tarefas • A quantidade de histórias que podem ser realizadas na Sprint é definida pelo Dev.Team.
  • 82. Estimativas • A Equipe de Desenvolvimento é responsável por todas as estimativas dos itens do Backlog • O Product Owner deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalham fazem a estimativa final.
  • 83.
  • 84. Sprint Backlog • é um conjunto de itens do Backlog do Produto selecionados para a Sprint Sprint Backlog
  • 85.
  • 86. Reunião Diária • A idéia da reunião diária, ou stand-up meeting, é juntar a equipe para um bate-papo de 15 minutos no máximo para revisar o andamento do projeto. • Objetivo é estabelecer o comprometimento, descobrir problemas e garantir que o Scrum funcione; • Não é uma reunião de status;
  • 87. Reunião Diária • Quem deve estar: • Time de Desenvolvimento • Scrum Master • Cada membro da equipe deve responder as seguintes perguntas: • O que eu consegui completar ontem? • O que farei hoje? • Quais obstáculos estão impedindo o meu progresso?
  • 88. Reunião Diária • Não é hora de discussões; apenas de apontar necessidades de conversas, impedimentos; Reuniões podem ser marcadas para discutir os temas posteriamente; • Questão extra: • Alguém está trabalhando em algo que não esteja no quadro?
  • 89.
  • 90. Revisão da Sprint • Revisar todos os itens desenvolvidos e demonstrar as partes que foram entregues com o objetivo de coletar feedbacks; • O PO pode aceitar ou rejeitar histórias; • A duração desta reunião considerando um sprint de um mês é 4 horas. • Quem? • Time Scrum • Interessados: Suporte, PMO, ...
  • 91. Retrospectiva da Sprint • A sprint acabou! • Kaizen – Melhoria contínua • Agora é hora de olhar para trás e repensar o que deu certo, o que deu errado e planejar o que pode ser melhorado no futuro.
  • 92.
  • 94.
  • 95.
  • 96. Burndown Chart • É um gráfico que tem a função de monitorar o desenvolvimento da equipe. • Funciona da seguinte maneira: • todos os dias você anota quantas tarefas do seu Sprint Backlog foram efetivamente cumpridas. • Desta maneira você pode saber com antecedência a velocidade que sua equipe trabalha.
  • 98. Grooming session • Preparação das histórias da próxima iteração; • + - 1 hora por iteração • O PO apresenta as ideias • O Trio (Dev + Tester + AN) discutem e detalham os cenários de aceitação; • Refinam e quebram as histórias quando necessário;
  • 99. Aumentando a Qualidade do que entra e do que saí....
  • 100. Definition of Ready (DoR) • Define uma lista de critérios que as histórias precisam atender para fazerem parte do Sprint Backlog • Exemplos: • Aprovada pelo Gestor da Área • Deve ser escrita em formato de história de usuário • Foi estimada? O tamanho é menor que X? • Deve conter cenários de aceitação • A responsabilidade de atender as definições é do PO • Não pode ser rígida a ponto de tornar o processo Cascata SECURITY https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready
  • 101. Definition of Done (DoD) • Define uma lista de critérios que as histórias precisam atender para serem consideradas entregues • Exemplos: • Código foi revisado • Passar pela pipeline de integração continua • Passado pelo SonarQube • Conter testes automatizados • A responsabilidade de atender as definições é do Dev Team.
  • 102. Estimativas e Métricas • As estimativas são feitas durante o Grooming/Planning, ou seja, só são estimados as histórias que estão próximas de irem para o Sprint Backlog; • Medições empíricas e baseadas no valor; • É medido o que se entrega e não o que se prevê que irá entregar; • Algumas técnicas: • Planning Poker • 3 Pontos • Ideal day • P M G
  • 103. Estimativas e Métricas • ...”Os patrocinadores geralmente querem saber quando o projeto estará pronto. Uma vez que a equipe estabelece uma velocidade confiável (histórias médias ou pontos de história por iteração) ou o tempo médio do ciclo, pode prever quanto tempo o projeto levará.”... (p.55) • Acompanhamento com o Burndown/Burnup Chart • Velocidade do Time
  • 105. Kanban • Sistema Toyota de Produção (TPS) na década de 60 • kanban significa Cartão/Sinalização • Kanban é o método • David J. Anderson trouxe para o mundo de Software
  • 106. Pare de começar, e comece a terminar! Foco na entrega contínua. As equipes estão focadas no fluxo de trabalho até a conclusão e não iniciam novos trabalhos até que o trabalho em andamento esteja concluído. é mais importante completar o trabalho do que começar um novo trabalho
  • 107.
  • 108. Princípios • Comece com o que você tem hoje • Mapeie seu processo • Busque mudanças incrementais e evolucionárias • Faça hipóteses e faça pequenas mudanças • Respeite o processo atual, papéis, responsabilidades e títulos
  • 110. Visualizar o Fluxo de Trabalho • Da esquerda para Direita • Cada etapa acrescenta valor ao item
  • 111. Limitar o trabalho em progresso (WIP)
  • 113. Backlog Usando Ag. Lavar Lavando Ag. Guardar Guardado
  • 114. Backlog Usando WIP [2] Ag. Lavar WIP [2] Lavando WIP [1] Ag. Guardar WIP [2] Guardado
  • 115. Medir e gerenciar o fluxo
  • 116. Torne as políticas de processo explícitas • Se usar cores para diferenciar, deixe explicito o que cada cor representa • Explicite os WIPs • Regras de priorização
  • 117. Implemente ciclos de feedback e • Certifique-se que está entregando o produto certo; • Procure a melhoria contínua do processo (KAIZEN) Melhore colaborativamente
  • 118.
  • 119.
  • 120. Squads • 3-10 pessoas • P.O. dedicado • Estão próximos; • Tem uma missão a longo prazo. • Autônomos • Auto organizados • Responsáveis por realizar tudo que é necessário para entrega do produto; tendo as qualificações e ferramentas necessárias para desenvolver, testar, colocar em produção...
  • 121. Tribes • Um conjunto de Squads da mesma área de negócio; • Geralmente compostos por umas 100 pessoas; • Estão em uma mesma área física; • Há espaço físico para colaboração e troca de informações; • Há um “Chefe da Tribo”
  • 122. Chapter • Pessoas da mesma área técnica • Ideal para pulverizar o conhecimento através de encontros frequentes • Divisão horizontal • Exemplo Divisão de Devs, • Reunião para apresentar/discutir o release do C# 8, ...
  • 123. Guild • Comunidade de interesses • Pessoas de toda a organização e diferentes habilidades técnicas; http://www.full-stackagile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/ https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
  • 126.
  • 127.
  • 128.
  • 129.

Notas do Editor

  1. Em fevereiro de 2001, insatisfeitos com as técnicas e métodos de desenvolvimento de sistemas usados até o momento, um grupo de ... criaram a ... , mais conhecida como Agile Alliance, com o propósito de desenvolvimento mais flexível a mudanças e menos custoso em relação aos métodos tradicionais que despendem muito tempo em análise e planejamento.
  2. Lean Startup