ANAIS DO CONGRESSO DE INICIAO CIENTFICA DO INATEL - INCITEL 2012

79

Proposta de processo baseado em Scrum e Kanban

para uma empresa de telecomunicaes
Lus Augusto Cndido Garcia

Afonso Celso Soares

Centro de Ensino Superior em Gesto, Tecnologia

e Educao FAI
garcialac@yahoo.com.br

Centro de Ensino Superior em Gesto, Tecnologia

e Educao FAI
acs@fai-mg.br

ResumoEm ambientes de desenvolvimento com poucos

recursos sempre um grande desafio implantar um processo
devido as suas peculiaridades. Muitos processos de renome so
baseados em grandes organizaes o que torna ainda mais difcil
sua implantao nestes ambientes. Modelos e ferramentas de
processos como Scrum e Kanban surgem como alternativas
viveis a estes ambientes, por serem flexveis o suficiente para se
a adaptarem a eles. Neste artigo ser apresentada uma proposta
de processo baseado em Scrum e Kanban adaptados para uma
empresa de telecomunicaes.
Palavras chavekanbam, metodologias agis, processos, scrum,
telecomunicao.

atender s necessidades destes cenrios complexos e

dinmicos. Porm, boa parte deles no conseguem resultados
satisfatrios por supor que estes cenrios podem ser
totalmente definidos, estimados e medidos [8].

AbstractIn development environments with limited resources

is always a challenge to deploy a process due to its peculiarities.
Many well-known processes are based in large organizations
which makes its implementation more difficult in these
environments. Models and tools for processes such as Scrum and
Kanban emerge as viable alternatives to these environments
because they are flexible enough to adapt to them. In this article
we shall propose a process based on Scrum and Kanban adapted
for a telecommunications company.
Keywordsagile, kanbam, processes, scrum, telecommunication.

II. SCRUM

I. INTRODUO
Projetos atrasados, mudana de escopo e insatisfao por parte
dos clientes, estes so problemas comuns vividos nas
empresas de desenvolvimento de software. Boa parte destes
problemas se deve a falta de um processo definido para o
desenvolvimento ou a impraticabilidade de um determinado
processo.
Falta de recursos, acmulo de papis, fluxo no constante de
projetos e manuteno de produtos existentes so problemas
comuns vividos por muitas pequenas e mdias empresas de
desenvolvimento o que torna o dia a dia da gerncia de
projetos ainda mais difcil.

Ao longo deste artigo sero abordados o modelo e a

ferramenta de processo Scrum e Kanban; suas principais
prticas e a maneira com que eles gerenciam o
desenvolvimento de software. Ser proposto um modelo de
processo baseado nessa combinao para ambientes com
poucos recursos e diversos projetos, incluindo manuteno.

Scrum um modelo de processo gil de desenvolvimento de

software [5] constitudo por um conjunto de prticas e regras
utilizadas para gerenciar e controlar todo o desenvolvimento.
O processo se d de forma emprica tendo por base trs
pilares: transparncia, inspeo e adaptao. Isso faz com que
todos os envolvidos no processo conheam seus aspectos e
faam as adaptaes necessrias para atingir seus objetivos.
O Scrum utiliza em sua estrutura conceitos do modelo espiral,
onde cada ciclo da espiral de desenvolvimento seria
equivalente ao que no Scrum conhecido como Sprint
(Iterao) [6]. No incio de cada Sprint, o time seleciona as
tarefas que ele acredita terminar durante a Sprint. Aps esta
etapa, o time se concentra no trabalho, decidindo qual ser a
melhor maneira para se realizar todas estas tarefas. Durante a
Sprint so feitos acompanhamentos constantes para identificar
possveis problemas que possam impedir a realizao do
trabalho. No final da Sprint entregue um incremento do
trabalho para anlise dos responsveis.
A arquitetura Scrum composta por trs papis, cinco regras e
trs artefatos.
1.

