SlideShare une entreprise Scribd logo
1  sur  13
Télécharger pour lire hors ligne
Chapter

1
Scrum: Uma Metodologia Ágil para Gestão e Plane-
jamento de Projetos de Software

Fabio Abrantes Diniz, Diego Grosmann, Thiago Reis da Silva e Íthalo Bruno
Grigório de Moura




                                         Abstract


Everyone knows that most software projects can be frustrating. Deadlines are rarely
met, software quality is not always ideal. Scrum is an agile development methodology
that focuses on teamwork, with self-managed teams and active participation of the client.
Another important figure is the scrum master, whose function is to remove obstacles and
provide the necessary elements so that the team has the best performance possible. The
routine begins with the Scrum product backlog, list of project requirements, ordered by
priority. From this list comprises the sprint backlog - requirements to be implemented
in the next sprint (iteration), each sprint lasts about 30 days and after its end, features
developed are validated by the product owner (client, usually) and released, starting a
new cycle.


                                         Resumo


Todos sabem que, a maioria dos projetos de software pode ser frustrante. Prazos de
entrega são raramente cumpridos, a qualidade do software nem sempre é ideal. Scrum
é uma metodologia de desenvolvimento ágil, focada no trabalho em equipe, com equi-
pes auto-gerenciadas e participação ativa do cliente. Outra figura importante é o scrum
master, que tem a função de eliminar obstáculos e proporcionar os elementos necessários
para que a equipe tenha o melhor desempenho possível. A rotina de Scrum começa com
o product backlog, lista dos requisitos do projeto, ordenados por prioridade. A partir
desta lista é formado o sprint backlog – requisitos que serão implementados no próximo
sprint (iteração); cada sprint dura cerca de 30 dias e, após seu final, as funcionalida-
des desenvolvidas são validadas pelo product owner (cliente, normalmente) e liberadas,
iniciando-se um novo ciclo.
1.1. METODOLOGIAS ÁGEIS
Esta seção abordará uma visão geral sobre a metodologia ágil que começa com as declarações
do manifesto ágil citadas abaixo.
       Esta seção abordará uma visão geral sobre a metodologia ágil que começa com as
declarações do manifesto ágil citadas abaixo.
       As metodologias ágeis, criadas em 2001 [1], foram apresentadas formalmente
ao público com o lançamento do Manifesto para o desenvolvimento ágil de software,
freqüentemente chamado apenas de Manifesto Ágil. Esse modelo descreve um conjunto
de abordagens para desenvolvimento de software:

   • Indivíduos e interação entre eles são mais importantes que processos e ferramentas;

   • Software em funcionamento é mais importante que documentação abrangente;

   • Colaboração com o cliente é mais importante que negociação de contratos;

   • Responder a mudanças é mais importante que seguir um plano.

       De acordo com análise das abordagens do manifesto ágil as contribuições e suas
tendências [2] [3] [4] avaliadas abaixo são importante para o objetivo desse trabalho.


Indivíduos e interação entre eles são mais importantes que processos e ferramentas:
Apesar da qualidade dos profissionais envolvidos no desenvolvimento do projeto afetar
diretamente a qualidade do produto e o bom desempenho da equipe no projeto, ter ótimos
profissionais não é certeza de sucesso, pois estes dependem diretamente do processo. Um
processo mal seguido pode fazer com que os desenvolvedores não sejam capazes de usar
de todo o seu talento. Além da mistura certa do processo adequado com bons profis-
sionais, é preciso que todo o grupo possa interagir perfeitamente entre si. Comunicação
é mais importante do que simples talento para programação. Logo, um desenvolvedor
médio com bom relacionamento é bem melhor, trabalhando em equipe, é mais produtivo
que um excelente programador trabalhando sozinho.
        É importante levar em consideração que as ferramentas utilizadas são importantes
para o sucesso final do projeto, mas elas não podem ter mais importância que seus uti-
lizadores. Logo, mais importante que as ferramentas são a qualidade e o grau de interação
da equipe.


Software em funcionamento é mais importante que documentação abrangente: A
documentação de um projeto é muito necessária para o sucesso do projeto, servindo como
comunicação entre o racional e a estrutura do sistema. Uma documentação legível para
descrever o sistema ainda se faz necessária na tomada de decisões do projeto. Porém,
é preciso tomar muito cuidado com o excesso na documentação. De nada adianta uma
grande quantidade de documentos que demoram muito tempo para serem gerados, se eles
não estão em sincronia com o que está sendo desenvolvido e o que foi especificado.
Documentos sem essa sincronia prejudicam a realidade do projeto, fazendo com
que decisões erradas possam ser tomadas. O Manifesto sugere é que somente a documen-
tação necessária seja gerada e esteja sempre sincronizada com o sistema, pois a transfer-
ência de conhecimento sobre o projeto é feita trabalhando lado a lado, utilizando-se do
código, sendo que este não permite duplas interpretações da funcionalidade e do que o
sistema faz.


Colaboração com o cliente é mais importante que negociação de contratos: Um
bom software não é feito somente escrevendo suas necessidades (contratos, prazos, cus-
tos) num papel e entregando à empresa que vai desenvolver. Projetos feitos desta maneira
são falhos, gerando um produto final com pouca eficiência e qualidade. Nas metodolo-
gias ágeis, para que o projeto tenha sucesso e aceitação, é preciso que exista sempre um
feedback do cliente para garantir que o software esteja sendo desenvolvido de maneira
que atenda as necessidades.
        Outra motivação está no fato de alguns requisitos mudarem e começarem a se
tornar dispensáveis. Além disso, pode haver a necessidade de se adicionar outros requisi-
tos não previstos em contrato ou especificação. Portanto, o melhor contrato é aquele que
propõe como será a comunicação e o relacionamento do cliente com a equipe desenvolve-
dora.


Responder a mudanças é mais importante que seguir um plano: Algumas mudanças
de especificação sempre vão ocorrer em projetos, e quanto maior é o grau de adaptação a
essas mudanças melhor será o projeto. Planos devem, sim, serem traçados. Porém, como
não é possível prever o futuro, as visões desses planos não podem ir muito longe. Muito
deve ser projetado para poucas semanas, pouco se projeta para o próximo mês e quase
nada se planeja para próximos anos, pois com as alterações que invariavelmente podem
aparecer, dificilmente se devem fazer planos mais longos.
        Logo, as metodologias ágeis são uma atitude, não um processo prescritivo; é um
suplemento aos métodos existentes, não é uma metodologia completa; é uma forma efe-
tiva de se trabalhar em conjunto para atender as necessidades das partes interessadas no
projeto; funciona na prática, não é uma teoria acadêmica; não é um ataque à documen-
tação, pelo contrário, aconselha a criação de documento que tem valor; o cliente faz parte
da equipe de desenvolvimento e utiliza um modelo iterativo e incremental.
       Atualmente há muitos processos ágeis disponíveis para desenvolvimento de soft-
wares. Os processos mais abordados são: Scrum, Dynamic Systems Development Method
(DSDM), Crystal Methods, Feature-Driven Development (FDD), Lean Development (LD)
e Extreme Programming [2]. Este trabalho descreverá a metodologia ágil Scrum.

1.2. Scrum
O Scrum é um processo ágil, simples e leve que pode ser utilizado para gerenciar e con-
trolar o desenvolvimento de software. Tem sido utilizado em diversas áreas de Tecnologia
da informação, tais como sistema da informação, vídeo games, websites, sistemas embar-
cados e celulares.
Figure 1.1. Análise comparativa das metodologias ágeis. Fonte: VersionOne
    Agile Global Survey 2008




1.2.1. Visão Geral
O Scrum uma metodologia ágil que surgiu a partir de um jogo conhecido como Rugby.
Esse jogo envolve oito jogadores de cada time para se formar uma muralha. Se um mem-
bro da equipe falhar, o outro time se sobressai [5]. O ponto fundamental desse jogo é o
trabalho em equipe. O trabalho em conjunto do time. É a essência dessa metodologia.
        A história do Scrum foi iniciada a partir de um gerenciamento de projetos em
empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka
no artigo “The New Product Development Game” (Harvard Business Review, Janeiro-
Fevereiro 1986) [6]. Eles concluíram que equipes pequenas e multidisciplinares pro-
duziam melhores resultados. Depois, Jeff Sutherland, John Scumniotales e Jeff McKenna
documentaram e implementaram o Scrum na empresa Easel Corporations em 1993, in-
corporando o estilo de gerenciamento observado por Takeuchi e Nonaka [6]. E em 1995,
Ken Shwaber formalizou a definição de Scrum como método ágil que prevê as mudanças
freqüentes no desenvolvimento do software [7].
       O Scrum se destaca dos outros processos ágeis por ser um método iterativo, in-
cremental e ágil para o gerenciamento de Projetos. O Scrum é o processo mais praticado
pelas empresas.
       Abaixo se encontra uma figura do terceiro anual Survey do ano 2008: “The State
of Agile Development” mostrando um grau comparativo de adoção das metodologias
ágeis em projetos de softwares, mostrando em especial a adoção do Scrum, um indício do
seu sucesso e relevância em projetos de desenvolvimento de software.
        Podemos verificar na figura 1.1 que o Scrum se encontra em destaque na maioria
das empresas de software. O Scrum é colaborativo e ideal em projetos pequenos com req-
uisitos que mudam constantemente durante o desenvolvimento de software, pois a prática
de Scrum facilita a adaptação a processos empíricos de desenvolvimento de sistemas. O
framework do Scrum é formado basicamente em papéis, cerimônias e artefatos [8] com
cada um fazendo parte do fluxo do processo do Scrum. Nas próximas seções serão detal-
hadas o framework do Scrum e o fluxo do Scrum.
1.2.1.1. Papéis do Scrum

O Scrum como qualquer outra metodologia é baseada em papéis e responsabilidades. Ele
é dividido em três papéis: Product Owner (Cliente), o time, e o Scrum Master [8]. Cada
um com sua responsabilidade.


Product Owner: Pode ser o financiador ou um interessado no projeto. Representa o
interesse de todos os usuários do sistema final. Suas responsabilidades são: definir as
funcionalidades do produto, coleta informações vindas dos usuários, stakeholders ou do
mercado para obter uma visão única dos requisitos do sistema, além disso, controla o ROI
do projeto, prioriza o Product Backlog [9].


Time: É o grupo de pessoas que está fazendo o trabalho e que garantirá que o pro-
jeto seja entregue com todas as funcionalidades necessárias. São multifuncionais e auto-
organizáveis. Define o objetivo do sprint e especifica os resultados dos trabalhos. Forma-
dos por até sete pessoas, são coletivamente os responsáveis pelo sucesso de cada interação
e do projeto como um todo. A idéia de auto-organizável e multifuncional é que o time
deve possuir toda a capacidade e conhecimento técnico do processo de desenvolvimento
do produto.


Scrum Master: É o líder, gerencia o interesse do Product Owner e treina o time. Por-
tanto ele melhora a vida e a produtividade do time provendo criatividade e conhecimento.
O Scrum Master também estimula a comunicação e a cooperação entre todas as pessoas
do time, remove impedimentos, garante que o processo está sendo respeitado e auxilia o
Product Owner a maximizar o ROI.


Stakeholders (Cliente e fornecedores): Estas são as pessoas que aprovam o projeto e
para quem o projeto irá produzir o benefício acordado. Eles só se envolvem no processo
durante as sprint reviews.
       Abaixo se encontra um possível cenário alocando cada responsável indicando seus
papéis e responsabilidades descritos (Veja a figura 1.2).

1.2.2. Cerimônias
As cerimônias SCRUM são eventos que acontecem dentro de um ciclo de desenvolvi-
mento Scrum. Existem três tipos de cerimônias Scrum: a reunião de Planejamento do
Sprint, as reuniões diárias do Scrum e a reunião de revisão do Sprint. Estes eventos se
caracterizam pelo ciclo de vida de cada Sprint: início, meio e fim.


1.2.2.1. Reunião de planejamento do Sprint (Sprint planning)

Uma reunião planejamento da Sprint ocorre no inicio da Sprint. Tem um tempo de du-
ração (Time-box) entre 3 a 4 horas é realizado no primeiro dia. Geralmente esta reunião
Figure 1.2. Cenário dos papéis dos envolvidos no processo Scrum. Fonte:
    http://delicious.com/marcospereira



é dividida em duas partes: Sprint Planning 1 (fase do Product Backlog) e Sprint Planning
2 (fase do Sprint Backlog).


Sprint planning 1: Participam o Product Owner (PO), time e o Scrum Master (SM) que
atua como mediador. A equipe realizará o planejamento para verificar qual é o Product
Backlog. A equipe deve selecionar quais itens (funcionalidades), ordenados pela priori-
dade, serão feitos na Sprint [10].


Sprint planning 2: Participam dessa parte o SM e o time, caso ocorra dúvida o PO pode
ser consultado para planejar o Sprint baseado no Product Backlog. A equipe seleciona
quais itens do Backlog serão implantados até o fim da Sprint (duração de 28 dias). Depois
cada item selecionado será quebrado em tarefas menores (stories) formando o chamado
Sprint Backlog. Com isso, o time fica sabendo o que é necessário ser feito para implantar
os itens.


1.2.2.2. Reuniões diárias do Scrum (daily sprint)

É uma reunião pública, onde só os membros do time podem fazer comentários e perguntas
e dura no máximo 15 minutos. Três perguntas são respondidas nessa reunião: O que eu fiz
desde a última reunião? O que eu vou fazer até a próxima reunião? Quais os problemas
estão impedindo a realização do meu trabalho?
       O Scrum Master tem um papel fundamental aqui em resolver os impedimentos.
Os benefícios dessas reuniões são a visibilidade do que está acontecendo para todo o
grupo e ajuda ao SM a identificar os impedimentos.


1.2.2.3. Reunião de revisão do Sprin (Srpint review)

É uma reunião realizada no ultimo dia da Sprint. Todos participam (PO, SM e time) e
dura 4 horas em geral e serve para revisar os altos e baixos do ciclo. Aqui é apresentado
o resultado do trabalho. Nesta reunião, podem ser levantadas novas funcionalidades e
os stakeholders podem identificar funcionalidades que não forem entregues e um novo
Product backlog é gerado [11].
       Depois que esta reunião é finalizada, um novo ciclo Sprint pode começar até que
todo o produto seja finalizado e o Product Backlog esteja limpo de pendências.


1.2.2.4. Sprint Retrospective

É uma reunião que acontece no final de uma Sprint. Dura em média 3 horas. Partici-
pam o Scrum Master, o time e o PO (opcional). Com o objetivo de detectar melhorias e
documentar as lições aprendidas.


1.2.2.5. Reunião de Planejamento da Versão para Entrega (Release Planning)

O propósito do planejamento da versão para entrega é o de estabelecer um plano e metas
que o Time Scrum e o resto da organização possam entender e comunicar. O planejamento
da versão para entrega responde às questões: “Como podemos transformar a visão em
um produto vencedor da melhor maneira possível? Como podemos alcançar ou exceder a
satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?” O plano da versão
para entrega estabelece a meta da versão, as maiores prioridades do Backlog do Produto,
os principais riscos e as características gerais e funcionalidades que estarão contidas na
versão.
       Ele estabelece também uma data de entrega e custo prováveis que devem se manter
se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse
plano da versão para entrega a cada Sprint.
       Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo que
cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco.
Mais e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um
pedaço potencialmente entregável do produto completo. Quando já tiverem sido criados
incrementos suficientes para que o produto tenha valor e uso para seus investidores, o
produto é entregue. Muitas organizações já possuem um processo de planejamento de
versão para entrega, e na maior parte desses processos o planejamento é feito no início do
trabalho da versão e não é modificado com o passar do tempo.
Figure 1.3. Product Backlog. Fonte: http://delicious.com/marcospereira



        No planejamento de versão para entrega do Scrum, são definidos uma meta geral
