SCRUM, O Tutorial v1

® l a i r o t u T O , M U R C S

O Tutorial

www.etcnologia.com.br

Rildo F Santos (11) 9123-5358

[email protected] twitter: @rildosan

Conteúdo:


1 – Desafios do desenvolvimento de Software 2 – Sobre o SCRUM 3 – Entendendo SCRUM 4 – Estudo de Caso

Objetivo:


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á.

Programa: “Menos Papel, Mais Árvores ®”


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 do homem, da tecnologia e do meio ambiente. 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 consumo sustentável de papel dentro das das organizações. organizações. Quer participar ? - Reduza o uso de papel (e de madeira) o máximo possível. - Só imprima se for extremamente extremamente necessári necessário. o. - Evite comprar produtos com excesso de embalagem. - Ao imprimir ou escrever, escrever, utilize os dois lados do papel. - Use papel papel reciclado. reciclado. Este material não deve ser impresso..

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 experiência em Gestão de Negócios, Gestão de Inovação, I novação, Governança 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).


Conheço Métodos Ágeis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), Processo Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias. Sou professor de curso de MBA da Fiap e f ui professor de pós-graduação da Fasp e IBTA. Tenho conhecimento 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 Risk ando Compliance), Compliance), SOX, Basel II e PCI; 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, Financeiro, Telecomunicações, Telecomunicações, Seguro, Saúde, Comunicação, Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás. Possuo as certificações: certificações: CSM - Certified Certified SCRUM Master, CSPO CSPO - Certified Certified SCRUM Product Product Owner , SUN Java Certified Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games; Sou membro do IIBA-International IIBA-International Institute of Business Analysis Analysis (Canada) Onde estou: Twitter: @rildosan @rildosan Blog: http://rildosan.blogspot.com/ Comunidade: http://etecnologia.ning.com

Conteúdo:



Objetivo:


Parte 1 - Desafios Desafios do desenvolvime desenvolvimento nto de Software Objetivo: Apresentar e discutir os principais desafios dos projetos de desenvolvimento de software. Pré-requisito: Não há.


Desafios do Desenvolvimento de Software

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 ® l a Para ontem... i r o t u T Quanto custará ? O Todo cliente quer saber quanto custará , M o software... U R C S O primeiro desafio desafio é conseguir conseguir responder qual é o custo do software e em quanto tempo o cliente vai ter o software funcionando.

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


3º. Desafio: Entender as necessidades dos clientes


Quando não se entende as necessidades dos clientes, não se pode entregar valor ao cliente.

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

Informação errada 13%


Outros 50%

37% das falhas estão relacionadas com requisitos

Falta de competência 6%

Falta de conhecimento técnico 7%

Requisitos incompletos 12%

Mudança de Requisitos 12%

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%

Freqüentemente 13%

Nunca 45%

As vezes 16% Raramente 19%

13

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


Como aumentar a produtividade da equipe de desenvolvimento de software ?

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


The The Myth Mythic ical al Man Mont Month h by Fred Frederi erick ck Brook Brooks, s, 1975*. 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, orientações, comunicação e treinamento 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 "Adicionar novas pessoas a um projeto de software softw are atrasado só adiará a sua entrega." – A Lei de Brooks

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

UP ® l a i r o t u T O , M U R C S

RUP

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

8º. Desafio: Como reter os bons profissionais ? Quantas vezes já montamos boas equipe, mas de repente as pessoas começam a sair...a sair...a trocar de emprego. A retenção de bons profissionais é grande desafio da atualidade, 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

® c hefe e não l emprego. A maioria das pessoas mudam de emprego por problema com o seu chefe a por motivo de salário. i r o t u T O , M U R C S

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

t Para enfrentar estes desafios: u T O Utilização de métodos ágeis, , como SCRUM, pode amenizar M estes problemas. U R C S

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

® l a - Sempre precisam do software software funcionando para ontem i r o t tempo e nem paciência paciência para falar falar com os u - Não têm tempo T desenvolvedores. O , M U Desenvolvedores: R - Não sabem sabem ou não querem querem conversar conversar com o cliente cliente C S

- Dificilmente Dificilmente conseguem conseguem atender atender o negócio e todas suas demandas - Têm dificuldade dificuldade em em se comunicar e entender entender os clientes clientes

Como enfrentar estes desafios: “O SCRUM é sua sogra” O SCRUm pode ser uma forma para enfrentar estes desafios, O SCRUM SCRUM não va vaii 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.. 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 ® l melhor: tomarem atitudes) os problemas continuaram a existir e levaram a maioria dos a projetos para a “marcha da morte”. i r o t u O Scrum vai deixar todos os problemas aparentes. T O , M U R C S

Se trabalhamos com desenvolvimento desenvolvimento Ágil: Logo temos: Colaboração com cliente: A estória do Usuário é escrita escrita em colaboração entre os desenvolvedores e o cliente (PO). A prioridade prioridade é satisfazer o cliente, entregando o mais rápido possível e de forma contínua c ontí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. ® l

a i Conversa face-a-face face-a-face é SEMPRE a melhor melhor forma forma de comunic comunicação: ação: r - Conversa feita na Reunião de Planejamento (Planning Meeting). o A estória do usuário geralmente é feita t u T O Aqui entra a Estória do Usuário: , M Prioridade: Alta Titulo: Pagamento com Cartão de Crédito U R C Como cliente de negócio eu e u gostaria de fazer pagamento com Cartão S 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.

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

® l a i r o t u T O , M 2 – Por que a especificação de requisitos de software não é solução para os problemas de U comunicação ? R C S

Conteúdo:



Objetivo:


Parte 2 – Sobre SCRUM: Objetivo: Apresentar Manifesto Ágil e o SCRUM, as principais características e práticas. Pré-requisito: Não há.

Parte 2


Sobre o SCRUM

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


SmallTalk Engineering Tools

Desenvolvimento iterativo e incremental

Reunião diária 24 horas

Produto Backlog

Sprint Backlog 2-4 Semanas

Produto

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. 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: são: - Reunião de Planejamento da Release, - Sprint (iteração), - Reunião de Planejamento Planejamento da Sprint, - Revisão da Sprint. - Retrospectiva da Sprint. - Reunião Diária.

® l a i r o t u T O Exemplos de Timebox: , A Sprint (que é uma iteração) que deve ser realizada de 2 a 4 semanas, no qual a M equipe de desenvolvedores deverá produzir um entregável de valor para o cliente U (mais frente discutiremos melhor isto). R A entrega de valor é a meta da Sprint, Sprint, a duração da Sprint deverá ser combinada C com o cliente, antes do começo da execução da Sprint. S 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, Diárias , uma reunião diária tem a duração fixa de 15 minutos. Ao final da Sprint, Sprint, é feita a reunião de Revisão da Sprint. Sprint . Para Sprints de um mês, essa é uma reunião com duração fixa de quatro horas. horas . Após a Revisão da Sprint e antes da próxima Reunião de Planejamento da Sprint, Sprint, a Equipe Scrum tem a Reunião de Retrospectiva da Sprint. Sprint . essa reunião, te duração fixa de três horas. horas .

Abordagem Iterativo e Incremental: Entrega 1

Entrega 2

Entrega 3

Incremental


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 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 cada iteração é feito um novo incremento (uma parte do software funcional) até completar o software.

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 é transparecer a eficácia relativa das suas práticas de ® l fazer transparecer a desenvolvimento para que você possa melhorá-las, enquanto i r provê um framework dentro do qual produtos complexos o podem ser desenvolvido t desenvolvidos. s. u T O , M Por ser um framework, o SCRUM não é uma ferramenta, nem U metodologia, nem processo e nem uma solução solução completa para o R C desenvolvimento de software, ele é um framework (uma estrutura), S 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.

Qual é a teoria do SCRUM ? A TEORIA DO SCRUM: Scrum, que é fundamentado na teoria de controle de processos empíricos*, 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 tipos de processos: Processo Definido: São processos que se conhece todas as variáveis, têm poucas ou nenhuma ® l mudança ao logo do processo, são repetitivos e são previsíveis. a Geralmente existe uma documentação aplicada a execução do processo. i r o Exemplo: Linha de produção t u T O *Processos Empíricos: , São aqueles processos que não se conhece todas as variáveis, têm M mudanças ao logo do processo, não são repetitivos e são imprevisíveis. U Geralmente baseado na experiência e no conhecimento de quem executa o R processo. C S 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 s e comporta de forma imprevisível.

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


Os pilares do SCRUM: Três pilares sustentam qualquer 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.


Esses aspectos aspectos não apenas devem 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 do processo devem ser inspecionados inspecionados com uma 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.

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


Se o “inspetor” determinar, 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.

3

1

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.

O Manifesto Ágil:


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

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 softw are 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 à