Diversos modelos, processos e metodologias se propem a

L. A. C. Garcia (garcialac@yahoo.com.br) e A. C. Soares (acs@fai-mg.br)
pertencem ao Centro de Ensino Superior em Gesto, Tecnologia e Educao
FAI. Av. Antnio de Cssia, 472 Santa Rita do Sapuca MG Brasil
37540-000

Os trs papis so: Product Owner1 (Proprietrio do

produto), ScrumMaster [sic] e o time. Aqui no h
referncia direta com os papis convencionais como

Optou-se pela utilizao dos termos em ingls por serem amplamente

utilizados na literatura.

ANAIS DO CONGRESSO DE INICIAO CIENTFICA DO INATEL - INCITEL 2012

80

por exemplo Gerente de Projeto ou Arquiteto de

Projeto, estes esto diludos nos papis citados,
cada um com sua funo especfica.
2.

3.

As cinco regras so: Sprint Planning Meeting

(Reunio de Planejamento da Iterao), Daily Scrum
Meeting (Reunio Diria do Scrum), Sprint, Sprint
Review Meeting (Reunio de Reviso da Iterao) e
Sprint Retrospective Meeting (Reunio de
Retrospectiva da Iterao). Nessas regras est o
corao do Scrum, onde feito todo o controle e
adaptao necessrios para alcanar o sucesso na
realizao do trabalho.
Os trs artefatos so: Product Backlog (Lista de
funcionalidades do produto), Sprint Backlog (Lista de
funcionalidades para a iterao) e Burndown Chart
(Grfico de acompanhamento). Estes artefatos so
utilizados para priorizar e acompanhar o trabalho.

A. Os papis

corao. Atravs das reunies os envolvidos no processo

conseguem identificar os bloqueios e os riscos do projeto e
realizar adaptaes para um trabalho mais rpido e mais
organizado.
No incio de cada Sprint, durante a Sprint Planning Meeting, o
Product Owner de posse do Product Backlog, prioriza cada
item para que sirva de referncia para o time trabalhar no
desenvolvimento do produto. Em seguida, com base em
prioridades, o time seleciona as funcionalidades que ele
acredita ser capaz de realizar durante uma Sprint, formando
assim o Sprint Backlog.
Aps a Sprint Planning Meeting o time se concentra na Sprint.
O perodo de uma Sprint varia entre 2 a 4 semanas, onde o
time reserva para trabalhar nas funcionalidades da Sprint
Backlog. Aps definido o tamanho da Sprint, o time pode
alterar a quantidade de funcionalidades contidas na Sprint
Backlog, sendo que a data final da Sprint deve continuar a
mesma [6].

No Scrum exitem apenas trs papis para gerncia e execuo

de todo o processo, ao contrrio dos processos tradicionais
onde existe toda uma hierarquia e definio detalhada de cada
papel.

Para acompanhamento e gerncia da Sprint so realizadas as

Daily Scrum Meetings, que so as reunies dirias. Atravs
dessas reunies possvel identificar possveis riscos e
impedimentos do projeto. Essas reunies so rpidas, durando
aproximadamente 15 minutos.

O Scrum exige que exista uma pessoa que tenha uma viso de
negcio do produto e que esteja focado no retorno do
investimento [7]. Essa pessoa o Product Owner. Ele o
responsvel por direcionar o trabalho do time a cada Sprint e
por manter os interesses da empresa.

No final da Sprint realizada a Sprint Review Meeting. Nessa

reunio, o time apresenta ao Product Owner e outros
interessados o resultado do trabalho. Nesse ponto, o produto
deve estar funcional, ele j passou por todas as etapas do
desenvolvimento: projeto, implementao e testes.

O time por sua vez o responsvel por desenvolver e

gerenciar o desenvolvimento do produto. No Scrum o time
composto por volta de 5 a 10 integrantes auto organizados,
decidindo pela melhor forma de realizar o trabalho durante a
Sprint.

