SCRUM, O Tutorial®

O Tutorial

www.etcnologia.com.br

Rildo F Santos
(11) 9123-5358 (11) 9962-4260
rildo.santos@etecnologia.com.br twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

Conteúdo:

SCRUM, O Tutorial®

1 – Desafios do desenvolvimento de Software 2 – Sobre o SCRUM

3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

2

Objetivo:

SCRUM, O Tutorial®

Objetivo: O Scrum é um Método Ágil para execução de qualquer projeto ou trabalho.
O Objetivo deste Tutorial é prover conhecimento, apresentar e discutir o SCRUM e suas práticas aplicadas a projetos de desenvolvimento de software.

Pré-requisito: Não há.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

3

Programa: “Menos Papel, Mais Árvores ®”

SCRUM, O Tutorial®

Qual é o mundo que queremos ? O primeiro passo para criar um mundo melhor, é saber qual tipo de mundo que queremos ter e qual tipo que deixaremos de herança para as próximas gerações. Nossa missão: É buscar pelo equilíbrio do homem, da tecnologia e do meio ambiente. Para cumprir esta missão é necessário: conscientizar, comprometer e AGIR.

O programa Menos Papel, Mais Árvores®, é uma ação, com objetivo de estimular o consumo sustentável de papel dentro das organizações.
Quer participar ? - Reduza o uso de papel (e de madeira) o máximo possível. - Só imprima se for extremamente necessário. - Evite comprar produtos com excesso de embalagem. - Ao imprimir ou escrever, utilize os dois lados do papel. - Use papel reciclado.
Este material não deve ser impresso..
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

4

Facilitador: Rildo F. Santos (@rildosan)
Coach , Instrutor, Consultor e Palestrante de Métodos Ágeis, Gestão de Negócios, Inovação , Processos e Tecnologia . Minha Experiência: Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Sou formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade Mackenzie.

Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM).

SCRUM, O Tutorial®

Conheço Métodos Ágeis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA. Tenho conhecimento de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI; Experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Fluência nos principais frameworks e padrões: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999; Participei de diversos projetos nos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás. Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International Institute of Business Analysis (Canada) Onde estou: Twitter: @rildosan Blog: http://rildosan.blogspot.com/ Comunidade: http://etecnologia.ning.com

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

5

Conteúdo:

SCRUM, O Tutorial®

1 – Desafios do desenvolvimento de Software 2 – Sobre o SCRUM

3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

6

Objetivo:

SCRUM, O Tutorial®
Parte 1 - Desafios do desenvolvimento de Software Objetivo: Apresentar e discutir os principais desafios dos projetos de desenvolvimento de software. Pré-requisito: Não há.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

7

SCRUM, O Tutorial®

Desafios do Desenvolvimento de Software
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

8

1º. Desafio: Responder ao cliente Quanto tempo vai levar ? O tempo é outro grande desafio, é raro (posso até afirmar que não existe) um cliente que diga: “Demore o tempo que for necessário, pois, não temos pressa nenhuma”. Geralmente o cliente quer o software funcionando Para ontem... Quanto custará ? Todo cliente quer saber quanto custará o software...
O primeiro desafio é conseguir responder qual é o custo do software e em quanto tempo o cliente vai ter o software funcionando.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

9

2º. Desafio: Falha na Comunicação das equipes de TI

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

10

3º. Desafio: Entender as necessidades dos clientes

SCRUM, O Tutorial®
Quando não se entende as necessidades dos clientes, não se pode entregar valor ao cliente.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

11

4º. Desafio: Compreender por que os projetos falham:

Informação errada 13%

SCRUM, O Tutorial®

Requisitos incompletos 12%

Outros 50%

Mudança de Requisitos 12% Falta de conhecimento técnico 7%

37% das falhas estão relacionadas com requisitos

Falta de competência 6%

Craig Larman, Agile and Iterative Development: A Manager’s Guide, Addison Wesley Professional (2004)

12
Todos os direitos reservados e protegidos © 2006 e 2010

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

12

5º. Desafio: Identificar o que é necessidade e o que é desejo Uso de funcionalidades do Software
Contudo, a maioria das funcionalidades nunca são usadas pelos usuários
Sempre 7% Nunca 45%

Freqüentemente 13%

SCRUM, O Tutorial®

As vezes 16% Raramente 19%

Craig Larman, Agile and Iterative Development: A Manager’s Guide, Addison Wesley Professional (2004)

13
Todos os direitos reservados e protegidos © 2006 e 2010

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

13

6º. Desafio: Aumentar produtividade da equipe de desenvolvimento: Satisfação dos Clientes

SCRUM, O Tutorial®

Como aumentar a produtividade da equipe de desenvolvimento de software ?

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

14

A falta de produtividade pode afetar o negócio
Qual é a solução ? Contratar mais desenvolvedores... Mas, será que a contratação de novas pessoas garante o aumento de produtividade ?

SCRUM, O Tutorial®

The Mythical Man Month by Frederick Brooks, 1975*. Quando um projeto está atrasado, contratar novas pessoas para ajudar no projeto pode servir apenas para atrasá-lo ainda mais. Pois, as novas pessoas precisam primeiro entender o que é projeto, objetivos, escopo, funcionalidades e etc, para depois começar a produzir, ou seja, temos que considerar o tempo que será gasto com explicações, orientações, comunicação e treinamento das novas pessoas, devemos considerar o esforço da gestão de projetos que aumentará Ao calcular o tempo que será necessário para desenvolver um software, temos que adicionar um tempo extra, pois os desenvolvedores precisam de "tempo para pensar“, “tempo para pesquisar” além do "tempo para desenvolver" "Adicionar novas pessoas a um projeto de software atrasado só adiará a sua entrega." – A Lei de Brooks
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

15

7º. Desafio: Escolher framework certo para desenvolver software ?

UP

SCRUM, O Tutorial®

SCRUM, Lean, ASD, XP, FDD...

RUP

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

16

8º. Desafio: Como reter os bons profissionais ?
Quantas vezes já montamos boas equipe, mas de repente as pessoas começam a sair...a trocar de emprego. A retenção de bons profissionais é grande desafio da atualidade, pessoas trocam muito mais de emprego do que a 10 anos atrás. Insegurança, chefes tiranos, a falta de respeito, falta de reconhecimento e de e ambiente “estressante” são as algumas das causas que fazem os profissionais de trocarem de emprego. A maioria das pessoas mudam de emprego por problema com o seu chefe e não por motivo de salário.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

17

Por que precisamos dos Métodos Ágeis ?
Problemas clássicos (ou tradicionais): Stakeholders (Clientes): - Têm dificuldades em externar suas necessidades - Geralmente fazem mudanças de requisitos - Precisam do software funcionando para ontem Desenvolvedores: - Não sabem ou não querem elicitar requisitos - Dificilmente conseguem atender todas as demandas de negócio - Tem dificuldade em comunicar e entender os clientes

SCRUM, O Tutorial®

Para enfrentar estes desafios:

Utilização de métodos ágeis, como SCRUM, pode amenizar estes problemas.

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

18

Cliente x Desenvolvedores:
Clientes: - Alguns clientes têm dificuldades em externar suas necessidades ou desejos de forma clara e objetiva (Não sabem o que querem) - Geralmente fazem mudanças de requisitos durante o desenvolvimento ou quando o software é entregue.

SCRUM, O Tutorial®

- Sempre precisam do software funcionando para ontem
- Não têm tempo e nem paciência para falar com os desenvolvedores.

Desenvolvedores: - Não sabem ou não querem conversar com o cliente
- Dificilmente conseguem atender o negócio e todas suas demandas

- Têm dificuldade em se comunicar e entender os clientes

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

19

Como enfrentar estes desafios: “O SCRUM é sua sogra”
O SCRUm pode ser uma forma para enfrentar estes desafios, O SCRUM não vai aumentar a produtividade da equipe, não vai fazer você entregar software mais cedo, nem melhorar a qualidade do software e nem otimizar os custos do projeto de desenvolvimento. O “SCRUM é como sua SOGRA” ele vai apontar os principais problemas, falhas e pontos críticos (riscos) do projeto de desenvolvimento, aquilo que realmente precisa ser melhorado, mas se as pessoas envolvidas com o projeto não tomarem nenhuma ação (ou melhor: tomarem atitudes) os problemas continuaram a existir e levaram a maioria dos projetos para a “marcha da morte”. O Scrum vai deixar todos os problemas aparentes.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

20

Se trabalhamos com desenvolvimento Ágil:
Logo temos: Colaboração com cliente: A estória do Usuário é escrita em colaboração entre os desenvolvedores e o cliente (PO). A prioridade é satisfazer o cliente, entregando o mais rápido possível e de forma contínua software que tenha valor: Para satisfazer o cliente é preciso entendê-lo. A estória ajuda a melhorar o entendimento da necessidade do cliente para que ocorra a entrega de valor. - Conversa face-a-face é SEMPRE a melhor forma de comunicação: A estória do usuário geralmente é feita na Reunião de Planejamento (Planning Meeting).

SCRUM, O Tutorial®

Aqui entra a Estória do Usuário:
Titulo: Pagamento com Cartão de Crédito Prioridade: Alta

Como cliente de negócio eu gostaria de fazer pagamento com Cartão de Crédito para minha comodidade.

Pontos: 5

A Estória de Usuário é uma “ferramenta” simples que pode ajudar. Uma Estória de Usuário nada mais é que um cartão com algumas frases, escrita pelo cliente e desenvolveres em linguagem comum, sobre algo que o software deve fazer.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

21

Exercícios:
1- É possível entregar valor ao cliente (software funcionado, segundo o Manifesto Ágil), sem entender a necessidade dele ?

SCRUM, O Tutorial®

2 – Por que a especificação de requisitos de software não é solução para os problemas de comunicação ?

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

22

Conteúdo:

SCRUM, O Tutorial®

1 – Desafios do desenvolvimento de Software 2 – Sobre o SCRUM

3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

23

Objetivo:

SCRUM, O Tutorial®
Parte 2 – Sobre SCRUM: Objetivo: Apresentar Manifesto Ágil e o SCRUM, as principais características e práticas. Pré-requisito: Não há.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

24

Parte 2

SCRUM, O Tutorial®

Sobre o SCRUM
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

25

As Raízes do Scrum:
TimeBoxes Artigo: “The New, New Product Development Game de Nonaka e Takeushi na Hardvard Bussines Review Desenvolvimento iterativo e incremental

SCRUM, O Tutorial®

SmallTalk Engineering Tools

Reunião diária 24 horas

Produto Backlog

Sprint Backlog Produto 2-4 Semanas

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

26

O que é TimeBox ?
É duração fixa (imutável). É um conceito diz que a quantidade de tempo é imutável, ou seja, tem duração fixa - a quantidade de dias não poderá aumentar. Assim, evita-se atrasos no prazo de entrega e facilita o planejamento. No Scrum as cerimônias e/ou eventos com duração fixa (Time-Boxes) são: - Reunião de Planejamento da Release, - Sprint (iteração), - Reunião de Planejamento da Sprint, - Revisão da Sprint. - Retrospectiva da Sprint. - Reunião Diária. Exemplos de Timebox: A Sprint (que é uma iteração) que deve ser realizada de 2 a 4 semanas, no qual a equipe de desenvolvedores deverá produzir um entregável de valor para o cliente (mais frente discutiremos melhor isto). A entrega de valor é a meta da Sprint, a duração da Sprint deverá ser combinada com o cliente, antes do começo da execução da Sprint. Se foi acertado que a Sprint tem a duração de 4 semanas, logo esta duração será fixa (não mudará). Durante a Sprint são realizadas as Reuniões Diárias, uma reunião diária tem a duração fixa de 15 minutos. Ao final da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints de um mês, essa é uma reunião com duração fixa de quatro horas. Após a Revisão da Sprint e antes da próxima Reunião de Planejamento da Sprint, a Equipe Scrum tem a Reunião de Retrospectiva da Sprint. essa reunião, te duração fixa de três horas.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