® menor escala de tempo. l a i r  Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. o  Construa projetos em torno de indivíduos motivados. t u T  Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O  O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento desenvolvimento , M é através de conversa face a face. U  Software funcionando é a medida primária de progresso. R desenvolvimento sustentável. C  Os processos ágeis promovem desenvolvimento S  Os patrocinadores, desenvolvedores 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 maximizar a quantidade de trabalho não realizado realizado -- é essencial. essencial.



As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. 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.

Como Ser Ágil ? Como ser ágil ? 1 - Para “ser ágil” é preciso colocar em prática os valores e os princípios do Manifesto Ágil. Á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 Vejamos o que diz o Manifesto Ágil: “ Entregar 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, á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.

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


Como Ser Ágil ?


Engenharia de Software 100% “Ágil:

O SCRUM é utilizado para Gestão de Projetos. Projetos. Já para as práticas de Engenharia de Software podemos utilizar o FDD para os requisitos de software e arquitetura e as Prátic Práticas as do XP para o desenvolvimento de software (codificação, (codificação, testes e refactoring). refactoring ).

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 Tradicional e de auto Gestão: Tradicional

auto Gestão

® l a i r o t u T O , M U R Método de Gestão de Projetos Tradicionais. Método Ágil Tradicionais. C - Não tem - ter auto auto gestã gestão, o, tem auto gestão. gestão. S - ser Auto organiza organizada; da; - Não são auto-or auto-organiz ganizadas. adas. - ser Interdisci Interdisciplin plinar ar - São fortemente hierarquizada. Com liderança - não ter Hierarq Hierarquia uia formal, formal, baseada no “comando-controle”. - ter responsab responsabilid ilidade. ade. - Equipe Equipe formada por especialis especialistas. tas. O Comando-controle: Comando-controle: Pode levar ao baixo A auto gestão: 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.

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: 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 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 ® l trabalho. a Equipe de desenvolvedores é muito parecida com um equipe de Volley i Volley Ball, r o onde todos tem um único objetivo e são interdisciplinares no jogo. t u Interdisciplinares e Sem hierarquia formal: T Interdisciplinares Equipes também são interdisciplinares: os membros da equipe devem ter todo o conhecimento e O habilidades necessárias para entregar a meta da Sprint. Sprint. , M Membros da equipe geralmente possuem conhecimentos especializados, tais como: programação, U testes, controle de qualidade, análise de negócios, arquitetura, desenho de interface de usuário e R modelagem de dados. No entanto, o conhecimento que os membros devem compartilhar - isto é, a C habilidade de trabalhar um item do Product Backlog (ou um requisito) e transformá-lo em um produto S (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, contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas. Na equipe não há hierarquia nem títulos, 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 responsável transformar os itens do Product Backlog em funcionalidades potencialmente entregáveis a cada Sprint.

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


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

Algumas empresas que estão usando SCRUM:


Quais empresas empresas estão estão utilizand utilizando oo SCRUM? Algumas Algumas empresa empresass brasileira brasileirass

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*

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 ® l clubes brasileiros e iniciar os seus treinamentos junto às equipes de base. a i r o Considerando que hoje esse processo de detecção difere em muito daqueles praticados anteriormente, t u T 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 O em relação aos selecionados, chegaríamos certamente a esta conclusão. , M U O objetivo deste texto é relatar os diversos mecanismos de captação de talentos em prática nos grandes R clubes do futebol profissional brasileiro. Dentre os mecanismos, destacamos cinco principais e dois C secundários. Podemos destacar alguns dos principais: as avaliações “peneiras”; campeonatos e jogos S 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 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+ http://www.universidadedo futebol.com.br/2010/07/1,14757,UM+RELATO+SOBRE+O+PROCESSO O+PROCESSO+DE+CAPTACAO +DE+CAPTACAO+DE+TALENTOS +DE+TALENTOS+NO+FUTE +NO+FUTEBOL.aspx?p=1 BOL.aspx?p=1

Conteúdo:



Objetivo:


Parte 3 – Entendendo SCRUM Objetivo: Apresentar Apresentar de forma forma detalhad detalhadaa o framework framework SCRUM segundo segundo o Guia Guia do Scrum. Scrum. Pré-requisito: Não há.

Parte 3


Entendend endo o SC SCRUM

Frame Framework work Scrum Scrum:: O framewor frameworkk Scrum Scrum é formad formadoo por um conjunto conjunto pela pela Equipe (Time) Scrum e seus papéis: Product Owner (PO), Scrum Scrum Master (SM) (SM) e equipe de de desenvolve desenvolvedores dores,, eventos com duração Fixa (TimeBoxes), artefatos e regras. Reunião diária

Planejamento da Sprint

® l a i r o t u T O , M Legenda: U R Reuniões C Artefatos S

Retrospectiva da Sprint

24 horas Visão

Produto Backlog

Sprint Backlog 2-4 Semanas

Eventos (Reuniões)

Papéis • Product Owner (PO) • ScrumMaster (SM) • Equipe Scrum

Revisão da Sprint

Planejamento da Release  Planejamento da Sprint  Diária  Revisão da Sprint  Retrospectiva da Sprint 

Produto

Artefatos • Product Backlog • Sprint Backlog Sprin rintt Bu Burn rndo down wn • Sp • Release Burndown

Sprint Sprint Burndown Burndown Release Burndown

Framework Framework Scrum: Scrum: Eventos Eventos de Duração Fixa: Fixa:


Regras

Framework Framework Scrum: Scrum: Regras 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 desenvolvimento podem falar falar durante uma Reunião Diária. - Equipe Equipe deve possuir auto-gestã auto-gestão.; o.; - Somente Somente o PO (Product (Product Owner) Owner) defini definirr e alterar alterar a prioridad prioridadee dos dos itens itens do Product Product Backlog. Backlog. - Uma pessoa pessoa não não pode pode desempen desempenhar har o papel papel de PO PO e de Scrum Scrum Master no mesmo mesmo projeto. projeto. Somente o PO PO pode cancelar cancelar uma uma Sprint. Sprint. ® l - Somente a i r o t u T O , M U R C S

Framework Framework Scrum: Scrum: Papéis Papéis e Equipe Equipe


Papéis e Equipe

Papéis SCRUM: Papéis Equipe Scrum são projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são auto-organizáveis, auto-organizáveis, interdisciplinares e trabalham em iterações. iter ações. Cada equipe possui três papéis:


Produc Prod uctt Own Owner er (P (PO) O),, que é responsável por maximizar o valor do trabalho que a equipe faz, PO também é responsável responsável por: - Defin Definirir a Visão Visão do Produto Produto - Ela Elabor borar ar , Prio Prioriza rizarr e man manter ter o Pro Produc ductt Bac Backlo klogg - Def Defini inirr ROI; ROI; - Repres Representar entar o cliente 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 Remover impediment impedimentos; os; - Proteger a equipe; - Ajuda Ajudarr o PO (quando necessário); - Ser o facilitador facilitador da da equipe. equipe. A equipe (ou time), time), é responsável pelo desenvolvimento do produto, é formada por desenvolvedores desenvolvedores que devem devem ter as habilidades necessárias para transformar transformar os itens do Product Product Backlog Backlog em Produto. Produto. A Equipe ainda é responsável por: -Fazer estimativa; - Definir Definir as tarefas; tarefas; - Garantir a qualidade do produto; - Apresentar o produto ao cliente

A Equip Equipee SCRUM SCRUM:: Scrum ScrumMas Master ter (SM) (SM) e Produ Product ct Owner Owner (PO): (PO):


O ScrumMaster é responsável responsável por garantir garantir que o Equipe Scrum esteja esteja aderindo aos valores do Scrum, às práticas e às regras. O ScrumMaster ajuda a Equipe Scrum e a organização organização a adotarem o Scrum. Scrum. O ScrumM ScrumMaster aster educa a Equipe Equipe Scrum Scrum treinando-o treinando-o e levando-o levando-o a ser mais produtivo produtivo e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda a Equipe Scrum Scrum a entende entenderr e usar usar auto-ge auto-gerenc renciam iament entoo e interdi interdisci scipli plinar narida idade. de. 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 ScrumMaster ajuda a realizar realizar essas mudanças, mudanças, isso é chamado chamado de “remoção de impedimentos”. No entanto, o ScrumM ScrumMast aster er não gerenci gerenciaa a Equipe Equipe Scrum; a Equipe Scrum é auto-organizáve auto-organizável.l. Productt Owner Owner (PO) é a única pessoa responsável pelo gerenciamento do O Produc Product Backlog Backlog e por garantir garantir o valor do trabalho trabalho realizado realizado pela Equipe. O PO mantém o Product Product Backlog Backlog (PB) e assegura que ele está visível 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 Product Owner deve ser uma pessoa, pessoa, e não um comitê. comitê. Podem existir existir comitês comitês que aconselhem ou influenciem , mas somente o PO poderá mudar a prioridade de um item do PB. Empresas Empresas que adotam Scrum podem perceber perceber que isso influencia influencia seus métodos para definir prioridades e requisitos ao longo do tempo. Para que o PO obtenha sucesso, todos todos na organização precisam respeitar suas decisões. decisões. Somente Somente o PO pode definir definir a prioridade prioridade dos itens que a equipe equipe irá trabalhar. As decisões decisões do Product Owner são visíveis visíveis no conteúdo conteúdo e na priorização priorização do Product Backlog. Backlog. Essa visibil visibilidade idade requer requer que o Product Product Owner Owner faça seu seu melhor, melhor, o que faz o papel de “ Prod Produc uctt Owne Ownerr “ exigente e recompensador ao mesmo tempo.

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

