GERENCIAMENTO DE PROJETOS COM

SCRUM
Rodrigo Yoshima

Aspercom Servios de Informtica Ltda. CNPJ 02.942.579/00001-37 Autores: Rodrigo Yoshima

GERENCIAMENTO DE PROJETOS COM SCRUM Abril de 2007

Copyright 2007, Aspercom. Todos os direitos reservados. http://www.aspercom.com.br

O contedo deste texto de propriedade da Aspercom Servios de Informtica Ltda. Qualquer reproduo total ou parcial deste contedo proibida.

ndice
1. O Manifesto gil do Desenvolvimento de Software ........................................ 5 1.1. 1.2. 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. 2.10. 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. O que so metodologias geis?.............................................................. 5 Pessoas, Processos e Tecnologia .......................................................... 6 O que o SCRUM? ................................................................................ 8 Controle do Processo: Emprico x Definido............................................. 8 Papis do SCRUM................................................................................ 10 Iniciando um Projeto gil ...................................................................... 11 Estrutura do Processo SCRUM ............................................................ 13 Por dentro do SPRINT .......................................................................... 14 Planejamento do Sprint......................................................................... 15 Como um dia de trabalho do Sprint?.................................................. 18 Sprint Review........................................................................................ 21 Sprint Retrospective.............................................................................. 22 Fundamentos........................................................................................ 23 Estimando em Story Points................................................................... 23 Pontos, Velocidade e Prazo.................................................................. 24 Planning Poker ..................................................................................... 26 Estimando a velocidade........................................................................ 27 Inspeo e Adaptao das Estimativas................................................. 29

Conceitos do SCRUM .................................................................................... 8

Estimativas e Mtricas geis........................................................................ 23

ndice de figuras
Figura 1 - Adoo de Metodologias geis - Fonte: VersionOne Agile Global Survey.................. 6 Figura 2 - Tringulo Pessoas, Processo e Tecnologia ................................................................ 6 Figura 3 - Adoo do SCRUM - Fonte: VersionOne Agile Global Survey....................................8 Figura 4 - Processo de Desenvolvimento em Cascata.............................................................. 11 Figura 5 Macro-estrutura do SCRUM........................................................................................ 12 Figura 6 - Processo Iterativo ..................................................................................................... 13 Figura 7 - Estrutura de um SPRINT .......................................................................................... 14 Figura 8 - Planejamento - Parte 1 ............................................................................................. 15 Figura 9 Project Backlog Primeiro Sprint............................................................................. 16 Figura 10 - Planejamento - Parte 2 ........................................................................................... 17 Figura 11 - Sprint Backlog ........................................................................................................ 17 Figura 12 - Sprint Backlog Atualizado ....................................................................................... 18 Figura 13 - Sprint Backlog - Definio de "Pronto".................................................................... 20 Figura 14 - Sprint Review ......................................................................................................... 21 Figura 15 - Retrospectiva do Sprint........................................................................................... 22 Figura 16 Mtricas: Acerto x Tempo Investido .......................................................................... 23 Figura 17 Equipe e o Product Backlog...................................................................................... 24 Figura 18 Product Backlog Pontuado........................................................................................ 25 Figura 19 Impacto da opinio em mtricas da equipe ............................................................... 26 Figura 20 Planning Poker ......................................................................................................... 26 Figura 21 Poker, consenso e participao do Product Owner................................................... 27 Figura 22 Estimando a Velocidade no Primeiro Sprint .............................................................. 27 Figura 23 Quebrando item do Product Backlog ........................................................................ 28 Figura 24 Product Backlog Final do Sprint 1 ............................................................................. 29 Figura 25 Product Backlog Replanejado................................................................................... 29

2. Conceitos do SCRUM
2.1. O que o SCRUM?
SCRUM um processo gil e leve que pode ser utilizado para gerenciar e controlar o desenvolvimento de software utilizando prticas iterativas e incrementais. Baseado em prticas de gerenciamento j fundamentadas no Extreme Programming e no RUP, o SCRUM produz os benefcios do desenvolvimento gil com a vantagem de ser uma implementao bem simples. O SCRUM aumenta significativamente a produtividade e reduz o tempo para obter resultados, pois facilita a adaptao a processos empricos de desenvolvimento de sistemas. O SCRUM tambm foi adotado como ferramenta padro de gerncia de projetos nas metodologias MSF for Agile e OpenUP e atende aos padres CMMI e PMBOK.