Aps a Sprint Review Meeting, realizado a Sprint

Retrospective Meeting. O objetivo dessa reunio reunir
ideias para melhorar o processo. Segundo Kniberg [3] essa
pode ser considerada depois da Sprint Planning Meeting o
evento mais importante pois, a hora de rever todo o processo
e adapt-lo para que a prxima Sprint seja ainda melhor.

E por ltimo para facilitar a comunicao entre o Product

Owner e o time e garantir que as prticas do Scrum sejam
seguidas existe a figura do ScrumMaster. O papel do
ScrumMaster a de um facilitador do processo, sendo sua
responsabilidade remover todo bloqueio encontrado durante o
trabalho e gerenciar as regras do Scrum.
B. Os artefatos
Os artefatos so ferramentas do Scrum que permitem
organizar e acompanhar o trabalho de forma simples e direta.
O Product Backlog uma lista com as funcionalidades
desejveis do produto, sendo gerenciada pelo Product Owner.
O Product Owner prioriza os itens dessa lista de acordo com o
valor de negcio de cada item. Em seguida, o time monta a
Sprint Backlog que conter os itens mais prioritrios do
Product Backlog a serem desenvolvidos durante a Sprint.
Durante a Sprint o acompanhamento ser feito pelo Burndown
Chart, que um grfico mostrando o andamento do Sprint,
devendo ser atualizado durante as Daily Scrum Meetings.
C. As regras
O Scrum tem nas suas regras a chave do seu sucesso, o seu

III. KANBAN
Kanban uma ferramenta de processo [4] criada como parte
do Sistema de Produo Toyota (TPS Toyota Production
System) [1]. Seu principal objetivo minimizar o trabalho em
andamento, evitando assim os gargalos em determinadas fases
do processo e os desperdcios da superproduo [1].
Para esse controle o Kanban utiliza 3 regras bsicas: visualizar
o fluxo de trabalho; minimizar o trabalho em andamento e
calcular o tempo mdio para concluso de uma tarefa [4].
Para visualizar o fluxo do trabalho, o Kanban utiliza um
quadro onde so feitas divises que correspondem as etapas do
fluxo do trabalho. Nesse quadro so fixados cartes que
correspondem as tarefas a serem executadas. Parte da tarefa
executada em cada etapa do fluxo e aps a sua concluso o
carto movido para a prxima etapa. Ao passar pela ltima
etapa do fluxo, a tarefa dever estar concluda.
Para evitar os desperdcios com a superproduo e os gargalos
no processo, o Kanban limita o nmero de tarefas em cada
etapa do fluxo. Ao terminar a execuo de uma tarefa em uma
determinada etapa, ela s pode ser encaminhada para a

ANAIS DO CONGRESSO DE INICIAO CIENTFICA DO INATEL - INCITEL 2012

prxima se esta ainda no atingiu seu limite, garantindo-se

assim um fluxo constante de tarefas em execuo [1].
Aps determinar o limite de cada etapa do fluxo, possvel
medir o tempo mdio de concluso de uma tarefa. Isso de
fundamental importncia na negociao de prazos. O ideal
que este tempo mdio seja o menor e mais previsvel possvel,
ajudando a definir prazos mais realistas [4].
IV. PROCESSO PROPOSTO
A empresa, alvo do estudo, pertence ao ramo de
telecomunicaes onde o trabalho do desenvolvimento
composto por desenvolvimento de hardware, software
embarcado e software aplicativo. A equipe 2 de software
aplicativo, foco do processo proposto, composta por nove
desenvolvedores e um supervisor. O trabalho da equipe se
divide em desenvolvimento de novos produtos, manuteno
dos produtos j existentes e gerncia de configurao. Muitas
vezes, o mesmo desenvolvedor atua tanto no desenvolvimento,
quanto na manuteno.
Manter a mesma equipe tanto no desenvolvimento quanto na
manuteno impede que o time se comprometa durante um
determinado perodo apenas ao desenvolvimento, pois no
possvel prever quando surgir uma nova manuteno e em
alguns casos quanto tempo ser gasto nessa manuteno. Isso
pode fazer com que o time pare com o desenvolvimento para
realizar uma manuteno por ser de maior prioridade [4].