27

Abordagem Iterativo e Incremental:
Entrega 1 Entrega 2 Entrega 3

Incremental

SCRUM, O Tutorial®

Iterativo

Devido a complexidade, tamanho, mudanças de requisitos, urgência e necessidade de demonstrar valor mais rápido, fica quase inconcebível desenvolver software utilizando o modelo cascata, ou seja, desenvolver todo o software em uma única vez. Desenvolvimento Iterativo e incremental é uma estratégia de planejamento (que segue a linha dividir para conquistar) , onde o software é construído em partes, ou seja, em ciclos (iterações), a cada iteração é feito um novo incremento (uma parte do software funcional) até completar o software.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

28

O qual é propósito do SCRUM ?
Scrum vem sendo utilizado para o desenvolvimento de produtos complexos desde o início dos anos 90.

Scrum não é um “processo “ ou uma “técnica “ para o desenvolvimento de produtos.
Ao invés disso, é um framework dentro do qual você pode empregar diversos processos e técnicas. O papel do Scrum é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê um framework dentro do qual produtos complexos podem ser desenvolvidos.

SCRUM, O Tutorial®

Por ser um framework, o SCRUM não é uma ferramenta, nem metodologia, nem processo e nem uma solução completa para o desenvolvimento de software, ele é um framework (uma estrutura), ou seja um “guia de referência” , isto significa que o “Scrum não vai lhe dizer como fazer as coisas! “ Por ser um framework, ele pode ser utilizado com as práticas de engenharia de software e/ou metodologia de desenvolvimento que já existem dentro da organização. O SCRUM pode ser utilizado para desenvolver qualquer produto e não só software.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

29

Qual é a teoria do SCRUM ?
A 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 O que são processos empíricos ? Antes de responder a pergunta, precisamos saber que existem dois tipos de processos: Processo Definido: São processos que se conhece todas as variáveis, têm poucas ou nenhuma mudança ao logo do processo, são repetitivos e são previsíveis. Geralmente existe uma documentação aplicada a execução do processo. Exemplo: Linha de produção

SCRUM, O Tutorial®

*Processos Empíricos: São aqueles processos que não se conhece todas as variáveis, têm mudanças ao logo do processo, não são repetitivos e são imprevisíveis. Geralmente baseado na experiência e no conhecimento de quem executa o processo. Exemplo: Desenvolvimento de Software. Quando desenvolvemos um software as vezes não conhecemos todos os requisitos, e os requisitos que são conhecidos mudam com certa frequência e geralmente todas as estimavas são feitas baseada no conhecimento das pessoas, isto quer dizer, que o mesmo trabalho feito por equipes diferentes a duração pode variar, pois, a equipe mais experiente deve realizar o trabalho mais rápido do que a equipe menos experiente. Isso porque o desenvolvimento de software é um problema complexo, que se comporta de forma imprevisível.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

30

Os pilares do SCRUM:
Três pilares sustentam qualquer implementação de controle de processos empíricos.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

31

Os pilares do SCRUM:
Três pilares sustentam qualquer implementação de controle de processos empíricos.

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

SCRUM, O Tutorial®

Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que algo está “pronto”, isso deve ser equivalente à definição de “pronto” utilizada. O segundo pilar:

Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção. O problema acontece quando a frequência de inspeção necessária excede a tolerância do processo à inspeção. Os outros fatores são a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho.

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

32

Os pilares do SCRUM:
Três pilares sustentam qualquer implementação de controle de processos empíricos. O terceiro pilar: 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. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.

SCRUM, O Tutorial®

1

3

2

4

Existem três pontos para inspeção e adaptação em Scrum. A Reunião Diária (2) é utilizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho. Além disso, as reuniões de Revisão da Sprint (3) e de Planejamento da Sprint (1) são utilizadas para inspecionar o progresso em direção à Meta da Release e para fazer as adaptações que otimizem o valor da próxima Sprint. E a Retrospectiva da Sprint (4) é utilizada para revisar a Sprint passada e estabelecer que adaptações tornarão a próxima Sprint mais eficiente, produtiva, recompensadora e gratificante.
Todos os direitos reservados e protegidos © 2006 e 2010

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

33

O Manifesto Ágil:

SCRUM, O Tutorial®

O SCRUM é um Metodo Ágil
Fonte: http://agilemanifesto.org/iso/ptbr/

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

34

Princípios por trás do Manifesto Ágil:
Nós seguimos estes princípios:
 Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.  Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.  Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.  Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à

SCRUM, O Tutorial®

menor escala de tempo.  Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.  Construa projetos em torno de indivíduos motivados.  Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.  O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.  Software funcionando é a medida primária de progresso.  Os processos ágeis promovem desenvolvimento sustentável.  Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.  Contínua atenção à excelência técnica e bom design aumenta a agilidade.  Simplicidade -- a arte de maximizar a quantidade de trabalho não realizado -- é essencial.  As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.  Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

35

Como Ser Ágil ?
Como ser ágil ? 1 - Para “ser ágil” é preciso colocar em prática os valores e os princípios do Manifesto Ágil.

Exemplo:
Se uma organização implementou o SCRUM e aparentemente tudo ocorre bem...mas, se equipe não está conseguindo entregar “software funcionando” ao cliente a quatro meses, podemos afirmar que existe uma equipe ágil ? Vejamos o que diz o Manifesto Ágil: “Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.” Podemos concluir que a equipe não é ágil, pois além da implementação do SCRUM, que é um método ágil, ela também deverá levar em conta os valores e princípios do Manifesto Ágil, ou seja, entregar software funcionando com certa regularidade.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

36

Como Ser Ágil ?
Como ser ágil ? 2 – Além de implementar o SCRUM para Gestão de Projetos de desenvolvimento de software também adote práticas de Engenharia de Software Ágil, tais como XP e FDD.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

37

Como Ser Ágil ?

SCRUM, O Tutorial®
Engenharia de Software 100% “Ágil: O SCRUM é utilizado para Gestão de Projetos. Já para as práticas de Engenharia de Software podemos utilizar o FDD para os requisitos de software e arquitetura e as Práticas do XP para o desenvolvimento de software (codificação, testes e refactoring).
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

38

Equipe: Tradicional x Colaborativa
Como ser ágil ? 3 – Para trabalhar como o SCRUM é preciso trabalhar em equipe: Existem alguns tipos de equipe, vamos comparar o formato Tradicional e de auto Gestão: Tradicional auto Gestão

SCRUM, O Tutorial®

Método de Gestão de Projetos Tradicionais. - Não tem auto gestão. - Não são auto-organizadas. - São fortemente hierarquizada. Com liderança baseada no “comando-controle”. - Equipe formada por especialistas.

Método Ágil - ter auto gestão, - ser Auto organizada; - ser Interdisciplinar - não ter Hierarquia formal, - ter responsabilidade.

O Comando-controle: Pode levar ao baixo A auto gestão: Requer alto comprometimento da comprometimento e desmotivação é sinônimo de equipe, que é a chave para a produtividade. Equipe baixa produtividade e produtos de baixa qualidade. motivada produz mais e melhor.

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

39

As Características da Equipe:
Como ser ágil ? 3 – Para trabalhar como o SCRUM é preciso trabalhar em equipe: Auto Gestão e Auto-organização: A equipe possui a auto gestão e é auto-organizada. Não deve haver interferência externa, nem o ScrumMaster ou Product Owner - pode dizer como a equipe deve se organizar ou fazer inferência na forma de trabalho da equipe. A equipe deve ser capaz de se auto-organizar para dividir e fazer trabalho. Equipe de desenvolvedores é muito parecida com um equipe de Volley Ball, onde todos tem um único objetivo e são interdisciplinares no jogo. Interdisciplinares e Sem hierarquia formal: Equipes também são interdisciplinares: os membros da equipe devem ter todo o conhecimento e habilidades necessárias para entregar a meta da Sprint. Membros da equipe geralmente possuem conhecimentos especializados, tais como: programação, testes, controle de qualidade, análise de negócios, arquitetura, desenho de interface de usuário e modelagem de dados. No entanto, o conhecimento que os membros devem compartilhar - isto é, a habilidade de trabalhar um item do Product Backlog (ou um requisito) e transformá-lo em um produto (software funcionando) tendem a ser mais significativas do que aqueles que eles não dividem. As pessoas que se recusam a programar porque são arquitetas ou designers não se adaptam bem a equipe. Todos devem contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas. Na equipe não há hierarquia nem títulos, todos são iguais e não há exceções a essa regra. As equipes também não devem ter sub-equipe dedicados a áreas particulares como testes, banco de dados ou análise de negócios. Responsabilidade: A equipe de desenvolvedores é responsável transformar os itens do Product Backlog em funcionalidades potencialmente entregáveis a cada Sprint.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

40

Reforçando: “Não existe a Bala de Prata”
SCRUM não é a Bala de Prata:
O SCRUM não é a solução completa para os problemas de produtividade, complexidade, custo, prazo e qualidade do processo de desenvolvimento de software.
Veja Lei F. Brooks, Não existe bala de prata

SCRUM, O Tutorial®

“Não existe solução mágica para problemas complexos”
Contudo, você pode utilizar o SCRUM para: - SCRUM é ideal para desenvolvimento de software complexos onde os requisitos mudam rapidamente; - SCRUM é método ágil para gerenciar e controlar desenvolvimento de trabalho; - SCRUM possibilita que você utilize as praticas de engenharia existentes e que já são conhecidas; - SCRUM é baseado na abordagem interativa e incremental; - Equipe de desenvolvedores (ou time) deve ter auto gestão; - SCRUM é o caminho para detectar e causa raiz e a remoção de qualquer coisa que esteja impedindo o desenvolvimento e/ou entrega de software/produtos; - SCRUM é o caminho para maximizar a produtividade; - SCRUM vai dá transparência ao processo de desenvolvimento de software.

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

41

Algumas empresas que estão usando SCRUM:

SCRUM, O Tutorial®

Quais empresas estão utilizando o SCRUM?

Algumas empresas brasileiras

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

42

Exercício
Leia o texto e complete a lacuna (no último paragrafo): O processo de captação de talentos no futebol:
Baseado no texto do Fabrício Moreira*

SCRUM, O Tutorial®

Um dos aspectos mais importantes dos grandes clubes de futebol está relacionado à captação de talentos para compor suas categorias de base, e posteriormente formar esses atletas para ingressarem no profissional. Para entendermos melhor os caminhos atualmente traçados por esses candidatos a futuros atletas de futebol precisamos analisar as formas que costumam chegar esses garotos até os clubes brasileiros e iniciar os seus treinamentos junto às equipes de base. Considerando que hoje esse processo de detecção difere em muito daqueles praticados anteriormente, e que cada vez mais, tem se tornado precoce e competitivo, em que a concorrência chega a ser absurda. Se pudéssemos ter acesso aos números de garotos avaliados anualmente nos grandes clubes em relação aos selecionados, chegaríamos certamente a esta conclusão. O objetivo deste texto é relatar os diversos mecanismos de captação de talentos em prática nos grandes clubes do futebol profissional brasileiro. Dentre os mecanismos, destacamos cinco principais e dois secundários. Podemos destacar alguns dos principais: as avaliações “peneiras”; campeonatos e jogos amistosos; indicações; escolas licenciadas “franquias” e os observadores técnicos. Entre as secundárias, destacamos: as clínicas de futebol e o intercâmbio internacional. As chamadas “peneiras” são um dos mecanismos mais conhecidos e utilizados no meio do futebol. Porém, é um processo ___________________, baseado na observação dos treinadores em uma única situação (muitas vezes apenas de jogo e de curta duração). Neste caso, muitos clubes pré-selecionam alguns garotos para continuarem os testes por pelo menos uma semana no clube, ou mais um dia, no mínimo.
http://www.universidadedofutebol.com.br/2010/07/1,14757,UM+RELATO+SOBRE+O+PROCESSO+DE+CAPTACAO+DE+TALENTOS+NO+FUTEBOL.aspx?p=1

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