e resultados prováveis. Esse planejamento geralmente não requer mais do que 15-20%
do tempo que uma organização costumava utilizar para produzir um plano de versão para
entrega tradicional. No entanto, uma versão com Scrum realiza planejamento no momento
da execução de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma
forma que realiza um planejamento diário no momento da execução de cada Reunião
Diária.
        De forma geral, os esforços para uma versão para entrega com Scrum provavel-
mente consomem ligeiramente mais esforço do que os esforços para um planejamento
de versão para entrega tradicional. Planejamento de versão para entrega requer estimar e
priorizar o Backlog do Produto para a Versão. Há diversas técnicas para fazê-lo que estão
fora do alcance do Scrum, mas que apesar disso são úteis quando usadas com ele.

1.2.3. Artefatos
Product Backlog É uma lista de funcionalidades feita pelo proprietário do produto
(Product Owner) em conjunto com o cliente, que é organizada por prioridade de entrega.
O time contribui estimando o custo de desenvolvimento das funcionalidades. A Figura
1.3 mostra um exemplo de product backlog:


Sprint Backlog São tarefas menores formado pela quebra dos itens do Backlog. É uma
lista especificando os passos necessários para implantar uma funcionalidade do sistema.
A Figura 1.4 mostra um exemplo de Sprint backlog em quadro de cartolina dividido em
Figure 1.4. Sprint Backlog. Fonte: Gerenciamento de projetos com Scrum, abril de 2007




quatro colunas. A Figura mostra o item do product backlog, tarefas que estão pendentes
a fazer, tarefas alocadas para cada membro do time, e as tarefas prontas pelo time.

1.2.4. Fluxo do Scrum
Nessa seção será descrito, de forma geral, como ocorre o processo Scrum no gerencia-
mento do desenvolvimento de software. De início a Figura 1.5 resume visualmente todas
as fases do processo do Scrum. Logo depois são apresentadas as descrições passo-a-passo
de cada etapa do processo.
        De acordo com a figura, um projeto Scrum inicia com a visão global do sistema
que será desenvolvido. O proprietário do produto é responsável por produzir esse doc-
umento de forma que seja maximizado seu retorno de investimento (ROI). O Product
Owner elabora a lista de itens priorizados gerando o Product Backlog, que são os requi-
sitos funcionais e não funcionais do sistema. O Product Backlog é priorizado pelos itens
mais desejados. Logo, os mais importantes serão entregues nas primeiras versões.
        Todo o trabalho é feito em Sprints ou iterações. Cada Sprint é uma interação de
30 dias consecutivos [8]. Entretanto na prática há uma flexibilidade em relação a esse
tamanho, pois depende muito das características do time e do esforço para implantar o
produto. Cada Sprint é iniciado com a reunião do planejamento do Sprint (Sprint Plan-
ning), em que o Product Owner e o time estão juntos para colaborar sobre o que será feito
na próxima Sprint.
       A Sprint Planning tem duração de 8 horas. Esse tempo fixo é importante para
Figure 1.5. Fluxo do Scrum. Fonte:blog.marciel.org/?m=200909)



manter ágil o processo. A Sprint Planning é dividida em duas etapas. A primeira etapa é
de 4 horas com o Product Owner apresentando o Product Backlog ao time. O time pode
questionar sobre as intenções de cada item do Product Backlog. Diferente nas metodolo-
gias tradicionais como o RUP só uma pessoa é que faz o levantamento dos requisitos.
Na segunda etapa, o Scrum Master e o time selecionam os itens mais ágeis de ser imple-
mentados por meios de técnicas de estimativas de esforços como, por exemplo, técnica
do Planning Poker que estima os itens pelo tamanho da complexidade [10]. Depois de
estimadas, o time divide os itens em tarefas menores gerando o Sprint Backlog para cada
item do Backlog que serão implantados durante a Sprint.
        Todos os dias terão reuniões diárias que duram 15 minutos, em que os membros
do time fazem comentários e perguntas sobre como esta o andamento do projeto. Essa re-
união diária usa alguns conceitos do XP, como a reunião em pé e o valor da comunicação
entre a equipe. Isso traz benefícios como troca de conhecimentos entre a equipe resul-
tando sincronização entre todos. Destaca-se nessas reuniões o dever do Scrum Master em
resolver os impedimentos.
         No final da Sprint, o Sprint review é realizado com duração de 4 horas [8]. Aqui
é mostrado ao product Owner de tudo o que foi desenvolvido na Sprint. Nessa reunião,
podem ser levantadas novas funcionalidades e gerar um novo Product Backlog. Depois
que esta reunião é finalizada, um novo ciclo Sprint pode começar até que todo o produto
seja finalizado e o Product Backlog esteja limpo de pendências. Após essa prática, é
feita a Sprint Retrospecive e algumas perguntas são respondidas, como: O que aconteceu
durante a Sprint? O que foi bom durante a Sprint? O que poderia funcionar melhor? Essa
prática traz benefício para a equipe conhecer melhor e melhorar nas próximas Sprints.
Portanto juntos a Sprint Planning, Sprint Review e o Sprint Retrospective constituem
uma inspeção formal e uma adaptação ao processo Scrum.

1.2.5. Estimativa de Tempo usando Planning Poker
Antes de começar falar sobre estimativas, gostaria de chamar a atenção para o significado
da palavra “Estimativa”.
       O que é uma estimativa?
1. Um cálculo aproximado;

   2. Uma declaração por escrito do preço aproximado que será cobrado para um trabalho
      específico;

   3. Um julgamento ou avaliação.

        Mais importantes, estimativas são inerentemente erradas. Estimativas não são ex-
atas, e não refletem a realidade. A única maneira de saber o tempo exato que uma ativi-
dade vai durar, ou quanto esforço será necessário despender para executar algum trabalho,
é após a sua realização. Dito isso, vamos prosseguir a respeito do Poker Planning.
        Uma das maneiras mais eficientes e recomendadas de estimar o tamanho de requi-
sitos em times que adotam métodos ágeis (XP/Scrurn) é o jogo de cartas conhecido como
Planning Poker [14]. Este método de estimar combina opinião de especialistas, analogias
e desagregação em uma aproximação eficiente para estimar de maneira rápida, porém
confiável. É uma variação do método de estimativa Wideband Delphi [15].
        As estimativas acontecem normalmente em uma reunião, também chamada de
timeboxed (geralmente 4 ou 8 horas, dependendo da quantidade de requisitos a ser es-
timada). Os participantes do jogo de poker são todos os membros do time do Scrum.
O Product Owner normalmente comparece a esta reunião para prestar esclarecimentos
a respeito dos requisitos, porém não pode opinar e estimar junto com o time. O Scrum
Master registra os resultados da reunião, e assim como o Product Owner, não interfere
nas estimativas do time.
        No início de uma reunião de Planning Poker, cada membro do time recebe um
deck de cartas, que contém uma variação da sequência de Fibonacci: 0, 1/2, 1, 2, 3, 5, 8,
13, 20, 40, 50, 75, 90, 100 ? e “Pausa”. Ainda no início, todos os itens a serem estimados
são lidos pelo Product Owner ou Scrum Master, e a equipe conversa para decidir qual é o
menor item de backlog disponível.


1.2.5.1. Gerenciamento de Projetos com Scrum utilizando Planning Poker

O Gerenciamento de Projetos com SCRUM, após essas estimativas iniciais, esse item é
marcado corno “2” pontos, e a equipe prossegue para estimar os demais itens de backlog.
Isso serve para definir uma referência de tamanho e complexidade para ser utilizada nas
demais estimativas. Isso só precisa ser definido na primeira reunião de Estimativa, e
deve ficar registrado, para uso nas futuras reuniões. Em casos excepcionais, o time pode
decidir mudar a estória de referência por uma outra estória. Aqui também é importante
usar o bom-senso.
       Seguindo adiante, para cada estória a ser estimada, o Scrum Master ou Product
