O Scrum uma framework que visa a gesto de projectos e o desenvolvimento gil de software.

. utilizado em projectos complexos projectos de requisitos variveis ou tecnologia incerta.

O Scrum uma framework na qual podem ser utilizados vrios processos e tcnicas. Baseia-se na teoria de controlo de processos empricos e efectua uma abordagem iterativa e incremental para optimizar a previsibilidade e controlar riscos.

O Scrum assenta em 3 pilares: Transparncia garantindo que os aspectos do processo que afectam o resultado devem ser visveis para quem gere o resultado;

Inspeco os vrios aspectos do processo devem ser inspeccionados com frequncia suficiente para ser possvel detectar variaes inaceitveis no processo; Adaptao necessidade de ajustar o processo ou o material que est a ser processado. Esse ajuste deve ser feito o mais rpido possvel para minimizar desvios posteriores.

Pontos de inspeco e adaptao:

1. 2. 3.

Daily Scrum Reunies de Planeamento da Sprint e de Reviso da Sprint Retrospectiva da Sprint

A framework Scrum composta por: Equipas Scrum Papeis associados:

Team Boxes Artefactos Regras

Em cada Equipa de Scrum h 3 papis:

O ScrumMaster - responsvel por garantir que o processo seja compreendido e seguido; O Product Owner responsvel por maximizar o valor do trabalho da equipa (representa o negcio e os stakeholders, define os requisitos); A Equipa quem executa o trabalho.

O Scrum Master

um papel de lder-servidor da equipa; o responsvel pela adeso da equipa aos valores, prticas e regras do Scrum; Educa a equipa, tornando-a mais produtiva e aumentando a qualidade do seu produto; Ajuda a equipa a entender a multidisciplinaridade e a auto-organizao.

O Product Owner

o responsvel por maximizar o valor do trabalho da equipa; Define as prioridades a ter em conta; responsvel pela gesto e visibilidade do Product Backlog.

O Product Owner nunca deve ser o Scrum Master.

A Equipa

multi-disciplinar - os seus membros devem possuir todo o conhecimento necessrio para criar um incremento no trabalho. Devem compartilhar o conhecimento. Na equipa no h ttulos. Tambm no h sub-equipas dedicadas a reas especializadas como testes ou anlise. auto-organizvel . O tamanho ptimo de 7 pessoas(+-2), sem incluir o Product Owner e o Scrum Master. A equipa trabalha em iteraes.

Team Boxes so eventos com durao fixa, que criam regularidade.

Evento Reunio de Planeamento da Release Reunio de Planeamento da Sprint Sprint Daily Scrum Reunio de Reviso da Sprint Retrospectiva da Sprint Realiza-se no incio da Release Realizam-se no incio de cada Sprint a cada 7-30 dias Iterao de 1 ms (ou menos) Reunio diria de 15 minutos Reviso do trabalho que est concludo e que falta concluir Reflexo sobre a sprint passada incentivo melhoria contnua

Reunio de Planeamento da Release

O plano da release estabelece: A meta da release As maiores prioridades do Product Backlog Os principais riscos Caractersticas gerais e funcionalidades Estabelece a data de entrega e o custo provveis Requer estimar e priorizar o Product Backlog para a release. possvel alterar o plano da release, a cada Sprint.

Sprint

uma iterao; Tem durao fixa; Todas as sprints utilizam o mesmo modelo de Scrum; As sprints tm como resultado um incremento do produto final potencialmente entregvel; Durante a Sprint, o Scrum Master garante que no ser feita qualquer mudana que possa afectar a Meta da Sprint; Cada sprint comea imediatamente aps a anterior.

Sprint
Cada sprint contm :

Reunio de planeamento da Sprint O trabalho de desenvolvimento A reviso da Sprint A retrospectiva da Sprint

Sprint
Cancelamento de uma Sprint

Uma Sprint pode ser cancelada antes que o seu prazo fixo tenha terminado; S o Product Owner pode cancelar a Sprint; A Sprint deve ser cancelada se a sua Meta se tiver tornado obsoleta.

O cancelamento de uma sprint raramente ocorre.

Reunio de Planeamento da Sprint

Dura 8 horas para uma sprint de 1 ms.

