Scrum

O SCRUM possui um fluxo de trabalho muito bem definido. Muitos autores afirmam que esse simples fluxo é a essência desse framework e deve ser seguido o mais próximo possível da sua realidade.

Sprint Planning 1

- Estimativas da próxima entrega

- O PO participa

Sprint Planning 2

- Planejamento dentro da equipe

- O PO não precisa participar

Daily SCRUM

- Reunião diária, que engloba:

- O que fiz desde a última Daily SCRUM?

- O que espero fazer até a próxima Daily SCRUM?

- O que está impedindo o progresso?

Sprint Review

- Entrega dos artefatos planejados para este sprint. Importante: Presume-se que antes foi definido que este sprint teria algo “pronto” a ser apresentado.

Sprint Reprospective

- Aprendizado, lições aprendidas, discutir sucessos e erros do sprint.

Vantagens do SCRUM

- Processo bem definido e com time boxing;

- Formação de profissionais auto-gerenciáveis;

- Maior envolvimento do cliente;

- Entregas frequentes;

- Desenvolvimento da equipe (liderança e auto-organização);

- Pessoas responsáveis pelos seus atos: na Daily SCRUM o time indica como está, seus impedimentos e, com o suporte do SCRUM Master, torna-se responsável pela sua entrega acordada;

- Disseminação da prática de retrospectivas ou lições aprendidas: o que erramos no último sprint e o que podemos melhorar nos próximos sprints?;

- Foco no cliente: O time entende que sua tarefa é uma parte em um Sprint e vêem valor agregado no que estão fazendo;

- O cliente também torna-se responsável nas alterações de escopo.

O PRIMEIRO PILAR É A TRANSPARÊNCIA

A transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados.

O SEGUNDO PILAR É A INSPEÇÃO

Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas.

O TERCEIRO PILAR É A ADAPTAÇÃO

Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado.

O Time Scrum é composto pelo ScrumMaster, pelo Product Owner e pelo Time. Os membros do Time Scrum são chamados “porcos”. Qualquer outra pessoa é chamada de “galinha”. “Galinhas” não podem dizer aos “porcos” como eles devem fazer seu trabalho.

O SCRUM MASTER

- O Scrum Master é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras.

- O ScrumMaster ajuda o Time Scrum e a organização a adotarem o Scrum.

- O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade.

- O ScrumMaster ajuda o Time Scrum a entender e usar autogerenciamento e interdisciplinaridade.

- No entanto, o ScrumMaster não gerencia o Time Scrum; o Time Scrum é auto-organizável

O PRODUCT OWNER

- O Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time.

- Essa pessoa mantém o Backlog do Produto e garante que ele está visível para todos.

- Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.

- O Product Owner é uma pessoa, e não um comitê.

- Podem existir comitês que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de um item, terá que convencer o Product Owner.

O TIME

- Times de desenvolvedores transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint.

- Times também são interdisciplinares: membros do Time devem possuir todo o conhecimento necessário para criar um incremento no trabalho.

- Os Times também não contém subtimes dedicados a áreas particulares como testes ou análise de negócios.

- Times também são auto-organizáveis.

- A sinergia que resulta disso melhora a eficiência e eficácia geral do Time como um todo.

- O tamanho ótimo para um Time é de sete pessoas mais ou menos duas pessoas.

- Quando há menos do que cinco membros em um Time, há menor interação e, como resultado, há menor ganho de produtividade.

- Se há mais do que nove membros, há simplesmente a necessidade de muita coordenação.

- Times grandes geram muita complexidade para que um processo empírico consiga gerenciar.

Os Eventos com Duração Fixa (Time-Boxes) no Scrum são a Reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Reunião Diária.

REUNIÃO DE PLANEJAMENTO DA VERSÃO PARA ENTREGA

- O propósito do planejamento da versão para entrega é o de estabelecer um plano e metas que o Time Scrum e o resto da organização possam entender e comunicar.

- O plano da versão para entrega estabelece a meta da versão, as maiores prioridades do Backlog do Produto, os principais riscos e as características gerais e funcionalidades que estarão contidas na versão.

- Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar.

- A organização pode então inspecionar o progresso e fazer mudanças nesse plano da versão para entrega a cada Sprint.

- Os produtos são construídos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco.