Spri Sprint ntss .


A equipe deve ser interdisciplinar: os membros da equipe equipe devem ter todo o conhecimento e habilidades necessárias para entregar a meta da Sprint. 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 conheciment conhecimentoo que os membros membros devem compartilhar compartilhar - isto é, a habilidade habilidade de trabalhar trabalhar um item do Product Product Backlog Backlog (ou um um requisito requisito)) e transformá-l transformá-loo em um produto (software funcionando) tendem a ser mais significativas 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 iguais e não há exceções a essa regra. As equipes equipes também não devem ter sub-equipe dedicados a áreas particulares 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 haver interferência extern externa, a, nem nem o ScrumMas ScrumMaster ter ou Produc Productt Owner Owner – ninguém pode dizer como a equipe deve se organizar ou fazer inferência na forma de trabalho trabalho da equipe. A equipe deve deve ser capaz de se auto-organizar para dividir dividir e fazer trabalho. A equipe deve ser autosuficiente, cada membro da equipe aplica aplica sua especialidade a todos os problemas. A sinergia que resulta resu lta disso melhora a eficiência e eficácia geral da equipe como um todo.

Equipe: Comprometimento e Tamanho:

® Envolvidos Comprometidos l a i r o t Stakeholders Product Onwer u (clientes e usuários finais) T O , M Equipe SCRUM Master U R O tamanho ótimo para uma equipe é de 7 pessoas, mais ou menos duas pessoas. Quando há C menos do que cinco membros em uma equipe, há menor interação e, como resultado, há menor S ganho de produtividade. produtividade. Mais do que isso, a equipe poderá encontrar 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 ScrumMaster não estão incluídos incluídos nessa conta, a menos que também sejam porcos. porcos. A composição da equipe pode mudar ao final da Sprint. Toda vez que a equipe equipe muda, a produtividade ganha através da auto-organização é reduzida. Deve-se tomar cuidado ao mudar a composição da equipe.



Eventos

Event Eventos: os:Vi Visão são Geral Geral


Eventos com duração fixa (time-boxes) : Os eventos com duração fixa são utilizados 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 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 Todas as Sprints utilizam o mesmo modelo modelo de Scrum Scrum e todas todas as Sprints Sprints têm como como resultado resultado um incremen incremento to do produto produto final que é potencialmente entregável. Cada Sprint começa imediatamente após a anterior.

Reunião Diária

Sprint

Product Product Backlog Backlog

Sprint Sprint Backlog Backlog

Produto

Framework Framework Scrum: Scrum: Eventos Eventos de Duração Fixa: 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 cliente e o Retorno Retorno sobre ® l Investimento (ROI) desejados?” a i r O Plano da Release, Release, que é o artefato resultante dessa reunião, estabelece a meta da release, as o t maiores prioridades do Product Backlog, os principais riscos e as características gerais e u T funcionalidades que estarão contidas na release. Ele estabelece também uma data de entrega e O 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. M U O planejamento da release é opcional. opcional . Contudo, se a equipe Scrum iniciar o trabalho sem essa R reunião, a ausência de seu artefato aparecerá como um impedimento que deverá ser resolvido. C S 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 entreg egáv ável el do adicionando incrementos ao produto. Cada incremento é um “pedaço” potencialmente entr 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.

Framework Framework Scrum: Scrum: Eventos Eventos de Duração Fixa: 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 realiza um planejamento planejamento diário no momento momento da execução 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 r elease tradicional. O planejamento planejamento da release requer estimar estimar e priorizar priorizar o Product Product Backlog Backlog para a release. 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

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

Release #1

Release #2

Release #3

Visão do Planejamento

Product Backlog Release BurnDown

Spri Sp rint nt #

1

2

3

4

5

6




Reunião diária

Revisão da Sprint


24 horas Visão

Produto Backlog

Sprint Backlog Sprint 2-4 Semanas

Produto

Framework Framework Scrum: Scrum: Eventos Eventos de Duração Fixa: Fixa: REUNIÃO DE PLANEJAMENTO DA SPRINT A Reunião de Planejamento Planejamento da Sprint é o momento no qual a iteração é planejada. É fixada em oito horas de duração duração para uma Sprint Sprint de um mês. Para Sprints Sprints mais curtas, curtas, aloca-se aloca-se para essa reunião aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes. A primeira parte, um evento 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 equipe Scrum trata da questão: questão: “o quê?”. ® l Product Owner Owner apresenta apresenta a equipe equipe o que é mais priori prioritário tário no Product Product Backlog. Backlog. a O Product i r Eles trabalham em conjunto conjunto para definir qual funcionalidade deverá ser desenvolvida durante a o t próxima Sprint. As entradas para essa reunião são o Product Back, o incremento mais recente ao u T produto, a capacidade da equipe e o histórico de desempenho da equipe. Cabe somente a equipe a decisão decisão de quanto itens do Product Product Backlog Backlog ela deve selecionar selecionar.. O Somente a Equipe pode avaliar o que ele é capaz de realizar na próxima Sprint. , M U Meta da Sprint: R Uma vez seleci seleciona onado do o Produc Productt Backlo Backlogg , a Meta Meta da Sprint Sprint é deline delineada ada.. A Meta Meta da Sprint Sprint é o C objetivo que será atingido através da implementação do Product Backlog. Ela é uma descrição que S fornece orientação a equipe sobre a razão pela qual ele está desenvolvendo o incremento. A Meta da Sprint é um subconjunto subconjunto da Meta da Release. Release. O motivo para se ter uma Meta da Sprint é dar a equipe alguma margem com relação à funcionalidade. 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 Product Owner Owner e implementa implementarr a funcionali funcionalidade dade apenas parcialment parcialmente. e.



REUNIÃO DE DE PLANEJAMENTO PLANEJAMENTO DA SPRINT 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á 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 Ess a lista de tarefas é chamada de Sprint Incluir novo cliente Backlog que é um artefato do SCRUM. A equipe equipe se auto-organiza para se encarregar e se responsab responsabiliza ilizarr pelo pelo trabalho trabalho contid contidoo na Sprint Sprint Backlog Backlog , tanto tanto durante durante a Reuniã Reuniãoo de Planejamen Planejamento to da Sprint Sprint quanto quanto no próprio próprio momento momento da execução execução da Sprint. Sprint. O Produc Productt Owner Owner está está presen presente te durant durantee a segund segundaa parte parte da Reuniã Reuniãoo de Planej Planejame amento nto da Sprint Sprint para para esclare esclarecer cer o Produc Productt Backlo Backlogg e para para ajudar ajudar a efetuar trocas. Se a equipe concluir que ele tem trabalho demais ou de menos, ele pode pode renego renegocia ciarr os itens itens do Produc Productt Backlo Backlogg escolh escolhido ido com o Produc Productt Owner Owner.. A equipe também pode convidar outras pessoas , tais como clientes 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 equipe - não individu individualment almentee - nessa reunião. reunião. A equipe equipe percebe 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: reunião: Sprint Backlog

consultar cliente

alterar cliente Fazer Testes Unitários




Reunião diária

Revisão da Sprint


24 horas Visão

Produto Backlog


Produto