81

Portanto, ser proposto um processo tambm baseado em

Scrum e Kanban, mas com as adaptaes necessrias a este
cenrio de poucos recursos e fluxo varivel de projetos.
A. Diviso dos papis
A diviso dos papis segue o modelo proposto pelo Scrum.
Porm, na diviso dos times, o Scrum sugere de cinco a dez
desenvolvedores e um ScrumMaster. Neste caso, como toda a
equipe composta por dez desenvolvedores, formam-se times
com dois desenvolvedores ou at mesmo um nico. Neste
caso, devido a limitao de recursos apresentada no item I,
prope-se um ScrumMaster para times com 4 ou mais
integrantes onde um dos integrantes seria o ScrumMaster. E
um nico ScrumMaster para times com 3 ou menos
integrantes onde o ScrumMaster seria o prprio supervisor do
departamento. A Figura 1 ilustra esta distribuio. Espera-se
que o arranjo proposto
traga maior agilidade e por
conseguinte aumento de produtividade dos times. No
encontrou-se, na literatura pesquisada, nenhuma abordagem
relacionada sobrecarga de papis, embora seja uma situao
tpica das pequenas e mdias empresas de tecnologia.

Outra questo so os impedimentos que surgem durante o

trabalho. Com apenas uma pessoa responsvel por resolver
esses impedimentos, no caso o supervisor, o trabalho torna-se
lento algumas vezes, alm de provocar sobrecarga na
responsabilidade do supervisor.
Kniberg e Skarin [4] apresentam um estudo de caso de uma
empresa onde o trabalho da equipe de desenvolvimento
tambm era divido em desenvolvimento de novos produtos e
manuteno de produtos j existentes. A empresa havia
implantado Scrum no desenvolvimento e com isso vrios
impedimentos foram resolvidos e o desempenho da equipe
cresceu. Porm, a imprevisibilidade das manutenes e a
necessidade de priorizao constante das tarefas tornavam o
sistema de sprints do Scrum invivel.
Para esta empresa Kniberg e Skarin [4] implantaram um
processo baseado no Scrum e Kanban, onde as principais
mudanas foram a substituio das sprints pelo fluxo do
trabalho do Kanban e a Sprint Planning Meeting passou a ser
realizada semanalmente permitindo-se uma priorizao
constante das tarefas. Desta forma a empresa conseguiu
conciliar o desenvolvimento e a manuteno na mesma
equipe.
Embora o cenrio da empresa descrita pelos autores seja
parecido com o da empresa foco do estudo, em nenhum
momento os autores relatam problemas como falta de recursos
e fluxo varivel de projetos, problemas estes vividos pela
empresa foco do estudo.
2

Equipe so todas as pessoas que compem uma diviso do

desenvolvimento e time so as pessoas que pertencem a um projeto.

Figura 1 - Distribuio dos times

A empresa possui o cargo de Gerente de Produtos que quem

analisa o mercado e traz as informaes necessrias para o
desenvolvimento dos produtos. Esta pessoa assumiria o papel
de Product Owner dentro do desenvolvimento do produto,
participando das cerimnias quando sua presena for
necessria. Porm, a equipe de software aplicativo algumas
vezes tambm desenvolve produtos para uso interno de outros
departamentos da empresa. Neste caso, a pessoa responsvel
por este produto no outro departamento assumiria o papel de
Product Owner, participando das cerimnias quando sua
presena for necessria.
B. Os artefatos
Para acompanhamento e controle das atividades ser utilizado
um quadro do Kanban e os cartes usados seguiro o modelo
da Figura 2.