Owner lê a descrição e os critérios de aceitação da mesma. O Product Owner responde a
quaisquer questionamentos que o time possua a respeito da estória, entretanto procurando
manter o nível da discussão em alto nível, e no entrar em detalhes. É comum definir
também um timebox para esse tempo de Perguntas e Respostas, de modo a não se estender
demais e perder muito tempo em uma única estória. Depois da apresentação e discussão
inicial, cada pessoa seleciona sua estimativa (uma carta), baseada em sua opinião pessoal
a respeito do tamanho e complexidade da estória, e a coloca em cima da mesa, com a face
voltada para baixo. Quando todos os participantes selecionarem uma carta, as mesmas
serão viradas ao mesmo tempo.
       Se houver uma grande variância entre a maior e menor carta, o time vai discutir o
que cada membro estava pensando quando selecionou o tamanho. A ideia aqui é que todos
entendam as razões, que mais uma ou outra pergunta sejam respondidas pelo Product
Owner, e a equipe volta a pensar sobre a estória, e faz uma nova estimativa. O ciclo
deve ser repetido até que todas as estimativas estejam próximas, ou que a equipe chegue
a um consenso. É comum definir um limite de rodadas de poker, para evitar que as coisas
fiquem muito arrastadas. Repetir até que todas as estórias estejam 100% estimadas!

1.2.6. Considerações Finais
Muitas empresas desenvolvem software sem usar nenhum processo. Geralmente isso
ocorre porque os processos tradicionais não são adequados às suas realidades. Em par-
ticular, as pequenas e médias empresas ou organizações não possuem recursos suficientes
para adotar o uso de metodologias pesadas e, por essa razão, normalmente não utilizam
nenhum processo. O resultado dessa falta de sistematização na produção de software é a
baixa qualidade do produto final.
        Devido a esse contexto, as metodologias ágeis vêm se tornando cada vez mais
utilizadas pelas empresas nos últimos anos por ter uma abordagem simplificada. Está
comprovado que os métodos, práticas e técnicas para o desenvolvimento de projeto ágil
são adequados para situações em que a mudança de requisitos é freqüente [8]. Isso au-
menta a satisfação do cliente [12], produz alta qualidade de software e diminuição dos
prazos e custos de desenvolvimento [13]. Os projetos tradicionais de desenvolvimento de
software não são adequados para projetos em que mudanças são freqüentes. Isso acaba
atrapalhando o cumprimento de prazos, aumentando seus custos e prazos, e diminuindo a
qualidade do software.
        Diante desse contexto, o Scrum é uma das metodologias ágeis que estão mais
adaptadas a mudanças e está mais sendo usada pelas empresas de softwares. O Scrum é
um processo que constrói software incrementalmente em ambientes complexos, onde os
requisitos não são claros ou mudam com muita frequência.

1.3. Referências
References
 [1] Disponível em http://www.agilemanifesto.org/ Ultimo acesso em 18/10/2009.
 [2] BECK, K., “Extreme Programming Explained: Embrace Change”, 1st Edition,
     Addison-Wesley, 1999.
 [3] WELLS, D, Disponível em http://www.extremeprogramming.org, Visitado em
     20/09/2004;
 [4] SANTOS, R. Disponível em http://www.ime.usp.br/˜ daltonl/ageis/ageis_6pp.pdf
                                                    g
     Visitado em 08/10/2009.
[5] Disponível em     http://www.javamovel.com/2009/09/scrum.html     Visitado   em
     08/10/2009.

 [6] Disponível em http://pt.wikipedia.org/wiki/Scrum Visitado em 08/10/2009.

 [7] Asfora, Diego Maciel. “Uma abordagem para a priorização de requisitos em ambi-
     entes ágeis” Dissertação Mestrado, UFPE, 2009.

 [8] Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004

 [9] Disponível em http://www.aspercom.com.br/ead/mod/resource/view.php?id=245
     Visitado em 08/10/2009.

[10] Disponível em http://www.companyweb.com.br/Rildo/scrum/Tutorial-SCRUM-
     v9.pdf Visitado em 08/10/2009.

[11] Ken Schwaber. Agile Software Development with Scrum. Prentice Hall (2001).

[12] BOEHM, B. and Turner, R., Balancing Agility and Discipline A Guide for the Per-
     plexed, Addison Wesley, 2003.

[13] ANDERSON, D. J., Agile Management for Software Engineering, Applying the
     Theory of Constraints for Business Results, Prentice Hall, 2003.

[14] Henrik Kniberg. Scrum; XP Direto das trincheiras. Ed. Enterprise Software Devel-
     opment Community, 2007.

[15] Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi; Warsta, Juhani. Agile Software
     Development Method, Review and Analysis. Espoo 2002. VTT publications 478.
     107p

Contenu connexe

Tendances

Treinamento de Scrum
Treinamento de ScrumTreinamento de Scrum
Treinamento de ScrumLuiz Duarte
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMLucas Vinícius
 
Ferramentas para testes de software
Ferramentas para testes de softwareFerramentas para testes de software
Ferramentas para testes de softwareNorton Guimarães
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareDaniel Cukier
 
Tutorial BizAgi Modelagem de Processos de Negócio
Tutorial BizAgi Modelagem de Processos de NegócioTutorial BizAgi Modelagem de Processos de Negócio
Tutorial BizAgi Modelagem de Processos de NegócioRildo (@rildosan) Santos
 
Implantação e Manutenção de Softwares
Implantação e Manutenção de SoftwaresImplantação e Manutenção de Softwares
Implantação e Manutenção de SoftwaresMarcelo Schumacher
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareAdolfo Neto
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Cloves da Rocha
 
Desarrollo ágil con JIRA y Confluence
Desarrollo ágil con JIRA y ConfluenceDesarrollo ágil con JIRA y Confluence
Desarrollo ágil con JIRA y ConfluenceHéctor Gomis Hidalgo
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - ResumoDaniel Brandão
 
Agile Practices - eXtreme Programming
Agile Practices - eXtreme ProgrammingAgile Practices - eXtreme Programming
Agile Practices - eXtreme ProgrammingAniruddha Chakrabarti
 

Tendances (20)

Test link
Test linkTest link
Test link
 
eXtreme Programming (XP)
eXtreme Programming (XP)eXtreme Programming (XP)
eXtreme Programming (XP)
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
 
Mapa Mental Scrum
Mapa Mental ScrumMapa Mental Scrum
Mapa Mental Scrum
 
Tutorial Scrum Experience
Tutorial Scrum Experience Tutorial Scrum Experience
Tutorial Scrum Experience
 
Treinamento de Scrum
Treinamento de ScrumTreinamento de Scrum
Treinamento de Scrum
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
 
Ferramentas para testes de software
Ferramentas para testes de softwareFerramentas para testes de software
Ferramentas para testes de software
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
 
Tutorial BizAgi Modelagem de Processos de Negócio
Tutorial BizAgi Modelagem de Processos de NegócioTutorial BizAgi Modelagem de Processos de Negócio
Tutorial BizAgi Modelagem de Processos de Negócio
 
Scrum
ScrumScrum
Scrum
 
Implantação e Manutenção de Softwares
Implantação e Manutenção de SoftwaresImplantação e Manutenção de Softwares
Implantação e Manutenção de Softwares
 
Role of scrum master
Role of scrum masterRole of scrum master
Role of scrum master
 
Agile Scrum
Agile ScrumAgile Scrum
Agile Scrum
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
 
Desarrollo ágil con JIRA y Confluence
Desarrollo ágil con JIRA y ConfluenceDesarrollo ágil con JIRA y Confluence
Desarrollo ágil con JIRA y Confluence
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
Agile Practices - eXtreme Programming
Agile Practices - eXtreme ProgrammingAgile Practices - eXtreme Programming
Agile Practices - eXtreme Programming
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
 

Similaire à Scrum uma metodologia ágil paragestão e planejamento de projetos de software

Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumRaphael Donaire Albino
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareEverton vitor
 
Trabalho pds libre office 2
Trabalho pds libre office 2Trabalho pds libre office 2
Trabalho pds libre office 2Edinaldo Mendes
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Maicon Zerbielli
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANFernando Palma
 
Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Caroline Seara
 
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...Kéllyson Gonçalves da Silva
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalhoRuan Pozzebon
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosWilliam Lima
 

