Você está na página 1de 17

27/08/2018

Framework
SCRUM

Paradigma Cascata x Ágil

Cascata Ágil
Plano de projeto Releases
Acompanhado pelo gerente Acompanhado por todos
Requisitos detalhados antes Requisitos detalhados durante
Cliente aprova especificações Cliente aprova software funcionando
Elaborar documentos Código
Encontrar defeitos Evitar defeitos

1
27/08/2018

Lean – Conceitos 7 Desperdícios

Passagem de Fora dos


trabalho de Transferência Trabalho critérios
uma pessoa de Controle Inacabado de aceite
para outra. do cliente.

Pessoas
passando de
uma tarefa Troca de
Defeitos Entregas
fora do
Atrasos
Tarefas
para outra, Funcionalidades prazo.
sem terminar a entregues com
anterior.. erros.

Rediscutir
Adicionar novas itens que já
Funcionalidades Reaprendizado
funções, além do foram
Extras
solicitado. definidos .

© 2017 Wipro wipro.com confidential 3

Lean – Conceitos 7 Desperdícios

1 – Requisitos/trabalho inacabado
• Requisitos, especificados muito cedo que perdem sua credibilidade, eficácia e compromete a usabilidade
do sistema. Funcionalidades pela metade apenas atravancam o caminho para trabalhos que poderiam ser
feitos. Tornando-se facilmente obsoleto.
• Muito conhecido como “está pronto, só falta testar”.

2 – Processos a mais
• Burocracia e atividades que não geram valor e que diminui o tempo de resposta.
• Documentação desnecessária e documentação que são esquecidos ou perdem valor e se tornam
obsoletos ou documentos que ninguém se importa em ler.

3 - Funcionalidades a mais
• 80% das funcionalidades implementadas não são utilizadas.
• Código não-utilizado introduz complexidade e a complexidade é um inimigo da manutenção.

4 - Troca de tarefas/Transferência controle


• Organizar pessoas em múltiplos projetos é outra forma de desperdício.
• Quanto tempo se perde para parar uma determinada atividade e iniciar outra, relembrar onde parou,
concentrar-se e finalmente produzir algo?.

5 – Atrasos
• Atrasos em geral são puro desperdício e irão gerar aumento do custo do projeto;
• Um dos maiores desperdícios no desenvolvimento de software é a espera para que as coisas aconteçam.

6 - Defeitos
• Equipes ágeis se esforçam ao máximo para evitar defeitos.
• “Inspecionar para prevenir defeitos é bom; Inspecionar para encontrar defeitos é desperdício” -- Shigeo
Shingo

7 – Movimento/reaprendizado/esforços de comunicação
• Equipes ágeis valorizam a conversa e por isso trazem o cliente para perto.
• Tempo e esforço gasto para encontrar informações.

© 2017 Wipro wipro.com confidential 4

2
27/08/2018

SCRUM

 Scrum é um processo ágil que permite manter o foco na entrega do


maior valor de negócio, no menor tempo possível.

 As necessidades do negócio é que determinam as prioridades do


desenvolvimento de um sistema. As equipes se auto-organizam para
definir a melhor maneira de entregar as funcionalidades de maior
prioridade.

 A cada duas ou quatro semanas todos podem ver o real software em


produção, decidindo se o mesmo deve ser liberado ou continuar a ser
aprimorado por mais um “Sprint”.

SCRUM

 Mudança de ATITUDE de todos!

 Mudança de mindset;

 O projeto é nosso.

 Ágil não é fazer rápido, mas fazer a diferença;

 Conceito moderno: Errar rápido, aprender rápido;

 Líder servidor;

 Equipes auto-organizadas;

 Fim do comando e controle;

 Serve para projetos de qualquer tamanho.

3
27/08/2018

O que significa SCRUM?

 Scrum é o nome de uma das mais conhecidas jogadas do Rugby,


tendo como principal característica uma formação ordenada que pode
ser visualizada na imagem abaixo:

 Nesta jogada, oito jogadores


disputam a reposição de bola
atuando em conjunto com o
mesmo objetivo, sendo
que se um deles falhar,
todos falham.

 O trabalho em equipe é a
principal característica do
framework.

Características do Scrum

 O objetivo so SCRUM é desenvolver e manter produtos complexos e


adaptativos.

 O SCRUM é:
 Leve
 Simples de entender
 Extremamente difícil de dominar.

 O conhecimento vem da experiência e tomada de decisões baseadas no


que é conhecido, chamada de empirismo.

4
27/08/2018

Base do SCRUM

Empírico.....

... Desenvolvimento
Iterativo e
Incremental

...Timebox!!!

Visão Geral SCRUM

5
27/08/2018

Os Pilares do SCRUM

Transparência
Foco na definição
de pronto.

Sprint Plan
Inspeção de tudo Reunião diária
que é produzido. Reunião revisão
Retrospectiva