ANAIS DO CONGRESSO DE INICIAO CIENTFICA DO INATEL - INCITEL 2012

82

necessitem de uma anlise prvia antes de serem executadas.

Por exemplo, no caso das tarefas de manuteno, nem sempre
possvel determinar a causa de um problema num projeto,
requerendo primeiro uma anlise. Aps a anlise, a tarefa
encaminhada para a etapa de Transferncia, Execuo ou
Finalizada caso no exista nenhuma manuteno a ser feita.

Figura 2 - Carto modelo

Descrio dos campos do carto:

Cdigo: um nmero que identifica a funcionalidade

no Product Backlog;

Projeto: o nome do projeto que a tarefa pertence;

Tamanho: o tamanho da tarefa estimado em pontos

[3];

Entrada: a data em que a tarefa entrou no quadro

para ser feita;

Finalizada: a data em que a tarefa foi finalizada;

Descrio: uma breve descrio do que para ser

feito nesta tarefa;

Como demonstrar: segundo Kniberg [3] este campo

descreve como esta tarefa ser demonstrada na Sprint
Review Meeting e tambm pode ser utilizado para
implementao dos testes.

Os campos Tamanho, Entrada e Finalizada sero utilizados

para calcular a velocidade do time. Por exemplo, se uma tarefa
entrou no quadro dia 20/06/2010 e foi finalizada dia
25/06/2010 e seu tamanho 10 pontos, significa que o time
demorou 5 dias para conclu-la dando uma mdia de 2 pontos
por dia. Essa estimativa ser utilizada na negociao de
prazos.
Para identificar as tarefas de desenvolvimento e manuteno
sero utilizados cartes de cores diferentes, como mostrado na
Figura 3.
Estes cartes sero fixados em um quadro Kanban, onde todos
visualizaro as tarefas e o fluxo que as tarefas seguiro dentro
do processo. O quadro ser montado conforme ilustrado na
Figura 4.
O fluxo do processo no quadro segue da esquerda para a
direita. No topo de cada coluna est o nome da etapa e a
quantidade mxima de tarefas da etapa.
Toda tarefa nova ser colocada na primeira coluna (A fazer),
podendo ser tanto de desenvolvimento quanto de manuteno.
A prioridade entre elas de cima para baixo, onde tarefas do
topo possuem maior prioridade, sendo que as tarefas de
manuteno so mais prioritrias que as de desenvolvimento.
A segunda coluna (Anlise) ser utilizada para as tarefas que

Como mencionado no incio do captulo, a empresa em estudo

tambm desenvolve hardware e software embarcado e existe
uma integrao entre estes sistemas e os softwares aplicativos.
Muitas vezes acontece de os problemas de um sistema
refletirem no outro. Neste caso, quando uma tarefa de
manuteno ao passar pela anlise e for constatado que o
problema devido a outro sistema, esta ser encaminhada para
a coluna Transferncia. Isso quer dizer que a tarefa est em
anlise por outra equipe e aguardando resposta. Aps a
resposta da outra equipe esta tarefa ser encaminhada para a
coluna Finalizada, caso o problema seja realmente da outra
equipe, ou ser encaminhada para Anlise novamente ou
Execuo caso o problema seja realmente do software
aplicativo.
Na coluna Execuo ficam todas as tarefas que esto sendo
trabalhadas naquele momento, sejam elas de desenvolvimento
ou manuteno.
Aps a tarefa ter sido executada, ser encaminhada para a
coluna Teste, onde um outro desenvolvedor far os testes
necessrios. Neste ponto, o campo Como demonstrar do
carto pode servir de partida para os testes [4]. Se a tarefa
passar pelos testes, ir para coluna Finalizada, encerrando-se
o fluxo. Caso contrrio ela volta para a coluna Execuo para
as correes necessrias e passar novamente pelos testes.
Se em qualquer uma das etapas surgir algo que impea o
andamento da tarefa, ela ser encaminhada para a coluna
Bloqueada. O desenvolvedor informa ao ScrumMaster que
existe um impedimento e ele fica responsvel por remov-lo.
Cada etapa do processo possui um limite de tarefas. Como este
artigo trata de uma proposta e a empresa em estudo nunca
utilizou nenhuma tcnica parecida no desenvolvimento, estes
limites no puderam ser baseados em informaes histricas.
Estes valores foram baseados no nmero de desenvolvedores
da equipe, j apresentados no item IV.