Outras 15% DSDM 8% SCRUM 40%

Hbrida 14% XP 23%

Figura 3 - Adoo do SCRUM - Fonte: VersionOne Agile Global Survey

2.2.

Controle do Processo: Emprico x Definido

Muito dos processos do nosso dia a dia s so aceitos como vlidos porque aceitamos o nvel de introspeco que o processo nos oferece, isto , aceitamos o nvel de qualidade que o produto final nos proporciona. Voc aceita o processo de construo de um carro mesmo com um pequeno rudo no freio. Voc aceita aguardar at 3 minutos para ser atendido no SAC. O trnsito violento e mesmo assim no deixamos de usar o carro. Processo e Qualidade so intimamente relacionados. Quando um determinado processo no atende o nvel de qualidade que esperamos podemos dizer que o processo no funciona. Se voc no aceita aguardar 3 minutos at ser atendido no SAC automaticamente voc torna o processo de atendimento invlido. Com relao a essa qualidade, determinados processos so prescritivos, isto , possuem pontos observveis que a cada passo podem ser verificveis como vlidos. A construo de uma ponte segue um processo prescritivo. Uma linha de montagem de um produto um processo prescritivo. A forma que um cartrio funciona um processo prescritivo. Nesses processos, a cada passo que voc avana no ciclo MENOR a sua incerteza, pois voc pode avaliar aquele passo como vlido. Voc consegue avaliar a qualidade das fundaes de uma ponte e ter certeza que est caminhando na direo correta.

Uma caracterstica importante dos processos prescritivos que se caso o produto final no atenda o nvel de qualidade que voc espera o custo muito alto para reconstruir esse produto novamente ou para reparar a falha. Como exemplo, se um carro ao final da linha de produo foi montado de maneira errada praticamente impossvel coloc-lo novamente na linha para que seja produzido da maneira certa. mais barato jogar o carro no lixo e corrigir a linha de produo. O software no possui passos intermedirios que possam ser verificveis como vlidos durante o seu ciclo de vida. Quando voc captura requisitos voc no tem certeza que eles solucionaro as necessidades do negcio, quando voc elege uma arquitetura no tem certeza se ela ser suficiente, quando voc codifica soma-se a essas incertezas aspectos tcnicos e tambm com relao ao futuro (como o software ser mantido). Testes so efetuados sobre requisitos incertos e tambm nunca sabemos se os testes so suficientes. Ns s conseguimos reduzir essa incerteza quando o usurio olha a aplicao. Em determinadas aplicaes, a incerteza s reduz depois que ela est em produo a mais de dois anos! Por conta disso, chegamos declarao abaixo:

DESENVOLVIMENTO DE SOFTWARE = GERENCIAMENTO DE INCERTEZA

Quando desenvolvemos produtos de processos empricos, como o Software, maneiras empricas de gerenciamento de projeto devem ser aplicadas. O software um produto que evolui constantemente at que os objetivos de negcio sejam atingidos. Muitas vezes, simplesmente atender a requisitos no suficiente. Uma confuso constante no desenvolvimento de software a definio de retrabalho. Imagine que voc capturou requisitos com relao a uma determinada tela de pedidos e com a entidade de pedidos. Voc modelou e implementou de acordo com o que voc definiu como objetivos do seu Sprint. Voc mostra a tela para o usurio, ele gostou do que viu, mas ainda faltam algumas coisas (que podem fazer parte da prxima entrega). O fato de voc ter que mexer na tela novamente ou na entidade no significa necessariamente retrabalho e sim refinamentos. O que mostra o andamento do projeto o cumprimento desses objetivos e no o nmero de telas implementadas. Se depois, na vigsima entrega, algum conceito de negcio necessitar de mais ajustes na entidade pedido tambm no ser retrabalho, simplesmente o software amadurecendo. No considere ter que mexer em coisas j implementadas como retrabalho, principalmente se o processo gil. Essa dinmica possvel porque o PRODUTO SOFTWARE nos permite que o tratemos dessa forma. O custo para ajustar os conceitos no SOFTWARE no segue o padro de um produto de processo prescritivo. A tecnologia nos permite construir o software dessa maneira. Isso nos leva a outro conceito:

