Gestão Ágil de Projetos

Gestão Ágil de Projetos

SCRUM

Quem é você?

powered by

SCRUM

Veja Ouça Fale

Pontualidade e Presença

Roteiro

• Discussão inicial• Metodologias e processos ágeis• SCRUM• SCRUM + MPS.Br• Discussão final

“A maioria das nossas suposições sobre negócios, tecnologia e organizações têm pelo menos 50 anos. Elas tem sobrevivido ao seu tempo. Como resultado, estamos pregando, ensinando, e praticando políticas que estão cada vez mais desalinhadas com a realidade, e são contra produtivas.”

Peter Drucker (1909-2005)

"Melhor é o mancebo pobre e sábio do que o rei velho e insensato, que não se deixa mais admoestar" Ec 4:13

Porque tudo isso

agora?

Estatísticas do CHAOS Report

Exercício

Jogos Estatísticos:

Lotes de Produção x

Produtividade

Metodologias e Processos Ágeis

• XP | Extreme Programming (Kent Beck)• FDD | Feature Driven Development (Jeff DeLuca) • DSDM | Dynamic System Development Method

(Dane Faulkner)• SCRUM (Ken Schwaber) • Adaptive Software Development (Jim Highsmith)• Crystal (Alistair Cockburn)• Lean Software Development (Mary Poppendieck)• …

Manifesto Ágil • 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.

© 2001 Agile Alliance. http://www.agilemanifesto.org

Princípios do Manifesto Ágil (1/3)

• 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.

• 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.

• 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.


Teoria por trás do pensamento ágil

• Theory of Constraints and Lean Thinking• Complex adaptive systems: a ciência da

incerteza• Cognitive science: a natureza humana do

processo de tomada de decisão• Evolutionary psychology & anthropology: as

origens da iteração social e a sua natureza

Porque usar metodologia ágil para projetos de software?

• “É típico adotar a abordagem de modelagem definida quando os mecanismos subjacentes pelos quais um processo opera são razoavelmente bem entendidos. Quando o processo é muito complexo para ser definido, a abordagem empírica é a escolha apropriada.” (Ogunnaike and Ray, Oxford University Press)

•Desenvolvimento de software não é um

processo que gera as mesmas saídas para as mesmas entradas

Fonte: DZone Refcardz

Tempox

ROIx

Qualidade

Fonte: Revista MundoJ, número 42, ano VIII, 2010, p.6 – Rodrigo Yoshima

Eventos sobre Agile

DoD

Agi

le D

evel

opm

ent

AgileNCR 2011

http://www.agilebrazil.com/2011/pt/

http://www.agilevale.com.br/

http://www.agiletour.org/br/AT2010_RioDeJaneiro.html

http://www.clarus.co.nz/index.php/Registrations.html

http://agile2011.agilealliance.org/

http://www.agilidadenapratica.com.br/index.php

PDCA

Plan

DoCheck

Act

SCRUM

SCRUM

Framework !!!Metodologia.

Custo da mudança no Scrum

Development Life Cycle

Cost

of c

hang

e

Scrum é flexível o bastante para acomodar as mudanças de requisitos facilmente, sem causar grandes custos adicionais.

• Scrum permite mudanças a qualquer tempo• Desde que fora do ciclo do release• Scrum espera preparado pelas mudanças

Scrum Development Life Cycle

Cost

of c

hang

e

Waterfall

Fonte: Agile Project Management with Scrum, Aditya Raj

Estatísticas

Fonte: Version One Agile Survey 2009

Fonte: http://www.slideshare.net/acarlos1000/scrum-agile-development-intro-campus-party-2009-presentation

Visão do Produto

Product Backlog

Estimativa

SP1 SP2Sprint Backlog

Desenvolvimento

Testes

Sprint2 a 4 semanas

Reunião Diária

24hs

Review

Produto

Retrospectiva powered by Fábio Menezes (Peggasus)

Sprint

Planejamento Tático é feito a cada Sprint

Em cada Sprint: planejamento, execução, acompanhamento, validação e análise de melhorias

As reuniões diárias servem para o acompanhamento de metas e verificação de impedimentos

Papéis

Fonte: http://www.implementingscrum.com

Product Owner • Cria e compartilha a visão do

projeto• Gerencia o product backlog• Representa stakeholders• Aceita/rejeita resultados• Define/prioriza funcionalidades• Estabelece e mantém o plano de

entregas• Toma decisões pensando no ROI

do projeto

Scrum Master • Trabalha com o product owner

• Remove obstáculos• Evita interferências• Mantém foco na meta da sprint• Garante colaboração e comunicação• Guardião das práticas do scrum• O scrum master também é time• Pode ser:• Part-time ou total• Técnico ou administrativo• Gerente ou coordenador

Time

Time

• Auto-gerenciável– Gerencia o próprio progresso– Mantém o foco no que o PO quer– Garante a qualidade– Desenvolve o processo– Define a distribuição interna das tarefas

• Multifuncional• 5 a 9 pessoas• Fulltime• Estima itens do backlog• Se compromete na entrega de um incremento funcional• Foco na lista priorizada pelo PO e acordada com o time• Define as tarefas que determinam o “COMO”• Desenvolve o produto

O processo não é avaliado enquanto está rodando

Cerimônias

Sprint Planning 1Sprint Planning 2

Review

RetrospectiveEstimativa

Daily Meetings

Estimativa

• Preparação para o Sprint Planning

• Estimar baseado no tamanho, nunca em tempo

• Atualizar Product Backlog com as estimativas

• Importante para o PO criar o release plan

Exercício.

Planning Poker

Sprint Planning 1

• Nível estratégico• PO apresenta o Product Backlog priorizado já