Framework Framework Scrum: Scrum: Eventos Eventos de Duração Fixa: Fixa: A SPRINT A Sprint Sprint é uma iteração. iteração. Sprints Sprints são eventos eventos com duração duração fixa. fixa. Durante Durante a Sprint, Sprint, o ScrumMaster ScrumMaster garante que não será feita nenhuma mudança que possa afetar afetar a Meta da Sprint. Tanto Tanto a composição da equipe quanto as metas de qualidade devem permanecer constantes durante a Sprint. As Sprints Sprints contêm e consistem consistem na reunião reunião de Planejamen Planejamento to de Sprint, Sprint, o trabalho trabalho de desenvolvi desenvolvimento mento,, a Revisão Revisão da Sprint Sprint e a Retrospect Retrospectiva iva da Sprint. Sprint. As Sprints Sprints ocorrem 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 l a que será desenvolvido, um plano para desenvolvê-lo, o trabalho realizado de acordo com o i r plano e o produto resultante. Cada projeto possui um horizonte, que é o período de tempo para o t qual o plano plano é válido. válido. Se o horizonte horizonte for longo demais, a definição poderá ter mudado, variáveis u o qual T demais demais poderão poderão ter surgido, surgido, o risco poderá ser grande demais demais etc. etc. Scrum é um um framework framework para já há complexidade suficiente tal O projetos cujo horizonte não é superior ao período de um mês, onde já , que um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve ser M controlada pelo pelo menos a cada mês, e o risco de que o projeto saia de controle ou se torne U imprevisível é contido pelo menos a cada mês. R C Sprints podem ser ser canceladas canceladas antes que que o prazo fixo da Sprint tenha acabado. acabado. Somente o S As Sprints Product Product Owner tem a autoridade autoridade para cancelar cancelar a Sprint Sprint,, embora ele possa fazê-lo sob influência das partes interessadas, da equipeou do ScrumMaster. ScrumMaster. Sob que tipo de circunstâncias circunstâncias pode ser necessário cancelar uma Sprint? A gerência pode precisar cancelar uma Sprint se a Meta da Sprint 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 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




Reunião diária

Revisão da Sprint


24 horas Visão

Produto Backlog


Produto

Framework Framework Scrum: Scrum: Eventos Eventos de Duração Fixa: 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.


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 transforma transformando ndo os itens do Product Product Backlog Backlog um incremen incremento to (a equipe), equipe), e para mais ninguém. ninguém. A equioe equioe se comprometeu comprometeu com uma Meta da Sprint, Sprint, e a esses itens do product Backlog. 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.




Reunião diária

Revisão da Sprint


24 horas Visão

Produto Backlog


Produto

Framework Framework Scrum: Scrum: Eventos Eventos de Duração Fixa: Fixa: REVISÃO DA SPRINT Ao final da Sprint, é feita a reunião de Revisão Revisão da Sprint. Para Sprints 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 deve tomar mais do 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 eles colaboram sobre quais são as próximas coisas que podem ser feitas. Essa é uma reunião informal, com a que tem a intenção de promover a colaboração sobre o que fazer em ® l apresentação da funcionalidade, que a seguida. i r o A reunião inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o t u T 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 O que está pronta e responde responde a questioname questionamentos ntos.. O Product Product Owner Owner então discute discute o Product Product Backlog Backlog , M da maneira como esse se encontra. várias hipóteses de velocidade. Em U Ele faz projeções de datas de conclusão prováveis a partir de várias R seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa significa com relação ao que fazer C em seguida. A Revisão da Sprint fornece entradas valiosas para as reuniões de Planejamento de S Sprints Sprints seguintes. seguintes.




Reunião diária

Revisão da Sprint


24 horas Visão

Produto Backlog


Produto

Framework Framework Scrum: Scrum: Eventos Eventos de Duração Fixa: Fixa: RETROSPECTIVA DA SPRINT Após a Revisão Revisão da Sprint e antes da próxima próxima reunião de Planejamento Planejamento da Sprint, a equipe 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, 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 Retrospectiva. ® l diversas técnica que são úteis em uma Retrospectiva. a i r A finalidade da Retrospectiva é inspecionar como foi a última Sprint em se tratando de pessoas, o das relações entre elas, dos processos e das ferramentas. A inspeção deve identificar e priorizar t u T 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 O reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para , transformar itens itens do Product Product Backlog Backlog em alguma coisa “pronta”. M transformar U R No final da Retrospectiva Retrospectiva da Sprint, a equipe Scrum deve ter identificado as ações de melhoria C factíveis que será implementada na próxima Sprint. Essas mudanças se tornam a adaptação para S a inspeção empírica.

Framework Framework Scrum: Scrum: Artefat Artefatos os


Artefatos

Framework Framework Scrum: Scrum: Artefat Artefatos os

® l a i r o t u T O , M U R C artefatos principais: principais: S Scrum tem quatro artefatos - Produc Productt Backlo Backlog g: é uma lista priorizada de tudo que pode ser necessário no produto. - Sprint Sprint Backlo Backlog g: é uma lista de tarefas tarefas para transformar transformar o Product Product Backlog Backlog , por uma Sprint, Sprint, em um incremento do produto potencialm potencialmente ente entregável entregável.. Um burndown burndown é uma medida do backlog backlog restante restante pelo tempo. tempo. - Release Burndown: Mede o Product Product Backlog Backlog restante restante ao longo longo do tempo tempo de um um Plano Plano de Release do Produto. - Sprint Sprint Bu Burnd rndown: own: Mede os itens itens da Sprint Backlog Backlog restantes restantes ao longo longo do tempo de de uma Sprint. Sprint.

Framework Framework Scrum: Scrum: Artefat Artefatos os PRODUC PRODUCT T BA BACKL CKLOG OG e RELEA RELEASE SE BURND BURNDOWN OWN Os requisitos para o produto que a equipe está desenvolvendo estão listados no Product Backlog O Product Product Owner (PO) é o responsáv responsável el pelo Product Product Backlog Backlog , por sua criação, 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 requisitos inicialment inicialmentee conhecidos conhecidos e melhor melhor entendidos. entendidos. O Product Product Backlog Backlog evolui evolui à medida medida que o produto produto e o ambiente ambiente em que ele será usado evoluem. evoluem. O Backlog Backlog é dinâmico, dinâmico, no sentido sentido de ® l que ele está constantemente mudando para identificar o que o produto necessita para ser a apropriado, apropriado, competitiv competitivoo e útil. útil. Enquant Enquantoo existir existir um produto, produto, o Product Product Backlog Backlog também também existir existirá. á. i r o t Product Backlog Backlog representa representa tudo que é necessário necessário para desenvolver desenvolver e lançar um produto produto de u O Product T sucesso. É uma lista de todas as características, funções, tecnologias, melhorias e correções de O defeitos que constituem as mudanças que serão efetuadas no produto para releases futuras. Os , itens do Product Product Backlog Backlog possuem possuem os atributos atributos de descrição, priorid prioridade ade e estimativa. estimativa. A prioridade prioridade é M determinada por risco, valor e necessidade. Há diversas técnicas para dar valor a esses atributos. U R O Produc Productt Backlo Backlog g é ordenado por prioridade, os itens com as maiores prioridades devem ter o C desenvolvimento imediato. S Quanto mais alta sua prioridade, mais urgente ele é, mais se pensou sobre ele e há mais consenso no que diz respeito ao seu valor. valor. Os itens do Backlog de maior prioridade, possuem mais informações informações e detalhes detalhes do que os itens do Backlog Backlog de menor prioridade. prioridade. É mais mais fácil de fazer a estimativa quando existem mais informações informações e mais detalhes.

Framework Framework Scrum: Scrum: Artefat Artefatos os PRODU PRODUCT CT BA BACKL CKLOG OG e RELEAS RELEASE E BUR BURND NDOWN OWN (conti (continua nuação ção): ): Quando um produto é utilizado, que seu valor aumenta e que o cliente fornece feedback, o Product Product Backlog Backlog poderá poderá se tornar uma lista maior e mais aprofundada aprofundada.. Os requisitos requisitos nunca param de mudar. mudar. O Product Product Backlog Backlog é um documento documento vivo. Mudanças Mudanças nos requisitos requisitos de negócios, 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 itens do Produc Productt Backlo Backlogg que ocupar ocuparão ão a Equipe Equipe Scrum Scrum pelas pelas várias várias Sprint Sprintss seguin seguintes tes deverã deverãoo 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 itens é aplicado aplicado no Backlog Backlog do Produto. 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.

® l a i r o t u T O , M U O gráfico de Release Burndown registra a soma das estimativas dos esforços restantes do Product R Backlog ao longo do tempo. O esforço estimado deve deve estar em qualquer qualquer unidade de medida de C trabalho que a equipe e a organização tenham decidido usar. As unidades de tempo geralmente S são Sprints. As estimativ estimativas as dos itens do Product Product Backlog Backlog são inicialmente inicialmente calculadas calculadas durante durante o Planejamento da Release, Release, e posteriormente à medida que itens forem sendo criados. Durante a preparação do Product Product Backlog Backlog , os itens são revistos revistos e revisados. 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 Produc Productt Backlo Backlogg e o Releas Releasee Burndo Burndown wn do Backlo Backlogg atuali atualizad zados os e public publicado adoss todo o tempo. tempo. Uma linha de tendência pode ser traçada baseada baseada na mudança do trabalho restante.

Framework Framework Scrum: Scrum: Artefat Artefatos os PRODUCT PRODUCT BA BACKLO CKLOG: G: Exemplo Exemplo

