Scrum permite criar produtos melhor adaptados às necessidades dos clientes de forma ágil, reduzindo o excesso de formalidade que pode limitar o progresso dos projetos. Praticar Scrum traz benefícios como comprometimento, motivação e integração para as equipes, facilitando o gerenciamento e sucesso dos projetos.
1. 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
jocemarfg@gmail.com
Outubro / 2008
2. 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)
3. Abordagem Ágil
Desenvolvimento 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;
4. 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”.
5. 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
6. 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
7. 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;
8. 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”
9. 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.
12. 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
13. SCRUM: Papéis e Responsabilidades
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.
14. SCRUM: Papéis e Responsabilidades
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;
16. 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;
17. 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.
18. 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
19. SCRUM: Cerimônias
Planejamento
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ócio
Condições
de negócio
Capacidades
da equipe
Capacidades
da equipe
Product
backlog
Product
backlog
Tecnologia
Tecnologia
Produto
atual
Produto
atual
20. 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
21. 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?
22. 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.
23. SCRUM: Cerimônias
Aprendendo 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;
24. 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…
25. 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
26. 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
27. 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?
28. Gerenciando projetos de maneira ágil
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...
29. Gerenciando projetos de maneira ágil
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!
30. Gerenciando projetos de maneira ágil
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...
31. Bibliografia
Mike Cohn
mike@mountaingoatsoftware.com
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