SCRUM

SCRUM


O QUE É:

É um framework de desenvolvimento ágil, cujo trabalho é estruturado em ciclos de trabalho chamados de sprints que são iterações de trabalho que normalmente vão de duas a quatro semanas de duração.

A lista de requisitos contida em cada sprint é chamada de user stories é tratada pelo time por prioridade.

No final de cada sprint, o produto em potencial é entregue para o cliente.

PARA QUE SERVE:

É uma metodologia ágil de gerenciamento e desenvolvimento de projetos em equipe que busca como toda metodologia, a entrega do projeto no prazo e custo estipulado.

BENEFÍCIOS:

  • Entregar para o cliente aquilo que foi pedido dentro do prazo e orçamento.
  • Priorizar o impeditivo de desenvolvimento sistematicamente os removendo aumentando a produtividade e qualidade
  • Remove a pressão gerencial sobre o time de desenvolvimento os permitindo escolher e priorizar as tarefas mais relevantes para o sucesso do projeto.
  • Regras simples e descomplicadas

O FRAMEWORK:

Tree Roles (Os três papeis / cargos) e suas responsabilidades:

  • Product Owner (Detentores da idéia do Produto / Cliente)

    • Definir as características do produto
    • Definir a data de lançamento e o conteúdo que será lançado
    • Ser responsável pela lucratividade do produto (ROI – Return On Investment)
    • Priorizar características do produto de acordo com o valor de mercado
    • Ajustar características e prioridades a cada 30 dias ou quando necessário
    • Aceitar ou rejeitar trabalho realizado

  • Scrum Master

    Este é um facilitador e líder do projeto

    • Garantir que o time de desenvolvimento é completamente funcional e produtivo
    • Facilitar a cooperação entre as pessoas que exercem papeis e funções diferentes
    • Remover barreiras e impedimentos
    • Proteger o time de interferências externas
    • Garantir que o processo SCRUM (e suas definições) são seguidas a risca:

      • Scrums diários
      • Revisão de sprint
      • Planejamento de sprints
      • Etc…

      As responsabilidades extras do Scrum-Master além de conduzir os scrums diários:

      • O Scrum-Master tem que saber quais as tarefas que foram cumpridas, quais foram iniciadas, quais foram descobertas e as mudanças de estimativa de tempo. Isso faz ser possível atualizar o Burndown Chart que nos mostra o restante do trabalho acumulado dia a dia.

      • O Scrum-Master tem que ter cuidado com o número de tarefas sendo executadas concomitantemente.

      • Trabalhos concomitantes tem que ser minimizados para que se maximize pequenos ganhos de produtividade

      • O Scrum-Master tem que ajustar impedimentos para que possa ocorrer o próximo scrum. Um remendo no plano tem que ser implementado por prioridades. Alguns impedimentos são resolvidos pelo time, outros através do time e outros ainda por terceiras pessoas.

      • Por último mas não de menor importância, o Scrum-Master tem que gerenciar as pessoas que se encontram dentro do time e seus conflitos tem que ser resolvidos dentro de cada scrum.

  • The Team (O time)

    • É multidisciplinar, e contem por volta de 7 pessoas. Não mais nem menos que 2.
    • Seleciona os objetivos do sprint e especificar os resultados do trabalho
    • Tem o direito de fazer tudo dentro dos limites do projeto objetivando os objetivos do sprint
    • Organiza-se e seu trabalho
    • Demonstra resultados para o Product Owner.