ANAIS DO CONGRESSO DE INICIAO CIENTFICA DO INATEL - INCITEL 2012

83

Figura 3 - Cartes de manuteno (esquerda) e desenvolvimento (direita)

Figura 4 - Quadro Kanban

Para o nmero mximo de tarefas da coluna Execuo,

utiliza-se a expresso 2n-1 (n nmero de desenvolvedores)
proposta por Kniberg e Skarin [4], considerando no caso 10
desenvolvedores. Isso significa que nove desenvolvedores
podem trabalhar em duas tarefas simultneas e o dcimo estar
com apenas uma. Caso precise trabalhar numa segunda tarefa,
ter que esperar o trmino de alguma ou ajudar algum
desenvolvedor a terminar uma de suas tarefas. O propsito
dessa estratgia aumentar a colaborao entre os
desenvolvedores.
Ilustra-se na Figura 5 um exemplo de preenchimento do
quadro Kanban e na Figura 6 o preenchimento de um carto de
manuteno e outro de desenvolvimento.
C. As regras
Como visto no Item II, o Scrum prescreve cinco regras. Estas

regras sero mantidas para a empresa em estudo, porm com

algumas adaptaes. A principal mudana ser a substituio
das Sprints pelo fluxo do trabalho do Kanban. Num time onde
o trabalho se divide em desenvolvimento e manuteno, o
time no est cem porcento comprometido com o
desenvolvimento, que um requisito do Scrum na Sprint.
Portanto, a utilizao de Sprints torna-se invivel num cenrio
como este [4].

84

ANAIS DO CONGRESSO DE INICIAO CIENTFICA DO INATEL - INCITEL 2012

Figura 5 - Exemplo de um quadro Kanban (os cartes mais escuros so de manuteno e os mais claros de desenvolvimento)

Figura 6 - Cartes ampliados (superior de manuteno e inferior de desenvolvimento)

ANAIS DO CONGRESSO DE INICIAO CIENTFICA DO INATEL - INCITEL 2012

Para conciliar desenvolvimento e manuteno num mesmo

time necessrio um controle maior, fazendo com que as
tarefas tenham que ser priorizadas constantemente evitando-se
que o desenvolvimento ou a manuteno sejam deixados de
lado. Desta forma, tomando-se como base as experincias de
Kniberg e Skarin [4] e Kinoshita [2], realiza-se semanalmente
a Sprint Planning Meeting. Com relao ao dia ideal para
realizao desta reunio, Kinoshita [2] sugere que seja uma
quarta ou quinta-feira pois, iniciando as atividades numa
segunda-feira poderia provocar horas extras desnecessrias no
fim de semana para finalizar algumas tarefas pendentes.

85

ambientes onde exitem poucos recursos e exigem respostas

rpidas para as mudanas, estes modelos e ferramentas
podem-se tornar elementos chaves para o sucesso da
organizao.
Este artigo apresentou uma proposta de processo baseado no
modelo de processo Scrum e da ferramenta de processo
Kanban onde a principal caracterstica a melhoria contnua e
a resposta rpida s mudanas. Devido as peculiaridades da
empresa estudada, foram feitas algumas mudanas nos
modelos originais propostos pelo Scrum e Kanban,
objetivando assim melhor adaptao empresa estudada.

