UNIVERSIDADE METODISTA DE SO PAULO

Clayton MORAIS
Daniel ARMBRUST
Rodrigo LEITE
Thiago OLIVEIRA





SCRUM














SOROCABA
2012
Clayton MORAIS
Daniel ARMBRUST
Rodrigo LEITE
Thiago OLIVEIRA







SCRUM




Trabalho de iniciao ao Projeto de Ao Profissional
apresentado a Universidade Metodista de So Paulo no
curso de Anlise e Desenvolvimento de Sistemas.








Orientador: Prof. Wilson Kobayashi







SOROCABA
2012

SUMRIO
1 INTRODUO....................................................................................................................04
2 AGILE DEVELOPMENT..................................................................................................05
2.1 Prs e Contras do Scrum.....................................................................................................06
2.2 Prs......................................................................................................................................06
2.3 Contras................................................................................................................................07
3 DEFINIO.........................................................................................................................08
3.1 Histria................................................................................................................................08
3.2 Histria dos idealizadores do Scrum...................................................................................08
3.3 SECI....................................................................................................................................09
3.4 Empresas que utilizam Scrum.............................................................................................09
3.5 Funo.................................................................................................................................11
4 GRFICO BURNDOWN....................................................................................................13
4.1 Story Cards ou Cartes de Estrias.....................................................................................13
4.2 Clculos de Estimativa........................................................................................................15
4.3 Planning Poker...................................................................................................................16
4.4 Velocidade de Desenvolvimento........................................................................................18
4.5 Montagem do grfico, atualizao e resultado....................................................................18
4.6 Reunies Scrum..................................................................................................................19
4.7 Sprint Planning Meeting.....................................................................................................19
4.8 Daily Scrum.........................................................................................................................20
4.9 Sprint Review......................................................................................................................20
4.10 Sprint Retrospective..........................................................................................................21
4.11 Task Board ou Quadro de Tarefas....................................................................................22
5 FERRAMENTAS PARA GESTO DE PROJETOS SCRUM.......................................24
5.1 Vantagens e facilidades de ferramentas online...................................................................24
5.2 Algumas ferramentas online...............................................................................................25
5.3 ScrumMe.............................................................................................................................25
5.4 PangoScrum........................................................................................................................26
5.5 ScrumHalf...........................................................................................................................29
6 COMO SCRUM E KANBAN SE RELACIONAM?........................................................30
6.1 O Scrum mais prescritivo que o Kanban!........................................................................30
6.2 Scrum prescreve iteraes em time-box..............................................................................31
6.3 Kanban limita WIP por estado de fluxo de trabalho, Scrum por iterao..........................32
6.4 Scrum prescreve estimativas e velocidade..........................................................................34
6.5 Ambos permitem trabalhar em mltiplos produtos simultaneamente................................35
6.6 Resumo de Scrum vs. Kanban............................................................................................36
6.7 Similaridades.......................................................................................................................36
7 PROCESSO DE CERTIFICAO SCRUM....................................................................38
7.1 Certified Scrum Master.......................................................................................................39
7.2 Quem ganha mais ao usar Scrum?......................................................................................40
8 CONCLUSO......................................................................................................................42
9 GLOSSRIO........................................................................................................................43
10 REFERNCIAS.................................................................................................................44
4

1 INTRODUO

Ser apresentado neste trabalho, a utilizao da ferramenta Scrum para os
desenvolvedores de sistemas, tendo por intuito, mostrar os seus mtodos e
detalhes, as solues que a ferramenta dispe para seus utilizadores, ilustraes de
eventos relacionados, custo x beneficio at a certificao existente e tendo por base,
iniciar o Projeto de Ao Profissional da Universidade Metodista de So Paulo.

5

2 AGILE DEVELOPMENT

Desenvolvimento gil de software ou mtodo gil um conjunto de
metodologias de desenvolvimento de software que visam desenvolvimento
cooperativo, baseado mais nas pessoas e suas iteraes, em vez de focar em
grandes esforos de planejamento de requisitos e processos rgidos. importante
ressaltar que o desenvolvimento gil prega o simples, entretanto, ser simples implica
em grande carga de disciplina e organizao. Implementar uma metodologia gil
requer uma mudana de mentalidade nas pessoas que participam do processo de
desenvolvimento. Hoje em dia, existem inmeros frameworks para facilitar o
desenvolvimento de software gil, e todos focam no desenvolvimento em curto
perodo de tempo. Mtodos geis so mais adequados para projetos com pequenos
times, com no mximo de 20 a 40 pessoas. Enfatizam comunicaes em tempo real,
preferencialmente face a face junto equipe, a documentos escritos. Em
contrapartida, produzem pouca documentao.
Mtodos geis tm muito em comum com tcnicas de desenvolvimento rpido
de aplicao e preferencialmente utilizam frameworks sobre as linguagens de
programao para reduzir esforos de cdigos repetitivos. So particularmente
adequados para equipes que tm que lidar com mudanas rpidas ou imprevisveis
nos requisitos.
Desenvolvimento gil sinnimo de ciclo de desenvolvimento propcio a
mudanas de requisitos, baseado em iteraes curtas e com entrega de software
funcionando. Com isto, o resultado facilmente avaliado pelo cliente.










Figura 01: Viso do Desenvolvimento gil
6

Os mtodos geis iniciais criados incluam Scrum, Crystal Clear, Programao
extrema, Adaptive Software Development, Feature Driven Development, e Dynamic
Systems Development Method.
Falando de mtodos geis, iremos citar neste documento o Scrum. Poremos
dizer que Scrum um processo de gerenciamento de projetos geis, adaptado para
a rea de desenvolvimento de software, pelo especialista Ken Schwaber. Leva em
considerao planejamento no linear, porm de maneira mais exaustiva e est
focada em agregar valor para o cliente e em gerenciar os riscos, fornecendo um
ambiente seguro. Pode ser utilizada na gesto do projeto aliada a uma metodologia
de desenvolvimento como Programao Extrema, FDD, OpenUP, DSDM, Crystal ou
outras. Podemos tambm dizer que Scrum um framework.
A primeira experincia com o Scrum ocorreu em uma fbrica de automveis,
onde se constatou que a utilizao de equipes pequenas e multidisciplinares
produzia melhores resultados. A partir de 1995, Ken Schwaber formalizou a definio
de Scrum e ajudou a implant-lo em desenvolvimento de software em todo o mundo.
Dentre as tcnicas de utilizao do Scrum, h a entrega de produtos em
perodos de tempo pr-estabelecidos, nunca inferiores h uma semana ou
superiores h trinta dias. Para estimular o contato entre empresa e cliente, os
projetos so interrompidos em perodos regulares de tempo. A essas aes d-se o
nome de Sprint.

2.1 Prs e Contras do Scrum
2.2 Prs
Grande nfase no trabalho em equipe.
O framework foca no trabalho em equipe e na troca de informaes junto a mesma o
tempo todo. Elimina documentos complexos e manter as partes envolvidas o mais
atualizado possvel.
A equipe aprende e contribui durante todo o processo.
Todas as partes envolvidas ficam 100% ativas com toda evoluo do
desenvolvimento. A disseminao do conhecimento maior como tambm a
participao na entrega das partes tambm.
Entregas menores e acompanhamento do cliente.
O cliente acompanha toda a fase de desenvolvimento do software criticando o
mesmo. Com isto, a entrega ser sempre prxima da realidade esperada (feedback
7

imediato).

2.3 Contras
O framework no foi desenhado para projetos grandes.
Projetos maiores no se adaptam ao modelo empregado do framework uma vez que
haver muita interao com o cliente. As criticas que no podem ser medidas podem
atrapalhar os prazos e ir de encontro com o dito gil.
Adequado somente para desenvolvimento de novos produtos.
O framework no pode ser adaptado a uma correo de software ou um
redesenvolvimento. Ele somente pode ser empregado para novos
desenvolvimentos, onde temos somente a ideia da entrega.
No adaptvel a mudanas.
O framework no adaptvel a mudanas no que foi acordado no start do
desenvolvimento. Toda mudana gera uma reorganizao das ideias e processos
subsequentes. Quebra do Agile.

