Transcript Ciclo de Vida

Agenda Geral
 Métodos Ágeis no Desenvolvimento de Projetos
 Gerenciamento de Projetos
 O por que não ser Gerente?
Raphael Donaire Albino
Coordenador de Projetos
Lecom
[email protected]
[email protected]
www.twitter.com/raphalbino
Agenda
 Do Tradicional ao Ágil
 O que é o Scrum?
 Papéis
 Reuniões
 Artefatos
 Considerações e Dicas
Planejamento Tradicional
Reflexo do Planejamento
Tradicional
Motivações para mudar
 Clientes e Usuários não tem certeza do que querem.
Motivações para mudar
 Comunicação falha é mais comum do que parece.
Motivações para mudar
 Muitos detalhes que eles querem só serão revelados
durante o desenvolvimento.
Motivações para mudar
 Na medida que eles vêem o produto sendo construído,
elas mudam.
Existe solução para o CAOS que é
desenvolver Software?
Manifesto Ágil
Indivíduos e
Interação entre eles
Processos e
Ferramentas
Software em
funcionamento
Documentação
Abrangente
Colaboração com o
cliente
Negociação de
Contratos
Responder a
Mudanças
Seguir um plano
Metodologias Ágeis
 Extreme Progamming (XP)
 Crystal Clear
 Adaptive Software Development
 SCRUM
 Feature Driven Development (FDD)
Rugby??!!
Conceituando
 Scrum é uma prática de gerenciamento de projeto
empírica utilizada para entregar pequenos
incrementos com alto valor ao cliente de forma
iterativa.
Conceituando
 Método Iterativo e Incremental – Sprints;
 Análise, desenvolvimento, prótotipagem e testes
estão interligados de forma iterativa;
 A equipe arquiteta a solução;
 Equipes Multi-Funcionais; e
 A documentação criada serve como suporte e
NUNCA será mais importante do que o
desenvolvimento do software.
Valores
 Comprometimento
 Equipes SCRUM se comprometem em entregar algo de valor
ao cliente a cada iteração.
 Abertura
 Equipes SCRUM estão abertas a novas idéias.
 Foco
 Equipes SCRUM focam-se ao máximo em seus objetivos.
 Respeito
 Equipes SCRUM criam respeito.
 Coragem
 Equipes SCRUM estão aptas a encarar novos desafios.
Product Owner
Product Owner





Dono do Escopo do Produto;
Lida muito bem com priorização;
Define as datas dos releases;
Se preocupa com o ROI; e
Aceita ou rejeita o resultado Final.
Também é conhecido por:
• Analista de Negócios;
• Analista de Sistemas (Isto ainda existe?); ou
• Em alguns casos pode ser o próprio Cliente.
SCRUM Master
SCRUM Master
 Responsável pelo processo;
 Gerenciamento (PMBok);
 Remove os impedimentos;
 Garante produtividade; e
 Protege contra interferências.
Também é conhecido por:
• Gerente de Projetos; ou
• Coordenador de Projetos.
Team
Team






Multidisciplinar;
1 à 7 pessoas;
Liberdade;
Responsável pela qualidade;
Alocado Full Time ; e
Estima complexidade a cada Sprint.
Composta normalmente por:
• Designers;
• Desenvolvedores;
• Arquitetos de Informação; e
• Arquitetos de Sistema.
Por que porcos e não galinhas?
Fluxo SCRUM
Reuniões no Fluxo
Sprint Planning Meeting
 Objetivos
 Entender o Escopo; e
 Estimar complexidade dos pacotes de trabalho.
 Resultados
 Time define o que poderá entregar;
 Time define as atividades que serão desenvolvidas.
Daily SCRUM
 Objetivos
 Comunicar a todos da equipe como está o progresso do
trabalho.
 Características
 Deve responder as seguintes perguntas:
1.
2.
3.

O que eu fiz desde a última reunião diária?
O que eu vou fazer hoje?
Quais são os impedimentos existentes?
Tempo máximo de duração: 15 minutos.
Sprint Review
 Objetivos
 O Time apresentar ao Product Owner o resultado da
Sprint.
 Características
 Reunião Informal;
 Todo o time participa; e
 Tempo máximo de duração: 2 horas.
Sprint Retrospective
 Objetivos
 Levantar e documentar as lições aprendidas da Sprint.
 Características
 Reunião Informal;
 Todos os envolvidos na Sprint participam; e
 Tempo máximo de duração: 2 horas.
Product Backlog
 Conteúdo
 Lista priorizada contendo todas as funcionalidades
desejadas para o projeto;
 Não precisa estar completo no início do projeto; e
 Com o tempo, o Product Backlog cresce e muda à
medida que se aprende mais sobre o produto e seus
usuários.
 Criador
 Product Owner.
 Ciclo SCRUM
 Utilizado na reunião de planejamento da Sprint.