SOFTWARE = IDIA
Idias so coisas que amadurecem. bem raro uma ma cair na sua cabea e de uma hora para outra voc ter a idia completa de como resolver um problema complexo. O software assim como uma campanha publicitria, ou uma ao de marketing, ou um novo produto, algo que floresce com a participao de muitas pessoas e chega maturidade em constante inspeo e adaptao. O SCRUM uma das maneiras empricas de se controlar o gerenciamento da produo de um software baseado em alta produtividade e satisfao dos envolvidos.

2.3.

Papis do SCRUM
O SCRUM como qualquer outra metodologia baseada em papis e responsabilidades, porm, os papis do SCRUM so bem abrangentes e direcionados para um propsito comum: O SUCESSO DO PROJETO.

Product Owner
O Product Owner pode ser o financiador ou um importante interessado no projeto. Suas principais responsabilidades so: Define as funcionalidades do produto Concentra as informaes vindas de usurios, stakeholders ou do mercado de maneira que se obtenha uma viso nica dos requisitos do sistema Sua maior responsabilidade o ROI do projeto Prioriza o Product Backlog Pode alterar as prioridades fora do Sprint Aceita ou rejeita os resultados dos trabalhos

O Time (Team)
O Time mais bem definido como um grupo de pessoas do que um papel. O Time o grupo de pessoas diretamente ligadas ao trabalho a ser feito que garantir que o projeto seja entregue com todas as funcionalidades necessrias. Suas caractersticas so:

Multi-functional Formado por at 7 pessoas Define o objetivo do Sprint e especifica os resultados dos trabalhos Faz aquilo que necessrio dentro das diretrizes do projeto para alcanar o objetivo do Sprint Auto-organizvel Demonstram o resultado do Sprint para o Product Owner e outros Stakeholders

A idia por trs dos conceitos MULTI-FUNCIONAL e AUTO-ORGANIZVEL que o time deve ter a capacidade e o conhecimento tcnico sobre TODO o processo de desenvolvimento do produto. No caso de um projeto de desenvolvimento de software, o time deve ter pessoas capazes de analisar a soluo, codific-la e test-la sem necessitar de outros times ou outras pessoas.

10

SCRUM Master
O SCRUM Master desempenha um papel de liderana, gerenciando os interesses do Product Owner mediante o Time. Numa abordagem tradicional de gerenciamento de projetos, o SCRUM Master seria um Gerente de Projetos, porm, essa nomenclatura foi substituda para diferenciar o foco de liderana necessrio para que um processo emprico funcione. Um SCRUM Master eficiente deve: Melhorar a vida e a produtividade do time de desenvolvimento promovendo a criatividade e o conhecimento Estimular uma comunicao e cooperao muito prxima entre todas as pessoas do time Proteger o time de interferncias externas Remover Impedimentos ("Impediments") Garantir que o processo est sendo respeitado Convidar pessoas apropriadas para as reunies de acompanhamento (Daily SCRUM, Sprint Review e Sprint Retrospective) Remover barreiras entre o desenvolvimento e o cliente para garantir que realmente o cliente que est direcionando as funcionalidades desenvolvidas Auxiliar o Product Owner a maximizar o ROI atingindo os seus objetivos com o SCRUM Promover prticas de engenharia para que cada pedao de funcionalidade seja potencialmente implantvel.

2.4.

Iniciando um Projeto gil

comum que processos geis sejam contra atividades que seguem o processo tradicional em cascata. O processo tradicional define que todas as tarefas so encadeadas e seguem um padro linear. Esse modelo provadamente a maneira menos produtiva e mais arriscada de se desenvolver um projeto de software.

Figura 4 - Processo de Desenvolvimento em Cascata

11

Neste modelo temos uma diviso onde h precedncia e grande parte do projeto analisado, depois projetada, depois implementada e depois testada. Essa linha do tempo pode ser um prazo de dois anos. Um dos grandes problemas dessa abordagem o grande risco de no entregar software continuamente para reduzir as incertezas. Nessa abordagem, o software s fica funcional para os usurios depois de dois anos! Em dois anos os usurios j mudaram, o mercado j mudou, a concorrncia aumentou. Desenvolvimento em cascata uma abordagem arriscada para projetos de software. Em projetos de software a iteratividade primordial. De qualquer forma, todo projeto (de software ou no) necessita de uma fase inicial ou de concepo para definir exatamente o que o projeto deve resolver. Essas informaes so importantes para: 1. Definir os problemas a serem resolvidos 2. Estabelecer a viso e um escopo de alto nvel 3. Investigar a viabilidade do projeto 4. Fornecer esforo e prazo preliminares 5. Conseguir recursos como financiamento