Produc Productt Backlo Backlog g


Tema*

Item

Prioridade

Pontos (estimados)

Venda de Passagem Venda de Passagem Check-in

Vender passagens áreas

Alta

40

Consulta Consulta de disponibil disponibilidade idade de passagens áreas Fazer check-in

Alta

13

Alta

40

Check-in

Cancelar Check-in

Alta

8

Progra Programa ma de Fidelidade Progra Programa ma de Fidelidade Atendimento ao cliente

Adesão Adesão ao programa programa de fidelidade Consultar Consultar os pontos pontos do programa de fidelidade Fazer registro de comentários, sugestões sugestões e reclamações reclamações dos clientes Responder Responder ao cliente cliente (por email)

Média

20

Média

5

Baixa

8

Baixa

5

Atendimento ao cliente Nota: O que é Tema ?

Tema é utilizado para agrupar “Estórias do Usuários” relacionadas, as estórias são representam o detalhamento detalhamento dos itens do Backlog, ao ao usar o conceito de “tema”, ele poderá facilitar as atividades de priorização e de estimativa.

Framework Framework Scrum: Scrum: Artefat Artefatos os RELEASE BURNDOWN: Exemplo

Release Burndown Release Burndown registra a soma das estimativas dos esforços restan restantes tes do do Produ Product ct Backl Backlog og 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.

150


139

100

) s o d a m i t s e ( s o t n 50 o P

90

52

20 0

Spri Sp rint nt #1

Spri Sp rint nt #2

Sprin Sp rintt #13 Sprints

Spri Sp rint nt #4

Framework Framework Scrum: Scrum: Artefat Artefatos os SPRINT SPR INT BA BACK CKLOG LOG E SPRINT SPRINT BU BURND RNDOWN OWN:: A Sprint Sprint Backlo Backlog g 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 novo trabalho surge, a equipe equipe o adicion adicionaa a Sprint Sprint Backlog. 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 verifica que determinadas tarefas são desnecessárias, elas são removidas. Somente Somente a equipe equipe pode modificar modificar a Sprint Sprint Backlog Backlog durante durante uma Sprint, Sprint, pode mudar o seu conteúdo conteúdo ou as suas estimativas. estimativas. A Sprint Backlog Backlog é um retrato retrato em tempo real altamente altamente visível visível do trabalho que a equipe planeja efetuar durante a Sprint, e ela pertence unicamente a equipe.

Framework Framework Scrum: Scrum: Artefat Artefatos os SPRINT SPR INT BA BACK CKLOG LOG E SPRINT SPRINT BU BURND RNDOWN OWN:: Exempl Exemplo o


Na reunião de Planejamento da Sprint , PO deverá deverá apresen apresentar tar a visão do produto, produto, Product Product Backlog 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 Estória do Usuário Usuário Titulo: “Fazer Check-in”

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

Prioridade: Alta

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

Framework Framework Scrum: Scrum: Artefat Artefatos os SPRINT SPR INT BA BACK CKLOG LOG E SPRINT SPRINT BU BURND RNDOWN OWN:: Exempl Exemplo o Estória Estória do Usuário Usuário Titulo: “Fazer Check-in”


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

Prioridade: Alta

Fazer interface do usuário

Fazer Check-in

Impressão do Ticket

Criar Componentes de validação

Executar testes unitários

Integrar com Sistema de Reserva

Executar testes de aceitação

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

Sprint Backlog

A Sprint Sprint Backlo Backlog g é um artefato resultante da reunião de Planejamento da Sprint

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 desenvolvimento de software) algumas pessoas acham que representa 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 ® l parâmetro, podemos chegar a conclusão se estória cabe ou não dentro da Sprint. Se ela não couber a a opção é quebrar esta estória em estórias menores. i r o t u Exemplo de Estórias do Usuário: T O Prioridade: ? Titulo: Pagamento com Cartão de Crédito , M Quem ? U R como um cliente C O que ? S 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

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. Estória . Recomendamos utilizar os Pontos de Estória. 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”...

® l a i r o t u T O , Pontos de Estória: M ◦ Valores relativos U ◦ Mais abstrato R C S

- É mais fácil de estimar, estimar, mas pode ser tornar tornar difícil de estimar estimar se consideramos todas as interrupções e variações

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

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 esc rever as estórias do usuário. O Planning Poker é uma “prática” que ajuda ajuda na estimativa de uma estória 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,...) (1,2,3,5,8,13,...) + 20, 40, 100 ou em outra outra escala Jogando o Planning Poker: Antes de começar o jogo é necessário definir um valor de referência. Por exemplo: exemplo: Identificar a estória que pode ser atribuído a menor quantidade pontos, esta estória será utilizada 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... 40

1ª. Rodada

100

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

40

Product Owner

Equipe

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.

40

Nª. Rodada

40

40

40

Equipe

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


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

Prioridade: Alta

Fazer interface do usuário

Fazer Check-in

Impressão do Ticket

Criar Componentes de validação


Integrar com Sistema de Reserva


Planni Planning ng Poker, Poker, estóri estóriaa do usuári usuárioo e pontos de estória, nada disso faz parte parte do framew framework ork Scrum, 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.

Sprint Backlog

A Sprint Backlog é todo trabalho que a equipe identifica como como necessário para alcançar a Meta da Sprint.

Framework Framework Scrum: Scrum: Artefat Artefatos os SPRINT SPR INT BA BACK CKLOG LOG E SPRINT SPRINT BU BURND RNDOWN OWN::


A Sp Spri rin nt Burndo rndown wn (ou Burndown Burndown ) é um gráfico gráfico da quantidade quantidade restante restante de trabalho trabalho do Sprint Sprint Backlog Backlog em uma determinada determinada Sprint Sprint ao longo do tempo da Sprint. Para criar esse gráfico, determine quanto trabalho resta somando somando as estimativas estimativas do Backlog Backlog a cada dia da Sprint. A quantidade quantidade de trabalho trabalho restante para uma Sprint 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 que possível, possível, desenhe desenhe a Sprint Burndown 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.

A Sprint Sprint Burndo Burndown wn é um artefato que deve ser utilizado exclusivamente pela equipe. Se PO tentar tentar fazer a gestão gestão do do projeto com base na Sprint Burndown Burndown é considera considerado do como como micromicro-ger gerenc enciam iament entoo e que que pode pode levar ao comando-controle... O PO deve fazer fazer a gestão gestão do projet projetoo olhando a Release Burndown.

Framework Framework Scrum: Scrum: Artefat Artefatos os SPRINT SPR INT BU BURN RNDOW DOWN N : Exemplo Exemplo A transparência, 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 Tarefas deixam a Sprint com visibilidade visibilidade e transparência. transparência.


O Quadro de Tarefas também não parte do framework Scrum, ele parte de uma técnica chamada Gestão à Vista, Vista, que tem como objetivo facilitar a comunicação e dar visibilidade (transparência). (transparência).

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


Pronto

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

® l Definir claramente quando o produto estará “pronto”, a pois: i r o t Pronto, para desenvolvedor desenvolvedor significa: u - Encerrou codificação..... T Encerrou a codificação. O Pronto, para PO significa: significa: , Pronto, Quando foi entregue entregue... ... M - Quando U R Pronto, para os usuários finais e/ou clientes significa: C começou a funcionar em ambiente S - Quando o software começou de produção...

Evite: A síndrome síndrome dos 90% feito (pronto).

Framework Framework Scrum: Scrum: Definição Definição de Pronto Pronto A Definição de PRONTO Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada Sprint. Sprint. Esse incremento incremento deve ser potencialme potencialmente nte entregável, entregável, pois pois o Product 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 anteriores e exaustivamente exaustivamente testado, testado, garantindo que todos os incrementos funcionem f uncionem juntos.


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. desenvolvido. Se não houve definição de “pronto”, os outros 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 Product Backlog Backlog em uma Sprint. Sprint. Alguns produtos produtos não contêm documentação, 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 Product Backlog Backlog no incremento. incremento. Os testes testes incluem incluem testes de unidade, 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 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. Owner. Esse trabalho restante deverá ser feito antes que o produto possa ser implantado e utilizado.

Framework Framework Scrum: Scrum: Definição Definição de Pronto 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” “pronto” e o trabalho “não pronto”. O trabalho “não pronto” é a porção de cada incremento que terá que ser