Product Backlog
Item do Backlog
Estimativa
Criação de Carrinho de Compra
3
Identificação do Usuário
5
Finalização do Carrinho de Compra
8
Melhora de performance na buscca de
Produtos
??
Manutenção de carrinho de compras
5
Criação de listagem de produtos mais
vendidos
1
Product Backlog
Sprint Backlog
 Conteúdo
 Lista de funcionalidades que o SCRUM Team se
compromete a implementar em um Sprint.
 Considerações
 Os itens do Sprint Backlog são extraídos do Product
Backlog, pela equipe, com base nas prioridades definidas
pelo Product Owner ; e
 Cabe a equipe determinar a quantidade de itens do Product
Backlog que serão trazidos para o Sprint Backlog.
 Ciclo SCRUM
 Resultado da reunião de planejamento da Sprint.
Sprint Backlog
Burndown Chart
SCRUM não é o salvador da pátria!
 O mais importante dos métodos ágeis é o
entendimento dos conceitos;
 Projeto são pessoas, portanto as valorize;
 Agilidade está diretamente ligada a Melhoria
Contínua; e
 Desenvolver software deve ser encarado como algo
divertido.
Leia, Estude e Pratique
 Leia:
 Agile Software Development with Scrum by Ken
Schwaber and Mike Beedle .
 Agile Project Management with Scrum by Ken Schwaber.
 Scrum and XP from the Trenhces by Henrik Kniberg.
 Estude:
 Linguagens que focam o desenvolvimento ágil.
 Pratique:
 É praticando que se aprende.
Leonardo Fortunato
Gerente de Projetos
MS Tech
[email protected]
http://leonardofortunato.blogspot.com
Agenda
 Conceitos sobre Projeto
 Gerenciamento de Projetos
 Estudo de Caso
 Referências
Projeto
“É um esforço temporário empreendido para criar um
produto, serviço ou resultado exclusivo.”
PMBOK®
“Um processo único, consistindo de um grupo de
atividades coordenadas e controladas com datas para
início e término, empreendido para alcance de um
objetivo conforme requisitos específicos, incluindo
limitações de tempo, custo e recursos.”
ISO 10006
Diferenciando Projetos e Operações
Idéia
Melhorias / Atualizações
Projeto
Início
Produto
Execução
Fim
Operação
Gerenciamento de Projetos
Política ou
Norma
Metodologia
Metodologia
(Processos)
(Processos)
Metodologia (Ciclo
de
Metodologia
(Ciclo
de
Vida)
Vida)
Instruções operacionais
detalhando a execução das
atividades (Ferramentas)
Metodologia de Gerenciamento de
Projetos
Características:
 Baseada em melhores práticas do mercado;
 Ajustável às necessidades e realidade da organização;
 Utilizável, isto é, prática e não burocrática;
 Padronização de processos e documentação;
 Planejamento detalhado e controle apropriado;
 Facilitar a comunicação;
 Aumento de eficiência e produtividade.
Dimensões Gerenciamento de
Projetos
Áreas de
Conhecimento
ou Disciplinas
(Grupo)
Processos
Papéis
Ciclo
de Vida
Papéis
 Os papéis definem um conjunto de aptidões afins,
competências e responsabilidades.
Gerente
de Projeto
Analista de
Negócios
Stakeholder
Arquiteto
Áreas de Conhecimento ou
Disciplinas
 Descrevem a aplicação de conhecimentos, habilidades,
ferramentas e técnicas às atividades do projeto.
Áreas de Conhecimento - PMBOK®
Integração
Riscos
Custos
Aquisições
Escopo
Grupo de Processos
Iniciação
Planejamento
Execução
Monitoramento
e Controle
Encerramento
Obter
aprovação
Definir
escopo
Gerenciar a
execução
Controlar as
mudanças
Fechar
contratos
Elaborar
termo de
abertura
Elaborar
cronograma
Garantir a
qualidade
Controlar o
desempenho
Fechar o
projeto
Processo
Entradas
Procedimentos
Resultados
(Saídas)
Ciclo de Vida
“O Ciclo de Vida do projeto define as fases que
conectam o projeto do seu início ao seu fim.”
PMBOK®
“A definição das fases do ciclo de vida de um projeto
está diretamente ligada ao tipo de produto a ser
gerado.”
Methodware®
Ciclo de Vida
“Não existe uma única melhor maneira para definir um
ciclo de vida ideal do projeto.”
PMBOK®
Criação de um novo produto
Concepção
Pesquisa
Desenho
Contratação
Fabricação
do Protótipo
Entrega do
Produto
Desenvolvimento de software
Concepção
Elaboração
Desenvolvimento
Estabilização
Implantação
Ciclo de Vida
 Ciclos de vida alinhados com o objetivo do projeto.