Um problema corriqueiro em empresas de software o tempo investido para conseguir obter o esforo e o prazo. importante ressaltar que no inicio do projeto as incertezas so grandes, porm, durante o projeto os riscos vo sendo resolvidos sempre atravs de software funcionando. Investir duramente na fase de requisitos com o objetivo de refinar estimativas no funciona, pois requisitos so abstraes com grande incerteza! Mesmo que todos os requisitos sejam levantados nada garante que eles no vo mudar durante o processo. Adicionando iteraes a maneira mais indicada para refinar o esforo e o prazo, de qualquer forma, segundo recomendao do PMBOK, projetos de desenvolvimento devem ter escopo flutuante. O SCRUM tambm possui fases para definio da viso do projeto e tambm para um estudo de viabilidade. A figura a seguir demonstra a macro-estrutura do SCRUM:

Nvel Estratgico
Viso
Backlog Inicial

1.Definir os problemas a serem resolvidos 2.Estabelecer a viso e um escopo de alto nvel 3.Investigar a viabilidade do projeto 4.Fornecer esforo e prazo preliminares 5.Conseguir recursos como financiamento

Nvel Ttico

Backlog

1.Planejar Objetivos dos Sprints 2.Resolver Impedimentos 3.Liderar a Equipe 4.Promover a Comunicao

Nvel Operacional

Sprint Software Backlog Funcionando

1.Realizar Objetivos dos Sprints 2.Aplicar Boas Prticas de Engenharia 3.Adequar mudanas 4.Garantir a Qualidade

Figura 5 Macro-estrutura do SCRUM

12

2.5.

Estrutura do Processo SCRUM

O SCRUM define conceitos importantes referentes aplicao do processo no perodo do projeto. Esses conceitos fundamentam prticas importantes para definir a estratgia de inspeo e adaptao do projeto, fornecendo uma excelente visibilidade do andamento dos trabalhos, juntamente com uma importante previsibilidade do que acontecer no futuro.

SPRINT: ITERATIVO e INCREMENTAL

O processo iterativo um dos conceitos bsicos para qualquer metodologia de desenvolvimento de software cuja estratgia minimizar riscos oferecendo uma rpida avaliao dos usurios a respeito daquilo que est sendo construdo. Uma iterao um perodo de tempo fixo onde o time est trabalhando para que, ao final desse perodo, algo de valor para os usurios ou interessados seja demonstrado. Essa demonstrao importante para avaliar o andamento do projeto e tambm para inspecionar se o time est realmente compreendendo o que o produto deve fazer. No SCRUM, a iterao chamada de SPRINT. Durante esse perodo o TIME trabalha nos objetivos determinados para o SPRINT. Esse perodo de tempo pode variar, mas geralmente um perodo de 30 dias.

Sprint 1
30 dias

Sprint = Iterao
Sprint 2 Sprint 3 Sprint 4 Sprint 5 Tempo
Figura 6 - Processo Iterativo

Um projeto SCRUM composto por vrios SPRINTs do mesmo tamanho. No aconselhvel que o tamanho dos SPRINTs varie, pois um perodo de tempo fechado a melhor maneira para observar resultados, principalmente para avaliar a produtividade da equipe (veja o conceito velocidade no captulo 3).

13

TIME-BOXING: Perodo Fechado de Tempo

Outro conceito importante para as prticas do SCRUM o TIME-BOXING. Um SPRINT de 30 dias um TIME-BOX. O planejamento que ocorre no primeiro dia do SPRINT ocorre num TIME-BOX de 1 dia. As reunies dirias com a equipe devem demorar no mximo 15 minutos. Tudo que acontece dentro da metodologia SCRUM tem o espao de tempo definido e cronometrado. O TIME-BOX, como j citado, um artifcio importante para o acompanhamento. Alm disso, quando voc define um objetivo e um perodo de tempo fechado, isso fora sua equipe a se concentrar naquilo que mais importante, sem gastar tempo com coisas desnecessrias para o objetivo. O Time-boxing um pilar importante da metodologia SCRUM, pois a filosofia agregar valor de negcio num curto perodo de tempo. O Time-boxing garante que o tempo seja investido onde realmente importante para o projeto.

