Scrum

IT Depends on Common Sense

Motivadores

1. Temos que introduzir no processo de desenvolvimento um grande aumento de produtividade para conseguir atender à demanda prevista de sistemas;

2. Temos que garantir a qualidade do que é produzido.

3. Temos que caracterizar a mútua responsabilidade na construção /  testes dos sistemas – o processo de desenvolvimento é uma tarefa que exige colaboração de desenvolvedores, definidores de sistemas e usuários de funcionalidades.

Motivadores

4. Temos que migrar da atual realidade onde os sistemas são construídos sem planejamento, para um método de trabalho que permita planejar e controlar os trabalhos.

A transparência do processo tem de ser total, para todos os envolvidos (dono do produto, facilitador e equipe:usuários e informatas)

Martian Tourist Brochure Backlog

Create cover art, brand, and/or logoDefine major topics for Martian tourismDescribe “Art Interests in Europe” tourDescribe a tour based on photosynthesisOutline a “7 wonders of the world” expeditionSet prices for the toursOutline warning messages (gravity, oxygen, fungi,etc.)Suggest clothing optionsExplain travel options to/from MarsDescribe a “Human Sports” tourOutline refund policySuggest related servicesDefine advertisersDefine a 12-month campaignSet-up how to get more information

GOAL: DELIVER A GOAL: DELIVER A BROSCHURE FOR THE BROSCHURE FOR THE EARTH TOURIST BOARD EARTH TOURIST BOARD LOCATED ON MARSLOCATED ON MARS

Timebox: 25 min.Timebox: 25 min.

NOVOS REQUISITOS OBRIGATÓRIOS:NOVOS REQUISITOS OBRIGATÓRIOS:- Roteiro: Corrida do ouro no EgitoRoteiro: Corrida do ouro no Egito

- Roteiro: Olimpíadas PequimRoteiro: Olimpíadas Pequim- Opção de viagem passando pelo Sol (descrever o valor)Opção de viagem passando pelo Sol (descrever o valor)

Retrospective

"Regardless of what we discover, we understand and truly believe that

everyone did the best job they could, givenwhat they knew at the time, their skills and abilities,the resources available, and the situation at hand"(Kerth, Project Retrospectives, 2001)

O que aconteceu?

Scrum

2.1. Manifesto ÁgilO desenvolvimento ágil descreve abordagens de desenvolvimento

que seguem os seguintes princípios:

"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

– 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."

2.2. O que é o Scrum?

2.2. O que é o Scrum?

• Gerenciamento empírico e controle de processo

• Inspeção e adaptação com base em feedback

• Usado para gerenciar projetos complexos desde 1990

• Entrega de funcionalidades de negócio em 30 dias

• Escalabilidade na distribuição de projetos grandes e longos

• Compatível com CMM Level 3 e ISO 9001

• Extremamente simples mas de difícil implementação

2.3. Princípios

• Equipes auto-organizáveis

2.3. Princípios

• Time responsável e comprometido

• Honestidade

• Transparência

• Partes potencialmente entregáveis

• Timebox

www.glogerconsulting.de

2.4. SMART Objectives

• S pecific - específicos

• M easurable - mensuráveis

• A achivable - alcançáveis

• R ealistic - realísticos

• T imed - programado

www.glogerconsulting.de

Exercício: A arte do possível

Explore a diferença entre planejar uma festa iniciando todas as frases com:

“sim, mas” “sim, e”

3. Papéis no ScrumAtividade Papel Responsabilidade

Gerencia a visão

Product Owner

O Product Owner estabelece, mantem viva e comunica a visão do produto. Ele demonstra que o projeto é alcançável e o financia criando a visão dos releases e do Product Backlog inicial.

Gerencia o ROI

Product Owner

O Product Owner monitora o projeto, mantém de acordo com o ROI estabelecido. Ele atualiza as prioridade do Product Backlog para assegurar-se que as tarefas de maior valor funcional sejam produzidas primeiro. Ele prioriza o Product Backlog and mede o sucesso para assegurar que o projeto está no caminho certo.

Gerencia as iterações de desenvolvimento

Team Durante uma iteração o time seleciona e desenvolve os requisitos de maior prioridade do Product Backlog. Coletivamente, o time expande os itens do Product Backlog para tarefas mais explícitas no Sprint Backlog e gerenciam o trabalho e a sua própria organização para entregar os itens desejados naquela iteração. O time se gerencia para cumprir o compromissos.

Gerencia o processo

Scrum Master O Scrum Master é responsável por ajustar a equipe acima tentando assegurar o

sucesso do projeto e otimizar a cultura organizacional para encontrar os objetivos no projeto. Isto envolve organizar a Sprint Planning Meeting, a Sprint Review Meeting, protegendo a equipe dos distúrbios externos, realizando as Daily Scrum Meetings, e removendo impedimentos para o progresso do projeto.