Similaire à Scrum uma metodologia ágil paragestão e planejamento de projetos de software (20)

Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
 
Metodologias de desenvolvimento
Metodologias de desenvolvimentoMetodologias de desenvolvimento
Metodologias de desenvolvimento
 
Metodos ageis
Metodos ageisMetodos ageis
Metodos ageis
 
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
 
Trabalho pds libre office 2
Trabalho pds libre office 2Trabalho pds libre office 2
Trabalho pds libre office 2
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Metodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de SistemaMetodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de Sistema
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)
 
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
SCRUM: ADOÇÃO DE UM FRAMEWORK ÁGIL NO DESENVOLVIMENTO DE UM SOFTWARE PARA TRA...
 
Agil - artigo cientifico
Agil - artigo cientificoAgil - artigo cientifico
Agil - artigo cientifico
 
Processos Ágeis
Processos Ágeis Processos Ágeis
Processos Ágeis
 
Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2
 
Artigo corrigido
Artigo corrigidoArtigo corrigido
Artigo corrigido
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 

Plus de Thiago Reis da Silva

Apostila de Introdução a Programação
Apostila de Introdução a ProgramaçãoApostila de Introdução a Programação
Apostila de Introdução a ProgramaçãoThiago Reis da Silva
 
The use of games on the teaching of programming: a systematic review
The use of games on the teaching of programming: a systematic reviewThe use of games on the teaching of programming: a systematic review
The use of games on the teaching of programming: a systematic reviewThiago Reis da Silva
 
Desenvolvendo plug-in do Moodle em forma de módulo
Desenvolvendo plug-in do Moodle em forma de móduloDesenvolvendo plug-in do Moodle em forma de módulo
Desenvolvendo plug-in do Moodle em forma de móduloThiago Reis da Silva
 
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...Thiago Reis da Silva
 
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagemO uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagemThiago Reis da Silva
 
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagemIntegrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagemThiago Reis da Silva
 
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...Thiago Reis da Silva
 
Um modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Um modelo de objeto de aprendizagem com ênfase no planejamento para o MoodleUm modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Um modelo de objeto de aprendizagem com ênfase no planejamento para o MoodleThiago Reis da Silva
 
Aplicação de uma técnica de visualização de dados baseado em árvores para au...
Aplicação de uma técnica de visualização de dados baseado  em árvores para au...Aplicação de uma técnica de visualização de dados baseado  em árvores para au...
Aplicação de uma técnica de visualização de dados baseado em árvores para au...Thiago Reis da Silva
 
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...Thiago Reis da Silva
 
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...Thiago Reis da Silva
 
Ampliando o aprendizado na TV digital com MCD-TV e ginga
Ampliando o aprendizado na TV digital com MCD-TV e gingaAmpliando o aprendizado na TV digital com MCD-TV e ginga
Ampliando o aprendizado na TV digital com MCD-TV e gingaThiago Reis da Silva
 
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...Thiago Reis da Silva
 
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...Thiago Reis da Silva
 
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...Thiago Reis da Silva
 
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE COM O USO D...
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE  COM O USO D...ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE  COM O USO D...
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE COM O USO D...Thiago Reis da Silva
 

Plus de Thiago Reis da Silva (20)

Apostila de Introdução a Programação
Apostila de Introdução a ProgramaçãoApostila de Introdução a Programação
Apostila de Introdução a Programação
 
Introdução a Programação
Introdução a ProgramaçãoIntrodução a Programação
Introdução a Programação
 
The use of games on the teaching of programming: a systematic review
The use of games on the teaching of programming: a systematic reviewThe use of games on the teaching of programming: a systematic review
The use of games on the teaching of programming: a systematic review
 
Desenvolvendo plug-in do Moodle em forma de módulo
Desenvolvendo plug-in do Moodle em forma de móduloDesenvolvendo plug-in do Moodle em forma de módulo
Desenvolvendo plug-in do Moodle em forma de módulo
 
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
 
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagemO uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
 
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagemIntegrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagem
 
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
 
Survey e Análise Estatística
Survey e Análise Estatística Survey e Análise Estatística
Survey e Análise Estatística
 
Um modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Um modelo de objeto de aprendizagem com ênfase no planejamento para o MoodleUm modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Um modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
 
Aplicação de uma técnica de visualização de dados baseado em árvores para au...
Aplicação de uma técnica de visualização de dados baseado  em árvores para au...Aplicação de uma técnica de visualização de dados baseado  em árvores para au...
Aplicação de uma técnica de visualização de dados baseado em árvores para au...
 
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
 
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
 
Ampliando o aprendizado na TV digital com MCD-TV e ginga
Ampliando o aprendizado na TV digital com MCD-TV e gingaAmpliando o aprendizado na TV digital com MCD-TV e ginga
Ampliando o aprendizado na TV digital com MCD-TV e ginga
 
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
 
Minicurso SCRUM
Minicurso SCRUMMinicurso SCRUM
Minicurso SCRUM
 
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
 
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
 
Artigo
ArtigoArtigo
Artigo
 
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE COM O USO D...
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE  COM O USO D...ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE  COM O USO D...
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE COM O USO D...
 