Planejamento
Especificação
Desenvolvimento
Implantação
Visão
Implantação
Estabilização
Planejamento
Desenvolvimento
Metodologias
MSF
MSF
Processos
PMBOK
®
Áreas de
Conhecimento
RUP
Papéis
Scrum
RUP
Ciclo de Vida
MPS.BR
XP
Estudos de caso – Cenários
Grupo de Sistemas de um
Departamento de TI
Empresa de TI
 Todos os projetos
 Projetos possuem vários
possuem um único
produto final: Software;
 Equipes sempre
pequenas (2 ou 3
pessoas);
 Método dever ser sem
burocratização;
 Falta de ferramentas de
gerenciamento.
produtos de naturezas
diferentes;
 Equipes de tamanho
variado;
 Método deve ser sem
burocratização;
 Disponibilidade de
ferramentas de
gerenciamento.
Estudos de caso – Soluções
Grupo de Sistemas de um
Departamento de TI
Empresa de TI
 Baseado no OpenUP;
 Baseado no PMBOK® e
 Processos simples;
no MSF;
 Processos e
documentação bem
definidos;
 Áreas de conhecimento
com instruções e guias
definidos;
 Ciclos de vida para cada
tipo de projeto com
organização diferente.
 Documentação mínima;
 Ciclo de vida baseado
em iterações.
Estudos de caso – Soluções
Grupo de Sistemas de um
Departamento de TI
Metodologia
Empresa de TI
Política
(Processos e
Ciclo de Vida)
Instruções operacionais
detalhando a execução
das atividades manuais
Metodologia
(Processos)
Metodologia
(Ciclo de Vida)
Ferramentas de
Gerenciamento de
Projetos
Estudos de caso – Soluções
Grupo de Sistemas de um
Departamento de TI
Iteração 1
Concepção
Elaboração
Construção
Empresa de TI
Concepção
Implantação
Elaboração
Implantação
Desenvolvimento
Estabilização
Iteração 2
Concepção
Elaboração
Construção
Implantação
Desenvolvimento
Iteração N
Concepção
Elaboração
Construção
Implantação
Iteração 1
Iteração 2
Iteração N
Referências
 A Guide to the Project Management Body ok
Knowledge (PMBOK® Guide), 3ª edição, 2004, Project
Management Institute
 Metodologia de Gerenciamento de Projetos –
Methodware ®, 1ª edição, 2005, Carlos Magno da Silva
Xavier... [et al.]
 http://www.eclipse.org/epf
 http://www.microsoft.com/technet/solutionaccelerato
rs/msf
Agenda
 O papel do Gerente de Projetos
 Compartilhando experiência
Segundo o desciclo.pedia
 Saco de Pancada. - Google sobre Gerente de Projeto.
 Trata-se do que fala muito e sabe menos que o
estagiário. - Universitário sobre Gerente de Projeto.
 Gerente de Projeto não serve para nada! - Diretor de
Projeto sobre Gerente de Projeto.
Segundo o desciclo.pedia
 Se o projeto der certo, mérito da equipe, se dá errado,
culpa do gerente de projetos. - PMI - Project
Management Ignorance sobre gerentes de projeto.
 Pô bichão, eu entendo mas não tem como compensar
esses 4 dias entre hoje e amanhã? Nem dando uma
esticadinha? - Um conhecido Gerente de Projeto, PMP,
questionando sobre um possível esforço após o horário
de trabalho.
A origem
 Técnico qualquer (geralmente um não muito
qualificado) que acha que pode mandar em todo
mundo levando os louros no final do projeto.
 Existe o lado ruim (apesar de ninguém ter descoberto o
lado bom de ser gerente de projetos, ele deve existir),
que é sempre levar a culpa por tudo que acontece de
errado nos projetos.
Técnicas de motivação
 “A gente precisa marcar esse gol!”
 “Show de Bola!!!!”
 "Deixe comigo que nas próximas semanas (anos)
estarei resolvendo este problema para você.”
 “Bicho, aos 40 do segundo tempo, gol de mão vale
mais.”
Técnicas de motivação
 “Na situação em que a gente se encontra, você tem que




cobrar o escanteio e ainda correr para cabecear pro
gol.”
“Isso é molezinha, você faz isso em 10 minutos que eu
sei...”
“Se eu sentar aí eu faço isso..”
“Se eu sentar aí eu faço isso..“
“Eu não quero saber se o pato é macho, eu quero é ver o
ovo...”
O papel
 O papel gerente de projeto aloca recursos, ajusta as
prioridades, coordena interações com clientes e
usuários e geralmente mantém a equipe do projeto
concentrada na meta certa. O gerente de projeto
também estabelece um conjunto de práticas que
garantem a integridade e a qualidade dos artefatos do
projeto.
Habilidades fundamentais do
Gerente de Projetos
Negociação
Comunicação
Influência na
Empresa
Liderança
Tomada de
Decisões
O que nós achamos?