- Mais e mais Sprints vão adicionando incrementos ao produto.

- Cada incremento é um pedaço potencialmente entregável do produto completo.

- Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto é entregue.

- Planejamento de versão para entrega requer estimar e priorizar o Backlog do Produto para a Versão.

REUNIÃO DE PLANEJAMENTO DA SPRINT

- A Reunião de Planejamento da Sprint é quando a iteração é planejada.

- É fixada em oito horas de duração para uma Sprint de um mês.

- Para Sprints mais curtas, aloca-se para essa reunião aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes.

- Há duas partes na Reunião de Planejamento da Sprint: a parte do “o quê?” e a parte do “como?”.

1) O Time Scrum trata da questão do “o quê?”.

- Aqui, o Product Owner apresenta ao Time o que é mais prioritário no Backlog do Produto.

- Eles trabalham em conjunto para definir qual funcionalidade deverá ser desenvolvida durante a próxima Sprint.

- As entradas para essa reunião são o Backlog do Produto, o incremento mais recente ao produto, a capacidade do Time e o histórico de desempenho do Time.

- Cabe somente ao Time a decisão de quanto do Backlog ele deve selecionar.

- Uma vez selecionado o Backlog do Produto, a Meta da Sprint é delineada.

- A Meta da Sprint é um objetivo que será atingido através da implementação do Backlog do Produto.

- Ela é uma descrição que fornece orientação ao Time sobre a razão pela qual ele está desenvolvendo o incremento.

- A Meta da Sprint é um subconjunto da Meta da Versão para Entrega.

2) O Time trata a questão do “como?”.

- Durante as quatro horas seguintes da Reunião de Planejamento da Sprint, o Time define como transformará o Backlog do Produto selecionado durante a Reunião de Planejamento (o quê) em um incremento pronto.

- O Time geralmente começa projetando o trabalho.

- Enquanto projeta, o time identifica tarefas.

- Essas tarefas são pedaços detalhados do trabalho necessário para converter o Backlog do Produto em software funcional.

- As tarefas devem ser decompostas para que possam ser feitas em menos de um dia.

- Essa lista de tarefas é chamada de Backlog da Sprint.

- Se o Time concluir que ele tem trabalho demais ou de menos, ele pode renegociar o Backlog do Produto escolhido.

- Geralmente, um Time novo percebe pela primeira vez se irá ganhar ou perder como um Time.

- Conforme ele percebe isso, ele começa a se auto-organizar para assumir as características e comportamento de um verdadeiro Time.

A SPRINT

- A Sprint é uma iteração.

- Sprints são eventos com duração fixa.

- Durante a Sprint, o ScrumMaster garante que não será feita nenhuma mudança que possa afetar a Meta da Sprint.

- Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a Sprint.

- As Sprints contêm e consistem na reunião de Planejamento de Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint.

- As Sprints ocorrem uma após a outra, sem intervalos entre elas.

- Em desenvolvimento de software, o projeto é utilizado para desenvolver um produto ou sistema.

- Cada projeto possui um horizonte, que é o período de tempo para o qual o plano é válido.

- Se o horizonte for longo demais, a definição poderá ter mudado, variáveis demais poderão ter surgido, o risco poderá ser grande demais.

- Scrum é um framework para projetos cujo horizonte não é superior ao período de um mês, onde já há complexidade suficiente tal que um horizonte mais longo seria arriscado demais.

- A previsibilidade do projeto deve ser controlada pelo menos a cada mês, e o risco de que o projeto saia de controle ou se torne imprevisível é contido pelo menos a cada mês.

REVISÃO DA SPRINT- Ao final da Sprint, é feita uma reunião de Revisão da Sprint.

- Para Sprints de um mês, essa é uma reunião com duração fixa em quatro horas.

- Para Sprints de durações mais curtas, essa reunião não deve tomar mais do que 5% do total da Sprint.

- Durante a Revisão da Sprint, o Time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito.

- Baseados nisso e em mudanças no Backlog do Produto feitas durante a Sprint, eles colaboram sobre quais são as próximas coisas que podem ser feitas.

- Essa é uma reunião informal, com a apresentação da funcionalidade, que tem a intenção de promover a colaboração sobre o que fazer em seguida.

A reunião inclui ao menos os seguintes elementos:

- O Product Owner identifica o que foi feito e o que não foi feito.