Inspeção Adaptação

PAPÉIS
SCRUM

6
27/08/2018

O Product Owner

 Define as funcionalidades do produto, mantendo o Product Backlog.

 Decide datas de lançamento e conteúdo dos releases.

 Responsável pela rentabilidade (ROI).

 Prioriza funcionalidades de acordo com o valor.

 Ajusta funcionalidades e prioridades.

 Apresenta ao time os requisitos necessários para a entrega do


produto.

 Aceita ou rejeita o resultado dos trabalhos.

 Atua como facilitador quando há mais clientes envolvidos.

 Garante que especialistas estejam disponíveis para o time.


O Scrum Master

 Representa a gerência para o projeto.


 Responsável pela aplicação dos valores e práticas do Scrum.
 Remove os impedimentos.
 Garante a plena função e produtividade da equipe.
 Garante a colaboração entre os envolvidos.
 Escudo para interferências externas.
 Responsável por garantir que o produto atenda às necessidades do
cliente.
 Auxilia o Product Owner com o Product Backlog.
 Facilita as reuniões.

7
27/08/2018

O Time

 O trabalho entregue ao cliente é gerado por um “Time Scrum”


dedicado.

 Times Scrum são auto-organizados, multidisciplinares e


comprometidos.

 Responsáveis por entregar o que foi acordado como meta do Sprint.

 Definir como as tarefas devem ser divididas para gerar o resultado


esperado.

 Definir quem irá executar as tarefas e em que ordem elas são


realizadas.

Time - Funções

 No framework Scrum não existe diferença entre “testador" e


“arquiteto”. Todos eles compartilham o mesmo título de "Scrum
Team Member”.

 “Equipes Scrum” são pequenas. Deve ter entre 3 a9 pessoas.

Comprometimento – a mudança é individual e não da organização

8
27/08/2018

Time - Formação

 Quando se cria um novo “Time Scrum” não espere que ele vá


começar a trabalhar com o mais alto desempenho possível desde o
início.

 Após montar o time, este tem que passar


por certas fases, conforme descrito pelo Formação
Modelo de Tuckman: formação, conflito,
acordo e desempenho. Conflito

 Cada time tem tempos diferentes para Acordo


atingir a fase de desempenho.
Desempenho
 Em estudos realizados, um time Scrum
Dispersão
demora cerca de 3 sprints para entrar em
ritmo de desempenho.

Equipes de Sucesso

Planejamento
Empoderamento
Reconhecimento
Feedback
cOaching
Relacionamento
Meta

9
27/08/2018

Product Backlog

 Na definição mais simples o Product Backlog é simplesmente uma lista de


todas as coisas que precisam ser feitas dentro do projeto. Ele não substitui
os artefatos de especificação de requisitos tradicionais.

 Esses itens podem ter uma natureza técnica ou pode ser centrada no
usuário, por exemplo sob a forma de “User Stories”.

 O proprietário do Product Backlog é o Product Owner.

 O Scrum Master e o Time contribuem para ter uma ampla e completa lista
de afazeres.

 Deve ser visível a todos os envolvidos

Sprint

 O sprint é um timebox de 2 a 4 semanas.

 Timebox, nunca esqueça que a data final é definitiva.

 No conceito de sprint está implícito o conceito de entregar valor


constantemente para o cliente.

 Em SCRUM, o cliente sempre terá um produto ou parte do produto


entregue em intervalos curtos, de acordo com sua prioridade, facilitando
o controle e validação do software.

10
27/08/2018

Planejamento da Sprint

 Meta da Sprint

 O time scrum define a meta da Sprint.

 É uma breve descrição do que deve ser entregue de valor


(tangível).

 Deve ser realista e compreensível para todos.

Planejamento da Sprint

 Durante a sessão o PO apresenta a meta da sprint e discute com o


Time.

 Depois que o Time Scrum percorre os itens relevantes no Product


Backlog, eles se comprometem com o que acham que pode ser
totalmente concluído dentro da sprint.

 A decisão deve ser baseada na capacidade disponível e no


conhecimento sobre as atividades.

 A equipe deve estimar quanto tempo (horas) vai precisar para fazer tudo
o que é necessário para concluir cada atividade da Sprint.

 O resultado é o Sprint Backlog.

11
27/08/2018

Sprint Backlog

 O Sprint Backlog contém todas as atividades necessárias para


completar as entradas selecionadas do Product Backlog. Todos os itens
devem ser estimados numa base de homem-hora, a fim de acompanhar o
progresso e os esforços restantes.

 O Sprint Backlog é um artefato que deve ser atualizado diariamente. Se


um membro da equipe começa a trabalhar em uma atividade seu nome
está gravado dentro do Sprint Backlog.

 Novas atividades podem ser adicionados ao Sprint Backlog durante a


sprint.

 No final do dia, todos os esforços restantes são atualizados e isso define


