Gestão Ágil de Projetos com Scrum

Gestão Ágil de Projetos com Scrum

Noaldo Sales Santos Filho

Noaldo Sales Santos [email protected]

Motivação• 1986 um paper foi publicado comparando a

construção de pontes e a construção de softwares. Como premissa foi utilizado:– Pontes normalmente são entregues no prazo, dentro


– Pontes normalmente são entregues no prazo, dentro do orçamento e “não caem”

– Softwares raramente são entregues no prazo ou dentro do orçamento. E normalmente eles tem bugs.

• Razões para o sucesso na construção de pontes:– Alto nível de detalhe em momento de design;– O design é congelado e o contratante tem pouquíssima

flexibilidade de mudanças.

Motivação• The Standish Group fez uma pesquisa e em

2009 publicou:• 24% dos projetos fracassam;


• 44% dos projetos são entregues com sucesso parcial;

• E apenas 32% dos projetos obtêm sucesso.

Motivação• Os principais fatores que ajudaram no sucesso dos

projetos foram:– Envolvimento do usuário: 15.9%– Apoio executivo: 13.9%


– Apoio executivo: 13.9%– Declaração de requisitos clara e limpa: 13%– Planejamento apropriado: 9.6%– Expectativas realistas: 8.2%– Milestones pequenos: 7.7%– Equipe competente: 7.2%– Propriedade: 5.3%– Visão e objetivos claros: 2.9%– Trabalho duro e equipe focada: 2.4%– Outros: 13.9%

Motivação• Os fatores que influenciaram os projetos de sucesso

parcial foram:– Falta de insumos do usuário: 12.8%– Requisitos & Especificações incompletas: 12.3%


– Requisitos & Especificações incompletas: 12.3%– Mudanças nos requisitos & especificações: 11.8%– Falta de apoio executivo: 7.5%– Ambiente tecnológico incompleto: 7.0%– Falta de recursos: 6.4%– Expectativas irrealistas: 5.9%– Objetivos nebulosos: 5.3%– Ciclos (tempo) irrealistas: 4.3%– Novas tecnologias: 3.7%– Outras: 23%

Motivação• As principais causas de fracasso são:

– Requisitos Incompletos: 13.1%– Falta de envolvimento do usuário: 12.4%– Falta de recursos: 10.6%


– Falta de recursos: 10.6%– Expectativas não realistas 9.9%– Falta de apoio executivo: 9.3%– Mudanças de requisitos: 8.7%– Falta de planejamento: 8.1%– Não precisa mais daquilo: 7.5%– Falta de gestão da TI: 6.2%– Analfabetismo tecnológico: 4.3%– Outros: 9.9%

Motodologias Ágeis• Agile Alliance

– Em 2001, Kent Beck e outros dezesseis renomados desenvolvedores, autores e consultores assinaram o manifesto para o desenvolvimento ágil de software.


– Indivíduos e interações mais que processos e ferramentas

– Software que funciona mais que documentação completa

– Colaboração com o cliente mais que negociação contratual

– Respostas as mudanças mais que seguir o plano

Project noise level


Agile Value Profile


Plano vs Valor


Scrum Framework


Scrum Framework• Scrum não é uma metodologia que irá te ajudar a

desenvolver melhores produtos;• Scrum não lhe dá a resposta de como desenvolver

software de qualidade mais rapidamente;


software de qualidade mais rapidamente;• Scrum é uma ferramenta, um framework, que você pode

usar para identificar o que você precisa fazer para desenvolver software de qualidade rapidamente;

• Scrum não necessita que as equipes estejam co-localizadas. Porém, lhe permite medir a produtividade de equipes co-localizadas;

• Eficaz para projetos com prazos de entrega apertados, requisitos mutáveis e críticos de negócio.

O que é Scrum?• É um Framework Agile que permite entregar um “valor de

negócio” mais elevado num período de tempo mais curto;• Concebido em 1990 por Jeff Sutherland e sua equipe;• Permite entregar rapidamente software funcionando e de

