Scrum

Recentemente, Scrum se tornou a mais popular metodologia ágil.
Scrum pode ser definido como um processo ágil para desenvolvimento de software através de curtas iterações (normalmente inferiores a 30 dias) chamadas Sprints.

O trabalho a ser feito em um projeto Scrum é listado no Product Backlog que é uma lista contendo todas as mudanças mapeadas para o produto. No começo de cada sprint, uma reunião de planejamento (Sprint Planning Meeting) é realizada, e durante a qual o dono do produto (Product Owner) prioriza o product backloge o Time (Scrum Team) seleciona as tarefas que eles se comprometem a completar durante o sprint. Essas tarefas são então removidas do Product Backlog e inseridas no Sprint backlog. O time normalmente estima o esforço de cada atividade de maneira democrática e unânime. Em geral, utiliza-se um baralho com cartas que contêm valores que são apresentados todos de uma só vez no momento de se estimar o esforço para uma determinada atividade. Se há discrepância entre valores, os membros que não concordam com a maioria têm a chance de expor os seus pontos de vista e tentar convencer os outros a mudarem de idéia. Em seguida, joga-se uma outra rodada de cartas e o processo continua até que seja obtida uma concorndância de todos em relação ao esforço estimado.
Em cada dia da condução do sprint, há uma breve reunião (daily meeting) que ajuda o time a manter a trilha na execução das atividades selecionadas para o sprint
Nesta reunião são respondidas pelos membros do time as seguintes perguntas:
  • O que você fez desde ontem?
  • O que você está planejando fazer hoje?
  • Quais são os impedimentos que estão impedindo um bom desempenho do seu trabalho?
daily meeting é organizado sempre no mesmo horário e local, tem duração máxima de 15 minutos, os participantes estão sempre de pé e todos são bem-vindos, mas somente os membros do time (incluindo oScrum Master e o Product Owner) podem falar.
Durante o andamento de cada sprint, o Scrum Master preenche diariamente um gráfico (burn down chart) que dá visibilidade para o time e clientes se o trabalho está indo conforme o planejado ou não. A figura 1 abaixo traz um exemplo de burn down chart onde a linha reta indica o planejado e a linha sinuosa mostra o andamento diário da quantidade de tarefas que faltam até a data final do Sprint.

Figura 1. SCRUM Burn Down Chart

No final de cada sprint, o time demonstra as funcionalidades que foram finalizadas em uma reunião (Sprint Review Meeting).
Os três papéis previstos na metodologia Scrum são os seguintes:
  • Time: realiza as atividades de resolução de problemas e desenvolvimento de sofware. Normalmente consiste num grupo de 5 a 9 pessoas. Os membros do time decidem como o trabalho será realizado e distribuído. Não há papéis específicos para cada membro do time e pode haver trocas de tarefas entre seus membros. Naturamente isso não impede que haja especialistas em determinadas áreas.
  • Product Owner: representa a voz dos clientes e assegura que o time trabalhe nas atividades certas sob o aspecto do negócio. O Product Owner administra o Product Backlog - uma lista de atividades ordenadas de acordo com o lucro (ou valor) que se espera que cada uma gere para o negócio. O papel exige conhecimento sobre a engenharia, marketing e processos de negócio.
  • Scrum Master: sua principal atividade é remover impedimentos de maneira a facilitar e otimizar o trabalho do time. O foco é sempre em providenciar que o time tenha as melhores circunstâncias possíveis para realizar as atividades previstas no Sprint.
Projetos Scrum têm as seguintes características:
  • Entregas Flexíveis- o conteúdo da entrega é ditada pelo ambiente.
  • Planejamento flexível - a entrega pode ser necessária mais tarde ou mais cedo do que inicialmente planejada.
  • Pequenas equipes - cada equipe não tenha entre 5 a 9 membros. Pode haver várias equipes trabalhando em um mesmo projeto.
  • Revisões frequentes - progressos são revistos tão frequentemente quanto exigidos pelos riscos e complexidades do ambiente (geralmente ciclos de 1 a 4 semanas).
  • Colaboração - intra e inter-colaboração é esperada durante o projeto.
As entregas (releases) do produto são planejadas de acordo com as seguintes variáveis:
  • Requisitos do cliente - quanto o sistema corrente necessita de aprimoramento.
  • Pressão do tempo - qual lapso de tempo é requerido para ganhar vantagem competitiva?
  • Competição - qual é a competição e o que é requerido para ganhá-la?
  • Qualidade - qual é a qualidade requerida, dadas as variáveis acima?
  • Visão - que mudanças são requeridas no estágio atual para preencher a visão do sistema.
  • Recursos - quais pessoas e recursos financeiros estão disponíveis?
Essas variáveis formam o plano inicial para um projeto de aprimoramento de software. Entretanto, essas variáveis também mudam durante o projeto. Uma metodologia de desenvolvimento deve levar em conta essas variáveis e sua natureza evolucionária.



Autor:
Anônimo
Fonte:http://knol.google.com

Seja o primeiro a comentar

Postar um comentário

Related Posts Plugin for WordPress, Blogger...
Troca de Links - Parceiros RSS Search Site no Esquillo Directorio Twingly BlogRank Teaching Blog Directory GoLedy.com Divulgue seu blog! Blogalaxia BRDTracker Directory of Education/Research Blogs Top Academics blogs Education and Training Blogs - BlogCatalog Blog Directory blog directory Blog Search: The Source for Blogs Submit Your Site To The Web's Top 50 Search Engines for Free! Sonic Run: Internet Search Engine Estou no Blog.com.pt
http://rpc.twingly.com/

  ©Trabalhos Feitos / Trabalhos Prontos - Todos os direitos reservados.

Template by Dicas Blogger | Topo