43

Conteúdo:

SCRUM, O Tutorial®

1 – Desafios do desenvolvimento de Software 2 – Sobre o SCRUM

3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

44

Objetivo:

SCRUM, O Tutorial®
Parte 3 – Entendendo SCRUM Objetivo: Apresentar de forma detalhada o framework SCRUM segundo o Guia do Scrum. Pré-requisito: Não há.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

45

Parte 3

SCRUM, O Tutorial®

Entendendo o SCRUM
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

46

Framework Scrum:
O framework Scrum é formado por um conjunto pela Equipe (Time) Scrum e seus papéis: Product Owner (PO), Scrum Master (SM) e equipe de desenvolvedores, eventos com duração Fixa (TimeBoxes), artefatos e regras.
Reunião diária Revisão da Sprint

Planejamento da Sprint

Retrospectiva da Sprint

SCRUM, O Tutorial®

24 horas Visão Produto Backlog Sprint Backlog Produto 2-4 Semanas

Legenda: Reuniões Artefatos

Eventos (Reuniões)
Papéis Artefatos  Planejamento da Release  Planejamento da Sprint  Diária  Revisão da Sprint  Retrospectiva da Sprint • Product Backlog • Sprint Backlog • Sprint Burndown • Release Burndown

• Product Owner (PO) • ScrumMaster (SM) • Equipe Scrum

Sprint Burndown Release Burndown

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

47

Framework Scrum: Eventos de Duração Fixa:

SCRUM, O Tutorial®

Regras
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

48

Framework Scrum: Regras
As Regras fazem o elo entre os eventos com duração fixa (time-boxes), os papéis e os artefatos do Scrum. As regras são descritas ao longo desta apresentação. Alguns exemplos de Regras: - Somente os membros da equipe de desenvolvimento podem falar durante uma Reunião Diária. - Equipe deve possuir auto-gestão.; - Somente o PO (Product Owner) definir e alterar a prioridade dos itens do Product Backlog. - Uma pessoa não pode desempenhar o papel de PO e de Scrum Master no mesmo projeto. - Somente o PO pode cancelar uma Sprint.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

49

Framework Scrum: Papéis e Equipe

SCRUM, O Tutorial®

Papéis e Equipe
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

50

Papéis SCRUM: Papéis
Equipe Scrum são projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são auto-organizáveis, interdisciplinares e trabalham em iterações. Cada equipe possui três papéis: Product Owner (PO), que é responsável por maximizar o valor do trabalho que a equipe faz, PO também é responsável por: - Definir a Visão do Produto - Elaborar , Priorizar e manter o Product Backlog - Definir ROI; - Representar o cliente - Aceitar ou rejeitar os entregáveis O ScrumMaster, que é responsável por garantir que o processo (as práticas do SCRUM) seja compreendido e seguido. É responsável ainda por: - Remover impedimentos; - Proteger a equipe; - Ajudar o PO (quando necessário); - Ser o facilitador da equipe. A equipe (ou time), é responsável pelo desenvolvimento do produto, é formada por desenvolvedores que devem ter as habilidades necessárias para transformar os itens do Product Backlog em Produto. A Equipe ainda é responsável por: -Fazer estimativa; - Definir as tarefas; - Garantir a qualidade do produto; - Apresentar o produto ao cliente
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

51

A Equipe SCRUM: ScrumMaster (SM) e Product Owner (PO):
O ScrumMaster é responsável por garantir que o Equipe Scrum esteja aderindo aos valores do Scrum, às práticas e às regras. O ScrumMaster ajuda a Equipe Scrum e a organização a adotarem o Scrum. O ScrumMaster educa a Equipe Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda a Equipe Scrum a entender e usar auto-gerenciamento e interdisciplinaridade. O ScrumMaster também auxiliar a equipe a fazer o seu melhor em um ambiente organizacional que pode ainda não ser otimizado para o desenvolvimento de produtos complexos. Quando o ScrumMaster ajuda a realizar essas mudanças, isso é chamado de “remoção de impedimentos”. No entanto, o ScrumMaster não gerencia a Equipe Scrum; a Equipe Scrum é auto-organizável. O Product Owner (PO) é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pela Equipe. O PO mantém o Product Backlog (PB) e assegura 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 deve ser uma pessoa, e não um comitê. Podem existir comitês que aconselhem ou influenciem , mas somente o PO poderá mudar a prioridade de um item do PB. Empresas que adotam Scrum podem perceber que isso influencia seus métodos para definir prioridades e requisitos ao longo do tempo. Para que o PO obtenha sucesso, todos na organização precisam respeitar suas decisões. Somente o PO pode definir a prioridade dos itens que a equipe irá trabalhar. As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa visibilidade requer que o Product Owner faça seu melhor, o que faz o papel de “Product Owner “ exigente e recompensador ao mesmo tempo.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

52

A Equipe SCRUM: A Equipe
A Equipe (time) de desenvolvedores transformam o Product Backlog em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. A equipe deve ser formada por pessoas “comprometidas” em atingir as metas das Sprints .

SCRUM, O Tutorial®

A equipe deve ser interdisciplinar: os membros da equipe devem ter todo o conhecimento e habilidades necessárias para entregar a meta da Sprint. Membros da equipe geralmente possuem conhecimentos especializados, tais como: programação, testes, controle de qualidade, análise de negócios, arquitetura, desenho de interface de usuário e modelagem de dados. No entanto, o conhecimento que os membros devem compartilhar - isto é, a habilidade de trabalhar um item do Product Backlog (ou um requisito) e transformá-lo em um produto (software funcionando) tendem a ser mais significativas do que aqueles que eles não dividem. As pessoas que se recusam a programar porque são arquitetas ou designers não se adaptam bem a equipe. Todos devem contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas. Na equipe não há hierarquia nem títulos, todos são iguais e não há exceções a essa regra. As equipes também não devem ter sub-equipe dedicados a áreas particulares como testes, banco de dados ou análise de negócios. A equipe possui a auto gestão e é auto-organizada. Não deve haver interferência externa, nem o ScrumMaster ou Product Owner – ninguém pode dizer como a equipe deve se organizar ou fazer inferência na forma de trabalho da equipe. A equipe deve ser capaz de se auto-organizar para dividir e fazer trabalho. A equipe deve ser autosuficiente, cada membro da equipe aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia geral da equipe como um todo.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

53

Equipe: Comprometimento e Tamanho:

SCRUM, O Tutorial®

Envolvidos

Comprometidos

Stakeholders (clientes e usuários finais)

Product Onwer

Equipe

SCRUM Master

O tamanho ótimo para uma equipe é de 7 pessoas, mais ou menos duas pessoas. Quando há menos do que cinco membros em uma equipe, há menor interação e, como resultado, há menor ganho de produtividade. Mais do que isso, a equipe poderá encontrar limitações de conhecimento durante partes da Sprint e não ser capaz de entregar uma parte “pronta” do produto. Se há mais do que 9 membros, há simplesmente a necessidade de muita coordenação. Equipe grandes geram muita complexidade para que um processo empírico consiga gerenciar. Contudo, temos encontrado algumas equipes bem-sucedidas que excederam os limites superior e inferior dessa faixa de tamanhos. O PO e o ScrumMaster não estão incluídos nessa conta, a menos que também sejam porcos. A composição da equipe pode mudar ao final da Sprint. Toda vez que a equipe muda, a produtividade ganha através da auto-organização é reduzida. Deve-se tomar cuidado ao mudar a composição da equipe.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

54

Framework Scrum: Eventos de Duração Fixa:

SCRUM, O Tutorial®

Eventos
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

55

Eventos:Visão Geral
Eventos com duração fixa (time-boxes) : Os eventos com duração fixa são utilizados para criar para criar regularidade, os seguintes eventos têm a duração fixa: - Reunião de Planejamento da Release - Reunião de Planejamento da Sprint, - Sprint, - Reunião Diária, - Revisão da Sprint - Retrospectiva da Sprint. A Sprint: Parte central, ou o coração do Scrum, é a Sprint, que é uma iteração de um mês ou menos, de duração consistente com o esforço de desenvolvimento. Todas as Sprints utilizam o mesmo modelo de Scrum e todas as Sprints têm como resultado um incremento do produto final que é potencialmente entregável. Cada Sprint começa imediatamente após a anterior.

SCRUM, O Tutorial®

Reunião Diária

Sprint

Produto

Product Backlog Versão 1 Nov 2010 | RFS

Sprint Backlog rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

56

Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DE PLANEJAMENTO DA RELEASE O propósito do planejamento da release é o de estabelecer um plano e metas que a equipe Scrum e o resto da organização possam entender e comunicar. O planejamento da release responde às questões: - “Como podemos transformar a visão em um produto vencedor da melhor maneira possível? - “Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?” O Plano da Release, que é o artefato resultante dessa reunião, estabelece a meta da release, as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. 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 release a cada Sprint. O planejamento da release é opcional. Contudo, se a equipe Scrum iniciar o trabalho sem essa reunião, a ausência de seu artefato aparecerá como um impedimento que deverá ser resolvido. O trabalho para resolver o impedimento se tornará um item do Product Backlog. Ao se utilizar Scrum, 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. Muitas organizações já possuem um processo de planejamento de release, e na maior parte desses processos o planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

57

Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DE PLANEJAMENTO DA RELEASE (continuação)
No planejamento de release do Scrum, são definidos uma meta geral e resultados prováveis. Esse planejamento geralmente não requer mais do que 15-20% do tempo que uma organização costumava utilizar para produzir um plano de release tradicional. No entanto, uma release com Scrum realiza planejamento no momento da execução de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma forma que realiza um planejamento diário no momento da execução de cada Reunião Diária. De forma geral, os esforços para uma release com Scrum provavelmente consomem ligeiramente mais esforço do que os esforços para um planejamento de release tradicional. O planejamento da release requer estimar e priorizar o Product Backlog para a release. Há diversas técnicas para fazê-lo que estão fora do alcance do Scrum, mas que apesar disso são úteis quando usadas com ele. Artefato resultante dessa reunião: Plano de Release

SCRUM, O Tutorial®

Plano de Release do Produto
Release #
Visão do Produto

Release #1

Release #2

Release #3

Visão do Planejamento

Product Backlog
Release BurnDown

Sprint #

1
Versão 1 Nov 2010 | RFS

2

3

4

5

6
Todos os direitos reservados e protegidos © 2006 e 2010

rildo.santos@etecnologia.com.br

58

Framework Scrum: Eventos de Duração Fixa:

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

SCRUM, O Tutorial®

24 horas Visão Produto Backlog Sprint Backlog Sprint 2-4 Semanas Produto

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

