SlideShare uma empresa Scribd logo
1 de 28
1
APOSTILA INTRODUTÓRIA
AOSCRUM
2
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 ________________________________________________________ 9
Conceitos do SCRUM ______________________________________________________________ 9
O que é SCRUM?__________________________________________________________________ 9
Pilares do SCRUM ________________________________________________________________ 10
O SCRUM ________________________________________________________________ 11
Papéis no SCRUM ________________________________________________________________ 12
Product Owner ________________________________________________________________ 12
Scrummaster__________________________________________________________________ 12
Time ________________________________________________________________________ 12
O ciclo do SCRUM _________________________________________________________ 14
Reunião de Planejamento da Release _________________________________________ 14
Artefatos do Release Planning ______________________________________________________ 14
Backlog do Produto ____________________________________________________________ 14
Release Burndown _____________________________________________________________ 16
Dicas além do SCRUM_____________________________________________________________ 17
Definição de "Pronto" ______________________________________________________ 18
A Sprint _________________________________________________________________ 19
Planejamento da Sprint_____________________________________________________ 19
Dicas além do SCRUM_____________________________________________________________ 20
Execução da Sprint ________________________________________________________ 22
Artefatos da Sprint _______________________________________________________________ 22
Backlog da Sprint ______________________________________________________________ 22
Sprint Burndown_______________________________________________________________ 24
Dicas além do SCRUM_____________________________________________________________ 25
Reunião Diária ____________________________________________________________ 26
Dicas além do SCRUM_____________________________________________________________ 26
Revisão da Sprint__________________________________________________________ 27
Dicas além do SCRUM_____________________________________________________________ 27
Retrospectiva da Sprint_____________________________________________________ 28
Dicas além do SCRUM_____________________________________________________________ 28
3
Í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
4
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
5
Introdução ao Manifesto Ágil
Em 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. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arien van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward 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.
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
6
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.
7
Os princípios do Manifesto Ágil
Complementares 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
8
Metodologias Ágeis
Com 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)
FeatureDrivenDevelpoment (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.
9
SCRUM
A origem do SCRUM
De início, o SCRUM foi concebido como uma forma de gerenciamento de projetos de produtos
complexo por IkujiroNonaka e HirotakaTakeuchi, no livro “The New NewProductDevelopment
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 trabalharam em sua formação.
Em 1995 o SCRUM foi formalizado por Ken Schwaber, Mike Beedle e Jeff Sutherland e
apresentado oficialmente na OOPLSA (Object-OrientedProgramming, Systems,
LanguagesandApplications).
Conceitos do SCRUM
O SCRUM tem em sua base os conceitos de:
LEAN
Desenvolvimento iterativo e incremental
Team Process
Micro enterprisedevelopment
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
10
Pilares do SCRUM
Trê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.
11
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
ProductOwner: 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
12
Papéis no SCRUM
O Time SCRUM é composto por um Scrummaster, ProductOwner e pelo Time.
ProductOwner
O ProductOwner é o responsável por maximizar o ROI (ReturnonInvestiment) do Projeto. Seu
papel é fundamental e suas atribuições são de grandes responsabilidades. O ProductOwner
deve manter vivo o ProductBacklog, 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 ProductOwner é 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 ProductOwner.
Dentre as atribuições do ProductOwner, 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
Scrummaster
O 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 ProductOwner na manutenção do ProductBacklog
Proteger o time de interferências externas
Promover práticas e procedimentos que auxiliem o Time no desenvolvimento do
Produto
Time
O Time tem a responsabilidade de realizar e entregar o produto solicitado pelo ProductOwner.
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êmsubtimes dedicados a áreas particulares do produto. Os Times SCRUM
devem ter tais características:
Auto organizado
Interdisciplinar
13
Ser formador por cinco até nove membros
Ser auto organizado implica que ninguém deve dizer ao Timecomo transformar as solicitações
do ProductOwner 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 ProductOwner
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.
14
O ciclo do SCRUM
Reunião de Planejamento da Release
A 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 ProductOwner 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 Produto
O ProductOwneré responsável por gerar e manter oBacklog 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 ProductOwner 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.
15
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
16
Release Burndown
O 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.
17
Dicas além do SCRUM
Definiçõ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 ShirtSize 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 (UserStories),
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 UserStories
ou outras medidas abstratas.
18
Definição de "Pronto"
O SCRUM define que o Time e o ProductOwner 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 ProductOwner 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 ProductOwner 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.
19
A Sprint
Uma 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 Sprint
O 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 ProductOwner apresenta o Backlog do Produto ao Time e destaca os itens de
maior prioridade. O ProductOwner 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 ProductOwner. 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.
20
Dicas além do SCRUM
É difundida a utilização de UserStories
[http://www.extremeprogramming.org/rules/userstories.html] para se popular o Backlog da
Sprint e Backlog do Produto. Uma UserStory descreve uma funcionalidade que deve conter
valor de negócio para o usuário ou cliente do projeto. A UserStory é 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 almoxarifadopara
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
ProductOwner. 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, ProductOwner e Time. Alguns
times adotam o Story-Writing Workshop. Tal reunião é realizada entre cliente, ProductOwnere
Time onde os mesmos escrevem as histórias, os critérios de aceite e aprofundam no
conhecimento do produto.
21
É difundida também a utilização do Planning Poker para se estimar uma UserStory. 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 UserStory
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 UserStory
em um incremento pronto de produto.
Uma UserStory é 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 UserStory. 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 ProductOwner pode auxiliar.
22
Execução da Sprint
Uma 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 Sprint
O 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 Sprinte 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.
23
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 Estimativa
Inserção de novos materiais do Almoxarifado
– 3 pontos
Refinar requisitos 2 horas
Tela de inserção de
dados
4 horas
Validação do código
do material
3 horas
Testes de aceite 2 horas
Alterar quantidade de materiais existentes no
Almoxarifado – 2 pontos
Refinar requisitos 2 horas
Seleção de material 1 hora
Alteração da
descrição e
quantidade do
material
3 horas
Teste de aceite 1 hora
Remover material do cadastro do
Almoxarifado – 5 Pontos
Refinar requisito 1 hora
Excluir material 2 horas
Teste de aceite 3 horas
10 pontos 24 horas
Tabela 2 – Backlog da Sprint
24
Sprint Burndown
O 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.
25
Dicas além do SCRUM
Para 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
Almoxarifado
Tela de
inserção de
dados
Validaçã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 aceite
Remover
material do
cadastro do
Almoxarifado
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.
26
Reunião Diária
A 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 ProductOwner,
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 SCRUM
Ao final da Reunião diária o Time pode colaborar com o ProductOwner 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.
27
Revisão da Sprint
No 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 ProductOwner. O
Time SCRUM e pessoas interessadas se juntam para conversar sobre o que foi realizado. O
Time apresenta para o ProductOwner os itens prontos e o ProductOwner 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
ProductOwneratualiza 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 SCRUM
O 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 ProductOwner e através deles, orientar a
apresentação. Itens que forem rejeitados pelo ProductOwner devem voltar para o Backlog do
Produto para serem analisados novamente. O ideal é que o ProductOwner possa interagir com
o sistema durante a apresentação. Isto aguça os sentimentos do ProductOwner em relação ao
produto. Sempre se deve buscar apresentar produto funcionado.
28
Retrospectiva da Sprint
Logo 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 SCRUM
Existem 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.

Mais conteúdo relacionado

Mais procurados

Uma introdução ao SCRUM
Uma introdução ao SCRUMUma introdução ao SCRUM
Uma introdução ao SCRUMelliando dias
 
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...Thiago Compan
 
Scrum - Framework, Competências e Valores (versão community)
Scrum -  Framework, Competências e Valores (versão community)Scrum -  Framework, Competências e Valores (versão community)
Scrum - Framework, Competências e Valores (versão community)Manoel Pimentel Medeiros
 
Workshop Scrum - 8 horas
Workshop Scrum - 8 horasWorkshop Scrum - 8 horas
Workshop Scrum - 8 horasWise Systems
 
Guia do Papel e Responsabilidade do Scrum Master
Guia do Papel e Responsabilidade do Scrum MasterGuia do Papel e Responsabilidade do Scrum Master
Guia do Papel e Responsabilidade do Scrum MasterPaulo Lomanto
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilIsrael Santiago
 
Palestra sobre metodologia Scrum
Palestra sobre metodologia ScrumPalestra sobre metodologia Scrum
Palestra sobre metodologia ScrumPersonal
 
Scrum em 15 minutos
Scrum em 15 minutosScrum em 15 minutos
Scrum em 15 minutosSerge Rehem
 
Lean Kanban
Lean KanbanLean Kanban
Lean KanbanLucashgt
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosWilliam Lima
 
2020 scrum-guide-portuguese br
2020 scrum-guide-portuguese br2020 scrum-guide-portuguese br
2020 scrum-guide-portuguese brPriscila Pinheiro
 
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Annelise Gripp
 

Mais procurados (20)

Uma introdução ao SCRUM
Uma introdução ao SCRUMUma introdução ao SCRUM
Uma introdução ao SCRUM
 
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
Resumo do livro SCRUM a arte de fazer o dobro do trabalho na metade do tempo ...
 
Scrum - Framework, Competências e Valores (versão community)
Scrum -  Framework, Competências e Valores (versão community)Scrum -  Framework, Competências e Valores (versão community)
Scrum - Framework, Competências e Valores (versão community)
 
Scrum guide-portuguese-br
Scrum guide-portuguese-brScrum guide-portuguese-br
Scrum guide-portuguese-br
 
Workshop Scrum - 8 horas
Workshop Scrum - 8 horasWorkshop Scrum - 8 horas
Workshop Scrum - 8 horas
 
Guia do Papel e Responsabilidade do Scrum Master
Guia do Papel e Responsabilidade do Scrum MasterGuia do Papel e Responsabilidade do Scrum Master
Guia do Papel e Responsabilidade do Scrum Master
 
Scrum - Desenvolvimento Ágil
Scrum - Desenvolvimento ÁgilScrum - Desenvolvimento Ágil
Scrum - Desenvolvimento Ágil
 
Palestra sobre metodologia Scrum
Palestra sobre metodologia ScrumPalestra sobre metodologia Scrum
Palestra sobre metodologia Scrum
 
Scrum em 15 minutos
Scrum em 15 minutosScrum em 15 minutos
Scrum em 15 minutos
 
Lean Kanban
Lean KanbanLean Kanban
Lean Kanban
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
SCRUM - Priorização do backlog
SCRUM  - Priorização do backlogSCRUM  - Priorização do backlog
SCRUM - Priorização do backlog
 
2020 scrum-guide-portuguese br
2020 scrum-guide-portuguese br2020 scrum-guide-portuguese br
2020 scrum-guide-portuguese br
 
Agile SCRUM
Agile SCRUMAgile SCRUM
Agile SCRUM
 
Scrum
ScrumScrum
Scrum
 
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
Extreme Programming - Workshop Praticas Jedi XP - LinguÁgil 2016
 
Gerenciamento Ágil de Projetos com Scrum
Gerenciamento Ágil de Projetos com ScrumGerenciamento Ágil de Projetos com Scrum
Gerenciamento Ágil de Projetos com Scrum
 
O que é SCRUM
O que é SCRUMO que é SCRUM
O que é SCRUM
 
Scrum
ScrumScrum
Scrum
 

Destaque

Museu Interativo_Ana
Museu Interativo_AnaMuseu Interativo_Ana
Museu Interativo_Anacarol_vaz
 
Carole pateman participação e teoria democrática
Carole pateman   participação e teoria democráticaCarole pateman   participação e teoria democrática
Carole pateman participação e teoria democráticaUniversity of Campinas
 
オンライン教育市場における就活生のための動画サイトへの変革提案
オンライン教育市場における就活生のための動画サイトへの変革提案オンライン教育市場における就活生のための動画サイトへの変革提案
オンライン教育市場における就活生のための動画サイトへの変革提案stucon
 
Trabajo semestral de diciembre 2013
Trabajo semestral de diciembre 2013Trabajo semestral de diciembre 2013
Trabajo semestral de diciembre 2013Axel Bonilla
 
Procesamiento de muestras IHQ
Procesamiento de muestras IHQProcesamiento de muestras IHQ
Procesamiento de muestras IHQJorge_lda
 
Planejamento Midia - Promott
Planejamento Midia - PromottPlanejamento Midia - Promott
Planejamento Midia - Promottpromott12
 
End Polio 2013 - Campanha do Rotary em Campo Grande/MS
End Polio 2013 - Campanha do Rotary em Campo Grande/MSEnd Polio 2013 - Campanha do Rotary em Campo Grande/MS
End Polio 2013 - Campanha do Rotary em Campo Grande/MSVanessa Campos
 

Destaque (16)

Museu Interativo_Ana
Museu Interativo_AnaMuseu Interativo_Ana
Museu Interativo_Ana
 
Carole pateman participação e teoria democrática
Carole pateman   participação e teoria democráticaCarole pateman   participação e teoria democrática
Carole pateman participação e teoria democrática
 
Presentation
PresentationPresentation
Presentation
 
オンライン教育市場における就活生のための動画サイトへの変革提案
オンライン教育市場における就活生のための動画サイトへの変革提案オンライン教育市場における就活生のための動画サイトへの変革提案
オンライン教育市場における就活生のための動画サイトへの変革提案
 
Equação do 2° grau ii
Equação do 2° grau iiEquação do 2° grau ii
Equação do 2° grau ii
 
Carta 2
Carta 2Carta 2
Carta 2
 
Premio Jornalismo2009
Premio Jornalismo2009Premio Jornalismo2009
Premio Jornalismo2009
 
Trabajo semestral de diciembre 2013
Trabajo semestral de diciembre 2013Trabajo semestral de diciembre 2013
Trabajo semestral de diciembre 2013
 
Procesamiento de muestras IHQ
Procesamiento de muestras IHQProcesamiento de muestras IHQ
Procesamiento de muestras IHQ
 
Final de gbi ii
Final de gbi iiFinal de gbi ii
Final de gbi ii
 
CWK CV
CWK CVCWK CV
CWK CV
 
O product backlog
O product backlogO product backlog
O product backlog
 
Planejamento Midia - Promott
Planejamento Midia - PromottPlanejamento Midia - Promott
Planejamento Midia - Promott
 
La isla
La islaLa isla
La isla
 
End Polio 2013 - Campanha do Rotary em Campo Grande/MS
End Polio 2013 - Campanha do Rotary em Campo Grande/MSEnd Polio 2013 - Campanha do Rotary em Campo Grande/MS
End Polio 2013 - Campanha do Rotary em Campo Grande/MS
 
Javascript
JavascriptJavascript
Javascript
 

Semelhante a Apostila introdutória ao Scrum (V1)

Agilidade - Palestra -Prodabel
Agilidade - Palestra -ProdabelAgilidade - Palestra -Prodabel
Agilidade - Palestra -ProdabelYoris Linhares
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareEverton vitor
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingDaniel Wildt
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...André Luis Celestino
 
Grupo 3 - Gestão Ágil (3).pptx
Grupo 3 - Gestão Ágil (3).pptxGrupo 3 - Gestão Ágil (3).pptx
Grupo 3 - Gestão Ágil (3).pptxssuser064821
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerAlan Carlos
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Maicon Zerbielli
 
Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013Lourenco P Soares
 
Introdução Metodologias áGeis Para Desenvolvimento De Software
Introdução  Metodologias áGeis Para Desenvolvimento De SoftwareIntrodução  Metodologias áGeis Para Desenvolvimento De Software
Introdução Metodologias áGeis Para Desenvolvimento De SoftwareMarcos Cardoso
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumRaphael Donaire Albino
 
Paloma costa mba gestao de projetos
Paloma costa   mba gestao de projetosPaloma costa   mba gestao de projetos
Paloma costa mba gestao de projetosPaloma Costa
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareThiago Reis da Silva
 
Valores e principios das metodologias ágeis
Valores e principios das metodologias ágeisValores e principios das metodologias ágeis
Valores e principios das metodologias ágeisKarol Oliveira
 

Semelhante a Apostila introdutória ao Scrum (V1) (20)

Agilidade - Palestra -Prodabel
Agilidade - Palestra -ProdabelAgilidade - Palestra -Prodabel
Agilidade - Palestra -Prodabel
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
 
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
Grupo 3 - Gestão Ágil (3).pptx
Grupo 3 - Gestão Ágil (3).pptxGrupo 3 - Gestão Ágil (3).pptx
Grupo 3 - Gestão Ágil (3).pptx
 
Lean software
Lean software Lean software
Lean software
 
Curso Scrum - Turma Visie
Curso Scrum - Turma VisieCurso Scrum - Turma Visie
Curso Scrum - Turma Visie
 
Manifesto Ágil.pdf
Manifesto Ágil.pdfManifesto Ágil.pdf
Manifesto Ágil.pdf
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test Manager
 
Metodologias de desenvolvimento
Metodologias de desenvolvimentoMetodologias de desenvolvimento
Metodologias de desenvolvimento
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
 
Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013
 
Introdução Metodologias áGeis Para Desenvolvimento De Software
Introdução  Metodologias áGeis Para Desenvolvimento De SoftwareIntrodução  Metodologias áGeis Para Desenvolvimento De Software
Introdução Metodologias áGeis Para Desenvolvimento De Software
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
 
Paloma costa mba gestao de projetos
Paloma costa   mba gestao de projetosPaloma costa   mba gestao de projetos
Paloma costa mba gestao de projetos
 
Scrum origens
Scrum origensScrum origens
Scrum origens
 
Princípios Ágeis
Princípios ÁgeisPrincípios Ágeis
Princípios Ágeis
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
 
Valores e principios das metodologias ágeis
Valores e principios das metodologias ágeisValores e principios das metodologias ágeis
Valores e principios das metodologias ágeis
 

Mais de Rafael Barbosa Camargo

Expectativas, objetivos e disfunções do papel Scrum Master
Expectativas, objetivos e disfunções do papel Scrum MasterExpectativas, objetivos e disfunções do papel Scrum Master
Expectativas, objetivos e disfunções do papel Scrum MasterRafael Barbosa Camargo
 
Traga me pessoas! Envolvimento, comprometimento e conhecimento
Traga me pessoas! Envolvimento, comprometimento e conhecimentoTraga me pessoas! Envolvimento, comprometimento e conhecimento
Traga me pessoas! Envolvimento, comprometimento e conhecimentoRafael Barbosa Camargo
 
Corra scrum master, corra para saber mais
Corra scrum master, corra para saber maisCorra scrum master, corra para saber mais
Corra scrum master, corra para saber maisRafael Barbosa Camargo
 
Análise de Negócios - Case de sucesso com Análise de Negócio Ágil - Agile Bra...
Análise de Negócios - Case de sucesso com Análise de Negócio Ágil - Agile Bra...Análise de Negócios - Case de sucesso com Análise de Negócio Ágil - Agile Bra...
Análise de Negócios - Case de sucesso com Análise de Negócio Ágil - Agile Bra...Rafael Barbosa Camargo
 
Cases de sucesso através de análise de negócio ágil
Cases de sucesso através de análise de negócio ágilCases de sucesso através de análise de negócio ágil
Cases de sucesso através de análise de negócio ágilRafael Barbosa Camargo
 
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Req...
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Req...Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Req...
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Req...Rafael Barbosa Camargo
 
Agile além fazenda: Os desafios e interesses de uma empresa
Agile além fazenda: Os desafios e interesses de uma empresaAgile além fazenda: Os desafios e interesses de uma empresa
Agile além fazenda: Os desafios e interesses de uma empresaRafael Barbosa Camargo
 
Liderança servidora e os Desafios da Motivação em Grupo
Liderança servidora e os Desafios da Motivação em GrupoLiderança servidora e os Desafios da Motivação em Grupo
Liderança servidora e os Desafios da Motivação em GrupoRafael Barbosa Camargo
 

Mais de Rafael Barbosa Camargo (16)

Statik e dinâmico
Statik e dinâmicoStatik e dinâmico
Statik e dinâmico
 
Expectativas, objetivos e disfunções do papel Scrum Master
Expectativas, objetivos e disfunções do papel Scrum MasterExpectativas, objetivos e disfunções do papel Scrum Master
Expectativas, objetivos e disfunções do papel Scrum Master
 
Histórias. Solução ou Hipótese
Histórias. Solução ou HipóteseHistórias. Solução ou Hipótese
Histórias. Solução ou Hipótese
 
Análise através de hipóteses
Análise através de hipótesesAnálise através de hipóteses
Análise através de hipóteses
 
Traga me pessoas! Envolvimento, comprometimento e conhecimento
Traga me pessoas! Envolvimento, comprometimento e conhecimentoTraga me pessoas! Envolvimento, comprometimento e conhecimento
Traga me pessoas! Envolvimento, comprometimento e conhecimento
 
Um feedback sobre seu feedback
Um feedback sobre seu feedbackUm feedback sobre seu feedback
Um feedback sobre seu feedback
 
Corra scrum master, corra para saber mais
Corra scrum master, corra para saber maisCorra scrum master, corra para saber mais
Corra scrum master, corra para saber mais
 
Análise de Negócios - Case de sucesso com Análise de Negócio Ágil - Agile Bra...
Análise de Negócios - Case de sucesso com Análise de Negócio Ágil - Agile Bra...Análise de Negócios - Case de sucesso com Análise de Negócio Ágil - Agile Bra...
Análise de Negócios - Case de sucesso com Análise de Negócio Ágil - Agile Bra...
 
Cases de sucesso através de análise de negócio ágil
Cases de sucesso através de análise de negócio ágilCases de sucesso através de análise de negócio ágil
Cases de sucesso através de análise de negócio ágil
 
Agile comedy stand up
Agile comedy stand upAgile comedy stand up
Agile comedy stand up
 
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Req...
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Req...Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Req...
Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócios e Engenharia de Req...
 
Scrum spin
Scrum spinScrum spin
Scrum spin
 
Agile além fazenda: Os desafios e interesses de uma empresa
Agile além fazenda: Os desafios e interesses de uma empresaAgile além fazenda: Os desafios e interesses de uma empresa
Agile além fazenda: Os desafios e interesses de uma empresa
 
Liderança servidora e os Desafios da Motivação em Grupo
Liderança servidora e os Desafios da Motivação em GrupoLiderança servidora e os Desafios da Motivação em Grupo
Liderança servidora e os Desafios da Motivação em Grupo
 
Domain game
Domain gameDomain game
Domain game
 
SCRUM do tradicional a o irreverente
SCRUM do tradicional a o irreverenteSCRUM do tradicional a o irreverente
SCRUM do tradicional a o irreverente
 

Último

Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx2m Assessoria
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASMarcio Venturelli
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx2m Assessoria
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx2m Assessoria
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)Alessandro Almeida
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAMarcio Venturelli
 

Último (8)

Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 

Apostila introdutória ao Scrum (V1)

  • 2. 2 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 ________________________________________________________ 9 Conceitos do SCRUM ______________________________________________________________ 9 O que é SCRUM?__________________________________________________________________ 9 Pilares do SCRUM ________________________________________________________________ 10 O SCRUM ________________________________________________________________ 11 Papéis no SCRUM ________________________________________________________________ 12 Product Owner ________________________________________________________________ 12 Scrummaster__________________________________________________________________ 12 Time ________________________________________________________________________ 12 O ciclo do SCRUM _________________________________________________________ 14 Reunião de Planejamento da Release _________________________________________ 14 Artefatos do Release Planning ______________________________________________________ 14 Backlog do Produto ____________________________________________________________ 14 Release Burndown _____________________________________________________________ 16 Dicas além do SCRUM_____________________________________________________________ 17 Definição de "Pronto" ______________________________________________________ 18 A Sprint _________________________________________________________________ 19 Planejamento da Sprint_____________________________________________________ 19 Dicas além do SCRUM_____________________________________________________________ 20 Execução da Sprint ________________________________________________________ 22 Artefatos da Sprint _______________________________________________________________ 22 Backlog da Sprint ______________________________________________________________ 22 Sprint Burndown_______________________________________________________________ 24 Dicas além do SCRUM_____________________________________________________________ 25 Reunião Diária ____________________________________________________________ 26 Dicas além do SCRUM_____________________________________________________________ 26 Revisão da Sprint__________________________________________________________ 27 Dicas além do SCRUM_____________________________________________________________ 27 Retrospectiva da Sprint_____________________________________________________ 28 Dicas além do SCRUM_____________________________________________________________ 28
  • 3. 3 Í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
  • 4. 4 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
  • 5. 5 Introdução ao Manifesto Ágil Em 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. Martin Mike Beedle Jim Highsmith Steve Mellor Arien van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward 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. 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
  • 6. 6 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.
  • 7. 7 Os princípios do Manifesto Ágil Complementares 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
  • 8. 8 Metodologias Ágeis Com 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) FeatureDrivenDevelpoment (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.
  • 9. 9 SCRUM A origem do SCRUM De início, o SCRUM foi concebido como uma forma de gerenciamento de projetos de produtos complexo por IkujiroNonaka e HirotakaTakeuchi, no livro “The New NewProductDevelopment 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 trabalharam em sua formação. Em 1995 o SCRUM foi formalizado por Ken Schwaber, Mike Beedle e Jeff Sutherland e apresentado oficialmente na OOPLSA (Object-OrientedProgramming, Systems, LanguagesandApplications). Conceitos do SCRUM O SCRUM tem em sua base os conceitos de: LEAN Desenvolvimento iterativo e incremental Team Process Micro enterprisedevelopment 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
  • 10. 10 Pilares do SCRUM Trê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.
  • 11. 11 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 ProductOwner: 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
  • 12. 12 Papéis no SCRUM O Time SCRUM é composto por um Scrummaster, ProductOwner e pelo Time. ProductOwner O ProductOwner é o responsável por maximizar o ROI (ReturnonInvestiment) do Projeto. Seu papel é fundamental e suas atribuições são de grandes responsabilidades. O ProductOwner deve manter vivo o ProductBacklog, 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 ProductOwner é 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 ProductOwner. Dentre as atribuições do ProductOwner, 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 Scrummaster O 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 ProductOwner na manutenção do ProductBacklog Proteger o time de interferências externas Promover práticas e procedimentos que auxiliem o Time no desenvolvimento do Produto Time O Time tem a responsabilidade de realizar e entregar o produto solicitado pelo ProductOwner. 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êmsubtimes dedicados a áreas particulares do produto. Os Times SCRUM devem ter tais características: Auto organizado Interdisciplinar
  • 13. 13 Ser formador por cinco até nove membros Ser auto organizado implica que ninguém deve dizer ao Timecomo transformar as solicitações do ProductOwner 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 ProductOwner 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.
  • 14. 14 O ciclo do SCRUM Reunião de Planejamento da Release A 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 ProductOwner 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 Produto O ProductOwneré responsável por gerar e manter oBacklog 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 ProductOwner 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.
  • 15. 15 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
  • 16. 16 Release Burndown O 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.
  • 17. 17 Dicas além do SCRUM Definiçõ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 ShirtSize 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 (UserStories), 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 UserStories ou outras medidas abstratas.
  • 18. 18 Definição de "Pronto" O SCRUM define que o Time e o ProductOwner 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 ProductOwner 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 ProductOwner 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.
  • 19. 19 A Sprint Uma 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 Sprint O 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 ProductOwner apresenta o Backlog do Produto ao Time e destaca os itens de maior prioridade. O ProductOwner 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 ProductOwner. 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.
  • 20. 20 Dicas além do SCRUM É difundida a utilização de UserStories [http://www.extremeprogramming.org/rules/userstories.html] para se popular o Backlog da Sprint e Backlog do Produto. Uma UserStory descreve uma funcionalidade que deve conter valor de negócio para o usuário ou cliente do projeto. A UserStory é 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 almoxarifadopara 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 ProductOwner. 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, ProductOwner e Time. Alguns times adotam o Story-Writing Workshop. Tal reunião é realizada entre cliente, ProductOwnere Time onde os mesmos escrevem as histórias, os critérios de aceite e aprofundam no conhecimento do produto.
  • 21. 21 É difundida também a utilização do Planning Poker para se estimar uma UserStory. 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 UserStory 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 UserStory em um incremento pronto de produto. Uma UserStory é 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 UserStory. 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 ProductOwner pode auxiliar.
  • 22. 22 Execução da Sprint Uma 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 Sprint O 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 Sprinte 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.
  • 23. 23 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 Estimativa Inserção de novos materiais do Almoxarifado – 3 pontos Refinar requisitos 2 horas Tela de inserção de dados 4 horas Validação do código do material 3 horas Testes de aceite 2 horas Alterar quantidade de materiais existentes no Almoxarifado – 2 pontos Refinar requisitos 2 horas Seleção de material 1 hora Alteração da descrição e quantidade do material 3 horas Teste de aceite 1 hora Remover material do cadastro do Almoxarifado – 5 Pontos Refinar requisito 1 hora Excluir material 2 horas Teste de aceite 3 horas 10 pontos 24 horas Tabela 2 – Backlog da Sprint
  • 24. 24 Sprint Burndown O 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.
  • 25. 25 Dicas além do SCRUM Para 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 Almoxarifado Tela de inserção de dados Validaçã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 aceite Remover material do cadastro do Almoxarifado 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.
  • 26. 26 Reunião Diária A 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 ProductOwner, 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 SCRUM Ao final da Reunião diária o Time pode colaborar com o ProductOwner 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.
  • 27. 27 Revisão da Sprint No 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 ProductOwner. O Time SCRUM e pessoas interessadas se juntam para conversar sobre o que foi realizado. O Time apresenta para o ProductOwner os itens prontos e o ProductOwner 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 ProductOwneratualiza 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 SCRUM O 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 ProductOwner e através deles, orientar a apresentação. Itens que forem rejeitados pelo ProductOwner devem voltar para o Backlog do Produto para serem analisados novamente. O ideal é que o ProductOwner possa interagir com o sistema durante a apresentação. Isto aguça os sentimentos do ProductOwner em relação ao produto. Sempre se deve buscar apresentar produto funcionado.
  • 28. 28 Retrospectiva da Sprint Logo 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 SCRUM Existem 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.