Professional Documents
Culture Documents
com\alisonrabelo
Programa
I. Gerenciamento de Projetos
II. Projetos de Desenvolvimento de Software
III. Métodos Ágeis de Desenvolvimento de Software
IV. Gerenciamento Ágil de Projetos
V. Scrum
VI. Regras do Scrum
1
Parte I
Motivação
Cenário mundial
Concorrência global
Maior exigência por qualidade
Menor tempo para desenvolvimento de produtos
Recursos limitados
Grandes redes de informação e fornecedores atuando
globalmente
2
Projetos
“Cerca de 2 milhões de pessoas estão
trabalhando em 300 mil projetos de
software nos Estados Unidos. Entre 1/3 e
2/3 destes projetos excederão seus
prazos e orçamentos antes de serem
concluídos. Dentre os mais caros projetos
de software, cerca de 1/2 eventualmente
serão cancelados por estarem
completamente fora de controle.”
Software Project Survival Guide
3
Projetos
Projetos
são únicos e finitos, isto é, tem início e fim.
“Um projeto é um esforço temporário para criar um
produto ou serviço único.”
Projetos
Características de um projeto:
Elaboração Progressiva:
característica de projetos que integra o conceito da
temporariedade e particularidade;
conceito de elaboração do projeto por etapas ou incrementos
iterativos;
distingue as fases de um projeto.
Temporário
significa possuir um início e um fim definido.
4
Projetos
Exemplos de Projetos:
Desenvolvimento de um novo modelo de veículo;
Construção ou reforma de um prédio;
Uma campanha para um cargo político;
Organização de um evento, como uma feira de negócios,
um show, entre outros;
Desenvolvimento ou aquisição de um Sistema de
Informação.
Operações
Operações
são corriqueiras e repetitivas;
possuem atividades contínuas, não sendo limitadas a
tempo
suportam o funcionamento normal de uma organização.
são um conjunto de ações cujos resultados, em um dado
período, contribui para o atendimento de uma
necessidade administrativa ou operacional da
organização.
5
Projetos x Operações
Possuem características semelhantes, apesar de
serem conceitos diferentes;
Tanto os projetos como as operações são realizadas
por pessoas, restritos em recursos e são planejados,
executados e controlados;
São realizados com um propósito definido e
possuem atividades inter-relacionadas.
A finalidade de um projeto é atingir o objetivo e ser
finalizado.
O objetivo de uma operação é normalmente
sustentar o negócio.
Parte II
6
Projetos de Desenvolvimento de
Software
Estão inseridos em ambientes de negócio bastante
dinâmicos e complexos.
São projetos de alta complexidade devido às mudanças
constantes de requisitos (escopo)
Muitos projetos fracassaram ou estavam fadados ao
insucesso devido ao desconhecimento ou emprego
incorreto de práticasApenas
de gerenciamento de projetos.
34% dos projetos de
desenvolvimento de software
foram bem-sucedidos em
2002 (Standish Group)
©Alison Rabelo | twitter.com\alisonrabelo
Parte III
7
Métodos Ágeis de Desenvolvimento de
Software
São uma resposta ao baixo desempenho dos projetos
de software.
Visam atender às demandas crescentes por produtos e
serviços inovadores e à necessidade de mudanças
constantes de escopo nos projetos de desenvolvimento
de software.
Uma reação aos métodos clássicos de desenvolvimento
de software, baseados no RUP, CMMi, PMBOK, etc.
Fruto de um movimento da comunidade de analistas e
desenvolvedores
8
Métodos Ágeis de
Desenvolvimento de Software
Métodos adaptativos e não preditivos.
O planejamento é refeito, levando em considerações as
mudanças de requisitos e no ambiente de negócios.
Diferença entre duas abordagens:
9
Métodos Ágeis de Desenvolvimento de
Software
Em 2001, um grupo inicial de 17 metodologistas formou a Aliança Ágil
e publicou um manifesto, chamado Manifesto Ágil composto por
quatro simples declarações de valores:
Ou seja, embora haja valor nos itens à direita, nós valorizamos mais os
itens à esquerda”.
©Alison Rabelo | twitter.com\alisonrabelo
Parte IV
10
Gerenciamento Ágil de Projetos
Surgiu a partir dos valores e princípios do Manifesto
Ágil.
O movimento de desenvolvimento ágil ampliou a sua
abrangência, sendo estendido ao gerenciamento de
projetos.
O Gerenciamento Ágil de Projetos aparece, então,
como uma nova plataforma de gerenciamento de
projetos aplicável a ambientes voláteis e desafiadores,
sujeitos a freqüentes mudanças, em que o processo
prescritivo e padronizado não mais funciona.
Tempo
11
Gerenciamento Ágil de Projetos
Fases do Gerenciamento Ágil de Projetos:
Visão
Visão
Escopo
Comunidade do projeto Plano de
Equipe do projeto entregas
Especulação Exploração
Ações de Funcionalidades
adaptação complementares
Adaptação
Lista de
funcionalidades
Encerramento
Produto final
12
Gerenciamento Ágil de Projetos
Exploração:
Entrega dos produtos planejados;
Estas entregas são feitas sob a forma de incrementos de
funcionalidades do produto e são divididas entre os ciclos do
projeto;
Adaptação:
Revisão dos resultados entregues;
Análise da situação atual e avaliação do desempenho da equipe e
do projeto, para eventual adaptação;
Esta revisão objetiva não apenas uma comparação entre o
realizado e o planejado, mas principalmente entre o realizado e
as informações e os requisitos atualizados do projeto, para
identificação de mudanças necessárias.
©Alison Rabelo | twitter.com\alisonrabelo
13
Vantagens de ser ágil
Cria um ambiente propício para definição de requisitos
e inovação durante o ciclo de desenvolvimento do
produto.
Cria um ambiente mais colaborativo e produtivo entre
desenvolvedores e clientes, resultando em entregas
mais rápidas de produtos, melhor adaptados à
realidade do cliente e com a qualidade esperada.
O Gerenciamento de Projetos é facilitado pela maior
integração e comprometimento da equipe com as
entregas do projeto.
14
Parte V
Scrum
Baseado no controle
empírico de processos
químicos industriais, usado
para controlar processos
complexos, de
comportamento
imprevisível.
Tem como objetivo lidar com a complexidade do
desenvolvimento de software, em que requisitos surgem e
mudam rapidamente.
Estabelece conjuntos específicos de regras e práticas
gerenciais que devem ser utilizadas para o sucesso de um
projeto.
©Alison Rabelo | twitter.com\alisonrabelo
15
Scrum
Pode ser aplicado de forma variada, adaptando-se as
suas práticas.
Recomendado para projetos de outras áreas e
principalmente para projetos de Implantação, pesquisa
e inovação.
Características do Scrum
Simples;
Fácil de aprender;
Aplicável a projetos cujos requisitos são pouco estáveis
ou desconhecidos;
Aplicável a equipes pequenas de nove pessoas, no
máximo;
Valoriza o envolvimento das partes interessadas no
planejamento do projeto;
16
Características do Scrum
Iterações ou ciclos de 30 dias;
Auto-gestão do trabalho de desenvolvimento por parte
da equipe;
Dá prioridade aos requisitos que mais agregam valor ao
software.
Benefícios do Scrum
Participação mais efetiva da equipe quanto à definição
das atividades, gerando maior comprometimento,
motivação e confiança.
Maior visibilidade do desempenho da equipe e de cada
membro.
Maior participação e satisfação do cliente.
Estimula a colaboração e a integração entre os
membros da equipe.
Incentiva o compartilhamento e a disseminação do
conhecimento.
Fortalece o trabalho em equipe.
©Alison Rabelo | twitter.com\alisonrabelo
17
Práticas Gerenciais do Scrum
Prática Descrição
Product Backlog Lista de atividades do projeto
Daily Scrum Meeting Reunião diária de 15 minutos para
monitoramento do projeto
Sprint Iteração de 30 dias.
Sprint Planning Meeting Reunião de planejamento do Sprint.
Sprint Backlog Lista de funcionalidades a serem
desenvolvidas durante o Sprint
Sprint Review Meeting Reunião para apresentação, revisão
e avaliação das entregas realizadas
durante o Sprint.
18
Papéis do Scrum
Product Owner
ScrumMaster
Equipe Scrum
Product Owner
Representante do patrocinador no projeto.
Define os requisitos dos produtos, decide as datas das
releases de software e o que deve conter em cada uma
delas.
É responsável pelo retorno financeiro (ROI) do
produto.
Prioriza os requisitos de acordo com as necessidades
de negócio ou seu valor de mercado.
Pode mudar os requisitos e prioridades a cada Sprint
Planning Meeting.
Aceita ou rejeita o resultado de cada Sprint
©Alison Rabelo | twitter.com\alisonrabelo
19
ScrumMaster
Responsável pelo processo Scrum, isto é, garante que
todos sigam as regras e práticas do Scrum, conduzindo
as reuniões diárias, de planejamento e revisão do
Sprint.
Tem um papel mais próximo ao de um facilitador do
que de um Gerente de Projetos.
Facilita a colaboração entre as funções e áreas.
Elimina os impedimentos da equipe.
Equipe Scrum
Multifuncional
Deve possuir de 5 a 9 membros.
É responsável por selecionar, entre os itens priorizados
pelo Product Owner, os que irão ser implementados
durante o Sprint.
Auto-organizada: o trabalho entre os membros é
organizado de forma participativa.
Ao final de cada Sprint, a equipe realiza a apresentação
do software desenvolvido para o Product Owner na
reunião de revisão do Sprint.
©Alison Rabelo | twitter.com\alisonrabelo
20
Artefatos do Scrum
Product Backlog
Sprint Backlog
Burndown Chart
Product Backlog
Os requisitos do software estão listados no Product
Backlog.
O Product Owner é responsável pelo conteúdo e pela
priorização dos itens do Product Backlog.
Nunca está completo.
É uma mera estimativa inicial dos requisitos.
É alterado assim que as necessidades de negócios
mudam.
21
Product Backlog
Sprint Backlog
Lista de atividades ou requisitos a serem desenvolvidos
no Sprint, ou seja, é o plano de trabalho da equipe
durante o Sprint.
São itens selecionados do Product Backlog que a
equipe acredita e se compromete que pode realizar
durante o Sprint.
A equipe escolhe e estima as tarefas durante a reunião
de Planejamento (Sprint Planning Meeting).
Apenas a equipe pode alterar o Sprint Backlog.
22
Sprint Backlog
23
Burndown Chart
O Burndown Chart também pode ser usado para medir o
progresso do projeto.
Parte V - Final
24
Regras do Scrum
O Scrum pode ser considerado um jogo com regras
claras e definidas.
O ScrumMaster é responsável por assegurar que todos
os participantes do projetos, sigam as regras do Scrum.
A experiência mostra que estas regras têm funcionado
com sucesso em muitos projetos de diversas
organizações.
É importante que todos que participam de um projeto
gerenciado com Scrum conheçam e sigam as regras de
modo a evitar mal-entendidos, perda de tempo e baixo
comprometimento com metas.
25
Sprint Planning Meeting
26
Sprint Planning Meeting
Sprint
1) Tempo fixo de 30 dias consecutivos.
2) O time pode procurar orientação, ajuda, informação e
suporte de pessoas externas durante o Sprint.
3) Ninguém pode dar conselhos, instruções ou direções
sobre as atividades da equipe durante o Sprint. A equipe
deve fazer a auto-gestão das suas atividades.
4) A equipe se compromete com o Product Backlog durante
a Sprint Planning Meeting. Ninguém possui permissão
para mudar o Sprint Backlog durante o Sprint. O escopo
estará “congelado” até o final do Sprint.
27
Sprint
5) Se provar-se que o Sprint não é viável, o ScrumMaster
pode encerrar o Sprint e iniciar uma nova Sprint Planning
Meeting de modo a iniciar um novo Sprint.
6) O ScrumMaster pode interromper o Sprint sem
consentimento das equipe ou do Product Owner ou à
pedido destes.
7) O Sprint pode se tornar inviável quando:
A tecnologia utilizada no desenvolvimento provar-se não ser
capaz de atender os requisitos.
As necessidades de negócio mudarem de maneira que o
requisitos desenvolvidos no Sprint não possuem mais valor para a
organização.
O time recebe interferência externa durante o Sprint.
©Alison Rabelo | twitter.com\alisonrabelo
Sprint
8) Se a equipe se sentir impossibilitada de completar
todo o Sprint Backlog durante o Sprint, pode
consultar o Product Owner sobre quais itens remover
do Sprint em curso.
9) Se houver muitos itens a serem removidos de
maneira que o Sprint perca seu valor e significado no
projeto, o ScrumMaster pode terminar o Sprint.
10) Se a equipe identificar que pode desenvolver mais
requisitos do que os relacionados no Sprint Backlog,
ela poderá consultar o Product Owner para incluir
itens adicionais para o Sprint em curso.
28
Sprint
11) Os membros da equipe têm duas responsabilidades
administrativas durante o Sprint:
Comparecer ao Daily Scrum Meeting.
Manter o Sprint Backlog atualizado e visível para
todos.
29
Daily Scrum Meeting
5) Todos o membros da equipe devem participar.
6) Se alguém não puder comparecer pessoalmente, deve
participar por telefone ou pedir que alguém relate o
status da suas atividades no seu lugar.
7) O ScrumMaster deverá começar a reunião na hora
marcada, sem levar em conta que está presente.
8) Quem chegar atrasado na reunião deverá pagar um
dinheiro pra caixinha de fim de ano ao ScrumMaster
imediatamente.
30
Daily Scrum Meeting
11) Os membros da equipe devem manter o foco nas
respostas à aquelas três questões.
12) Devem ser evitados outros assuntos, como questões
técnicas, discussões sobre problemas, fofocas, etc.
13) Uma pessoa deve falar pode vez e relatar o status das
suas tarefas. Todos devem ouvi-lo. Não é permitido
conversas paralelas.
14) Se um membro de equipe relata algo de interesse de
outros ou alguns membros necessitam ajuda de
outros membros, estas questões deverão ser tratadas
após o final da reunião.
31
Sprint Review Meeting
6) Artefatos e documentação não devem ser apresentados, a
menos que sirvam para esclarecer o entendimento das
funcionalidades apresentadas.
7) Artefatos não devem ser mostrados como produtos de
trabalho e seu uso deve ser minimizado de forma a evitar
deixar confusas as partes interessadas ou a requerer que
eles entendam como o desenvolvimento de sistemas
funciona.
8) Funcionalidades devem ser apresentadas nos
computadores dos membros da equipe a partir do
servidor mais próximo da produção, usualmente um
servidor de QA (Quality Assurance)
©Alison Rabelo | twitter.com\alisonrabelo
32
Sprint Review Meeting
12) No fim da apresentação, as partes interessadas são
consultadas, uma por uma, para dar as suas
impressões, seus desejos de mudança e a prioridade
dessas mudanças.
13) O Product Owner discute com as partes interessadas
e a equipe a reordenação do Product Backlog a partir
do feedback dado.
14) As partes interessadas são livres pra fazer quaisquer
comentários, observações e críticas a respeito dos
incrementos de funcionalidade do produto.
33
Sprint Retrospective Meeting
Tem tempo fixo de 3 horas.
Participantes:
Equipe Scrum
ScrumMaster
Product Owner (opcional)
A reunião começa com os participantes respondendo a
duas questões:
O que foi bem no último Sprint?
O que pode ser melhorado no próximo Sprint?
O ScrumMaster anota as respostas dadas pelos
participantes em um formulário.
34