59

Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DE PLANEJAMENTO DA SPRINT A Reunião de Planejamento da Sprint é o momento no qual 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. A primeira parte, um evento com duração fixa de 4 horas, é o momento no qual é decidido “o quê” será feito na Sprint. A segunda parte, também é um evento com duração fixa de 4 horas, é o momento no qual a equipe entende “como” desenvolverá essa funcionalidade em um incremento do produto durante a Sprint. Na 1º a equipe Scrum trata da questão: “o quê?”. O Product Owner apresenta a equipe o que é mais prioritário no Product Backlog. 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 Product Back, o incremento mais recente ao produto, a capacidade da equipe e o histórico de desempenho da equipe. Cabe somente a equipe a decisão de quanto itens do Product Backlog ela deve selecionar. Somente a Equipe pode avaliar o que ele é capaz de realizar na próxima Sprint.
Meta da Sprint: Uma vez selecionado o Product Backlog , a Meta da Sprint é delineada. A Meta da Sprint é o objetivo que será atingido através da implementação do Product Backlog. Ela é uma descrição que fornece orientação a equipe sobre a razão pela qual ele está desenvolvendo o incremento. A Meta da Sprint é um subconjunto da Meta da Release. O motivo para se ter uma Meta da Sprint é dar a equipe alguma margem com relação à funcionalidade. Por exemplo, a meta para a Sprint acima poderia também ser: “Automatizar a funcionalidade de modificação de conta de clientes através de um “middleware” seguro capaz de recuperar transações.” Conforme a equipe trabalha, ela mantém a meta em mente. Para satisfazer a meta, elaa implementa a funcionalidade e a tecnologia. Se o trabalho se mostrar mais difícil do que a equipe esperava, a equipe então irá colaborar com o Product Owner e implementar a funcionalidade apenas parcialmente.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

60

Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DE PLANEJAMENTO DA SPRINT (Continuação): Sprint Backlog Na segunda parte da Reunião de Planejamento da Sprint, a equipe trata a questão: “como?”. Durante as quatro horas seguintes da Reunião de Planejamento da Sprint, a equipe Fazer UI define como transformará o Backlog do Produto selecionado durante a Reunião de Planejamento (o quê) em um incremento pronto. A equipe geralmente começa Fazer as projetando o trabalho. Enquanto projeta, a equipe identifica tarefas. Essas tarefas Tabelas são “pedaços” detalhados do trabalho necessário para converter os itens do Product Backlog em software funcional. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint Incluir novo cliente Backlog que é um artefato do SCRUM. A equipe se auto-organiza para se encarregar e se responsabilizar pelo trabalho contido na Sprint Backlog , tanto durante a Reunião de Planejamento da Sprint quanto no próprio momento da execução da Sprint. O Product Owner está presente durante a segunda parte da Reunião de Planejamento da Sprint para esclarecer o Product Backlog e para ajudar a efetuar trocas. Se a equipe concluir que ele tem trabalho demais ou de menos, ele pode renegociar os itens do Product Backlog escolhido com o Product Owner. A equipe também pode convidar outras pessoas , tais como clientes finais e/ou especialista de negócio, a participarem da reunião para fornecerem conselhos técnicos ou sobre o domínio em questão. Geralmente, uma equipe nova percebe pela primeira vez se irá ganhar ou perder como uma equipe - não individualmente - nessa reunião. A equipe percebe que deve contar consigo mesmo. Conforme ele percebe isso, ele começa a se autoorganizar para assumir as características e comportamento de uma verdadeiro equipe. Artefato resultante dessa reunião: Sprint Backlog
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

consultar cliente

alterar cliente Fazer Testes Unitários

61

Framework Scrum: Eventos de Duração Fixa:

SCRUM, O Tutorial®

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Visão Produto Backlog Sprint Backlog Produto Sprint 2-4 Semanas

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

62

Framework Scrum: Eventos de Duração Fixa:
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 da equipe 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. Um projeto serve para cumprir alguma função. Em desenvolvimento de software, o projeto é utilizado para desenvolver um produto ou sistema. Cada projeto consiste em uma definição do que será desenvolvido, um plano para desenvolvê-lo, o trabalho realizado de acordo com o plano e o produto resultante. 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 etc. 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. As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa fazê-lo sob influência das partes interessadas, da equipeou do ScrumMaster. Sob que tipo de circunstâncias pode ser necessário cancelar uma Sprint? A gerência pode precisar cancelar uma Sprint se a Meta da Sprint se tornar obsoleta. Isso pode ocorrer se a empresa mudar de direção ou se as condições do mercado ou tecnologia mudarem. Em geral, uma Sprint deve ser cancelada se ela não fizer mais sentido dadas as circunstâncias atuais, todavia isso deve ser uma exceção. Porém, por causa da curta duração das Sprints, raramente isso faz sentido. Artefato resultante dessa iteração: Parte do produto
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

63

Framework Scrum: Eventos de Duração Fixa:

SCRUM, O Tutorial®

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Visão Produto Backlog Sprint Backlog Produto Sprint 2-4 Semanas

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

64

Framework Scrum: Eventos de Duração Fixa:
REUNIÃO DIÁRIA A equipe deve se encontrar 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: 1. O que ele realizou desde a última reunião diária; 2. O que ele vai fazer antes da próxima reunião diária; e 3. Quais obstáculos estão em seu caminho.

SCRUM, O Tutorial®

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 deve garantir que a equipe realize essa reunião. A equipe é responsável por conduzir a Reunião Diária. O ScrumMaster ensina a equipe a manter a Reunião Diária com curta duração, reforçando as regras e assegurando 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 Product Backlog um incremento (a equipe), e para mais ninguém. A equioe se comprometeu com uma Meta da Sprint, e a esses itens do product Backlog. A Reunião Diária é uma inspeção do progresso na direção da Meta da Sprint (as três perguntas). Geralmente acontecem reuniões subsequentes para realizar adaptações ao trabalho que está por vir na Sprint. A intenção é otimizar a probabilidade de que a equipe alcance sua Meta. Essa é uma reunião fundamental de inspeção e adaptação no processo empírico do Scrum.

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

65

Framework Scrum: Eventos de Duração Fixa:

SCRUM, O Tutorial®

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Visão Produto Backlog Sprint Backlog Produto Sprint 2-4 Semanas

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

66

Framework Scrum: Eventos de Duração Fixa:
REVISÃO DA SPRINT Ao final da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints de um mês, essa é uma reunião com duração fixa de 4 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, a equipe Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanças no Product Backlog 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. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, além de como esses problemas foram resolvidos. A equipe então demonstra o trabalho que está pronta e responde a questionamentos. O Product Owner então discute o Product Backlog 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.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

67

Framework Scrum: Eventos de Duração Fixa:

SCRUM, O Tutorial®

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Visão Produto Backlog Sprint Backlog Produto Sprint 2-4 Semanas

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

68

Framework Scrum: Eventos de Duração Fixa:
RETROSPECTIVA DA SPRINT Após a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, a equipe Scrum tem a reunião de Retrospectiva da Sprint. Nessa reunião, com duração fixa de três horas, o ScrumMaster encoraja a equipe 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. Existem diversas técnica que são úteis em uma Retrospectiva. A finalidade da Retrospectiva é inspecionar como foi 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 da equipe, os preparativos para reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para transformar itens do Product Backlog em alguma coisa “pronta”. No final da Retrospectiva da Sprint, a equipe Scrum deve ter identificado as ações de melhoria factíveis que será implementada na próxima Sprint. Essas mudanças se tornam a adaptação para a inspeção empírica.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

69

Framework Scrum: Artefatos

SCRUM, O Tutorial®

Artefatos
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

70

Framework Scrum: Artefatos

SCRUM, O Tutorial®

Scrum tem quatro artefatos principais: - Product Backlog: é uma lista priorizada de tudo que pode ser necessário no produto. - Sprint Backlog: é uma lista de tarefas para transformar o Product Backlog , por uma Sprint, em um incremento do produto potencialmente entregável. Um burndown é uma medida do backlog restante pelo tempo. - Release Burndown: Mede o Product Backlog restante ao longo do tempo de um Plano de Release do Produto. - Sprint Burndown: Mede os itens da Sprint Backlog restantes ao longo do tempo de uma Sprint.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

71

Framework Scrum: Artefatos
PRODUCT BACKLOG e RELEASE BURNDOWN Os requisitos para o produto que a equipe está desenvolvendo estão listados no Product Backlog O Product Owner (PO) é o responsável pelo Product Backlog , por sua criação, por seu conteúdo, por sua disponibilidade e por sua priorização. O Product Backlog nunca está completo. A seleção inicial para o seu desenvolvimento somente mostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usado evoluem. 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 Product Backlog também existirá. O Product Backlog 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 releases futuras. Os itens do Product Backlog possuem os atributos de descrição, prioridade e estimativa. A prioridade é determinada por risco, valor e necessidade. Há diversas técnicas para dar valor a esses atributos. O Product Backlog é ordenado por prioridade, os itens com as maiores prioridades devem ter o desenvolvimento imediato. Quanto mais alta sua prioridade, mais urgente ele é, mais se pensou sobre ele e há mais consenso no que diz respeito ao seu valor. Os itens do Backlog de maior prioridade, possuem mais informações e detalhes do que os itens do Backlog de menor prioridade. É mais fácil de fazer a estimativa quando existem mais informações e mais detalhes.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

72

Framework Scrum: Artefatos
PRODUCT BACKLOG e RELEASE BURNDOWN (continuação): Quando um produto é utilizado, que seu valor aumenta e que o cliente fornece feedback, o Product Backlog poderá se tornar uma lista maior e mais aprofundada. Os requisitos nunca param de mudar. O Product Backlog é um documento vivo. Mudanças nos requisitos de negócios, condições do mercado, tecnologia e equipe causam mudanças no Product Backlog. Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados. Os itens do Product Backlog que ocuparão a Equipe Scrum pelas várias Sprints seguintes deverão ter granularidade mais fina (mais detalhados), tendo sido decompostos de forma tal que cada um dos itens possa ser feito dentro da duração da Sprint. Frequentemente, múltiplas equipes trabalham juntas no mesmo produto. Um único Product Backlog é usado para descrever o trabalho a ser realizado no produto. Então, um atributo que agrupe os itens é aplicado no Backlog do Produto. O agrupamento pode ocorrer por conjuntos de características, por tecnologia ou por arquitetura, e ele é frequentemente utilizado como uma forma de se organizar o trabalho por equipe. O gráfico de Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organização tenham decidido usar. As unidades de tempo geralmente são Sprints. As estimativas dos itens do Product Backlog são inicialmente calculadas durante o Planejamento da Release, e posteriormente à medida que itens forem sendo criados. Durante a preparação do Product Backlog , os itens são revistos e revisados. Entretanto, eles podem ser atualizados em qualquer momento. A equipe é responsável por todas as estimativas. O Product Owner (PO) pode influenciar a equipe, ajudando-o a entender e a escolher as mudanças, mas a estimativa final é feita pelo equipe. O Product Owner mantém o Product Backlog e o Release Burndown do Backlog atualizados e publicados todo o tempo. Uma linha de tendência pode ser traçada baseada na mudança do trabalho restante.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

73

Framework Scrum: Artefatos
PRODUCT BACKLOG: Exemplo

Product Backlog
Tema* Venda de Passagem Item Vender passagens áreas Consulta de disponibilidade de passagens áreas Fazer check-in Cancelar Check-in Adesão ao programa de fidelidade Consultar os pontos do programa de fidelidade Fazer registro de comentários, sugestões e reclamações dos clientes Responder ao cliente (por email) Prioridade Alta Alta Alta Alta Média Média Baixa Pontos (estimados) 40 13 40 8 20 5 8