Gerencia os releases

Product Owner O Product Owner toma decisões sobre quando criar um release oficial. Por uma série

de razões não é desejável liberar um realease a cada incremento. O Product Owner toma esta decisões de maneira consistente com base na visão de investimento que foi estabelecida para o projeto.

3.1. Questionamento a respeito dos papéis

• O que ocorre quando o Scrum Master faz parte do time?

• O que ocorre quando o Scrum Master assume o papel de Product Owner?

• Tempo: 5 minutos (Timebox)

3.1. Questionamento a respeito dos papéis

O que David deve fazer?

05 Product Owner

01 Scrum Master

4. Fluxo do Scrum

4.1. O que é um Backlog Item?

Como <user role> eu quero <feature> para que <business value>

4.2. Product Backlog

• Lista de funcionalidades, tecnologia a ser aplicada, issues

• Issues são situações/assuntos do projeto que terão o trabalho definido mais tarde

• Itens priorizados e estimados

• Maior detalhamento sobre os itens de maior prioridade

• O Product Owner é responsável pela priorização

• Qualquer um da equipe pode contribuir

• Mantido e fixado em local visível

• Derivado do plano de negócio e da visão estabelecida, que tem que ser criada em conjunto com o cliente

• Estimation Meeting

Planning Poker

• Chile• Argentina• Venezuela• Brasil• Uruguai• Paraguai• Egito• Itália

• 1, 2, 3, 5, 8, 13, 21

4.3. Sprint Planning 1

• Definir o Sprint Goal e o Selected Product Backlog

• Para cada Backlog Item do Product Backlog– O Product Owner deve explicar a história por trás do item– Cada membro da equipe deve mostrar a sua estimativa para o

item– Se as estimativas da equipe forem diferentes, o menor e o

maior valor devem ser explicados até que cheguem em um acordo

4.4. Sprint Planning 2

• Define as tarefas para realizar o Sprint Backlog e alinha ao Sprint Goal

• Junta a estimativa com a realidade da equipe e do projeto

• Design é detalhado nesta sessão

• Vamos ao quadro!

4.6. Monitor the task board

• Sprint Burndown

• Product Burndown

• Velocity per Sprint

• Chart: business value evolution

4.5. Daily Meeting

• Objetivo: Sincronizar a equipe

– Quais as tarefas foram realizadas ontem?

– Quais as tarefas serão desempenhadas hoje?

– Quais os impedimentos encontrados durante o seu trabalho?

• Mover as tarefas dentro do quadro de acordo com a sua execução

• Resultados

– Atualização do Impediment Backlog

– Atualização do Sprint Backlog

– Atualização dos gráficos Burndown

• Novas funcionalidades que surgirem serão armazenadas para avaliação ao final

do Sprint

Done!

• Quando uma tarefa esta realmente concluída?

4.9. Impediments Backlog

• Backlog de Impedimentos (podem ser para a equipe ou para a organização resolver)

Recursos Skills

Prazo impossível Infra-estrutura

Ausência de feedback pelo cliente Escopo não definido

Escopo em constante mudança Problemas contratuais

Falta de prioridade Falta de unidade entre equipes

Burocracia

4.7. Sprint Abnormal Termination

• Sprints podem ser cancelados antes do final do Sprint

4.8. Sprint Review

• O team deve apresentar os resultados do Sprint e as novas

funcionalidades desenvolvidas

• Se surgirem novas funcionalidades ou alteração, os novos itens

irão para o Backlog para serem estimados e priorizados

• O team deve reportar os impedimentos durante o

desenvolvimento

• Ao final todos envolvidos no projeto devem entender a evolução

do projeto e os impedimentos

4.10. Sprint Retrospective

• O processo é aprimorado ao final de cada Sprint

• Facilitado pelo ScrumMaster

• O que aconteceu de bom que nóspodemos utilizar como melhoria?

• ScrumMaster basea a prioridade de acordo com o team

• A equipe planeja a solução dos problemas de sua responsabilidade

4.11. Listagem de artefatos

• Product Backlog• Sprint Backlog• Impediments Backlog• Bugs Backlog

• Chart: business value evolution• Product Burndown• Sprint Burndown

• Velocity per Sprint

Escalabilidade no SCRUM

Chickens and Pigs

Velocity Game

GO GO GO!

Retrospectiva AINFO

“Independente do que nós descubramos, nós compreendemos e acreditamos verdadeiramente que todos fizeram o melhor trabalho que poderiam, naquele momento deram o que sabiam, seus conhecimentos e suas habilidades, os recursos disponíveis, e a situação disponível.”

Timeline

Retrospectiva

• O que ocorreu bem?

• O que pode ser melhorado?– Dividir em “Team” e “Organization”