Tem duas partes (4 horas cada): 1 parte -decide-se o que ser feito na Sprint 2 parte - a equipa entende como desenvolver a funcionalidade

Reunio de Planeamento da Sprint

1 Parte o que ser feito
Inputs para esta parte da reunio: Product Backlog O incremento mais recente ao produto A capacidade da equipa O histrico do desempenho da equipa
.

definida a Meta da Sprint

Reunio de Planeamento da Sprint

2 Parte como ser feito

O trabalho projectado pela equipa, sendo identificadas as tarefas necessrias. As tarefas so decompostas at poderem ser efectuadas em menos de 1 dia. A lista de tarefas o Sprint Backlog. A equipa auto-organiza-se para efectuar o trabalho.

Reunio de Reviso da Sprint

Dura 4 horas (para sprints de 1 ms); Apresenta-se a funcionalidade; Tem a participao da equipa e dos stakeholders;

Reunio de Reviso da Sprint

O Product Owner identifica o que foi feito e o que no foi feito; A equipa refere os pontos positivos, os problemas que ocorreram e a forma como foram resolvidos; A equipa apresenta o trabalho; O Product Owner estima vrias datas de concluso provveis; Todo o grupo colabora sobre o que est feito e o que ser feito em seguida.

Reunio de Retrospectiva da Sprint

Dura 3 horas (para sprints de 1 ms); Realiza-se entre aps a Reviso da Sprint e antes do Planeamento da Sprint seguinte; Tem uma perspectiva de melhoria contnua: identifica-se o que correu bem e aquilo que poderia ter sido feito de forma diferente ex. composio de equipa, preparativos para reunies, ferramentas, definio de pronto, mtodos de comunicao e processos.

Daily Scrum

Dura 15 minutos; Realiza-se todos os dias, mesma hora, no mesmo local.

Daily Scrum
A cada membro da equipa so feitas 3 perguntas: O que fez ontem? O que planeia fazer hoje? H algum problema que o impea de atingir o seu objectivo? Cada resposta um compromisso!

O Scrum utiliza 4 artefactos principais:

Product Backlog uma lista prioritizada de tudo o que pode ser necessrio no produto; Sprint Backlog -lista de tarefas para transformar o Product Backlog por uma Sprint, num incremento de produto potencialmente entregvel; Release Burndown mede o Product Backlog restante ao longo do tempo de um plano de release; Sprint Burndown mede os itens do Sprint Backlog restantes ao longo do tempo de uma Sprint.

O Product Backlog e o Burndown da Release

lista de todas as caractersticas do produto; Cada item possui uma descrio, prioridade (determinada por risco, valor e necessidade) e, estimativa; o item mais prioritrio o mais urgente. O Product backlog dinmico para minimizar o rework, apenas os itens mais prioritrios necessitam de ser mais detalhados.

O Product Backlog contm os requisitos do produto - a

Release Burndown regista a soma das estimativas dos esforos estimados restantes do Product Backlog ao longo do tempo;

O Sprint Backlog e o Burndown da Sprint

O Sprint Backlog contm todo o trabalho identificado pela equipa, para alcanar a Meta da Sprint. Cada item deve ser descomposto at durao de 1 dia, ou ainda menos. O Sprint Backlog vai sendo actualizado durante a Sprint, pela equipa, e s pela equipa. Sprint Burndown o grfico da quantidade restante de trabalho do Sprint Backlog, numa dada Sprint, ao longo do tempo dessa Sprint. Deve ser acompanhado diariamente.

As Regras ligam as team-boxes, os papis e os artefactos do Scrum.

Ex. s os membros da equipa podem falar durante uma Daily Scrum.

Definio de Pronto (done)

A definio de pronto adoptada pela equipa deve estar clara para o Product Owner. O Product Owner deve poder saber se um incremento completamente pronto inclui, ou no inclui: anlise, projecto, programao, documentao e testes (sendo que os testes devero incluir testes unitrios e de integrao, bem como testes performance, estabilidade e segurana).

O trabalho pronto ser inspeccionado pelo Product Owner, no fim de cada Sprint.

Referncia

Ken Schwaber e Jeff Sutherland

Portugal mjoao.costa@hotmail.com

Maria Joo Costa

Adaptao