Gestão Ágil com Scrum

Gestão Ágil de Projetos com Scrum

Noaldo Sales Santos Filho
noaldo@gmail.com


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
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%
– 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%
– 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%
– 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;
• 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);
• 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
– 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;
– 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 Example
User 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 H 5
documento
Como usuário eu gostaria de buscar documentos H 10
pelo texto deles
Como usuário eu gostaria de criar pastas para os M 3
documentos
Como usuário eu gostaria de poder mover um M 3
documento para uma pasta
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;
• 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;
– 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
• 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

Tamanho Cálculo Duração

300 Story Velocity = 300/20 =
Points 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-
scrum-master-also-be-member-of.html
• http://www.planningpoker.com/


Gestão Ágil com Scrum

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Destaque

Destaque (6)

Semelhante a Gestão Ágil com Scrum

Semelhante a Gestão Ágil com Scrum (20)

Gestão Ágil com Scrum