2.6.

Por dentro do SPRINT

Para facilitar o entendimento da dinmica do SPRINT, vamos padronizar o perodo do SPRINT em 30 dias. Um SPRINT um perodo de trabalho planejado e observvel. Nesse perodo a equipe faz tudo ao seu alcance para que os objetivos que agregam valor ao negcio do cliente sejam alcanados. Vamos verificar com mais detalhes o que ocorre durante um SPRINT.

ng 1& 2 Dia 1 Di a 2 Dia 3 Di a 4 Dia ..... .... Dia Re 28 vie w

Sprint Tempo 30 dias
Figura 7 - Estrutura de um SPRINT

A figura acima representa os dias no sentido vertical, evoluindo dentro do perodo de 30 dias. A estrutura do processo SCRUM dentro do tempo bem simples. O SPRINT inicia com um dia de

Pla nni

Re

tro spe cti v

14

planejamento que ocorre em duas partes. Neste dia, todos os envolvidos planejam quais sero os objetivos a serem finalizados nos prximos 28 dias. Nesses 28 dias a equipe est trabalhando e colaborando entre si em constante comunicao. No 30 dia do Sprint todo o trabalho da equipe avaliado juntamente ao Product Owner que pode dar novos direcionamentos ao projeto. Por ltimo, temos um momento de retrospectiva, onde a equipe discute as lies aprendidas e quais ajustes so necessrios no processo. Logo em seguida, um novo planejamento do prximo Sprint realizado, dando continuidade e fluidez construo do Software. Todos os Sprints possuem uma estrutura exatamente igual, o primeiro dia voc planeja, durante o Sprint voc cumpre o planejamento, no ltimo dia voc avalia o resultado e ajusta o processo buscando uma melhoria contnua. A simplicidade do modelo de papis, artefatos e estrutura do processo SCRUM uma das razes da sua eficcia. Para que cada um desses pontos fique ainda mais claro, vamos comentar cada um deles com mais detalhes.

2.7.

Planejamento do Sprint
O planejamento do projeto como um todo ocorre a cada planejamento de Sprint na metodologia SCRUM. Este planejamento ocorre em duas partes, cada uma delas com TIME-BOX de 4 horas.

Parte 1

Parte 2

Product Backlog Priorizado

4 horas 4 horas

Sprint Backlog

Tempo 1 dia
Figura 8 - Planejamento - Parte 1

15

Na primeira parte da reunio de planejamento o SCRUM Master rene-se com o Product Owner para verificar qual o Product Backlog. O Product Backlog um artefato do SCRUM que nada mais um documento ou planilha onde constam todas as funcionalidades de alto nvel do sistema. L esto todas as funcionalidades desejadas pelos Stakeholders ordenadas pela prioridade. Aquilo que mais prioritrio est no topo da lista, e aquilo que menos prioritrio vai para o fim da lista.

ID 1 2 3 4 5 6 7 8 9 10 11

Descrio Emitir Pedido Faturar Pedido Aprovar Pedido Integrao com ERP Cadastrar Cliente Aprovar Crdito do Cliente Cadastrar Produtos Estoque Entrada de Mercadorias Estoque Sada de Mercadorias

Sprint 1 1 1

Esforo

Concluso

Figura 9 Project Backlog Primeiro Sprint Nesta primeira parte da reunio a conversa deve focar no ROI (Retorno sobre Investimento) do projeto. O trabalho de ordenar o Product Backlog uma importante tarefa, pois o Product Owner decidir aquilo que agregar mais valor ao software para ser entregue ao final do Sprint que se iniciar amanh. Os itens que aparecem no Product Backlog so qualquer tipo de funcionalidade ou tarefa que possua um valor para o Product Owner ou ao grupo de Stakeholders que este Product Owner representa. Esses itens seguem um conceito do SCRUM chamado incremento de funcionalidade potencialmente implantvel. Uma funcionalidade potencialmente implantvel significa que quando esse item do Product Backlog for finalizado ele estar completamente funcional e resolvendo algum problema de negcio dos Stakeholders. O planejamento dos Sprints feito atravs de conjuntos de funcionalidades potencialmente implantveis, sendo que ao final do Sprint, algo funcional SEMPRE esteja sendo entregue. inadimissvel para a filosofia do SCRUM que ao final do Sprint sua equipe s entregue documentos para o Product Owner (veja o segundo princpio do Manifesto gil). Software funcionando ao final do Sprint mandatrio!

