MÉTODOS ÁGEIS – SCRUM

MÉTODOS ÁGEIS – SCRUM

INTRODUÇÃO

Scrum é um framework de desenvolvimentos de produtos baseado em métodos ágeis, busca controlar projetos visando além do escopo, custo e  prazo, observando também a qualidade e principalmente valor agregado. É baseado em pequenos times auto organizados, que possuem flexibilidade, visibilidade e adaptação do projeto, seguindo um processo interativo e incremental para o desenvolvimento do mesmo.

O planejamento pela metodologia ágil baseia seu “ release “ nos requisitos do cliente, na urgência e recursos disponíveis para o projeto, na competição existente e visão de toda a sistemática.

As fases do Scrum são:

• Pré-Jogo (definições gerais, planejamento e projeto de alto nível);
• Jogo (Sprint, desenvolvimento, integração, revisão e ajustes);
• Pós-Jogo (Fechamento);

O Scrum é recomendado quando:

• Mudanças são constantes;
• Equipe aprende ao longo do projeto;
• Complexidade e incerteza reduzem a visão do projeto;
• Colaboração é importante;

A metodologia de gerenciamento passa a ser descentralizada, contando com uma equipe de gerência “light “ e membros auto organizados.

PAPÉIS NO SCRUM

Proprietário do Produto - PO

Responsável pela preparação do produto, conhecedor dos requisitos do projeto, acompanha o desenvolvimento e fases do produto, faz a macro gerência (responsável pelos sprints, release e andamento do produto), age como mediador tratando com o cliente, possui uma equipe de apoio para disponibilizar documentação para o projeto.

Scrum Master - SM

É o facilitador, evitando interferências externas que possam a vir a prejudicar o desempenho da equipe, removendo obstáculos para permitir o trabalho eficaz, é responsável por facilitar também as reuniões identificando a necessidade das mesmas, definindo conteúdo e horários . Também auxilia o P.O.  com o Product Backlog (é uma lista contendo todas as funcionalidades desejadas para um produto, e não precisa estar completo no início de um projeto), resumidamente, o S.M. garante o SCRUM.

Membros da Equipe

Responsáveis pelo desenvolvimento do produto ou projeto, são equipes auto-organizadas e multidisciplinares que tem na colaboração a principal ferramenta de trabalho.

HISTÓRIA/USER STORIES

A História (que antecede o projeto ou produto),  descreve funcionalidades que devem gerar valor para o cliente, aponta para as necessidades do mesmo, podendo ser considerado como requisito do projeto e demonstrada como um caso de uso, onde o P.O. indica o valor agregado. No caso de Histórias Brutas (alto nível) são chamados de épicos.

A história possui três componentes:

Ator  - quem precisa da história, ou o solicitante.

Objetivo - qual é o resultado final que pretendo com essa história.

Justificativa - qual a necessidade  daquela história, qual solução ou soluções.

Lembrando que é pela a ótica do ator que a história  é elaborada. Essa história deve ser flexível, estimável, realizável em uma Sprint, testável e finalmente que agregue valor.

Esse conjunto da história gera o Product Backlog  que dão origem ao produto/projeto.

As histórias estarão mais bem detalhadas estarão em cima, e os épicos que precisão ser mais detalhados estarão embaixo.

A imagem que melhor representa é a de um iceberg , onde a história prioritária está no topo, o release na metade deste iceberg  e os épicos no fundo do mesmo, isso visão o trabalho de priorização das histórias.

COMO PREPARAR O PRODUCT BACKLOG

O Product Backlog apresenta os requisitos do projeto abordando as necessidades do cliente, nele também encontramos o conjunto de histórias que darão origem ao produto, ordenado por prioridades de implementação. O Product Backlog vai evoluir com o produto e a dinâmica do ambiente, e é de responsabilidade do P.O.

COMO FAZER O PLANNING POKER, DEFINIR SUA VELOCIDADE E PLANEJAR RELEASES.

Para tratarmos de estimativas e entregas, é preciso abordar o Planning Poker  que tem como característica o uso de cartas com pontuação baseada na série de Fibonacci.

O Planning Poker é uma técnica para estimar histórias, onde a equipe trabalha este processo com a ajuda do S.M., cada história a equipe, após discutir o problema, joga a carta que acredita representar o esforço necessário para desenvolver a história, não havendo concordância, é feito uma nova rodada de discursões e nova carta é dada, resumindo, a estimativa deverá ser encontrada por unanimidade.

A velocidade da equipe, é outro fator determinante, onde esta indica o quanto o time  consegue fazer em uma Sprint. No início a velocidade é estimada de forma aleatória com base na experiência da equipe, e ao longo do desenvolvimento esta se estabiliza. Logo esta velocidade é usada para o planejamento do time box de Sprints  e por consequência pode ser usada para o planejamento de Releases (entregas).

A Release, é uma versão do produto pronta para ser utilizada, normalmente compreende várias Sprints, onde ocorre uma demanda por planejamento específico, este planejamento também deve ser baseado na velocidade.  

PLANEJANDO UMA SPRINT

Durante os processos de rotinas teremos as seguintes reuniões:

• Planejamento I
• Planejamento II
• Reunião Diária
• Reunião de Revisão
• Reunião de Retrospectiva

(Subtópico) Planejamento I – Conteúdo abordado:

O que? (O que será feito? Qual a necessidade do cliente? )

Proposta de uma Meta para a Sprint pelo P.O.  [pic 1]

Meta é a descrito como desejo final da Sprint em termos de valor, como funcionalidade.

Após a proposta, o P.O. explica as histórias prioritárias do Backlog para a equipe e na sequência é feito o Planning Poker. Normalmente está reunião dura 04 horas para uma Sprint de 4 semanas, 02 horas para uma Sprint de 15 dias,  ao final desta reunião a equipe define junto com  o P.O. o quanto acha que conseguirá fazer, que histórias serão contempladas e qual é a meta da Sprint.