Evento Conjunto das Comunidades MCITPSC e BluDotNet

www.mcitpsc.com.br www.bludotnet.com.br

Patrocinadores

ApoioNão basta fazer,

é preciso saber fazer

• Fernando Ferreira

• Estudante de T.I. na UDESC

• Desenvolvedor .Net

• Twitter: @fthomm

• Blog: www.codigoecafe.com

• Comunidade:www.mcitpsc.com.br

• ferreira.sf@gmail.com/fthomm@msn.com

• Alguns artigos publicados na .Net

Magazine

Fernando Ferreira

• Scrum review

• Visual Studio Team Foundation Server

2010

• Demo

• Framework ágil de gerenciamento de

projetos

• Empírico – Conhecimento vem da

experiência

• Três pilares sustentam o processo

empírico:

– Transparência

– Adaptação

– Inspeção

• NÃO é uma metodologia

• Usado desde 1990

• Simples e resistente

– Mudança de cultura

Papéis

Product Owner

Scrum Master

Team

Cerimônias

(Timeboxes)

Sprint

Daily Scrum Meeting

Sprint Review

Sprint Retrospective

Artefatos

Product Backlog

Sprint Backlog

Burndown Chart

– O “cara” que tem a visão do produto

– Garantir o R.O.I.

– Patrocina o projeto ou representa uma

comissão que patrocina

– Deve ser uma única pessoa

– Só ele pode mudar ou cancelar itens do

backlog

• Líder facilitador

• Garantir que o Scrum está sendo

seguido

• Eliminar impedimentos

• Manter comunicação e visão clara dos

itens do Backlog para o time de

desenvolvimento

Esse “cara” não é o

Gerente de

Projetos?

Esse “cara” não é o

Gerente de

Projetos?

• Responsável pelo desenvolvimento do produto

• Desenvolvedores, Arquitetos, Testadores, Analistas de Negócios etc…

– Não é algo muito simples

– Temos muitos especialistas

– Pode ser trabalhado

• Recomenda-se fortemente que o time seja multidisciplinar

P.O.

Team

Scrum Master

• Tempo definido para o

desenvolvimento das tarefas de um

Backlog

• Pode ser de uma a quatro semanas

• Timebox (NÃO pode ser extendida)

• Quanto menor melhor

– Facilitam a inspeção e adaptação

• Tem como resultado uma versão do

produto potencialmente entregável.

• Reunião diária

• Tem que ser rápida, no máximo 15

minutos

• Basicamente os membros do dizem “o

que eu fiz e o que vou fazer”

• Avaliar o progresso na direção do

Objetivo do Sprint

• Impedimentos são expostos

• Reunião ao final da Sprint

• O Time apresenta o produto

funcionando

• Identificar problemas ocorridos durante

a sprint

• fornece um entrada valiosa para as

próximas reuniões de Planejamento do

Sprint.

• Ocorre após a Sprint Review e antes do

planejamento da próxima sprint

• É um espaço de tempo onde o time

Scrum pode avaliar o seu desempenho

• Propor melhorias

• Lista de tudo o que pode sernecessário no produto

• Nunca está completo

• Dinâmico – Muda constantemente

• Contém os requisitos, novasfuncionalidades, correções etc.

• Quanto mais importantes forem ositens, mais detalhados devem ser

• Artefato vivo

• Lista de itens retirados do Product

Backlog para compor uma Sprint

Backlog

• Lista de tarefas bem definidas para o

time desenvolver

• Irá resultar em um novo incremento no

produto

• Plataforma colaborativa para projetos

de qualquer tamanho

• Objetivo é acompanhar todas as etapas

de um projeto do início ao fim

• Ambientes Heterogêneos

• Gated Check-in – Prevenção de bugs

• Grande visibilidade do projeto através

de relatórios e dashboards

Mas o que são mesmo os processos?

• MSF for Agile 5.0

• MSF for CMMI

• Scrum 1.0

Muito Obrigado!

Patrocinadores

ApoioNão basta fazer,

é preciso saber fazer