Scrum uma metodologia ágil paragestão e planejamento de projetos de software

  • 1. Chapter 1 Scrum: Uma Metodologia Ágil para Gestão e Plane- jamento de Projetos de Software Fabio Abrantes Diniz, Diego Grosmann, Thiago Reis da Silva e Íthalo Bruno Grigório de Moura Abstract Everyone knows that most software projects can be frustrating. Deadlines are rarely met, software quality is not always ideal. Scrum is an agile development methodology that focuses on teamwork, with self-managed teams and active participation of the client. Another important figure is the scrum master, whose function is to remove obstacles and provide the necessary elements so that the team has the best performance possible. The routine begins with the Scrum product backlog, list of project requirements, ordered by priority. From this list comprises the sprint backlog - requirements to be implemented in the next sprint (iteration), each sprint lasts about 30 days and after its end, features developed are validated by the product owner (client, usually) and released, starting a new cycle. Resumo Todos sabem que, a maioria dos projetos de software pode ser frustrante. Prazos de entrega são raramente cumpridos, a qualidade do software nem sempre é ideal. Scrum é uma metodologia de desenvolvimento ágil, focada no trabalho em equipe, com equi- pes auto-gerenciadas e participação ativa do cliente. Outra figura importante é o scrum master, que tem a função de eliminar obstáculos e proporcionar os elementos necessários para que a equipe tenha o melhor desempenho possível. A rotina de Scrum começa com o product backlog, lista dos requisitos do projeto, ordenados por prioridade. A partir desta lista é formado o sprint backlog – requisitos que serão implementados no próximo sprint (iteração); cada sprint dura cerca de 30 dias e, após seu final, as funcionalida- des desenvolvidas são validadas pelo product owner (cliente, normalmente) e liberadas, iniciando-se um novo ciclo.
  • 2. 1.1. METODOLOGIAS ÁGEIS Esta seção abordará uma visão geral sobre a metodologia ágil que começa com as declarações do manifesto ágil citadas abaixo. Esta seção abordará uma visão geral sobre a metodologia ágil que começa com as declarações do manifesto ágil citadas abaixo. As metodologias ágeis, criadas em 2001 [1], foram apresentadas formalmente ao público com o lançamento do Manifesto para o desenvolvimento ágil de software, freqüentemente chamado apenas de Manifesto Ágil. Esse modelo descreve um conjunto de abordagens para desenvolvimento de software: • Indivíduos e interação entre eles são mais importantes que processos e ferramentas; • Software em funcionamento é mais importante que documentação abrangente; • Colaboração com o cliente é mais importante que negociação de contratos; • Responder a mudanças é mais importante que seguir um plano. De acordo com análise das abordagens do manifesto ágil as contribuições e suas tendências [2] [3] [4] avaliadas abaixo são importante para o objetivo desse trabalho. Indivíduos e interação entre eles são mais importantes que processos e ferramentas: Apesar da qualidade dos profissionais envolvidos no desenvolvimento do projeto afetar diretamente a qualidade do produto e o bom desempenho da equipe no projeto, ter ótimos profissionais não é certeza de sucesso, pois estes dependem diretamente do processo. Um processo mal seguido pode fazer com que os desenvolvedores não sejam capazes de usar de todo o seu talento. Além da mistura certa do processo adequado com bons profis- sionais, é preciso que todo o grupo possa interagir perfeitamente entre si. Comunicação é mais importante do que simples talento para programação. Logo, um desenvolvedor médio com bom relacionamento é bem melhor, trabalhando em equipe, é mais produtivo que um excelente programador trabalhando sozinho. É importante levar em consideração que as ferramentas utilizadas são importantes para o sucesso final do projeto, mas elas não podem ter mais importância que seus uti- lizadores. Logo, mais importante que as ferramentas são a qualidade e o grau de interação da equipe. Software em funcionamento é mais importante que documentação abrangente: A documentação de um projeto é muito necessária para o sucesso do projeto, servindo como comunicação entre o racional e a estrutura do sistema. Uma documentação legível para descrever o sistema ainda se faz necessária na tomada de decisões do projeto. Porém, é preciso tomar muito cuidado com o excesso na documentação. De nada adianta uma grande quantidade de documentos que demoram muito tempo para serem gerados, se eles não estão em sincronia com o que está sendo desenvolvido e o que foi especificado.
  • 3. Documentos sem essa sincronia prejudicam a realidade do projeto, fazendo com que decisões erradas possam ser tomadas. O Manifesto sugere é que somente a documen- tação necessária seja gerada e esteja sempre sincronizada com o sistema, pois a transfer- ência de conhecimento sobre o projeto é feita trabalhando lado a lado, utilizando-se do código, sendo que este não permite duplas interpretações da funcionalidade e do que o sistema faz. Colaboração com o cliente é mais importante que negociação de contratos: Um bom software não é feito somente escrevendo suas necessidades (contratos, prazos, cus- tos) num papel e entregando à empresa que vai desenvolver. Projetos feitos desta maneira são falhos, gerando um produto final com pouca eficiência e qualidade. Nas metodolo- gias ágeis, para que o projeto tenha sucesso e aceitação, é preciso que exista sempre um feedback do cliente para garantir que o software esteja sendo desenvolvido de maneira que atenda as necessidades. Outra motivação está no fato de alguns requisitos mudarem e começarem a se tornar dispensáveis. Além disso, pode haver a necessidade de se adicionar outros requisi- tos não previstos em contrato ou especificação. Portanto, o melhor contrato é aquele que propõe como será a comunicação e o relacionamento do cliente com a equipe desenvolve- dora. Responder a mudanças é mais importante que seguir um plano: Algumas mudanças de especificação sempre vão ocorrer em projetos, e quanto maior é o grau de adaptação a essas mudanças melhor será o projeto. Planos devem, sim, serem traçados. Porém, como não é possível prever o futuro, as visões desses planos não podem ir muito longe. Muito deve ser projetado para poucas semanas, pouco se projeta para o próximo mês e quase nada se planeja para próximos anos, pois com as alterações que invariavelmente podem aparecer, dificilmente se devem fazer planos mais longos. Logo, as metodologias ágeis são uma atitude, não um processo prescritivo; é um suplemento aos métodos existentes, não é uma metodologia completa; é uma forma efe- tiva de se trabalhar em conjunto para atender as necessidades das partes interessadas no projeto; funciona na prática, não é uma teoria acadêmica; não é um ataque à documen- tação, pelo contrário, aconselha a criação de documento que tem valor; o cliente faz parte da equipe de desenvolvimento e utiliza um modelo iterativo e incremental. Atualmente há muitos processos ágeis disponíveis para desenvolvimento de soft- wares. Os processos mais abordados são: Scrum, Dynamic Systems Development Method (DSDM), Crystal Methods, Feature-Driven Development (FDD), Lean Development (LD) e Extreme Programming [2]. Este trabalho descreverá a metodologia ágil Scrum. 1.2. Scrum O Scrum é um processo ágil, simples e leve que pode ser utilizado para gerenciar e con- trolar o desenvolvimento de software. Tem sido utilizado em diversas áreas de Tecnologia da informação, tais como sistema da informação, vídeo games, websites, sistemas embar- cados e celulares.
  • 4. Figure 1.1. Análise comparativa das metodologias ágeis. Fonte: VersionOne Agile Global Survey 2008 1.2.1. Visão Geral O Scrum uma metodologia ágil que surgiu a partir de um jogo conhecido como Rugby. Esse jogo envolve oito jogadores de cada time para se formar uma muralha. Se um mem- bro da equipe falhar, o outro time se sobressai [5]. O ponto fundamental desse jogo é o trabalho em equipe. O trabalho em conjunto do time. É a essência dessa metodologia. A história do Scrum foi iniciada a partir de um gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo “The New Product Development Game” (Harvard Business Review, Janeiro- Fevereiro 1986) [6]. Eles concluíram que equipes pequenas e multidisciplinares pro- duziam melhores resultados. Depois, Jeff Sutherland, John Scumniotales e Jeff McKenna documentaram e implementaram o Scrum na empresa Easel Corporations em 1993, in- corporando o estilo de gerenciamento observado por Takeuchi e Nonaka [6]. E em 1995, Ken Shwaber formalizou a definição de Scrum como método ágil que prevê as mudanças freqüentes no desenvolvimento do software [7]. O Scrum se destaca dos outros processos ágeis por ser um método iterativo, in- cremental e ágil para o gerenciamento de Projetos. O Scrum é o processo mais praticado pelas empresas. Abaixo se encontra uma figura do terceiro anual Survey do ano 2008: “The State of Agile Development” mostrando um grau comparativo de adoção das metodologias ágeis em projetos de softwares, mostrando em especial a adoção do Scrum, um indício do seu sucesso e relevância em projetos de desenvolvimento de software. Podemos verificar na figura 1.1 que o Scrum se encontra em destaque na maioria das empresas de software. O Scrum é colaborativo e ideal em projetos pequenos com req- uisitos que mudam constantemente durante o desenvolvimento de software, pois a prática de Scrum facilita a adaptação a processos empíricos de desenvolvimento de sistemas. O framework do Scrum é formado basicamente em papéis, cerimônias e artefatos [8] com cada um fazendo parte do fluxo do processo do Scrum. Nas próximas seções serão detal- hadas o framework do Scrum e o fluxo do Scrum.
  • 5. 1.2.1.1. Papéis do Scrum O Scrum como qualquer outra metodologia é baseada em papéis e responsabilidades. Ele é dividido em três papéis: Product Owner (Cliente), o time, e o Scrum Master [8]. Cada um com sua responsabilidade. Product Owner: Pode ser o financiador ou um interessado no projeto. Representa o interesse de todos os usuários do sistema final. Suas responsabilidades são: definir as funcionalidades do produto, coleta informações vindas dos usuários, stakeholders ou do mercado para obter uma visão única dos requisitos do sistema, além disso, controla o ROI do projeto, prioriza o Product Backlog [9]. Time: É o grupo de pessoas que está fazendo o trabalho e que garantirá que o pro- jeto seja entregue com todas as funcionalidades necessárias. São multifuncionais e auto- organizáveis. Define o objetivo do sprint e especifica os resultados dos trabalhos. Forma- dos por até sete pessoas, são coletivamente os responsáveis pelo sucesso de cada interação e do projeto como um todo. A idéia de auto-organizável e multifuncional é que o time deve possuir toda a capacidade e conhecimento técnico do processo de desenvolvimento do produto. Scrum Master: É o líder, gerencia o interesse do Product Owner e treina o time. Por- tanto ele melhora a vida e a produtividade do time provendo criatividade e conhecimento. O Scrum Master também estimula a comunicação e a cooperação entre todas as pessoas do time, remove impedimentos, garante que o processo está sendo respeitado e auxilia o Product Owner a maximizar o ROI. Stakeholders (Cliente e fornecedores): Estas são as pessoas que aprovam o projeto e para quem o projeto irá produzir o benefício acordado. Eles só se envolvem no processo durante as sprint reviews. Abaixo se encontra um possível cenário alocando cada responsável indicando seus papéis e responsabilidades descritos (Veja a figura 1.2). 1.2.2. Cerimônias As cerimônias SCRUM são eventos que acontecem dentro de um ciclo de desenvolvi- mento Scrum. Existem três tipos de cerimônias Scrum: a reunião de Planejamento do Sprint, as reuniões diárias do Scrum e a reunião de revisão do Sprint. Estes eventos se caracterizam pelo ciclo de vida de cada Sprint: início, meio e fim. 1.2.2.1. Reunião de planejamento do Sprint (Sprint planning) Uma reunião planejamento da Sprint ocorre no inicio da Sprint. Tem um tempo de du- ração (Time-box) entre 3 a 4 horas é realizado no primeiro dia. Geralmente esta reunião
  • 6. Figure 1.2. Cenário dos papéis dos envolvidos no processo Scrum. Fonte: http://delicious.com/marcospereira é dividida em duas partes: Sprint Planning 1 (fase do Product Backlog) e Sprint Planning 2 (fase do Sprint Backlog). Sprint planning 1: Participam o Product Owner (PO), time e o Scrum Master (SM) que atua como mediador. A equipe realizará o planejamento para verificar qual é o Product Backlog. A equipe deve selecionar quais itens (funcionalidades), ordenados pela priori- dade, serão feitos na Sprint [10]. Sprint planning 2: Participam dessa parte o SM e o time, caso ocorra dúvida o PO pode ser consultado para planejar o Sprint baseado no Product Backlog. A equipe seleciona quais itens do Backlog serão implantados até o fim da Sprint (duração de 28 dias). Depois cada item selecionado será quebrado em tarefas menores (stories) formando o chamado Sprint Backlog. Com isso, o time fica sabendo o que é necessário ser feito para implantar os itens. 1.2.2.2. Reuniões diárias do Scrum (daily sprint) É uma reunião pública, onde só os membros do time podem fazer comentários e perguntas e dura no máximo 15 minutos. Três perguntas são respondidas nessa reunião: O que eu fiz
  • 7. desde a última reunião? O que eu vou fazer até a próxima reunião? Quais os problemas estão impedindo a realização do meu trabalho? O Scrum Master tem um papel fundamental aqui em resolver os impedimentos. Os benefícios dessas reuniões são a visibilidade do que está acontecendo para todo o grupo e ajuda ao SM a identificar os impedimentos. 1.2.2.3. Reunião de revisão do Sprin (Srpint review) É uma reunião realizada no ultimo dia da Sprint. Todos participam (PO, SM e time) e dura 4 horas em geral e serve para revisar os altos e baixos do ciclo. Aqui é apresentado o resultado do trabalho. Nesta reunião, podem ser levantadas novas funcionalidades e os stakeholders podem identificar funcionalidades que não forem entregues e um novo Product backlog é gerado [11]. Depois que esta reunião é finalizada, um novo ciclo Sprint pode começar até que todo o produto seja finalizado e o Product Backlog esteja limpo de pendências. 1.2.2.4. Sprint Retrospective É uma reunião que acontece no final de uma Sprint. Dura em média 3 horas. Partici- pam o Scrum Master, o time e o PO (opcional). Com o objetivo de detectar melhorias e documentar as lições aprendidas. 1.2.2.5. Reunião de Planejamento da Versão para Entrega (Release Planning) O propósito do planejamento da versão para entrega é o de estabelecer um plano e metas que o Time Scrum e o resto da organização possam entender e comunicar. O planejamento da versão para entrega responde às questões: “Como podemos transformar a visão em um produto vencedor da melhor maneira possível? Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?” O plano da versão para entrega estabelece a meta da versão, as maiores prioridades do Backlog do Produto, os principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse plano da versão para entrega a cada Sprint. Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um pedaço potencialmente entregável do produto completo. Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto é entregue. Muitas organizações já possuem um processo de planejamento de versão para entrega, e na maior parte desses processos o planejamento é feito no início do trabalho da versão e não é modificado com o passar do tempo.
  • 8. Figure 1.3. Product Backlog. Fonte: http://delicious.com/marcospereira No planejamento de versão para entrega do Scrum, são definidos uma meta geral e resultados prováveis. Esse planejamento geralmente não requer mais do que 15-20% do tempo que uma organização costumava utilizar para produzir um plano de versão para entrega tradicional. No entanto, uma versão com Scrum realiza planejamento no momento da execução de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma forma que realiza um planejamento diário no momento da execução de cada Reunião Diária. De forma geral, os esforços para uma versão para entrega com Scrum provavel- mente consomem ligeiramente mais esforço do que os esforços para um planejamento de versão para entrega tradicional. Planejamento de versão para entrega requer estimar e priorizar o Backlog do Produto para a Versão. Há diversas técnicas para fazê-lo que estão fora do alcance do Scrum, mas que apesar disso são úteis quando usadas com ele. 1.2.3. Artefatos Product Backlog É uma lista de funcionalidades feita pelo proprietário do produto (Product Owner) em conjunto com o cliente, que é organizada por prioridade de entrega. O time contribui estimando o custo de desenvolvimento das funcionalidades. A Figura 1.3 mostra um exemplo de product backlog: Sprint Backlog São tarefas menores formado pela quebra dos itens do Backlog. É uma lista especificando os passos necessários para implantar uma funcionalidade do sistema. A Figura 1.4 mostra um exemplo de Sprint backlog em quadro de cartolina dividido em
  • 9. Figure 1.4. Sprint Backlog. Fonte: Gerenciamento de projetos com Scrum, abril de 2007 quatro colunas. A Figura mostra o item do product backlog, tarefas que estão pendentes a fazer, tarefas alocadas para cada membro do time, e as tarefas prontas pelo time. 1.2.4. Fluxo do Scrum Nessa seção será descrito, de forma geral, como ocorre o processo Scrum no gerencia- mento do desenvolvimento de software. De início a Figura 1.5 resume visualmente todas as fases do processo do Scrum. Logo depois são apresentadas as descrições passo-a-passo de cada etapa do processo. De acordo com a figura, um projeto Scrum inicia com a visão global do sistema que será desenvolvido. O proprietário do produto é responsável por produzir esse doc- umento de forma que seja maximizado seu retorno de investimento (ROI). O Product Owner elabora a lista de itens priorizados gerando o Product Backlog, que são os requi- sitos funcionais e não funcionais do sistema. O Product Backlog é priorizado pelos itens mais desejados. Logo, os mais importantes serão entregues nas primeiras versões. Todo o trabalho é feito em Sprints ou iterações. Cada Sprint é uma interação de 30 dias consecutivos [8]. Entretanto na prática há uma flexibilidade em relação a esse tamanho, pois depende muito das características do time e do esforço para implantar o produto. Cada Sprint é iniciado com a reunião do planejamento do Sprint (Sprint Plan- ning), em que o Product Owner e o time estão juntos para colaborar sobre o que será feito na próxima Sprint. A Sprint Planning tem duração de 8 horas. Esse tempo fixo é importante para
  • 10. Figure 1.5. Fluxo do Scrum. Fonte:blog.marciel.org/?m=200909) manter ágil o processo. A Sprint Planning é dividida em duas etapas. A primeira etapa é de 4 horas com o Product Owner apresentando o Product Backlog ao time. O time pode questionar sobre as intenções de cada item do Product Backlog. Diferente nas metodolo- gias tradicionais como o RUP só uma pessoa é que faz o levantamento dos requisitos. Na segunda etapa, o Scrum Master e o time selecionam os itens mais ágeis de ser imple- mentados por meios de técnicas de estimativas de esforços como, por exemplo, técnica do Planning Poker que estima os itens pelo tamanho da complexidade [10]. Depois de estimadas, o time divide os itens em tarefas menores gerando o Sprint Backlog para cada item do Backlog que serão implantados durante a Sprint. Todos os dias terão reuniões diárias que duram 15 minutos, em que os membros do time fazem comentários e perguntas sobre como esta o andamento do projeto. Essa re- união diária usa alguns conceitos do XP, como a reunião em pé e o valor da comunicação entre a equipe. Isso traz benefícios como troca de conhecimentos entre a equipe resul- tando sincronização entre todos. Destaca-se nessas reuniões o dever do Scrum Master em resolver os impedimentos. No final da Sprint, o Sprint review é realizado com duração de 4 horas [8]. Aqui é mostrado ao product Owner de tudo o que foi desenvolvido na Sprint. Nessa reunião, podem ser levantadas novas funcionalidades e gerar um novo Product Backlog. Depois que esta reunião é finalizada, um novo ciclo Sprint pode começar até que todo o produto seja finalizado e o Product Backlog esteja limpo de pendências. Após essa prática, é feita a Sprint Retrospecive e algumas perguntas são respondidas, como: O que aconteceu durante a Sprint? O que foi bom durante a Sprint? O que poderia funcionar melhor? Essa prática traz benefício para a equipe conhecer melhor e melhorar nas próximas Sprints. Portanto juntos a Sprint Planning, Sprint Review e o Sprint Retrospective constituem uma inspeção formal e uma adaptação ao processo Scrum. 1.2.5. Estimativa de Tempo usando Planning Poker Antes de começar falar sobre estimativas, gostaria de chamar a atenção para o significado da palavra “Estimativa”. O que é uma estimativa?
  • 11. 1. Um cálculo aproximado; 2. Uma declaração por escrito do preço aproximado que será cobrado para um trabalho específico; 3. Um julgamento ou avaliação. Mais importantes, estimativas são inerentemente erradas. Estimativas não são ex- atas, e não refletem a realidade. A única maneira de saber o tempo exato que uma ativi- dade vai durar, ou quanto esforço será necessário despender para executar algum trabalho, é após a sua realização. Dito isso, vamos prosseguir a respeito do Poker Planning. Uma das maneiras mais eficientes e recomendadas de estimar o tamanho de requi- sitos em times que adotam métodos ágeis (XP/Scrurn) é o jogo de cartas conhecido como Planning Poker [14]. Este método de estimar combina opinião de especialistas, analogias e desagregação em uma aproximação eficiente para estimar de maneira rápida, porém confiável. É uma variação do método de estimativa Wideband Delphi [15]. As estimativas acontecem normalmente em uma reunião, também chamada de timeboxed (geralmente 4 ou 8 horas, dependendo da quantidade de requisitos a ser es- timada). Os participantes do jogo de poker são todos os membros do time do Scrum. O Product Owner normalmente comparece a esta reunião para prestar esclarecimentos a respeito dos requisitos, porém não pode opinar e estimar junto com o time. O Scrum Master registra os resultados da reunião, e assim como o Product Owner, não interfere nas estimativas do time. No início de uma reunião de Planning Poker, cada membro do time recebe um deck de cartas, que contém uma variação da sequência de Fibonacci: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 50, 75, 90, 100 ? e “Pausa”. Ainda no início, todos os itens a serem estimados são lidos pelo Product Owner ou Scrum Master, e a equipe conversa para decidir qual é o menor item de backlog disponível. 1.2.5.1. Gerenciamento de Projetos com Scrum utilizando Planning Poker O Gerenciamento de Projetos com SCRUM, após essas estimativas iniciais, esse item é marcado corno “2” pontos, e a equipe prossegue para estimar os demais itens de backlog. Isso serve para definir uma referência de tamanho e complexidade para ser utilizada nas demais estimativas. Isso só precisa ser definido na primeira reunião de Estimativa, e deve ficar registrado, para uso nas futuras reuniões. Em casos excepcionais, o time pode decidir mudar a estória de referência por uma outra estória. Aqui também é importante usar o bom-senso. Seguindo adiante, para cada estória a ser estimada, o Scrum Master ou Product Owner lê a descrição e os critérios de aceitação da mesma. O Product Owner responde a quaisquer questionamentos que o time possua a respeito da estória, entretanto procurando manter o nível da discussão em alto nível, e no entrar em detalhes. É comum definir também um timebox para esse tempo de Perguntas e Respostas, de modo a não se estender demais e perder muito tempo em uma única estória. Depois da apresentação e discussão
  • 12. inicial, cada pessoa seleciona sua estimativa (uma carta), baseada em sua opinião pessoal a respeito do tamanho e complexidade da estória, e a coloca em cima da mesa, com a face voltada para baixo. Quando todos os participantes selecionarem uma carta, as mesmas serão viradas ao mesmo tempo. Se houver uma grande variância entre a maior e menor carta, o time vai discutir o que cada membro estava pensando quando selecionou o tamanho. A ideia aqui é que todos entendam as razões, que mais uma ou outra pergunta sejam respondidas pelo Product Owner, e a equipe volta a pensar sobre a estória, e faz uma nova estimativa. O ciclo deve ser repetido até que todas as estimativas estejam próximas, ou que a equipe chegue a um consenso. É comum definir um limite de rodadas de poker, para evitar que as coisas fiquem muito arrastadas. Repetir até que todas as estórias estejam 100% estimadas! 1.2.6. Considerações Finais Muitas empresas desenvolvem software sem usar nenhum processo. Geralmente isso ocorre porque os processos tradicionais não são adequados às suas realidades. Em par- ticular, as pequenas e médias empresas ou organizações não possuem recursos suficientes para adotar o uso de metodologias pesadas e, por essa razão, normalmente não utilizam nenhum processo. O resultado dessa falta de sistematização na produção de software é a baixa qualidade do produto final. Devido a esse contexto, as metodologias ágeis vêm se tornando cada vez mais utilizadas pelas empresas nos últimos anos por ter uma abordagem simplificada. Está comprovado que os métodos, práticas e técnicas para o desenvolvimento de projeto ágil são adequados para situações em que a mudança de requisitos é freqüente [8]. Isso au- menta a satisfação do cliente [12], produz alta qualidade de software e diminuição dos prazos e custos de desenvolvimento [13]. Os projetos tradicionais de desenvolvimento de software não são adequados para projetos em que mudanças são freqüentes. Isso acaba atrapalhando o cumprimento de prazos, aumentando seus custos e prazos, e diminuindo a qualidade do software. Diante desse contexto, o Scrum é uma das metodologias ágeis que estão mais adaptadas a mudanças e está mais sendo usada pelas empresas de softwares. O Scrum é um processo que constrói software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita frequência. 1.3. Referências References [1] Disponível em http://www.agilemanifesto.org/ Ultimo acesso em 18/10/2009. [2] BECK, K., “Extreme Programming Explained: Embrace Change”, 1st Edition, Addison-Wesley, 1999. [3] WELLS, D, Disponível em http://www.extremeprogramming.org, Visitado em 20/09/2004; [4] SANTOS, R. Disponível em http://www.ime.usp.br/˜ daltonl/ageis/ageis_6pp.pdf g Visitado em 08/10/2009.
  • 13. [5] Disponível em http://www.javamovel.com/2009/09/scrum.html Visitado em 08/10/2009. [6] Disponível em http://pt.wikipedia.org/wiki/Scrum Visitado em 08/10/2009. [7] Asfora, Diego Maciel. “Uma abordagem para a priorização de requisitos em ambi- entes ágeis” Dissertação Mestrado, UFPE, 2009. [8] Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004 [9] Disponível em http://www.aspercom.com.br/ead/mod/resource/view.php?id=245 Visitado em 08/10/2009. [10] Disponível em http://www.companyweb.com.br/Rildo/scrum/Tutorial-SCRUM- v9.pdf Visitado em 08/10/2009. [11] Ken Schwaber. Agile Software Development with Scrum. Prentice Hall (2001). [12] BOEHM, B. and Turner, R., Balancing Agility and Discipline A Guide for the Per- plexed, Addison Wesley, 2003. [13] ANDERSON, D. J., Agile Management for Software Engineering, Applying the Theory of Constraints for Business Results, Prentice Hall, 2003. [14] Henrik Kniberg. Scrum; XP Direto das trincheiras. Ed. Enterprise Software Devel- opment Community, 2007. [15] Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi; Warsta, Juhani. Agile Software Development Method, Review and Analysis. Espoo 2002. VTT publications 478. 107p