16

Parte 1

Parte 2

Product Backlog Priorizado

4 horas 4 horas

Sprint Backlog

Tempo 1 dia

Figura 10 - Planejamento - Parte 2 Na segunda parte do dia do planejamento, o SCRUM Master se rene com o time e com o Product Owner (opcionalmente) para planejar o Sprint baseado no Product Backlog criado ou atualizado. O trabalho nessa segunda parte estabelecer e firmar os objetivos do Sprint, selecionando quais itens prioritrios do Backlog sero implantados completamente at o fim dos 28 dias. Para isso, mtricas so adotadas para quantificar o esforo de cada item do Backlog a fim de estimar a velocidade da equipe (veja captulo 3). Note que importante ressaltar que o Product Owner e o SCRUM Master somente definiram a ordem das coisas, mas no cabe a eles definir os prazos. Os prazos, como boa prtica de todas as metodologias de gerenciamento de projeto, so dados pelo Time que responsvel pela parte produtiva do projeto. Aps ter selecionado quais itens potencialmente implantveis sero resolvidos neste Sprint, o Time quebra cada item selecionado em tarefas menores que podem ser cumpridas em um dia (desejvel). Esta quebra de cada item chamado SPRINT BACKLOG e o time define que cada uma dessas tarefas menores esclarece tudo que necessrio ser feito para implantar os itens do PRODUCT BACKLOG selecionados para esse Sprint. Uma das ferramentas que podem ser utilizadas para controlar o SPRINT BACKLOG um quadro em cartolina com 4 colunas conforme o descrito seguir:
Item Pendente
Refinar Requisitos Modelo de Dados Tela de Busca Prd. Tela de Pedidos Testes / Homolog

Alocado

Pronto

Emitir Pedido
Carga de Produtos

Refinar Requisitos

Tela de Faturam. Testes / Homolog

Regras de Validao

Faturar Pedido
Impresso NF

Modelo de Dados

Tela Aprovao Teste de Carga

Aprovao Automtica Testes / Homolog

Aprovar Pedido
Tela de Param.

Integrao ERP

Definir Interface Dados para Teste

Testes API Comm Testes / Homolog

Escrever Docum.

Figura 11 - Sprint Backlog

17

Este quadro montado a cada Sprint, e a idia que ele esteja visvel a cada membro do Time durante o perodo de trabalho. Neste quadro constam os itens potencialmente implantveis do Product Backlog em azul na primeira coluna Item. A coluna Pendente mostra a quebra deste item em tarefas menores com durao mdia de um dia atravs de notas em amarelo (post-its). Demonstraremos mais utilidades deste quadro durante este captulo. O que voc precisa ter em mente neste momento que itens do Product Backlog foram selecionados para serem resolvidos neste Sprint e esses itens foram quebrados em tarefas menores no Sprint Backlog. O Sprint Backlog o produto do trabalho do dia de planejamento. Ao fim deste dia, o Time j sabe exatamente aonde o esforo dos prximos 28 dias ser empregado. Toda metodologia de gerenciamento de projetos baseada em: planejamento, execuo, controle e avaliao. No SCRUM isso no diferente. O primeiro dia do Sprint investido em planejar baseado em objetivos aquilo que ser entregue aos usurios ao final do perodo.

2.8.

Como um dia de trabalho do Sprint?

Com o Sprint Backlog definido a idia que os integrantes do Time peguem tarefas para realizar. Isso consiste em retirar o post-it da coluna Pendente e coloc-lo na coluna Alocado, conforme a figura a seguir:
Item Pendente
Tela de Pedidos

Alocado
Refinar Requisitos Carga de Produtos Modelo de Dados

Pronto

Emitir Pedido
Tela de Busca Prd. Testes / Homolog

Refinar Requisitos

Tela de Faturam. Testes / Homolog

Regras de Validao

Faturar Pedido
Impresso NF