completada completada mais tarde. O Product Product Owner Owner sabe exatamente exatamente o que ele está inspecionand inspecionandoo ao final da Sprint, porque o incremento atende à definição de “pronto” e o Product Product Owner Owner entende entende essa definição. definição. Productt Backlo Backlogg o chamado “trabalho não pronto”, de “não pronto” é adicionado a um item item do Produc ® l O trabalho “não que ele se acumula e isso é refletido corretamente no gráfico de Release Release Burndown Release. a forma que i r Essa técnica cria transparência no progresso em direção à entrega. A inspeção e a adaptação na o Revisão t Revisão da Sprint Sprint serão tão precisas precisas quanto quanto essa essa transparênc transparência ia for. for. u T Exemplo: O , M Se uma equipe não é capaz de realizar os testes de performance, regressão, estabilidade, U segurança e integração para cada item do Product Backlog, a proporção desse trabalho em R relação ao trabalho que pode ser pronto (análise, projeto, refatoramento, programação, C documentação, testes unitário e testes de usuário) é calculada. S Vamos supor que essa proporção é de seis peças de “pronto” e quatro peças de “não pronto”. Se a equipe equipe terminar terminar um item de Product Product Backlog Backlog de seis unidades unidades de trabalho trabalho (a equipe equipe está estimando baseado no que ele sabe como “aprontar”), quatro unidades serão acrescidas ao item do do Product Product Backlog Backlog denominado “trabalho não pronto” pronto” quando eles eles tiverem tiverem terminado. terminado. Spri Sprint nt a Spr Sprin intt, 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, imprevisível, visto que o acúmulo de trabalho “não pronto” não é linear. linear.

Exercícios: Responda Verdadeiro 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 rapi rapida dam mente ente.. Ao inv invés diss dissoo, ten tente alg algo e veja eja como como se sai sai. Os mec mecani anismo smos de inspeç speçãão-eo-e-ad adaaptaç ptação ão iner ineren ente tess à natu nature reza za empí empíri rica ca do Scru Scrum m irão irão lhe lhe guia guiarr. [ ] Ve Verdadeiro [ ] Fa Falso ® l a i crumMas mMastter traba raballha com os cli cliente ntes e a ger gerênci ênciaa par para iden identitifficar icar e desig esigna narr um Prod Produc uctt Owner. er. r 2 - O Scru o ScrumM mMas aste terr ensi ensina na ao Produ roduct ct Owne Ownerr como como faze fazerr seu seu trab trabal alho ho.. Espe Espera ra-s -see dos dos Prod Produc uctt Owne Owners rs que que t O Scru u eles eles saiba aibam m como como con consegu seguiir otimi timiza zarr valor alor atrav través és do Scrum crum.. Se eles eles não não soub souber erem em,, con conside siderramo amos o T ScrumMaster ScrumMaster responsável responsável.. O , Verdadeiro [ ] Fa Falso M [ ] Ve U R C 3 - O Scru ScrumM mMas aste terr pode pode ser ser um memb membro ro da equi equipe pe;; por por exem exempl plo, o, um dese desenv nvol olvvedor edor real realiz izan ando do tare tarefa fass S da Spri Sprint nt.. No enta entant nto, o, isso isso freq freque uent ntem emen ente te leva leva a conf conflilito toss quan quando do o Scru ScrumM mMas aste terr deve deve esco escolh lher er entr entree remov remover er impedi impedimen mentos tos ou realiz realizar ar tarefa tarefas. s. [ ] Ve Verdadeiro

[ ] Fa Falso

4 - O Scrum crumMa Mast ster er nunc nuncaa dev deve ser ser o Produ roduct ct Owne Ownerr. [ ] Ve Verdadeiro

[ ] Fa Falso

Exercícios: Responda Verdadeiro Verdadeiro ou Falso para as questões: 5 - O Prod Produc uctt Owner ner pode ode ser ser um memb membro ro da equi equipe pe,, trab trabal alha hanndo também mbém na real realiizaçã zaçãoo das das tare tareffas. Mas, essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partes interessadas. [ ] Ve Verdadeiro

[ ] Fa Falso

® l 6 – Se a equipe sentir que se comprometeu com mais do que podia, ele se encontra com o Product Ownerr para para remo remove verr ou redu reduzi zirr o esco escopo po da Spri Sprint nt Back Backlo logg (ite (itens ns do Prod Produc uctt Back Backlo logg sele seleci cion onad adoo para para a Owne i r a Sprint). Se a equipe sentir que sobrará tempo ele pode trabalhar junto ao Product Owner para o sele t seleci cion onar ar mais mais do iten itenss do Prod Produc uctt Back Backlo log. g. u T [ ] Ve Verdadeiro [ ] Fa Falso O , M Geralm lmeente, some somennte 60-7 60-70% 0% do total otal da Spri Sprinnt Backl acklog og será será defi defini nido do na Reuni eunião ão de Plan lanejam ejamen entto U 7- Gera rde ou são dadas estimativas grandes que R da Sprint. O restante é deixado para ser detalhado mais tarde C serã serãoo decom decompo post stas as mais mais tard tardee na Spri Sprint nt.. S [ ] Ve Verdadeiro [ ] Fa Falso 8 - Os itens tens do Produ roduct ct Back Backllog são são comu comum ment ente repr repres eseentad ntadoos como como “Estó Estóri rias as do Usuário”. Casos de Uso Uso tamb também ém são são aprop apropri riad ados os.. [ ] Ve Verdadeiro

[ ] Fa Falso

Exercícios: Responda Verdadeiro Verdadeiro ou Falso para as questões: 9 - Teste stes de acei ceitação ação fazem azem part partee da Estór stóriia de Usuá suário rio, são são utili tiliza zaddos par parar subst ubstiituir uir descri scriçõ ções es text textua uais is mais mais deta detalh lhad adas as com com uma uma descr descriç ição ão test testáv ável el.. [ ] Ve Verdadeiro

[ ] Fa Falso

10 - O Relea elease se Bur Burndow ndownn regi regisstra a soma oma das das esti stimati mativvas dos dos esfor sforço çoss res restante antess do Pro Product duct Backl ackloog ® l ao longo ongo do temp tempo. o. O esf esforço orço esti estima mado do dev deve esta estarr em qual qualqu quer er unida nidade de de medi medida da de trab trabal alho ho que que a a i r equipe Scrum e a organização tenham decidido usar. As unidades de tempo geralmente são o Estó Estóri rias as do Usuá Usuári rio. o. t u T [ ] Ve Verdadeiro [ ] Fa Falso O , M U R C S

Conteúdo:



Objetivo:


Estudo de Caso Objetivo: Apresentar um Estudo 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.

Estudo de Caso


Estudo de Caso

Frame Framework work SCR SCRUM UM

Planejamento da Release

® l a i r o t u T O , M Legenda: U R Reuniões C Artefatos S

Reunião diária


Revisão da Sprint


24 horas Product Backlog

Sprint Backlog Sprint (2-4 Semanas)

Visão

Papéis • Product Owner (PO) • ScrumMaster (SM) • Equipe (time)

Reuniões • Planejamento da Release • Planejamento da Sprint • Diária • Revisão da Sprint • Retrospectiva da Sprint

Produto

Artefatos • Product Backlog • Sprint Backlog Sprin rintt Bu Burn rndo down wn • Sp • Release Burndown

•Sprint Sprint Burndown Burndown • Release Burndown

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




Reunião diária

Revisão da Sprint


24 horas Produto Backlog


Visão

1

Produto

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. ® l a i r o t u T O , M U R C S Após entender a necessidade do cliente, é hora de definir a Visão Visão do Produto: Declaração da Visão do Produto:

Para Para o Hotel Hotel que que necess necessita ita de de um Sist Sistema ema o Portal Portal de de Reser Reserva vass On-Lin On-Linee é um software baseado na web, intuitivo e fácil de usar que fornece a possibilidade possibilidade fazer a consultas e reservas de apartamentos. Diferente Diferente de outros outros sistemas, sistemas, o produto oferece oferece um canal direto direto de acesso acesso ao cliente. cliente.

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

® l a i r o t u T O , M U R C S Funcionalidades do produto O Product desenvolver e Product Backlog Backlog,, inicialmente é uma lista que representa tudo que é necessário para desenvolver 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.

Estudo de Caso: Visão do Produto


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


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




Reunião diária

Revisão da Sprint




Visão

2

Produto

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 melhor maneira possível? - Como podemos alcançar ou exceder a satisfação do cliente ? - Como podemos podemos alcançar alcançar o ROI ROI (retorno (retorno sobre invest investiment imento) o) ? 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 entrega e custos prováveis que devem se manter se nada mudar. mudar. A organização pode então 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 técnicas para para fazê-lo que que estão fora fora do alcance alcance do Scrum (lembre-se (lembre-se o SCRUM SCRUM é framework framework ele não indica nenhuma técnica), mas que apesar disso são úteis quando usadas com ele. Release Burndown (artefato)

Entradas Visão do Produto

Planejamento da Release Product Product Backlog Backlog (priorizado (priorizado))

Product Product Backlog Backlog (visão inicial) inicial)

Saídas Equipe SCRUM

Plano de 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).

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

