Académique Documents
Professionnel Documents
Culture Documents
Mtodos geis
em Gerenciamento de Projetos
1 Edio
Rio de Janeiro
Horcio da Cunha e Sousa Ribeiro
2015
1
Gerenciamento de Projetos
com Mtodos geis
contato@cursospin.com.br
Av. Djalma Batista, n. 946, sala 08 (Centro Empresarial Santo Remdio) - Vieiralves
Nossa Sra. das Graas Manaus
Telefone (92) 3584-1966
Site: WWW.cursospin.com.br
contato@cursospin.com.br
1 Edio
contato@cursospin.com.br
Av. Djalma Batista, n. 946, sala 08 (Centro Empresarial Santo Remdio) - Vieiralves
Nossa Sra. das Graas Manaus
Telefone (92) 3584-1966
Site: WWW.cursospin.com.br
contato@cursospin.com.br
Rio de Janeiro
Horcio da Cunha e Sousa Ribeiro
2015
Todos os direitos reservados. Nenhuma parte deste livro pode ser fotocopiada, gravada, reproduzida ou
armazenada num sistema de recuperao ou transmitida sob qualquer forma ou por qualquer meio
eletrnico ou mecnico sem o prvio consentimento dos autores.
Direito Editorial
Horcio da Cunha e Sousa Ribeiro
R484g
Dedicatria:
Este livro dedicado a Emanuel Bodstein
Ribeiro o projeto mais complexo da minha
vida.
Rafael Dias Ribeiro
Contedo
CAPTULO 1 ...................................................................................................................................10
1.1 - Introduo .........................................................................................................................10
1.2 - Anlises de Ambientes ...............................................................................................11
1.2.1 -Teoria de Cynefin ..................................................................................................12
1.3 - Tolerncia ao Erro ........................................................................................................15
1.4 - Projetos Direcionados Valor e Projetos Direcionados Planos ........17
1.4.1 - Projeto Direcionado Plano: ..........................................................................17
1.4.2 - Projeto Direcionado Valor: ...........................................................................18
CAPTULO 2 ...................................................................................................................................20
2.1 Introduo: ......................................................................................................................20
2.2 - Indivduos e interaes mais que processos e ferramentas...........21
2.3 - Software em funcionamento mais que documentao abrangente .....21
2.4 - Colaborao com o cliente mais que negociao de contratos .............22
2.5 - Responder a mudanas mais que seguir um plano .....................................22
2.6 - Os 12 Princpios por trs do Manifesto: .............................................................23
2.7 - Declarao de Interdependncia ......................................................................24
CAPTULO 3 ...................................................................................................................................25
3.1 Feature Driven Development(FDD) - Desenvolvimento Dirigido a
Funcionalidades .......................................................................................................................25
3.1.1 - Modelagem de Domnio do Objeto: ........................................................25
3.1.2 - Desenvolvimento por Funcionalidade:.................................................26
3.1.3 - Propriedade Individual(cdigo): ...............................................................26
3.1.4 - Times Dinmicos: ..............................................................................................26
3.1.5 - Inspees: ..............................................................................................................26
3.1.6 - Gerenciamento de Configurao:............................................................26
3.1.7 - Construes Regulares: ...............................................................................26
3.1.8 - Visibilidade: ...........................................................................................................26
3.2 - Dynamic Systems Development Method(DSDM) - Metodologia de
Desenvolvimento de Sistemas Dinmicos ..................................................................27
3.2.1 - - Ciclo de Vida DSDM ........................................................................................27
3.3 - Crystal ...............................................................................................................................29
3.4 - Lean Software Development Desenvolvimento de Software
Enxuto ..........................................................................................................................................30
3.5 - KanBan .............................................................................................................................33
CAPTULO 4 ...................................................................................................................................37
4.1 - eXtremingProgramming .........................................................................................37
7
CAPTULO 1
1.1 - Introduo
Pela necessidade de um aumento contnuo de competitividade, com
o dinamismo e a velocidade com que a informao e o conhecimento
circulam, o ambiente corporativo de vrias empresas necessita utilizar a
gerncia atravs de projetos para se tornar mais eficaz, gil e competitivo.
H uma crescente demanda de profissionais detentores de
habilidades para gerenciar projetos, que utilizem boas prticas e ferramentas
para alcanar os objetivos do projeto e no apenas intuio ou bom senso.
Para responder a esse desafio, colaboradores devem reunir atributos de
conhecimentos tcnicos sobre gerenciamento de projetos, usando de modo
eficiente esse conhecimento, aumentando as chances de sucesso do projeto.
Neste captulo, iremos compreender o que realmente um projeto e vamos
identificar as caractersticas de projetos orientados a planos e de projetos
orientados a valor.
muito comum no meio corporativo, ouvirmos:
Prximo ms, iniciamos o Projeto XYZ(...)
Esto todos dedicados ao Projeto XYZ(...)
Mas ser que o conceito de projeto usado corretamente? Vamos
entender o que um projeto e suas caractersticas.
A definio do PMBoK-Project Management Body of Knowledge,
sobre projeto, :
Um PROJETO um esforo temporrio empreendido
para criar um produto, servio ou resultado exclusivo.
Observe que os projetos possuem caractersticas bem significativas,
10
como:
Temporrios, possuem um incio e um fim definidos;
Planejados, executados e controlados;
Entregam produtos, servios ou resultados exclusivos;
Desenvolvidos em etapas, implementam uma elaborao
progressiva; realizados por pessoas; sofrem restries.
A empresa, assim como a execuo de determinados projetos,
algo vivo, que muda seu comportamento durante a execuo e, em
momentos diversos, poder exigir abordagens diferentes do gestor.
11
12
imprevisvel,
colaborativa,
adaptvel;
Responder
e,
assim,
podemos
aplicar
prtica
emergente(emergente).
Por exemplo, ao entrar em um consultrio mdico e relatar que est
com dor no estmago(efeito), alm de tratar dos efeitos, o mdico ir iniciar
uma srie de testes at descobrir a causa.
Catico: este o lugar no qual impossvel discernir a relao entre
causa e efeito. A melhor abordagem nesse domnio simplesmente agir.
No h nenhuma relao entre causa e efeito no nvel de sistemas, a
abordagem Agir - Sentir - Responder e, assim, podemos descobrir novas
prticas.
14
que
no
possvel
para
todas
as
atividades),
pois
15
de
Projeto
de
Caractersticas de Profissionais
Construo(Trabalho Industrial)
do Conhecimento
O trabalho visvel.
O trabalho invisvel.
O trabalho estvel.
O trabalho instvel.
nfase na mudana.
Definio de tarefas.
Comando e controle.
Autonomia.
Padronizao.
Inovao contnua.
Foco na qualidade.
Foco na qualidade.
Medio
de
desempenho
padronizada.
Minimizao
Ensinamento
aprendizado
contnuo.
do
custo
pago
ao
Quadro de comparao do trabalho industrial com profissionais do conhecimento, adaptado de PMIACP ExamPrep, MakiGiffiths, 2012.
16
17
(ex: Plano de
18
19
CAPTULO 2
2.1 Introduo:
Diferentes tipos de projetos necessitam de diferentes mtodos de
gerenciamento. A abordagem gil muito utilizada em projetos orientados a
valor. Como vimos, projetos orientados a valor geralmente so realizados por
profissionais do conhecimento e possuem elevado grau de incerteza, por
grande indefinio do escopo e elevado nmero de mudanas.
A maior parte dos conceitos e princpios geis surgiu com foco em
projetos de desenvolvimento de software e atualmente so utilizados em
diversos tipos de projetos que possuem grandes incertezas, como
campanhas publicitrias, novos produtos, planejamento de oramento e
muitas outras reas. Neste livro iremos manter o foco em projetos de
software, porm estes conceitos NO so especficos para estes tipos de
projetos.
Existem diversos tipos de abordagens geis, como veremos neste
livro e estas abordagens geis buscam estar alinhadas com diversos
princpios
definidos
no
documento
Manifesto
for
Agile
Software
20
primariamente
no
desenvolvimento
dos
indivduos
qualidade,
mas
muitas
vezes
entregas
em
partes
que
este
valor
no
est
sugerindo
abandonar
22
frequentemente
software
funcionando,
de
poucas
de
negcio
desenvolvedores
devem
trabalhar
equipes auto-organizveis
11.
23
CAPTULO 3
3.1 Feature Driven Development(FDD) - Desenvolvimento
Dirigido a Funcionalidades
uma abordagem simples de entender e poderosa para o
desenvolvimento de produtos. Uma equipe de projeto seguindo o mtodo
FDD ir primeiro desenvolver um modelo global para o produto, construir lista
de recursos e planejar o trabalho. A equipe ento se move atravs da
concepo e construo de iteraes para desenvolver cada recurso. O FDD
busca apresentar resultados frequentes, tangveis e funcionais.
Desenvolver um
modelo global para o
produto
Planeje por
funcionalidade
Projete por
Projete
por
funcionalida
Projete
por
funcionalid
de
funcionalida
ade
de
Construa
Construa
por
Construa
por
funcionalida
por de
funcionalid
funcionalida
ade
de
25
26
27
28
3.3 - Crystal
Crystal uma famlia de metodologias desenvolvidas por Alistair
Cockburn, em meados da dcada de 1990, destinadas para projetos que vo
desde aqueles executados por pequenas equipes de desenvolvimento com
baixa criticidade e prove abordagens at com grandes equipes que
implementam sistemas de alta criticidade.
A famlia de metodologias Crystal utiliza cores diferentes para indicar
o "peso" do projeto e qual a metodologia aplicar.
Criticidade
(Defeitos causam
perda de ...)
29
que
todos
possam
apresentar
suas
dvidas
questionamentos)
Foco (Cada membro do time deve saber o que precisa fazer e ter
liberdade suficiente para trabalhar no que necessrio)
Fcil acesso ao usurio (Fcil acesso aos usurios chaves e
rpido feedback)
Ambiente automatizado (Testes automatizados, controle de
configuraes, integrao contnua,...)
30
Desperdcio
gerado
por
antecipar
possveis
Desperdcio
gerado
pela
cultura
de
trabalho,
Aprendizagem:
Este
conceito
envolve
facilitar a
32
3.5 - KanBan
Antes de iniciarmos nossa conversa sobre o KanBan, deixem contar
uma histria sobre os jardins do palcio imperial Japons. Em Abril, centenas
de visitantes vo aos jardins do palcio para apreciarem as flores de
Sakura(flor de cerejeira). Como os jardins, apesar de grandes, so limitados
fisicamente, existe um controle de cartes de entrada e sada.
Fim
Sada
(+1 Ticket)
Incio
Entrada
(-1 Ticket)
Visitante
33
Em
Desenvolvimento,
Desenvolvido,
Em
implantao,
Pronto. Ou qualquer outro estado que faa sentido para o trabalho e para a
equipe.
Limitador
Low-Tech,
High
Touch.Quando
inserimos
tarefa(ou
36
CAPTULO 4
4.1 - eXtremingProgramming
Os Valores em XP so conceitos no tangveis que se acredita fazer
uma grande diferena na qualidade final do produto e na motivao dos
times. Eles so:
Valores:
Comunicao
O valor da comunicao visto dentro do time, entre seus
membros, e entre o time e o cliente. Ambos tm igual importncia.
A comunicao deve ser:
DIRETA
EFICAZ
ESCLARECEDORA
Feedback
um valor que engloba as relaes interpessoais, mas tambm
se refere ao feedback que o prprio cdigo do projeto devolve aos
membros do time.
Para que o feedback do cdigo funcione bem, so necessrios
testes automatizados de unidade e um servidor de integrao contnua
para que os testes mais longos sejam rodados com freqncia e, se
quebrarem, sinalizem uma inconsistncia. Com o feedback o cliente pode:
Identificar erros rapidamente
Definir prioridades
37
38
comum
que
desenvolvedores
trabalhem
em
partes
39
mais
sobre
ego
less
programming
no
site:http://blog.codinghorror.com/the-ten-commandments-ofegoless-programming/
40
Imagem que representa o custo dos ajustes tcnicos no cdigo durante o tempo do projeto.
41
sabe
quais
funcionalidades
foram
42
43
52 cartas no Baralho.
44
46
CAPTULO 5
5.1 - SCRUM
O que SCRUM ?
Scrum um mtodo gil emprico, iterativo com entregas
incrementais.
Emprico porque se apoia no empirismo que afirma que o
conhecimento vem da experincia e de tomada de decises baseadas no que
conhecido. O Scrum emprega uma abordagem iterativa e incremental para
aperfeioar a previsibilidade e o controle de riscos.
5.1.1 - Histria
Scrum baseado em um artigo de 1986 escrito por HirotakaTakeuchi
e Ikujiro Nonaka para a Harvard Business Review, o "The Game
Development New Product". Neste trabalho, os autores utilizaram o esporte
do rugby como uma metfora para descrever os benefcios da auto
organizao de equipes de desenvolvimento de produtos inovadores e de
entrega. Jeff Sutherland, Ken Schwaber e Mike Beedle aderiram as ideias
deste artigo, incluindo a metfora, e as aplicou na rea de desenvolvimento
de software. Eles chamaram seu novo mtodo de Scrum*. Schwaber e
Beedle, escreveu sobre suas experincias em seu livro Desenvolvimento de
Software gil com Scrum em 2002.
O Scrum ou formao ordenada uma situao frequente no rugby,
47
48
49
50
51
documentado
(manual
atualizado),
52
mas
aqueles
que
quiserem uma
alterao
nas
Realizar Kick-Off
54
valor
criado
pelo
Time
Scrum.
Algumas
de
suas
responsabilidades so:
Educar o Time e stakeholders sobre o processo
Assegurar que a equipe faz o Daily Scrum no horrio certo e de
modo produtivo
Resolver os impedimentos da melhor maneira possvel
Manter o foco das reunies
Indicar pontos de melhoria no processo e no ferramental
Segundo o Scrum Guide, a Equipe de Desenvolvimento (Dev.
Team) consiste de profissionais que realizam o trabalho de entregar uma
verso usvel que potencialmente incrementa o produto Pronto ao final de
cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam
incrementos.
As Equipes de Desenvolvimento so estruturadas e autorizadas pela
organizao para organizar e gerenciar seu prprio trabalho. A sinergia
resultante aperfeioa a eficincia e a eficcia da Equipe de Desenvolvimento
como um todo.
Os Times Scrum so auto organizveis e multifuncionais. Equipes
auto organizveis escolhem qual a melhor forma para completarem seu
trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes
multifuncionais possuem todas as competncias necessrias para completar
o trabalho sem depender de outros que no fazem parte da equipe.
O que auto-organizao?
A auto organizao o processo onde uma estrutura ou padro aparece
em um sistema sem uma autoridade central ou elemento externo que define um
planejamento.
Segundo a fsico-qumica, a auto organizao a caracterstica de que
sistemas abertos podem se organizar espontaneamente quando sujeitos a um dado
gradiente. O termo auto, nesse caso, reflete o fato de que no h nenhuma instruo
do ambiente sobre como a organizao deve ocorrer ou como o sistema deve se
adequar em resposta ao gradiente. Em outras palavras, o gradiente imposto
completamente neutro em termos de informaes e a organizao emerge de dentro
55
56
57
58
5.6.1 - Sprint
Segundo o Scrum Guide, a Sprint um time-box de um ms ou
menos, durante o qual um Pronto, verso incremental potencialmente
utilizvel do produto, criado. Sprints tem duraes coerentes em todo o
esforo de desenvolvimento. Uma nova Sprint inicia imediatamente aps a
concluso da Sprint anterior.
As Sprints so compostas por uma reunio de Planning meeting
(Planejamento da Sprint), Daily Scrum (Reunies Dirias), o trabalho de
desenvolvimento, uma Review Meeting (Reviso da Sprint) e a Retrospective
Meeting (Restrospectiva da Sprint).
59
61
Identificar o
Problema
Indetificar Causas
Razes
Identificar
Solues
Propor Solues
para diminuir ou
eliminar o
Problema(em sua
causa Raz)
Testar a Soluo
Incorporar a
Soluo no
Processo e no Time
62
Nesta seo vamos apresentar algumas dinmicas que podem ser utilizadas
nas reunies de retrospectiva.
63
64
5.7 - Consideraes:
Problemas que no geram aes e solues podem ser adiados para
discusso posterior, estes problemas devem ficar na rea de parking
lot do quadro
Aes devem ser atitudes concretas que permitam a execuo
sem dupla interpretao. Por exemplo: Quem desenvolveu deve
realizar testes unitrios!
Sugiro que aes sejam endereadas, por exemplo, fulano de tal
o responsvel por lembrar-se da importncia da ao XYZ, durante o
prximo sprint
Ao final da retrospectiva, deve-se jogar no lixo os post its e deixar
fixadas as aes combinadas visveis para todos, sugiro que elas
fiquem no quadro kanban para que todos se lembrem !
65
1) Liste as habilidades que voc tem e julgue ser til para o time
e para o produto
2) O que voc tem vontade de aprender ? Como isso ser til para o
time ? Como isso ser til para o produto ?
66
5) Defina aes !
Java
SQL Server
CSS
Teste Automatizado
67
Java
SQL Server
CSS
Teste Automatizado
5.8.1 - Problema:
Escolha o problema para trabalhar. Veja como a equipe trabalha. O
que precisa ser melhorado?
68
5.8.2 - Opes:
Considere as suas opes. O que voc poderia tentar que podero
influenciar a situao para melhor? Relacione pelo menos trs opes.
5.8.3 - Experimente:
Escolha uma opo e a execute.
5.8.4 - Reviso:
Analise o resultado. Voc melhorou as coisas? Mesmo se as coisas
no melhoraram, voc j aprendeu alguma coisa ?
Vamos praticar o PrOpER atravs de um exemplo.
5.8.5 - EXEMPLO:
Problema:
Jack chegou tarde para a reunio de Daily Scrum hoje. Aconteceu na
semana passada tambm. Voc est preocupado, porque ele est
trabalhando na construo de um ambiente de teste novo. Ele est perdendo
informaes importantes sobre os problemas da equipe com o ambiente de
teste atual.
Opes: Aqui esto algumas opes que voc pode considerar:
Pegue o touro pelos chifres: Quando Jack chega, pea um tempo para
inform-lo sobre o que ele perdeu at o momento no Daily Scrum.
Enquanto voc est revendo os pontos, fale com ele sobre a importncia
de participar do Daily Scrum todo dia.
Educar a equipe: Executar uma sesso de treinamento para toda a
equipe para aprender a melhorar o Daily Scrum, o que pode ajudar o Jack
a entender porque importante para todos na equipe a participao na
reunio.
69
70
71
CAPTULO 6
6.1 - Planejamento Orientado Valor
Em projetos geis, devido a sua prpria caracterstica de incerteza, o
planejamento de verses e a priorizao do que ser desenvolvido (Backlog)
estratgica para melhorar o ROI (Return Over Investiment).
As tcnicas de planejamento de gil tem forte afinidade com o
planejamento em ondas dos mtodos de gerenciamento de projetos
orientados planos, porm com algumas diferenas conforme apresentadas
na figura abaixo. Veja que no interessante antecipar todo o planejamento
j que como temos muitas incertezas, teremos grandes probabilidades de
mudanas caso a antecipao seja feita. Ao invs disso, fazemos um
planejamento de alto nvel para identificar e planejar os releases, e
posteriormente planejamos mais detalhadamente cada iterao.
72
73
74
75
Voc
pode
consultar
mais
sobre
esta
tcnica
na
URL:
http://innovationgames.com/remember-the-future/
Cebola de Planejamento
77
78
Carto:
Cada estria escrita em um carto com um objetivo especfico, o
que permite mais clareza no que necessrio que seja
desenvolvido.
Conversa:
Como o carto uma descrio simples, ele leva a conversas com
o time e com o cliente sobre a funcionalidade, o que permite um
melhor entendimento sobre a percepo de valor, identifica riscos
e prioridades.
Confirmao:
Atravs das conversas com o time e clientes poderemos entender
como validar o carto e confirmar se o que o temos definido
realmente o necessrio o sucesso da demanda.
As estrias tambm utilizam os conceitos conhecidos com INVEST:
Negocivel
funcionalidades,
ela
negocivel
para
melhor
atender
as
necessidades do negcio.
79
Small(pequena)
poucos personagens.
Testvel
Exemplo 2:
Como comprador que no tem carto de crdito
Quero que o sistema de suporte a pagamento em boleto bancrio
81
82
Valor
Qual a importncia deste item para que o produto seja lanado ? Quanto mais
importante, mais no topo ele dever estar.
Riscos
Qual o nosso grau de conhecimento sobre o item ? Quais as incertezas ?
Identificamos os riscos associados ? Em geral, quanto menos conhecemos ou
de maior riscos devem ser priorizados. Quanto mais cedo falharmos, mais
cedo corrigimos e obtemos sucesso.
"Dependncia"
Temas e "dependncias" devem ser considerados na priorizao.
83
Emanuel
Helga
Letcia
(1.0)
(1.0)
(1.0)
Por exemplo:
Emanuel
Helga
Letcia
(2.0)
(1.0)
(1.0)
(1.0)
Carrinho de
Compras
Alerta de
Estoque
Lista de Mais
Vendidos
Gerao de
Boleto de
pagamento
TOTAL NO
GASTO
Divida o total de Reais de desenvolvimento de acordo com o peso de
cada participante.
Carrinho
Rafael
Emanuel
Helga
Letcia
(2.0)
(1.0)
(1.0)
(1.0)
de
Compras
Alerta de Estoque
Lista
de
Mais
Vendidos
Gerao
de
Boleto
de
pagamento
85
TOTAL
NO R$40,00
R$20,00
R$20,00
R$20,00
GASTO
Passo 4:Os interessados distribuem seus Reais de desenvolvimento
sobre os itens do backlog de acordo com suas preferncias. Reais de
desenvolvimento que foram licitadas so deduzidos seus Reais no
gastos. Imagine as partes interessadas alocar seus Reais da seguinte forma:
Rafael
Emanuel
Helga
Letcia
(2.0)
(1.0)
(1.0)
(1.0)
R$6,00
R$8,00
R$5,00
R$5,00
Alerta de Estoque
R$5,00
R$4,00
R$3,00
R$4,00
Lista de Mais
R$3,00
R$3,00
R$4,00
R$5,00
R$6,00
R$5,00
R$8,00
R$6,00
R$20,00
R$0,00
R$0,00
R$0,00
Carrinho de
Compras
Vendidos
Gerao de
Boleto de
pagamento
TOTAL NO
GASTO
Passo 5: O time estima o custo do desenvolvimento de cada item.
Rafael
Emanuel
Helga
Letcia
TOTAL
CUSTO
(2.0)
(1.0)
(1.0)
(1.0)
PAGO
ESTIMAD
O(DEV.
TIME)
Carrinho de
R$6,00
R$8,00
R$5,00
R$5,00
R$14,00
R$5,00
R$4,00
R$3,00
R$4,00
R$16,00
R$3,00
R$3,00
R$4,00
R$5,00
R$15,00
R$6,00
R$5,00
R$8,00
R$6,00
R$24,00
11
Compras
Alerta de
Estoque
Lista de Mais
Vendidos
Gerao de
Boleto de
86
pagamento
TOTAL NO
R$20,00
R$0,00
R$0,00
R$0,00
GASTO
Emanuel
Helga
Letcia
TOTAL
CUSTO
TOTAL
(2.0)
(1.0)
(1.0)
(1.0)
PAGO
ESTIMA
PAGO/
DO(DE
V.
CUSTO
ESTIMADO
TIME)
Carrinho de
R$6,00
R$8,00
R$5,00
R$5,00
R$14,00
14/7 = 2
R$5,00
R$4,00
R$3,00
R$4,00
R$16,00
16/5 =
Compras
Alerta de
Estoque
Lista de
3,2
R$3,00
R$3,00
R$4,00
R$5,00
R$15,00
15/5 = 3
R$6,00
R$5,00
R$8,00
R$6,00
R$24,00
11
24/11 =
Mais
Vendidos
Gerao de
Boleto de
2,18
pagamento
TOTAL
R$20,0
NO
R$0,00
R$0,00
R$0,00
GASTO
87
Lista no priorizada
Carrinho de
Lista priorizada
TOTAL PAGO/
TOTAL PAGO/
CUSTO
CUSTO
ESTIMADO
ESTIMADO
14/7 = 2
Compras
Alerta de
3,2
Estoque
Alerta de Estoque
Lista de Mais
16/5 = 3,2
15/5 = 3
Vendidos
Lista de
Mais
Vendidos
Gerao
Gerao de Boleto
de pagamento
24/11 = 2,18
2,18
de Boleto
de
pagamento
Carrinho
de
Compras
Dica:
Ordenando por ROI nos permite identificar a priorizar as
melhores oportunidades. Veja que o item Gerao de Boleto
de pagamento tem a maior oferta global(R$24,00), ele tambm
tem um custo de desenvolvimento alto(R$11,00) e por isso est
mais abaixo na lista de prioridades.
88
podem
alocar
mais
ou
menos
Reais
para
determinados itens.
Interveno governamental: Quando o mercado livre gera
prioridades que no esto nos interesses estratgicos do projeto, o
Product Owner pode intervir e alocar Reais adicionais para um
determinado item. Como em qualquer mercado livre, a interveno
governamental pode ter uma srie de consequncias negativas:
extras Reais injetados no sistema reduzem o valor relativo de outros
89
90
Temas
Tema
Tema
Tema
Tema
Tema
(Base)
Colabora para atingir a meta
Facilidade de desenvolvimento
Score
-1
-2
Legenda:
+ = Mais que
- = Menos que
0 = mesmo que
91
4) Tema B
5) Tema E
ATENO
Existem 2 grandes riscos nesta tcnica. O primeiro a
escolha de critrios equivocados, geralmente quando no foi
bem desenvolvida a viso do produto. O segundo risco est
associado a escolha do Base line, um com prioridade muito
alta far com que muitos temas pontuem negativo. Um base
line muito baixo far com que muitos temas pontuem muito
alto. Assim, a escolha de um base line intermedirio na escala
de prioridade bem importante. Se errarmos na escolha da
base line, poderemos criar distores nos resultados.
92
Disfuncional:
Como
voc
se
sentir
se
esta
93
Disfuncional
Gostaria
Funcional
Deveria
Indiferente
Suporta
No
Gostaria
Gostaria
Deveria
Indiferente
Suporta
No
Gostaria
LEGENDA
M
Mandatrio
Indiferente
Linear
Reverso
Desejado
Questionvel
Funcionalidade
A
Funcionalidade
B
Funcionalidade
C
Desejado
Linear
Mandatrio
Indiferente
Reverso
Questionvel
12
29
22
21
21
23
94
bsico
esperado),
fazer
mximo
de
95
Dica
Para simplificar o planejamento de verses, elimine
dependncias tcnicas, lembre-se que as estrias devem
respeitar o conceito de INVEST.
96
CAPTULO 7
7.1 - Estimativas geis
Um
dos
grandes
desafios
de
profissionais
da
rea
de
baseada
na
opinio
especializada,
informaes
histricas
ou
simplesmente adivinhao.
Estimativa Anloga(Top Down): Usam opinio especializada e
informaes histricas para prever o futuro
Estimativa Paramtrica: Observa os relacionamentos entre as
variveis em uma atividade para calcular estimativas.
97
98
utilizada
pela
comunidade gil,
ns igualmente estamos
99
100
101
102
FORMAO
TEMPESTADE
(Storming)
NORMALIZAO
PERFORMANCE
SUSPENSO
103
uns
sobre
os
outros,
neste
momento
inicia-se
104
ATENO
Quando falamos em CONFLITO, devemos sempre
lembrar que:
O conflito natural e fora uma busca de
alternativas
O conflito uma questo de equipe
A abertura resolve conflitos
A resoluo de conflitos deve se concentrar
em questes e no em personalidade
A resoluo de conflitos deve se concentrar
no presente e no no passado
6) Custo
7) Personalidade
Na fase de Normalizao o time em potencial comea a se tornar
um verdadeiro time, aprendendo como trabalhar uns com os outros e como
time, neste momento o TIME deve criar regras para ajudar\governar o
trabalho do prprio time. Neste momento a liderana um pouco mais
tmida e concentra-se mais no auxilio resoluo de alguns conflitos, assim
como lembrar constantemente das regras criadas por eles mesmos. Nesta
fase um bom momento para desafiar o time, para auxili-lo a se tornar um
time de alta performance.
Na fase de Performance os times so altamente competentes e
comprometidos, autnomos, empoderados, auto organizados e autopoliciados. O time trabalha com um s, com alta performance no trabalho e
nas suas entregas. Cada indivduo conhece bem as caractersticas dos
demais membros do time, a liderana assume um papel de trazer novos
desafios(para que o time resolva) sempre buscando a melhoria contnua.
Muitos times dificilmente chegam a fase final devido a mudanas na sua
composio.
106
Outros
Auto-Gerenciamento
Habilidades Sociais
Auto-Controle
Auto-Controle
Conscincia
Liderana Inspiradora
Adaptabilidade
Direcionamento e
Trabalho em equipe e
Motivao
colaborao
Auto-Conhecimento
Conscincia
Regular
Social
Auto-Confiana
Empatia
Auto-conhecimento
Conscincia Organizacional
Emocional
Compreender o Ambiente
Reconhecer
Precisa Auto-Avaliao
107
Project
Management
Institute(PMI)
existe
uma
108
110
DICA
Para facilitar a comunicao cara-a-cara e o
compartilhamento de conhecimentos, recomendado
que os times sejam de tamanho reduzido, geralmente
at 12 membros ou menos(Lembre-se que o aumento
da complexidade da comunicao diretamente
proporcional ao nmero de pessoas envolvidas).
Quando os projetos so maiores o recomendado
trabalhar com diversos times, utilizando tcnicas como
o Scrum sob Scrum.
111
trabalhamos
com
equipes
virtuais
(distantes
112
113
114
115
MENSAGEM FINAL
Os novos cenrios organizacionais, com o uso estratgico de
informaes e conhecimentos como o principal diferencial competitivo
demanda novas tcnicas de gesto e gerenciamento diferentes das
tradicionais estratgias de comando e controle, assim a adoo de tcnicas
emergentes para projetos orientados valor vem ganhando grande
crescimento
em
diversas
reas
que
lidam
com
profissionais
de
116
SOBRE OS AUTORES:
117
em formas
contato@cursospin.com.br
Av. Djalma Batista, n. 946, sala 08 (Centro Empresarial Santo Remdio) - Vieiralves
Nossa Sra. das Graas Manaus
Telefone (92) 3584-1966
Site: WWW.cursospin.com.br
118