estimado pelo Time• O Time obtém o entendimento das histórias– Discussão sobre os critérios de aceitação

• A equipe aprova as histórias com as quais se comprometerá a concluir

• O Sprint Backlog é criado• Duração média de 3 horas

Sprint Planning 1

Product Backlog Capacidade da equipe

Condições do Negócio

RevisaConsideraOrganiza

Objetivos da Sprint Itens selecionados do backlog

Aceite do time

Sprint Planning 2

• Nível tático• PO não precisa participar• O Time planeja como vai implementar cada

história• As histórias são quebradas em tarefas

foto: http://www.tecmedia.com.br/blog/wp-content/uploads/2008/12/dsc00091.jpg

O que fez ontem?

O que fará hoje?

Tem algum obstáculo?

As respostas são compromissos!

Daily Meeting

Review

• Software funcionando para o PO e interessados

• Os resultados são aceitos ou rejeitados pelo PO

• Toda equipe• Definição de “pronto”• Informal (no slides)

Retrospective

"Loucura é fazer a mesma coisa e esperar um resultado diferente."

Albert Einstein

O que devemos começar a fazer?

O que precisamos parar de fazer?

O que devemos continuar a fazer?

Retrospective

Exercício.

Negociação

Artefatos

Product Backlog Sprint Backlog

Burn-down chart

Burn-up chart

Taskboard

Impediment List

Product Backlog

EmergentePriorizado e estimado

Maior prioridade, mais detalhesQualquer um pode contribuir

Priorização é tarefa do POSempre visível

Alinhado ao plano de negócios: (benefício + penalidade) / tamanho

Sprint Backlog

Produto da SP1Mantido pelo Time

O Time aloca o trabalhoExecutado na ordem definida pelo PO

Não deve mudarTudo deve ser entregue, e sem bugs

Taskboard

Burn-down e Burn-up

Exercício

Scrum of scrums

Scrum+

XP• Padronização de código• Testes automatizados• Controle de versão

• TDD• User stories• Refatoração

• Integração contínua• Codificação em pares• Código compartilhado

Scrum+

Kanbam

O fator H (1/2)• Características de um time ágil:– Orientação ao valor proporcionado ao cliente– Desenvolvimento das competências individuais– Times pequenos– Autodisciplina sustentável– Intensa colaboração– Reduzido custo de transferência da informação– Tempo reduzido para feedback– Aprendizado e adaptação constantes

O fator H (2/2)• Cinco estágios para o desenvolvimento de

times (PMBOK)– Formação– Tempestade– Norma– Desempenho– Nova jornada

Benchmarking

Benchmarking simples (identificação)Benchmarking de líderes (Ex: Toyota e 5

meses de treinamento para todos os novos funcionários)

Benchmarking da concorrência total (extrapole)

POR OUTRO LADO, TODO CONCORRENTE É UM PARCEIRO EM POTENCIAL ... BASTA ENCONTRAR UM INTERESSE EM COMUM...

Fonte: Aísa Pereira - www.engenhariadevendas.com.br

http://www.engenhariadevendas.com.br/

Déficit técnico

Fonte: DZone Refcardz

Erros comums em reuniões diárias

• Reuniões diárias a cada três dias• Reuniões com longa duração (+15 minutos)• Reuniões diárias realizadas fora do ambiente de

trabalho (ex.: sala de reuniões)• Reunião diária como report ao Scrum

Master/Coach/Líder• Reuniões de 2 minutos (curtas demais)• Detalhamento e explicações de soluções na reunião• Horário flutuante• Participação parcial na reunião

Fonte: Dairton Bassi – Agile Brazil 2010

Erros comuns no burn down chart

• Ausência ou abandono• Burn down para o Product Owner• Não ajustar os planos


Erros comuns no papel do cliente/PO

• Sobreposição do papel com o Scrum Master• Cliente com várias vozes• Envolvimento pontual


SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

SCRUM + MPS.Br

Exercício

Projeto do avião

Problemas comuns na adoção de Scrum

Product Owner pouco presente

Sem VisãoSem release plan

Sem product backlog

Product Backlog não é mantido

Falta estimativaFalta priorizaçãoFalta acompanhamento

Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation

Se as cerimônias não acontecem

Falta planejamento Falta comprometimento para entregas PO pode aceitar itens que não estão prontos


Sem retrospectivas

Falta de uma maneira de melhorar o trabalho do time Mesmos erros acontecem sempre Impedimentos não são removidos


O que é difícil em Scrum?

Detalhes podem escapar se não for gerenciado corretamente

Criar e manter um Product Backlog requer trabalho


Não é uma metodologia completa e com o carimbo de um fornecedor


Livros

Obrigado!

Duas certezas sobre seu próximo projeto:1. O escopo vai mudar2. Alguma coisa vai dar errado

Este trabalho está licenciado através da “Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 3.0 Unported”

Você pode:Copiar, distribuir, exibir e executar a obra

Criar obras derivadas

Sob as seguintes condições:Atribuição. Você deve dar crédito ao autor original, da forma especificada pelo autor ou licenciante.Uso Não-Comercial. Você não pode utilizar esta obra com finalidades

comerciais. Compartilhamento pela mesma Licença. Se você alterar, transformar, ou criar

outra obra com base nesta, você somente poderá distribuir a obra resultante sob uma licença idêntica a esta

• Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da licença desta obra. • Qualquer uma destas condições podem ser renunciadas, desde que Você obtenha permissão do autor.• Nothing in this license impairs or restricts the author's moral rights.

http://creativecommons.org/licenses/by-nc-sa/3.0/deed.pt

Gestão Ágil de Projetos

Business