Scrum

Tiago Silva da Silva

Scrum

[email protected] !

@tiagosdasilva !

[email protected] !

tiago.silva.da.silva

mailto:[email protected]



Scrum

[email protected] !

@tiagosdasilva !

[email protected] !




Agenda

• Origens

• Pilares

• Framework Scrum

• Papéis

• Artefatos

• Cerimônias

• Desafios

Por que utilizar Métodos Ágeis?

Origens

Origens

• Takeuchi, H; Nonaka, I. The new new product development game. Harvard Business Review. P. 137-146, 1986.

• Conference on Object Oriented Programming Systems, Languages and Applications, 1995., Austin. Proceedings…Austin: OOPSLA, 1995.

• Schwaber, K. Agile project management with Scrum. Redmond: Microsoft, 2004.

• Schwaber, K.; Sutherland, J. The Scrum Guide., 2013.

Origens

• Teorias empíricas de processo, empirismo.

• Afirma que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido.

• Emprega uma abordagem iterativa e incremental.

• Transparência

• Inspeção

• Adaptação

Pilares que apóiam o Scrum

• Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados

Transparência

• Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações.

Inspeção

• Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou material sendo produzido deve ser ajustado.

• O ajuste deve ser realizado o mais breve possível para minimizar mais desvios.

Adaptação

Framework Scrum

Framework Scrum

• …para apoiar a resolução de problemas complexos em ambientes de alta imprevisibilidade.

• Scrum não é o seu processo, mas o framework sobre o qual você empiricamente construirá os seus processos,

• você é bem mais habilitado para fazer isso do que outros profissionais que não conhecem a realidade de seu projeto e cultura da sua empresa.

Scrum

• Papéis

• Artefatos

• Cerimônias

Scrum

Scrum

Sprint

24 hours

Sprint Backlog Tasks

Product or increment

Daily Scrum

Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Product Backlog

Vision Release Planning

Sprint Planning

Retrospective

Review

Inspection and Adaption

Inspection and Adapttion

Sprint

24 hours

Subset of the PBL

Sprint Backlog


Daily Scrum

Product Backlog

Release Planning

Sprint Planning

Retrospective

Review

Inspection


Review if necessary

Sprint Zero

•  Contracting •  Team forming •  Proof of concepts •  Necessary requirements

gathering •  Necessary requirements

eliciting

Adapt in the next Sprint

Papéis

Papéis

• Product Owner

• Team

• Scrum Master

Papéis

• Product Owner

• Team

• Scrum Master

!

• Auto-organizadas

• Multifuncionais

Product Owner

Product Owner

• Entende e compartilha a visão do produto

• Gerencia e maximiza o ROI

• Sabe como priorizar o Product Backlog

• Colabora constantemente com o Time e o SM

• Planeja releases

• Gerencia e poda o Product Backlog

Team

Team• Auto-organizado

• Multidisciplinar

• Responsável pela estimativa quanto ao tamanho dos itens do Product Backlog

• Está em constante conflito

• Compreende o conceito de auto-gerenciamento dentro do contexto técnico de uma Sprint

• Ninguém os orienta sobre como transformar o Product Backlog em incrementos de funcionalidades de software pronto.

Scrum Master

Scrum Master• Remove impedimentos

• Verifica se o o Scrum está sendo implementado adequadamente

• Facilita as cerimônias

• Melhora constantemente suas habilidades de liderança

• Líder na questão do processo

• Coach o Time e o PO

• Para o restante da organização, ele servirá como interface e especialista em Scrum

Artefatos

Artefatos

• Product Backlog

• Sprint Backlog

• Incremento

Product Backlog

Product Backlog

• DEEP

• Detailed appropriately

• Estimable

• Emergent

• Prioritized

The Product Backlog Dynamics


• Foco na Representação, não na Documentação

• Entregável vs. Consumível


High priority

Low priority

At each iteration, the set of higher priority (finer granularity) is selected.

At any given moment, items can go up or down in the PBL

PBI’s down in the PBL have coarse granularity and must be worked as the Sprints progresses

Product Backlog

Backlog do Produto: TwitterLogin de usuários já cadastrados

Cadastrar novo usuárioTweetar

Visualizar tweets de quem sigoVisualizar número de seguidores que possuo

Visualizar histórico de um tweetMostrar banner promocional

Remover tweetVer sugestões de usuários a seguir

Listar trendsCompor e alterar meu perfil de usuário

(…)

Sprint Backlog

Sprint Backlog

• US1: As a client, I need to log into the system in order to edit my data └  T1: Model and design database

tables └  T2: Design front-end interface └  T3: Develop communication

middleware └  T4: Develop login rules

• US2: As a seller, I want a list of clients to be able to contact them. └  T1: blablabla └  T2: blablabla

Sprint Planning

Ordered Product Backlog

Sprint BacklogMeta da Sprint: usuários poderão estar no twitter

Login de usuários já cadastrados

Ativar login com usuário Gmail

Montar layout do box de login

Montar plano de segurança Testar integrado

Estruturar log Revisar código

Criar comportamento de login

Inserir hint explicativo

Atualizar documentação técnica

(…)

Cadastrar novo usuário

Criar tabelas no banco de dados

Estruturar persistência

Definição sobre uso de templates

Quando validado, ativar usuário

Escrever testes Definir padrões para cadastros

Atualizar documentação técnica

Validar email cadastrado

Testar integrado (…)

Incremento

• Resultado do que foi produzido durante a sprint

• Um dos principais conceitos do Scrum

• Vai ao encontro da sua natureza empírica, já que permite ao PO perceber o valor do investimento e também vislumbrar outras possibilidade

• Potentially Shippable - Potencialmente Entregável

• O cliente pode colocar imediatamente em produção

DoD• Definition of Done

• Uma funcionalidade somente é considerada pronta se tiver passado por todas as etapas definidas pela Equipe de Desenvolvimento.

• Uma funcionalidade que não esteja pronta ao final da Sprint deve retornar ao Product Backlog para que seja incluída em uma próxima Sprint.

• Conforme a Equipe amadurece, é esperado que esta DoD se expanda para acomodar mais critérios visando à melhora na qualidade.

Cerimônias

Cerimônias

• Eventos de duração fixa (time-boxed) realizados em intervalos regulares.

• Cada um desses eventos é uma oportunidade para Inspeção e Adaptação.

Sprint

Sprint

Sprint

24 hours



Daily Scrum

Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Product Backlog


Sprint Planning

Retrospective

Review


Sprint

• Todo o desenvolvimento em Scrum é feito de forma iterativa e incremental - ciclos completos de desenvolvimento de duração fixa que, ao final, resultem em incrementos potencialmente entregáveis do produto.

• Duração de até um mês, o que permite feedbacks constantes.

• Sprint Planing, Daily Scrum, Sprint Review e Retrospective.

Sprint Planning

• O que será entregue no Incremento resultante nesta Sprint?

• Como faremos para entregar o Incremento nesta Sprint?

Release Planning

• Delineamento de entregas para o cliente

• Criação do Product Backlog

• Análise de Negócios

Sprint Planning vs. Release Planning

• Sprint Planning acontece para planejar a iteração, logo:

• Trabalha com histórias de menor granularidade

• Tem um horizonte de planejamento curto

• Representa um alto nível de comprometimento

• Release Planning acontece para dar respostas ao cliente:

• Quando será entregue

• Maior granularidade: alto nível de abstração

• Grande quantidade de histórias

• Geralmente planeja-se 2-3 sprints antecipadamente

Daily Scrum

Sprint

24 hours



Daily Scrum

Product Backlog


Sprint Planning

Retrospective

Review


Daily Scrum, Daily Meeting

• O que fiz desde a última Daily?

• O que pretendo fazer até a próxima Daily?

• Existe algo me impedindo de concluir alguma tarefa?

Sprint Review vs. Retrospective

Sprint

24 hours



Daily Scrum

Product Backlog


Sprint Planning

Retrospective

Review


Sprint Review

• Entrada é o Produto.

• Objetivo é inspecionar o que o Time produziu e colher impressões dos presentes para, caso seja necessário, adaptar o plano para a Sprint seguinte.

• PO valida ou não as entregas da Sprint, de acordo com a meta acordada com o Time.

• Demonstração

• Time responde à perguntas

Sprint Retrospective

• Entrada é o Processo.

• Imediatamente após a Review.

• Objetivo é a melhoria do processo

• Interação entre os membros do Time

• Práticas e ferramentas utilizadas

• O que funcionou

• O que precisa ser melhorado

• Além de identificar problemas, deve-se identificar medidas a serem tomadas para a melhoria do processo já na próxima Sprint.

Desafios

Desafios

• Framework que fornece visibilidade para a equipe e um mecanismo que permite realizar inspeções e adaptações constantes.

• Transparência - deixa visíveis os problemas e impedimentos que impactam no PO e na eficiência da equipe.

• Não resolve os problemas do desenvolvimento, apenas os deixa visíveis.

