gerenciamento ágil de projetos com scrum

Gerenciamento Ágil de Projetos com SCRUM

A melhor forma de ser ágil é construir somente o que o cliente valoriza e não mais que isto. O excesso de formalidade pode limitar o progresso do projeto, mas por outro lado, o caos total, sem a utilização de processos pode impedir que se alcancem os objetivos do projeto. Scrum permite criar produtos melhor adaptados à realidade do cliente de forma ágil.

Praticar Scrum nos projetos traz grandes benefícios para a equipe como comprometimento, motivação, colaboração, integração e compartilhamento de conhecimento, o que facilita em muito o gerenciamento e sucesso dos projetos.

Jocemar Ferreira Garcia

[email protected]

Outubro / 2008

Abordagem Ágil

Manifesto Ágil: “Estamos descobrindo maneiras melhores de desenvolver

software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e

ferramentas Produto em funcionamento mais que documentação

abrangente Colaboração com o cliente mais que negociação de

contratos Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

(http://agilemanifesto.org)

Abordagem ÁgilDesenvolvimento Iterativo

Uma iteração é um “pacote de tempo” que possui um custo fixo e um conjunto de funcionalidades que pode variar;

As funcionalidades que farão parte de uma iteração são priorizadas pelo cliente;

Iterações podem perder funcionalidades, mas nunca datas;

Cliente entende que prioridades no “final da lista” podem ficar de fora e/ou eles podem adicionar funcionalidades;

Flexibilidade está nas funcionalidades, não no prazo ou no custo;

O que é SCRUM?

É uma abordagem ágil para o gerenciamento de projetos. Fornece práticas que ajudam gerentes a tornar mais dinâmico e gerenciável o ambiente de desenvolvimento de software.

Permite a rápida e contínua inspeção do software em produção (em intervalos de duas a quatro semanas).

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.

Entre cada duas a quatro semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um “Sprint”.

Quem usa SCRUM?

Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Globo.com

Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

Scrum tem sido usado para:

Software comercial Desenvolvimento interno Desenvolvimento

contratado (terceirização) Projetos de preço fixo Aplicações Financeiras Aplicações certificadas pela

iso 9001 Sistemas embarcados Sistemas disponíveis 24x7 Desenvolvimento por

hackers solitários

Vídeo games Sistemas para suporte à

vida Sistemas para controle de

satélites Websites Software para handhelds Telefones celulares Aplicações para redes Aplicações de ISV

(Independent Software Vendors)

Algumas das maiores aplicações em produção

Por quê SCRUM?

Scrum é bastante objetivo, com papéis bem definidos, de fácil adaptação e ainda, sua curva de aprendizado é relativamente baixa.

É usado em trabalhos complexos nos quais não é possível prever tudo o que irá ocorrer e oferece um framework e um conjunto de práticas que torna tudo visível.

Permite aos praticantes do Scrum saber exatamente o que está acontecendo ao longo do projeto e fazer os devidos ajustes para manter o projeto se movendo ao longo do tempo visando alcançar os seus objetivos.

Scrum é uma abordagem para desenvolvimento de sistemas e produtos onde os requisitos sofrem constantes mudanças;

Scrum é uma forma de otimizar a comunicação do time e favorecer a cooperação;

Scrum é escalável para pequenos projetos e grandes corporações;

SCRUM: Características

Equipes que se auto-organizam

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

Os requerimentos são listados em um “Product Backlog”

Não há prática de engenharia prescrita (o Scrum adequa-se a todas)

Usa regras generativas na criação de um ambiente ágil para a entrega de projetos

É uma das “metodologias ágeis”

SCRUM: Como Funciona?

O ciclo de vida do Scrum tem o seu progresso baseado em um série de iterações bem definidas, chamadas Sprints.

Antes de cada Sprint, realiza-se uma Reunião de planejamento (Sprint Planning Meeting) onde o time (equipe) de desenvolvedores tem contato com o cliente (Product Owner) para priorizar o trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro da Sprint.

A próxima fase é a Execução da Sprint. Durante a execução da Sprint, o time controla o andamento do desenvolvimento realizando Reuniões Diárias Rápidas (Daily Meeting).

Ao final da Sprint, deve-se realizar uma Reunião de Revisão (Sprint Review), onde o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido.

Logo em seguida, realiza-se a Reunião de Retrospectiva (Sprint Retrospective), uma reunião de lições aprendidas, com o objetivo de melhorar o processo/time e/ou produto para a próxima Sprint.

SCRUM: Ciclo de Vida

SCRUM: Papéis e Responsabilidades

O Product Owner representa o cliente ou patrocinador do projeto, e faz parte do time que entregará o produto. Sua função é levantar requisitos, gerenciar e priorizar o product backlog (lista de funcionalidades), aceitar o software ao final de cada iteração.

Define as funcionalidades do produto

Decide datas de lançamento e conteúdo

Responsável pela rentabilidade (ROI)

Prioriza funcionalidades de acordo com o valor de mercado

Ajusta funcionalidades e prioridades

Aceita ou rejeita o resultado dos trabalhos


A função do SCRUM Master é cuidar da equipe, trabalhar com o product owner, remover impedimentos, manter o processo funcionando.

Representa a gerência para o projeto e permite que o time seja auto-gerenciável;

Responsável pela aplicação dos valores e práticas do Scrum

Remove obstáculos

Garante a plena funcionalidade e produtividade da equipe e a colaboração entre os diversos papéis e funções

Escudo para interferências externas

Garante que o time esteja totalmente funcional e produtivo.


A função da Equipe (TEAM) estimar o tamanho dos itens do backlog, assumir compromisso com a entrega, autoorganizar-se.

Um membro do time é alguém que esteja comprometido a fazer o trabalho necessário para atingir a meta de uma sprint. Em Scrum não temos arquitetos, testers ou programadores, temos sim, membros com perfis de arquiteto, de tester ou de programador...mas que podem atuar em papéis secundários para garantir o alcance da meta.

Suas responsabilidades são:

Definir a meta da sprint e estar comprometido com o trabalho e com a alta qualidade;

Trabalhar seguindo a visão do produto e meta da sprint e colaborar com outros membros do time e ajudar a torná-lo auto-gerenciado;

Estimar os itens do backlog e garantir o esforço necessário para que as estimativas sejam realistas;

Participar das reuniões diárias e manifestar impedimentos;

SCRUM: Processos e Metodologia

•Product backlog•Sprint backlog•Burndown charts

•Dono do produto•ScrumMaster•Equipe

Papéis

•Planejamento•Revisão•Retrospectiva•Reunião diária

Cerimônia

•Product backlog•Sprint backlog•Burndown charts

Artefatos

SCRUM: Sprints

Projetos Scrum progridem em uma série de “sprints” (iterações)

Ocorre em um período de duas a quatro semanas

Um período constante leva a um melhor “ritmo”

O produto é projetado, codificado e testado durante o sprint

O conceito de Sprint nos remete à necessidade de estarmos frequentemente entregando algo de valor para o cliente. Diferentemente dos modelos “tradicionais”, onde você desenvolve o produto em um longo período de tempo e, apenas no final – com o produto “pronto” - o entrega ao cliente, em Scrum você sempre entregará “parte” do produto em pequenos intervalos de tempo, sendo que esta “parte” é a prioridade do cliente, ou seja, o que ele realmente está precisando naquele momento;

SCRUM: Artefatos

O Product Backlog contém uma lista de itens priorizados que incluem tudo o que precisa ser realizado, que possa ser associado com valor de negócio, para a finalização do projeto, sejam requisitos funcionais ou não. É importante ressaltar que cada item no Backlog do produto deve ter um valor de negócio associado (Business Value), onde podemos medir o retorno do projeto e priorizar a realização dos itens.

SCRUM: Artefatos

No Sprint Backlog cada indivíduo escolhe o trabalho que fará: trabalhos nunca são atribuídos

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

Qualquer membro da equipe pode adicionar, apagar ou mudar tarefas

O trabalho aparece a partir do Sprint

Se uma tarefa não é clara, defina-a como um item com uma quantidade maior de tempo e subdivida-a depois

Atualize as coisas a serem feitas na medida em que se tornam mais conhecidas

SCRUM: CerimôniasPlanejamento

Priorização

• Análise e avaliação do product backlog• Objetivo do sprint

Plano

• Decidir como chegar ao objetivo (projeto)• Cria tarefas do sprint

backlog a partir dos itens do product backlog (user stories / funcionalidades)• Horas no sprint backlog

Condições de negócioCondições de negócio

Capacidades da equipe

Capacidades da equipe

Product backlogProduct backlog

TecnologiaTecnologia

Produto atual

Produto atual

SCRUM: Cerimônias

A Sprint Planning Meeting ou Reunião de Planejamento, é dividida em duas partes, e entra em cena no início de cada Sprint.

Além de todos os comprometidos (PO, SM e Time), alguns envolvidos podem ser convidados a participar em determinados momentos da reunião, desde que agreguem valor à mesma e tenham seu convite aprovado pelo Product Owner.

O Sprint Backlog é criado Tarefas identificadas e estimadas (1 a 16 horas) De forma colaborativa, não apenas feito pelo ScrumMaster

SCRUM: Cerimônias

Uma vez que a Sprint tenha sido iniciada, emerge então uma das principais práticas do Scrum: as reuniões diárias (Scrum Daily Meetings);

Uma Scrum Daily Meeting é uma reunião diária, com duração exata de 15 minutos, que devem sempre ser realizada no mesmo local e horário e sempre com a participação do Scrum Master (facilitador) e dos membros do time;

Cada membro deve relatar ao time sobre os progressos e obstáculos que vem encontrando em seu caminho. Em suma, três perguntas devem ser respondidas por cada um deles:

1. O que fiz (quanto andei) desde a última reunião diária?

2. O que pretendo fazer (quanto andarei) até a próxima reunião diária?

3. Estou encontrando impedimentos? Quais?

SCRUM: Cerimônias

Após a finalização de uma Sprint, é hora de realizar a Sprint Review;

Aqui deveremos avaliar: O que estou entregando? O que eu deveria estar entregando? Nesta atividade a equipe irá realizar uma apresentação do produto que foi gerado (incrementado) durante a Sprint, focando nas tarefas do Sprint Backlog;

Participam da Sprint Review o Product Owner, o Scrum Master, os membros do time, clientes, stakeholders, executivos, e qualquer pessoa que esteja interessada no resultado da Sprint;

Esta apresentação dura normalmente entre 30 minutos e 1 hora e deve ser realizada no formato de demo, ou seja, Power points são completamente dispensáveis;

Qualquer participante da Sprint Review deve ser encorajado a realizar perguntas e fornecer sugestões.

SCRUM: CerimôniasAprendendo com os acertos...mas principalmente com os erros

A Sprint Retrospective é uma das ferramentas mais importantes para que você obtenha sucesso com Scrum;

Esta é a oportunidade que o time tem para discutir sobre o que funcionou e o que não funcionou durante a Sprint;

Product Owner, Scrum Master e os membros do time devem participar da retrospectiva. Uma boa estratégia é convidar alguém neutro para facilitar a sessão;

A estrutura da Sprint Restrospective é bem simples. Divida um quadro branco ou poster em duas áreas com os seguintes títulos: “O que funcionou bem?” e “O que pode ser melhorado?”. Após isso, cada membro deve colocar post-its em cada uma das áreas indicando os itens que, em sua opinião, merecem estar ali;

Então, o time visualiza os itens citados, discute sobre e planeja ações a serem tomadas para a próxima Sprint;

SCRUM: Iniciando sua aplicação...

Você quer aplicar o SCRUM? Não sabe como?

Comece com as daily meetings.

Defina um product backlog.

Torne o projeto “time boxed”.

Depois crie um taskboard.

Realize retrospectivas.

Sinta a diferença…

Cenário do Mundo da Informática

Organizações desorganizadas Resistência a mudanças

Cultura autocrática

Falta de processos definidos...

Excesso de processos definidos!

Demandas ao invés de projetos

Pessoas desmotivadas

Choque de gerações

Desalinhamento com os objetivos

Comunicação ineficiente

Cenário do Mundo da Informática

Particularidades Projetos de TI normalmente possuem estas particularidades

Ambiente de constantes mudanças (tecnológicas, mercadológicas, etc)

Necessidade de constante (re)planejamento

Expectativas dos clientes são altas!

Necessidade de padronização e retenção de conhecimento

Essencialmente dependentes de pessoas

Equipes que irão desenvolver

Clientes que irão trazer suas necessidades e, lógico, financiar

Gerenciando projetos de maneira ágil

Para o cliente só importa uma métrica Produto entregue e com qualidade Definição de “funcional” depende de cada equipe:

Por exemplo: produto criado, testado, documentado e aprovado pelos envolvidos.

Qualidade deve ser INEGOCIÁVEL!

Quebra de paradigma: Esforço x tempo

Por que gerar valor só no final?


Não existe projeto sem planejamento!

Ao planejar definimos onde queremos chegar e quais são os passos necessários

Mas...

O planejamento nunca será totalmente correto, ainda mais por longos períodos!

Seguir cegamente o planejamento normalmente resulta em falhas e pode nos levar a falhar tardiamente...


Mudança de escopo é uma verdade absoluta em projetos

Seja por variáveis internas (desejos) ou externas (mercado)

Prioridades mudam!

Precisamos aceitar isso e jogar conforme as regras

Minimizar as incertezas, criando ciclos de desenvolvimento de curta duração

Se necessário, mudar processos e se for inevitável, falhar mais cedo!


Projetos de TI

Sabendo que (relembrando):

Ambiente de constantes mudanças (tecnológicas, mercadológicas, etc) Necessidade de constante (re)planejamento Expectativas dos clientes são altas! Necessidade de padronização e retenção de conhecimento Essencialmente dependente de pessoas

Que tal pensar em uma abordagem diferente?! Planejar ciclos menores de desenvolvimento Valorizar as pessoas Inspecionar as atividades realizadas no período Adaptar o processo para melhorá-lo Replanejar com base nestas adaptações propostas e reiniciar o ciclo...

Bibliografia

Mike Cohn [email protected] www.mountaingoatsoftware.com

Flávio Stteffens http://mudandoumapequenaempresa.blogspot.com

Alexandre Magno http://amagno.blogspot.com

Paulo Pereira, Paula Torreão, Ana Sofia Marçal Entendendo Scrum para Gerenciar Projetos de Forma

Ágil

gerenciamento ágil de projetos com scrum

Technology