Scrum (overview)

Há algum tempo o companheiro “Fernando Zambroti” dividiu sua sapiência com alguns pobres mortais (como o esvrevente deste pequeno blog) sobre este assunto: SCRUM (não sei a causa do nome, me parece que veio de alguma modalidade esportiva … mas, isso não importa!)

Como esse termo é a “bola da vez” em quando se fala de metodologia de desenvolvimento de aplicações (ou ALM, como indica a vertente deste canal!)

Em linhas gerais, quase ´por tópicos’ este post pretende registrar o que foi aprendido com o Fernando nessa ocasião…

O  que conhecemos de modelo de gerenciamento de projetos?

Quase todos os modelos se assemelham em maior ou menor grau ao Modelo Waterfall (cascata) e as principais notícias de projetos de software são variações de:

 

  • Problemas nas estimativas (justificam o atraso do projeto!?)
  • Prazos não cumpridos com justificativas de que os “prazos são apertados ou insuficientes” – o que remete ao item anterior!?
  • Mudança de escopo (as necessidades mudam com o decorrer do projeto…)
  • Equipe sempre acredita que vai dar tempo (essa é a pior das crenças!)
  • Mas… o Aviso de que não vai dar tempo normalmente ocorre no último dia, quando não no último minuto antes da previsão de entrega)
  • Cada integrante tem responsabilidade com a “sua parte” – (sempre sobra para alguém!)
  • Teoricamente tem outras pessoas olhando para as demais tarefas – (retórica? ou prática?)

Em resumo, o que se têm é a sequência fatídica (death’s fall!?)

Planejamento

Desenvolvimento

Entrega (onde o problema aparece!)

 

O que é vivenciado em projetos de software?

 

  • O Processo de desenvolvimento de software normalmente tem uma complexidade muito elevada;
  • A forma de execução das atividades é fortemente dependente do executor pois exigem atividades racionais;

Desenvolvimento de Software não é “commodity”

O que isso significa?

Construir uma aplicação não é  tão “simples” como construir uma Casa.

Quase todas as Engenharias nasceram de processos empíricos (experimentação, tentativa + erro), e a Engenharia de Software também segue este padrão.

Acontece que, as demais engenharias (e digo agora especificamente a Engenharia Civil) acompanha a humanidade desde que os nossos ancestrais biológicos sairam das cavernas e começaram a construir suas residências. O tempo de maturidade de uma Engenharia Civil, por exemplo, a coloca na posição de “commodity” dada à sua maturidade e a sua curva de evolução (que hoje depende mais de novos materiais e suas técnicas de aplicação do que da Engenharia propriamente dita!).

A Engenharia De Software, por sua vez, tem no máximo uns 50 anos de existência. Se colocarmos as existências das duas Engenharias citadas numa proporção de linha de tempo na escala de duração de um jogo de futebol A Engenharia Civil surgiu logo após o apito inicial do jogo equanto a Engenharia de software surgiu apenas alguns milisegundos antes do juiz apitar o fim da partida!

Ou seja, o principal problema a ser resolvido pela EngSW é a Gestão de

  1. Processos empíricos que normalmente são …
  2. Complexos, caóticos, ou com muita incerteza. E que demandam
  3. Atividades ciclicas com durações variáveis agregadas às
  4. Dificuldades em estimativa de tempo.

Como o Modelo SCRUM pretende endereçar isso?

A Visão SCRUM é direcionada à Gestão de Processos Empíricos onde são fixados alguns parâmetros tais como:

 

  • Parametros de contexto
  • PRAZO (fixado, mas não é o prazo final do projeto) – é o que veremos a seguir com o nome “SPRINT”.
  • ESFORÇO
  • EQUIPE (ESTRUTURA)
  • Parametros de saída
  • Objetivo
  • Critério de avaliação
  • Parametro de entrada fixo
  • Backlog. (lista das atividades)
  • Prioridades.
  • Estimativa.

Para isso, o alicerce da metologia SCRUM é a tática do JACK (ou do Napoleão, como quiserem!) “Dividir para conquistar”. O projeto inteiro passa a ser divididos em entregas parciais em espaços de tempo fixos e recorrentes onde, em cada intereação (ou SPRINT) é a plicado o …

Modelo  PDCA

Planejamento (PLAN)

Sprint planning

Fazer (DO)

SPRINT

Verificar (Check)

Sprint Review

Agir (Act)

Sprint Restrospective

 

 

 

O foco nas entregas parciais, totalmente funcionais nos sprints é o que permite realizar as entregas de maior valor agregado para o cliente, conforme as prioridades determinadas por ele.

 

Palavra de ordem : gerenciamento da expectativa! 