8

3 DEFINIO
O Scrum um processo de desenvolvimento iterativo e incremental para
gerenciamento de projetos e desenvolvimento gil de software. Scrum no um
processo que prescreve, ou seja, ele no descreve o que fazer em cada situao.
Ele usado para trabalhos complexos nos quais impossvel predizer tudo o que ir
ocorrer.
Apesar de Scrum ter sido destinado para gerenciamento de projetos de software, ele
pode ser utilizado em equipes de manuteno de software ou como uma abordagem
geral de gerenciamento de projetos/programas.

3.1 Histria
Inicialmente, o SCRUM foi concebido como um estilo de gerenciamento de projetos
em empresas de fabricao de automveis e produtos de consumo, por Takeuchi e
Nonaka no artigo "The New Product Development Game" (Harvard Business
Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes
pequenas e multidisciplinares (cross-functional) produziram os melhores resultados,
e associaram estas equipes altamente eficazes formao Scrum do Rugby
(utilizada para reincio do jogo em certos casos). Jeff Sutherland, John Scumniotales
e Jeff McKenna conceberam, documentaram e implementaram o Scrum, na empresa
Easel Corporation em 1993, incorporando os estilos de gerenciamento observados
por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definio de Scrum e
ajudou a implant-lo no desenvolvimento de softwares em todo o mundo.

3.2 Histria dos idealizadores do Scrum
Ikujiro Nonaka (nascido a 10 de maio de 1935) professor emrito da Universidade
Hitotsubashi. Em 2008 o Wall Street Journal o listou como uma das pessoas com o
pensamento mais influente na rea de negcios. Os professores Ikujiro Nonaka e
Hirotaka Takeuchi conceberam no livro "The Knowledge-Creating Company" a
espiral do conhecimento, tambm conhecida como modelo SECI, uma das mais
conhecidas teorias da Gesto do Conhecimento (Gourlay 2003), para apresentar o
processo de interao entre o conhecimento explcito e o conhecimento tcito.



9

3.3 SECI:
Socializao
Externalizao
Combinao
Internalizao

Hirotaka Takeuchi (nascido a 16 de outubro de 1946) reitor da Escola de
Estratgia Corporativa Internacional na Universidade Hitotsubashi e foi descrito pela
BusinessWeek como um dos dez melhores professores de gerncia para programas
de educao corporativa no mundo. Ele coautor de artigos com o professor Ikujiro
Nonaka sobre conhecimento tcito.

3.4 Empresas que utilizam Scrum
Abril Digital
Accion
Add Technologies (RJ)
Agncia Goiana de Habitao S/A AGEHAB
Alterdata Sofware
Aspercom
Aurum
B2ML Sistemas
B5S Tecnologia
Banco Fator
Bluesoft
Borland/Microfocus
BRQ
BSA
C.E.S.A.R
Caelum
Cerprosoft Informtica
Ci&T;
Concrete Solutions
Crivo
CVale
10

DB1 Informtica
Dgitro
Dito Internet
ENGESET Eng. Servios de Telecomunicaes S/A
Euax Gesto de Projetos
Fundao de Ensino Superior de Passos
Globo.com
Gol
H2J Solues
Hotsoft Informtica
Instituto Nokia de Tecnologia
Inspira Tecnologia
Insula TI
Iea
Keeplay Game Studios
Knowtec
LBS Local
Living Consultoria
Locaweb
Meta IT
Microsoft
MobileCOMM
OnCast Technologies
Petrobras
Pitanga
Plugar Informaes Estratgicas
Powerlogic
Process Informtica
ProcessMind
Provider Tecnologia
Resolve Informtica
Secretaria de Estado da Sade de Gois
SEFAZ
SG Sistemas
11

Soluo Simples
Stefanini It Solutions
SulAmrica Seguros Sade / Autos
Synchro
Tecgraf
Totvs
TRIP Linhas Areas
UOL
Uptodate Consulting
Vertigo
Visie Padres Web
Visual Systems
Vivo
WebGoal
Way2 Technology
Web Road Mdias & Sistemas
(Lista atualizada em 06/07/2010)

3.5 Funo
A funo primria do Scrum ser utilizado para o gerenciamento de projetos de
desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim
como Extreme Programming e outras metodologias de desenvolvimento. Porm,
teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas
necessitam trabalhar juntas para atingir um objetivo comum, como iniciar uma escola
pequena, projetos de pesquisa cientfica, ou at mesmo o planejamento de um
casamento.
Mesmo que idealizado para ser utilizado em gesto de projetos de desenvolvimento
de software ele tambm pode ser usado para a gerncia de equipes de manuteno,
ou como uma abordagem para gesto de programas.
Algumas caractersticas de Scrum
Clientes se tornam parte da equipe de desenvolvimento (os clientes devem
estar genuinamente interessados na sada);
Entregas frequentes e intermedirias de funcionalidades 100% desenvolvidas;
Planos frequentes de mitigao de riscos desenvolvidos pela equipe;
12

Discusses dirias de status com a equipe;
A discusso diria na qual cada membro da equipe responde s seguintes
perguntas:
O que fiz desde ontem?
O que estou planejando fazer at amanh?
Existe algo me impedindo de atingir minha meta?
Transparncia no planejamento e desenvolvimento;
Reunies frequentes com os stakeholders (todos os envolvidos no processo)
para monitorar o progresso;
Problemas no so ignorados e ningum penalizado por reconhecer ou
descrever qualquer problema no visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que
"trabalhar horas extras" no necessariamente significa "produzir mais".


13

4 GRFICO BURNDOWN
O grfico burndown em SCRUM uma poderosssima ferramenta de clculo de
desempenho e visualizao de capacidade e velocidade de desenvolvimento.
Representa a relao do trabalho a ser realizado versus o tempo disponvel mximo
estimado para a realizao total da tarefa, entenda-se iterao ou sprint.
Possui duas dimenses ou eixos. O eixo X, sua linha horizontal, traz a escala de
dias restantes para o trmino do prazo estimado. O eixo Y, sua linha vertical, traz a
representao escalar da unidade escolhida pelo grupo para o calculo de esforo
necessrio para finalizar o sprint, normalmente sendo utilizados os story points ou
horas ideais.














4.1 Story Cards ou Cartes de Estria
Antes de iniciar o clculo da estimativa, apresentada cada tarefa que foi separada
para o sprint, geralmente no formato Quem, o que e porque, em outras palavras,
para quem a tarefa ser feita, ou quem solicitou, o que ser feito e qual o motivo
pelo qual a solicitao foi realizada, tendo estas informaes apresentadas de forma
clara, cada tarefa descrita em cartes que representam visualmente cada tarefa
dentro do quadro de tarefas.
Esta explicao feita pelo gestor do projeto, pelo product owner ou pelo cliente,
quando um carto de estria torna-se muito complexo, amplo, grande ou com muitas
necessidades, dado a ele o nome de pico. Para organizar este pico, pode-se
Figura 03: Ilustrao de um grfico Burndown
14

subdividi-lo por temas, que so agrupamentos de necessidades menores que tratem
de mesmo assunto, cada tema, por sua vez, contm um grupo de cartes de estria,
cada um com fraes menores das especificaes e necessidades do pico.
Ao escrever uma estria, tem se usado muito ultimamente o mtodo INVEST, que
nada mais do que um lembrete criado por Bill Wake (autor de vrios livros em
diversas reas, inclusive muito sobre a metodologia Agile) para facilitar o
entendimento e memorizao das boas praticas que devem ser levadas em
considerao no momento de escrever a estria. INVEST o acrnimo para as
palavras: Indepent, Negotiable, Valuable, Estimatable, Small e Testable, o que
lembra que a estria, antes de seguir para o sprint, deve ser:
Independente, ou seja, no deve depender de outra estria para ser
desenvolvida;
Deve ser negocivel, flexvel de forma que possa ser discutido pelos
membros;
Deve ter valor para o cliente ou negcio, ele a especificao de uma
funcionalidade e no de uma tarefa;
Deve ser estimvel, ou seja, sua descrio deve fornecer a informao
necessria e suficiente, ao mesmo tempo em que resumida de forma que seja
possvel realizar a estimativa do esforo necessrio para realizar sua
estimativa;
Deve possuir o tamanho necessrio para que seja entendida sua
funcionalidade, no havendo esta possibilidade a estria deve ser includa em
outra estria no caso de ser muito pequena ou dividida em estrias menores
caso seja muito grande;
A ltima letra de INVEST indica que a estria deve ser testvel, ou seja, deve
ser claro o suficiente para que no produto final seja possvel testar se o
objetivo foi alcanado.
Ultimamente, tambm muito tem se utilizado o acrnimo SMART, (Specific,
Measurable, Achivable, Realistic, Timed) para planejar as tarefas da estria, que
devem ser:
Especficos: Devem dar ao time tudo que eles precisam saber para iniciar o
trabalho;
15

Mensurveis: Deve poder ser convertido em um nmero, uma dificuldade,
uma medida;
Atingveis: Deve ser possvel de se alcanar;
Realistas: Devem ser calculados usando todos os fatores envolvidos,
inclusive os humanos;
Temporizados: Devem ter seu tempo calculado de forma que no seja curto e
torne os objetivos impossveis nem to longos que tornem o desenvolvimento
maante.
Cada carto pode apresentar tambm um valor numrico referente prioridade ou
importncia da tarefa, assim tornando mais fcil a posterior deciso de quais
estrias entraro no prximo sprint.
Estes cartes so, aps o planejamento inicial, divididos por funcionalidades
necessrias para a realizao ou concluso daquela estria, vamos nos referir a
estas funcionalidades como tarefas.


4.2 Clculos da Estimativa
O esforo necessrio para a finalizao de uma iterao deve ser calculado entre o
grupo SCRUM, e pode ser medido por times iniciantes na metodologia, usando-se
horas ideais, e por times mais experientes usando pontos de histria ou story points,
este ultimo amplamente utilizado na maioria dos praticantes do SCRUM.
Neste mtodo de clculo o time SCRUM decide a dificuldade de uma tarefa do
Sprint, atribuindo a ela pontos numricos, sendo zero a tarefa mais fcil e cem, a
tarefa mais trabalhosa, somam-se estes pontos de cada tarefa que compor a
iterao e se alcanar o mximo de esforo necessrio para o cumprimento do
sprint backlog.
A forma de se calcular quantos pontos devem ser atribudos a uma tarefa varia de
acordo com a experincia do membro do time que est realizando a estimativa. Um
Figura 04: Exemplo de Story Card
T
16

programador experiente pode atribuir um nmero menor a uma tarefa enquanto um
programador menos experiente pode atribuir um nmero de pontos muito maior. O
inverso pode ser possvel, quando um programador mais hbil atribui um nmero
maior a uma tarefa, devido a que com sua experincia, consegue visualizar ngulos
do projeto que um desenvolvedor iniciante ainda no possui o feeling necessrio
para encontrar.
Existem alguns mtodos utilizados para se realizar a estimativa de esforo
necessrio, dentre eles o planning poker, o calculo atravs de dias ideais ou ainda o
mtodo que realiza a estimativa atravs de pontos de funo.

4.3 Planning Poker
Devido diferena na quantidade de pontos que cada membro atribui a uma tarefa,
foram criados alguns mtodos para decidir os pontos necessrios que representaro
aquela tarefa no grfico burndown.
A mais utilizada comumente entre os praticantes o planning poker, neste mtodo,
cada participante do time SCRUM tem em mos um pseudo baralho de cartas
numeradas, comumente utilizando a sequncia escalar numrica de Fibonacci.

Leonardo Fibonacci, tambm conhecido como Leonardo de Pisa, Leonardo
Pisano ou ainda Leonardo Bigollo, mas na maioria das vezes, simplesmente
como Fibonacci foi um matemtico italiano. considerado por alguns como o
mais talentoso matemtico ocidental da Idade Mdia.

Ficou conhecido pela
descoberta da sequncia de Fibonacci e pelo seu papel na introduo
dos algarismos arbicos na Europa.

Esta sequncia numrica distinta comeou a ser usada de forma a facilitar a
preciso dos clculos das estimativas de esforo necessrio, ao mesmo tempo em
que visa no dar uma falsa impresso de exatido nestas mesmas estimativas, pois,
em desenvolvimento nem sempre possvel declarar de forma absoluta o tempo ou
o esforo necessrio para a realizao de uma tarefa distinta. Nesta sequncia, so
usados comumente os nmeros 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Deve-se esclarecer aqui que a forma de calcular a estimativa neste mtodo
emprico, virtual e depende da experincia dos integrantes do time para chegar a um
valor aceitvel para se usar como base estimada. No existe forma de se calcular
17

com exatido o tempo ou esforo necessrio para a finalizao de uma tarefa, visto
que o planejamento depende de fator humano, inclusive disponibilidade de mo de
obra, comprometimento do time, inspirao, ausncia de impedimentos entre outros.













Tendo em mos as cartas, cada uma contendo um nmero desta sequncia,
primeiramente escolhe-se uma tarefa cujos todos concordem que tem o valor de
dois pontos, isto ser o ponto de partida para a distribuio dos pontos para as
demais tarefas do sprint. Cada membro do grupo, durante o clculo da estimativa,
escolhe uma das cartas aps ouvir os requisitos e parmetros da tarefa explicada
pelo gestor do projeto, pelo product owner, ou cliente.
Apenas aps todos escolherem uma carta, os valores so abertos para o gestor,
finalizando o que chamado de rodada. Neste primeiro conjunto de resultados,
haver diferenas nos nmeros apresentados por cada membro da equipe, neste
caso, feita uma comparao entre os membros que atriburam o maior e menor
numero de pontos tarefa. O dilogo neste momento fundamental, cada um
destes dois participantes justifica sua escolha, dando seus pareceres e motivos da
escolha daquela pontuao.
Aps este dilogo iniciada mais uma rodada onde novamente os membros do
grupo selecionam uma carta. Ao exibir os resultados as diferenas tendem a
diminuir, caso contrrio um novo dilogo e uma nova rodada so iniciados, at que
haja um consenso da pontuao que ser dada quele carto.
Figura 05: Exemplo de Baralho para Planning Poker

18

Somados todos os pontos das tarefas que compor o sprint, o resultado torna-se o
eixo X do nosso grfico burndown.


4.4 Velocidade de desenvolvimento
A velocidade de desenvolvimento do time SCRUM calculada, quando se usando o
mtodo de story points, atravs da quantidade de pontos que so eliminados em um
dia de trabalho focado no desenvolvimento, trazendo o resultado no formato pontos
por dia ou ainda pontos por hora se dividido o dia de trabalho entre as horas teis
somadas de cada membro do time.
Esta velocidade inicialmente calculada atravs de simulaes ou projetos pilotos.
Dados o esforo necessrio e a velocidade da equipe, a lgica matemtica trar o
nosso eixo X do grfico burndown, sendo este eixo o prazo estimado para a entrega.
Divide-se o total de story points pela quantidade de pontos dirios que a equipe
pode eliminar, o resultado desta diviso trar a quantidade de dias necessrios
estimada para a entrega do sprint release.

4.5 Montagem do grfico, atualizao e resultado
Tendo em mos os nossos eixos X e Y, necessrio realizar a atualizao diria do
grfico, com os resultados dirios alcanados.














Figura 06: Exemplo de grfico Burndown
19

A linha deve representar o esforo gasto a cada dia, de forma a visualmente tornar
claro o quo prximo o prazo est de ser atingido e o quanto o time deve ser
eficiente para a concluso da tarefa.
Um fato muito importante a ser esclarecido que seguindo a metodologia do
SCRUM, os desenvolvedores no fazem esforo extraordinrio, fora do planejado
para atingir as metas, portanto, o grfico apresentando resultado indesejado,
apontando para que os objetivos no sejam cumpridos dentro do prazo estipulado,
feito um reajuste das estrias tratadas pelo product owner e scrum master, estes
calculam a necessidade de se entrar em contato com o cliente e diminuem a
quantidade total de pontos do sprint, de forma que o produto final prometido ao
cliente no seja afetado criticamente, assim o prazo dado ao cliente ser atingido.
esta capacidade de visualizao de resultado e estimativa que torna o grfico
to eficaz dentro da metodologia. Graas a ele, possvel realizar projees para
projetos futuros, estimativas melhores, adaptaes de plano e melhorias no
processo.

4.6 Reunies Scrum
Em Scrum, existem reunies que definem o andamento, planejamento e reviso do
sprint j definido, estas reunies consistem em Daily Scrum, Sprint Planning
Meeting, Sprint Review e Sprint Retrospective.

4.7 Sprint Planning Meeting
a primeira reunio, a reunio de planejamento do sprint, onde todo o time de
desenvolvedores, product owner, scrum master e se necessrio, clientes ou seus
representantes se renem e discutem o objetivo ou meta que o sprint dever ou
pretender alcanar.
neste encontro que o product backlog dividido de acordo com suas prioridades e
decidido o objetivo que o produto final deste sprint deve apresentar.
Neste evento, os gestores do projeto apresentam o escopo do produto final e das
necessidades do cliente, o time de desenvolvedores faz as perguntas necessrias
para detalhar a tarefa e ter um parecer prvio e tcnico do que deve ser feito. Este
time separadamente se encontra posteriormente a este evento e decidem se devem
ou no negociar com o product owner a retirada de alguns pontos para que o
objetivo seja alcanado.
20

Normalmente esta reunio dividida em duas partes, sendo a primeira parte a
apresentao do product backlog por parte do product owner e a sesso de
perguntas do time de desenvolvedores e a segunda parte, a deciso por do que ser
separado para a realizao do sprint.

4.8 Daily Scrum
a reunio diria do sprint em desenvolvimento, considerada por muitas empresas
como a mais importante das reunies do Scrum, consiste em um encontro dirio
com todos os envolvidos no projeto, com exceo do product owner, em horrio e
local categoricamente determinado e de preferncia imutvel, com durao de
quinze minutos ou menos, desenvolvido sempre com todos os participantes em p,
normalmente em frente ao task board. O motivo de a reunio ser desenvolvida em
p forar os participantes do encontro a se expressarem de forma rpida e
consistente, pois o ato de estar em p causa desconforto fsico e isto faz com que os
participantes anseiem o seu trmino.
Os objetivos deste encontro de forma resumida apresentar o que cada
desenvolvedor conseguiu progredir no dia anterior referente ao sprint, o que cada
membro pretende fazer no dia atual e quais os impedimentos surgiram que
impediram o progresso do desenvolvimento.
importante frisar que nenhum problema resolvido neste encontro, ele apenas
redireciona o foco dos esforos para onde realmente devem estar. Apenas resumos
dos fatos devem ser apresentados e extremamente importante o dilogo de todos
os participantes do grupo.
Tambm de suma importncia que o encontro dirio no se torne um ritual a ser
cumprido, de forma que os participantes no opinem de forma significativa ou que
novos pontos no sejam levantados para discusso. Os encontros devem ser cem
por cento produtivos todos os dias, os impedimentos devem ser listados para
tratamento futuro e os progressos devem ser contabilizados. Este evento tambm
no deve tornar-se uma reunio social entre os participantes e todos os assuntos
tratados devem ser apenas referentes ao sprint.

4.9 Sprint Review
Ao final do desenvolvimento do sprint ocorre este evento com todos os
comprometidos no sprint, onde posto mesa tudo aquilo que foi feito e o que no
21

foi feito dentro do desenvolvimento do produto final. tambm neste momento que o
product owner avalia se o produto ser entregue ou rejeitado de acordo com a
ausncia de metas atingidas, pois uma diretriz constante do SCRUM nunca
entregar um produto incompleto.
Mediante a apresentao, so postos a prova os objetivos que foram traados na
Sprint Planning Meeting versus os objetivos que foram alcanados. Aps a
apresentao preparada uma verso de demonstrao do produto final, ou
popularmente conhecido como demo, que por sua vez apresentada ao cliente
final.
Muitas empresas pecam neste ponto devido a tomar como aceitos muitos itens do
objetivo que no final esto parcialmente completos, entregando produtos com
problemas, bugs, ou ausncia de pontos solicitados pelo cliente. Em SCRUM,
prefervel que se entregue o produto menor e cem por cento funcional a um produto
maior e teoricamente incompleto, isto, muitas vezes chamado de Sndrome dos
90% pronto.

4.10 Sprint Retrospective
A ltima reunio do sprint atual, tambm muito importante. Neste encontro so
repassados todos os fatos que ocorreram durante a iterao e isto servir de medida
positiva ou negativa para o prximo sprint.
Este evento rene todos os membros comprometidos com o projeto, exceto o
product owner, embora a exceo no seja obrigatria, e discutido tudo aquilo que
correu bem e tudo o que pode ser usado para que a prxima iterao flua melhor.
Muitas empresas neste ponto costumam reunir as informaes desta reunio em um
relatrio de lies aprendidas, onde constar tudo que pode ser usado novamente e
tudo que causou impedimento durante o projeto para impedir a reincidncia.
Comumente utilizam-se as trs perguntas para todos os membros: O que devemos
comear a fazer? O que devemos parar de fazer? O que devemos continuar
fazendo?
Importante ressaltar que no apenas os pontos fsicos do desenvolvimento devem
ser levantados, mas tambm o fator humano. Deve ser feita uma avaliao a
respeito das atitudes e comprometimento dos envolvidos, visando melhora
constante na prxima iterao.

22

4.11 Task Board ou quadro de tarefas
O quadro de tarefas mais uma ferramenta visual para o gerenciamento da equipe
SCRUM, nele, so dispostos os cartes de estria, divididos com todas as
funcionalidades separadas para a iterao, em colunas que indicam o status de
cada tarefa.












No quadro, so dispostos, comumente na vertical, em cada linha um membro do
grupo de desenvolvimento, cada coluna representa um status, existem alguns
formatos, sendo mais utilizado o layout Para fazer, Fazendo, Finalizado.
Fisicamente, trata-se de um quadro com pequenas notas coladas ou pregadas, onde
cada bloco significa uma tarefa. O conceito de se utilizar blocos de notas para
identificar as tarefas justamente necessrio para que as tarefas sejam pequenas e
sucintas.
Normalmente usam-se as cores para diferenciar o tipo de tarefa que est sendo
disposta no quadro, a prioridade ou identificar um impedimento para o
desenvolvimento.
Esta ferramenta fornece tambm o grfico burndown, e em suma, uma poderosa
forma de gerenciamento visual e de planejamento de esforos. Atravs deste
quadro, possvel se visualizar com preciso a quantidade de tarefas que ainda
deve ser realizada para alcanar o objetivo do sprint, bem como quanto empenho
dever ser empregado para se atingir as metas do grfico. Deve ser atualizado
diariamente, normalmente durante a reunio diria.
Figura 07: Exemplo de Task Board
23

tambm uma ferramenta muito flexvel, dando espao para a criao de novas
colunas ou layouts diferentes, desde que se respeitem certas regras, como por
exemplo, no devem constar no quadro, colunas referentes a problemas ou
redundantes.


24

5 FERRAMENTAS PARA GESTO DE PROJETOS SCRUM
Existem dois grupos de pessoas, de um lado os que pregam que o Scrum deve ser
aplicado da forma mais simples possvel, utilizando cartes para as histrias, e,
quando necessrio, quadro branco e post-its para as tarefas, e, do outro lado, esto
os que so a favor do uso de uma ferramenta, pois alegam que a utilizao de
ferramentas sempre sero bem vindas visto que existem sites que ofeream
diversas ferramentas online.

5.1 Vantagens e facilidades de ferramentas online
Com a utilizao de uma ferramenta, existe a possibilidade de todos os participantes
do projeto proporem histrias e do PO aprovar histrias remotamente, evitando
assim que ideias sejam esquecidas por no terem sido registradas em tempo. Essa
facilidade aumenta a agilidade, a colaborao dentro da equipe e
a transparncia com relao ao que deve ser feito.
Outro ponto a facilidade de poder consultar tudo que j foi desenvolvido dentro do
projeto, pois com uma ferramenta, possvel realizar buscas por termos,
aumentando novamente a transparncia para a equipe do que foi realizado dentro
do projeto.
Ainda, com a utilizao de uma ferramenta, o andamento da sprint pode ser
consultado a qualquer hora e de qualquer lugar, ajudando o Scrum Master a detectar
os impedimentos o quanto antes e, novamente, aumentando a transparncia para a
equipe com relao ao que foi combinado antes da sprint.
Por fim, com uma ferramenta possvel ter armazenado todo o histrico do projeto,
concentrando todo o conhecimento do projeto em um mesmo lugar. Isso permite a
todos os membros do projeto:
- consultar histrias j implementadas,
- verificar o desempenho da equipe em sprints anteriores,
- analisar o contedo das reunies de retrospectiva e etc.
Com a facilidade de consultar os resultados passados das reunies de retrospectiva,
a adaptao ao Scrum melhorada, bem como a transparncia da equipe, com a
disponibilizao de todos os dados do projeto atuais e histricos.
Para projetos onde a equipe fica distribuda geograficamente, a adoo de uma
ferramenta faz-se necessria, entretanto, para um projeto onde todos da equipe
25

trabalham no mesmo lugar fsico, a adoo de uma ferramenta no obrigatria,
mas pode ser considerada como uma grande melhoria no seu processo Scrum.

5.2 Algumas ferramentas online

5.3 ScrumMe
um gerenciador de projetos que acaba de ganhar uma verso para Google
Chrome. Com este aplicativo, voc dispe de uma plataforma online para cadastrar
e gerenciar projetos, facilitando assim o controle sobre as atividades, a definio de
prazos e tambm a troca de informaes.
possvel cadastrar vrios membros no servio, marcar reunies, escrever uma
breve descrio sobre a pauta a ser discutida em cada encontro e muito mais. O
ScrumMe pode tanto servir para fins profissionais, quanto para fins acadmicos e
pessoais, sempre auxiliando a organizar tudo o que feito em um projeto.
Recursos:
Gerenciamento de projetos
Gerenciamento de sprints
Gerenciamento de fases
Gerenciamento de tarefas
Gerenciamento do time
Chat com o time
Estatsticas do projeto
Grfico de queima
Alertas









26
















5.4 PangoScrum
Entregue mais software, sempre. De uma maneira simples e sem interferir no seu
Scrum, melhore continuamente sua eficincia nas entregas. Obtenha feedback para
tomar as decises corretas, acessando facilmente as informaes relevantes e
atualizadas em tempo real.








Figura 08: Pgina do gerenciamento do projeto - SrumMe
Figura 09: (Reproduo/PangoScrum)
27

Gerencie seu Product Backlog. Como voc gerencia o backlog de seus produtos?
Com PangoScrum voc escrever, estimar e priorizar seu product backlog atravs
de uma interface simples e amigvel.








Planeje sprints com maior rapidez. PangoScrum far voc trabalhar mais rpido.
Objetivamente e sem burocracia, seus Sprints sero planejados com maior
agilidade.








Figura 10: (Reproduo/PangoScrum)
Figura 11: (Reproduo/PangoScrum)
28

Agende eventos com facilidade. Suas equipes esto alinhadas com um calendrio?
No PangoScrum as datas de suas reunies de planning, review e retrospectiva
estaro agendadas em um calendrio com fcil visualizao e acesso.









E o cadastro simples e rpido!

Figura 12: (Reproduo/PangoScrum)
Figura 13: Pgina inicial do Web site
29

5.5 ScrumHalf
uma ferramenta web para apoio a projetos geis, baseado no framework Scrum.
Possui diversas facilidades para auxlio ao cliente e equipe de projeto. No
demanda nenhuma instalao em seu computador.

Aps uma prvia analise de apenas estes trs sites, consciente da existncia de
inmeros do gnero na internet, percebe-se que a maioria preza por auxiliar na
utilizao da metodologia Scrum por meio de uma facilidade de uso e administrao
do projeto, integrando as equipes de forma a resultar em um melhor
desenvolvimento do sistema.
As formas de utilizao so geralmente gratuitas por certo perodo ou para sempre,
porm tem a possibilidade de adquirir planos com custos acessveis que ofeream
mais recursos para o desenvolvimento.
Agora fica ao critrio da equipe utilizar os recursos do quadro com anotaes ou os
recursos diversos das ferramentas online.


Figura 14: Pgina inicial ScrumHalf
30

6 COMO SCRUM E KANBAN SE RELACIONAM?
Scrum e Kanban so ambos ferramentas de processo!
Ferramenta = qualquer coisa utilizada com a finalidade de realizar uma tarefa ou
atingir um objetivo.
Processo = como voc trabalha.

Scrum e Kanban so ferramentas de processo que, em certa medida, te ajudam a
trabalhar de maneira mais eficaz, dizendo a voc o que fazer. Java tambm uma
ferramenta, ela lhe fornece uma maneira mais simples de programar. A escova de
dente tambm uma ferramenta, que ajuda voc a alcanar seus dentes para que
voc possa limp-los.
Compare ferramentas para compreenso, No julgamento!
Nenhuma ferramenta completa, nenhuma ferramenta perfeita!
Como quaisquer ferramentas, Scrum e Kanban no so perfeitos nem tampouco
completos. Eles no lhe dizem tudo o que voc precisa fazer, eles apenas lhes
oferecem algumas restries e orientaes. Por exemplo, Scrum lhe restringe a ter
iteraes de tempo fixo e equipes multifuncionais, enquanto que Kanban lhe
restringe a utilizar quadros visveis e limitar o tamanho de suas linhas de produo.
O interessante aqui que o valor de uma ferramenta que ela limita suas opes.
Uma ferramenta-processo que lhe permite fazer tudo no l muito til. Ns
poderamos chamar este processo Faa Qualquer Coisa ou que tal Faa a Coisa
Certa. O processo Faa a Coisa Certa certamente funciona, uma bala de prata!
Afinal, se ele no funcionar, bvio que voc no est seguindo o processo.
Um projeto pode ter sucesso por utilizar uma boa ferramenta;
Um projeto pode ter sucesso apesar de uma pssima ferramenta;
Um projeto pode falhar por causa de uma pssima ferramenta;
Um projeto pode falhar apesar de utilizar uma boa ferramenta.

6.1 O Scrum mais prescritivo que o Kanban!
Podemos comparar ferramentas analisando quantas regras elas oferecem.
Prescritivo significa mais regras a seguir e adaptativo significa menos regras a
seguir. Prescritivo 100% significa que voc no precisa usar seu crebro, j h
regra para tudo. Adaptativo 100% significa faa qualquer coisa, no existe nenhum
31

tipo de regras ou restries. Como podemos ver os dois extremos da escala
acabam se tornando ridculos.
Mtodos geis so s vezes chamados de mtodos leves (lightweight),
especificamente porque eles so menos prescritivos que os mtodos tradicionais.
De fato, o primeiro princpio do Manifesto gil Indivduos e Interaes sobre
Processos e Ferramentas. Scrum e Kanban so ambos altamente adaptativos, mas
falando relativamente, Scrum mais prescritivo que Kanban. Scrum lhe d mais
restries, por conta disso, deixa menos opes abertas. Por exemplo, o Scrum
prescreve o uso de iteraes de durao fixa, o Kanban no.
Scrum prescreve 3 papis: Product Owner (cria a viso do produto e
prioridades), Equipe (implementa o produto) e ScrumMaster (remove
impedimentos e fornece liderana de processo). Kanban no prescreve papel
nenhum.
Isso no significa que voc no possa ou no deva ter o papel de um Product Owner
em Kanban! Significa apenas que voc no precisa. Tanto em Scrum quanto em
Kanban, voc livre para incluir quaisquer papis adicionais que precisar. O
raciocnio comum tanto em Scrum quanto em Kanban menos mais. Ento, na
dvida, comece com menos.

6.2 Scrum prescreve iteraes em time-box
Scrum baseado em iteraes de tempo fixo. Voc pode escolher a durao da
iterao, mas a idia geral manter a mesma durao de iterao por um perodo
de tempo, desta forma estabelecendo uma cadncia.
Incio da iterao: Um plano de iterao criado, isto , a equipe puxa um
nmero especfico de itens do product backlog, baseado nas prioridades do
Product Owner e no quanto a equipe acha que pode completar em uma
iterao.
Durante a iterao: A equipe concentra-se em entregar os itens com que se
comprometeu. O escopo da iterao fixado.
Fim da iterao: A equipe demonstra o cdigo de trabalho para as partes
interessadas relevantes. Este cdigo, idealmente, deveria ser potencialmente
entregvel (isto , testado e pronto para funcionar). Em seguida, a equipe faz
uma retrospectiva para discutir e melhorar seu processo. Ento o Scrum
32

uma nica cadncia de tempo fixo que combina trs diferentes atividades:
planejamento, melhoria de processo e (idealmente) release.
No Kanban, iteraes de durao fixa no so prescritas. Voc pode escolher
quando planejar, melhorar processo e entregar. Pode escolher fazer essas
atividades numa periodicidade regular (release toda segunda), ou por demanda
(release sempre que tivermos algo til a entregar).

6.3 Kanban limita WIP por estado de fluxo de trabalho, Scrum por iterao.
Em Scrum, o sprint backlog mostra quais so as tarefas a serem executadas durante
a iterao corrente (= sprint na linguagem Scrum). Geralmente ele representado
usando cartes na parede, conhecido tambm por quadro do Scrum ou quadro de
tarefas.
Ento qual a diferena entre o quadro de Scrum e o quadro de Kanban?


Vamos comear com um projeto trivialmente simples e compar-los:
H diferena entre esses dois exemplos de quadros?
Sim o pequeno 2 na coluna do meio no quadro Kanban. E isto tudo. Este 2
significa no pode haver mais de 2 itens nesta coluna ao mesmo tempo. Em Scrum
no h nenhuma regra advertindo a equipe para no colocar todas as atividades na
coluna Em execuo ao mesmo tempo! Porm, h um limite implcito, j que a
interao, por si s, tem um escopo fixo. Neste caso, o limite implcito por coluna 4,
j que h apenas 4 itens em todo o quadro. Ento, Scrum limita as atividades em
andamento indiretamente, enquanto Kanban as limita diretamente. A maioria das
equipes Scrum aprende na prtica que no uma boa idia ter muitas atividades na
coluna em execuo, e criam uma cultura de tentar finalizar as atividades atuais
Figura 15: Quadros comparativos entre Scrum e Kanban
33

antes de comear outras. Alguns at decidem claramente limitar os nmeros de
atividades permitidas na coluna em execuo e ento tchammm! o quadro Scrum
se transforma em um quadro Kanban! Ento, tanto Scrum quanto Kanban limitam as
atividades em andamento, mas de formas diferentes. Equipes Scrum geralmente
medem a velocidade quantos itens (ou unidades de medidas correspondentes
como pontos da estria) sero feitos por iterao. Uma vez que a equipe sabe sua
velocidade, ela torna-se seu limite de atividades em andamento. Uma equipe que
tem velocidade mdia de 10, geralmente, no ir colocar mais de 10 itens (ou
pontos da estria) em uma iterao. Desta forma, em Scrum as atividades em
andamento so limitadas por unidade de tempo. Em Kanban as atividades em
andamento so limitadas pelo fluxo de trabalho. Ambos Scrum e Kanban so
baseados no desenvolvimento incremental, isto , quebrar o trabalho em pedaos
menores. Uma equipe Scrum ir comprometer-se apenas aos itens que julguem
poder terminar dentro de uma iterao (baseado no conceito de Done). Caso um
item seja grande demais para caber em um sprint, a equipe e o Product Owner tero
que encontrar formas de quebr-lo em pedaos menores at que ele se encaixe. Se
os itens tendem a ser grandes, as iteraes sero maiores (embora geralmente no
maiores do que 4 semanas).


Equipes Kanban tentam minimizar o tempo de execuo e equilibra o fluxo, de modo
que indiretamente criam um incentivo para quebrar itens em pedaos relativamente
menores. Porm no h nenhuma regra explcita indicando que os itens devam ser
suficientemente pequenos para caber em um determinado perodo de tempo. Em um
mesmo quadro ns podemos ter um item que ir levar 1 ms para ser concludo e
outro item que levar 1 dia.
Figura 16: Tabela de sprints de Scrum
34


6.4 Scrum prescreve estimativas e velocidade
No Scrum, equipes devem estimar o tamanho (quantidade de trabalho) de cada
item aos quais eles se comprometeram. Somando o tamanho de cada item
concludo ao final de cada sprint, ns teremos a velocidade. A velocidade uma
medida da capacidade a quantidade de coisas que ns podemos entregar por
sprint. Aqui temos um exemplo de uma equipe caso esta tenha uma velocidade
mdia igual a 8.


Saber que a velocidade mdia 8 bom porque nos permite fazer previses mais
realistas sobre quais itens podemos entregar nos futuros sprints, e portanto,
fazer planos de entrega cada vez mais prximos da realidade. J no Kanban,
estimativa no obrigatrio. Portanto, se voc precisar ter comprometimentos voc
precisar decidir como fornecer previses. Algumas equipes optam por fazer
estimativas e medir a velocidade assim como no Scrum. Outras equipes escolhem
pular as estimativas, mas tentam quebrar cada item em itens menores de
aproximadamente do mesmo tamanho desta forma eles podem medir a velocidade
simplesmente em termos de quantos itens foram concludos por unidade de tempo
(por exemplo, requisitos ou funcionalidades por semana). Algumas equipes agrupam
itens em nveis mnimos de funcionalidades (do ingls MMFs (minimum marketable
Figura 17: Tabela de sprints em execuo
Figura 18: Tabela de velocidade mdia
35

features) e medem a mdia de tempo de execuo por MMF, e usam esta medio
para estabelecer o ANS (Acordos de Nvel de Servio) por exemplo, quando ns
nos comprometemos a um MMF, este ser sempre entregue no prazo de 15 dias.
Existem inmeras tcnicas interessantes para o modelo Kanban de planejamento de
entregas e gerenciamento de compromissos porm no h tcnica especfica ou
mandatria a ser seguida ento v em frente e pesquise novas formas e tcnicas at
encontrar a que se encaixe melhor ao seu contexto. Provavelmente veremos
algumas boas prticas surgir ao longo do tempo.

6.5 Ambos permitem trabalhar em mltiplos produtos simultaneamente
No Scrum, Product Backlog um nome muito infeliz, pois implica que todos os
itens devem ser do mesmo produto. Aqui temos dois produtos, verde e amarelo,
cada um com seu prprio product backlog e sua prpria equipe:










Mas, e se voc s tem uma equipe? Bem, pense no product backlog mais como um
backlog da equipe. Ele lista as prioridades das iteraes programadas para uma
equipe em particular (ou um grupo de equipes). Ento, se essa equipe est
mantendo mltiplos produtos, basta juntar os produtos em uma nica lista. Isso nos
fora a priorizar os produtos, o que til em alguns casos. Existem muitas maneiras
de fazer isso na prtica:
Uma estratgia seria ter a equipe focada em um produto por sprint:



Figura 19: Product backlog, separado por cor e equipe
Figura 20: Produto por Sprint
36

Outra estratgia seria ter a equipe trabalhando em caractersticas dos dois produtos
em cada sprint:








a mesma coisa no Kanban. Podemos ter diversos produtos fluindo atravs do
mesmo quadro branco. Podemos distingui-los utilizando diferentes cartes coloridos:






...ou por raias:








6.6 Resumo de Scrum vs. Kanban
6.7 Similaridades:
Ambos so Lean e Agile.
Ambos usam controle de cronograma.
Ambos limitam atividades em andamento.
Ambos usam transparncia para direcionar a melhoria do processo.
Figura 21: Produtos em simultneo
Figura 22: Produtos distribudos em Kanban
Figura 23: Produtos distribudos em Kanban
37

Ambos concentram-se na entrega de software que funcione, o mais rpido
possvel.
Ambos so baseados em equipes auto-organizveis.
Ambos exigem que o trabalho seja dividido em partes.
Em ambos, o planejamento de release continuamente otimizado, baseado em
dados (velocidade / tempo de execuo) empricos.
Scrum Kanbam
Iteraes Timeboxed
prescritas.
Iteraes Timeboxed opcionais. Pode ter cadncia
separada para o planejamento, release e melhoria
de processos. Pode ser orientada para eventos, em
vez de Timeboxed.
Equipe compromete-se a uma
quantidade especfica de
trabalho para esta iterao.
Compromisso opcional.
Usa a velocidade como padro
mtrico para o planejamento e
melhoria de processos.
Usa o Lead time como padro mtrico para o
planejamento e melhoria de processos.
Equipes multifuncionais
prescritas.
Equipes multifuncionais opcionais.
Equipes de Especialistas autorizadas.
Os itens devem ser divididos
para que possam ser
concludos dentro de 1 sprint.
Nenhum tamanho especial de item prescrito.
Grfico Burndown. Nenhum tipo especfico de diagrama prescrito.
WIP limitado indiretamente
(por sprint).
WIP limitado diretamente (por situao do fluxo de
trabalho).
Estimativa prescrita. Estimativa opcional.
No poder adicionar itens
iterao em uso.
Pode adicionar novos itens sempre que houver
capacidade disponvel.
O Sprint backlog de uma
equipe especifica
Quadros kanban podem ser compartilhados por
vrias equipes ou individualmente.
Possui 3 papis (Product
Owner/Scrum Master/Team).
No discrimina nenhum papel.
Um quadro Scrum reiniciado
entre cada sprint
Um quadro kanban continua.
Prescreve um product backlog
priorizado.
Priorizao opcional.



38

7 PROCESSO DE CERTIFICAO SCRUM
O processo de certificao em Scrum um pouco diferente das certificaes que
vemos no mercado atualmente. Para esclarecer um pouco melhor este processo,
abaixo uma interpretao do processo de certificao. A descrio oficial est aqui.







No primeiro nvel de certificao, que seriam os treinamentos de Certified
Scrum Master e Certified Scrum Product Owner, a pessoa apenas recebe o
treinamento de um Trainer aprovado pela Scrum Aliance. Este treinamento atesta
que o participante possui conhecimento e capaz de aplicar o Scrum, mas no
comprova experincia ou habilidade.
No segundo nvel de certificao, a pessoa precisa responder a uma srie de
questionamentos sobre a utilizao de Scrum em um projeto em que participou.
Estes questionamentos so avaliados por uma comisso da Scrum Aliance, que
pode fazer novos questionamentos para esclarecer algo que no esteja claro. Esta
comisso verifica se no projeto avaliado os conceitos de Scrum foram seguidos
corretamente, conferindo (ou no) o ttulo de Certified Scrum Practitioner. Nesse
nvel, a certificao tambm atesta experincia e habilidade com a implantao e
utilizao de scrum.
No terceiro nvel da certificao, a pessoa passa a ter um tutor, que vai trein-la para
a realizao de treinamentos de novos Certified Scrum Masters e Certified Scrum
Product Owners, ou ento atuar como coach de Scrum em organizaes. A
impresso que tenho, que este nvel da certificao algo parecido com um
"treinamento Jedi", mestre e aprendiz. Quando o tutor decidir, o candidato passa por
uma avaliao, onde uma comisso pode aprov-lo como Certified Scrum Trainer ou
Certified Scrum Coach. Nesse nvel, a certificao atesta que a pessoa capaz de
transmitir conhecimento para outras pessoas que estejam interessadas em aprender
Scrum.
Concordo quando pessoas da comunidade gil dizem que os nomes devam ser
Figura 24: Interpretao da Certificao
39

diferentes, pois no demonstram fielmente o objetivo de cada nvel de certificao.
De qualquer forma gostei muito do processo de certificao, acho muito mais
honesto que muitas das certificaes "decore o livro, responda o questionrio de
Xzinho e voc ser um super especialista no assunto", que vemos por ai. Talvez os
nomes pudessem ser diferentes, para deixar mais claro o significado de cada nvel,
mas isso outra histria.


Notcia de ltima hora: Segundo o site da Scrum Aliance, h um novo
sistema de avaliao em fase de aprovao, onde as certificaes para CSM's e
CSPOs sero realizadas atravs de uma prova e no mais pelo feeling dos trainers.
At onde entendi, a cada 2 anos a pessoa precisaria fazer uma nova prova
comprovando que est atualizando seus conhecimentos e renovar a certificao. Os
detalhes sero finalizados na Scrum Gathering Orlando, em breve teremos
novidades.

7.1 Certified Scrum Master







O treinamento de Certified Scrum Master um treinamento de imerso em
Scrum, com a durao de 16 horas, e ministrado por um Trainer certificado pela
Scrum Aliance. Este treinamento certifica apenas que o participante possui
conhecimento em Scrum, e que est apto a trabalhar em implantaes de Scrum em
qualquer organizao. Por outro lado este treinamento no certifica que o
participante tenha experincia com Scrum ou qualquer tipo de habilidade necessria
para a sua implantao. Por outro lado, por experincia prpria, tenho certeza
absoluta que qualquer Certified Scrum Master tem um conhecimento muito maior do
que qualquer pessoa que tenha tentado aplicar Scrum por conta prpria, apenas
pesquisando e estudando.
Figura 25: Logotipo da Aliana
Scrum
40

Trata-se de um treinamento extremamente dinmico e com muito contedo e prtica
tambm. Durante o treinamento h muitas dinmicas e debates que mostram
claramente vrios dos conceitos e prticas propostos pelo Scrum.
Por causa disso tudo, no h nenhuma prova durante o processo, mas isso no
significa que esta certificao seja uma enganao, muito pelo contrrio, o
treinamento absurdamente bom. Caso algum pense que s ir para o
treinamento e dormir o dia todo para ser certificado, fique sabendo que o instrutor
tem toda a autoridade de no certificar o participante se em algum momento
perceber que este no absorveu o contedo necessrio a um Certified Scrum
Master.
Todo o processo de certificao da Scrum Aliance bem diferente do que estamos
acostumados a ver, mas entendendo melhor o processo de certificao, fica fcil
perceber que um sistema bem mais honesto que a maioria das certificaes que
vemos por ai.



7.2 Quem ganha mais ao usar Scrum?













"O mais legal do SCRUM a parte para trabalhar com a equipe."

Figura 26: Ilustrao da escolha (exemplo)
41

claro que SCRUM ajuda muito as pessoas a trabalharem juntas, mas est
muito longe de ser apenas isso.
Em minha opinio SCRUM sobre aumentar a eficcia de projetos, e
consequentemente de negcios. Melhorar e facilitar o processo de trabalho das
equipes apenas um dos meios atravs do qual se atinge este objetivo.
Antes da explicao em si, permita-me diferenciar Eficcia de Eficincia.
Eficcia fazer a coisa certa; j Eficincia conseguir o melhor custo x benefcio
para se fazer algo. Portanto, no SCRUM sempre procuramos fazer A COISA
CERTA, tenha isso sempre em mente.
Quando se inicia um projeto usando SCRUM, as primeiras tarefas do Product
Owner so definir a Viso do Projeto e fazer um Backlog Inicial priorizado pelo ROI
que cada item pode proporcionar ao Projeto. J o Time, segue a premissa que
sempre deve ser entregue um incremento do produto com qualidade ao fim do
Sprint, e isso vale desde o primeiro Sprint. J o Scrum Master, tem como principais
funes remover impedimentos da equipe, mitigar os riscos do projeto e facilitar a
comunicao entre os envolvidos.
Em outras palavras, o Product Owner dever garantir que sejam trabalhados
os itens que provavelmente traro maior retorno ao Projeto seguindo uma idia
original. O Time sempre deve entregar algo que o cliente veja e entenda que possui
algum valor e no somente documentaes ou frameworks que sero usados como
base para o desenvolvimento. J o Scrum Master, usando uma metfora, deve
manter as engrenagens lubrificadas, para que tudo funcione bem. Trabalhando
desta forma, o cliente logo vislumbrar o produto e poder dar feedbacks rpidos
para que a rota do projeto seja corrigida, ou mesmo que o projeto seja cancelado,
quando e se necessrio.
Todas estas premissas existem apenas para que o projeto seja executado da
forma mais eficaz possvel. Perceba, que at aqui, em nenhum momento falei sobre
equipe. A idia sempre trabalhar no que pode trazer um melhor retorno para o
projeto e se alguma deciso no foi boa o suficiente, importante descobrir o mais
rpido possvel e no apenas no fim do projeto, quando tudo j estar perdido.
Claro que o SCRUM tambm facilita o trabalho com equipes, mas repito, este
apenas um meio para atingir ao objetivo. Espero ter deixado isso um pouco mais
claro, pois muitas vezes vejo as pessoas na contramo deste pensamento.

42

8 CONCLUSO
O Scrum mostrou ser uma ferramenta de muita utilidade para o bom
desenvolvimento de projetos, no permitindo falhas que possam causar custos e
atrasos ao final do projeto e unindo equipes, embora existam diversas ferramentas
no mercado com a mesma disponibilidade, Scrum consegue destacar o seu bom
funcionamento perante as demais e ser a ferramenta mais conhecida entre
empresas e desenvolvedores de software.

43

9 GLOSSRIO
Cross-functional: funo de passagem para alteraes no desenvolvimento do
projeto;
Frameworks: nome utilizado para identificao de uma ferramenta (como o Scrum);
Grfico Burndown: grfico esquemtico para avaliao da execuo do tempo de
processo;
Mtodos geis: conjunto de metodologias de desenvolvimento de software;
Minimum Marketable Feature: a mnima utilizao de recursos;
Planning Poker: estilo de organizao em cartas numeradas onde o especialista diz
em que nvel se encontra;
Post-its: bilhetes autocolantes, utilizados no quadro de estrias;
Product backlog: uma lista de itens priorizados a serem desenvolvidos para um
software;
Product Owner: uma lista de requisitos que tipicamente vm do cliente;
Release: liberao do produto;
Scrum Alliance: Aliana Scrum para certificao de pessoal capacitado;
Scrum Master: mantm os processos (normalmente no lugar de um gerente de
projeto);
Stakeholders: so os mais interessados no final do software;
Task Board: tela de tarefas (tela onde se cola os bilhetes);
Time-box: caixa do tempo (o quadro de estrias).

44

10 REFERNCIAS
http://pt.wikipedia.org/wiki/Leonardo_de_Pisa - (acesso em 09/04/2012)
http://scrummethodology.com/scrum-effort-estimation-and-story-points/ - (acesso em
09/04/2012)
http://www.dicas-l.com.br/brod/brod_20080728.php#.T4Rm1Znt-3h - (acesso em
09/04/2012)
http://www.scrumdesk.com/Articles/EffortVsSize.html - (acesso em 09/04/2012)
http://www.abuzitos.com.br/SCRUM_BlogDoAbu_ApostilaDeApoio_v2_1.pdf -
(acesso em 09/04/2012)
http://pt.wikipedia.org/wiki/Scrum#Reuni.C3.B5es - (acesso em 09/04/2012)
http://martinfowler.com/articles/itsNotJustStandingUp.html#WeStandUpToKeepTheM
eetingShort - (acesso em 09/04/2012)
http://improveit.com.br/scrum/sprint_planning_meeting - (Acesso em 11/04/2012)
http://epf.eclipse.org/wikis/scrumpt/Scrum/tasks/sprint_retrospective_262A428.html -
(Acesso em 11/04/2012)
http://pt.scribd.com/doc/29066623/SCRUM-Product-Owner-v3 - (Acesso em
11/04/2012)
http://www.blogcmmi.com.br/o-que-e/o-que-e-smart - (Acesso em 11/04/2012)
http://pt.wikipedia.org/wiki/Hirotaka_Takeuchi - (Acesso em 11/04/2012)
http://pt.wikipedia.org/wiki/Ikujiro_Nonaka - (Acesso em 11/04/2012)
http://pt.wikipedia.org/wiki/Scrum - (Acesso em 11/04/2012)
http://www.gestaoetc.com.br/150/empresas-que-utilizam-scrum/ - (Acesso em
11/04/2012)
http://blog.scrumhalf.com.br/2011/08/desenvolver-projetos-scrum-com-ferramentas-
e-um-bom-negocio/ - (Acesso em 11/04/2012)
https://chrome.google.com/webstore/detail/hpojfhmgahfgnpambeihjahmkdlgidel?hl=p
t-BR - (Acesso em 14/04/2012)
http://www.baixaki.com.br/download/scrumme.htm#ixzz1vS7eYtMu - (Acesso em
14/04/2012)
http://rafaelmahler.com/2009/09/pangoscrum/ - (Acesso em 14/04/2012)
http://pangoscrum.com/ - (Acesso em 14/04/2012)
https://www.scrumhalf.com.br/login.jsf - (Acesso em 14/04/2012)
45

http://www.infoq.com/resource/minibooks/kanban-scrum-
minibook/pt/pdf/KanbanEScrumInfoQBrasil.pdf - (Acesso em 15/04/2012)
http://milton-roman.blogspot.com.br/search/label/Scrum - (Acesso em 15/04/2012)
http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software - (Acesso em
15/04/2012)
http://pt.wikipedia.org/wiki/Scrum - (Acesso em 15/04/2012)
http://blogdoabu.blogspot.com.br/ - (Acesso em 15/04/2012)
http://blog.tucaz.net/2008/11/22/slides-apresentacao-encontros-e-desencontros-na-
adocao-de-scrum/ - (Acesso em 15/04/2012)