- O Time discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, além de como esses problemas foram resolvidos.

- O Time então demonstra o trabalho que está pronto e responde a questionamentos.

- O Product Owner então discute o Backlog do Produto da maneira como esse se encontra.

- Ele faz projeções de datas de conclusão prováveis a partir de várias hipóteses de velocidade.

- Em seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relação ao que fazer em seguida.

- A Revisão da Sprint fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.

RETROSPECTIVA DA SPRINT- Após a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, o Time Scrum tem uma reunião de Retrospectiva da Sprint.

- Nessa reunião, com duração fixa em três horas, o ScrumMaster encoraja o Time a revisar, dentro do modelo de trabalho e das práticas do processo do Scrum, seu processo de desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint.

- A finalidade da Retrospectiva é inspecionar como correu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas.

- A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores.

- Isso inclui a composição do time, preparativos para reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para transformar itens do Backlog do Produto em alguma coisa “pronta”.

- No final da Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria factíveis que ele implementará na próxima Sprint.

- Essas mudanças se tornam a adaptação para a inspeção empírica.

REUNIÃO DIÁRIA

- Cada time se encontra diariamente para uma reunião de 15 minutos chamada Reunião Diária.

- Essa reunião é sempre feita no mesmo horário e no mesmo local durante as Sprints.

- Durante a reunião, cada membro explica:

O que ele realizou desde a última reunião diária

O que ele vai fazer antes da próxima reunião diária

Quais obstáculos estão em seu caminho

- As Reuniões Diárias melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto.

- O ScrumMaster garante que o Time realize essa reunião.

- O Time é resposável por conduzir a Reunião Diária.

- O ScrumMaster ensina o time a manter a Reunião Diária com curta duração, reforçando as regras e garantido que as pessoas falem brevemente.

- O ScrumMaster também enfatiza a regra de que galinhas não estão autorizadas a falar e nem a interferir de modo algum na Reunião Diária.

- A Reunião Diária não é uma reunião de status.

- Ela é só para as pessoas que estão transformando os itens do Backlog do Produto em um incremento (o Time).

- A Reunião Diária é uma inspeção do progresso na direção da Meta da Sprint (as três perguntas).

- A intenção é otimizar a probabilidade de que o Time alcance sua Meta.

- Essa é uma reunião fundamental de inspeção e adaptação no processo empírico do Scrum.

Os artefatos do Scrum incluem o Backlog do Produto, o Burndown da Versão para Entrega, o Backlog da Sprint e o Burndown da Sprint.

BACKLOG DO PRODUTO E BURNDOWN DA VERSÃO PARA ENTREGA

- Os requisitos para o produto que o(s) Time(s) está(ão) desenvolvendo estão listados no Backlog do Produto.

- O Product Owner é o responsável pelo Backlog do Produto, por seu conteúdo, por sua disponibilidade e por sua priorização.

- A seleção inicial para o seu desenvolvimento somente mostra os requisitos inicialmente conhecidos e melhor entendidos.

- O Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil.

- Enquanto existir um produto, o Backlog de Produto também existirá.

- O Backlog do Produto representa tudo que é necessário para desenvolver e lançar um produto de sucesso.

- É uma lista de todas as características, funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto para versões futuras.

- Os itens do Backlog do Produto possuem os atributos de descrição, prioridade e estimativa.

- A prioridade é determinada por risco, valor e necessidade.

- O Backlog do Produto é ordenado por prioridade.

- Quanto mais alta sua prioridade, mais urgente ele é, mais se pensou sobre ele e há mais consenso no que diz respeito ao seu valor.

- O Backlog de mais alta prioridade é mais claro e possui mais informações detalhadas do que o Backlog de prioridade mais baixa.

- Quanto mais baixa a prioridade, menor é o nível de detalhe, até que mal se consiga entender o item.

- Os requisitos nunca param de mudar.

- Mudanças nos requisitos de negócios, condições do mercado, tecnologia e equipe causam mudanças no Backlog do Produto.

- Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados.

- O gráfico de Burndown da Versão para Entrega registra a soma das estimativas dos esforços restantes do Backlog do Produto ao longo do tempo.

- O esforço estimado deve estar em qualquer unidade de medida de trabalho que o Time Scrum e a organização tenham decidido usar.