Modelo de Dados

Tela Aprovao Teste de Carga

Aprovao Automtica Testes / Homolog

Aprovar Pedido
Tela de Param.

Integrao ERP

Definir Interface Dados para Teste

Testes API Comm Testes / Homolog

Escrever Docum.

Figura 12 - Sprint Backlog Atualizado Como os itens esto ordenados de acordo com a prioridade do Product Backlog, importante que os itens no topo da lista sejam resolvidos primeiro. Se o foco resolver os itens em ordem, seria estranho que um post-it do item Integrao com ERP estivesse alocado no incio do Sprint. Uma caracterstica importante que o membro do Time quem seleciona a tarefa que ele vai fazer. Isso permite que as pessoas tenham um maior controle e comprometimento sobre o prprio trabalho, sem que algum esteja delegando tarefas repetidamente de uma maneira prescritiva. Um time multi-funcional e auto-organizvel traz um timo ambiente de trabalho e uma melhor performance no desenvolvimento.

18

Reunio Diria (Daily SCRUM)

Um evento importante que ocorre todos os dias durante o Sprint a REUNIO DIRIA. A reunio diria (Daily SCRUM) um encontro entre o SCRUM Master, o Time e qualquer pessoa interessada no projeto. As reunies dirias ocorrem num TIME-BOX de 15 minutos no mximo. comum ocorrer algumas reunies com menos de 5 minutos, porm, faa todos se concentrarem naquilo que realmente importante para que esse encontro no dure 2 ou 3 horas comprometendo a produtividade da equipe. A reunio diria so 15 minutos onde cada membro da equipe dar as suas impresses a respeito do projeto, respondendo a trs perguntas importantes:

1. O que eu fiz desde a ltima reunio diria? 2. O que eu pretendo fazer at amanh? 3. Tem alguma coisa impedindo o meu trabalho?

aconselhvel que a reunio diria ocorra todo o dia no mesmo horrio. Neste momento o SCRUM Master verifica o andamento do trabalho, observando problemas, verificando a continuidade do processo, resolvendo mal-entendidos e principalmente liderando as pessoas. Esses 15 minutos dirios so preciosos para manter a comunicao e a sincronizao do status do projeto entre os membros da equipe. A reunio diria promove a auto-organizao, um maior comprometimento das pessoas e um compartilhamento das responsabilidades. Com relao pergunta 3, o SCRUM define um conceito chamado IMPEDIMENTO.

IMPEDIMENTOS
Um impedimento qualquer tipo de problema que um membro do Time est enfrentando que impede o andamento dos trabalhos. Um impedimento pode ser um computador com defeito ou mal dimensionado para o trabalho, interferncias externas (recursos compartilhados com outros projetos), dificuldades para se comunicar com Stakeholders, dependncias com outras equipes ou projetos, falhas no processo e etc... Os impedimentos so reportados diretamente ao SCRUM Master, e o SCRUM Master responsvel por remover essas barreiras.

19

DEFINIO DE PRONTO
Um dos pontos de muita discusso a respeito da adoo do SCRUM a definio da equipe a respeito dos itens do Product Backlog finalizados. O SCRUM possui um conceito de valor agregado (earned value do PMBOK) bem agressivo com relao aos riscos. Vamos analisar a situao do Sprint Backlog abaixo:
Item Pendente Alocado
Refinar Requisitos

Pronto
Modelo de Dados Tela de Busca Prd. Tela de Pedidos Testes / Homolog

Emitir Pedido
Carga de Produtos

Regras de Validao

Refinar Requisitos

Tela de Faturam.

Faturar Pedido
Testes / Homolog Impresso NF

Tela Aprovao

Aprovao Automtica Testes / Homolog

Modelo de Dados

Aprovar Pedido
Teste de Carga Tela de Param.

Integrao ERP

Definir Interface Dados para Teste

Testes API Comm Testes / Homolog

Escrever Docum.