SCRUM, O Tutorial®

Venda de Passagem Check-in Check-in Programa de Fidelidade Programa de Fidelidade Atendimento ao cliente Atendimento ao cliente

Baixa

5

Nota: O que é Tema ? Tema é utilizado para agrupar “Estórias do Usuários” relacionadas, as estórias são representam o detalhamento dos itens do Backlog, ao usar o conceito de “tema”, ele poderá facilitar as atividades de priorização e de estimativa. Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

74

Framework Scrum: Artefatos
RELEASE BURNDOWN: Exemplo

Release Burndown
150

SCRUM, O Tutorial®

139

100

Pontos (estimados)

90

Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organização tenham decidido usar. As unidades de tempo geralmente são Sprints.

50

52

20 0

Sprint #1

Sprint #2 Sprints

Sprint #13

Sprint #4

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

75

Framework Scrum: Artefatos
SPRINT BACKLOG E SPRINT BURNDOWN: A Sprint Backlog consiste nas tarefas que a equipe executa para transformar os itens do Product Backlog em um incremento “pronto”. Muitas deles são elaboradas durante a Reunião de Planejamento da Sprint. A Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta da Sprint. Os itens do Sprint Backlog devem ser decompostos. A decomposição deve ser suficiente para que mudanças no progresso possam ser entendidas na Reunião Diária. A equipe modifica a Sprint Backlog no decorrer da Sprint. Quando chega às tarefas individuais, a equipe pode descobrir que mais ou menos tarefas serão necessárias, ou que uma determinada tarefa levará mais ou menos tempo do que era esperado. À medida que novo trabalho surge, a equipe o adiciona a Sprint Backlog. À 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 a equipe pode modificar a Sprint Backlog durante uma Sprint, pode mudar o seu conteúdo ou as suas estimativas. A Sprint Backlog é um retrato em tempo real altamente visível do trabalho que a equipe planeja efetuar durante a Sprint, e ela pertence unicamente a equipe.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

76

Framework Scrum: Artefatos
SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo

SCRUM, O Tutorial®

Na reunião de Planejamento da Sprint, PO deverá apresentar a visão do produto, Product Backlog e seus Itens, comentando o nível de prioridade de cada item. Os membros da equipe devem selecionar os itens com os maiores níveis de prioridades para fazer parte da Sprint.

Estória do Usuário
Titulo: “Fazer Check-in”

Como cliente de negócio, eu quero fazer check-in pela web para que fique menos tempo em filas. Pontos: ? Prioridade: Alta

A estória do usuário auxilia no entendimento do que deve ser feito, ela permite fazer a estimativa de velocidade da equipe e também é, utilizada como lembrete e para as atividades de planejamento. Geralmente a estimativa é feita em pontos (pontos de estória)

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

77

Framework Scrum: Artefatos
SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo Estória do Usuário
Titulo: “Fazer Check-in”

Como cliente de negócio, eu quero fazer check-in

SCRUM, O Tutorial®

pela web para que fique menos tempo em filas. Pontos: ?

Prioridade: Alta

Quebrar a estória do Usuário em tarefas: - Para facilitar a estimativa de velocidade da equipe, considere quebrar a estória em tarefas, isto pode fazer que todos os membros da equipe visualizem todas as tarefas que devem ser feitas para implementar o item do backlog. Mas, ainda precisamos estimar os pontos...

Fazer interface do usuário

Impressão do Ticket

Sprint Backlog

Fazer Check-in

Criar Componentes de validação Integrar com Sistema de Reserva

Executar testes unitários Executar testes de aceitação

A Sprint Backlog é um artefato resultante da reunião de Planejamento da Sprint
Todos os direitos reservados e protegidos © 2006 e 2010

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

78

Estimando os pontos da “Estória do Usuário”:
Uma breve introdução sobre estimativa: Estimar é Difícil ? - Estimativa (mundo real) representa um valor aproximado. - Estimativa (em desenvolvimento de software) algumas pessoas acham que representa um valor exato. Contudo, devemos estimar as Estórias do Usuário para saber se elas “cabem” dentro de uma Sprint. Uma vez que os pontos são estimados eles ajudam a definir a velocidade da equipe, a partir deste parâmetro, podemos chegar a conclusão se estória cabe ou não dentro da Sprint. Se ela não couber a opção é quebrar esta estória em estórias menores.

SCRUM, O Tutorial®

Exemplo de Estórias do Usuário:
Titulo: Pagamento com Cartão de Crédito Quem ? Prioridade: ?

como um cliente
O que ?
Pessoal, qual estimativa para essa estória...

preciso de uma interface de pagamento por cartão de crédito que seja intuitiva e fácil de usar. Por que ? Com objetivo de facilitar os pagamentos. Pontos: ?

Product Owner Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

79

Estimando os pontos da “Estória do Usuário”:
Quando trabalhamos com métodos ágeis temos pelo menos duas formas para estimar a velocidade da equipe: Ideal Days e Pontos de Estória. Recomendamos utilizar os Pontos de Estória. Ideal Days: ◦ Mais fácil para iniciantes ◦ Fácil de explicar

Dias Ideais (Ideal Days)
Baseado na duração de tarefas. - Dias ou horas é unidade bem definida, contudo o “tempo ideal” quase nunca é igual ao “tempo real”... - É mais fácil de estimar, mas pode ser tornar difícil de estimar se consideramos todas as interrupções e variações

SCRUM, O Tutorial®

Pontos de Estória: ◦ Valores relativos ◦ Mais abstrato

Pontos de Estória (Story Points) Baseia-se no tamanho da estória influenciado pela: - Nível de dificuldade, complexidade e experiência (é empírico); Foco nas funcionalidades; O importante são os valores relativos; Pontos são medidas sem unidade; Equipe diferentes podem ter pontos diferentes para a mesma estórias. Principais técnicas: ◦ Opinião de especialista; ◦ Analogia; ◦ Decomposição (Dividir para conquistar).

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

80