- As unidades de tempo geralmente são Sprints.

- O Time é responsável por todas as estimativas.

- O Product Owner mantém o Backlog do Produto e o Burndown do Backlog da Versão para Entrega atualizados e publicados todo o tempo.

BACKLOG DA SPRINT E BURNDOWN DA SPRINT

- O Backlog da Sprint consiste nas tarefas que o time executa para transformar itens do Backlog do Produto em um incremento “pronto”.

- Muitas delas são elaboradas durante a Reunião de Planejamento da Sprint.

- O Backlog da Sprint é todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint.

- Os itens do Backlog da Sprint devem ser decompostos.

- A decomposição deve ser suficiente para que mudanças no progresso possam ser entendidas na Reunião Diária.

- O Time modifica o Backlog da Sprint no decorrer da Sprint, bem como surge Backlog da Sprint durante a Sprint.

- Quando chega às tarefas individuais, o Time pode descobrir que mais ou menos tarefas serão necessárias.

- À medida que novo trabalho surge, o Time o adiciona ao Backlog da Sprint.

- À medida que se trabalha nas tarefas ou que elas são completadas, as horas estimadas de trabalho restantes para cada tarefa são atualizadas.

- Quando se verifica que determinadas tarefas são desnecessárias, elas são removidas.

- Somente o Time pode modificar o seu Backlog da Sprint durante uma Sprint.

- Somente o Time pode mudar o seu conteúdo ou as suas estimativas.

- O Backlog da Sprint é um retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante a Sprint, e ele pertence unicamente ao Time.

- O Burndown do Backlog da Sprint é um gráfico da quantidade restante de trabalho do Backlog da Sprint em uma determinada Sprint ao longo do tempo da Sprint.

- Para criar esse gráfico, determine quanto trabalho resta somando as estimativas do Backlog a cada dia da Sprint.

- A quantidade de trabalho restante para uma Sprint é a soma do trabalho restante para tudo do Backlog da Sprint.

- Acompanhe essas somas diariamente e utilize-as para criar um gráfico que mostre o trabalho restante ao longo do tempo.

- Traçando uma linha através dos pontos no gráfico, o Time pode gerenciar seu progresso em completar o trabalho de uma Sprint.

- A duração não é considerada em Scrum.

- O trabalho restante e a data são as únicas variáveis de interesse.

Como fazemos product backlogs

- O product backlog é o coração do Scrum.

- O product backlog é basicamente uma lista de requisitos, estórias, coisas que o cliente deseja, descritas utilizando a terminologia do cliente

- Deve conter uma descrição, valor, prioridade, estimativa e um resumo.

Como nos preparamos para o planejamento do sprint

- Tenha certeza de que o product backlog está organizado e fechado antes da reunião de planejamento do sprint.

Como planejamos sprint

- O planejamento de sprint é uma reunião crítica, provavelmente o evento mais importante no Scrum.

- Um encontro de planejamento de sprint mal feito pode bagunçar totalmente um sprint.

- O propósito da reunião de planejamento do sprint é dar à equipe informação suficiente para trabalharem em paz por algumas semanas, e para dar ao product owner confiança suficiente para deixá-los fazerem isto.

Resultado

- Um objetivo de sprint.

- Uma lista de membros da equipe (e seus níveis de comprometimento, se não 100%).

- Um sprint backlog (= uma lista de estórias inclusas no sprint). - Uma data definida para a apresentação do sprint.

- Data e local definidos para a reunião diária

Definindo o tamanho do sprint

- sprints curtos são bons. Eles permitem que a equipe seja “ágil”, isto é, mude de direção freqüentemente. Sprints curtos = ciclo curto de feedback = entregas mais freqüentes = feedback mais freqüente do cliente = menos tempo perdido, indo na direção errada = aprender e melhorar rápido, etc.

- sprints longos são bons também. A equipe tem mais tempo para ganhar ritmo, ela tem mais espaço para se recuperar dos problemas, e conseguir atingir o objetivo do sprint, você tem menos overhead em termos de reuniões de planejamento, apresentações, etc.

Estimativa de tempo usando planning poker

- Dividindo estórias em tarefas

- Estórias são trabalhos que podem ser entregues e que o product owner tem que se preocupar.

- Tarefas são atividades que não podem ser entregues, ou atividades que o product owner não precisa se preocupar.