® l a i r o O Plano de Release t u é elaborado nessa T reunião. Nesse plano O define-se o prazo de , entrega do produto e M nível de prioridade U dos itens do backlog R C S

3

2

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

Reserva

Promoções

Relacionamento ao cliente

Programa de Fidelidade

Tour Virtual Virtual

5 Releases

Alto

Médio

Médio

Médio

Baixo

1 Alto, 3 médio e 1 baixo

30 dias

15 dias

7 dias

15 dias

15 dias

82 dias

Estudo de Caso: Reunião de Planejamento da Release Com Produc Productt Backlo Backlog g atualizado e o Plano de Release, o PO poderá construir o Release Burndown, que é um dos artefatos do SCRUM. As estimativas estimativas dos itens do Product Product Backlog Backlog são inicialmente inicialmente calculadas durante durante a Reunião de Planejamento da Release. O Release Release Burndown Burndown registra registra a soma das estimat estimativas ivas dos esforço esforçoss restantes restantes do Product Product Backlog 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. Sprints.

Release Burndown ® l a i r o t u T O , M U R C S

120

O Produc Productt Ow Owner ner é respo responsá nsável vel por manter por manter o Produc Productt Backl Backlog og 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.

108 80

) s o d a m i t s e ( s o40 t n o P

68 48

40

20 0

Release #1

Release #2

Release #3 Releases

Release #4

Release #5



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


Estudo de Caso: Reunião de Planejamento da Sprint Terceiro passo: Realizar a Reunião de Planejamento da Sprint, o resultado resultado desta desta reunião reunião são os artefatos Sprint Sprint Backlo Backlog g e Sprint Sprint Bu Burnd rndown. own.




Reunião diária

Revisão da Sprint




Visão

3

Produto

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

® l a i r o t u T O , A Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. No nosso M exemplo a duração é fixada em 8 horas, pois, a Sprint tem a estimativa estimativa de um mês. U Essa reunião é dividida em duas partes: R C 2ª. Parte da Reunião (4 horas): S 1ª. Parte da Reunião (4 horas): A equipe equipe Scrum Scrum trata trata da questã questão: o: “o quê?”. A equipe trata a questão: “como?”. O PO apresenta apresenta a equipe equipe o que é mais mais Durante as 4 horas seguintes a equipe define como prioritário no Product Backlog. Todos Todos trabalham transformará o item selecionado em incremento do em conjunto para definir qual funcionalidade produto “pronto” e potencialmente entregável. deverá ser desenvolvida durante a próxima O PO estará presente para esclarecer dúvidas e para Sprint. Sprint. O Product Product Backlog Backlog está ordenado ordenado de ajudar a efetuar efetuar trocas, se necessário. Se a equipe acordo com nível de prioridade dos itens. concluir que ela tem trabalho demais ou de menos, A equipe deve selecionar o item de maior ela pode renegociar renegociar os itens do Product Product Backlog Backlog prioridade e definir qual será a meta da Sprint. escolhido com o PO

Estudo de Caso: Reunião Reunião de Planejamento da Sprint Detalhand Detalhando o os itens do Produto Produto Backlog Backlog em estórias do usuário: usuário:


Para facilitar o entendimento dos itens itens do Produc Productt Backl Backlog og ele são são descritos em estóri estórias as do usuári usuárioo elas auxiliam auxiliam no entendim entendimento ento do que deve ser feito, permite fazer a estimativa de velocidade da equipe e também é, utilizada utilizada como lembrete e para as atividades de planejamento. Geralmente a estimativa é feita em pontos pontos (pontos (pontos de estória) estória)

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 dúvidas sobre do que deve deve ser feito.

Estória Estória do Usuário Usuário Titulo: “Fazer Reserva de Apartamentos”

Cartão: Estória do Usuário Usuário são tradicionalmente escritas em um cartão. Cartão podem ter notas, estimativas, comentário observações e etc

Como cliente de negócio, eu quero fazer reserva de apartamentos pela web para facilitar facilitar o meu

Conversas: Detalhes que podem surgir durante as conversas conversas com com PO (Product (Product Owner) Owner) e/ou cliente. cliente.

planejamento.

Pontos: ?

Prioridade: Alta

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.

Boa Prática: A Estória Estória do Usuário deve prover o entendimento do que deve ser feito e deve deve facilitar a estimativa de velocidade da equipe.

Estudo de Caso: Reunião Reunião de Planejamento da Sprint Detalhando as Estórias do Usuário em Tarefas: Tarefas: Estória Estória do Usuário Usuário Titulo: “Fazer Reserva de Apartamentos”

Como cliente de negócio, eu quero fazer reserva de apartament apartamentos os pela web para facilita facilitarr o meu


planejamento. Prioridade: Alta

Pontos: ? Tarefas de Negócio

Tarefas Técnicas

Consulta de Reserva de Apartamento

Criar Interfaces Do Usuário

Cadastro de Fila de Espera

Criar Tabelas

Fazer Reserva de Apartamentos Cadastro de Cliente


Confirmação da Reserva


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

Estudo de Caso: Reunião 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 esc rever as estórias do usuário. O Planning Poker é uma “prática” que ajuda ajuda na estimativa de uma estória 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,...) (1,2,3,5,8,13,...) + 20, 40, 100 ou em outra outra escala Jogando o Planning Poker: Antes de começar o jogo é necessário definir um valor de referência. Por exemplo: exemplo: Identificar a estória que pode ser atribuído a menor quantidade pontos, esta estória será utilizada 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... 40

1ª. Rodada

100

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

40

Product Owner

Equipe

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 concesso entre os membros da equipe.

40

Enésima Rodada

40

40

40

Equipe

Estudo de Caso: Reunião Reunião de Planejamento da Sprint Estória Estória do Usuário Usuário Titulo: “Fazer Reserva de Apartamentos”

Como cliente de negócio, eu quero fazer reserva de


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

Pontos: 40 Tarefas de Negócio

Tarefas Técnicas


Criar Interfaces Do Usuário


Criar Tabelas

Fazer Reserva de Apartamentos

Plann Planning ing Poker Poker , Estóri Estóriaa do Usuári Usuárioo e Pontos de Estória, Estória, nada disto faz parte parte do framew framework ork Scrum, 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 Sprint Burndown, Burndown, devemos devemos fazer a definição de “Pronto”.

Cadastro de Cliente




Sprint Backlog

A Sprint Backlog Backlog é todo trabalho trabalho que a equipe identifica como necessário para alcançar a Meta da Sprint.

Estudo de Caso: Reunião 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. Sprint. Esse incremento incremento deve ser potencialm potencialmente ente entregável entregável,, pois o Product Product Owner 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.

® l Uma conversa comum entre o cliente e o desenvolvedor: a i r [Cliente] E aí como anda o desenvolvimento da aplicação ? o t [Desenvolvedor] Está “pronta”... u [Cliente] Isso quer dizer que eu posso implementa-la ? T [Desenvolvedor] Bem...ainda não, preciso fazer mais alguns testes... O [Cliente] Mas, aplicação não está “ pronta”.. , M U Definir claramente quando o produto estará “pronto”, R pois: C Pronto, para desenvolvedor desenvolvedor significa: S - Encerrou Encerrou a codificação. codificação..... Pronto, Pronto, para PO significa: significa: - Quando Quando foi entregu entregue... e... 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.

Estudo de Caso: Reunião Reunião de Planejamento da Sprint A transparência, 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 Tarefas deixa a Sprint com visibilidade e transparência necessária. Entretanto, o Quadro de Tarefas Tarefas é para o uso exclusiva da equipe, que é responsável pela sua atualização.

Task Board (Quadro (Quadro de Tarefas) arefas) ® l a i r o t u T O , M U R C S

Para Fazer

Fazendo

Pronto

Sprint Sprint Burndo Burndown wn


Pontos 40


30 20

Cadastro de Cliente


10 0

1

2

3

4

Semanas

Meta da Sprint Entregar a funcionalidade de reserva de apartamentos em 30 dias.

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