qualidade a cada duas a quatro semanas (Sprints);


qualidade a cada duas a quatro semanas (Sprints);• O cliente define as prioridades. O time se auto-organiza e

determina a melhor forma de entregar as funcionalidades de maior priorização;

• No fim de cada Sprint o Time apresenta para o cliente as funcionalidades funcionando.

• Seus princípios são usados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as atividades de requisitos, análise, projeto, evolução e entrega.

Por que Scrum?• Aumento do ROI

– Métodos tradicionais demoram para satisfazer as necessidades do cliente;

– Entregar mais cedo permite um ROI mais cedo.

• Flexibilidade


• Flexibilidade– Responder a mudanças de requisitos;– Responder a evolução da tecnologia.

• Produto de Qualidade– Entregar produto certo na primeira entrega;– Entregar com menos erros, testando mais cedo e com mais

frequência.

• Visibilidade– Medida do progresso = produto concluído;

• Rápido Feedback– Feedback constante do cliente, stakeholders e membros do time.

O que é Scrum?• Transparência• Inspeção• Adaptação


Scrum é composto por• Times Scrum – e seus papéis associados;• Time-Boxes – Eventos com duração fixa;• Artefatos;


• Regras;

Time-Boxes• Assegurar o foco do time nas tarefas que

precisam ser executadas.– Reunião de Release Planning;– Reunião de Sprint Planning;


– Reunião de Sprint Planning;– Sprint;– O Daily Stand up;– Sprint Review;– Retrospectiva;

Os Três Papéis


Porcos e Galinhas


Galinhas• Não fazem parte do time;• Não podem mandar no time;• Não podem alterar o caminho do time;


• Suas idéias só farão parte do Product Backlog se o PO assim decidir;

• Quer fazer alguma coisa? Quer decidir? Quer participar? Então, seja porco.

Product Owner (PO)


Product Owner (PO)• Define as funcionalidades do produto;• Decide a data de entrega e o conteúdo;• Responsável pelo ROI;


• Prioriza as funcionalidades conforme o valor de negócio;

• Ajusta as funcionalidades e suas prioridades a cada Sprint;

• Aceita ou rejeita os resultados.

Scrum Master (SM)

“The sheepdog for the team” – Ken Schwaber


Scrum Master (SM)• Responsável pela aplicação dos valores e

práticas do Scrum;• Remove impedimentos;


• Assegura que a equipe está totalmente funcional e produtiva;

• Permite a cooperação entre os diversos papéis e funções;

• Proteje o time das interferências externas.

Scrum Master (SM)• Quem pode ser o ScrumMaster?• O ScrumMaster pode ter outros papéis?• Quais as qualidades que ele precisa ter?


• Qual a autoridade que o ScrumMaster tem?• O ScrumMaster é responsável por datas,

orçamento, benefícios, etc.?• Quais as obrigações do ScrumMaster?

O Time (Team)


O Time (Team)• 7 pessoas (+ ou - 2);• Multifuncional;• Dedicados ao projeto;


• Auto-organizado e auto-gerenciável;• Responsável por escolher o trabalho que será

executado durante o Sprint;• Responsável por quebrar as funcionalidades e

estimar a sua complexidade;

Scrum = Communication


Alguém ainda não viu?


Product Backlog Iceberg


Product Backlog ExampleUser Story Priority Estimate

Como usuário eu gostaria de criar uma conta H 4

Como usuário eu gostaria de enviar um documento H 8


Como usuário eu gostaria de visualizar um documento

H 5

Como usuário eu gostaria de buscar documentos pelo texto deles

H 10

Como usuário eu gostaria de criar pastas para os documentos

M 3

Como usuário eu gostaria de poder mover um documento para uma pasta

M 3

Como usuário eu gostaria de taggear um documento L 4

User Stories• Atributos:

– Tamanho (pontos, dias ideiais), Valor de negócio;– Condições de satisfação.


User Stories• Quando necessário, a equipe também pode

definir estórias para o produto;• Estórias muito grandes devem ser divididas.