Em síntese:

  • As necessidades de negócio geram o Backlog.
  • 80% do valor de negócio está em aproximadamente 20% das atividades
    • Isso significa Priorizar as atividades que são mais importantes.
  • O Escopo completo é dividido em escopos menores que caibam nos SPRINTS sendo que
  • Os escopos por sprint são minimalistas
    • e a Decisão técnica fica ao encargo da equipe.
  • Os riscos podem ser minimizados através da definição de:

 

                    • Critérios de aceite.
                    • Premissas
                    • Experiência de equipe

 

  • Refactoring (possível para o próximo sprint)

 

 

 

 

 

SCRUM FRAMEWORK

PAPEIS: (não confundir com CARGO!)

  • Product owner

    PO

    É o cara (não é o cliente)  é o que está do lado do cliente.

    Faz o levantamento dos requisitos, montar o backlog, é o equivalente ao analista de negócios.

    Características dos produtos

    Gerenciar o backlog e priorizar.

    Responsável pelo “ACEITE” do entregável da equipe.

    Faz a análise do ROI (Revenue of Investiment)  para cada item do backlog.

    Responsável pela Entrega

    Scrum Master

    SM

    É o cara da equipe cuja principal responsabilidade  é fazer com que a metodologia esteja sendo aplicada no projeto

    Atualização de quadro

    Impedimentos (remoção dos …)

    Execução das reuniões (condução)

    Team

    T

    Equipe de trabalho. – normalmente 7 pessoas em média (+- 2). De 5 a 9 pessoas. Um número excessivo de pessoas pode tornar o processo improdutivo. Não existem papeis pré definidos. A liderança normalmente é suscitada naturalmente. (MERITOCRACIA).

 

Não existe nenhuma entidade regulamentadora que define  os padrões scrum. (e essa é a melhor parte!)

 

Quais são os eventos (ou cerimônias) que ocorrem em um SPRINT?

Sprint Planning

  • estimativa(P1)
  • planejamento (P2)

Início do sprint

Todos participam.

PO olha o backlog e prioriza.

A equipe estima o prazo (P1) – estimativa de complexidade – o que é mais importante e o que é mais fácil para desenvolver (menor complexidade).

Na reunião de planejamento (P2) os itens de backlog estão priorizados e com a complexidade definida. Nesta reunião ocorre o comprometimento com a entrega no sprint atual.

Neste caso, a equipe elenca os artefatos que serão entregues no fim do sprint e define o OBJETIVO do sprint que não representa necessariamente  o total das entregas realizadas.

–> Objetivo é norteado por necessidades de negócio.

 

Sprint Review

Fim do sprint

A equipe faz a entrega para o PO que formaliza o Aceite, faz a devolução de itens ao backlog (Product Backlog) e reprioriza o BackLog.

A equipe pode ser reformulada (se necessário)

Sprint Retrospective

Fim do sprint

Parecido com o “Lessons Learned” do PMBoK

Daily Scrum Meeting

diário

Checkpoint diário rápido de acompanhamento. Normalmente conduzida pelo SM com a equipe e o PO.

 

ARTEFATOS:

Product backlog

 

Necessidades de negócio a serem atendidas (ao longo de todo o projeto)

Sprint backlog

 

Tarefas (relacionadas a cada product backlog)

Burndown charts

 

Relatório de acompanhamento do Projeto.

 

E quanto à ESPECIFICAÇÃO?

O conjunto de detalhes está embutido no entendimento das funcionalidades, que são mapeadas através dos “User stories”.

  • Pode haver um conjunto de tarefas inerentes à um user histories.
  • As user hstories podem ser quebradas em user stories mais específicas
  • (a história original morre, neste caso)
  • O Product backlog é o conjunto de user stories.
  • Product Backlog Item = user story

 

Uma boa história deve ser…

  • Independente
  • Negociável
  • Valorizável
  • Estimável
  • Pequeno
  • Testável

Assim, o SCRUM endereça o desenvolvimento de software com base em 2 princípios fundamentais para conseguir o sucesso no desenvolvimento de software:

  • Planejamento Estratégico
  • Trata do “negócio” para a empresa
  • Planejamento Tático
  • O que será feito para que o planejamento estratégico seja efetivado (realizado)

Mas… e sobre as estimativas?

Há uma técnica de definição de complexidade utilizada para as estimativas, com base em  valores de uma “série de fibonacci” (o que é, no SCRUM chamado de story points) mas isso vai demandar um post específico para este assunto.

Parece que eu já vi esse filme (será um remake?)

Provavelmente você, meu caro leitor, deve ter identificado alguns elementos comuns da metodologia SCRUM com o que se chama “Extreme Programming”, Agile, … e isso não é mera coincidência. O cerne principal dessa metodologia é justamente a mola mestra denominada “Desenvolvimento Interativo”.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s