o quanto o trabalho ainda falta até que a meta da sprint seja alcançada.
É o Sprint Burndown.

Exemplo Sprint backlog

Fonte: Santos, Rildo. Scrum. O tutorial definitivo.

12
27/08/2018

Teste de aceitação

 A elaboração dos testes de aceitação auxiliam o Time na


validação das funcionalidades construídas.

• Teste de pagamento com cartão


vencido.
• Testes de pagamento com cartão sem
limite para o valor da compra.
Como um cliente cadastrado no • Teste de pagamento com cartão
site posso pagar meu pedido expirado.
com cartão de crédito. • Testes de pagamento com as
bandeiras Visa e Master.
• Testes de pagamento com mais de um
cartão.

Teste de aceitação

 Escrever os testes de aceitação antes da codificação.

 O cliente é quem deve especificar testes de Aceitação.

 Teste DEVE fazer parte do processo.

 Tipos de testes:

 Testes funcionais, navegação, domínio, usabilidade,


carga, stress, performance, etc.

13
27/08/2018

Cuidados Durante a Execução de uma Sprint

 O Time deve dar foco total ao que se comprometeu a entregar com o


PO.

 Mudanças são bem-vindas, mas devem ser incluídas no Product


Backlog para posterior priorização e planejamento.

 Se há mudanças constantes no Sprint Backlog:

 Product Owner não dá a devida atenção a priorização do Product


Backlog e ao planejamento, pois ele pode alterar a hora que quiser.

 Time não se compromete com a sprint, pois ela mudará!

 Time perde o foco e a motivação.

 Voltamos ao cenário dos projetos tradicionais!

Quando uma sprint pode ser cancelada?

 Uma Sprint pode ser cancelada quando:

 O Time Scrum verifica que as estimativas foram erradas e que não


conseguirá entregar o combinado.

 O PO percebe que mudanças relevantes ocorreram e afetam o


resultado da sprint.

 Caso uma sprint seja cancelada, o Time Scrum e o Product Owner


devem, na sequência, iniciar o planejamento da próxima sprint.

 Somente o PO tem autoridade para cancelar um Sprint.

14
27/08/2018

Reunião diária
 Durante essa reunião, cada membro da equipe deve fornecer brevemente as
respostas para as três perguntas seguintes:

 O que foi realizado desde a última reunião que ajuda no cumprimento


da meta do Sprint?
 O que vai realizar até a próxima reunião que ajuda no cumprimento da
meta do Sprint?
 Quais são os impedimentos em suas tarefas que ajuda no
cumprimento da meta do Sprint?

 Todos os membros da equipe devem participar e eles devem ficar em pé


durante a reunião que não deve durar mais de 15 minutos.

Revisão da Sprint

 Ao final da Sprint há a Revisão da mesma, onde todos podem participar.

 Tem como principal objetivo inspecionar e obter opiniões e impressões de como


foi a sprint para o Product Owner e convidados.

 O time é quem realiza a apresentação, que deve ser feita no formato de


demonstração do software.

 O Product Owner avalia se a meta da sprint foi atingida, faz anotações que
poderão se transformar em novos itens para o Product Backlog.

 Tempo máximo: 4 horas.

 Atualização do Release Burdown.

 Product Backlog atualizado.

15
27/08/2018

Retrospectiva da Sprint

 Após a Revisão do sprint ocorre a reunião da Retrospectiva da mesma, com o


Time Scrum e o Scrum Master como facilitador.

 Nesta reunião todos os membros da equipe refletem sobre o sprint passado e


verificam três coisas:

 O que correu bem durante o sprint?


 O que não correu bem durante o sprint?
 Quais melhorias poderiam ser feitas no próximo sprint?

 Sem esta reunião a equipe nunca será capaz de melhorar a sua produtividade;
 Tempo estimado: máximo 3 horas.
 É parte integrante do processo de "inspecionar e adaptar".

Sprint Zero

 Puristas Scrum não gostam desse termo, pois não produz valor para o
cliente e seu objetivo é preparar para o primeiro sprint.

 Ideia é:
 Montar a equipe do projeto.
 Criar o ambiente para o desenvolvimento do projeto.
 Fazer plano inicial, estruturar o Product Backlog ou o design.

 Duração estimada da sprint: 2 semanas.

16
27/08/2018

Spike

 Uma técnica ágil que visa responder a requisitos técnicos ou problemas


de design com o objetivo de examinar e eliminar eventuais
preocupações.

 Deve ser estimado na sprint planning como uma sprint técnica.

 Pode ser utilizado para entender um processo de negócio.

 Realiza pesquisa e desenvolvimento para minimizar riscos de problemas


técnicos.

 Frequentemente produz desenhos de arquitetura, protótipos de telas e


provas de conceito.

 Duração estimada da sprint: 2 semanas

Obrigado

17

Você também pode gostar