User Stories• Teste escrever:

– What? (O quê?)– Why? (Por que?), Who? (Quem?)


User Stories no Backlog• 3 “C”s

– Card – Escritas em index cards de tamanho 9 x 15cm– Podem conter estimativas, alguns detalhes, etc.


– Conversation – Um lembrete para ter uma conversa– Exponha os requerimentos, não os documente– Os detalhes aparecem durante as conversas

– Confirmation – Teste de aceitação para confirmar que a estória foi desenvolvida corretamente

– Documente os detalhes das conversas

Story Points• Tamanho de uma estória;• Influenciado por:

– O quanto difícil é a estória;


– Qual o tamanho do trabalho.

• Valor relativo;• Pontos não possuem unidades:

– Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, ...)

Tempo• Quanto tempo algo iria demorar se:

– Você trabalhasse apenas nisso;– Sem interrupção de tempo;– Tudo que você precisa estará disponível;


– Tudo que você precisa estará disponível;

• O tempo ideal de uma partida de futebol seria de 90 minutos:– Dois tempos de 45 minutos.

• O tempo total, porém, leva + ou - 2 horas.

Prática – Product Backlog�Dividam-se em equipes;

�Escolham um Product Owner;


�O produto será um software para uma loja de roupas;

�Definam de 10 a 12 User Stories;

�Priorizem com o Product Owner;

� 30 minutos;

ROI – Return Of Investment


Sprint Planning


Sprint Burndown


Prática – Sprint Planning• Com o product backlog produzido

anteriormente:

– Quebrar as User Stories em tasks;


– Quebrar as User Stories em tasks;– Definir o tempo em horas ideais que cada task deve

demorar pra ser feito;– Priorizar conforme as necessidades do product owner;

– #PARADO AQUI#

Release


Velocity• Para fazer um release plan, precisamos saber

ou ter uma idéia de Velocity;


• 3 formas de termos a Velocity:– Média das anteriores;– Aprendizado das Sprints anteriores;– Faça uma previsão.

• Deve ser expressa como um intervalo

Re-estimar• Velocity normalmente corrige as falhas de

estimativas;


• Só deve acontecer quando o tamanho relativo de uma user story se altera;

• Alterar os tamanhos relativos de todas as user stories não leva você a lugar nenhum;

Definindo Pronto• O que significa “pronto” em seu projeto atual?

• Quais os problemas que você tem com a


definição atual?

• Como resolver esses problemas?

• Quais problemas de engenharia você percebe?

Definição de Done

• Code produced (all ‘to do’ items in code completed)• Code commented, checked in and run against current version in source

control• Peer reviewed (or produced with pair programming) and meeting

development standards


development standards• Builds without errors• Unit tests written and passing• Deployed to system test environment and passed system tests• Passed UAT (User Acceptance Testing) and signed off as meeting

requirements• Any build/deployment/configuration changes

implemented/documented/communicated• Relevant documentation/diagrams produced and/or updated• Remaining hours for task set to zero and task closed

Fonte: http://www.allaboutagile.com/definition-of-done-10-point-checklist/

Estimativa / Velocity = Duração

TamanhoTamanho CálculoCálculo DuraçãoDuração


300 StoryPoints

300 StoryPoints

Velocity = 20

Velocity = 20

300/20 = 15 Sprints300/20 =

15 Sprints

Interrupção Anormal• Uma ferramenta a ser evitada;

• Para circunstâncias extremas;


• Um novo Sprint Planning Meeting deve ser feito.

Review


Questões?


Referências• Material do curso CSM do CST Michel Goldenberg;• http://www.scrumalliance.org• http://www.allaboutagile.com/• http://blog.agilegamedevelopment.com/2008/08/should-


• http://blog.agilegamedevelopment.com/2008/08/should-scrum-master-also-be-member-of.html

• http://www.planningpoker.com/

Gestão Ágil de Projetos com Scrum

Art & Photos

Transcript of Gestão Ágil de Projetos com Scrum