APOSTILA INTRODUTÓRIA AO SCRUM
1
Desafio do desenvolvimento de software_____________________________________4
Introdução ao Manifesto Ágil______________________________________________5
Os princípios do Manifesto Ágil____________________________________________7
Metodologias Ágeis______________________________________________________8
SCRUM________________________________________________________________9
A origem do SCRUM__________________________________________________________9Conceitos do SCRUM_______________________________________________________________9O que é SCRUM?__________________________________________________________________9Pilares do SCRUM_________________________________________________________________10
O SCRUM__________________________________________________________________11Papéis no SCRUM_________________________________________________________________12
Product Owner________________________________________________________________12Scrummaster__________________________________________________________________12Time_________________________________________________________________________12
O ciclo do SCRUM___________________________________________________________14
Reunião de Planejamento da Release___________________________________________14Artefatos do Release Planning_______________________________________________________14
Backlog do Produto_____________________________________________________________14Release Burndown______________________________________________________________16
Dicas além do SCRUM_____________________________________________________________17
Definição de "Pronto"_______________________________________________________18
A Sprint___________________________________________________________________19
Planejamento da Sprint______________________________________________________19Dicas além do SCRUM_____________________________________________________________20
Execução da Sprint__________________________________________________________22Artefatos da Sprint________________________________________________________________22
Backlog da Sprint_______________________________________________________________22Sprint Burndown_______________________________________________________________24
Dicas além do SCRUM_____________________________________________________________25
Reunião Diária_____________________________________________________________26Dicas além do SCRUM_____________________________________________________________26
Revisão da Sprint___________________________________________________________27Dicas além do SCRUM_____________________________________________________________27
Retrospectiva da Sprint______________________________________________________28Dicas além do SCRUM_____________________________________________________________28
2
Índice de figuras e tabelas
Figura 1 – Fluxo do Scrum 11
Figura 2 – Burndown da Release 16
Figura 3 – Burndown da Sprint 24
Tabela 1 – Backlog do Produto 15
Tabela 2 – Backlog da Sprint 23
Tabela 3 – Quadro SCRUM 25
3
Desafio do desenvolvimento de software Os desafios de se desenvolver softwares vão muito mais além do que problemas de processos e procedimentos. Trabalhar com expectativas, transferir e compartilhar conhecimento, motivação e um bom ambiente são exemplos de aspectos que devem ser considerados muito importantes no desenvolvimento de um software. Cada vez mais fica claro que o foco de pontos a melhorar e a melhoria contínua provem e depende das pessoas comprometidas com o desenvolvimento do software. Isto nos eleva a um novo patamar na cultura de desenvolvimento de software, onde, tanto quanto a Ciência de Software é considerada uma área Exata, sua aplicabilidade se demonstra cada vez mais uma área Humana.
A evolução de uma prática, processo ou produto somente se dá através da evolução de Pessoas. Esta evolução está cada vez mais presente nas necessidades do desenvolvimento de software atual. Evoluirmos como Pessoa, como um Time unido, através de colaboração, confiança e comprometimento são atitudes que se mostram eficazes e eficientes para vencer os desafios de desenvolver um software. Esta cultura que já nasceu e está sendo disseminada, uma cultura voltada a Pessoas e a interação entre elas, voltada ao real valor agregado aos clientes, simples e leve vem se fortificando, se adaptando as necessidades e dando novos ares a forma que se desenvolve software.
Rafael Barbosa Camargo
4
Introdução ao Manifesto ÁgilEm fevereiro de 2001, vários profissionais da área de desenvolvimento de software se reuniram em uma Estação de Esqui em Utah, Estados Unidos, para uma discussão sobre o desenvolvimento de software. Em tal discussão, foram abordados os desafios, necessidades e desejos que todos tinham em relação a tal assunto. Através desta reunião, foram extraídas algumas conclusões que pautaram a geração de um Manifesto.
O Manifesto Ágil foi gerado sobre os Valores que estes profissionais vislumbraram ser algo bom, com a finalidade de impulsionar melhorias no cenário geral de desenvolvimento de software.
O Manifesto Ágil:
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o Cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
http://agilemanifesto.org
O Manifesto Ágil foi gerado por muitos profissionais e estudiosos de Desenvolvimento de Software, onde destes, os seguintes assinaram o Manifesto:
Kent Beck James Grenning Robert C. MartinMike Beedle Jim Highsmith Steve Mellor
Arien van Bennekum Andrew Hunt Ken SchwaberAlistair Cockburn Ron Jeffries Jeff SutherlandWard Cunnigham Jon Kern Dave Thomas
Martin Fowler Brian Marick
O Manifesto Ágil é uma citação complexa, que requer estudo, prática e reflexão.
O primeiro axioma nos mostra que o valor dos indivíduos e a interação entre eles geram mais valor do que a simples utilização de ferramentas ou padrões. Pessoas reagem através de emoções. Tais emoções geram ações que tornam os processos imprevisíveis. Logo, a adaptação de processos e procedimentos em relação á interação entre as pessoas se tornar uma melhor ferramenta do que a padronização do comportamento humano a processos genéricos.
5
O segundo axioma nos exibe um dos principais focos de um projeto: “Software funcionando”. Não é difícil encontrar projetos onde o software esteja “90%” concluído, porém ainda não esteja em funcionamento. Tal questão se dá muito pelo fato das documentações abrangentes geradas. A finalidade desta documentação é representar um desejo e fixá-lo quase como um “contrato”. Porém o esforço tomado para isto é muito grande e gera pouco valor agregado uma vez que os desejos e necessidades de um projeto mudam fatalmente conforme seu andamento. Isto de forma alguma implica que o Manifesto Ágil discorda ou não aconselha a geração de documentação, mas sim, que incentiva a documentação com real valor, gerada no tempo certo e por motivos que tragam valor.
O terceiro axioma exibe uma mudança profunda de atitude. O processo de desenvolvimento de um software é algo colaborativo e dinâmico. Os contratos de desenvolvimento de software hoje em dia são meramente “artefatos para segurança” ou “negociação de risco”. Estes contratos são firmados muitas vezes apenas com a designação de “definir um culpado” caso o projeto falhe e/ou uma “definição rígida” de prazo, custo e escopo. Os contratos muitas vezes são usados para gerar pressão, seja por parte do cliente cobrando o todo ou mesmo pelo fornecedor, se eximindo em relação a qualquer mudança daquilo que foi combinado. Logo, o Manifesto Ágil nos exibe a faceta da colaboração real. Tal colaboração deve visar um real valor agregado para o cliente e para tal, deve ser pautada em confiança e transparência.
O último axioma é tão simples tanto quanto profundo. Em muitos projetos, busca-se tanto seguir o Planejamento inicial definido, que ao longo de projeto, perde-se o foco no produto. Torna-se mais importante seguir o plano do que entregar o software. Pelos motivos explicados no terceiro axioma, gera-se o problema exemplificado no segundo axioma. Logo tudo impacta no quarto axioma. Vamos explicar:
Pela falta de colaboração e confiança, são firmados contratos com valores, custos, prazos e escopos definidos. Para se ter certeza (certeza totalmente irreal esta!) gera-se toda a documentação abrangente para se levantar as funcionalidades a serem desenvolvidas. O levantamento de requisitos é custoso e demorado e quando se começa o desenvolvimento do sistema, acontecem às mudanças. Essas mudanças se tornam traumáticas mediante ao tanto de tempo que já foi gasto analisando e documentando requisitos. Inicia-se todo um trabalho para ver o quanto esta mudança altera no escopo, prazo e custo do projeto e é aqui que o cabo de guerra se intensifica.
O foco do Manifesto Ágil está em responder as mudanças para maximizar o valor do produto, ao invés de seguir um plano pré-definido. Muitas vezes as mudanças trazem imenso valor e não puderam ser vistas no início do projeto pelo simples fato de que naquele momento, não se fazia sentido pedir o que se pede agora. O mundo é dinâmico e o desenvolvimento de software também tem está característica. Cabe a nós tirar proveito desta mudança como um diferencial de valor agregado e buscar colaborar para atingir um sucesso completo.
6
Os princípios do Manifesto ÁgilComplementares ao ideal do Manifesto criaram-se princípios que auxiliam na empreitada de desenvolver softwares:
Nossa maior prioridade é satisfazer o cliente, através de entregas rápidas e contínuas gerando valor ao software
Devemos receber bem as mudanças nos requisitos, mesmo em estágios tardios do desenvolvimento. Processos ágeis devem admitir mudanças em prol de vantagens competitivas para o cliente
Trabalhar para entregar software em intervalos de duas semanas até dois meses, com preferência para que tenha uma curta escala de tempo
As pessoas de negócio e os desenvolvedores devem trabalhar juntos diariamente durante todo o projeto
Construir projetos baseados em indivíduos motivados. Dar-lhes o ambiente e o suporte que precisam e confiar que irão realizar o trabalho
O método mais eficiente e efetivo de transmitir informações em uma equipe de desenvolvimento é conversa face-a-face
Software funcionando é a principal medida para o progresso. Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, os
desenvolvedores e os usuários devem ser capazes de manter um ritmo constante indefinidamente
Atenção contínua a excelência técnica e um bom design aumentam a agilidade Simplicidade – a arte de maximizar o valor do trabalho não feito – é essencial As melhores arquiteturas, requisitos e design surgem a partir de equipes auto-
organizadas Em intervalos regulares, a equipe deve refletir sobre como tornar-se mais efetiva e
então, ajustar-se de acordo com seu comportamento
7
Metodologias ÁgeisCom base nos valores e princípios do Manifesto Ágil, algumas metodologias foram enquadradas ou nasceram e levam a alcunha de Metodologias Ágeis.
Metodologias Ágeis mais conhecidas:
Crystal Extreme Programming (XP) Feature Driven Develpoment (FDD) LEAN Software Development OpenUP RUP (a partir da versão 7.0) SCRUM
Repare que o Manifesto Ágil fora criado em 2001 e algumas destas metodologias são anteriores a esta data. Isso se dá pelo fato que o conceito e a prática destas metodologias pautaram a criação do Manifesto.
Conceitos como “Empirismo”, “PDCA”, “LEAN” estão por trás destas metodologias e logo, por trás do Manifesto Ágil. É importante ter em mente que o Manifesto Ágil não definiu tais conceitos, mas sim, explicita os ganhos que tais aplicações geraram.
8
SCRUM
A origem do SCRUMDe início, o SCRUM foi concebido como uma forma de gerenciamento de projetos de produtos complexos por Ikujiro Nonaka e Hirotaka Takeuchi, no livro “The New New Product Development Game” [Harvard Business Review, Janeiro-Fevereiro 1986].
Em 1993, Jeff Sutherland, John Scumniotales e Jeff MacKenna conceberam, documentaram e implementaram o SCRUM na empresa Easel Corporation. Ken Schwaber, Mike Smith e Chris Martin também o implementaram e trabalhara em sua formação.
Em 1995 o SCRUM foi formalizado por Ken Schwaber, Mike Beedle e Jef Sutherland e apresentado oficialmente na OOPLSA (Object-Oriented Programming, Systems, Languages and Applications).
Conceitos do SCRUMO SCRUM tem em sua base os conceitos de:
LEAN Desenvolvimento iterativo e incremental Team Process Micro enterprise development Empirismo PDCA Time Boxe Definição de Pronto Team Velocity
O que é SCRUM?SCRUM é um framework para desenvolvimento de produtos complexos, fundamentado na teoria de controle de processos empíricos, utilizando da abordagem iterativa e incremental, visando maximizar valor de negócio, otimizar a previsibilidade e controlar risco.
Outras definições encontradas de SCRUM:
• Processo iterativo e incremental para o desenvolvimento de produtos e gerenciamento de projetos
• SCRUM é um framework dentro do qual você pode empregar diversos processos e técnicas, onde, produtos complexos podem ser desenvolvidos.
• SCRUM é um processo ágil e leve que pode ser utilizado para gerenciar e controlar o desenvolvimento de software
9
Pilares do SCRUMTrês pilares sustentam o SCRUM:
Transparência: Visibilidade e entendimento
Os pontos do processo devem estar visíveis para todos aqueles que participam ou são afetados pelo processo. Além da visibilidade, todos os aspectos devem estar passíveis de entendimento por todos.
Inspeção: Verificação e sentimento
Os pontos do processo devem ser passíveis de verificação com freqüência. A freqüência deve ser suficiente para que ruídos inaceitáveis sejam detectados.
Adaptação: Mudar parar melhor, tentar
Dado a visibilidade e o entendimento. O processo de inspeção tem como resultado algumas adaptações que visam à melhoria do sistema. As ações de mudança são então ajustadas e realizadas e um novo ciclo se inicia.
Em uma aplicação de SCRUM é fundamental estar atento a estes pilares, logo, ao se buscar incrementar ou alterar um processo ou procedimento, busque visualizar se esta ação está de acordo com os pilares do SCRUM. Tal verificação será valida também para os valores e princípios do Manifesto Ágil.
10
O SCRUM
Figura 1 – Fluxo do SCRUM
O SCRUM é formado papéis, eventos com duração fixa, artefatos e regras.
Os papéis são:
Scrummaster: responsável por garantir que o processo seja compreendido e seguido
Product Owner: responsável por maximizar o valor de trabalho que o Time gera Time: Executa o trabalho. Formado com todas as habilidades necessárias para
gerar o produto
O SCRUM utiliza de eventos com duração fixa para gerar uma regularidade. As cerimônias com duração fixa são:
Reunião de Planejamento da Release Reunião de Planejamento da Sprint Sprint Reunião diária Revisão da Sprint Retrospectiva da Sprint
O SCRUM utiliza ainda os seguintes artefatos:
Backlog do Produto Backlog da Sprint Burndown da Release Burndown da Sprint
11
Papéis no SCRUMO Time SCRUM é composto por um Scrummaster, Product Owner e pelo Time.
Product OwnerO Product Owner é o responsável por maximizar o ROI (Return on Investiment) do Projeto. Seu papel é fundamental e suas atribuições são de grandes responsabilidades. O Product Owner deve manter vivo o Product Backlog, com as informações das necessidades que deseja realizar. É de sua responsabilidade priorizar o trabalho a ser realizar pelo Time, bem como, dar visibilidade a está priorização. O Product Owner é uma única pessoa, porém, esta pessoa pode ser auxiliada por um grupo de pessoas. Contudo, deve-se ressaltar que a decisão da prioridade é realizada pelo Product Owner.
Dentre as atribuições do Product Owner, ressalta-se:
Definir as funcionalidades do produto Maximizar o ROI Apresentar ao Time os requisitos necessários para o desenvolvimento do produto Planejar as entregas do produto Gerenciar alterações do produto
ScrummasterO Scrummaster é o responsável por garantir e ajudar o Time SCRUM esteja aderindo e aplicando os valores do SCRUM, as práticas e as regras. Mais do que garantir a adesão e aplicação, o Scrummaster educa o Time SCRUM, treinando-os e estimulando-os a melhoria contínua. O Scrummaster tem uma atuação de “Facilitador”, removendo os impedimentos que o Time SCRUM venha a ter, para poder maximizar a produtividade do Time.
As responsabilidades do Scrummaster são:
Remover impedimentos no desenvolvimento do produto Ensinar o cliente na maximização do valor agregado Facilitar a rotina do Time SCRUM, estimulando a criatividade e motivando-os Auxiliar o Product Owner na manutenção do Product Backlog Proteger o time de interferências externas Promover práticas e procedimentos que auxiliem o Time no desenvolvimento do
Produto
TimeO Time tem a responsabilidade de realizar e entregar o produto solicitado pelo Product Owner. O Time é um grupo de pessoas que têm as formações necessárias para gerar o produto solicitado. Todos os integrantes do Time devem contribuir para a geração do produto, mesmo que isto implique em que um membro do Time tenha de aprender uma nova habilidade. Os Times não contêm subtimes dedicados a áreas particulares do produto. Os Times SCRUM devem ter tais características:
Auto organizado Interdisciplinar
12
Ser formador por cinco até nove membros
Ser auto organizado implica que ninguém deve dizer ao Time como transformar as solicitações do Product Owner em incrementos de funcionalidade. O Time descobre por si só como isto deve ser feito. O Scrummaster deve auxiliá-los nesta descoberta.
O Time tem a responsabilidade de:
Fazer o necessário dentro dos valores e diretrizes para alcançar os objetivos da Sprint
Demonstrar o resultado do desenvolvimento em uma Sprint para o Product Owner Comprometidos com o trabalho Organizar o espaço físico (ambiente)
Os papéis no SCRUM são bem definidos, porém, existe ainda uma gama de skills que cada pessoa que ocupar estes papéis deve desenvolver.
A interação entre os membros do Time SCRUM é crucial para o sucesso de um projeto. Um ambiente de confiança e transparência deve ser gerado e mantido.
13
O ciclo do SCRUM
Reunião de Planejamento da ReleaseA Reunião do Planejamento da Release tem por finalidade estabelecer um plano de Metas que o Time SCRUM possa entender comunicar e desenvolver. O Planejamento da Release eleva à discussão as questões como:
• Como podemos transformar os desejos do Cliente em um produto vencedor?
• Como podemos maximizar o Retorno sobre o Investimento desejado?
O Planejamento da Release pode ser definido através de uma Visão. O SCRUM não explicita como esta visão pode ser declarada, porém, indica que as metas a serem obtidas devem estar bem expressas e visíveis a todos, assim como as maiores prioridades do Backlog do Produto, os principais riscos e as características gerais da funcionalidade a ser desenvolvida. Ainda no Planejamento da Release, procura-se obter-se uma data estimada de entrega do produto, bem como um provável custo. Para a estimativa de entrega, requer-se que o Backlog do Produto tinha sido priorizado pelo Product Owner e estimado pelo Time. O SCRUM não define uma técnica de estimativa, mas existem várias técnicas úteis que podem ser utilizadas.
Artefatos do Release Planning
Backlog do ProdutoO Product Owner é responsável por gerar e manter o Backlog do Produto. O Backlog do Produto é uma lista com as necessidades para lançar o produto desejado. Esta lista deve ser priorizada de forma que os itens com maior prioridade se mantenham na parte de cima do Backlog do Produto. O SCRUM não define uma técnica de priorização, porém recomenda que a mesma seja feita com base em risco, valor e necessidade. Os itens com maior prioridade devem ser melhor detalhados e compreendidos, pois, serão os itens a ser primeiramente desenvolvidos pelo Time. Para os itens de maior prioridade, o Product Owner e o Time já podem avançar, estudando requisitos mais definidos, critérios de aceitação ou detalhes técnicos.
O Backlog do Produto evoluiu à medida que o produto evolui e desta forma, ele nunca está completo ou terminado. Ele é um artefato vivo.
O Time pode estimar uma velocidade inicial para poder gerar estimar as datas de entrega. Esta velocidade deve ser aferida constantemente. Uma vez atualizada, o Backlog do Produto e suas datas de entrega também devem ser revistos.
14
Exemplo:
Item Valor de Negócio Critérios de Aceite Estimativa Data estimada
Inserção de novos materiais do Almoxarifado
100 Inserir dados da descrição do produto, quantidade de produtos e código. O código deve ser um texto com até 5 caracteres.
3 09/05
Alterar quantidade de materiais existentes no Almoxarifado
90 Alterar o valor existente do produto cadastrado. Não permitir que um produto tenha quantidade negativa.
2 09/05
Remover material do cadastro do Almoxarifado
80 Poder excluir um material do Almoxarifado. A exclusão exclui o material e toda a quantidade do mesmo do cadastro do Almoxarifado.
5 09/05
Entrada em lote de materiais do Almoxarifado
70 Inserir vários materiais de uma única vez.
8 16/05
Alteração em lote de materiais do Almoxarifado
60 Alteração de vários materiais de uma única vez.
5 23/05
Pesquisa de materiais com quantidade igual a 0 no Almoxarifado
50 3 23/05
Mensagem de alerta para quantidade de material menor que 3
40 8 30/05
Exclusão em lote de Materiais
30 5 06/06
TOTAL 39 Entrega em 13/06
Tabela 1 – Backlog do Produto
15
Release BurndownO gráfico de Burndown da Release exibe a somatória das estimativas dos itens que faltam ser realizados do Backlog do Produto ao longo da Release. O Time tem a liberdade de escolher a sua unidade de medida de trabalho. A unidade de tempo geralmente são as Sprints, conforme o tamanho definido pelo Time SCRUM.
No início, somasse todas as estimativas do Backlog do Produto e gera-se o total de trabalho a ser realizado. À medida que o projeto avança, os esforços já realizados são diminuídos da estimativa de esforço inicial. A intenção do Burndown da Release é exibir o quanto de trabalho ainda falta ser realizado e não o quanto de trabalho já foi realizado. Logo, o Time deve sempre estimar a quantidade de trabalho restante ao longo do projeto e manter o Backlog do Produto atualizado. Uma linha de tendência é traçada baseada na mudança do trabalho restante para indicar o avanço ideal do Time.
Exemplo:
Com base no nosso Backlog do Produto anterior, temos o seguinte Release Burndown.
Figura 2 – Release Burndown
Neste caso temos Sprints semanais (cinco dias úteis) A expectativa inicial de velocidade considerada é de 9 pontos aproximadamente.
16
Dicas além do SCRUMDefinições de Visão podem ser feitas através de Modelos de Mapa Mental.
Para uma Visão, você pode levantar:
Objetivos Publico Alvo Metas Definições tecnológicas Funcionalidades Macro
Para priorizar seu Backlog do Produto, você pode usar pontuação através de Valor de Negócio e assim ordenar seus itens. Existem outras técnicas como MoSCoW que podem lhe auxiliar. O Backlog do Produto tende a ter os itens mais prioritários na parte superior. Os itens prioritários devem ser os itens melhores trabalhados e especificados. Sempre deve-se orientar o trabalho através da priorização.
Para estimar seu Backlog do Produto você pode utilizar Story Points, T Shirt Size e outras técnicas.
Você pode utilizar de tamanhos como "Épico" e "Histórias" para manter seu Backlog do Produto. Épicos seriam itens que ainda estão muito grandes e indefinidos, logo, menos priorizados. Os itens com maior prioridade podem estar no formato de Histórias (User Stories), com uma analise já realizada.
Para realizar estimativas de data de entrega o Time SCRUM tem de definir uma Velocidade de Time inicial. Esta velocidade traduz a média de produtividade do Time. Esta medida representar a quantidade de trabalho que o Time é capaz de realizar ao longo da Sprint. A velocidade será usada para guiar o Planejamento da Release ao longo do projeto e deve ser verificada a cada Sprint. O Time pode demorar algumas Sprints para encontrar sua velocidade sustentável. A velocidade geralmente é medida através de pontos estimados sobre User Stories ou outras medidas abstratas.
17
Definição de "Pronto"O SCRUM define que o Time e o Product Owner devem alinhar-se para o conceito de "Pronto". Cada incremento de software construído deve obedecer a definição de "Pronto" para poder ser entregue. O ideal é que um incremento considerado "Pronto" esteja realmente pronto, a ponto de ser possível subir o mesmo para Produção, caso o Product Owner assim solicite. Esta definição deve estar clara e difundida entre o Time SCRUM e os interessados no produto. Um incremento "Pronto" idealmente não deve estar apenas desenvolvido e testado. O incremento deve estar aceito pelo Product Owner e deve estar pronto para subir em um ambiente de Produção.
Está definição é importante, pois, para avaliar se o Time está concluindo suas Tarefas e atingindo o objetivo, não deve-se levar em conta uma tarefa "50% realizada". No SCRUM, um item está realmente pronto quando satisfaz a definição de "Pronto" e assim pode ser considerado como entregue.
18
A SprintUma Sprint é um espaço de tempo fixado, com o tamanho médio de uma semana a quatro semanas, onde se busca entregar um incremento de produto potencialmente pronto. As Sprints são formadas pelo Planejamento da Sprint, a execução da Sprint, a Revisão da Sprint e a Retrospectiva da Sprint.
Um projeto SCRUM é composto por várias Sprint sequênciais onde se espera que não existam intervalos entre elas. Ao final de uma Sprint, se inicia outra. O ideal é que as Sprint tenham um período de tempo que não varie. Logo, se foi definido que as Sprints tenham 2 semanas, que procure se manter assim e não mude ao longo da Release.
Planejamento da SprintO Planejamento da Sprint é o momento onde se planeja o trabalho do próximo período de tempo fixado. A Reunião é divida em duas partes:
O que? (discovery)
Nesta parte, o Product Owner apresenta o Backlog do Produto ao Time e destaca os itens de maior prioridade. O Product Owner explica ao Time o que espera que seja realizado, o valor de negócio que isto proporcionará e como espera que isso funcione de maneira macro. Cabe ao Time dizer a quantidade de itens do Backlog do Produto que deseja selecionar para conversar, pois, apenas o Time é capaz de dizer o quanto é capaz de realizar. Através da parte selecionada do Backlog do Produto, cria-se uma Meta para a Sprint. A Meta deixa claro o objetivo de negócio a ser atingido ao final da Sprint. Ela é uma descrição sucinta que expressa ao Time uma orientação sobre a razão que eles estão desenvolvendo os itens selecionados.
Como? (delivery)
Nesta parte da Reunião, o Time estima a porção de maior prioridade do Backlog do Produto, e irá definir como é a melhor maneira de implementar o desejo do Product Owner. Para tal, o Time cria Tarefas, nas quais descrevem pequenas porções de trabalho a ser feito. O ideal é que uma tarefa não seja superior a mais de um dia útil de trabalho. Tais Tarefas auxiliam o Time em sua organização durante a evolução da Sprint. Ao final, gera-se o Backlog da Sprint, que contém os itens e Tarefas a serem trabalhados na Sprint. O foco da Sprint é gerar uma porção de incremento de software potencialmente pronto para implantação/produção.
O ideal é que o Planejamento da Sprint dure cerca de 5% do tamanho da Sprint.
19
Dicas além do SCRUMÉ difundida a utilização de User Stories [http://www.extremeprogramming.org/rules/userstories.html] para se popular o Backlog da Sprint e Backlog do Produto. Uma User Story descreve uma funcionalidade que deve conter valor de negócio para o usuário ou cliente do projeto. A User Story é composta pelos três "C":
Card (cartão): Descrição sucinta da história do usuário. Ela deve obedecer a três perguntas:
Quem? Papel do usuário que obterá o valor da funcionalidade O que? O desejo expresso que se tem Por quê? O valor de negócio que se espera obter com a história.
Exemplo: Como <papel> desejo <necessidade expressa> para <valor de negócio>
Como almoxarife desejo cadastrar os materiais recém chegados no almoxarifado para manter atualizada e correta minhas informações de materiais disponíveis.
Conversation (conversas): Toda história deve ser um convite a uma conversa entre o Time e o Product Owner. Uma história existe mais para representar os requisitos do cliente do que documentá-los. Logo, a conversa face-a-face é uma ferramenta importantíssima e deve ser fomentada pelas histórias.
Confirmation (confirmação): Histórias devem conter critérios de aceite que deixem claros quando uma história pode ser dada como implementada. Tais critérios auxiliam o Time a saber como devem implementar as necessidades e podem ser validadas ao longo da Sprint.
Como almoxarife desejo cadastrar os materiais recém chegados no almoxarifado para manter atualizada e correta minhas informações de materiais disponíveis.
Incluir descrição do material Incluir quantidade de material Incluir código do material. O código deve ser um texto livre de até 5
caracteres
O ideal é que as histórias sejam escritas em conjunto, cliente, Product Owner e Time. Alguns times adotam o Story-Writing Workshop. Tal reunião é realizada entre cliente, Product Owner e Time onde os mesmos escrevem as histórias, os critérios de aceite e aprofundam no conhecimento do produto.
20
É difundida também a utilização do Planning Poker para se estimar uma User Story. O Planning Poker utiliza de cartas com a numeração de Fibonacci. Cada membro do Time tem um conjunto de cartas com estes números a sua disposição. Geralmente, estimasse uma User Story com base no esforço e complexidade que se julga ter para implementá-la. Esta estimativa deve levar em consideração o trabalho que o Time todo irá ter para transformar aquela User Story em um incremento pronto de produto.
Uma User Story é apresentada e discutida e então, através de uma contagem regressiva, todos os membros do Time devem mostrar uma carta que represente o tamanho que estimam para a User Story. Caso haja divergência de estimativa, o membro que apresentou a menor estimativa deve falar primeiro e em seguida o membro que apresentou a maior estimativa. Após isto, uma nova contagem regressiva é feita e cada membro do Time apresenta sua estimativa. Se houver mais de três rodadas de estimativa, o Time pode fazer uma pausa e buscar um consenso rápido, neste consenso o Product Owner pode auxiliar.
21
Execução da SprintUma vez que o Backlog da Sprint foi definido, a Sprint tem início. O Time busca se auto organizar da melhor maneira a implementar as Tarefas e Itens. O ideal é que uma Sprint não tenha sua meta alterada ou mesmo seus itens. Caso as mudanças em uma Sprints sejam frequentes, deve ser feita uma analise sobre o que pode estar acontecendo. Um volume grande de mudanças na Sprint causa incertezas e dificuldades na execução das Tarefas o que pode prejudicar a entrega do incremento do produto.
Artefatos da Sprint
Backlog da SprintO Backlog da Sprint contém as tarefas que o Time irá realizar para gerar um incremento “pronto” do produto. Ele deve conter todas as Tarefas necessárias para se atingir a Meta da Sprint e idealmente estas Tarefas devem ser decomposta de maneira que as mudanças ocorridas ao longo dia possam ser entendidas durante a Reunião diária. O Backlog da Sprint também é um artefato vivo. Ele é alterado constantemente ao longo da Sprint para dar a visibilidade correta em tempo real do trabalho que o Time tem planejado para a Sprint. Novas Tarefas podem surgir ao longo da Sprint e o Time deve manter o Backlog da Sprint atualizado. Apenas o Time deve ser responsável por alterar e atualizar o Backlog da Sprint.
O Time pode estimar em horas cada Tarefa do Backlog da Sprint e gerar um Total de Horas de trabalho da Sprint, atualizando o total de horas restantes a serem trabalhadas. Cada Tarefa realizada, excluída ou adicionada deve gerar uma atualização no total de horas.
22
Exemplo: Com base no Backlog do Produto estimado e priorizado, e na Reunião de Planejamento da Sprint, temos o seguinte Backlog da Sprint.
Item Tarefa EstimativaInserção de novos materiais do Almoxarifado – 3 pontos
Refinar requisitos 2 horasTela de inserção de
dados4 horas
Validação do código do material
3 horas
Testes de aceite 2 horasAlterar quantidade de materiais existentes no Almoxarifado – 2 pontos
Refinar requisitos 2 horasSeleção de material 1 hora
Alteração da descrição e
quantidade do material
3 horas
Teste de aceite 1 horaRemover material do cadastro do Almoxarifado – 5 Pontos
Refinar requisito 1 horaExcluir material 2 horasTeste de aceite 3 horas
10 pontos 24 horas
Tabela 2 – Backlog da Sprint
23
Sprint BurndownO Sprint Burndown é um gráfico que tem por objetivo exibir a quantidade de trabalho restante que se tem de um Backlog da Sprint. O Time soma a quantidade de trabalho de um Backlog da Sprint e atualiza conforme for realizando as Tarefas da Sprint, deixando visível e claro a quantidade de trabalho restante da Sprint.
Exemplo:
Figura 3 – Sprint Burndown
Neste caso, temos 24 horas de trabalho restante para serem realizadas em cinco dias úteis.
24
Dicas além do SCRUMPara ajudar na visibilidade do fluxo do SCRUM, alguns times utilizam de Quadros SCRUM (ou kanban). Estes quadros são gerados para expressar o fluxo de trabalho do Time e devem exibir o estado atual de cada tarefa do Sprint:
Item Pendente
Tarefa Pendente
Tarefas em Desenvolvimento
Tarefas Prontas
Item em Aceite Item Pronto
Refinar requisitos
Inserção de novos
materiais do Almoxarifad
o
Tela de inserção de
dadosValidação do
código do material
Testes de aceite
Refinar requisitos
Alterar quantidade de materiais existentes no Almoxarifado
Seleção de material
Alteração da descrição e
quantidade do material
Teste de aceiteRemover
material do cadastro do Almoxarifad
o
Refinar
requisito
Excluir material Teste de
aceite
Tabela 3 – Quadro SCRUM
Neste exemplo, o primeiro item está “pronto”. O segundo item está em uma etapa de aceite enquanto o terceiro item ainda está pendente, pois está sendo desenvolvido ainda.
Muitos Times utilizam de Quadros branco para desenhar seus quadros SCRUM ou kanban. Isto é interessante, pois permite que a cada mudança necessária, o quadro possa ser alterado com facilidade. São também muito utilizado os post-its para se incluir itens e tarefas no Quadro.
25
Reunião DiáriaA Reunião diária busca oferecer ao Time SCRUM e a qualquer pessoa interessada um feedback sobre o andamento da Sprint naquele exato momento. A Reunião diária pode ser feita em frente a um quadro de visibilidade de processo ou mesmo em um local afastado do ambiente natural de trabalho do Time. É recomendando também que a Reunião Diária ocorra sempre no mesmo horário. Nesta reunião apenas os membros do Time falam, o Product Owner, Scrummaster e outras pessoas que acompanham a reunião devem permanecer como ouvintes.
Cada membro do Time deve ser sucinto e responder a três perguntas:
• O que fiz desde a última reunião diária?
• O que pretendo fazer até a próxima reunião diária?
• Estou tendo (tive) impedimentos?
Impedimentos são geralmente quaisquer tipos de problemas que um membro do Time encontre na tentativa de realizar uma tarefa.
A Reunião diária não deve durar mais do que 15 minutos.
Dicas além do SCRUMAo final da Reunião diária o Time pode colaborar com o Product Owner para validar o quão distante estão da Meta da Sprint e o que podem fazer para atingi-la. Isto pode implicar em alterações no Backlog da Sprint. O Time SCRUM deve estar atento para estas deliberações.
26
Revisão da SprintNo fim da Sprint, é realizada a reunião de Revisão da Sprint. Esta reunião tem por objetivo realizar a inspeção no incremente de produto pronto que o Time entrega ao Product Owner. O Time SCRUM e pessoas interessadas se juntam para conversar sobre o que foi realizado. O Time apresenta para o Product Owner os itens prontos e o Product Owner identifica o que foi feito e o que não foi feito. Feito isto o Time pondera sobre o que ocorreu bem e as dificuldades que teve ao longo da Sprint e como estas foram superadas. Em seguida o Product Owner atualiza o Backlog do Produto e pode realizar alterações nas projeções de entrega do produto conforme a velocidade do Time. Por fim o Time SCRUM faz uma projeção do que pode ser realizado na próxima Sprint.
O ideal é que a Revisão da Sprint tenha a duração de cerca de 5% do tamanho da Sprint.
Dicas além do SCRUMO Time pode ter um ambiente preparado para apresentar os itens. Se o Time utiliza post it, pode levá-los a reunião e entregá-los ao Product Owner e através deles, orientar a apresentação. Itens que forem rejeitados pelo Product Owner devem voltar para o Backlog do Produto para serem analisados novamente. O ideal é que o Product Owner possa interagir com o sistema durante a apresentação. Isto aguça os sentimentos do Product Owner em relação ao produto. Sempre se deve buscar apresentar produto funcionado.
27
Retrospectiva da SprintLogo após a Revisão da Sprint e antes da próxima Reunião de Planejamento da Sprint é realizada a reunião de Retrospectiva da Sprint. Nesta reunião, o Time é estimulado a realizar uma avaliação de seu processo de trabalho com o objetivo de melhorá-lo cada vez mais. O foco desta reunião é inspecionar o modo de trabalho realizado na última Sprint e buscar formas de tornar o trabalho mais eficaz e gratificante. O Scrummaster colabora com o Time para que juntos possam focar em pontos de melhoria e formas de realizar esta melhoria. Deve ser realizada uma identificação e priorização dos principais itens que aconteceram de forma boa e também dos itens que ocorreram de uma forma que poderia ter sido feita melhor. Esta reflexão inclui a formação do time, ambiente de trabalho, comunicação, preparativos e processos realizados para se gerar um incremento pronto de produto.
Ao final o Time deve ter levantado ações claras de melhoria e formas de dar visibilidade a elas. Essas mudanças se transformam na adaptação para a inspeção empírica.
Esta reunião tem duração de três horas.
Dicas além do SCRUMExistem várias técnicas para se realizar uma Retrospectiva. Você pode utilizar post its para que cada pessoa do Time SCRUM escreva os pontos bons da Sprint e os pontos a melhorar. Cada membro pode deliberar sobre suas anotações e juntos todos podem priorizar as ações de melhorias mais prioritárias e definir ações concretas.
É difundido o uso de Analise de Causa-Raiz na forma de Diagrama de Causa e Efeito, os “5 porquês” [Sistema Toyota de Produção] ou Árvore da Realidade Atual, com base na Teoria das Restrições para realizar sua Retrospectiva.
Busque manter suas reuniões com um ambiente colaborativo e animado.
28