Tree Ceremonies (as três formalidades):

  • Sprint Planning Meetings

    A preparação de uma scrum sprint começa quando o product owner desenvolve um plano para um produto ou projeto. O product owner pode ser um cliente ou um representante de um cliente. Para um produto comercial de uma compania, o product owner é o mercado, e quem desempenha o papel de product owner representa as necessidades do mercado. O Product Owner tem que ter uma visão financeira completa do investimento que está sendo feito no projeto. Ele prepara a lista de requisitos do cliente, e prioriza esses requisitos pela valor acrescentado em termos de negócio. Essa lista é chamada de Product Backlog.

    O Scrum se inicia quando há uma suficiente definição da lista conhecida como Product Backlog e priorizada para se iniciar o primeiro sprint de 30 dias. O Sprint Planning Meetings é usado para se determinar um plano detalhado para iteração. É iniciado com a revisão da visão, do roadmap (planejamento e agendamento), release plan (plano de liberação das partes do projeto) e o Product Backlog (que é a lista de requisitos) com todo o time. O time tem neste momento que rever as estimativas de tempo para desenvolver cada característica e determinar que essas estejam o mais próximo do real. O time decide qual quantidade de trabalho terá sucesso dentro de uma sprint baseado na quantidade de horas trabalhadas por cada membro que o compõe. É muito importante que o time priorize os itens que estão no topo da lista de prioridades, ou seja, da Product Backlog.

    Quando o time selecionou as tarefas de mais alta prioridade, o Scrum-Master conduz o time em seções de planejamento e divide as tarefas selecionadas da Product Backlog em tarefas de Sprint. Tarefas de Sprint atividades específicas de desenvolvimento e são necessárias para implementar uma característica do projeto e formar o Sprint Backlog.

    Essa fase de Sprint Planning Meeting deve levar no máximo 4 horas.

  • Daily Scrum Meeting

    Uma vez que o plano estiver completo, o Sprint de 30 dias se inicia. Cada um desses 30 dias o Scrum-Master conduz uma reunião diária de 15 minutos com o objetivo de clarificar o estado do Scrum (como anda o trabalho de cada membro da equipe.)

    Nesta reunião, cada membro da equipe deve responder a 3 questões:

    • O que eu fiz ontem?
    • O que estou fazendo hoje?
    • O que está me impedindo de realizar o trabalho?

    Somente as pessoas que estiveram comprometidas em entregar trabalho terão a permissão de falar.

    O objetivo desta reunião é ter uma visão geral do andamento do projeto, descobrir novas dependências, novas solicitações, ajustar o tempo de trabalho diário.

  • Sprint Review Meeting

    Todo final de Sprint, é necessária uma revisão do que foi feito. Para tanto, realiza-se uma reunião de no máximo 4 horas onde a primeira metade é demonstrado para o Product Owner o que foi codificado e desenvolvido neste sprint.

    O Product Owner conduz esta primeira parte da reunião e convida todos os interessados no projeto (stakeholders) a estarem presentes.

    São revistos as regras de negócio, o mercado e a tecnologia empregada.

    O Product Owner determina quais itens do Product Backlog foram realizados e como devemos priorizar os outros itens do Product Backlog para o próximo sprint para se definir os objetivos do próximo sprint.

    A segunda parte da reunião é uma retrospectiva do time liderada pelo Scrum-Master. O time avalia a forma de trabalho conjunto e identifica as coisas positivas que aconteceram e que podem se repetir no trabalho futuro. O time também identifica o que poderia ter sido melhor e desenvolve estratégias para melhorar.

    Após esta etapa o processo novamente se inicia até a próxima iteração.

Tree Artifacts (Os três artefatos):

  • Product Backlog

    Lista dos requisitos do cliente priorizada pelo valor de negócio. O time contribui para tal documento estimando o custo para cada requisito.

    Este documento deve conter requisitos visíveis para o cliente como também requisitos técnicos dos quais o cliente não necessariamente saiba.

    Os requisitos tem que ser bem detalhados e caso a expectativa de codificação ultrapasse 10 dias, podemos tentar “quebrá-la” em sub requisitos.

  • Sprint Backlog

    É um artefato da Sprint Planning Meeting. Quando o time se compromete a entregar algumas das principais características definidas no Product Backlog, essas características são subdivididas na Sprint Backlog que nada mais é do que uma lista de tarefas específicas do desenvolvimento que compõe uma característica do produto. Essas tarefas são divididas em partes que não necessitarão mais de 2 dias para serem cumpridas (ou 16 horas de desenvolvimento).

  • Burndown Chart

    É um gráfico que mostra em uma sprint o trabalho remanescente diário. No Sprint Planning Meeting o time identifica quais as tarefas que devem ser concluídas para que o sprint tenha sucesso. O total de tempo estimado de trabalho remanescente de todas as Sprint Backlog é o Cumulative Backlog. Quando as tarefas são realizadas, o Scrum-Master re-estima o tempo de desenvolvimento das tarefas remanescentes causando um decréscimo de tempo estimado para o final da sprint.

    O Sprint Backlog pode variar pelas seguintes razões:

    • O melhor conhecimento do time sobre o trabalho que deve ser feito faz com que haja a decisão de acrescentar tarefas ao Sprint Backlog para que seja completado os itens selecionados do Product Backlog

    • Defeitos podem ser identificados e documentados como tarefas adicionais.

    • O Product Owner pode trabalhar junto com o time para ajudar a refinar o entendimento do objetivo do Sprint.

    • O Scrum-Master e o time decidem que devem fazer pequenos ajustes para melhorar o valor do produto final.

      O gráfico é usado para guiar o sucesso do time de desenvolvimento a completar uma Sprint no tempo previsto que pode ser entregue como parte do produto.

Breve Histórico:

Quando Jeff Sutherland criou o processo scrum em 1993 ele emprestou o termo “scrum”de uma analogia de um estudo feito por Takeuchi e Nonaka de 1986 publicada pela Harvard Business Review. Neste estudo, Takeuchi e Nokawa compararam a alta performance e a multidisciplinaridade do time de scrum usadas pelos times de Rugby.

Ken Schwaber formalizou o processo para indústria mundial de software através da first published paper on Scrum na OOPSLA 1995. (Download Ken’s whitepaper on Scrum.)

Glossário

  • Sprint:

    • Dicionário: Corrida de Velocidade / Correr com Velocidade
    • Definição do Método:

  • Backlog

    • Dicionário: Acumular / Reserva

  • Scrum

    • Dicionário: Alinhamento de jogadores amontoados

Referência:

http://www.scrumalliance.org/pages/what_is_scrum

http://www.scrumalliance.org/articles/39 –> glossário dos termos de scrum

Anúncios
Esta entrada foi publicada em Metodologias e Processos. ligação permanente.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s