Figura 13 - Sprint Backlog - Definio de "Pronto" Como j foi dito, os itens mais importantes do Product Backlog so as principais funcionalidades do sistema (podendo ser casos de uso, cenrios, user stories ou outros). Se voc verificar o item Emitir Pedido, podemos chegar concluso que ele est pronto, pois no existem mais tarefas a serem realizadas para este item. O detalhe aqui que o Time, juntamente com o SCRUM Master, em concordncia com o Product Owner, devem ter a sentena daquilo que o projeto define como PRONTO. Por exemplo, comum aos desenvolvedores acharem que ao terminar a codificao a funcionalidade est pronta, porm, conceitualmente no SCRUM, uma determinada funcionalidade do Product Backlog s est pronta quando potencialmente implantvel, isto , a funcionalidade s est pronta quando tem o potencial de entrar em produo assim que o Product Owner decidir. Alguns exemplos de definio de pronto: - Funcionalidade testada no ambiente de homologao; - Funcionalidade avaliada por um Stakeholder; - Funcionalidade homologada nos ambientes MySQL e Oracle; A definio de pronto um importante aspecto para avaliao no andamento do projeto, isso porque a metodologia SCRUM no considera as funcionalidades 50% realizadas como comum nas abordagens tradicionais de gerenciamento de projeto. Para o SCRUM, um item s est pronto quando atende definio de pronto do time e o projeto s avana quando itens so dados como completamente prontos no Product Backlog. No SCRUM, 20% da codificao feita no significa nada para o andamento do projeto.

20

Esta poltica diretamente ligada viso do SCRUM com relao a objetivos. O SCRUM direcionado por OBJETIVOS e no por TAREFAS. Esta abordagem fornece uma base concreta para que o Product Owner realmente saiba onde o dinheiro dele est sendo investido de uma maneira clara. O foco em OBJETIVOS um dos pilares importantes do SCRUM. Um time que realmente segue a metodologia SCRUM planeja baseada em OBJETIVOS, executa as tarefas baseadas em OBJETIVOS e principalmente, reporta o andamento do projeto baseada em OBJETIVOS e no em porcentagens enganosas. 99% de uma funcionalidade pronta no agrega qualquer valor de negcio ao software.

2.9.

Sprint Review
O Sprint Review (Reviso) um importante ponto de inspeo da metodologia SCRUM. Esta reunio ocorre no ltimo dia do Sprint e representa o momento que a equipe e o SCRUM Master demonstram as funcionalidades potencialmente implantveis executadas para o Product Owner.

Review

$ $

Product Backlog Atualizado

Tempo 4 horas
Figura 14 - Sprint Review Conforme dito anteriormente, o desenvolvimento de software um gerenciamento de incerteza. Muitos passos no processo de desenvolvimento devem ser seguidos, porm, a funcionalidade potencialmente implantvel a nica medida real a respeito do andamento do projeto que pode reduzir essa incerteza. Quando voc demonstra a aplicao rodando para o Product Owner o sentimento de valor agregado ao investimento importante para manter a sustentabilidade do projeto e tambm para a motivao da equipe onde objetivos claros foram definidos e muitos deles (seno todos) foram implementados corretamente segundo o aval do Product Owner.

21

2.10.

Sprint Retrospective

O SCRUM um conjunto de prticas focadas em melhoria contnua do processo. O SCRUM, como um controle emprico, no prega uma rigidez do processo, ao invs, o SCRUM promove a constante adaptao das prticas mesmo durante o projeto. O processo pode mudar de um Sprint para o outro sempre buscando uma melhoria na produtividade ou qualidade do produto final. A retrospectiva do Sprint uma reunio entre SCRUM Master e a equipe onde duas perguntas so feitas:

1. O que foi bom durante o Sprint? 2. O que pode ser melhorado?

Retrospective

O que foi bom? O que pode ser melhorado?

Lies Aprendidas

Tempo 4 horas
Figura 15 - Retrospectiva do Sprint
Nessa reunio o objetivo a transparncia interna da equipe. O SCRUM Master deve avaliar friamente os pontos apresentados e prover os recursos necessrios para que as mudanas ocorram. Um dos problemas mais comuns a equipe no buscar ou no se empenhar para que essas mudanas no processo ocorram. A adaptao contnua um fundamento importante para controlar projetos crticos e esses pontos de melhorias devem ser valorizados. As lies aprendidas um fundamento em muitas metodologias de gerenciamento de projeto. Elas representam a memria corporativa e promovem uma maneira para que os projetos no sofram sempre dos mesmos problemas. Se sua empresa tem muitos projetos ou projetos simultneos essas lies aprendidas devem ser compartilhadas em toda a organizao.

22