Por que insistimos que todos os sprints terminem com uma apresentação

- Uma apresentação de sprint bem feita, apesar disso poder parecer dramático, tem um efeito profundo.

- A equipe ganha crédito por suas realizações. Eles se sentem bem.

- Outros aprendem o que sua equipe está fazendo.

- A apresentação atrai feedback vital dos stakeholders.

- Apresentações são (ou deveriam ser) um evento social onde equipes diferentes podem interagir umas com as outras e discutir seu trabalho. Isso tem muito valor.

- Fazer uma apresentação força a equipe a realmente terminar as coisas e liberá-las (mesmo que seja apenas em um ambiente de teste).

- Com apresentações nós podemos ter menos itens prontos, mas estes itens estarão realmente prontos, o que é muito melhor do que termos uma pilha inteira de coisas que estão apenas parcialmente prontas e que irão poluir o próximo sprint.

Exemplos de coisas que podem aparecer durante as retrospectivas

- “Nós deveríamos ter gasto mais tempo quebrando as estórias em sub-itens e tarefas”

- “Interferências externas demais”

- “Nós nos comprometemos com coisas demais e só metade está pronta”

- “Nosso ambiente é barulhento e bagunçado demais”

Como combinamos Scrum e XP

- Programação em par

- Desenvolvimento Orientado a Testes (TDD)

- Design incremental

- Integração contínua

- Propriedade coletiva do código

- Ambiente de trabalho informativo

- Padrão de codificação

- Ritmo Sustentável / Trabalho energizado

Construção de um software para gerenciamento de redes sociais.

Problema: o nosso cliente (pj) tem muitas redes sociais como twitter, facebook, orkut, google+, linkedin, flickr, foursquare, entre outras, mas tem dificuldades em gerencia-las (login, painel único de leitura, notificação em emails (vários), relatórios de acesso (dos visitantes), tempo em que permanece nas redes, retorno que tem das redes, gráfico de trend, informações relevantes.

Construa um protótipo em papel para resolver esse problema em

1 release [01:30]

2 sprints

** Devem-se usar as práticas de Scrum!

Bibliografia Inicial:

- Guia do Scrum

- Scrum e XP Direto das Trincheiras

Quarta Iteração - Hands On!

Everton Gomede

http://evertongomede.blogspot.com

evertongomede@gmail.com

Terceira Iteração - Como Fazemos?

08:30 - 10:00 -> 1it (Visão Geral)

10:30 - 12:00 -> 2it (Detalhes)

13:30 - 15:00 -> 3it (Como Fazemos?)

15:30 - 17:00 -> 4it (Hands On!)

51 slides -> ~5 minutos/slide

ARTEFATOS DO SCRUM

Segunda Iteração - Detalhes

TEORIA DO SCRUM

Scrum, que é fundamentado na teoria de controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.

PAPÉIS NO SCRUM

TIME-BOXES

Primeira Iteração - Visão Geral

Definições

O Time

- Product Owner: Criar e compartilhar uma visão projeto, tomar decisões sobre os itens do product backlog, indicar e priorizar itens de backlog, validar a entrega no final do sprint;

- Time: Estimar os itens do backlog, desenvolver (programar), auto-organizados para entregar o que o Product Owner quer;

- Scrum Master: Contato direto com o Product Owner, cuidar do time, disseminar o SCRUM, garantir comunicação e evitar impedimentos.

SCRUM é um framework iterativo e incremental para o desenvolvimento de projetos e utilizado desde 1990. O seu objetivo é entregar o máximo de valor de negócio no menor tempo.

O SCRUM tem como foco o PDCA (Plan, Do, Check, Act), resultando na melhoria contínua.

Inicialmente, ele foi concebido para utilização em projetos de software, que possuem algumas características, tais como:

- São empíricos: complexos, caóticos, com detalhes pouco conhecidos;

- Difícil estimativa de tempo de duração das atividades;

- Os requisitos mudam constantemente.

No SCRUM, existe uma lista com os requisitos identificados pelo cliente chamada de Product Backlog. Esta lista é alimentada continuamente pelo cliente em conjunto com o Product Owner e reflete os trabalhos pendentes do time.

O Fluxo do SCRUM

SCRUM

Framework iterativo e incremental para o desenvolvimento de projetos