No mesmo dia logo aps a Sprint Planning Meeting feita a

Sprint Retrospective Meeting. Neste caso, como a equipe toda
pequena, no h necessidade de se fazer uma retrospectiva
para cada time. Renem-se os times, os ScrumMasters e os
Product Owners. A presena dos Product Owners opcional
[7].

Espera-se que esta proposta seja utilizada em organizaes

onde o cenrio seja parecido com o da empresa estudada. E
que os resultados obtidos por meio de estudo de caso sejam
relatados em trabalhos futuros.

Todos se renem numa sala fora do ambiente de trabalho, para

que se evite interrupes durante a reunio [3] e debatem
sobre duas perguntas: O que funcionou bem no processo
desde a ltima retrospectiva? e O que deveria ser
melhorado? [7]. O supervisor anota as opinies de todos e no
fim da reunio a equipe prioriza as mudanas para a prxima
semana, isso faz com que o processo esteja sempre em
melhoria contnua.

[1] K. Hiranabe, (2010, Jun) Kanban Applied to Software

Development: from Agile to Lean [Online]. Disponvel:
http://www.infoq.com/articles/hiranabe-lean-agilekanban.

Nos casos de desenvolvimento, aps as Sprint Planning

Meetings o Product Owner avalia se as funcionalidades
implementadas at aquele momento so suficientes para
compor um produto utilizvel. Caso j se tenha, agendada a
Sprint Review Meeting onde o time, o ScrumMaster, o
Product Owner e as reas da empresa interessadas avaliam o
produto desenvolvido at ali.
Durante a reunio, o time apresenta as funcionalidades
implementadas desde a ltima Sprint Review Meeting e
anotam as observaes e comentrios feitos. Estas anotaes
sero utilizadas na prxima Sprint Planning Meeting, onde o
Product Owner decidir quais delas iro para o Product
Backlog.
Durante a semana, no incio de cada manh, o time e o
ScrumMaster se renem para realizar a Daily Scrum Meeting.
Nesta reunio os times atualizam o quadro Kanban e
respondem a trs perguntas feitas pelo ScrumMaster: o que
foi feito desde a ltima reunio?; existe algum
impedimento?; e o que ser feito at a prxima reunio?
[7]. O objetivo encontrar o mais rpido possvel os bloqueios
do projeto, tudo aquilo que impea o avano do
desenvolvimento.
O supervisor far uma reunio individual com cada time.
Espera-se com isso maior aproveitamento da reunio j que
todos estaro focados em um nico projeto.
V. CONCLUSO
Devido as dificuldades da implantao de processos
tradicionais, modelos e ferramentas de processo vm
ganhando cada vez mais espao dentro das organizaes. Em

REFERNCIAS

[2] F. Kinoshita, Practices of an Agile Team, IEEE

Computer Society, Toronto, pp. 373-377, Aug. 2008.
[3] H. Kniberg, (2010, Jan) Scrum and XP from the Trenches:
How
we
do
Scrum
[Online].
Disponvel:
http://www.infoq.com/minibooks/scrum-xp-from-thetrenches.
[4] H. Kniberg, M. Skarin, (2010, Feb) Scrum and Kanban:
making the most of both [Online]. Disponvel:
http://www.infoq.com/minibooks/kanban-scrumminibook.
[5] R. Pressman, Engenharia de Software. (6. ed.) So Paulo:
McGraw-Hill, 2006.
[6] L. Rising, N. Janoff, The Scrum Software Development
Process for Small Teams, IEEE Software, New York, pp.
26-32, July 2000.
[7] K. Schwaber, Agile Project Management with Scrum.
Redmond: Microsoft Press, 2004.
[8] K. Schwaber, (2010, Jun) SCRUM Development Process
[Online].
Disponvel:
https://wiki.state.ma.us/confluence/download/attachments
/16842777/Scrum+Development+Process.pdf.