Estimando os pontos da “Estória do Usuário”:
Estimativa* e o Planning Poker: Para fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever as estórias do usuário. O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseada no consenso de toda a equipe. Geralmente o Planning Poker usa um conjunto de cartas com valores específicos que podem representar pontos relativos e é praticado como se fosse um jogo de cartas. Os pontos devem estar em uma escala não linear, por e exemplo a Fibonacci: (1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala

SCRUM, O Tutorial®

Jogando o Planning Poker: Antes de começar o jogo é necessário definir um valor de referência. Por exemplo: Identificar a estória que pode ser atribuído a menor quantidade pontos, esta estória será utilizada como referência para pontuação das demais estórias. O PO apresenta uma estória e pede para os membros da equipe fazer a estimativa de velocidade...
1ª. Rodada

40

100

Pessoal, qual é estimativa para essa estória...

40

40

Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos pontos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja concesso.

Nª. Rodada

40

40

40

40

Product Owner Versão 1 Nov 2010 | RFS

Equipe rildo.santos@etecnologia.com.br

Equipe
Todos os direitos reservados e protegidos © 2006 e 2010

81

Framework Scrum: Artefatos
SPRINT BACKLOG: Exemplo Estória do Usuário
Titulo: “Fazer Check-in”

Como cliente de negócio, eu quero fazer check-in

SCRUM, O Tutorial®

pela web para que fique menos tempo em filas. Pontos: 40

Prioridade: Alta

Planning Poker, estória do usuário e pontos de estória, nada disso faz parte do framework Scrum, contudo são técnicas e ferramentas complementares ao framework. Elas são altamente utilizadas para fazer a estimativa de velocidade da equipe. E finalmente temos a Sprint Backlog e podemos criar o Sprint Burndonw.

Fazer interface do usuário

Impressão do Ticket

Sprint Backlog

Fazer Check-in

Criar Componentes de validação Integrar com Sistema de Reserva

Executar testes unitários Executar testes de aceitação

A Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta da Sprint.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

82

Framework Scrum: Artefatos
SPRINT BACKLOG E SPRINT BURNDOWN:
A Sprint Burndown (ou Burndown ) é um gráfico da quantidade restante de trabalho do Sprint Backlog 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 da Sprint Backlog. 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, a equipe 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. Uma das regras do Scrum está ligada ao objetivo de cada Sprint, que é ter como resultado incrementos de funcionalidade potencialmente entregáveis que estejam de acordo com uma definição de “pronto”.
Dica: Sempre que possível, desenhe a Sprint Burndown em um quadro que esteja na área de trabalho da equipe. É mais provável que a equipe veja um gráfico grande e visível do que um gráfico de feito em uma planilha de calculo.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br

SCRUM, O Tutorial®

A Sprint Burndown é um artefato que deve ser utilizado exclusivamente pela equipe. Se PO tentar fazer a gestão do projeto com base na Sprint Burndown é considerado como micro-gerenciamento e que pode levar ao comando-controle... O PO deve fazer a gestão do projeto olhando a Release Burndown.

Todos os direitos reservados e protegidos © 2006 e 2010

83

Framework Scrum: Artefatos
SPRINT BURNDOWN : Exemplo A transparência, que é dos pilares do Scrum, garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. O Quadro de Tarefas deixam a Sprint com visibilidade e transparência.
O Quadro de Tarefas também não parte do framework Scrum, ele parte de uma técnica chamada Gestão à Vista, que tem como objetivo facilitar a comunicação e dar visibilidade (transparência).

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

84

Framework Scrum: Definição de Pronto

SCRUM, O Tutorial®

Pronto
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

85

Definição de Pronto (*DoD):
Uma conversa comum entre o cliente e o desenvolvedor: [Cliente] E aí como anda o desenvolvimento da aplicação ? [Desenvolvedor] Está pronta... [Cliente] Isso quer dizer que eu posso implementa-la ? [Desenvolvedor] Bem...ainda não, preciso fazer mais alguns testes... [Cliente] Mas, aplicação não estava pronta..

SCRUM, O Tutorial®

Definir claramente quando o produto estará “pronto”, pois: Pronto, para desenvolvedor significa: - Encerrou a codificação... Pronto, para PO significa: - Quando foi entregue... Pronto, para os usuários finais e/ou clientes significa: - Quando o software começou a funcionar em ambiente de produção...

Evite: A síndrome dos 90% feito (pronto).
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

86

Framework Scrum: Definição de Pronto
A Definição de PRONTO

Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente entregável, pois o Product Owner (PO) pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

SCRUM, O Tutorial®

No desenvolvimento de produtos, afirmar que a funcionalidade está pronta pode levar alguém a presumir que ela está pelo menos bem codificada, refatorada, que tenha passado por testes unitários, que tenha sido feito o “build” e que tenha passado por testes de aceitação. Outros podem presumir que apenas o código tenha sido desenvolvido. Se não houve definição de “pronto”, os outros dois pilares do controle de processos empíricos não funcionam. Quando alguém descreve algo como “pronto”, todos devem entender o que “pronto” significa. “Pronto” define o que a equipe quer dizer quando se compromete a “aprontar” um item de Product Backlog em uma Sprint. Alguns produtos não contêm documentação, de forma que sua definição de “pronto” não inclui documentação. Um incremento completamente “pronto” inclui toda a análise, projeto, refatoramento, programação, documentação e testes para o incremento e todos os itens do Product Backlog no incremento. Os testes incluem testes de unidade, de sistema, de usuário e de regressão, bem como testes não-funcionais como de performance, de estabilidade, de segurança e de integração. “Pronto” inclui também qualquer internacionalização necessária. Algumas equipes ainda não são capazes de incluir em sua definição de “pronto” tudo o que é necessário para a implantação. Isto deve estar claro para o Product Owner. Esse trabalho restante deverá ser feito antes que o produto possa ser implantado e utilizado.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

87

Framework Scrum: Definição de Pronto
A Definição de PRONTO e “NÃO PRONTO”
Algumas organizações são incapazes de desenvolver um incremento completo dentro de uma Sprint. Elas podem ainda não ter infraestrutura automatizada de testes para completar todos os testes. Nesse caso, duas categorias são criadas para cada incremento: o trabalho “pronto” e o trabalho “não pronto”. O trabalho “não pronto” é a porção de cada incremento que terá que ser completada mais tarde. O Product Owner sabe exatamente o que ele está inspecionando ao final da Sprint, porque o incremento atende à definição de “pronto” e o Product Owner entende essa definição. O trabalho “não pronto” é adicionado a um item do Product Backlog o chamado “trabalho não pronto”, de forma que ele se acumula e isso é refletido corretamente no gráfico de Release Burndown Release. Essa técnica cria transparência no progresso em direção à entrega. A inspeção e a adaptação na Revisão da Sprint serão tão precisas quanto essa transparência for. Exemplo: Se uma equipe não é capaz de realizar os testes de performance, regressão, estabilidade, segurança e integração para cada item do Product Backlog, a proporção desse trabalho em relação ao trabalho que pode ser pronto (análise, projeto, refatoramento, programação, documentação, testes unitário e testes de usuário) é calculada. Vamos supor que essa proporção é de seis peças de “pronto” e quatro peças de “não pronto”. Se a equipe terminar um item de Product Backlog de seis unidades de trabalho (a equipe está estimando baseado no que ele sabe como “aprontar”), quatro unidades serão acrescidas ao item do Product Backlog denominado “trabalho não pronto” quando eles tiverem terminado. Sprint a Sprint, o trabalho “não pronto” de cada incremento vai se acumulando e deve ser tratado antes da entrega do produto. Esse trabalho é acumulado linearmente, embora haja algum tipo de acúmulo exponencial que é dependente das características de cada organização. Sprints são adicionados ao final de cada release para completar o trabalho “não pronto”. O número de Sprints é imprevisível, visto que o acúmulo de trabalho “não pronto” não é linear.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

88

Exercícios:
Responda Verdadeiro ou Falso para as declarações: 1 - Quando as regras não são declaradas, espera-se que os usuários de Scrum descubram o que devem fazer. Não tente descobrir uma solução perfeita, porque geralmente o problema muda rapidamente. Ao invés disso, tente algo e veja como se sai. Os mecanismos de inspeção-e-adaptação inerentes à natureza empírica do Scrum irão lhe guiar.

SCRUM, O Tutorial®

[

] Verdadeiro

[

] Falso

2 - O ScrumMaster trabalha com os clientes e a gerência para identificar e designar um Product Owner. O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que eles saibam como conseguir otimizar valor através do Scrum. Se eles não souberem, consideramos o ScrumMaster responsável.

[

] Verdadeiro

[

] Falso

3 - O ScrumMaster pode ser um membro da equipe; por exemplo, um desenvolvedor realizando tarefas da Sprint. No entanto, isso frequentemente leva a conflitos quando o ScrumMaster deve escolher entre remover impedimentos ou realizar tarefas.

[

] Verdadeiro

[

] Falso

4 - O ScrumMaster nunca deve ser o Product Owner. [ ] Verdadeiro [ ] Falso
rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

Versão 1 Nov 2010 | RFS

89

Exercícios:
Responda Verdadeiro ou Falso para as questões:

5 - O Product Owner pode ser um membro da equipe, trabalhando também na realização das tarefas. Mas, essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partes interessadas.
[ ] Verdadeiro [ ] Falso

SCRUM, O Tutorial®

6 – Se a equipe sentir que se comprometeu com mais do que podia, ele se encontra com o Product Owner para remover ou reduzir o escopo da Sprint Backlog (itens do Product Backlog selecionado para a Sprint). Se a equipe sentir que sobrará tempo ele pode trabalhar junto ao Product Owner para selecionar mais do itens do Product Backlog. [ ] Verdadeiro [ ] Falso

7- Geralmente, somente 60-70% do total da Sprint Backlog será definido na Reunião de Planejamento da Sprint. O restante é deixado para ser detalhado mais tarde ou são dadas estimativas grandes que serão decompostas mais tarde na Sprint. [ ] Verdadeiro [ ] Falso

8 - Os itens do Product Backlog são comumente representados como “Estórias do Usuário”. Casos de Uso também são apropriados. [ ] Verdadeiro [ ] Falso
rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

Versão 1 Nov 2010 | RFS

90

Exercícios:
Responda Verdadeiro ou Falso para as questões:

9 - Testes de aceitação fazem parte da Estória de Usuário, são utilizados parar substituir descrições textuais mais detalhadas com uma descrição testável.
[ ] Verdadeiro [ ] Falso

SCRUM, O Tutorial®

10 - O Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe Scrum e a organização tenham decidido usar. As unidades de tempo geralmente são Estórias do Usuário. [ ] Verdadeiro [ ] Falso

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

91

Conteúdo:

SCRUM, O Tutorial®

1 – Desafios do desenvolvimento de Software 2 – Sobre o SCRUM

3 – Entendendo SCRUM
4 – Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

92

Objetivo:

SCRUM, O Tutorial®
Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de Software. Pré-requisito: Conhecimento das práticas Scrum.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

93

Estudo de Caso

SCRUM, O Tutorial®

Estudo de Caso
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

94

Framework SCRUM

Planejamento da Release

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

SCRUM, O Tutorial®

24 horas Product Backlog Sprint Backlog Produto Sprint (2-4 Semanas) Visão Legenda: Reuniões Artefatos

Reuniões
Papéis Artefatos • Planejamento da Release • Planejamento da Sprint • Diária • Revisão da Sprint • Retrospectiva da Sprint • Product Backlog • Sprint Backlog • Sprint Burndown • Release Burndown

• Product Owner (PO) • ScrumMaster (SM) • Equipe (time)

•Sprint Burndown • Release Burndown
95

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

Estudo de Caso: Visão
Primeiro passo: definir a Visão do Produto.

SCRUM, O Tutorial®

Planejamento da Release

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Produto Backlog Sprint Backlog Sprint 2-4 Semanas Visão Produto

1
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

96

Estudo de Caso: Visão do Produto
Para definir a visão do Produto, primeiro é necessário entender qual é a real necessidade do cliente:

A necessidade: Um hotel, quer incrementar um novo canal de consultas e vendas de reservas de apartamentos. A sugestão foi criar um Portal de Reservas para vender os serviços.

SCRUM, O Tutorial®

Após entender a necessidade do cliente, é hora de definir a Visão do Produto: Declaração da Visão do Produto:

Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line é um software baseado na web, intuitivo e fácil de usar que fornece a possibilidade fazer a consultas e reservas de apartamentos. Diferente de outros sistemas, o produto oferece um canal direto de acesso ao cliente.
rildo.santos@etecnologia.com.br

Versão 1 Nov 2010 | RFS

Todos os direitos reservados e protegidos © 2006 e 2010

97

Estudo de Caso: Visão do Produto
Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog:

SCRUM, O Tutorial®

Funcionalidades do produto O Product Backlog, inicialmente é uma lista que representa tudo que é necessário para desenvolver e lançar um produto. A lista deve conter 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 futuras releases . O Product Backlog é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

98

Estudo de Caso: Visão do Produto

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

99

Estudo de Caso: Visão do Produto
Exercício: Podemos fazer a declaração da Visão do Produto sem entender a real necessidade do cliente ?

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

100

Estudo de Caso: Reunião de Planejamento da Release
Segundo passo: Realizar a Reunião de Planejamento da Release, o resultado desta reunião é o Plano de Release e o Release Burndown (artefato Scrum).

SCRUM, O Tutorial®

Planejamento da Release

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Produto Backlog Sprint Backlog Sprint 2-4 Semanas Visão Produto

2
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

101

Estudo de Caso: Reunião de Planejamento da Release
O propósito da Reunião de Planejamento da Release é o de estabelecer o Plano de Release, as Metas e Release Burndown (que é um artefato do Scrum) que a Equipe Scrum e o resto da organização possam entender e comunicar. O planejamento da release responde às questões: - Como podemos transformar a visão em um produto da melhor maneira possível? - Como podemos alcançar ou exceder a satisfação do cliente ? - Como podemos alcançar o ROI (retorno sobre investimento) ? O Plano de Release estabelece a meta da release, as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na release. Ele estabelece também uma data de entrega e custos prováveis que devem se manter se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse Plano de Release a cada Sprint. O planejamento da release requer estimar e priorizar o Product Backlog para a release. Há diversas técnicas para fazê-lo que estão fora do alcance do Scrum (lembre-se o SCRUM é framework ele não indica nenhuma técnica), mas que apesar disso são úteis quando usadas com ele.
Release Burndown (artefato)

SCRUM, O Tutorial®

Entradas
Visão do Produto

Planejamento da Release
Product Backlog (visão inicial) Product Backlog (priorizado)

Saídas
Equipe SCRUM Plano de Release

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

102

Estudo de Caso: Reunião de Planejamento da Release

1

Visão inicial do Product Backlog, antes da reunião de Planejamento da Sprint, ele tem somente as funcionalidades do produto, agrupadas por tema (este agrupamento é opcional).

SCRUM, O Tutorial®

O Plano de Release é elaborado nessa reunião. Nesse plano define-se o prazo de entrega do produto e nível de prioridade dos itens do backlog

O Plano de Release é base para atualização do Product Backlog Agora ele apresenta o nível de prioridade e quantidade de pontos estimados dos itens. O PO é responsável pela priorização dos itens e a Equipe é responsável pela estimativa.

2
Plano de Release Releases Nível de Prioridade Prazo (estimado)
Reserva

3
Promoções Relacionamento ao cliente Programa de Fidelidade Tour Virtual

5 Releases
1 Alto, 3 médio e 1 baixo

Alto

Médio

Médio

Médio

Baixo

30 dias

15 dias

7 dias

15 dias

15 dias

82 dias
103

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

Estudo de Caso: Reunião de Planejamento da Release
Com Product Backlog atualizado e o Plano de Release, o PO poderá construir o Release Burndown, que é um dos artefatos do SCRUM. As estimativas dos itens do Product Backlog são inicialmente calculadas durante a Reunião de Planejamento da Release. O Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organização tenham decidido usar. As unidades de tempo geralmente são Sprints.

Release Burndown

SCRUM, O Tutorial®

120

108 80

Pontos (estimados)

O Product Owner é responsável por manter o Product Backlog e o Release Burndown atualizados e publicados todo o tempo. Uma linha de tendência pode ser traçada baseada na mudança do trabalho restante.
68

40

48

40

20 0

Release #1

Release #2

Release #3 Releases

Release #4

Release #5

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

104

Estudo de Caso: Reunião de Planejamento da Release

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

105

Estudo de Caso: Reunião de Planejamento da Release
Exercício: O que aconteceria se a equipe SCRUM não fizer a Reunião de Planejamento da Release ?

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

106

Estudo de Caso: Reunião de Planejamento da Sprint
Terceiro passo: Realizar a Reunião de Planejamento da Sprint, o resultado desta reunião são os artefatos Sprint Backlog e Sprint Burndown.

SCRUM, O Tutorial®

Planejamento da Release

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Produto Backlog Sprint Backlog Sprint 2-4 Semanas Visão Produto

3
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

107

Estudo de Caso: Reunião de Planejamento da Sprint
Product Backlog: Sistema de Reserva On-Line

SCRUM, O Tutorial®

A Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. No nosso exemplo a duração é fixada em 8 horas, pois, a Sprint tem a estimativa de um mês. Essa reunião é dividida em duas partes: 1ª. Parte da Reunião (4 horas): A equipe Scrum trata da questão: “o quê?”. O PO apresenta a equipe o que é mais prioritário no Product Backlog. Todos trabalham em conjunto para definir qual funcionalidade deverá ser desenvolvida durante a próxima Sprint. O Product Backlog está ordenado de acordo com nível de prioridade dos itens. A equipe deve selecionar o item de maior prioridade e definir qual será a meta da Sprint.
Versão 1 Nov 2010 | RFS

2ª. Parte da Reunião (4 horas): A equipe trata a questão: “como?”. Durante as 4 horas seguintes a equipe define como transformará o item selecionado em incremento do produto “pronto” e potencialmente entregável. O PO estará presente para esclarecer dúvidas e para ajudar a efetuar trocas, se necessário. Se a equipe concluir que ela tem trabalho demais ou de menos, ela pode renegociar os itens do Product Backlog escolhido com o PO
Todos os direitos reservados e protegidos © 2006 e 2010

rildo.santos@etecnologia.com.br

108

Estudo de Caso: Reunião de Planejamento da Sprint
Detalhando os itens do Produto Backlog em estórias do usuário:
Para facilitar o entendimento dos itens do Product Backlog ele são descritos em estórias do usuário elas auxiliam no entendimento do que deve ser feito, permite fazer a estimativa de velocidade da equipe e também é, utilizada como lembrete e para as atividades de planejamento. Geralmente a estimativa é feita em pontos (pontos de estória)

SCRUM, O Tutorial®

Como escrever uma Estória do Usuário ? Conversações sobre a estória, entre os usuários e desenvolvedores, de modo a detalhar o item do Product Backlog e esclarecer todas as dúvidas sobre do que deve ser feito.

Estória do Usuário
Titulo: “Fazer Reserva de Apartamentos” Como cliente de negócio, eu quero fazer reserva de apartamentos pela web para facilitar o meu planejamento.

Cartão: Estória do Usuário são tradicionalmente escritas em um cartão. Cartão podem ter notas, estimativas, comentário observações e etc Conversas: Detalhes que podem surgir durante as conversas com PO (Product Owner) e/ou cliente. Confirmação: Testes de aceitação “confirmam” se a Estória do Usuário foi codificada da forma correta. Testes de aceitação são tipo Caixa Preta.

Pontos: ?

Prioridade: Alta

Boa Prática: A Estória do Usuário deve prover o entendimento do que deve ser feito e deve facilitar a estimativa de velocidade da equipe.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

109

Estudo de Caso: Reunião de Planejamento da Sprint
Detalhando as Estórias do Usuário em Tarefas: Estória do Usuário
Titulo: “Fazer Reserva de Apartamentos” Como cliente de negócio, eu quero fazer reserva de apartamentos pela web para facilitar o meu

SCRUM, O Tutorial®

planejamento. Pontos: ? Prioridade: Alta

Devemos buscar meios para facilitar a estimativa de velocidade da equipe, quebrar a estória do usuário em tarefas pode fazer que todos os membros da equipe visualizem todas as tarefas que devem ser feitas para implementar a Estória do Usuário. Testes de aceitação devem ser escritos para detalhar melhor a estória do usuário, geralmente eles são escritos no versão do cartão.

Tarefas de Negócio Consulta de Reserva de Apartamento Cadastro de Fila de Espera

Tarefas Técnicas Criar Interfaces Do Usuário Criar Tabelas

Fazer Reserva de Apartamentos

Cadastro de Cliente

Executar testes unitários

Confirmação da Reserva

Executar testes de aceitação

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

110

Estudo de Caso: Reunião de Planejamento da Sprint
Estimativa e o Planning Poker: Para fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever as estórias do usuário. O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseada no consenso de toda a equipe. Geralmente o Planning Poker usa um conjunto de cartas com valores específicos que podem representar pontos relativos e é praticado como se fosse um jogo de cartas. Os pontos devem estar em uma escala não linear, por e exemplo a Fibonacci: (1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala

SCRUM, O Tutorial®

Jogando o Planning Poker: Antes de começar o jogo é necessário definir um valor de referência. Por exemplo: Identificar a estória que pode ser atribuído a menor quantidade pontos, esta estória será utilizada como referência para pontuação das demais estórias. O PO apresenta uma estória e pede para os membros da equipe fazer a estimativa de velocidade...
1ª. Rodada

40

100

Pessoal, qual é estimativa para essa estória...

40

40

Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos pontos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja concesso entre os membros da equipe.

Enésima Rodada

40

40

40

40

Product Owner Versão 1 Nov 2010 | RFS

Equipe rildo.santos@etecnologia.com.br

Equipe
Todos os direitos reservados e protegidos © 2006 e 2010

111

Estudo de Caso: Reunião de Planejamento da Sprint
Planning Poker, Estória do Usuário e Pontos de Estória, nada disto faz parte do framework Scrum, contudo, são técnicas e ferramentas complementares ao framework. Elas são utilizadas para ajudar na estimativa de velocidade da equipe. E finalmente temos a Sprint Backlog, mas antes de fazermos o Sprint Burndown, devemos fazer a definição de “Pronto”.

Estória do Usuário
Titulo: “Fazer Reserva de Apartamentos” Como cliente de negócio, eu quero fazer reserva de

SCRUM, O Tutorial®

apartamentos pela web para facilitar o meu planejamento. Pontos: 40 Prioridade: Alta

Tarefas de Negócio Consulta de Reserva de Apartamento Cadastro de Fila de Espera

Tarefas Técnicas Criar Interfaces Do Usuário Criar Tabelas

Sprint Backlog

Fazer Reserva de Apartamentos

Cadastro de Cliente

Executar testes unitários Executar testes de aceitação

Confirmação da Reserva

A Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta da Sprint.
Todos os direitos reservados e protegidos © 2006 e 2010

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

112

Estudo de Caso: Reunião de Planejamento da Sprint
Definição de Pronto: Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente entregável, pois o Product Owner (PO) pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

SCRUM, O Tutorial®

Uma conversa comum entre o cliente e o desenvolvedor: [Cliente] E aí como anda o desenvolvimento da aplicação ? [Desenvolvedor] Está “pronta”... [Cliente] Isso quer dizer que eu posso implementa-la ? [Desenvolvedor] Bem...ainda não, preciso fazer mais alguns testes... [Cliente] Mas, aplicação não está “pronta”..

Definir claramente quando o produto estará “pronto”, pois: Pronto, para desenvolvedor significa: - Encerrou a codificação... Pronto, para PO significa: - Quando foi entregue... Pronto, para os usuários finais e/ou clientes significa: - Quando o software começou a funcionar em ambiente de produção...

Equipe SCRUM: Definiu que o “pronto” é software “rodando” em ambiente de produção.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

113

Estudo de Caso: Reunião de Planejamento da Sprint
A transparência, que é dos pilares do Scrum, ela garante que aspectos do processo que afetam o resultado sejam visíveis para aqueles que gerenciam os resultados. O Quadro de Tarefas deixa a Sprint com visibilidade e transparência necessária. Entretanto, o Quadro de Tarefas é para o uso exclusiva da equipe, que é responsável pela sua atualização.

Task Board (Quadro de Tarefas)
Para Fazer

SCRUM, O Tutorial®

Fazendo

Pronto
Pontos 40

Sprint Burndown

Consulta de Reserva de Apartamento Cadastro de Fila de Espera

30

20 Cadastro de Cliente

10

Confirmação da Reserva

0

1

2 Semanas

3

4

Meta da Sprint Entregar a funcionalidade de reserva de apartamentos em 30 dias.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

114

Estudo de Caso: Reunião de Planejamento da Sprint

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

115

Estudo de Caso: Reunião de Planejamento da Sprint
Esclarecendo algumas dúvidas: Por que 40 pontos em uma Sprint de 30 dias ? É a primeira vez que a equipe utiliza o SCRUM para o desenvolver um software, logo ela não tem experiência e nem histórico de velocidade de desenvolvimento, que possa ser usado para definir a quantidade de tempo que ela levará para fazer 40 pontos. Para não correr riscos, a equipe optou por trabalhar com uma folga. Com o decorrer das Sprints e novos projetos será possível calibrar melhor a velocidade da equipe. O Quadro de Tarefas é importante ?

SCRUM, O Tutorial®

O Quadro de Tarefas (Task Board) também não parte do Framework Scrum, ele parte de uma técnica chamada Gestão à Vista, que tem como objetivo facilitar a comunicação e dar transparência (visibilidade). Lembre-se que a transparência é um dos pilares do SCRUM.
Qual é a duração em dias recomendável quando uma equipe começa a trabalhar com Scrum ? Quando uma equipe começa com o Scrum, Sprints de duas semanas o permite aprender sem cair nas armadilhas da incerteza.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

116

Estudo de Caso: Reunião de Planejamento da Sprint
Exercício: O que aconteceria se a equipe considerar que o item do Product Baclog: “Os clientes poderão fazer reserva de apartamentos” é um “épico” ?

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

117

Estudo de Caso: Reunião Diária
Quarto passo: Após a reunião de Reunião de Planejamento da Sprint, efetivamente a Sprint começa, o próxima passo são as Reuniões Diárias.

SCRUM, O Tutorial®

Planejamento da Release

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Produto Backlog Sprint Backlog Sprint 2-4 Semanas Visão Produto

4
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

118

Estudo de Caso: Reunião Diária
A equipe deve se encontrar diariamente para uma reunião de 15 minutos chamada Reunião Diária. Essa reunião é sempre feita com as pessoas de pé, no mesmo horário e no mesmo local durante as Sprints. Durante a reunião, cada deve membro explicar: 1. O que foi realizado desde a última reunião diária; 2. O que vai ser feito antes da próxima reunião diária; 3. Foi encontrado algum obstáculo (impedimento). 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 aperfeiçoa o nível de conhecimento de todos acerca do projeto. O ScrumMaster é responsável por garantir que a equipe realize essa reunião. Contudo, a própria equipe é responsável por conduzir a reunião. O ScrumMaster deve orientar a equipe a manter a Reunião Diária com curta duração (15 minutos), reforçando as regras e assegurando que as pessoas falem brevemente. O ScrumMaster também enfatiza a regra de que as pessoas que não participam da equipe não podem SCRUM Master atrapalhar e nem a interferir de modo algum a reunião. Ela é só para as pessoas que estão transformando os itens do Product Backlog um incremento (produto), e para mais ninguém. A Reunião Diária não é uma reunião de status. A equipe se comprometeu com a Meta da Sprint, e os itens do Product Backlog. A Reunião Diária é uma inspeção do progresso na direção da Meta da Sprint (as três perguntas). Geralmente acontecem reuniões subsequentes para realizar adaptações ao trabalho que está por vir na Sprint. A intenção é otimizar a probabilidade de que a equipe alcance sua Meta. Essa é uma reunião fundamental de inspeção e adaptação no processo empírico do Scrum.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

119

Estudo de Caso: Reunião Diária
Na primeira reunião a Equipe decide qual tarefa vai ser feita primeiro. Após a escolha da tarefa o Task Board (Quadro de Tarefas) é atualizado.

SCRUM, O Tutorial®

Consulta de Reserva de Apartamento

OK

OK

?

OK

Equipe

SCRUM Master
Versão 1 Nov 2010 | RFS

Questões: 1. O que foi realizado desde a última reunião diária; 2. O que vai ser feito antes da próxima reunião diária; 3. Foi encontrado algum obstáculo. rildo.santos@etecnologia.com.br

15 Minutos
Todos os direitos reservados e protegidos © 2006 e 2010

120

Estudo de Caso: Reunião Diária
As reunião se repetem ao longo dos dias e a cada reunião a Task Board é atualizado (as tarefas e Sprint Burndown).

SCRUM, O Tutorial®

O que vai ser feito antes da próxima reunião diária? Começar a tarefa Cadastro de Cliente

O que foi feito desde a última reunião diária ? Terminamos a tarefa Consulta de Reserva de Apartamentos...

OK
Foi encontrado algum obstáculo ? Não

Movimentação do post-it para a coluna: Pronto

Atualização do Sprint Burndown

OK

?

Equipe

SCRUM Master
Versão 1 Nov 2010 | RFS

Questões: 1. O que foi realizado desde a última reunião diária; 2. O que vai ser feito antes da próxima reunião diária; 3. Foi encontrado algum obstáculo. rildo.santos@etecnologia.com.br

15 Minutos
Todos os direitos reservados e protegidos © 2006 e 2010

121

Estudo de Caso: Reunião Diária
Durante as reuniões diárias todos os impedimentos (ou obstáculos) identificados são registrados no Quadro de Tarefas. Eles representam um risco a Sprint. O Risco de não se atingir a meta, logo eles devem ser removidos. Geralmente os impedimentos são escritos em “Post it” de cor rosa.

15 Minutos

SCRUM, O Tutorial®

OK

OK

OK

?
Encontrei um obstáculo (impedimento).

Equipe

SCRUM Master
Versão 1 Nov 2010 | RFS

Questões: 1. O que foi realizado desde a última reunião diária; 2. O que vai ser feito antes da próxima reunião diária; 3. Foi encontrado algum obstáculo. rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

122

Estudo de Caso: Impedimento
Cabe ao “SCRUM Master” remover todos os impedimentos, identificados e demonstrados no Quadro de Tarefas, para que estes não afetem o desempenho da equipe nem a meta da Sprint. Caso contrário, o impedimento poderá comprometer a meta e a entrega de valor que deve ocorrer no final da Sprint.
O que é um impedimento ? Impedimento tudo aquilo que impede a equipe de realizar seu trabalho e atingir a meta da Sprint. Um impedimento pode ser um problema de rede, falhas no servidor, falta de servidor para testes, a lentidão do banco de dados do ambiente de teste ou falta de informação para implementação de uma tarefa.

SCRUM, O Tutorial®

SCRUM Master
SCRUM Master deverá remover este impedimento

Após remoção do impedimento o SCRUM podemos “registrar em base de conhecimento” a “causa raiz do impedimento”, esta informação deverá ser utilizada para melhorar o processo, logo será discutida na Retrospectiva da Sprint.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

123

Estudo de Caso: Reunião Diária
Quando todas as tarefas estão prontas, e a Equipe atualiza o Quadro de Tarefas e o Sprint Burndown.

15 Minutos

SCRUM, O Tutorial®

OK

OK

OK

?

OK

Equipe

SCRUM Master
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

124

Estudo de Caso: Reunião Diária

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

125

Reunião de Planejamento da Sprint
Exercício: O que pode acontecer se um impedimento não for removido ?

SCRUM, O Tutorial®
Quem pode cancelar a Sprint ?

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

126

Estudo de Caso: Reunião de Revisão da Sprint
Quinto passo: Após o final da Sprint (quando todas as tarefas estão prontas) começa a Reunião de Revisão da Sprint. Objetivo primário desta reunião é apresentar ao PO que foi feito durante a Sprint.

SCRUM, O Tutorial®

Planejamento da Release

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Produto Backlog Sprint Backlog Sprint 2-4 Semanas Visão Produto

5
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

127

Revisão da Sprint: Reunião da Revisão da Sprint
Produto “pronto”

SCRUM, O Tutorial®

OK

Product Owner OK OK

4 horas

Equipe

SCRUM Master

Equipe apresenta que foi produzido e faz entrega para PO, que avalia o valor da entrega. PO poderá aceitar ou rejeitar a entrega do produto.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

128

Reunião de Revisão da Sprint
A Reunião de Revisão da Sprint, para Sprints de 1 mês, essa é uma reunião com duração fixa de 4 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, a Equipe Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanças no Product Backlog 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. O Product Owner identifica o que foi feito e o que não foi feito. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, além de como esses problemas foram resolvidos. A equipe então demonstra o trabalho que está pronto e responde a questionamentos. O Product Owner então discute o Product Backlog 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.

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

129

Reunião de Revisão da Sprint
O Release Burndown é atualizado. Lembre-se: “O Release Burndown registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a organização tenham decidido usar. As unidades de tempo geralmente são Sprints. “

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

130

Reunião de Revisão da Sprint
Product Backlog é atualizado. Lembrem: “PO é responsável por manter atualizado Release Burndown e Product Backlog.”

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

131

Estudo de Caso: Reunião de Revisão da Sprint

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

132

Reunião de Planejamento da Sprint
Exercício: O que aconteceria se PO não aceitasse a entrega ?

SCRUM, O Tutorial®

Podemos considerar que a entrega da Sprint foi feita mesmo que ela não esteja em conformidade com a definição de Pronto ?

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

133

Reunião de Retrospectiva da Sprint
Sexto passo: Após a reunião de Reunião de Revisão da Sprint, é realizada a Reunião de Retrospectiva da Sprint. O propósito desta reunião é inspecionar como correu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas.

SCRUM, O Tutorial®

Planejamento da Release

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Produto Backlog Sprint Backlog Sprint 2-4 Semanas Visão Produto

6
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

134

Retrospectiva da Sprint Reunião Retrospectiva da Sprint
As retrospectivas são a essência do conceito de Inspeção e Adaptação.
impedimentos

Problemas no Servidor de Teste

SCRUM, O Tutorial®

=

SCRUM Master

????
Velocidade da equipe... Equipe

3 horas
Equipe discute o quê deu errado e o quê deu certo... O que precisa ser melhorado para a próxima Sprint
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

135

Reunião de Retrospectiva da Sprint:
A Reunião de Retrospectiva da Sprint é a última reunião de uma Sprint.

SCRUM, O Tutorial®

Nessa reunião, com duração fixa de 3 horas, o ScrumMaster deve encorajar a equipe 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. Existem diversas técnicas que são úteis em uma Retrospectiva (por ser um framework Scrum não indica diretamente nenhuma técnica)
A finalidade da Retrospectiva é inspecionar como foi 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 da equipe, os preparativos para reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para transformar itens do Product Backlog em alguma coisa “pronta”. No final da Retrospectiva da Sprint, a equipe Scrum deve ter identificado as ações de melhoria factíveis que será implementada na próxima Sprint. Essas mudanças se tornam a adaptação para a inspeção empírica.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

136

Retrospectiva da Sprint
Lições Aprendidas, o que deve melhorado para a próxima Sprint:

OK
Consulta de Reserva de Apartamento Cadastro de Fila de Espera

Pontos de Atenção
Velocidade da equipe

O Que Deve Ser Melhorado

SCRUM, O Tutorial®

=
Atitude: Para uma equipe (time) SCRUM funcionar será necessário mudança de atitude, caso contrário isto poderá afetar o desempenho da equipe Será necessário mais atenção na hora de estimar as estórias do usuário.

Cadastro de Cliente

Impedimentos:
Problemas no Servidor de Teste

Confirmação da Reserva

Planejamento: Prestar atenção na hora do planejamento da Sprint, para identificar se todos os recursos necessário estão disponíveis
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

137

Reunião de Retrospectiva da Sprint

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

138

Começar nova iteração (nova Sprint)
Repetir o ciclo Scrum:

SCRUM, O Tutorial®

Planejamento da Release

Planejamento da Sprint

Reunião diária

Revisão da Sprint

Retrospectiva da Sprint

24 horas Produto Backlog Sprint Backlog Sprint 2-4 Semanas Visão Produto

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

139

Reunião de Planejamento da Sprint
Exercício: O PO deve participar da Reunião de Retrospectiva da Sprint ?

SCRUM, O Tutorial®

Durante este estudo de caso não foi apresentado as práticas e ferramentas de Engenharia de Software, tais como TDD, SCM e etc, explique o motivo:

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

140

Quer mais ?
Os membros da comunidade podem participar dos eventos, treinamentos e cursos gratuitos. Comunidade: http://etecnologia.ning.com/

SCRUM, O Tutorial®
Para participar da comunidade basta se cadastrar: http://bit.ly/czZlez A missão da comunidade é compartilhar conhecimento, trocar experiências e prover aprendizado.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

141

Referências
Scrum Guide
Agile Collection (SCRUM, FDD e XP) nova versão
1 Scrum Experience [O Tutorial SCRUM] - Tutorial SCRUM, demonstra as práticas SCRUM para o gerenciamento de projetos de software. 2 SCRUM Product Owner: - Este eBook descreve o SCRUM enfatizando a atuação do Product Owner. É apresentado responsabilidades, técnicas e ferramentas que são utilizadas pelo PO para a garantir o ROI na gestão de projetos ág... 3 Engenharia de Software 100% Agil (SCRUM, FDD e XP) - Esta apresentação faz uma demonstração de como combinar os métodos ágeis: SCRUM, FDD e XP para tornar o Ciclo de Desenvolvimento de Software Ágil, ou seja, a Engenharia de Software 100% Ágil. 4 Engenharia de Software Ágil: SCRUM e FDD - SCRUM e o FDD são Métodos Ágeis que são utilizados para desenvolvimento de software. Fizemos uma pequena demonstração de como utilizar o SCRUM e FDD (Featured Driven Development) 5 Escrevendo Estórias do Usuário Eficazes - Este tutorial demonstra como "escrever as estórias do usuário de forma eficaz." É também apresentado as principais técnicas, boas práticas e ferramentas. 6 Workshop Como Criar, Estimar, Priorizar e Manter o Product Backlog - Este tutorial demonstra como usar as melhores práticas e técnicas para "Como criar, estimar, priorizar e manter o Product Backlog". 7 Workshop SCRUM Product Owner - Delírio de PO em dia de Verão Esta apresentação sobre o SCRUM Product Owner que aborda práticas, ferramentas e responsabilidades do PO. Também é demonstrado como os "delírios" do PO pode afetar negativamente os membros da equipe e o resultado do projeto.
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

SCRUM, O Tutorial®

142

Licença:

SCRUM, O Tutorial®

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

143

Notas:
Marcas Registradas: Todos os termos mencionados que são reconhecidos como Marca Registrada e/ou comercial são de responsabilidades de seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor que é apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo para fins educativo, não visando ao lucro, favorecimento ou desmerecimento da marca ou produto.

SCRUM, O Tutorial®

Melhoria e Revisão: Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie um e-mail para nós. Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-mail para nós. Imagens: Google, Flickr e Banco de Imagem.

Rildo F dos Santos (rildo.santos@etecnologia.com.br)
Versão 1 Nov 2010 | RFS rildo.santos@etecnologia.com.br
Todos os direitos reservados e protegidos © 2006 e 2010

144

SCRUM, O Tutorial®

O Tutorial

www.etcnologia.com.br

Rildo F Santos
(11) 9123-5358 (11) 9962-4260
rildo.santos@etecnologia.com.br twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/

Versão 1 Nov 2010 | RFS

rildo.santos@etecnologia.com.br

Todos os direitos reservados e protegidos © 2006 e 2010

Sign up to vote on this title
UsefulNot useful