Pomodoro aliado a SCRUM para aumento da

Pomodoro aliado a SCRUM para aumento da
produtividade: um estudo de caso
Robério Gomes Patrício¹ e Natália de Cassia Coelho Macedo²
¹Universidade Estadual do Ceará, Mestrado Acadêmico em Ciências da Computação, Fortaleza – CE, Brasil, 60740-000
¹Instituto Federal de Educação Ciência e Tecnologia, Crato – CE, Brasil, 63115-500
¹ ²Faculdade de Juazeiro do Norte, Juazeiro do Norte – CE, Brasil, 63010-475
Cícero Tadeu Pereira Lima França³
Faculdade de Juazeiro do Norte, Juazeiro do Norte – CE, Brasil, 63010-475
Resumo ⎯ Este trabalho relata a experiência da aplicação
do framework ágil Scrum aliada à ferramenta de gerenciamento
de tempo Pomodoro, objetivando um melhor aprendizado sobre
o planejamento das atividades envolvidas no processo de
construção de software, e a maximização do tempo aplicado
nestas. Aqui foi possível observar os benefícios oferecidos pelo
uso destas ferramentas em conjunto, bem como as dificuldades
e os impedimentos encontrados pelo time. Partindo de uma
observação pessimista, acreditando-se na existência de interesses
e práticas conflitantes entre as duas abordagens, o time obteve
um alto crescimento em sua capacidade de produção e
conhecimento no desenvolvimento de novos produtos.
Palavras-chave ⎯ Metodologia ágil, Framework, Scrum e
Pomodoro.
Uma vez que Desenvolvimento Ágil valoriza a
velocidade e o dinamismo, é possível afirmar que o
principal objetivo deste modelo de desenvolvimento é
obter o produto final, o software, com rapidez e acima
de tudo, qualidade.
Esse trabalho, por meio de um estudo de caso,
demonstra o uso do framework ágil Scrum e a técnica
de gerenciamento de tempo Pomodoro, usados em
conjunto, com objetivo de maximização do uso efetivo
do tempo da equipe de desenvolvimento, destacando os
pontos importantes da experiência vivida com essa
integração.
II. SCRUM
I. INTRODUÇÃO
O Desenvolvimento ágil foi uma estratégia
encontrada pela Engenharia de Software, como aliada
no processo de construção de software, contemplando
a velocidade e o dinamismo, visto que nas
metodologias de desenvolvimento tradicionais a
dinâmica dos processos se dava de forma inflexível,
não se adaptando facilmente às constantes mudanças
de requisitos.
Segundo os agilistas, termo atribuído aos adeptos e
praticantes dos Métodos Ágeis, a idéia seria manter o
foco nos indivíduos e não nos processos, existindo
uma grande preocupação em dedicar maior parte do
tempo na construção do software em vez de gastar
tempo com documentação, diagramas e relatórios.
Uma característica importante das metodologias
ágeis é que estas são adaptativas e não preditivas, os
fatores que influenciam suas mudanças acontecem no
presente, com as necessidades do cliente, tornando os
requisitos flexíveis, ao invés de analisar previamente
tudo que vai acontecer no decorrer do desenvolvimento,
sabendo que isso é impossível. Outras características
importantes a serem destacadas são: desenvolvimento
iterativo e incremental, comunicação e redução de
produtos
intermediários,
como
documentação
extensiva. Sendo assim, possibilita atender o máximo
possível aos requisitos do cliente, que na maioria das
vezes são mutáveis.
¹ [email protected]
² [email protected]
³ [email protected] O nascimento
O processo de desenvolvimento de software vem
passando por mudanças profundas desde o advento dos
Métodos Ágeis. Desde então foram várias as iniciativas
em divulgar os seus princípios e levar à frente os
valores propostos pelo Manifesto Ágil [1]. Ao mesmo
tempo em que tal manifesto define os princípios base
para uma nova forma de desenvolvimento de software,
ele não é capaz de mostrar os caminhos, meios e/ou
procedimentos necessários para ser ágil. É verdade que
ser ágil pressupõe saber trabalhar em meio ao caos
criativo, mas era de se esperar algo mais que meros
princípios. É em meio às várias tentativas de
formalização e até mesmo normatização de como “ser
ágil” que surge o modelo de desenvolvimento Scrum.
Segundo [2], as bases do Scrum apontam para
meados dos anos oitenta, quando as diferenças em
desenvolvimento de produtos foram pesquisadas e
descritas em um artigo intitulado “O novo jogo para
desenvolvimento de novos produtos” [3]. Surgiam aí as
primeiras reflexões e indícios de que era necessário
repensar o modo de desenvolver novos produtos,
levando em conta como algumas empresas de forma
consistente e rápida eram capazes de lançar novos
produtos bem-sucedidos e inovadores no mercado. [3]
falam ainda que:
Muitas empresas descobriram que era preciso
mais do que os princípios aceitos de alta qualidade,
baixo custo e diferenciação para a excelência no
mercado competitivo de hoje. Era necessário
também velocidade e flexibilidade.
Ainda em seu estudo [3] fazem a seguinte proposta:
O estilo tradicional de “corrida de revezamento”
aplicado ao desenvolvimento de produtos (...) pode
conflitar com os objetivos de velocidade e
flexibilidade máximas. Ao invés disto, um estilo
holístico, onde a equipe busca como em um jogo de
“rugby”, de forma integrada, avançar em direção à
meta, com passes de bola, pode servir melhor às
atuais necessidades competitivas.
Dessa forma ficou demonstrado que as empresas de
sucesso não desenvolvem produtos usando um modelo
tradicional de desenvolvimento seqüencial, como a
abordagem em cascata segundo [4] no setor de
software.
Como funciona
Em sua implementação o Scrum prevê regras
simples, muitas delas fáceis de entender em poucos
minutos, juntamente com algumas cerimônias, artefatos
e papeis que são associados aos membros da equipe de
desenvolvimento.
São três os papeis presentes em uma equipe que
deseja trabalhar com Scrum:
• Product Owner (Dono do Produto): é o “dono do
produto“, representa os interesses do cliente e tem
como missão ajudar na identificação dos requisitos,
sua priorização e maximização do ROI (Return on
Investiment).
• Scrum Master (Mestre Scrum): é o “líder servo”
da equipe cujo papel é remover os impedimentos
que atrapalhem a equipe no processo de
desenvolvimento do produto e garantir que os
princípios do Scrum estejam sendo seguidos.
• Team (Time): é o time de desenvolvedores, com
uma formação multidisciplinar e um perfil autogerenciado.
Essencialmente o desenvolvimento usando Scrum
acontece em iterações, denominadas sprints, com
duração entre duas a quatro semanas. Tomando como
base a lista de requisitos do cliente, denominada
Product Backlog, o time se compromete em
desenvolver, durante esse intervalo de tempo, um
conjunto de funcionalidades previamente apontadas e
priorizadas de acordo com as necessidades do cliente.
Esse comprometimento baseia-se no que o time acredita
ser viável acrescentar ao produto em termos funcionais
naquele dado sprint.
Ao início de cada sprint o time se reúne com o
Product Owner em uma cerimônia chamada Sprint
Planning com o objetivo de identificar, com base nas
prioridades do negócio, o que deve ser entregue ao final
daquele sprint e qual o esforço necessário para isso.
Nessa discussão escolhe-se um subconjunto de
funcionalidades, chamado Sprint Backlog, e estima-se o
esforço necessário para obtê-las, sendo este, o resultado
esperado do trabalho realizado nessa nova iteração.
As funcionalidades a serem trabalhadas, suas
estimativas de esforço e as atividades envolvidas no
processo de construção são dispostas em formato de
tickets em um quadro chamado Task Board. Os
integrantes do time a qualquer momento podem atribuir
a si mesmos tais tarefas, assumindo o compromisso de
entregá-las
completamente
funcionais.
O
acompanhamento da execução das tarefas torna-se fácil
ao observar a movimentação destas pelas colunas do
Task Board. Também é costume usar um gráfico de
linhas que relaciona a quantidade de trabalho restante
no sprint versus os dias da semana. Com esse gráfico é
possível confrontar o andamento ideal das tarefas,
representado por uma função linear, com o andamento
real diário chamado Burn Down.
Ao final do sprint, o time se reúne novamente com o
Product Owner e outros interessados no projeto (Sprint
Review) para demonstrar o progresso do produto. Não
se trata de uma entrega de relatórios e/ou documentos,
mas uma demonstração do software em funcionamento.
Essa reunião se configura como uma ótima
oportunidade para o time obter o feedback dos
interessados com relação ao que está sendo produzido.
Uma outra cerimônia chamada Sprint Retrospective
(Retrospectiva do Sprint) é feita logo em seguida, tendo
como participantes somente o time e seu Scrum Master.
O objetivo é avaliar as lições aprendidas, pontos fortes
e fracos, e que ações podem ser tomadas para melhorar
o desempenho da equipe à luz dos princípios do Scrum.
Sob a óptica de inspeção e adaptação, todos os dias o
time se reúne durante no máximo 15 minutos em uma
reunião chamada Daily Scrum. Essa é a oportunidade
para avaliar o progresso obtido nas últimas 24 horas,
discutindo os impedimentos existentes e decidindo os
novos rumos para o próximo dia de trabalho.
Segundo [5], seguindo as idéias de inspeção e
adaptação, trabalhando de forma iterativa incremental,
recebendo o feedback dos interessados e reavaliando
constantemente sua forma de trabalhar, o time tem a
oportunidade de aumentar o seu conhecimento em duas
dimensões: o conhecimento sobre o produto em
desenvolvimento e o conhecimento sobre como
trabalhar em conjunto.
[2] é bastante feliz quando compara Scrum ao jogo
de tabuleiro de xadrez. Essa comparação reforça a idéia
da simplicidade das regras do Scrum, além de enfatizar
que dessas simples regras surgem estratégias complexas
e sofisticadas que podem levar toda uma vida para se
atingir o domínio e maestria.
III.
POMODORO
Encara-se o tempo como um grande inimigo, pois se
acumulam tarefas e dispõe-se cada vez de menos tempo
para executá-las. [6] ao abrir o capítulo que fala sobre
priorização cita a seguinte afirmativa: “Não raramente,
ou nunca, existe tempo suficiente para fazer tudo.”
O Pomodoro é uma técnica criada para o
gerenciamento individual do tempo, objetivando
transformá-lo em um aliado ao invés de um inimigo.
Essa técnica surgiu na década de 80, criada por
Francesco Cirillo, que quando universitário em Roma,
viu a necessidade de organizar o seu tempo, visto que
havia um elevado número de distrações e interrupções e
o nível de concentração e motivação era baixo. Então
era preciso encontrar uma maneira de melhorar seu
rendimento pessoal elevando seu poder de concentração
e aprendendo a tratar tais distrações. Ele possuía em
mãos um relógio de cozinha em forma de tomate (essa é
a razão do nome Pomodoro, do italiano), marcou um
determinado tempo para executar sua tarefa de forma
que estivesse 100% focado, seguido de uma pequena
pausa. [7] pôde observar que aquela era uma boa prática
para aproveitar da melhor forma seu tempo. Para tanto,
era necessário somente manter o foco e a concentração
por aquele espaço de tempo, tornando possível reavaliar
suas prioridades a cada pausa que dava.
A técnica Pomodoro toma por base, o fato de que o
ser humano não consegue concentrar-se completamente
em uma atividade por longos períodos de tempo. Dessa
forma, é proposto que sejam dados intervalos de tempo,
mesmo que curtos, para que possa reavaliar o que está
sendo feito. A idéia consiste em se trabalhar por um
período de tempo de 25 minutos, chamado de
Pomodoro, com um pequeno intervalo de 5 minutos
entre um Pomodoro e outro. Após 4 Pomodoros é
aconselhável um intervalo maior de 25 a 30 minutos,
para que possam ser efetuadas atividades mais
complexas e que exijam mais da pessoa. O
planejamento é algo muito importante nesta prática.
Define-se no inicio do dia as atividades a serem
executadas, estimando-se o número de Pomodoros
previsto para cada atividade, sendo que aconselha-se
que atividades que demandem menos de 1 Pomodoro
sejam agrupadas, e atividades que exijam mais de 7
Pomodoros sejam quebradas em atividades menores.
[7] propõe que sejam utilizadas folhas de papel onde
são anotadas as atividades a serem executadas (A Fazer
Hoje), e as interrupções internas e externas que são
feitas no decorrer do Pomodoro (Não Planejada e
Urgente), e ainda uma folha onde são registradas as
interrupções que podem ser executas posteriormente,
onde se planeja quando fazê-las. Existem ferramentas
disponíveis gratuitamente na web, que podem ser
utilizadas na substituição das folhas de papel. Essa
técnica é muito eficiente para o autogerenciamento,
pois ajuda bastante a focar no objetivo, mesmo que
existam muitos outros correlacionados.
Em The Pomodoro Technique, [7], a Técnica
Pomodoro, tem como objetivo fornecer uma ferramenta
simples e capaz de aliviar a ansiedade, aumentar o foco
e a concentração através da redução de interrupções,
aumentar a conscientização de suas decisões, aumentar
a motivação e mantê-la constante, reforçar a
determinação para atingir seus objetivos, refinar o
processo de estimativas tanto em qualidade como em
quantidade, melhorar os processos de trabalho ou
estudo e reforçar a determinação de manter-se firme
diante de situações mais complexas.
IV.
ESTUDO DE CASO
O trabalho com métodos ágeis não significa apenas
saber as regras da metodologia ou das ferramentas de
apoio que estão sendo utilizadas, é necessário saber
adaptar e implementar de maneira que se adéque da
melhor forma ao time.
O time
O time de desenvolvedores foi composto por dois
programadores e um líder técnico, cada um destes
utilizando um computador pessoal, ocupando uma
pequena sala, o que tornava a comunicação do time
fácil e rápida.
Com relação ao perfil da equipe, os dois
programadores não apresentavam mais que um ano de
experiência em desenvolvimento de software, sendo
esse projeto em específico o primeiro em que
trabalhavam com tantas tecnologias diferentes e
complexas tais como Enterprise Java Beans, Web
Services e Adobe Flex. O líder técnico era o integrante
mais experiente e acumulava as atividades de Scrum
Master com o objetivo de favorecer a remoção dos
impedimentos, uma vez que estes em sua maioria eram
de ordem tecnológica. O líder técnico acabava não
sendo responsável por muitas tarefas durante as sprints,
assumindo a responsabilidade apenas de tarefas
pontuais, tecnicamente complexas, quando o time assim
o solicitava.
Iterações, release e planejamento
Apesar de todos os integrantes do time já terem
usado Scrum, foi escolhido trabalhar com sprints
semanais com o objetivo de minimizar os riscos
técnicos, julgando ser esse o intervalo de tempo
adequado para tomadas de decisão e mudanças de
planos e rumos.
O Sprint Planning acontecia sempre no primeiro dia
da semana, na parte da manhã. De posse do Product
Backlog devidamente preenchido com as User Stories e
seus Business Value associados, o Scrum Master
ajudava o time a estimar a complexidade destas. As
User Stories eram estimadas em ordem de grandeza ou
complexidade e não em dias ideais como fazem alguns
times ágeis [6]. Essa abordagem objetivava reduzir a
necessidade de reestimativas futuras uma vez que o
time estava apenas interessado em determinar a
dificuldade envolvida na obtenção de uma dada
funcionalidade, atribuindo-lhe uma pontuação (Story
Points).
Um fato importante a destacar foi o uso do Planning
Poker baseado na Série de Fibonnaci como escala de
Story Points. [6] afirma que é a melhor maneira para
estimativas ágeis, uma vez que combina a opinião dos
especialistas, analogia e desagregação de um modo
divertido, resultando em estimativas rápidas e
confiáveis. Com essa ferramenta foi possível visualizar
a expectativa de dificuldade que cada programador
tinha para uma dada funcionalidade, sendo sempre
aberta uma discussão quando as expectativas eram
divergentes. Uma vez estimadas as Stories, tomava-se
como ponto de partida na construção do Sprint Backlog
um índice de maximização do ROI gerado pela divisão
do Business Value pela Complexidade de cada uma. A
partir dos valores obtidos foi gerada uma sequência de
execução das Stories, mas sempre era levado em conta
as possíveis dependências e precedências existentes no
processo de construção das funcionalidades.
Para o Release Planning a falta de experiência do
time com as tecnologias envolvidas não favorecia o uso
de um histórico de velocidade de produção. Assim, o
time optou pelo método de estimativas baseado em
previsão de velocidade proposto por [6]. Assim, o
cálculo da velocidade do time foi obtido a partir de
quantas horas o time teria disponível para trabalhar em
cada Sprint, e, escolhendo-se algumas Stories
aleatoriamente e quebrando-as em tarefas e sub-tarefas,
o time chegava a um volume de trabalho com o qual
estava disposto a comprometer-se. Em seguida,
avaliava-se a quantos Story Points esse compromisso do
time equivalia, chegando-se a uma estimativa que
segundo [6] apresenta uma margem de erro de 60%.
Com relação ao planejamento da release, ficou
determinado que na primeira sprint seria utilizado
somente Scrum e a partir da segunda seria feita a
intervenção com o Pomodoro.
A escolha das sprints de uma semana não foi por
acaso, essa prática é interessante para possibilitar a
visualização de resultados rapidamente, servindo de
incentivo ao time para se obter o resultado final.
Sprint 1
Na primeira Sprint, usando somente Scrum, foram
estimadas 52 horas de trabalho disponíveis para a
equipe, sendo tomadas para o planejamento apenas 42
horas a partir do uso do backlog priorizado e da
capacidade de compromisso da equipe estimada durante
o planejamento da Release (18 story points). As
histórias foram quebradas e divididas em sub tarefas,
estimando-se quantas horas seriam necessárias a cada
sub tarefa chegando ao número acima mencionado.
A partir deste ponto entra em cena a utilização do
Task Board para o acompanhamento das atividades que
se tem a fazer, as que estão sendo feitas e as que estão
prontas. Para cada uma das tarefas, um pequeno ticket
foi associado, estando estes sempre se movendo entre as
colunas do Task Board até a sua conclusão. No decorrer
da sprint cada integrante de time escolhia a tarefa na
qual iria trabalhar e movia o ticket para a coluna
“fazendo”, anotando a inicial do seu nome para melhor
identificação. Ao finalizar, o ticket era movido para a
coluna “feito” e datado do fim da tarefa. A partir dessas
datas foi possível gerar o burn down da primeira sprint
ainda sem a utilização do Pomodoro, ficando da
seguinte forma:
Gráfico 1.1 Burn Down Sprint #1
Sprint 2
Durante a reunião de retrospectiva do sprint #1, foi
apresentada ao time, a técnica de gerenciamento de
tempo Pomodoro. O time entendeu que com base no
apresentado seria de grande valor realizar um
experimento de adoção de tal técnica visando
maximizar a produtividade do time. Foi escolhida a
ferramenta Pomodairo [8] para implantação da técnica.
Os critérios usados para adoção do Pomodairo foram
sua maior adequação aos modelos de acompanhamento
propostos por Cirillo e sua portabilidade entre os
Sistemas Operacionais. Com essa ferramenta é possível
implementar o pomodoro sem a necessidade do uso de
folhas de papel, uma vez que na própria ferramenta
existem todos os campos que seriam necessários na
folha de papel, sendo ainda possível comparações entre
os pomodoros.
Para a sprint #2, foram tomadas 47 horas de
trabalho, equivalendo isso a 21 Story Points. Após a
divisão das tarefas, iniciou-se a execução destas
utilizando-se Scrum e Pomodoro. Nos primeiros
momentos, acontecem mais impedimentos que o usual,
já que é a fase de adaptação à ferramenta Pomodairo.
Notou-se uma inquietação dos integrantes do time, mas
logo no primeiro dia foi estabelecido que cada
indivíduo teria o compromisso de executar apenas 5
pomodoros durante seu dia. A idéia era não deixar os
membros do time isolados, focados na resolução única e
exclusivamente de suas tarefas, deixando o trabalho
coletivo em segundo plano, prejudicando o rendimento
coletivo e a comunicação. Logo foi possível observar a
contribuição do uso do Pomodoro. O time conseguiu no
primeiro dia da sprint diminuir em 10 horas o volume
de horas a trabalhar. Fazendo-se uma média de quantas
horas o time deveria consumir a cada dia do sprint,
sendo 47 horas em 5 dias, percebe-se que logo no
primeiro dia de uso do Pomodoro a média diária
esperada de 9,4 havia sido superada. No segundo dia da
sprint, com o time estando mais adaptado a ferramenta,
a evolução foi maior sendo conquistadas mais 13 horas
de trabalho, ficando bem acima da media diária
esperada. No terceiro dia da sprint, aconteceram
impedimentos de caráter técnico, problemas com a
sincronização do repositório nos computadores dos
desenvolvedores, sendo este o dia menos proveitoso da
sprint, podendo ser observado no gráfico que mostra a
evolução da sprint #2. No dois dias subseqüentes, a
sprint correu da forma esperada, ficando bem próxima
da linha ideal.
Sprint 3
Os resultados obtidos na segunda sprint foram
animadores deixando o time curioso quanto ao que
poderia acontecer a partir daquele, momento visto que
havia se passado o sprint de adaptação. O planejamento
da sprint foi um pouco mais ousado, assumindo-se 23
story points com uma carga de 50 horas estimadas de
trabalho. Ainda com o compromisso de pelo menos 5
pomodoros diários o time obteve o seguinte burn down:
Gráfico 1.3 Burn Down Sprint #3
Sprint 4
Para a conclusão da release restavam alguns itens
que o time julgava agregar pouco valor de negócio e
cuja complexidade e risco de execução eram altos. A
sprint 4 foi planejada com xx story points e 51 horas de
esforço estimadas. Essa parecia ser a sprint mais
desafiadora, mas como algumas questões que elevavam
os riscos do projeto no decorrer das sprints anteriores
foram se tornando mais claras, e a equipe ganhava a
cada dia mais confiança no seu potencial e nos
resultados que podia obter uma surpresa lhes estava
reservada. A Sprint foi cumprida em apenas 3 dias! É
certo que a maturidade e o reuso de componentes de
software obtidos nas iterações anteriores contribuíram
para esse feito. Mas não se pode deixar de falar dos
efeitos do Pomodoro nessa conquista. Desenvolvedores
mais focados, centrados em ser efetivos em suas tarefas,
primando pela qualidade para redução do retrabalho e
mais maduros quanto ao processo de planejamento de
suas atividades, esse era o grande fruto da Sprint 4.
ideal Gráfico 1.2 Burn Down Sprint #2
Gráfico 1.4 Burn Down Sprint #4
V. CONCLUSÃO
Como proposto por [5], o estudo de caso demonstrou
que a cada novo sprint o time melhorava sua maneira de
trabalhar, e, como nos esportes coletivos, a motivação,
a autoconfiança, o planejamento e a discussão de novas
estratégias levam o time a obter melhores resultados.
Apesar do fato que as práticas propostas pelo Scrum
ajudarem o time a crescer como um todo, elas não dão
ao indivíduo as ferramentas e diretrizes para o melhor
planejamento e execução das tarefas individualmente
assumidas. O fato é que o Task Board contempla as
tarefas em um nível nem sempre suficientemente
detalhado. O uso de Pomodoro confere aos membros do
time a oportunidade de exercitar a quebra das tarefas
em itens mais mensuráveis de executar, além de
favorecer o uso racional do tempo, dando chance de
adaptação e tomadas de novos rumos de maneira rápida,
minimizando as perdas de tempo com processos de
exploração e tentativas.
Durante a apresentação da técnica Pomodoro, foi
levantada a questão sobre a possibilidade da mesma ser
conflitante com os objetivos e princípios do Scrum os
quais primam pelo trabalho em equipe e comunicação.
O uso racional de 5 pomodoros diários deu ao time a
leveza necessária para manter-se um ambiente de
trabalho comunicativo e dinâmico com momentos
fortes durante o dia de concentração e rendimento
individual. Essa proposta veio da observação do volume
de interrupções que aconteciam durante o dia dos
programadores, uma vez que estes estavam alocados
apenas 6 horas por dia.
Ao final da última Sprint o time de desenvolvimento
se deu por satisfeito com os resultados obtidos e pôde
utilizar com maior confiança e propriedade os dados
históricos obtidos, aplicando-os no planejamento de um
novo produto com características diferentes mas com
uso das mesmas tecnologias anteriormente usadas.
Uma nova avaliação de rendimento poderia ser
aplicada no contexto desse novo produto. Assim
poderiam ser abordados aspectos mais complexos da
interação Scrum e Pomodoro, tais como o uso de
estimativas em pomodoros no lugar de horas de esforço,
análise do volume de interrupções externas e que
medidas poderiam ser utilizadas para redução destas no
ambiente de trabalho.
VI.
BIBLIOGRAFIA
[1] BECK, K. BEEDLE, M. et.al. Manifesto Ágil
<http://agilemanifesto.org/> 30/01/2011
[2] KEITH, C. Agile Game Development With
Scrum. 1ª edição. Indiana: Addison-Wesley, 2010.
[3] TAKEUCHI. H; NONAKA. I. The new new
product development game. 1986. Harvard
Business Review January: 137–146.
[4] O’DOCHERDY, Mike.
Object - Oriented
Analysis & Design. Berkeley: John Wiley e Sons
Ltd, 2005.
[5] SCHWABER, K. Agile Project Management with
Scrum. Redmond: Microsoft Press, 2004.
[6] COHN, Mike. Agile Estimating and Planning.
Massachusetts: Pearson Education, 2005.
[7] CIRILLO, F. The Pomodoro Technique. 1ª edição.
San Francisco: 2006.
[8] <http://code.google.com/p/pomodairo> 30/01/11