Desafios

• Erro comum: quando se encontra uma prática do framework difícil de aplicar, tenta mudado o próprio Scrum, em vez de mudar a forma como a equipe trabalha.

• Equipe com dificuldade de entregar o que foi planejado durante uma Sprint tende a estender seu prazo de duração.

• Negando a possibilidade de aprender a melhor estimar e gerenciar seu tempo.

Perguntas

Perguntas• Sua empresa concorda em mudar o ciclo de vida dos

projetos para timboxes de 1-4 semanas?

• Sua organização concorda sem problemas em juntar divisões funcionais clássicas como analistas, programadores, testers, arquitetos em um único time?

• Sua empresa concorda em abrir mão de hierarquias rígidas tradicionais para uma estrutura mais horizontal?

• A liderança concorda em abrir mão do comando e controle, empoderando essa equipe multi-disciplinar a se auto-organizar e auto-gerenciar o trabalho?

Perguntas

• Escolher um líder-servidor para atuar como ScrumMaster é algo fácil na sua organização ou vai gerar muita discussão?

• O papel de Product Owner é facilmente identificável na sua organização? O cliente está “próximo”?

• Sua empresa está disposta a uma queda inicial de produtividade devida a curva de aprendizado e a inspeção e adaptação?

• Sua empresa está disposta a abrir mão dos atuais mecanismos de controle (custos, prazo, escopo) para adotar a forma ágil de controlar um projeto?

Problemas

Problemas

!

!

• Equipe não dedicada (comprometimento).

• Cliente ausente.

• Muita interrupção.

Problemas

• Como fica o planejamento e alinhamento com negócios?

• Como a diretoria pode ver?

• Por que não precisa de coordenação?

• Como mostrar o andamento?

Desafios

SCRUM+SCRUM

SCRUM+

...mas essa é a forma do Time B ser mais ágil.

SCRUMBUT


Scrum

[email protected] !

@tiagosdasilva !

[email protected] !




Conceitos e Técnicas

• User Stories

• Burndown chart

• Acceptance Tests

• Story Points

User Stories

User Stories• Uma descrição informal das necessidades do

negócio

• São trabalhadas e amadurecem à medida que a análise progride

• Uma história pode ser decomposta em duas ou mais histórias

• Devem ser testadas e aprovadas

• São priorizadas pelo PO de acordo com as necessidades do cliente

User Stories

Epic

blablablablablabla

blablablablablabla

blablablablablabla

Objective

Feature

Use Case/ User Story

Functional requirements

Non-functional requirements

The relationship between use cases and user stories

Burndown

Burndown

Acceptance Tests

Acceptance Tests

• Certificam que as stories implementadas correspondem ao que o cliente necessita

• Devem ser automatizados, se possível

Story Points

• Usado para estimar o tamanho de uma Story

• Estimativa relativa; 2 story points requerem mais esforço que um story point e, 13 story points requerem muito mais esforço do que um story point

• Por que a Sequencia de Fibonacci?

• 1 - 3 - 5 - 8 - 13

Story Points

• Empire State Building,

• Teatro Amazonas,

• sua casa,

• Cristo Redentor,

• Torre Eifel

Story Points• Empire State Building,

• Teatro Amazonas,

• sua casa,

• Cristo Redentor,

• Torre Eifel

!

• Estime a altura dos edifícios:

• Escolha o menor

• Use-o como 1 story point

• Estime todos os outros de forma relativa ao primeiro escolhido

Referências

• Takeuchi, H; Nonaka, I. The new new product development game. Harvard Business Review. P. 137-146, 1986.

• Conference on Object Oriented Programming Systems, Languages and Applications, 1995., Austin. Proceedings…Austin: OOPSLA, 1995.

• Schwaber, K. Agile project management with Scrum. Redmond: Microsoft, 2004.

• Schwaber, K.; Sutherland, J. The Scrum Guide., 2013.

• Métodos Ágeis para Desenvolvimento de Software, Organizadores: Rafael Prikladnicki, Renato Willi e Fabiano Milani. Porto Alegre : Bookman., 2014.

• Roriz, H. Certified Scrum Master Training (Apostila)., 2012.

• Magno, A.. O julgamento do Scrum. Palestra proferida no Agile Brazil 2013.


Scrum

[email protected] !

@tiagosdasilva !

[email protected] !


http://www.slideshare.net/silvadasilva

http://www.speakerdeck.com/silvadasilva



http://www.slideshare.net/silvadasilva

http://www.speakerdeck.com/silvadasilva

Scrum

Documents