Como estou iniciando com Scrum resolvi compartilhar o que acho de mais interessante (importante). É fato que já tem amplo material na Internet, mas tem algumas coisas que merecem ser repetidas para que a propagação seja “amplificada”.

Scrum

Scrum é um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possí­vel.

Scrum é uma framework iterativa e incremental para o desenvolvimento de qualquer produto ou gerenciamento de qualquer trabalho.

Sprint

Em Scrum uma iteração chama-se Sprint.

Uma Sprint é um time-box, geralmente com duração entre duas a quatro semanas.

O produto evolui em uma série de “Sprints”;

Papéis

Product Owner

O Product Owner é alguém equivalente a um Gerente de Produto.

É o responsável por conhecer bem as necessidades do cliente (pode ser o próprio cliente ou um representante)

Define as funcionalidades do produto;

Ajusta funcionalidades e prioridades;

Aceita ou rejeita o resultado dos trabalhos.

ScrumMaster

Representa a gerência para o projeto

O ScrumMaster é o responsável por remover os impedimentos do time.

É ele quem protege o time de interferências externas, além de garantir o uso correto de Scrum

Team

Desenvolvedores, arquitetos, designers, enfim, todos os que participam do desenvolvimento são os membros do time.

Cerimônias

Planning Meeting

A equipe seleciona itens do Product Backlog com os quais compromete-se a concluir

O Sprint Backlog é criado

Daily Scrum

Não é para a solução de problemas

Ajuda a evitar reuniões adicionais desnecessárias

Todos em pé e no máximo 15 minutos;

O que fizeste ontem? O que vais fazer hoje? Há algum obstáculo?

Sprint Review

Ao término da Sprint, o time apresenta o que foi produzido na Sprint em uma reunião

A apresentação é feita no formato de demonstração e podem comparecer qualquer pessoa interessada

Sugestões podem ser feitas e cabe ao Product Owner adicioná-las ao Product Backlog ou não

Todos os membros do time participam da demonstração

Sprint Retrospective

Periodicamente, observe o que funciona e o que não funciona

Feita após cada Sprint, serve para discutirem o que foi bem na Sprint e o que precisa ser melhorado para a próxima

Artefatos

Product Backlog

Os requisitos de software são listados em um “Product Backlog”.

Uma lista de todo o trabalho desejado no projeto.

Idealmente, na forma em que cada item tenha seu peso de acordo com a vontade do cliente ou usuários.

Priorizado pelo dono do produto.

Durante o projeto, esta lista pode receber novos itens, ter itens removidos ou repriorizados, sempre de acordo com as necessidades do cliente.

Sprint Backlog

O Sprint Backlog contém os itens que serão feitos durante a Sprint, e diferente do Product Backlog, esta lista não pode ser alterada.

Cada indiví­duo escolhe o trabalho que fará.

Atualização diária da estimativa do trabalho restante

Gráfico de Burndown

O gráfico de Burndown apresenta o trabalho cumulativo restante em uma Sprint, atualizado diariamente.

Considerações finais

As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade.

Ao calcular o tempo de desenvolvimento de qualquer coisa, temos que dobrá-lo. O programador precisa de “tempo para pensar” além do “tempo para programar”.

Referências

http://www.adaptworks.com.br/scrum/

http://www.mountaingoatsoftware.com/system/hidden_asset/file/52/PortugueseScrum.pdf

http://www.brod.com.br/?q=search/node/Scrum

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches