Escolar Documentos
Profissional Documentos
Cultura Documentos
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
2
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
3
Rafael Dias Ribeiro
Horcio da Cunha e Sousa Ribeiro
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 4
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
Contm Referncias
ISBN: 978-85-919102-1-2
CDD 658.404
5
Dedicatria:
6
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
4.2 - Como realizar o TDD ? .......................................................................................42
CAPTULO 5 ...................................................................................................................................47
5.1 - SCRUM ..............................................................................................................................47
5.1.1 - Histria ......................................................................................................................47
5.2 - Pilares SCRUM ..............................................................................................................48
5.3 - O Framework SCRUM ................................................................................................48
5.4 - Artefatos, Eventos e Papis ....................................................................................51
5.4.1 - Backlog de Produto( Product Backlog) ..................................................51
5.4.2 - Backlog da Sprint (Sprint Backlog) ..............................................................51
5.5 - Os papis e responsabilidades no Scrum: .......................................................52
5.6 - Eventos Scrum ...............................................................................................................59
5.6.1 - Sprint ..........................................................................................................................59
5.6.2 - Reunio de Planejamento - Planning Meeting .......................................59
5.6.4 - Scrum Dirio - Daily Scrum .............................................................................60
5.6.5 - Reunio de Reviso da Sprint - Review Meeting .................................61
5.6.6 - Reunio de Retrospectiva da Sprint - Retrospective Meeting ........61
5.6 - Dinmica Bons e Ruins ..............................................................................................63
5.7 - Consideraes: ..............................................................................................................65
5.8 - Dinmica Mercado de Habilidades (Market ofSkills) ...................................66
5.8 - Tcnica PrOpER............................................................................................................68
5.8.1 - Problema: .................................................................................................................68
5.8.2 - Opes: .....................................................................................................................69
5.8.3 - Experimente: ..........................................................................................................69
5.8.4 - Reviso: ....................................................................................................................69
5.8.5 - EXEMPLO: ..............................................................................................................69
CAPTULO 6 ...................................................................................................................................72
6.1 - Planejamento Orientado Valor ...........................................................................72
6.2 - Viso em um projeto gil ...........................................................................................73
6.3 - Planos Adaptativos ......................................................................................................76
6.4 - Planejamento de Release ....................................................................................77
6.5 - User Story .........................................................................................................................78
6.6 - Stories, Temas e EPICS............................................................................................81
6.7 - Priorizao de Backlog...............................................................................................82
6.8 - Priority markets ..............................................................................................................84
6.9 - Theme screening ..........................................................................................................90
6.10 - Kano model ...................................................................................................................92
8
6.11 - MMF Minimum Marketable Feature...............................................................95
CAPTULO 7 ...................................................................................................................................97
7.1 - Estimativas geis ..........................................................................................................97
7.2 - Um pouco mais sobre times geis..................................................................... 102
7.3 - Liderana Adaptativa ................................................................................................. 103
7.4 - Inteligncia Emocional............................................................................................. 107
7.5 - Comunicao e o ambiente de trabalho ......................................................... 108
7.6 - Equipes virtuais........................................................................................................... 112
7.7 - Acompanhamento de produtividade ................................................................. 112
7.8 Cumulative Flow Diagram(CFD) ........................................................................ 114
MENSAGEM FINAL ................................................................................................................. 116
SOBRE OS AUTORES:..................................................................................................... 117
Rafael Dias Ribeiro................................................................................................................ 117
Horcio da Cunha e Sousa Ribeiro .................................................................................. 118
9
CAPTULO 1
1.1 - Introduo
10
como:
11
1.2.1 -Teoria de Cynefin
12
Por exemplo, em uma loja do McDonalds, s existe uma melhor
forma de preparar um hambrguer(sempre a mesma temperatura e sempre a
mesma durao), o procedimento j predefinido e treinado.
13
O sistema imprevisvel em detalhes, mais ainda podemos discernir
padres. So nessas situaes complexas que a colaborao vem tona. A
colaborao funciona bem para cenrios complexos, pois o estilo de
trabalhar de forma colaborativa corresponde natureza das questes que
representam situaes complexas.
14
Desordem: o quinto domnio. o estado de no saber que tipo de
causalidade existe. Em pleno uso, a estrutura do Cynefin tem subdomnios, e
o limite entre simples e catico visto como algo catastrfico.
15
Cenrios simples e complicados so mais comuns em projetos de
construo como avies, pontes, prdios, mquinas de caf, etc. Pois
seguem um fluxo de construo de pea por pea, montagem, testes e esto
prontos para uso, seu processo pode ser decomposto em um plano bem
detalhado por etapas(ou entregas parciais) at o todo estar pronto. Projetos
complexos como softwares, desenhos e redesenhos de processos,
campanhas publicitrias e outros so construdos dia a dia, etapa aps
etapa, assim muito arriscado definir um plano muito detalhado, j que
necessidades e prioridades mudam de acordo com o andamento do projeto(e
pela prpria dinmica das organizaes).
16
1.4 - Projetos Direcionados Valor e Projetos Direcionados
Planos
17
1.4.2 - Projeto Direcionado Valor:
18
depende se voc deseja pendurar um quadro ou fazer uma instalao
eltrica. Podemos concluir que NO existe uma Bala de Prata em
Gerenciamento de Projetos. Assim, o entendimento dos possveis cenrios e
o conhecimento das diversas tcnicas e ferramentas de gerenciamento so
essenciais para o gestor de projetos.
19
CAPTULO 2
2.1 Introduo:
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens
esquerda.
20
2.2 - Indivduos e interaes mais que processos e ferramentas
21
2.4 - Colaborao com o cliente mais que negociao de
contratos
22
2.6 - Os 12 Princpios por trs do Manifesto:
(Disponvel em http://agilemanifesto.org/iso/ptbr/principles.html)
23
2.7 - Declarao de Interdependncia
24
CAPTULO 3
3.1 Feature Driven Development(FDD) - Desenvolvimento
Dirigido a Funcionalidades
Desenvolver um
Crie uma lista de Planeje por
modelo global para o
funcionalidades funcionalidade
produto
25
3.1.2 - Desenvolvimento por Funcionalidade:
Esta prtica envolve decompor as necessidades em funcionalidades
e definir perodos de desenvolvimento de uma ou mais funcionalidades em
intervalos de duas semanas ou mais curtos.
3.1.5 - Inspees:
So revises que ajudam a garantir boa qualidade e design de
cdigo.
3.1.8 - Visibilidade:
Controle e acompanhamento do progresso e dos resultados baseado
em funcionalidades desenvolvidas.
Voc poder aprofundar seus conhecimentos sobre o FDD, acessando o web site
oficial da metodologia, na URL: http://www.featuredrivendevelopment.com/
26
3.2 - Dynamic Systems Development Method(DSDM) -
Metodologia de Desenvolvimento de Sistemas Dinmicos
27
CICLO DE VIDA DSDM
Fonte: http://www.dsdm.org/content/6-lifecycle
28
3.3 - Crystal
Criticidade
(Defeitos causam
perda de ...)
Entregas Frequentes
Melhoria Reflexiva (Verificao constante e busca contnua de
promoo de melhoria e implementao de novos mtodos)
Comunicao Osmtica (Membros so alocados prximos uns
dos outros para melhorar a comunicao, este conceito tambm
conhecido como War Room - Sala de Guerra. Veremos mais
sobre comunicao mais adiante)
29
Segurana Pessoal (O Crystal defende um ambiente seguro
para que todos possam apresentar suas dvidas e
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
O Lean Software Development identifica sete conceitos principais,
so eles:
31
o investimento realizado no desenvolvimento. Como o cliente prioriza o que
deve ser feito primeiro, funcionalidades mais importantes (e as de maior
risco, assunto que ser tratado mais adiante) geralmente so produzidas
mais cedo, e consequentemente, entram em uso mais cedo, gerando maior
retorno.
32
3.5 - KanBan
Fim Incio
Sada Entrada
(+1 Ticket) (-1 Ticket)
Visitante
33
O Quadro Kanban permite visualizar o trabalho que est em
andamento e limitar o WIP. Tradicionalmente (mas NO uma REGRA), o
quadro Kanban dividido em quadros ou status como DO( Fazer)
DOING(Fazendo) DONE(Feito), as tarefas que preciso ser realizadas so
listadas(ou coladas) na parte Fazer, quando elas comeam a ser feitas,
elas mudam para o status Fazendo e quando esto(totalmente) prontas, vo
para o status Feito, bem os status podem ser completamente diferentes, por
exemplo, no caso de desenvolvimento de software poderamos ter
Modelado, Em Desenvolvimento, Desenvolvido, Em implantao,
Pronto. Ou qualquer outro estado que faa sentido para o trabalho e para a
equipe.
2 Limitador
34
estar no inventrio 1 , so duas paralelamente. Este limitador, geralmente
est associado a capacidade de atendimento da equipe.
35
Tornar Regras e Processos Explcitos: Com o quadro mais fcil
discutirmos os trabalhos que esto em andamento, que precisaro ser feitos
e como um trabalho em andamento poder impactar em outro.
36
CAPTULO 4
4.1 - eXtremingProgramming
Valores:
Comunicao
O valor da comunicao visto dentro do time, entre seus
membros, e entre o time e o cliente. Ambos tm igual importncia.
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.
37
Imagem de ciclos de Feedback do XP
Coragem
O XP prega que os desenvolvedores precisam ter coragem para
refatorar o cdigo em prol de melhorias em clareza e design e nada
melhor para dar coragem do que testes automatizados.
Simplicidade
Considere que, na mdia, o tempo de construo de um software
cerca de 30% do tempo investido nele. Os outros 70% so dedicados a
manuteno do sistema. Neste tipo de cenrio, a simplicidade essencial
para tornar esse perodo maior muito agradvel.
O desenvolvedor deve:
Implementar apenas o bsico
No antecipar funcionalidades (No gerar Gold Plating)
38
Propriedade Coletiva do Cdigo
comum que desenvolvedores trabalhem em partes
independentes do cdigo. A consequncia desta abordagem que
cada desenvolvedor se sente responsvel apenas por sua parte.
O ideal o sentimento de time onde todos so responsveis
pelo cdigo. Assim, um desenvolvedor livre para interferir em
qualquer parte do cdigo sem irritar o dono do cdigo.
39
Programar em par exige que as pessoas envolvidas sejam
receptivas, compreensivas umas com as outras, engajadas e,
sobretudo, humildes. necessrio aceitar que somos falveis para
que possamos programar em par. Jerry Weinberg, no livro The
Psychologyof Computer Programming apresenta o termo ego less
programming, ou seja, programao sem ego.
Descubra mais sobre ego less programming no
site:http://blog.codinghorror.com/the-ten-commandments-of-
egoless-programming/
40
Exemplo de acmulo de dbito tcnico ao passar do tempo.
Representa-se na figura acima que quando refatoramos constantemente,
representado na figura com ondas com a legenda Minutos, nosso dbito
perceptivelmente menor do que quando refatoramos com intervalos de
dias ou semanas.
Imagem que representa o custo dos ajustes tcnicos no cdigo durante o tempo do projeto.
41
O XP prega o uso extensivo de testes automatizados que
descrevem o comportamento de uma funcionalidade, preferencialmente
escritos antes mesmo do cdigo que eles testam, prtica que recebe o
nome de desenvolvimento dirigido por testes (Test Driven Development -
TDD).
42
Vejamos como os conceitos do TDD podem ser aplicados utilizando
um exemplo para desenvolvimento de um simulador do jogo de cartas Black
Jack
43
Defeito identificado ! No existe Coringa no Black Jack. Como
testar automaticamente em cada novo incremento para que problemas assim
no ocorram ?
Devemos criar os Critrios de Teste, para o Black Jack vamos testar
se existem:
52 cartas no Baralho.
13 Cartas de Cada Naipe.
No pode existir carta Coringa.
Uma carta de Cada Tipo
44
Classe que testa se existem 52 cartas no baralho e se so 13 de
cada naipe.
Classes para Testes
52 cartas no Baralho --- testado.
13 Cartas de Cada Naipe --- testado.
No pode existir carta Coringa.
Uma carta de Cada Tipo
//..Continuao
public void Verify_Deck_contains_no_joker( )
{
var deck = new Deck( );
Assert.IsFalse(deck.Contains(Card.Coringa ) );
}
}
//..Continuao
public void Verify_Every_Card_in_the_Deck( )
{
var deck = new Deck( );
Assert.IsTrue(deck.Contains(Card. Dois_de_Copas ) );
Assert.IsTrue(deck.Contains(Card. Tres_de_Copas ) );
45
Este pequeno exemplo ilustra como gerar classes em funo dos
testes necessrios. Uma vez implementado qualquer novo incremento no
cdigo ir passar por estes testes, j que eles fazem parte do cdigo.
46
CAPTULO 5
5.1 - SCRUM
O que SCRUM ?
5.1.1 - Histria
47
5.2 - Pilares SCRUM
Transparncia:
Todo o processo deve estar visvel a todos os envolvidos. Esta
transparncia deve ser refletida, no ambiente, nas pessoas e nos
processos.
Inspeo:
O processo em si deve ser inspecionado regularmente na busca por
anomalias e/ou oportunidades de melhorias.
Adaptao:
Caso a inspeo detecte algum processo que precise ser ajustado ou
melhorado, as adaptaes devero ser feitas o mais rpido possvel.
O quanto antes as mudanas sejam feitas, antes o novo processo
proposto testado e validado.
48
O projeto comea com uma viso clara oferecido pelo negcio, e um
conjunto de caractersticas do produto em ordem de importncia. Esses
recursos fazem parte da carteira de produtos, que mantido pelo cliente ou
representante do cliente referido como o Product Owner. Uma caixa de
tempo comumente referido como uma iterao ou Sprint, a quantidade de
tempo que a equipe tem para concluir as caractersticas selecionadas.
49
Sprint. Nenhuma alterao para o Sprint Backlog so permitidos, no entanto,
o Product Backlog pode ser alterado, em preparao para o prximo Sprint.
50
5.4 - Artefatos, Eventos e Papis
Artefatos
O Scrum prev alguns artefatos que nos permite ter uma viso sobre
o andamento do projeto e da Sprint. Estes artefatos so conhecidos como
Backlog.
O formato da lista pode variar de acordo com cada time, pode ser
formadas por casos de uso, Funcionalidades (do FDD), porm os mais
comuns so user stories, que veremos mais adiante quando tratarmos de
Backlog e priorizaes.
52
O Product Owner uma pessoa e no um comit. O Product
Owner pode representar o desejo de um comit no Backlog do
Produto, mas aqueles que quiserem uma alterao nas
prioridades dos itens de Backlog devem convencer o Product
Owner. Para que o Product Owner tenha sucesso, toda a
organizao deve respeitar as suas decises. As decises do
Product Owner so visveis no contedo e na priorizao do
Backlog do Produto. Ningum tem permisso para falar com a
Equipe de Desenvolvimento sobre diferentes configuraes de
prioridade, e o Time de Desenvolvimento no tem permisso para
agir sobre o que outras pessoas disserem.
53
Aps a concluso das entregas do projeto, na finalizao do projeto,
fase conhecida como Post-Game:
54
O Scrum Master ajuda todos a mudarem estas interaes para
maximizar o 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
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
do sistema. Processos de auto organizao so ubquos na natureza: de clulas a
rgos e organismos, de indivduos a organizaes sociais, de casas a bairros,
cidades, etc.
(Fonte:http://cienciaecultura.bvs.br/scielo.php?pid=S0009-67252011000100010&script=sci_arttext)
56
Este comportamento observado em empresas/departamentos de software
onde os desenvolvedores disputam em horrio de trabalho campeonatos de vdeo
game e ainda sim entregam seus trabalhos. Isso provoca um choque cultural na
empresa que pode atingir at a diretoria executiva com essa nova forma de
relacionamento.
57
Como regra geral, podemos dividir os papis e responsabilidades
como:
58
5.6 - Eventos Scrum
5.6.1 - Sprint
59
Na primeira parte, o Product Owner apresenta o conjunto de
caractersticas que ele gostaria de ver concluda no Sprint ("o qu"), os itens
do topo do backlog do produto. O Time avalia o esforo necessrio para a
concluso de cada item e negocia o que possvel entregar na Sprint.
60
O objetivo desta reunio melhorar a comunicao na equipe e dar
para todos uma viso mais clara do andamento do time na Sprint, alm de
facilitar a identificao e resoluo de problemas e impedimentos.
61
ambientes no geis), pois permite intensificar as caractersticas fortes de
cada time e eliminar pontos de fraqueza.
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
2) Quando todos finalizarem, colam-se os post its em um lugar
visvel(veja um exemplo de quadro sugerido abaixo)
64
5) Se faz a leitura dos pontos bons !(Prticas que devem ser
mantidas)
5.7 - Consideraes:
65
5.8 - Dinmica Mercado de Habilidades (Market ofSkills)
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
3) Informaes adicionais. Apresente o que voc tiver vontade para
o time( extra time, extra produto, ...) que voc sinta vontade de compartilhar
5) Defina aes !
67
Aps aes como programao pareada, a tendncia que o time
compartilhe conhecimento e melhore suas habilidades. A prxima dinmica
poderia gerar um resultado melhor, como o ilustrado abaixo:
5.8.1 - Problema:
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 ?
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.
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.
69
Deixe-os segurando o beb: Voc precisa de algum para cobrir a voc:
pergunte se Jack pode ajud-lo, executando o amanh o Daily Scrum.
Espere e veja: No fazer nada, e esperar para ver se a equipe faa que
Jack perceba que o seu atraso um problema por si s.
Experimente:
Voc escolhe a opo para primeiro falar com Jack sobre isso. Inicie
a conversa, mencionando que voc percebeu que ele perdeu o Daily Scrum
algumas vezes. Ele parece genuinamente surpreso que isso era importante,
j que a partir de sua perspectiva, seu trabalho no est diretamente ligado a
nenhuma em estrias de qualquer cliente, por isso certamente que ele no
precisaria estar l. Explique o motivo que sua preocupao que ele est
perdendo informaes de seus companheiros de equipe que precisaro ser
consideradas na construo do ambiente de teste novo. Tambm explique
que o Daily Scrum para a equipe, e no para o cliente. Sugerira que ele
convoque uma reunio com o testador(e time) para verificar as questes que
provavelmente no foram atendidas. Ele acena que concorda ele chegar no
horrio da prxima Daily Scrum.
70
Tire o corpo fora: Transfira o problema para outra pessoa dentro
ou fora da equipe
Anlise de causa raiz: Procure a causa raiz do problema
Educar a equipe: Fornea a equipe mais informaes para que
eles vejam uma soluo
Coloque-os no comando: entregue a responsabilidade para a
equipe ou a um membro da equipe.
71
CAPTULO 6
6.1 - Planejamento Orientado Valor
72
6.2 - Viso em um projeto gil
73
Uma das tcnicas bem interessantes de se iniciar a identificao e
criao da Viso conhecida como Elevator Statement, esta tcnica prev
que voc deve apresentar o produto que ser criado em poucos segundos,
como em uma viagem no elevador. Como sugesto, existe um modelo
proposto apresentado abaixo.
Nome do Produto
Grficos
Trs ou quatro pontos chave(benefcios) para vender o
produto
Principais funcionalidades no verso
Principais requisitos operacionais
74
Voc pode fazer esta dinmica com o time envolvido no projeto
usando caixa de sapato, cola e canetas coloridas lembrem-se que na
agilidade temos diversas tcnicas Low-Tech, High Touch.
75
A tcnica Remember the Future no um jogo de
adivinhao do futuro e sim uma ferramenta que nos auxilia
no entendimento do sucesso do projeto/produto e como
podemos atingir o objetivo final. Logo, NO plano, NO
cronograma, NO determinstico!
76
entender o que realmente necessrio para o sucesso do projeto. A figura
abaixo apresenta a cebola do planejamento estratgico em projetos
orientados valor.
Cebola de Planejamento
77
Observe que sero necessrios que o Product Backlog j esteja
definido e priorizado, as datas das Sprints definidas, e (se for um time j
existente) a velocidade mdia do time.
78
Na tcnica de User Story, o dono do produto descreve o que precisa
ser feito, identifica quem usar a funcionalidade e porqu (ajuda a no gerar
itens que no agregam valor ao negcio).
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.
79
Valiosa para usurios e clientes - A estria precisa estar associada a
um valor para o usurio ou clientes, sem isso, no existe razo para
ela existir.
poucos personagens.
Exemplo 1:
Uma estria para criar uma panela especfica:
80
Exemplo 2:
81
As estrias que esto agrupadas no tema NO esto
associadas a nenhuma regra de precedncia, lembre-se
que as estrias devem ser Independentes.
82
Em geral, a priorizao do backlog do produto segue uma sequncia
lgica, conforme apresentado abaixo:
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"
83
6.8 - Priority markets
Dica:
O nmero exato do total de Reais de desenvolvimento no critico.
Na prtica valores pequenos como R$10,00 por participante, j podem
apresentar uma distribuio que representa bem a priorizao. No nosso
exemplo utilizaremos um valor de R$20,00 por peso/participante, como temos
5, o total ser de R$100,00 de desenvolvimento
84
Por exemplo:
85
TOTAL NO R$40,00 R$20,00 R$20,00 R$20,00
GASTO
86
pagamento
TOTAL NO R$20,00 R$0,00 R$0,00 R$0,00
GASTO
ESTIMA PAGO/
(2.0) (1.0) (1.0) (1.0) PAGO
DO(DE CUSTO
ESTIMADO
V.
TIME)
Carrinho de R$6,00 R$8,00 R$5,00 R$5,00 R$14,00 7 14/7 = 2
Compras
Alerta de R$5,00 R$4,00 R$3,00 R$4,00 R$16,00 5 16/5 =
Estoque 3,2
Lista de R$3,00 R$3,00 R$4,00 R$5,00 R$15,00 5 15/5 = 3
Mais
Vendidos
Gerao de R$6,00 R$5,00 R$8,00 R$6,00 R$24,00 11 24/11 =
Boleto de 2,18
pagamento
TOTAL R$20,0 R$0,00 R$0,00 R$0,00
NO 0
GASTO
87
Lista no priorizada Lista priorizada
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
Passo 7: Realocao de Reais de Desenvolvimento
89
Reais, resultando em inflao; os interessados podem tambm se
sentem marginalizados por terem suas prioridades substitudas.
DICA:
Esses critrios podem ser definidos a partir da nossa
viso de produto, ou de requisitos de negcio a que
desejamos atender. Exemplos comuns podem incluir itens
como Colabora para atingir a meta, Impacto nos
processos organizacionais, Elimina problemas antigos
dos usurios, Facilidade de desenvolvimento,
Posicionamento do produto, etc.
90
Por exemplo, aps a escolha podemos ter um quadro conforme
apresentado abaixo.
CRITRIOS Temas
Tema Tema Tema Tema Tema
A B C D E
(Base)
Colabora para atingir a meta + + 0 - 0
Elimina problemas antigos dos usurios + - 0 0 -
Facilidade de desenvolvimento + - 0 + -
Impacto nos processos organizacionais 0 0 0 + 0
Score 3 -1 0 1 -2
Legenda:
+ = Mais que
- = Menos que
0 = mesmo que
1) Tema A
2) Tema D
3) Tema C
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
3. Desejadas (Delighters): so caractersticas que satisfazem o
cliente quando esto presentes no produto, porm, caso no estejam
no iro causar insatisfao.
Por exemplo:
Por exemplo:
93
E ento utilizando-se a seguinte categorizao para cada conjunto de
respostas(funcional e no funcional):
Disfuncional
No
Gostaria Deveria Indiferente Suporta
Gostaria
Gostaria Q D D D L
Deveria R I I I M
Indiferente R I I I M
Funcional
Suporta R I I I M
No
Gostaria R R R R Q
LEGENDA
M Mandatrio I Indiferente
L Linear R Reverso
D Desejado Q Questionvel
94
Com base nesse ltimo quadro temos que a funcionalidade A o
bsico que os clientes esperam ter, veja que temos 29 entrevistados que
classificaram a funcionalidade A como Mandatrio. Mas preciso lembrar
que, uma vez alcanado o bsico, no devemos mais adicionar esforo
nessa funcionalidade pois ela no ir aumentar a satisfao do cliente.
Devemos apenas mant-la. A funcionalidade B parece ser vista por algumas
pessoas como bsica e por outras como quanto mais, melhor e a
funcionalidade C vista como um diferencial. Portanto, a prioridade seria A >
B > C.
95
Dica
96
CAPTULO 7
7.1 - Estimativas geis
97
Estimativa de Trs Pontos(Anlise PERT): Considera a mdia
entre a estimativa no melhor cenrio(O), adicionada a quatro vezes a
estimativa mais provvel(M), mais a estimativa do pior cenrio(P) , divido por
seis.
( P + 4M +O ) / 6
98
Veja a histria relatada por James Surowiecki que em seu trabalho
intitulado A Sabedoria das Multides queapresenta uma experincia
realizada em 1906, quando o cientista britnico Francis Galton ficou chocado
com o resultado de um experimento realizado por ele, em uma feira
municipal. O desafio era que um aougueiro profissional deveria adivinhar
com preciso o peso de um boi abatido. Sua surpresa ocorreu ao descobrir
que pessoas que visitavam a feira(com pouca ou nenhuma experincia em
cortes de carne) eram capazes no s de adivinhar o peso final do animal,
mas eram capazes de adivinhar com grande preciso(inclusive com
quilogramas e os detalhes em gramas).
99
Exemplo de cartas que geralmente so utilizadas no Planning Poker
100
Geralmente o baralho do Planning Poker apresenta cartas com
escala da sequncia de Fibonacci, isso se deve ao fato da sequncia de
Fibonacci ser uma funo quadrtica, ao invs de uma funo linear, assim,
as diferenas entre valores so produzidas de forma muito rpida criando
intervalos logo no incio da sequncia, veja que as estimativas apresentam
erros, mas quando podemos comparar as tarefas(uma tarefa com 8 pontos
no significa que ela tem exatamente este tamanho mas algo entre 5 e 13
pontos) conseguimos dimensionar com mais preciso o esforo que dever
101
O Tamanho do esforo deve ser relativo. Isto , quando dizemos
que para entregar a estria A definimos 8 pontos e para a estria
B 16 pontos, significa que o esforo para entregar B o dobro de
A(mesmo que haja uma pequena variao devido a natureza
imprecisa das estimativas geis). Observe que neste ponto
devemos estar atento as estimativas por afinidade, podemos
agrupar as estrias por proximidade de esforo pontuado(pelo
TIME), o que facilita o dimensionamento do trabalho como um todo.
102
Lderes de times geis devem concentrar-se nos fatores
humanos(pessoas e relacionamentos) para obterem o melhor
resultado.
FORMAO
PERFORMANCE
TEMPESTADE NORMALIZAO
(Storming)
SUSPENSO
103
Na fase de Formao os membros (ainda no so um Time)
comeam a trabalhar em grupo, nesta fase eles iniciam o processo de
aprendizado uns sobre os outros, neste momento inicia-se o
autoconhecimento do futuro time. Nesta fase identificamos um grupo
altamente comprometido, porm sem grandes conhecimentos, logo, a
liderana dever atuar bastante no direcionamento do trabalho, para isso
questionamentos como: Deixe-me ver isso? Onde est o problema? Qual o
prximo passo? Sero bem comuns.
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
1) Cronogramas
2) Prioridades do Projeto
3) Recursos
4) Opinies Tcnicas
5) Procedimentos Administrativos
105
6) Custo
7) Personalidade
106
7.4 - Inteligncia Emocional
Prprio Outros
Auto-Gerenciamento Habilidades Sociais
Auto-Controle Auto-Controle
Conscincia Liderana Inspiradora
Regular
Adaptabilidade Desenvolvimento dos demais
Direcionamento e Trabalho em equipe e
Motivao colaborao
Auto-Confiana Empatia
Auto-conhecimento Conscincia Organizacional Reconhecer
Emocional Compreender o Ambiente
Precisa Auto-Avaliao
107
"O humor e comportamento do Lder conduz os humores e
comportamentos de todos os outros. Um chefe mal-humorado
e cruel cria uma organizao txica preenchida com
sentimentos negativos que ignoram as oportunidades."
108
Observe que muitas vezes no dedicamos o tempo necessrio neste
gerenciamento, mas vamos a um simples exemplo:
[N *(N-1)] / 2
Onde: N o nmero de pessoas envolvidas no projeto
109
influenciar o fracasso ou o sucesso do projeto, claro que algumas partes
interessadas podem influenciar mais do que outras em um projeto, mas
importante que TODAS sejam identificadas. Dentre muitos fatores, a
identificao das partes interessadas, possibilita ao gerente ter uma viso
dos interesses e expectativas de cada parte em relao ao projeto, o que
ajuda muito em negociaes e no gerenciamento das expectativas.
110
espera por uma informao ou deslocamento) alm de promover a
comunicao osmtica.
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
7.6 - Equipes virtuais
Sempre que possvel promova pelo menos uma reunio onde todos
os membros do time estejam presentes, mesmo que no dia a dia eles
trabalhem distante, uma atividade para que eles se conheam(fisicamente)
catalisa a fase de formao e melhora as futuras comunicaes.
112
sprints. Observe que o eixo tem comportamento decrescente e inicia-se no
topo do eixo vertical e termina na base(ponto O) deste mesmo eixo.
113
Podemos acompanhar o Previsto X Realizado em cada Sprint, assim
como a velocidade do time(pontos ou horas) por Sprint, o que facilitar o
planejamento para prximas verses do produto.
114
est pendente, isto , trabalho no iniciado, a rea laranja representa o
trabalho em progresso e a azul o trabalho pronto.
Dica:
Quando o grfico de seu time apresenta grande distncia
do pronto para o no iniciado significa que seu time est
com muitos trabalhos em progresso, possvel(e
aconselhvel) determinar um limitador para atividades em
andamento, por exemplo, s 2 estrias em paralelo, para
evitar o acmulo do trabalho em andamento e o atraso
nas entregas.
115
MENSAGEM FINAL
116
SOBRE OS AUTORES:
117
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.
ISBN: 978-85-919102-1-2
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 118
Site: WWW.cursospin.com.br