Estudo de Caso: Reunião 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. ® l a i r Para não correr riscos, a equipe optou por trabalhar com uma folga. o t possível calibrar calibrar u Com o decorrer das Sprints e novos projetos será possível T melhor a velocidade da equipe. O , M O Quadro de Tarefas é importante ? U (Task Board) também não parte do R O Quadro de Tarefas (Task C Framework Scrum, ele parte de de uma técnica chamada Gestão à S Vista, que tem como objetivo facilitar a comunicação c omunicaçã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 começa a trabalhar trabalhar com com Scrum ? Quando uma equipe equipe começa com o Scrum, Sprints de duas semanas o permite aprender sem cair nas armadilhas da incerteza.

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


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, começa, o próxima próxima passo passo são as Reuniões Diárias.




Reunião diária

Revisão da Sprint




Visão

4

Produto

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: 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 de decisões e aperfeiçoa o nível nível de conhecimento de todos acerca do projeto. O ScrumMaster ScrumMaster é responsável responsável por garantir garantir que a equipe equipe realize realize essa reunião. 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 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 transforma transformando ndo os itens do Product Product Backlog Backlog um incremento incremento (produto), (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 Product Backlog. 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 vir na Sprint. A intenção é otimizar a probabilidade de que a equipe alcance alcance sua Meta. Essa é uma reunião fundamental de inspeção e adaptação no processo empírico do Scrum.

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



OK

OK

OK

?

Equipe

SCRUM Master

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.

15 Minutos

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

O que vai ser feito antes da ® l próxima reunião diária? a Começar a tarefa i r Cadastro de Cliente o t u encontrado T Foi algum obstáculo ? O Não , M U OK R C S

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

OK

Movimentação do po post-i st-itt para a coluna: Pronto

Atualização do Sprint Burndown

?

Equipe

SCRUM Master


15 Minutos

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

15 Minutos ® l a i r o t u T O , M U R C S

OK

OK

?

OK

Equipe SCRUM Master

Encontrei um obstáculo (impedimento).


Estudo de Caso: Impedimento Cabe Cabe ao “SCRUM remove verr todo todoss os impe impedi dime ment ntos os,, iden identitififica cado doss e demo demons nstr trad ados os no Quad Quadro ro de “SCRUM Master” Master” remo Taref refas, para que estes não afetem o desempenho da equipe nem a meta da Sprint. Caso contrário, o imped mpediiment mentoo pode poderá rá comp compro rome mete terr a meta meta e a ent entreg rega de valo alor que dev deve ocor ocorre rerr no fina finall da Spri Sprint nt..


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 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 info inform rmaç ação ão dev deverá erá ser ser util utiliz izad adaa para para melh melhor orar ar o proc proces esso so,, logo logo será será discu discutitida da na Retr Retros ospe pect ctiv ivaa da Spri Sprint nt..

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 ® l a i r o t u T O , M U R C S

OK

OK

OK

?

Equipe

SCRUM Master

OK

Estudo de Caso: Reunião Diária


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

® l a i r o t u T O , M U R C S Quem pode pode cancelar cancelar a Sprint Sprint ?

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




Reunião diária

Revisão da Sprint




Visão

5

Produto

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


OK

Product Owner OK

4 horas

OK

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.

Reunião de Revisão da Sprint A Reunião de Revisão Revisão da Sprint, para Sprints de 1 mês, essa é uma reunião com duração fixa 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 Baseados nisso nisso e em mudanças mudanças no Product Product Backlog Backlog feitas feitas durante a Sprint, eles colaboram sobre quais são as próximas ® l coisas que podem ser feitas. Essa é uma reunião informal, intenção de a com a apresentação da funcionalidade, que tem a intenção i r promover a colaboração sobre o que fazer em seguida. o t u Product Owner Owner identifica identifica o que foi feito feito e o que não foi feito. A T O Product equipe discute sobre o que correu bem durante durante a Sprint e quais O problemas foram enfrentados, além de como esses problemas , resolvidos. A equipe então demonstra o trabalho que está M foram resolvidos. questionamentos. O Product Owner U pronto e responde a questionamentos. R então discute discute o Product Product Backlog Backlog da maneira maneira como esse se C encontra. S 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. seguida. A Revisão Revisão da Sprint fornece fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.

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


Reunião de Revisão da Sprint Produc Productt Backlo Backlog g é atuali atualizad zado. o. responsável por manter manter atualizado atualizado Release Release Burndown Burndown e Product Product Backlog Backlog .” Lembrem: “PO é responsável


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


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

® l a i r o t u T O , Podemos considerar que a entrega da Sprint foi feita mesmo que ela não esteja em conformidade M com a definição de Pronto ? U R C S

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.




Reunião diária

Revisão da Sprint




Visão

6

Produto

Retrospectiva da Sprint Reunião Retrospectiva da Sprint As retrospectivas são a essência do conceito de Inspeção e Adaptação. Adaptação. s o t n e m i d e p m i


Problemas no Servidor de Teste

=

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

Reunião de Retrospectiva da Sprint: Sprint: A Reunião de Retrospectiva da Sprint é a última reunião de uma Sprint. Nessa reunião, com duração fixa de 3 horas, o ScrumMaster deve encorajar a equipe a revisar, 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 Existem diversas técnicas que são úteis em uma ® l Sprint. Existem Retrospectiva iva (por (por ser um framewor frameworkk Scrum não indica indica a Retrospect i r diretamente nenhuma técnica) o t u Retrospectiva é inspecionar inspecionar como foi a T A finalidade da Retrospectiva última Sprint em se tratando de pessoas, das relações O entre elas, dos processos e das ferramentas. A inspeção , M deve identificar e priorizar os principais itens que U correram bem e aqueles que, se feitos de modo R diferente, poderiam ter deixado as coisas ainda C melhores. Isso inclui a composição da equipe, os S preparativos para reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para

transf transform ormar ar itens itens do do Produc Productt Backlo Backlogg em algu alguma ma cois coisaa “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.

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



Velocidade da equipe

Atitude: Para uma equipe (time) SCRUM funcionar será necessário mudança de atitude, caso contrário isto poderá afetar o desempenho da equipe


Cadastro de Cliente


=

Será necessário mais atenção na hora de estima estimarr as estóri estórias as do usuário.

Impedimentos: Problemas no Servidor de Teste

Planejamento: Prestar atenção na hora do planejamento da Sprint, para identificar se todos os recursos necessário estão disponíveis

Reunião de Retrospectiva da Sprint


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




Reunião diária

Revisão da Sprint




Visão

Produto

Reunião de Planejamento da Sprint Exercício: O PO deve particip participar ar da Reunião Reunião de Retrosp Retrospectiv ectivaa da Sprint Sprint ?

® l a i r o t u T O , Durante este estudo de caso não foi apresentado as práticas e ferramentas f erramentas de Engenharia de M Software, tais como como TDD, SCM e etc, explique o motivo: U R C S

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


Para participar da comunidade basta se cadastrar: http://bit.ly/czZlez A missão da comunidade é compartilhar conhecimento, trocar experiências e prover aprendizado.

Referências Scrum Scrum Guide Guide Agilee Collection Agil Collection (SCRUM (SCRUM,, FDD e XP) nova nova versão versão 1 Scrum Scrum Experience Experience [O Tutorial Tutorial SCRU SCRUM] M] - Tutorial SCRUM, SCRUM, demonstra as práticas SCRUM SCRUM para o gerenciamento gerenciamento de projetos de software.


2 SCR SCRUM UM Product Product Owner: Owner: - Este eBook eBook descreve descreve o SCRUM SCRUM enfatizan enfatizando do a atuação atuação do do Product Product Owner. 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 Engenharia de Software Software 100% 100% Agil Agil (SCRUM, (SCRUM, FDD e XP) - Esta apresentação faz uma demonstração de de como combinar os métodos ágeis: SCRUM, FDD e XP para tornar o Ciclo de Desenvolvi Desenvolvimento mento de Software Ágil, Ágil, ou seja, a Engenharia de Software 100% Ágil. 4 Engenharia Engenharia de Software Ágil: Ágil: SCRUM e FDD - SCRUM e o FDD FDD são Métodos Métodos Ágeis Ágeis que são utilizados utilizados para para desenvolvi desenvolvimento mento de software. Fizemos Fizemos uma pequena demonstração demonstração de como utilizar utilizar o SCRUM e FDD (Featured (Featured Driven Driven Developm Development) ent) 5 Escrevendo Escrevendo Estórias do Usuário Eficazes Eficazes - Este tutorial demonstra demonstra como "escrever "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 Priorizar e Manter o Product Backlog - Este tutorial demonstra como como usar as melhores práticas e técnicas técnicas para "Como criar, estimar, priorizar e manter o Product Product Backlog". 7 Worksho Workshop p SCRUM SCRUM Produc Productt Owner Owner - Delírio Delírio de PO em dia dia de Verão Verão Esta apresentação sobre o SCRUM SCRUM Product Owner que aborda práticas, ferramentas e responsabilidades responsabilidades do PO. Também é demonstrado demonstrado como os "delírios" "delírios" do PO pode afetar negativamente negativamente os membros da equipe e o resultado do projeto.

Licença:


Notas: Marcas Registrada Registradas: s: 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 decor rer 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.


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 ([email protected] ([email protected]) om.br)


O Tutorial

www.etcnologia.com.br

Rildo F Santos (11) 9123-5358

[email protected] twitter: @rildosan

SCRUM, O Tutorial v1

Recommend Documents