Gerenciamento de Projetos de Software

ENGENHARIA DE SOFTWARE
GERENCIAMENTO DE PROJETOS DE SOFTWARE

Professor: Rafael Dias Ribeiro
Prezado aluno,
Esta apostila a verso esttica, em formato .pdf, da disciplina online e contm
todas as informaes necessrias a quem deseja fazer uma leitura mais linear do
contedo.
Os termos e as expresses destacadas de laranja so definidos ao final da
apostila em um conjunto organizado de texto denominado NOTAS. Nele, voc
encontrar explicaes detalhadas, exemplos, biografias ou comentrios a
respeito de cada item.
Alm disso, h trs caixas de destaque ao longo do contedo.
A caixa de ateno usada para enfatizar questes importantes e implica um
momento de pausa para reflexo. Trata-se de pequenos trechos evidenciados
devido a seu valor em relao temtica principal em discusso.
A galeria de vdeos, por sua vez, aponta as produes audiovisuais que voc
deve assistir no ambiente online aquelas que o ajudaro a refletir, de forma
mais especfica, sobre determinado conceito ou sobre algum tema abordado na
disciplina. Se voc quiser, poder usar o QR Code para acessar essas produes
audiovisuais, diretamente, a partir de seu dispositivo mvel.
Por fim, na caixa de Aprenda mais, voc encontrar indicaes de materiais
complementares tais como obras renomadas da rea de estudo, pesquisas,
artigos, links etc. para enriquecer seu conhecimento.
Aliados ao contedo da disciplina, todos esses elementos foram planejados e
organizados para tornar a aula mais interativa e servem de apoio a seu
aprendizado!
Bons estudos!
Gerenciamento de Projetos de Software Apostila
Apresentao
Com uma economia cada vez mais dinmica e competitiva, informao e
conhecimento surgem e se propagam cada vez mais rpido. No ambiente
corporativo, esse dinamismo provocou um elevado nmero de projetos
organizacionais para atender s diversas demandas.
H uma crescente necessidade 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. Nesta disciplina, vamos conhecer
as prticas internacionais utilizadas no gerenciamento de projetos orientados a
valor.
Sendo assim, essa disciplina tem como objetivos:
1. Compreender as principais diferenas entre Projetos Orientados a Planos e
Projetos Orientados a Valor.
2. Conhecer as principais caractersticas das metodologias e mtodos geis.
3. Compreender como o fator humano influenciar todo o projeto.
Aula 1: Fundamentos do Gerenciamento de Projetos

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.
Nesta aula, iremos compreender o que realmente um projeto e vamos
identificar as caractersticas de projetos orientados a planos e de projetos
orientados a valor.
Objetivo:
1. Compreender o que um projeto e suas caractersticas;
2. Conhecer os cinco domnios do Cynefin Framework e como eles influenciam
no gerenciamento de projetos.
Contedo
Conceituao
muito comum, no meio corporativo, ouvirmos:
Prximo ms, iniciamos o Projeto XYZ (...)
Esto todos dedicados ao Projeto XYZ (...)
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, 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.
Conceituao
muito comum, no meio corporativo, ouvirmos:
Prximo ms, iniciamos o Projeto XYZ (...)
Esto todos dedicados ao Projeto XYZ (...)
A definio do PMBoK-Project Management Body of Knowledge, sobre projeto,
: Um projeto um esforo temporrio empreendido para criar um
Observe que os projetos possuem caractersticas bem significativas, 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.
Anlise de ambientes
No livro Management 3.0, de Jurgen Appelo, o autor procura explicar as
diferenas entre os possveis ambientes organizacionais, nos quais projetos
ocorrem, utilizando duas dimenses distintas.
A primeira dimenso diz respeito estrutura do sistema:
Simples: fcil de entender;
Complicado: muito difcil de entender.
A segunda dimenso diz respeito ao comportamento do sistema:
Ordenado: totalmente previsvel;
Complexo: parcialmente previsvel, mas com muitas surpresas;
Catico: imprevisvel.
Teoria de Cynefin
Outra abordagem sobre os ambientes organizacionais o Cynefin Framework, de
Dave Snowden, que descreve uma perspectiva sobre a natureza evolutiva de

sistemas complexos, inclui sua incerteza inerente.
O nome serve como um lembrete de que todas as interaes humanas so
fortemente influenciadas e, muitas vezes, determinadas por nossas experincias,
tanto atravs da interferncia direta da experincia pessoal, bem como atravs
da experincia coletiva, tais como histrias ou msica.
O Cynefin Framework tem cinco domnios. Vamos ver os quatro primeiros.
Teoria de Cynefin - Simples

No Simples, voc faz X e voc sempre ter Y, e no importa quantas vezes voc
faz X, voc obter o mesmo resultado Y. Voc pode prever com confiana o
resultado final da atividade. Nesses casos, a coordenao pode ser usada com
grande efeito. Aqui, a relao entre causa e efeito bvia para todos. A
abordagem : Sentir - Categorizar - Responder e, assim, podemos aplicar as
melhores prticas (Best Practice).
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.
Teoria de Cynefin - Complicado

J no Complicado, existe uma relao entre causa e efeito, porm voc tem
que investir tempo e energia em trabalhar fora dessa relao e, muitas vezes, h
uma srie de possveis respostas. Esse o reino de especialistas que concentram
tempo e energia em trabalhar tais relaes de causa e efeito. Nesse caso, a
cooperao eficaz nesse domnio, porque muitas vezes h um objetivo final
claro em mente, mas voc precisa das foras combinadas de uma gama de
pessoas para alcan-lo. A relao entre causa e efeito requer uma anlise ou
alguma outra forma de investigao e / ou a aplicao de conhecimento
especializado. A abordagem sentir - analisar - responder e, nesse caso,
podemos aplicar boas prticas (Good Practice).
Por exemplo, existem diversas formas de se criar a mistura do concreto em
uma obra. Dependendo da temperatura, umidade, ferramenta e outros fatores,
pode-se utilizar uma tcnica em detrimento de outra. Por exemplo, na obra da
usina de Itaipu, na mistura do concreto, foi utilizado gelo, em vez de gua no
estado lquido, para evitar microfissuras. Em uma construo, no comum se
utilizar gelo no processo de concretagem.
No Complexo, esse domnio caracterizado por causas e efeitos que so to
entrelaados e intrincados que as coisas s fazem sentido em retrospecto. Voc
ouve as pessoas dizerem: "Ah, este resultado aconteceu porque (...)", mas se
voc voltar um pouco atrs e verificar o que aconteceu, de fato, vai obter um
resultado diferente.
Retroceder e voltar a jogar, e ainda ter outro resultado. Esse fenmeno ocorre
porque, em situaes complexas, tudo to interligado que uma pequena
mudana em uma parte do sistema pode ter um impacto enorme em outro lugar
e vice-versa.
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.
Complexidade imprevisvel, colaborativa, adaptvel; complexidade
confusa difcil trabalhar a questo, e muito menos a resposta colaborativa,
pois envolve reunir uma diversidade de pessoas e talentos para experimentar,
criar e testar possveis abordagens para a soluo de um determinado problema.
Complexidade imprevisvel, isto , dependendo dos fatores (ex.: clima
organizacional, relacionamento interpessoal, autoconhecimento da equipe,
conhecimento prvio do trabalho que ser realizado e outros) no temos a
certeza do resultado produzido. Assim, no ambiente complexo, temos um grande
esforo para desenvolver o aspecto de confiana entre os membros da equipe
para que proporcione maior criatividade e, dessa forma, inovaes. A relao
entre causa e efeito s pode ser percebida em retrospecto, mas no com
antecedncia. A abordagem probabilidade - sentir - responder e, assim,
podemos aplicar a prtica 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.
Teoria de Cynefin Catico e desordem

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.
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.
Um exemplo bem interessante sobre a mudana do ambiente de simples para
catico ilustrado no filme, Um Dia de Fria (Falling Down, 1993), no qual o ator
principal se irrita com uma regra (normal em sistemas simples) e provoca algo
catastrfico.
Tolerncia ao erro
Atravs da atividade anterior, fomos capazes de identificar cenrios simples,
complexos e complicados. Iremos analisar agora a tolerncia ao erro (ou melhor,
possibilidade de aprender com o erro) e o tempo de resposta do sistema. Nos
cenrios caticos e complexos, o erro mais bem entendido do que nos cenrios
simples e complicados, j que a relao causa-efeito no existe ou
desconhecida. Essa aceitao conhecida com Fail Fast ou Learning Fast.
Nos cenrios simples e caticos, o tempo de resposta precisa ser mais rpido do
que nos cenrios complexos e complicados, pois a demora pode provocar perdas
significativas. Por exemplo, caso voc entre em uma lanchonete do tipo fast
food (cenrio simples) e o atendimento demore por volta de 20 minutos, voc

provavelmente ir procurar outro estabelecimento para fazer sua refeio ou, em
um prdio incendiando (cenrio catico), voc no poder demorar muito para
agir.
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). Preparamos uma tabela que compara o trabalho
industrial com profissionais do conhecimento.
Projetos direcionados a valor e projetos direcionados a planos

Cenrios de projetos de construo, normalmente, seguem uma abordagem
orientada a plano, j projeto complexo deve ter uma abordagem orientada a
valor, visto que a entrega final tem grande probabilidade de no ser a ideia inicial
do projeto.
10
Em projetos direcionados a plano, como o prprio nome sugere, temos um

grande esforo no planejamento, pois um bom plano aumenta as chances de
uma boa execuo. O guia de boas prticas PMBok define 47 processos, em 10
reas de conhecimento, que aumentam as chances de sucesso de um projeto.
Projetos orientados a valor

Em projetos orientados a valor, quando se investe muito no planejamento,
gerado um risco muito grande ao projeto, j em cenrios de grande incerteza, o
planejamento precisar ser baseado em muitas premissas (eventos incertos que
definimos como verdade para fins de planejamento) que sero falsas, o que pode
gerar tantas mudanas no plano original que o esforo de adaptao no
compensaria a energia gasta no desenvolvimento do plano original.
Outro ponto importante que tcnicas de gerenciamento de projetos
complicados, como as boas prticas do PMBoK (ex.: plano de comunicaes,
estimativas de custo, declaraes de trabalho de aquisio etc.), podem ser
aplicadas em projetos complexos, assim como tcnicas de agilidade (ex.: reunio
de retrospectiva, reunio de planejamento da interao, definio de viso do
produto, planejamento de release etc.), de projetos complexos, podem ser
aplicadas em cenrios complicados e simples, tudo depende da anlise do
gerente do projeto.
Perguntar qual a melhor forma de gerenciar um projeto sem conhecer o projeto
em si, ambiente organizacional e o produto do projeto equivale a perguntar o
11
que melhor, o martelo ou o alicate? A resposta 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.
Projeto e programa
Conforme vimos no incio desta aula, um projeto um esforo temporrio
empreendido para criar um produto, servio ou resultado exclusivo. E
possui algumas caractersticas, como:
Feito por pessoas;
Elaborado progressivamente;
Sofre restries;
Tem incio e fim (esforo temporrio);
Cria um resultado nico (criar um produto, servio ou resultado exclusivo).
J sobre programa, o PMI (Project Management Institute) o define como: um
grupo de projetos relacionados gerenciados de modo coordenado para a
obteno de benefcios e controle que no estariam disponveis se eles fossem
gerenciados individualmente.
Projeto e programa
O PMI (Project Management Institute) define portflio como: um conjunto de
projetos,
programas
ou
outros
trabalhos
agrupados
para
facilitar
gerenciamento eficaz desse trabalho, a fim de atingir os objetivos de negcios

estratgicos.
12
Preparamos uma tabela com as principais consideraes sobre portflio e

gerenciamento de projetos organizados.
13
Atividade proposta
Observe o texto abaixo para responder questo:
Uma empresa, inicialmente, era formada por trs engenheiros altamente
qualificados que comearam a pesquisar sobre como fazer um carro popular para
comercializao no mercado nacional. O desenvolvimento de um automvel
completo no era muito difundido na poca. Assim, para se criar um prottipo,
foram feitas diversas pesquisas (com erros e acertos), prottipos de suspenso,
posio de chassi etc. Depois de um ano, foi criado o primeiro automvel, porm,
seu custo era elevado e o tempo de produo era impossvel para atender ao
objetivo de criao do carro popular.
No ano seguinte, contrataram alguns tcnicos em mecnica e produziram novos
veculos. Durante a produo, desenvolveu-se um guia de boas prticas, o que
auxiliou muito o desenvolvimento de automveis e reduziu o custo de produo,
mas ainda era muito caro desenvolver um carro. Nos anos seguintes, os tcnicos
das boas prticas escolheram uma e a elegeram a melhor prtica, assim foi
possvel decompor o trabalho em partes e criar a linha de montagem. Como o
trabalho j estava planejado, a mo de obra no precisava ser de engenheiros
ou tcnicos, o que barateou a produo do automvel e permitiu a produo em
massa.
Com base no que estudamos at agora e em seus conhecimentos prvios,
classifique cada etapa do projeto em cenrio complexo, cenrio complicado ou
cenrio simples.
Chave de resposta: No primeiro momento em que estamos descobrindo como
montar o carro, testando possibilidades, errando e aprendendo, estamos em um
cenrio complexo. Com o passer do tempo, descobertas das relaes de causa e
efeito e de formas que podem provocar a transformao das entradas em sadas,
estamos no cenrio complicado. Aps definirmos a melhor forma de montar cada
compontente e definir as regras de montagem, simplificamos o processo e assim
14
podemos trabalhar com mais velocidade, escala e com o custo mais baixo. Neste
momento estamos no cenrio Simples.
Referncias
BARCAUI,
Andr
B.
Por
que
gerenciar
projetos?
Disponvel
em:
http://exame.abril.com.br/carreira/noticias/por-que-gerenciar-projetosm0042508; Acesso em: 25 nov. 2013.

MANRIQUE, Dlcio Ferreira. Para que serve o gerenciamento de projetos?.
Disponvel em: http://www.mundopm.com.br/noticia.jsp?id=251; . Acesso em:
28 nov. 2013.
Exerccios de fixao
Questo 1
No uma caracterstica de projetos de construo:
a) O trabalho estvel
b) nfase na execuo de etapas
c) Comando e controle
d) Mais estruturao com menos deciso
e) Inovao contnua
Questo 2
No uma caracterstica de projetos de profissionais do conhecimento:
a) O trabalho visvel
b) nfase na mudana
c) Autonomia
d) Trabalhador visto como ativo e no como custo
15
e) Foco nas perguntas certas
Questo 3
Correlacione os nmeros:
1 - Voc faz X e voc sempre ter Y, e no importa quantas vezes voc faz X,
voc obter o mesmo resultado Y. A relao entre causa e efeito bvia para
todos, a abordagem : Sentir - Categorizar - Responder e assim, podemos aplicar
as melhores prticas.
2 - Existe uma relao entre causa e efeito, porm voc tem que investir tempo
e energia em trabalhar fora dessa relao e muitas vezes h uma srie de
possveis respostas. A relao entre causa e efeito requer uma anlise ou alguma
outra forma de investigao e / ou a aplicao de conhecimento especializado. A
abordagem a Sentir - Analisar - Responder e, neste caso, podemos aplicar boas
prticas.
3 - Este domnio caracterizado por causas e efeitos que so to entrelaadas e
intrincada que as coisas s fazem sentido em retrospecto. O sistema
imprevisvel em detalhes, mais ainda podemos discernir padres. A colaborao
funciona bem para estes cenrios, pois o estilo de trabalhar de forma colaborativa
corresponde natureza das questes que representam estas situaes. A
abordagem Probabilidade - Sentir - Responder e, assim, podemos aplicar
prticas emergentes.
4 - Este o lugar onde impossvel discernir a relao entre causa e efeito. A
melhor abordagem neste domnio simplesmente agir. No h nenhuma relao
entre causa e efeito no nvel de sistemas, a abordagem Agir - Sentir - Responder
e podemos descobrir novas prtica.
( ) Catico
( ) Complexo
( ) Simples
16
( ) Complicado.
a) 4,3,1,2
b) 3,2,1,4
c) 4,3,2,1
d) 4,2,1,3
Questo 4
Segundo o PMI (Project Management Institute), um projeto um esforo
temporrio empreendido para criar um produto, servio ou resultado
exclusivo. Marque a opo que no representa uma caracterstica de projeto.
a) Feito por pessoas
b) Elaborado progressivamente
c) Repete-se todos do meses
d) Tem incio e fim (esforo temporrio)
e) Cria um resultado nico (criar um produto, servio ou resultado exclusivo)
Questo 5
Em relao ao ESCOPO, temos consideraes diferentes quando observamos
Projetos, Programas e Portflios. Marque a alternativa mais CORRETA sobre
Escopo no contexto de Projetos.
a) Tm objetivos definidos. Escopo elaborado progressivamente ao longo
do ciclo de vida.
b) Tm grande alcance e Proporcionam benefcios mais significativos.
c) Tm um mbito organizacional, e mudam de acordo com os objetivos
estratgicos da organizao.
17
d) Tm
mbito
processual
Proporcionam
melhoria
contnua
organizacional.
e) Tem objetivos claros e devem surpreender o solicitande adicionando novas
funcionalidades que podero ser teis no futuro, mesmo quando no
solicitadas.
Questo 6
Em relao a MUDANAS, temos consideraes diferentes quando observamos
Projetos, Programas e Portflios. Marque a alternativa mais CORRETA sobre
Mudanas no contexto de Projetos.
a) Os gerentes esperam mudanas e implementam processos para manter o
gerenciamento e o controle de mudana.
b) Gestores esperam mudanas a partir de dentro e de fora do programa e
esto preparados para administr-las.
c) Gestores monitoram continuamente as mudanas no ambiente interno e
externo da organizao.
d) Os gerentes no autorizam mudanas pois aps planejamento a mudana
inviabiliza o plano de gerenciamento.
e) Todos as mudanas so bem aceitas e incorporadas imediatamente no
plano de projeto atendendo as necessidades de negcio.
Questo 7
A definio abaixo de progamas. preencha a lacuna:
Um grupo de _____________ relacionados gerenciados de modo coordenado
para a obteno de benefcios e controle que no estariam disponveis se eles
fossem gerenciados individualmente.
18
a) PROJETOS
b) PORTFLIO
c) PROCESSOS
d) VALORES
e) PARTES INTERESSADAS
Questo 8
Preencha as lacunas
DEFINIO DE ________________ : Uma parte menor do __________ total,
que pode ter certa autonomia, mas sua existncia no faz sentido sozinha.
Normalmente, terceirizada ou delegada a outra rea.
a) SUBPROJETO - PROJETO
b) PROCESSO - PROJETO
c) PROJETO - SUBPROJETO
d) PROJETO - PROCESSO
e) PROTFLIO - PROJETO
Questo 9
Marque a alternativa que apresente erro:
a) Temos dois tipos de projetos, orientados a Planos e Orientados a valor,
logo um projeto orientado a planos no pode ser classificado como
orientado a valor, Assim cada tipo de projeto utiliza as tcnicas
desenvolvidas para sua natureza.
b) Cenrios de projetos de construo, normalmente, seguem uma
abordagem orientada a plano, j projeto complexo deve ter uma
19
abordagem orientada a valor, visto que a entrega final tem grande

probabilidade de no ser a ideia inicial do projeto.
c) Em projetos direcionados a plano, como o prprio nome sugere, temos um
grande esforo no planejamento, pois um bom plano aumenta as chances
de uma boa execuo. O guia de boas prticas PMBok define 47
processos, em 10 reas de conhecimento, que aumentam as chances de
sucesso de um projeto.
d) Um PROJETO um esforo temporrio empreendido para criar um
e) Geralmente o que repete-se todos os meses so os processos
organizacionais. Processo como uma sequncia de passos, tarefas e
atividades que convertem entradas em uma sada. Um processo contnuo
e repetitivo.
20
Aula 2: Mtodos geis

Introduo
Na segunda aula desta disciplina, estudaremos os mtodos geis no
gerenciamento de projetos de engenharia de software. Para tanto, veremos os
principais mtodos de gerenciamento, como trabalhar as potencialidades dos
indivduos e interaes, alm das especificidades correlatas ao assunto. Boa aula!
Objetivo:
Aprender sobre os diversos mtodos geis que esto interligados ao processo de
gerenciamento de projetos.
Contedo
Mtodos de gerenciamento
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 surgiram 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. Nesta aula iremos
manter o foco em projetos de software, porm esses conceitos no so
especficos para esses tipos de projetos.
Existem diversos tipos de abordagens geis, como veremos nesta aula, e essas
abordagens geis buscam estar alinhadas com diversos princpios definidos no
documento Manifesto for Agile Software Development, criado em Fevereiro de
2001, por diversos especialistas em projetos de software.
21
Indivduos e interaes
Devemos, sempre, privilegiar indivduos e interaes a processos e ferramentas.
Observe que essa afirmao traz uma importante mensagem, processo e as
ferramentas provavelmente sero necessrios no projeto, porm, devemos tentar
concentrar a ateno da equipe sobre os indivduos e interaes envolvidos no
projeto. Lembre-se de que projetos so realizados por pessoas, e no por
ferramentas, assim como os problemas so resolvidos por pessoas, e no
processos.
Focando primariamente no desenvolvimento dos indivduos envolvidos no projeto
e enfatizando as interaes produtivas e eficazes, melhoramos as chances de
sucesso do projeto. Lembre-se de que isso no dizer que processos e
ferramentas no podem ajudar na concluso com xito de um projeto. Processos
e ferramentas bem desenhados e adequados so ativos de grande importncia.
Software em funcionamento
O segundo valor pregado destaca a necessidade entregar o software mais a
documentao abrangente. Projetos de software so normalmente iniciados com
os objetivos de criao de valor para a empresa por meio de um produto de
software de alta qualidade, mas muitas vezes h entregas em partes

intermedirias (incrementos), raramente a documentao completamente
atualizada e reflete a realidade do software, porm essencial se documentar o
que precisa ser documentado em um software, mas sem exagero. Lembre-se
sempre de que software sem documentao certamente problemtico e
dificulta o suporte e a manuteno. Mas uma documentao completa sem
software no agrega absolutamente nada a nenhuma organizao.
22
Colaborao com o cliente

O terceiro valor refora a necessidade de ser flexvel e eficiente, ao invs de
rgido e no cooperativo. semelhante diferena entre "estar certo" e fazer a
coisa certa". Poderamos construir o produto exatamente como originalmente
especificado, mas se o cliente mudar de ideia ou de prioridade, voc no
concorda que devemos ser flexveis e trabalhar para a nova meta? claro que
sim, as mudanas e ajustes devero ser refletidos em aditivos contratuais ou
ajustes, mas no deve ser um impeditivo para a continuidade do desenvolvimento
e entrega do software.
Atualmente existem diversas novas formas de contratos para acolher projetos
com caractersticas geis, como pagamento de preo fixo por interao (ou
sprint), pagamento por pontos, histrias, ou outras que permitem a flexibilidade

necessria para projetos orientados a valor.
Responder s mudanas
Em projetos com grande nmero de incertezas, quase certo que os planos
iniciais sero alterados. Em vez de investir esforos na tentativa de trazer o
projeto de volta aos planos originais, ns deveramos gastar esforo e energia
em responder s inevitveis mudanas no projeto. Observe que este valor no
est sugerindo abandonar o planejamento e apenas reagir s mudanas.
Ns ainda precisamos planejar, mas temos de reconhecer que os planos iniciais
foram criados quando conhecamos menos o Projeto (no incio), e com o
desenvolvimento do trabalho, vamos precisar atualizar o plano. Muitos dos
mtodos geis focam em macroplanos superficiais (criao de histrias, product
release, casos de uso etc.), e um planejamento mais especfico para iteraes

(ou sprints).
23
Os doze princpios do Manifesto

Listamos para voc os doze princpios bsicos do Manifesto para
Desenvolvimento gil de Softw are .
Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e
adiantada de software com valor agregado.
Mudanas
nos
requisitos
so
bem-vindas,
mesmo
tardiamente
no
desenvolvimento. Processos geis tiram vantagem das mudanas visando

vantagem competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a poucos
meses, com preferncia menor escala de tempo.
Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto
por todo o projeto.
Construa projetos em torno de indivduos motivados. D a eles o ambiente e o
suporte necessrio e confie neles para fazer o trabalho.
O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma
equipe de desenvolvimento atravs de conversa face a face.
Software funcionando a medida primria de progresso.

Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores,
desenvolvedores e usurios devem ser capazes de manter um ritmo constante
indefinidamente.
Contnua ateno excelncia tcnica e bom design aumenta a agilidade.
24
Simplicidade - a arte de maximizar a quantidade de trabalho no realizado

essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto
organizveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento
refina e ajusta seu comportamento de acordo.
Declarao de Interdependncia
Em 2005, The Agile Leadership Network (ALN) criou a Declarao de
Interdependncia para Gerenciamento de Projetos geis. Esse documento
promove abordagens geis e adaptveis para unir as pessoas, projetos e valor.
Para alcanar esses resultados, os seguintes procedimentos foram adotados:
Aumento do retorno sobre o investimento, fazendo fluxo contnuo de valor o
nosso foco;
Entrega dos resultados confiveis por envolver os clientes em interaes
frequentes e compartilharmos a propriedade;
Espera da incerteza e gerenciamento atravs de iteraes, antecipaes, e
adaptaes.
Liberdade de criatividade e inovao, reconhecimento de que os indivduos so
a melhor fonte de valor, e criao um ambiente onde eles podem fazer a
diferena.
Melhoramento o desempenho atravs de prestao de contas do grupo para
resultados e responsabilidade compartilhada para a eficcia do time.
Melhorias da eficcia e confiabilidade por meio de estratgias especficas,
processos e prticas
25
Existem diversas metodologias e frameworks geis, os mais comuns e utilizados

so o Scrum, Extreme Programming (XP), Feature Driven Development (FDD),
Dynamic Systems Development Method (DSDM), Crystal, Lean, KanBan, e outros.

O Scrum e o XP sero mais detalhados na prximas aulas pois so os de maior
aceitao e uso no Brasil, porm todos possuem caractersticas muito valiosas
para o gerenciamento de projetos orientados a valor.
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
Crie uma lista de funcionalidades
Planeje por funcionalidade
Projete por funcionalidade
Construa por funcionalidade
Boas prticas
O FDD recomenda uma srie de boas prticas oriundas da Engenharia de
Software, como:
26
Modelagem de Domnio do Objeto: as equipes devem explorar e explicar o

domnio (ou ambiente de negcios) do problema a ser resolvido.
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.
Propriedade Individual (cdigo): as reas de cdigo devem ter um nico
proprietrio para garantir consistncia, desempenho e integridade conceitual.
(Nota: Propriedade individual um bem diferente da ideia de propriedade cdigo
coletiva do XP que visa difundir o conhecimento para outros membros da equipe).
Times Dinmicos: so pequenas equipes, formadas dinamicamente de acordo
com caractersticas de cada projeto. Os times ajudam a mitigar o risco associado
propriedade individual.
Inspees: so revises que ajudam a garantir boa qualidade e design de
cdigo.
Gerenciamento de Configurao: Essa prtica envolve rotulagem de cdigo,
controle de alteraes e gerenciamento do cdigo-fonte.
Construes Regulares: atravs de entregas pequenas e constantes, o time
incrementa o produto de software com a nova funcionalidade desenvolvida. Essa
prtica tambm permite criar facilmente uma verso demo.
Visibilidade: controle e acompanhamento do progresso e dos resultados
baseado em funcionalidades desenvolvidas.
27
Metodologia de desenvolvimento de sistemas dinmicos

DSDM foi um dos pioneiros dos mtodos geis. uma metodologia de
desenvolvimento
bastante
prescritiva,
baseada
em
Rapid
Application
Development (RAD) - Desenvolvimento Rpido de Aplicaes, o DSDM enfatiza o

envolvimento constante do usurio durante todo o projeto. Cria um amplo ciclo
de vida de projeto, abrangendo aspectos de um projeto gil analisando sempre
a viabilidade e necessidade do negcio para a implementao.
Ciclo de vida DSDM

O ciclo de vida do DSDM iterativo e incremental. Portanto, a soluo no pode
ser entregue empresa de uma s vez , mas por uma srie de incrementos que
compem a soluo com cada entrega.
Desta forma, as necessidades de negcios urgentes podem ser priorizadas e
abordadas cedo, enquanto caractersticas menos importantes so implementadas
e entregues mais tarde.
A natureza iterativa permite que os representantes de negcios vejam e se
envolvam no trabalho em construo, analisando e j sugerindo os ajustes e
alteraes necessrias durante o desenvolvimento de um incremento da soluo.
Fazem parte do ciclo de vida DSDM o ciclo de vida de um projeto de gesto e um
ciclo de vida de desenvolvimento de produtos em um nico processo.
O DSDM pode ser utilizado sozinho como metodologia gil, porm o uso do DSDM
com outros mtodos e boas prticas de gerenciamento de projetos ou tcnicas
de desenvolvimento detalhados podem contribuir para a melhora nos processos
e resultados.
O DSDM centrado em 8 princpios (definidos antes da criao do Manifesto gil,
porm bem alinhados com os valores defendidos no Manifesto gil). So eles:
Foco na necessidade de negcio
28
Desenvolvimento incremental com bases slidas

Entregas no prazo
Desenvolva iterativamente
Colaborao
Comunicao contnua e clara
NUNCA comprometa a qualidade
Demonstre Controle
Crystal
O Crystal uma famlia de metodologias desenvolvidas por Alistair Cockburn, em
meados da dcada de 90, destinadas para projetos que vo desde aqueles
executados por pequenas equipes de desenvolvimento com baixa criticidade e
poucas abordagens at por grandes equipes que implementam sistemas de alta
criticidade. A famlia Crystal promove uma srie de princpios geis, como:
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, esse conceito tambm conhecido como War Room Sala de Guerra. Veremos mais sobre comunicao adiante).
29
Segurana pessoal (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.
Atividade proposta
Analisando o contedo da aula, faa uma reflexo sobre as caractersticas dos
princpios geis e das metodologias apresentadas e verifique se voc utiliza (ou
poderia utilizar) alguma dessas caractersticas em seu dia a dia nos projetos de
software.
Chave de resposta: Nesta atividade tem como objetivo a identificao de
oportunidades de uso das tcnicas apresentadas em seu dia a dia. Por exemplo,
podemos iniciar o uso dos princpios como os listados abaixo.
Trabalhar com Modelagem de Domnio do Objeto: As equipes de explorar
e explicar o domnio (ou ambiente de negcios) do problema a ser resolvido.
Direcionar o Desenvolvimento por Funcionalidade: Esta prtica envolve
decompor
as
necessidades
em
funcionalidades
definir perodos
de
desenvolvimento de uma ou mais funcionalidades em intervalos de duas semanas

ou mais curtos.
Propriedade Individual (cdigo): As reas de cdigo devem ter um nico
proprietrio para garantir consistncia, desempenho e integridade conceitual.
(Nota: que um bem diferente da ideia de Propriedade Cdigo Coletiva do XP
que visa difundir o conhecimento para outros membros da equipe).
30
Times Dinmicos: Estes so pequenas equipes, formadas dinamicamente de

acordo com caractersticas de cada projeto. Os times ajudam a mitigar o risco
associado propriedade individual.
Inspees: So revises que ajudam a garantir boa qualidade e design de
cdigo.
Gerenciamento de Configurao: Essa prtica envolve rotulagem de cdigo,
controle de alteraes e gerenciamento do cdigo fonte.
Construes Regulares: Atravs de entregas pequenas e constantes, o time
incrementa o produto de software com a nova funcionalidade desenvolvida. Esta
prtica tambm permite criar facilmente uma verso demo.
Visibilidade: Controle e acompanhamento do progresso e dos resultados
baseado em funcionalidades desenvolvidas.
Foco na necessidade de negcio;
Entregas no prazo;
Colaborao;
NUNCA comprometa a qualidade;
Desenvolvimento incremental com bases slidas;
Desenvolva iterativamente;
Comunicao contnua e clara;
Demonstre
Controle
(VISIBILIDADE
SOBRE
PROCESSOS
PRODUTOS).
Referncias
DSDM. Disponvel em: http://www.dsdm.org;
CRYSTAL. Disponvel em: http://alistair.cockburn.us .FDD. Disponvel em:
http://www.featuredrivendevelopment.com
MANIFESTO
FOR
AGILE
SOFTWARE
DEVELOPMENT.
Disponvel
em:
http://agilemanisfesto.org
MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT. Os 12 Princpios por trs

do Manifesto. Disponvel em:
http://agilemanifesto.org/iso/ptbr/principles.html
31
THE AGILE LEADERSHIP NETWORK (ALN). Declarao de Interdependncia para

Gerenciamento de Projetos geis. Disponvel em: http://pmdoi.org
Exerccios de fixao
Questo 1
Marque V (verdadeiro) e F (Falso) para as sentenas abaixo:
1 - Processos e ferramentas no so importantes segundo o Manifesto gil, j
que priorizam Indivduos e interaes.
2 - Colaborao com o cliente mais que negociao de contratos, significa que
no vamos ignorar os contratos, mas a prioridade atender o cliente e no parar
o projeto para discutir contratos. Os contratos podem/devem ser negociados sem
prejudicar o trabalho em andamento.
3 - Nos mtodos geis no planejamos (executamos direto para ganhar tempo)
a) FV-F
b) F-F-F
c) V-F-V
d) V-V-V
e) V-V-F
Questo 2
NO um dos 12 princpios geis:
a) Pessoas de negcio e desenvolvedores devem trabalhar diariamente em
conjunto por todo o projeto.
b) Simplicidade - a arte de maximizar a quantidade de trabalho no realizado
essencial.
32
c) Entregar frequentemente software funcionando, de poucas semanas a

poucos meses, com preferncia menor escala de tempo.
d) Construa projetos em torno de indivduos motivados. D a eles o ambiente
e o suporte necessrio e confie neles para fazer o trabalho.
e) Mudanas nos requisitos no so bem-vindas, quando tardiamente no
desenvolvimento aumentam as despesas e desanimam a equipe.
Questo 3
uma abordagem simples de entender e poderosa para o desenvolvimento de
produtos. Uma equipe de projeto seguindo este mtodo 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. Este mtodo busca apresentar resultados
frequentes, tangveis e funcionais.
A sentena acima refere-se a que Mtodo?
a) Feature Driven Development (FDD) - Desenvolvimento Dirigido a
Funcionalidades
b) Crystal Red
c) Dynamic Systems Development Method (DSDM)- Metodologia de
Desenvolvimento de Sistemas Dinmicos
d) Crystal Yellow
e) Crystal Clear
Questo 4
Este mtodo foi um dos pioneiros dos mtodos geis. uma metodologia de
desenvolvimento
bastante
prescritiva,
baseada
em
Rapid
Application
33
Development (RAD) - Desenvolvimento Rpido de Aplicaes, ele enfatiza o

envolvimento constante do usurio durante todo o projeto. Cria um amplo ciclo
de vida de projeto, abrangendo aspectos de um projeto gil analisando sempre
a viabilidade e necessidade do negcio para a implementao.
O ciclo de vida deste mtodo tanto iterativo e incremental. Portanto, a soluo
no pode ser entregue empresa de uma s vez, mas de uma srie de
incrementos que incrementam a soluo com cada entrega. Desta forma, as
necessidades de negcios urgentes podem ser priorizadas e abordadas cedo,
enquanto caractersticas menos importantes so implementadas e entregues
mais tarde.
A sentena acima refere-se a que Mtodo?
a) Feature Driven Development (FDD) - Desenvolvimento Dirigido a
Funcionalidades
b) Crystal Red
c) Dynamic Systems Development Method (DSDM)- Metodologia de
Desenvolvimento de Sistemas Dinmicos
d) Crystal Yellow
e) Crystal Clear
Questo 5
Marque a opo que NO faz parte ou no representa um valor desejado pelos
mtodos geis.
a) Indivduos e interaes mais que processos e ferramentas.
b) Software em funcionamento mais que documentao abrangente.
c) Colaborao com o cliente mais que negociao de contratos.
d) Responder a mudanas mais que seguir um plano.
34
e) Prever problemas futuros se antecipando as necessidades futuras do

cliente mais que fazer o simples.
Aula 3: Lean, KanBan e eXtreme Programming

Introduo
Com o gerenciamento de projetos, muito se fez necessrio encontrar mecanismos
que auxiliassem a exercer as tarefas pertinentes a essa rea. Por isso, foram
desenvolvidas uma srie de programas e formas de trabalho que torna mais
simples as prticas de gerenciamento. Esses programas e tcnicas criados podem
ser aplicados tanto no mbito pessoal quanto no coletivo.
Objetivo:
Conhecer o Lean, KanBan, eXtreme Programming e suas filosofias para auxiliar
no gerenciamento de projetos.
Contedo
Desenvolvimento de software enxuto
O Lean no especificamente uma metodologia gil, porm muitos de seus
valores esto presentes em valores geis e sua adoo pode agregar muitos
valores em diversas outras metodologias e boas prticas. Baseado na
metodologia desenvolvida pela Toyota conhecida como Lean Manufacturing.
O Lean est diretamente ligado reduo do desperdcio. Para o Lean,
desperdcio tudo que no feito para o cliente, e no caso dos softwares
podemos ter: espera (tempo de desenvolvimento parado por falta de
informaes), documentao excessiva, funcionalidades e rotinas no solicitadas
pelo cliente.
35
Conceitos do Lean
O Lean Software Development identifica sete conceitos principais, so eles:
Eliminar o desperdcio: Para maximizar o valor, precisamos minimizar o
desperdcio. O Lean classifica o desperdcio em 3 categorias:
MURA: Desperdcio gerado por antecipar possveis necessidades do cliente
(desenvolver o que no foi solicitado pelo cliente acreditando que um dia poder
ser til. Esse conceito est muito prximo ao de Gold Plating, do gerenciamento
de projetos). Podemos diminuir a MURA evitando desenvolver o que no foi
solicitado e evitando paradas em trabalhos ainda no terminados; MURI:
Desperdcio gerado pela falta de planejamento (ou planejamento malfeito). Na
MURI tambm classificamos o desperdcio causado pelo excesso de burocracia;
MUDA: Desperdcio gerado pela cultura de trabalho, desperdcios do dia a dia,
como: espera, superprocessamento, defeitos, locomoo, inventrio, transporte
desnecessrio e superproduo.
Empoderar o time: Em vez da abordagem de microgesto, devemos respeitar
o conhecimento superior dos membros do time e deixar que eles sejam
responsveis pelas decises tcnicas (locais) necessrias, para tornarem-se mais
produtivos e bem-sucedidos, aumentando as chances de sucesso do projeto.
Entregar rapidamente: Podemos aumentar o Retorno sobre Investimento
(return on investment) ROI com entregas de valor rpidas. Com entregas
rpidas e frequentes o cliente j pode iniciar o uso do software (das
funcionalidades j desenvolvidas) gerando valor mais rapidamente para 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.
36
Otimizar o todo: Para o Lean o sistema no apenas a soma de suas partes,

devemos observar alm de cada parte e como todas esto alinhadas aos
interesses de negcio da empresa e como otimiz-las da melhor forma possvel.
Construir com qualidade: O Lean no testa a qualidade no final do processo.
A qualidade do produto final deve ser assegurada com a qualidade de cada
etapa/parte do processo utilizando tcnicas como refatorao, integrao
contnua e muitas outras que veremos mais adiante.
Adiar decises: Parece estranho esse conceito mas a mensagem aqui
equilibrar o planejamento antecipado com a tomada de decises e decidir o mais
tarde possvel. Veja que no se est defendendo a procrastinao, mas sim
esperar o mximo possvel antes de decidir. Em muitos projetos na fase inicial
estamos decidindo baseado em vrias premissas (lembrando, premissa - eventos
incertos que para fins de planejamento consideramos como verdadeiros, o que
na execuo do projeto no necessariamente ser verdadeira), o que sempre
traz riscos ao projeto, como estar restrito a uma soluo limitada por uma
tecnologia disponvel at o momento.
Amplificar aprendizagem: Esse conceito envolve facilitar a comunicao cedo
e sempre, promovendo o feedback o mais rpido possvel, e aprendizado
contnuo com base no que aprendemos sobre projetos, softwares e negcios.
KanBan
Antes de iniciarmos o tpico sobre o KanBan, conhea 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. Um visitante, para entrar nos jardins, precisa de um
carto, esse carto retirado na entrada e devolvido na sada. Um novo visitante
s entra se tiver cartes disponveis. O que esse carto controla? O nmero de
37
atividades (pessoas) que os jardins so capazes de atender. Um controle simples

e eficiente garante o atendimento sem prejudicar a qualidade do servio.
O KanBan possui a mesma filosofia dos cartes, uma ferramenta visual que
auxilia o acompanhamento do fluxo de trabalho e controle do WIP (Work in
progress, Trabalho em progresso).
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 (A Fazer) Doing (Fazendo) Done (Feito), as
tarefas que preciso ser realizadas so listadas (ou coladas) na parte A Fazer,
quando elas comeam a ser feitas, elas mudam para o status Fazendo e quando
esto (totalmente) prontas, vo para o status Feito. 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.
38
Exemplo de quadro KanBan com tarefas em andamento.
Utilidades do quadro KanBan

O Quadro KanBan possui quatro caractersticas que se agregam execuo do
trabalho. Observe:
Visualizar o fluxo de trabalho
O quadro KanBan uma excelente ferramenta Low-Tech, High Touch. Quando
inserimos a tarefa (ou funcionalidade) no quadro, tornamos o trabalho tangvel,
o que um desafio para gerentes de projetos de softwares e servios. A
visualizao nos permite identificar onde esto ocorrendo os gargalos no fluxo
de trabalho e assim melhorar os processos redesenhando-os ou redimensionando
a equipe em cada tarefa.
Limitar o WIP (Trabalho em Progresso)
39
O trabalho, at estar pronto para o uso, custo, por exemplo, uma

funcionalidade em desenvolvimento que ainda no utilizada agrega algum valor
para a empresa? Um servio que est sendo desenhado, agrega ? NO ! S temos
valor quando a funcionalidade ou servio podem ser utilizados pela empresa.
Uma das regras mais importantes para qualquer metodologia ou framework gil
entregar mais que iniciar.
Tornar regras e processos explcitos
Com o quadro mais fcil discutir os trabalhos que esto em andamento, que
precisaro ser feitos e como um trabalho em andamento poder impactar outro.
Colaborao
A percepo visual do trabalho facilita o debate aberto do time sobre como
resolver atividades que esto engarrafando o fluxo, alm de dar a percepo
do todo (do conjunto de atividades feitas, fazendo e a fazer).
eXtreming Programming
Para entendermos o XP, inicialmente devemos compreender seus valores. Esses
so conceitos no tangveis que acredita-se fazer uma grande diferena na
qualidade final do produto e na motivao dos times. O primeiro deles a
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.
40
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 frequncia e, se quebrarem, sinalizem uma inconsistncia.
Com o feedback o cliente pode:
Identificar erros rapidamente;
Definir prioridades.
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.
Coragem tambm apagar o cdigo, mesmo funcionalidades inteiras, no
importa o trabalho que tenha sido empregado para desenvolv-la.
Coragem para no tentar prever o futuro, mas sim focar no que realmente
necessrio no momento. XP associa a essa ideia a sigla YAGNI (you aint gonna
need it voc no vai precisar disso).
Simplicidade e propriedade coletiva do cdigo

<font color="#333333">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.
Alm disso, comum que desenvolvedores trabalhem em partes independentes
do cdigo. A consequncia dessa 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.
41
Programao pareada
A programao em par uma forma eficaz de reduzir a incidncia de bugs em
um sistema. Quem trabalha continuamente com programao em par se habitua
a corrigir e ter seu trabalho corrigido dezenas de vezes ao dia.
A incidncia de erros identificados pelo colega costuma ser to elevada que
surpreende quem no est acostumado ao uso da tcnica e as equipes que
trabalham em par conseguem reduzir drasticamente a insero de defeitos em
seus cdigos.
A programao em par ajuda os desenvolvedores a criarem solues mais
simples, mais rpidas de implementar e mais fceis de manter. A programao
em par tambm uma forma de fazer com que o desenvolvedor tenha mais
confiana no cdigo que produz. Observe que todas essas caractersticas fazem
com que a programao em par acelere o desenvolvimento significativamente,
embora primeira vista parea o contrrio.
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 Psychology of Computer Programming, apresenta o
termo egoless programming, ou seja, programao sem ego.
Testes automatizados e refatorao

Um dos grandes desafios trabalhar em cdigos antigos. O XP prega a
refatorao constante. Mas, quanto maior o projeto, maior a quantidade de
cdigo no escrita por ns ou antigo, o que aumenta a insegurana de refatorar
o cdigo, impedindo a evoluo do projeto.
Com o aumento do projeto comum que pequenas partes de cdigo mal escrito
se acumulem e, quando menos se esperar, compromete todo o projeto. Esse
42
conceito foi nomeado por Joe Yoder como Big Ball of Mud. A melhor forma de
evitar esse problema atravs de pequenas refatoraes constantes.
O autor Martin Fowler define refatorao como uma tcnica controlada para
reestruturar um trecho de cdigo existente, alterando sua estrutura interna sem
modificar seu comportamento externo.
Funes dos testes automatizados

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). Os testes automatizados
tem duas funes importantes:
Permitir refatorao: Podemos refatorar o cdigo com mais segurana. Isto
, podemos alterar o cdigo e verificar automaticamente se o software continua
funcionando.
Documentar: Os testes devem ter nomes que explicam quais funcionalidades
eles testam, assim, ao executar o cdigo, o desenvolvedor sabe quais
funcionalidades foram implementadas e qual o comportamento esperado pelo
cdigo.
Atividade proposta
Nesta aula conhecemos o conceito de Programao Pareada (pair programming)
e o conceito de propriedade coletiva de cdigo. Esses conceitos esto fortemente
associados a programao sem ego. Em sua empresa voc e sua equipe
praticam esse conceito? Voc saberia identificar os maiores desafios para a
programao sem ego junto de sua equipe?
43
Chave de resposta: O objetivo desta atividade que voc faa uma anlise em
sua organizao e identifique caractersticas relacionadas ao comportamento e
processos dos desenvolvedores de sistemas. Os desenvolvedores compartilham
o cdigo fonte ou trabalham em par? Veja que j identificamos durante a aula os
benefcios destas prticas que alem de melhorar a qualidade do cdigo e
compartilhar conhecimento, diminui o risco no caso da ausncia de algum dos
membros do time de desenvolvimento. Logo, se voc no identificou em sua
empresa estas caractersticas, est na hora de comear a pratic-las.
Referncias
RIBEIRO, Rafael Dias; CUNHA, Horcio da; RIBEIRO, Sousa. Gerenciamento
de
Projetos
com
Mtodos
ISBN:9788591910212.
geis.
Rio
de
Disponvel
Janeiro:
[s.n.],
2015.
em:<
http://www.saraiva.com.br/gerenciamento-de-projetos-commetodos-ageis-8890292.html
Exerccios de fixao
Questo 1
Marque a opo que NO representa um dos conceitos defendidos pelo Lean:
a) Antecipar as decises
b) Empoderar o time
c) Reduzir desperdcios
d) Amplificar a aprendizagem
e) Construir com qualidade
Questo 2
Marque a opo que NO representa desperdcio classificado como MUDA,
desperdcio gerado pela cultura de trabalho, desperdcios do dia a dia.
44
a) Espera
b) Superprocessamento
c) Defeitos
d) Transporte desnecessrio
e) Erros por falta de planejamento
Questo 3
Marque a opo que NO representa um dos benefcios do uso do KanBan:
a) Eliminar o planejamento
b) Visualizar o fluxo de trabalho
c) Limitar o WIP (trabalho em progresso)
d) Tornar regras e processos explcitos
e) Colaborao
Questo 4
Com o aumento do projeto comum que pequenas partes de cdigo mal escrito
se acumulem e, quando menos se esperar, compromete todo o projeto. Esse
conceito foi nomeado por Joe Yoder como Big Ball of Mud. uma tcnica
controlada para reestruturar um trecho de cdigo existente, alterando sua
estrutura interna sem modificar seu comportamento externo. O trecho acima
refere-se:
a) refatorao
b) A limitar o WIP (trabalho em progresso)
c) programao estruturada
d) propriedade individual de cdigo
45
e) Ao feedback
Questo 5
Marque V (Verdadeiro) ou F (Falso):
Quando refatoramos constantemente, nosso dbito perceptivelmente menor do
que quando refatoramos com intervalos maiores.
2. 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.
3. O XP prega que os desenvolvedores precisam ter coragem para refatorar o
cdigo em prol de melhorias em clareza e design e coragem para no tentar
prever o futuro, mas focar no que realmente necessrio no momento. XP
associa a essa ideia a sigla YAGNI (you aint gonna need it - voc no vai precisar
disso).
a) V-V-V
b) V-F-F
c) F-V-V
d) V-F-V
e) F-F-V
46
Aula 4: Test Driven Development TDD e SCRUM

Introduo
Como vimos na aula anterior, 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).
Nesta aula voc ir aprofundar seus conhecimentos sobre o Test Driven
Developement (TDD) e sobre o mtodo SCRUM.

Objetivo:
Identificar as principais caractersticas do mtodo de desenvolvimento dirigido
por testes (TDD e SCRUM) utilizados nos gerenciamentos de projetos da
Engenharia de Software.
Contedo
Por que estudar o TDD?
Os testes automatizados tem 2 funes importantes:
Permitir refatorao
Podemos refatorar o cdigo com mais segurana. Isto , podemos alterar o
cdigo e verificar automaticamente se o software continua funcionando.
Documentar
Os testes devem ter nomes que explicam quais funcionalidades eles testam,
assim, ao executar o cdigo, o desenvolvedor sabe quais funcionalidades foram
implementadas e qual o comportamento esperado pelo cdigo.
47
Como realizar o TDD?

A filosofia do TDD que os testes guiem o prprio design das classes do sistema.
O processo TDD funciona da seguinte maneira:
1
Faz-se o teste automatizado para o caso mais simples.
2
Roda-se o teste (que no dever passar, pois a funcionalidade ainda no foi
implementada).
3
Implementa-se atravs da mudana mais simples possvel que faa o teste
passar.
4
Se o cdigo no estiver o melhor possvel:
- Refatora;
- Certifique-se de que os testes continuem passando.
5
Se o cdigo estiver bom - Volte para o primeiro item com o prximo teste mais
simples.
48
Vejamos como os conceitos do TDD podem ser aplicados utilizando um exemplo

para desenvolvimento de um simulador do jogo de cartas Black Jack.
Black Jack - teste 1

O Black Jack jogado com um ou mais baralhos de 52 cartas, para cujos
valores ser designado um total de pontos.
As cartas de 2 a 10 tero o valor dos nmeros. Reis, damas e valetes valem 10
pontos cada e ases podero ser usados tanto como 1 ou 11. O objetivo para o
jogador ser comprar cartas at um total de 21 pontos (sem exceder), vencendo
o total das cartas do distribuidor.
Passo 1: Desenho do deque de cartas
( Design a deck of cards )
Defeito identificado!
No existe Coringa no Black Jack.
public class Deck
{
private readonly Ilist<Card> cards = new List<Card>( );
public Deck( )
{
cards.Add(Card.Dois_de_Copas);
cards.Add(Card.Tres_de_Copas);
//..restante de copas
cards.Add(Card.Dois_de_Ouros);
cards.Add(Card.Tres_de_Ouros);
//..restante de ouros
cards.Add(Card.Dois_de_Espadas);
cards.Add(Card.Tres_de_Espadas);
//..restante de Espadas
49
cards.Add(Card.Dois_de_Paus);
cards.Add(Card.Tres_de_Paus);
//..restante de paus
//Coringa
cards.Add(Card.Coringa);
}
Como testar automaticamente, em cada novo incremento, para que problemas
assim no ocorram?
Sero testados automaticamente:
- 52 cartas no baralho.
- 13 Cartas de cada naipe.
- No pode existir carta coringa.
- Uma carta de cada tipo.
Teste 1: Existem 52 cartas no baralho?
public class DeckTest
{
public void Verify_Deck_contains_52_cards( )
{
var deck = new Deck( );
Assert.AreEqual(52,deck.Count( ) );
}
}

Teste 2: Existem 13 cartas de cada naipe?
Classe que testa se existem 52 cartas no baralho e se so 13 de cada naipe.
50
public class DeckTest2

{
public void Verify_Deck_contains_52_cards( )
{
Assert.AreEqual(52,deck.Count( ) );
}
public void
Verify_Deck_contains_13_cards_for_each_suit( )
{
Assert.AreEqual(13,deck.NumberofCopas( ) );
Assert.AreEqual(13,deck.NumberofEspadas( ) );
Assert.AreEqual(13,deck.NumberofOuros( ) );
Assert.AreEqual(13,deck.NumberofPaus( ) );
}
}
51
Teste 3: H carta Coringa?

{
//..Continuao
52
public void Verify_Deck_contains_no_joker( )

{
Assert.IsFalse(deck.Contains(Card.Coringa ) );
}
}
Classe que testa se h coringa nas cartas geradas.
Teste 4: Existe apenas uma carta de cada tipo?

{
//..Continuao
public void Verify_Every_Card_in_the_Deck ( )
{
Assert.IsTrue(deck.Contains(Card. Dois_de_Copas ) );
Assert.IsTrue(deck.Contains(Card. Tres_de_Copas ) );
//...Testar todas as cartas vlidas para cada naipe
}
}
Classe que testa se existe apenas uma carta de cada tipo.
Classes para Testes
52 cartas no Baralho --- testado.
13 Cartas de Cada Naipe --- testado.
53
No pode existir carta Coringa --- testado.

Uma carta de Cada Tipo --- testado.
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.
SCRUM
Histria
Scrum um mtodo gil emprico, iterativo com entregas incrementais.
Emprico porque apoia-se 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
previsibilidade e o controle de riscos

Scrum baseado em um artigo de 1986 escrito por Hirotaka Takeuchi e Ikujiro
Nonaka para a Harvard Business Review, o "The Game Development New New
Product".
54
Fonte: http://training-course-material.com;. Acesso em: 26 abr. 2015.

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 s ideias deste artigo,
incluindo a metfora, e aplicou-as na rea de desenvolvimento de software. Eles
chamaram seu novo mtodo de Scrum.
55
Fonte: http://image.slidesharecdn.com. Acesso em: 26 abr. 2015.

O Scrum ou formao ordenada uma situao frequente no rugby, geralmente
usado aps uma jogada irregular ou em alguma penalizao. Os 8 Avanados
das duas equipes formam uns contra os outros.
O Scrum-half (Mdia Formao) da equipe que no cometeu a infrao insere a
bola no meio do "tnel" formado pelas duas primeiras linhas de cada equipe com
a finalidade de que os jogadores da sua equipe consigam ganhar (talonar) a bola.
Schwaber e Beedle escreveram sobre suas experincias em seu livro
Desenvolvimento de Software gil com Scrum em 2002.
Pilares SCRUM
Como o Scrum baseado no empirismo, os seus pilares baseiam-se em:
Transparncia
Todo o processo deve estar visvel a todos os envolvidos. Essa 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 forem feitas, o novo processo proposto testado e validado.
56
No Scrum temos oportunidades constantes de verificar os 3 pilares

(Transparncia, Inspeo e Adaptao), e essas oportunidades esto nos eventos
da Reunio de Planejamento, Scrum Dirio, Reunio de Reviso do Sprint e
Reunio de Retrospectiva do Sprint.
O framework SCRUM
Scrum um framework (incompleto) para suportar o desenvolvimento e
manuteno de projetos/produtos complexos. incompleto, pois, na verdade,
ele simplesmente fornece uma estrutura para entrega, mas no diz como fazer
prticas especficas, deixando isso para a equipe determinar.
O projeto comea com uma viso clara oferecida pelo negcio, e um conjunto de
caractersticas do produto em ordem de importncia. Esses recursos fazem parte
da carteira de produtos, que mantida pelo cliente ou representante do cliente
referido como o Product Owner. Uma caixa de tempo comumente referida como
uma iterao ou Sprint a quantidade de tempo que a equipe tem para concluir
as caractersticas selecionadas.
Sprints tm geralmente de uma a quatro semanas de durao, e essa durao

mantida durante toda a vida do projeto. O Product Owner (negociando com o
time) seleciona itens do Product Backlog que acredita que pode ser concluda no
Sprint, e cria um Sprint backlog composto pelos recursos e tarefas, como parte
da reunio de planejamento (planning meeting) do Sprint.
Dica 1
O tamanho do Sprint influenciado (ou pode ser alterado) dependendo do
escopo, tamanho do time, disponibilidade do cliente, conhecimento do time sobre
agilidade, conhecimento do time sobre a tecnologia, mudanas na formao do
57
time. Porm, sempre que um novo tamanho definido, as mtricas de

produtividade devero ser refeitas.
Uma vez que o time se comprometeu com um Sprint backlog, o trabalho comea.
Durante este tempo, no Sprint, a equipe est protegida de interrupes e
permitiu concentrar-se em atender o objetivo do Sprint. Nenhuma alterao para
o Sprint backlog so permitidas, no entanto, o product backlog pode ser alterado,
em preparao para o prximo Sprint.
Dica 2
A regra do scrum no permite que o Sprint Backlog seja alterada, porm, se o
item que est em desenvolvimento perde o objetivo de negcio, isto , no
agrega mais valor, no faz sentido continuar a ser desenvolvido, e deve ser
interrompido. Geralmente o tempo restante do Sprint pode ser dedicado
refatorao de cdigos existentes ou pode se iniciar um novo Sprint, mas so
casos de exceo.
Durante o Sprint a equipe verifica no dirio com o outro sob a forma de uma
reunio, geralmente de 10 a 15 minutos conhecido como Daily Scrum (Scrum
Dirio).
No final do Sprint o time (e o cliente, quando possvel) renem-se para a reunio
conhecida como reviso (review). Eles tambm possuem uma reunio de
retrospectiva (retrospective) com o objetivo de aprender como melhorar. Essa
reunio fundamental, pois seu foco sobre os trs pilares do Scrum:
transparncia, inspeo e adaptao.
Atividade proposta
Nesta aula conhecemos o conceito de Desenvolvimento Direcionado a Testes.
Existe um jogo de cartas conhecido como Sueca. Monte os critrios de testes
para a montagem e entrega das cartas aos participantes.
Regras: Para jogar, so necessrios quatro jogadores, divididos em duplas,
sentados volta da mesa, de modo que cada dupla fique a frente uma para a
58
outra. O baralho de sueca no contm as cartas "8", "9" e "10" (da mesma forma
que o truco). Joga-se no sentido contra-horrio e cada jogador dever receber
10 (dez - uma vez que o baralho contem 52 cartas, ao retirar os 8 9 e 10 ficar
com 40, e 40 a dividir por quatro jogadores 10) cartas, de modo que o baralho
todo seja usado. importante frisar que o baralhar, cortar e distribuir das cartas
segue uma ordem rgida e especfica, de modo que qualquer irregularidade
(intencional ou no) neste processo resultar em penalidade para a dupla
infratora(caso o jogo tenha se iniciado).
Chave de resposta: Voc deve criar os Critrios de Teste, para Sueca. Neste
exemplo devemos testar se existem:
40 cartas no baralho;
10 cartas de cada naipe;
No pode existir cartas 8,9 e 10;
Uma carta de cada tipo.
Aprenda Mais
Para
saber
mais
sobre
Extreme
Programming,
acesse
http://www.extremeprogramming.org
Referncias
RIBEIRO, Rafael Dias; CUNHA, Horcio da; RIBEIRO, Sousa. Gerenciamento
de
Projetos
com
Mtodos
ISBN:9788591910212.
geis.
Rio
de
Janeiro:
[s.n.],
Disponvel
2015.
em:
http://www.saraiva.com.br/gerenciamento-de-projetos-commetodos-ageis-8890292.html
59
Exerccios de fixao
Questo 1
Ordene a sequncia lgica para realizar o TDD:
A) Roda-se o teste (que no dever passar, pois a funcionalidade ainda no foi
implementada).
B) Se o cdigo estiver bom volte para o primeiro item com o prximo teste mais
simples.
C) Faz-se o teste automatizado para o caso mais simples.
D) Se o cdigo no estiver o melhor possvel: Refatora - certifique-se que os
testes continuem passando.
E) Implementa-se atravs da mudana mais simples possvel que faa o teste
passar.
A alternativa correta :
a) C E A D B
b) A B C D E
c) C B E A D
d) A C E D B
e) A C B D E
Questo 2
Como o Scrum baseado no empirismo, baseia-se em 3 pilares. Marque a opo
que apresenta os 3 pilares do Scrum.
60
a) Transparncia Inspeo Adaptao

b) Planejamento Monitoramento Controle
c) Planejamento Reviso Retrospectiva
d) Coragem Simplicidade Feedback
e) Transparncia Planejamento - Controle
Questo 3
1 - Scrum um framework (incompleto) para suportar o desenvolvimento e
manuteno de projetos/produtos complexos. Incompleto, pois, na verdade ele
simplesmente fornece uma estrutura para entrega, mas no diz como fazer
prticas especficas, deixando isso para a equipe de determinar.
2 - Durante o Sprint, a equipe verifica no dirio com o outro sob a forma de uma
reunio, geralmente de 10 a 15 minutos conhecido como Daily Scrum (Scrum
Dirio).
3 - No Scrum temos oportunidades constantes de verificar os 3 pilares, e essas
oportunidades esto nos eventos da Reunio de Planejamento, Scrum Dirio,
Reunio de Reviso do Sprint e Reunio de Retrospectiva da Sprint.
a) V-V-F
b) F-V-V
c) F-V-F
d) V-V-V
e) F-F-F
Questo 4
61
Sprints tm geralmente de uma a quatro semanas de durao, e essa durao

mantida durante toda a vida do projeto. O Product Owner (negociando com o
time) seleciona itens do Product Backlog que acredita que pode ser concluda no
Sprint, e cria um Sprint backlog composto pelos recursos e tarefas, como parte
da reunio de planejamento (planning meeting) do Sprint.
O tamanho do Sprint pode ser influenciado (ou pode ser alterado) por alguns
fatores. Marque a opo que NO representa um dos fatores que poder alterar
a definio do tamanho do Sprint.
a) Escopo do projeto
b) Tamanho do time
c) Disponibilidade do cliente
d) Conhecimento do time sobre agilidade
e) Deciso do Scrum Master
Questo 5
Scrum um mtodo gil emprico, iterativo com entregas incrementais. Em
relao afirmativa acima, marque a opo que melhor justifica a razo de o
Scrum ser classificado como um mtodo emprico.
a) Emprico porque todas as decises so baseadas no desejo do membros
do time, buscando um ambiente mais agradvel.
b) Emprico porque apoia-se no empirismo que afirma que o conhecimento
vem da experincia e de tomada de decises baseadas no que
conhecido.
c) Emprico porque no define processos e atividades para serem seguidos.
d) Emprico porque como uma metodologia emergente, pode ser alterada
por seus criadores.
62
e) Emprico porque apoia-se no empirismo que afirma que o conhecimento

vem dos manuais e regras j testadas por diversos times que utilizam este
framework.
63
Aula 5: Framework Scrum

Introduo
Nesta aula voc aprender sobre artefatos, eventos e papis no Scrum.
Objetivo:
Definir os conceitos de artefatos, eventos e papis.
Contedo
Artefatos
O Scrum prev alguns artefatos que nos permitem ter uma viso sobre o
andamento do projeto e do Sprint. Esses artefatos so conhecidos como Backlog.
Backlog de Produto (P roduct Backlog )

uma lista ordenada criada pelo time.
O formato da lista pode variar de acordo com cada time, pode ser formada por
casos de uso, Funcionalidades (do FDD), porm os mais comuns so user stories,
que veremos mais adiante quando tratarmos de Backlog e priorizaes.
Durante a evoluo do projeto podem ocorrer alteraes nessa lista, como a
incluso de novos itens, mudanas na prioridade de desenvolvimento e entrega,
alguns itens podem ser ajustados de acordo com importncia para o negcio ou
at mesmo eliminados. Mas o NICO que pode inserir, alterar ou remover o
Dono do Produto (Product Owner).
Backlog do Sprint (Sprint Backlog )

um conjunto de itens selecionados para serem implementados (e entregues
como incremento ao produto) durante o Sprint.
O objetivo do Backlog do Sprint tornar o trabalho visvel e tangvel para que o
time atinja a meta do Sprint.
64
Ateno
Dica!
Meta: A meta do Sprint so os itens (casos de uso,
funcionalidades ou histrias do usurio) que precisam ser
adicionadas ao produto (incremento gerado pelo Sprint) com
sucesso. Geralmente na promoo dos itens do backlog de
produto para o backlog do Sprint definimos itens a mais do que a
meta, pois como as estimativas possuem certo grau de
impreciso, possvel que a meta seja atingida antes do trmino
do Sprint,
assim
time
ainda
tem
itens
para
serem
implementados.
Definio de Pronto: Essa definio precisa ser acordada e
respeitada por todos do time, geralmente a definio de pronto
significa dizer que o item j est codificado (de acordo com
patterns definidas), testado (teste unitrio, integrao,...),
documentado (manual atualizado), e implementvel. Enquanto
um item no atingiu todas as caractersticas determinadas na
definio de pronto, ele considerado WiP (Work In Progress
Trabalho em Progresso).
Os papis e responsabilidades no Scrum

A organizao dos recursos humanos envolvidos no projeto utilizando
o fram ew ork Scrum separada em trs papis:
P roduct Ow ner , Scrum M aster e Desenvolvedores.

Vamos ver cada um deles a seguir.
Product Owner
O P roduct Ow ner ou dono do produto, basicamente o representante do cliente
dentro do time Scrum, responsvel por entender o que o cliente precisa e
65
transportar esse conhecimento para os desenvolvedores. Algumas de suas

responsabilidades so:
Participar do Daily Scrum;
Responder dvidas dos desenvolvedores sobre o que est sendo desenvolvido
ou indicar que poderia respond-las;
Prover uma meta clara para cada Sprint;
Obter feedback e expectativas dos clientes e extrair deles as necessidades;
Manter o product backlog atualizado.
O P roduct Ow ner uma pessoa e no um comit. 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.
Responsabilidades do Product Owner

As responsabilidades do Product Owner so listadas para cada fase do projeto,
mas no se limitam a elas.
P re-Gam e
Antes do incio do trabalho, fase conhecida como P re-Gam e :
Identificar as necessidades estratgicas do projeto (patrocinador, time,
infraestrutura, reas envolvidas etc.);
Realizar Kick-Off;
66
Descobrir a viso do produto e elaborar artefatos necessrios;

Descobrir os requisitos para o Product Backlog;
Organizar e priorizar o Product Backlog.
Gam e
Durante o trabalho, fase conhecida como Gam e :
Participar de todas as reunies de planejamento e de reviso. Quando
necessrio visitar a reunio diria e participar da retrospectiva (geralmente,
quando convidado pelo time);
Estar disponvel para o time (ou garantir que algum designado por ele esteja);
Elaborar plano de release (plano de verses, veremos mais adiante);
Manter o Product Backlog;
Atualizar o plano de release.
P ost-Gam e
Aps a concluso das entregas do projeto, na finalizao do projeto, fase
conhecida como P ost-Gam e :
Promover e participar da retrospectiva do projeto;
Tornar resultados visveis para outros (e futuros) projetos Scrum na empresa.
Ateno
muito comum empresas que iniciam nos mtodos geis definir
Product Owner sem poder de deciso; com baixa disponibilidade;

com interesse em apenas uma parte do projeto; ou com acmulo
de outras funes no time (ou desenvolvedor ou Scrum Master).
Todas essas caractersticas enfraquecem e podem comprometer
a adoo da agilidade e do projeto.
P.O. sem poder de deciso;
67
P.O. com baixa disponibilidade;

O metade P.O.;
P.O. distante;
P.O. proxy;
P.O. da sua parte.
Scrum Master
Segundo o Scrum Guide, o Scrum M aster responsvel por garantir que o
Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que o
time Scrum adira teoria, prticas e regras do Scrum. O Scrum Master um
servo-lder para o time Scrum.
O Scrum Master ajuda aqueles que esto fora do time Scrum a entenderem quais
as suas interaes com o time Scrum so teis e quais no so. O Scrum Master
ajuda todos a mudarem essas 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 faa 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.
Equipe de Desenvolvimento
Segundo o Scrum Guide, a Equipe de Desenvolvimento (Dev. Team) consiste
de profissionais que realizam o trabalho de entregar uma verso usvel que
potencialmente incrementar o produto Pronto ao final de cada Sprint.
68
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 autoorganizveis 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.
Responsabilidades
Como regra geral, podemos dividir os papis e responsabilidades como:
MACRO P.O. (Negcio)
Assuntos relacionados ao macronegcio, priorizao, definio do que ser feito,
oramento
ou
qualquer
outro
assunto
associado
ao
negcio
de
responsabilidade do Product Owner (P.O.).

MICRO Dev. Team (Tecnologias)
Assuntos referentes tcnica de desenvolvimento, arquitetura, e assuntos mais
tcnicos so de responsabilidade do Time de Desenvolvimento (Dev. Team).
PROCESSO S.M.
E por fim, assuntos associados aos processos de trabalho so de responsabilidade
do Scrum Master<i/>.
69
Estes personagens formam o TI M E SCR UM e so, em conjunto, responsveis

pelo gerenciamento do projeto.
Eventos Scrum - Sprint

Segundo o Scrum Guide, o 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. Um novo

Sprint inicia imediatamente aps a concluso do Sprint anterior.
Os Sprints so compostos por:
P lanning m eeting (Planejamento do Sprint )

Daily Scrum (reunies dirias)
Reviso do Sprint (R eview m eeting )
R etrospective m eeting (retrospectiva do Sprint ).
Eventos Scrum - Reunio de Planejamento - Planning meeting

A reunio de planejamento de Sprint realizada no primeiro dia de cada Sprint.
O Scrum Master, Product Owner e o time de desenvolvimento esto todos os
presentes. Essa reunio no deve ocupar mais de 5% da durao do Sprint (por
exemplo,em um Sprint de 2 semanas, no deve durar mais de 4 horas) e
dividida em duas partes e deve chegar a responder s seguintes perguntas:
O que ser entregue no Incremento resultante neste Sprint?
Como faremos para entregar o Incremento neste Sprint?
70
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 no Sprint.
Ateno
A quantidade de itens selecionados para o Sprint prerrogativa
do Time de Desenvolvimento. Ele o nico capaz de avaliar o
esforo para cada item j que ser ele que ir desenvolv-los. Em
times com baixa maturidade importante que o Scrum Master
relembre da importncia de no subestimar ou sobrecarregar o
Sprint.
Aps selecionar os itens que sero realizados no Sprint, o time
define a meta do Sprint.
Na segunda parte da Reunio de Planejamento, o time define como ir
transformar os itens do backlog do Sprint em incrementos do produto.
Nesta etapa o time determina as tarefas necessrias para implementar esses
recursos ("o como").
Estimativas de trabalho so revistas para ver se a equipe tem o tempo para
concluir todas as caractersticas solicitadas no Sprint. Se assim for, a equipe se
compromete com o Sprint. Se no, os recursos de menor prioridade voltam para
o product backlog, at que a carga de trabalho para o Sprint seja de tamanho
adequado para obter o compromisso da equipe.
Eventos Scrum - Scrum Dirio - Daily Scrum

O Daily Scrum uma reunio rpida e informal, com durao mxima de 15
minutos, onde participam apenas o time Scrum.
Geralmente cada membro do time responde s seguintes perguntas:
71
O que fiz desde o ltimo Daily Scrum?

O que irei fazer at o prximo?
Quais impedimentos esto me atrapalhando?
O objetivo dessa reunio melhorar a comunicao na equipe e dar para
todos uma viso mais clara do andamento do time no Sprint , alm de
facilitar a identificao e resoluo de problemas e impedimentos.
Eventos Scrum - Reunio de Reviso do Sprint - Review meeting

No final do Sprint, o time convida os interessados (clientes) para uma reunio de
reviso do Sprint, onde as tarefas que foram concludas no Sprint so
demostradas e o feedback solicitado (apenas as que atendam a definio de
pronto).
Essa reunio no deve ocupar mais de 2.5% do tamanho do Sprint (por exemplo,
em um Sprint de 2 semanas no deve durar mais de 2 horas).
Essa reunio importante para demostrar ao cliente as novidades que estaro
disponveis para o uso, quanto para que o time de desenvolvimento receba o
feedback real dos usurios do sistema e entenda melhor suas necessidades.

Caso o cliente tenha dvidas, estas devero ser respondidas e qualquer problema
(ou possvel problema) encontrado deve ser anotado.
Nesta reunio o Product Owner aprova ou rejeita os itens implementados. Caso
rejeite, o item volta para o Backlog do Produto (e pode ou no entrar no prximo
Sprint, depender da avaliao do Product Owner).
Atividade proposta
Identifique em seu atual ambiente de trabalho quem desenvolve (ou poderia
realizar) o papel de cada componente do Time Scrum (Scrum Master Product
Owner Dev. Team)

72
Chave de resposta: nesta atividade, importante relembrar os domnios de

cada personagem no Scrum e verificar quem executa este papel no seu ambiente
de trabalho. Veja que os assuntos relacionados ao macro negcio, priorizao,
definio do que ser feito, oramento, ou qualquer outro assunto associado ao
negcio de responsabilidade do Product Owner (P.O.). Assuntos referentes a
tcnica de desenvolvimento, arquitetura, e assuntos mais tcnicos so de
responsabilidade do time de desenvolvimento (Dev. Team) e por fim, assuntos
associados aos processos de trabalho so de responsabilidade do Scrum Master.
Estes personagens formam o TIME SCRUM e so, em conjunto, responsveis pelo
gerenciamento do projeto.
Aprenda Mais
Para saber mais sobre o framework Scrum acesse:
https://www.scrumalliance.org
Referncias
SCRUM GUIDE. Disponvel em:
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-GuidePortuguese-BR.pdf/ Acesso em: 20 jan. 2015
Exerccios de fixao
Questo 1
Marque a alternativa correta. So artefatos do Scrum:
a) Backlog de Produto e Backlog do Sprint
b) Scrum Master, Product Owner e Dev. Team.
c) Reunio de Planejamento, Scrum Dirio, Reunio de Reviso e Reunio de
Retrospectiva
73
d) Incrementos do produto prontos

e) Todas as respostas acima
Questo 2
Marque a alternativa correta. So eventos do Scrum:
Retrospectiva
Questo 3
Marque a alternativa correta. So papis do Scrum:
Retrospectiva
Questo 4
uma reunio rpida e informal , com durao mxima de 15 minutos onde
participam apenas o time Scrum. Geralmente cada membro do time responde s
74
seguintes perguntas: O que fiz desde o ltimo Daily Scrum? O que irei fazer at
o prximo? Quais impedimentos esto me atrapalhando?.
A sentena acima diz respeito a qual evento do Scrum?
a) Scrum Dirio - Daily Scrum
b) Reunio de Planejamento - Planning meeting
c) Reunio de Reviso do Sprint - Review meeting
d) Reunio de Retrospectiva do Sprint - Retrospective meeting
e) A descrio acima no diz respeito a nenhum evento do Scrum
Questo 5
Essa reunio realizada no primeiro dia de cada Sprint. O Scrum Master, Product
Owner e o Time de Desenvolvimento esto todos os presentes. Essa reunio no

deve ocupar mais de 5% da durao do Sprint (por exemplo, em um Sprint de 2
semanas no deve durar mais de 2 horas) e dividida em duas partes e deve
chegar responder s seguintes perguntas:
O que ser entregue no incremento resultante neste Sprint?
Como faremos para entregar o incremento neste Sprint?
A sentena acima diz respeito a qual evento do Scrum?
a) Scrum Dirio - Daily Scrum
b) Reunio de Planejamento - Planning meeting
c) Reunio de Reviso do Sprint - Review meeting
d) Reunio de Retrospectiva do Sprint - Retrospective meeting
e) Definio da Viso do Projeto
75
Aula 6: Reunies Retrospectivas

Introduo
A reunio de retrospectiva um recurso de melhoria contnua, uma ferramenta
de comunicao e de evoluo do time. A prtica de retrospectiva vem sendo
utilizada em diversos ambientes de equipes e projetos, pois permite intensificar
as caractersticas fortes de cada time e eliminar pontos de fraqueza.
Nesta aula estudaremos as principais caractersticas da reunio de retrospectiva.
Objetivo:
1. Identificar os principais conceitos e caractersticas relacionadas s reunies de
retrospectivas.
Contedo
Reunio de retrospectiva
A reunio de retrospectiva um recurso de melhoria contnua, uma
ferramenta de comunicao e de evoluo do time. Times imaturos
costumam dar menos valor para este evento, porm a prtica de retrospectiva
vem sendo utilizada em diversos ambientes de equipes e projetos (mesmo em
ambientes no geis), pois permite intensificar as caractersticas fortes de cada
time e eliminar pontos de fraqueza.
Uma vez que a reviso est concluda, o time (sem as partes interessadas, a no
ser que o Time de Desenvolvimento e o Scrum Master decidam convidar...)
realiza uma retrospectiva para determinar o que seus membros fizeram bem e o
que querem continuar fazendo, o que foi ruim no Sprint, e quais as
recomendaes de melhoria daqui para frente. Um plano de ao criado e esses
itens so implementados ao longo do prximo Sprint, e revisado para a eficcia
na retrospectiva do Sprint seguinte. Geralmente a reunio de retrospectiva no
deve ocupar mais de 3,75% do Sprint (por exemplo, em um Sprint de 2 semanas
no deve durar mais de 3 horas).
76
Etapas das reunies de retrospectiva

Existem diversas tcnicas de retrospectiva, porm todas elas possuem as
seguintes etapas:
Identificar o problema.
Identificar causas razes.
Identificar solues.
Propor solues para diminuir ou eliminar o problema (em sua causa raiz).
Testar a soluo.
Incorporar a soluo no processo e no time.
Independente do mtodo/framework gil que for utilizado, existem elementos
comuns que quando bem utilizados agregam valor ao projeto.
Vamos apresentar algumas dinmicas que podem ser utilizadas nas reunies de
retrospectiva. Avance a tela.
Dinmica bons e ruins

Esta dinmica muito interessante em retrospectivas de equipes com alguma
experincia em agilidade ou para times que j se conhecem h algum tempo:
Permite a exposio dos problemas relevantes no momento em que o time se
encontra;
Permite que o time apresente, entenda e proponha solues para os problemas
(autogerenciamento);
Integra o time;
77
Gesto do conhecimento do time.

Dica: Nunca tarde para lembrar ao time que a retrospectiva no um caa s
bruxas e sim uma ferramenta de melhoria, logo, no o momento de acusaes,
mas de solues. O time deve ter maturidade e no levar nada para o lado
pessoal e o facilitador deve lembrar o time esses pontos sempre que necessrio!
1) Cada membro do time recebe post-it e canetas (de preferncia todos da
mesma cor) e escreve os pontos bons e ruins do Sprint.
2) Quando todos finalizarem, colam-se os post-its em um lugar visvel (veja um
exemplo de quadro).
3) feita a leitura dos tpicos ruins, observe que os problemas mais srios tero
mais post-its.
4) O time discute os problemas e prope aes de soluo.
Obs.: Dependendo do nmero de problemas interessante concentrar esforos
para resolver 2 ou 3 mais srios.
5) Faz-se a leitura dos pontos bons (prticas que devem ser mantidas)!
Consideraes:
Problemas que no geram aes e solues podem ser adiados para discusso
posterior, esses 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!. Uma sugesto as aes serem endereadas, por exemplo,
fulano de tal o responsvel por lembrar da importncia da ao XYZ durante o
prximo sprint.
78
Ao final da retrospectiva, deve-se jogar no lixo os post its e deixar fixadas as

aes combinadas visveis para todos, elas podem ficar no quadro kanban para
que todos se lembrem!
Dinmica mercado de habilidades (Market of skills)

Essa dinmica muito interessante em retrospectivas de equipes que esto no
processo de transformao para times! Alguns benefcios so:
Acelera o autoconhecimento como time;
Permite que o time inicie seu autogerenciamento, onde cada um assume como
e quando ajudar;
Integra o time;
Gesto do conhecimento do time.
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?
3) Informaes adicionais. Apresente o que voc tiver vontade para o time
(extra time, extra produto) que voc sinta vontade de compartilhar.
Dica: Nesta etapa, os membros do time identificam interesses comuns, o que
facilita o processo de comunicao e aproximao.
4) Venda-se para o time!
Dica: Durante a venda, todos podem acrescentar habilidades esquecidas pelo
vendedor (passo 1), formas de ajudar nas vontades (passo 2).
5) Defina aes!
79
Aps a primeira aplicao dessa dinmica, o time deve repeti-la (mais adiante no
projeto) e verificar sua evoluo.
Exemplo: na primeira dinmica, o time tinha identificado o seguinte quadro de
conhecimento:
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:
80
Tcnica PrOpER
A abordagem mais simples escolher uma coisa e pular dentro. Se no bvio
qual o problema para trabalhar em primeiro lugar, ento voc pode ter uma
abordagem gil. Faa uma tempestade de ideias, gere uma lista de reas
problemticas para trabalhar no que poderia melhorar a vida da sua equipe no
projeto. Ento priorize essa lista com base em sua misso de treinamento - agora
voc tem um ponto de partida!
Voc pode aplicar o ciclo PrOpER adequando a cada episdio de coaching ou na

retrospectiva.
Ateno
Problema: escolha o problema para trabalhar. Veja como a
equipe trabalha. O que precisa ser melhorado?
81
Opes: considere as suas opes. O que voc poderia tentar

que poder influenciar a situao para melhor? Relacione pelo
menos trs opes.
Experimente: escolha uma opo e a execute.
Reviso: analise o resultado. Voc melhorou as coisas? Mesmo
que as coisas no melhoraram, voc aprendeu alguma coisa?
Vamos praticar o PrOpER atravs de um exemplo.
Problema: Roberto 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 Roberto chegar, 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 Roberto a entender
porque importante para todos na equipe a participao na reunio.
Deixe-os segurando o beb: Voc precisa de algum para cobri-lo: pergunte
se Roberto pode ajud-lo, executando amanh o Daily Scrum.
Espere e veja: no faa nada e espere para ver se a equipe far com que
Roberto perceba que o seu atraso um problema por si s.
Experimente: voc escolhe a opo para primeiro falar com Roberto 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
nenhum cliente, por isso ele no precisaria estar l. Explique sua preocupao
GERENCIAMENTO DE PROJETOS DE SOFTWARE 82
em ele perder 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.

Sugira que ele convoque uma reunio com o testador (e time) para verificar as
questes que provavelmente no foram atendidas. Ele concorda em chegar no
horrio no prximo Daily Scrum.
Reviso: Reviso do resultado. No dia seguinte, Roberto chegou no horrio
acordado? A sua conversa fez a diferena? Se ainda h problemas, ento, que
outras opes voc pode tentar?
Ateno
Ao tentar chegar s opes, algumas ideias podem ser
consideradas:
Trazer o problema tona: torne o problema visvel para a
equipe.
Socializar o problema: converse com a equipe sobre o
problema.
Espere e veja: deixe este problema: se piorar, a equipe
provavelmente notar.
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 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.
83
Atividade proposta
As reunies de retrospectivas so originalmente utilizadas em equipes de projetos
geis, mas podem ser aplicadas a qualquer equipe ou tipo de projeto. Faa uma
reflexo sobre como voc poderia conduzir uma reunio de retrospectiva e quais
os desafios que voc poder encontrar nesse evento.
Aprenda Mais
Para
saber
mais
sobre
framework
Scrum
acesse:
https://www.scrumalliance.org/
Referncias
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-GuidePortuguese-BR.pdf. Acesso em: 20 jan. 2015.
Exerccios de fixao
Questo 1
Qual o principal objetivo das reunies de retrospectiva?
a) O gestor do projeto acompanhar o trabalho do time, saber o que cada um
est fazendo para alterar as atividades a fim de no atrasar a entrega
prevista.
b) O time identificar oportunidades de melhorias em seu trabalho para a
prpria evoluo.
c) Punir membros do time que prejudicam a performance.
d) Premiar membros do time que elevam a performance.
e) Seguir o ritual do Scrum.
84
Questo 2
A tcnica aplicada na dinmica conhecida como mercado de habilidades mais
adequada para:
a) Times recm-formados.
b) Times com muito tempo de trabalho em conjunto.
c) Times com desempenho de entrega baixo.
d) Times com muitos conflitos.
e) Times sem scrum master.
Questo 3
Segundo o Scrum Guide a reunio de restrospectiva:
a) No deve ser superior a 3,75% do Sprint.
b) Deve ser superior a 3,75% do Sprint.
c) Deve durar o tempo necessrio para a melhoria de todos os erros
identificados.
d) Deve ser superior a 5% do Sprint.
e) Deve ser superior a 7,5% do Sprint.
Questo 4
Marque V para verdadeiro e F para Falso.
( ) A reunio de retrospectiva opcional para times geis.
( ) A reunio de retrospectiva um recurso de melhoria contnua, uma
ferramenta de comunicao e de evoluo do time.
85
( ) A reunio de retrospectiva deve sempre ter todos os membros do time

gil, como o Product Owner, Scrum Master e Dev. Team.
Aula 7: Planejamento Orientado a Valor

Introduo
Em projetos geis, o planejamento de verses e a priorizao do que ser
desenvolvido (backlog) estratgia para melhorar o ROI (Return Over
Investiment). necessrio ter uma boa viso de produto.

Sendo assim, nesta aula iremos abordar as tcnicas para identificao e criao
da viso de produto, alm das tcnicas de gesto de portflio, Planejamento
estratgico e priorizao de backlog.
Objetivo:
Definir a viso do produto e conhecer o Project Data Sheet, Planejamento de
Release e USER.
Contedo
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).
86
As tcnicas de planejamento de gil tem forte afinidade com o planejamento em

ondas dos mtodos de gerenciamento de projetos orientados a planos, porm
com algumas diferenas, conforme apresentadas na figura a seguir. 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 as releases, e posteriormente planejamos mais detalhadamente cada
interao. No fluxo do framework Scrum, tudo se inicia na definio da viso do
projeto.
Viso em um projeto gil

Viso uma clara imagem que gera uma atrao emocional entre pessoas e
produto. Por exemplo: quando se fala, a viso de quem escuta deve ser capaz
de imaginar como ser o produto.
A viso deve responder s seguintes perguntas:
Quem ir comprar este produto?
Quem o cliente-alvo?
Quem ir usar o produto?
Quem so os usurios-alvo?
87
Quais problemas do cliente (ou usurios) o produto pretende resolver?

Qual valor o produto adicionar?
Quais atributos o produto deve possuir para resolver estes problemas e quais
garantiro o sucesso do produto?
Como o produto pode ser comparado a produtos ou alternativas existentes?
Quais so os pontos diferenciais deste produto?
Qual o preo-alvo do produto?
Como a empresa pretende ganhar dinheiro com esse produto?
Quais sero as fontes de faturamento e qual o seu modelo de negcio? (quando
aplicvel)
Lembre-se de que uma boa viso de produto permanece relativamente
constante, ao passo que o caminho para implementao da viso
frequentemente adaptado. Uma das tcnicas bem interessantes de se iniciar a
identificao e criao da viso conhecida como Elevator Statement. Essa
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. Acompanhe:
Para
cliente/pblico-alvo
que
necessidade
do
cliente/pblico-alvo
ou
oportunidade, o nome do produto um categoria do produto que principal

benefcio ou razo para comprar o produto. Diferentemente do principal
competidor ou alternativa nosso produto principal diferenciao.
88
Ateno
Se aps apresentar seu Elevator Statement no ficar claro o que
seu produto, qual o objetivo e para quem se destina, ele no
est bom!
Materializao do produto
O prximo passo materializar seu produto, mesmo sendo um
softw are !
A tcnica de Product Vision Box prope a criao da caixa do seu software com
informaes como:
Nome do Produto;
Grficos;
Trs ou quatro pontos-chave (benefcios) para vender o produto;
Principais funcionalidades no verso;
Principais requisitos operacionais.
Ateno
Voc pode fazer essa dinmica com o time envolvido no projeto
usando caixa de sapato, cola e canetas coloridas, lembre-se de
que na agilidade temos diversas tcnicas Low Tech, High Touch.
Observe que neste passo conseguimos identificar os principais
diferenciais e as funcionalidades essenciais do futuro software,
alm de alinhar as expectativas dos participantes.
89
Aps a criao da caixa do produto, podemos iniciar o Product Road Map, que
apresenta as funcionalidades e caractersticas do produto (e em que verso a
funcionalidade ser inserida). Para essa etapa podemos usar a tcnica Remember
the Future, que tem como objetivo descobrir o entendimento do sucesso do

cliente e iniciar a visualizao do Road Map do produto/projeto. Nessa tcnica,
ao invs de olhar o passo a passo, voc deve se posicionar no momento final
desejado e relembrar o que foi feito para chegarmos nesse ponto.
Lembre-se: 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!
Aps a aplicao das etapas anteriores, conseguimos ter um melhor
entendimento da viso do projeto e criar o Project Data Sheet, a planilha de
dados do projeto. Ela deve possuir dados tais como: nome do projeto, data de
incio, clientes, objetivos estratgicos de incio do projeto, matriz, pontos
estratgicos, benefcios dos clientes, performances e arquitetura de produtos.
90
Planos adaptativos
As estratgias, portflio e produto podem ser planejadas com tcnicas de gesto

de portflio, planejamento estratgico e outras conhecidas e utilizadas no mundo
dos negcios, porm algumas tcnicas geis de definio de viso (como vimos
anteriormente) auxiliaro a todos a entender o que realmente necessrio para
o sucesso do projeto.
Veja a figura que apresenta a cebola do planejamento estratgico em projetos
orientados a valor.
Planejamento de release
O planejamento de release uma reunio de planejamento de alto nvel que
trata de iteraes das futuros sprints. O objetivo planejar quais itens sero
desenvolvidos, quando devero estar prontos e quais recursos sero necessrios
para isso. As entregas iro ocorrer ao longo do projeto e a performance do time,
assim como as aes de monitoramento e controle.
Acompanhe:
91
Observe que sero necessrios que o Produck backlog j esteja definido e

priorizado, as datas dos sprints definidas, e (se for um time j existente) a
velocidade mdia do time.
Ateno
As datas de incio/fim das futuros sprints j devem considerar os
feriados, frias de membros do time e quaisquer interrupes j
planejadas.
A formao do time impactar em todo o andamento, em
projetos que temos uma restrio de tempo mais severa, a
montagem de um time snior mitiga o risco de atraso, porm
impactar no custo.
Com os itens pontuados e priorizados e com a estimativa mdia
de entregas do Time, podemos definir quantos sprints sero
necessrios. Por exemplo: Um projeto de 60 pontos com um time
de 12 pontos de produtividade por sprint durar 5 sprints (60 / 12
= 5 ).
User story
No levantamento tradicional de requisitos partimos do princpio de que o cliente,
em linguagem de negcios, identifica suas necessidades. Essas necessidades
identificadas so passadas ao analista que traduz em linguagem tcnica e que
92
posteriormente so entregues aos desenvolvedores que as transforma em

cdigos.
Observe que neste processo temos pontos fracos, como:
Premissas falsas podem ser geradas pelo cliente ou pelo analista
Requisitos detalhados desnecessariamente (desperdcio)
Na tcnica de User Story, o dono do produto descreve o que precisa ser feito,
identifica quem usar a funcionalidade e por que (ajuda a no gerar itens que
no agregam valor ao negcio). Essa tcnica utiliza os 3 Cs:
Carto: Cada histria 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 histrias tambm utilizam os conceitos conhecidos com INVEST:
Independente: A histrias so mais fceis de trabalhar quando so
independentes, isto , no dependem de outras histrias para acontecerem.
Negocivel: A histria no um contrato com definio de funcionalidades, ela
negocivel para melhor atender as necessidades do negcio.
Valiosa para usurios e clientes: A histria precisa estar associada a um valor
para o usurio ou clientes, sem isso, no existe razo para ela existir.
93
Estimvel: A histria precisa ser estimvel, mesmo que com alguma impreciso,
precisamos dimensionar o esforo para implement-la.
Sm all (pequena): Histrias representam situaes simples, com poucos

personagens.
Testvel: Toda histria precisa ser testvel. O cliente deve identificar quais
seriam as condies de testes da histria escrita. As condies de teste definidas
pelo cliente ajudam o time a entender se a meta da histria foi bem-sucedida.
Uma boa histria deve responder:
QUEM? COMO? POR QU?
Como um PERFIL eu posso /gostaria/devo FUNO para VALOR AO NEGCIO
Ou POR QU? QUEM? COMO? Com o propsito de VALOR AO NEGCIO, como
um PERFIL, eu posso/gostaria/devo FUNO
Por exemplo, uma histria para criar uma panela especfica:
Como um Cozinheiro (Usurio);
Quero panela de inox, com fundo oval e antiaderente (Funcionalidade);
Para cozinhar um salmo (Valor de Negcio).
Outro exemplo:
Como comprador que no tem carto de crdito;
Quero que o sistema suporte pagamento em boleto bancrio.
Stories, temas e epics

Algumas histrias podem ser mais complexas e com uma previso maior do que
a capacidade de entrega do sprint. Essas histrias so conhecidas com epic. As
94
epics precisam ser analisadas e revistas com o objetivo de identificar melhor seus
objetivos e a sua possvel decomposio em histrias menores. (Lembre-se de
que as histrias devem respeitar as premissas do INVEST).
Geralmente os Epics aparecem na base do backlog do produto, pois ainda no
possuem granularidade para serem implementadas.
Existem casos em que um grupo de histrias est associado a um determinado
tema especfico, nestes casos, no momento de priorizao do backlog do produts
essas histrias tendem a serem produzidas no mesmo sprint ou em sprints
prximos.
Ateno
As histrias que esto agrupadas no tema no esto associadas
a nenhuma regra de precedncia, lembre-se de que as histrias
devem ser independentes.
Priorizao de backlog
A priorizao do Backlog de responsabilidade do Product Owner e est
diretamente associada melhoria do retorno sob investimento (ROI), pois quanto
antes as funcionalidades mais importantes forem entregues, mais cedo geraro
retorno para o negcio. Em geral, a priorizao do backlog do produto segue
uma sequncia lgica, conforme apresentada:
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
95
maior riscos devem ser priorizados. Quanto mais cedo falharmos, mais cedo
corrigimos e obtemos sucesso.
R eleasability (Capacidade para lanamento): Itens que permitam lanar

mais rapidamente o produto devem ser priorizados (Minimum Marketable Feature
- MMF), como veremos mais adiante.
"Dependncia: Temas e "dependncias" devem ser considerados na
priorizao.
Priority markets
Na tcnica de priorizao Priority markets, simulamos um mercado, onde para
cada avaliador dado algum dinheiro virtual (Reais de desenvolvimento), que
devero ser usados para licitar itens do backlog. O mtodo democrtico, em
que todos os interessados possuem voz no processo de priorizao. Tambm
permite transparncia para que todos possam ver como ocorreu a priorizao de
cada item. Essa ferramenta simples de administrar e se adapta bem a um
grande nmero de interessados e listas longas de itens do backlog, mitigando os
debates sem fim em busca de um consenso para a priorizao.
Clique aqui para conhec-la.
Geoff Watts e Jason Haines, em seu trabalho sobre Priority Markets, cita alguns
comportamentos que surgem desta dinmica, o qual os autores chamam de A
psicologia do mercado. So eles:
Negociao: Os interessados podem ver os lances uns dos outros e ajustar o
seu lance de acordo com o mercado.
Negociao: Uma das partes interessadas podem "vender" seus Reais de
desenvolvimento para outro dos interessados para as prestaes em espcie.
96
Votao ttica: Com base em outros lances, uma das partes interessadas
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: extra Reais injetados no sistema reduz o valor relativo de outros Reais,
resultando em inflao; os interessados podem tambm se sentir marginalizados
por terem suas prioridades substitudas.
Theme screening
Uma outra tcnica bem interessante de priorizao a Theme Screening. Para
essa tcnica, geralmente selecionamos de 5 a 9 critrios para avaliar o que
mais importante para o prximo sprint. Esses critrios devem representar
aspectos do nosso produto que consideramos importantes para a priorizao de
requisitos.
Aps definir os critrios, selecione um tema que servir como base para os
fatores de comparao. Lembre-se de que temas so grupos de requisitos
funcionalmente ligados ou que tenham objetivos de negcio complementares.
Esse tema deve ser algo que deveria entrar no prximo sprint.
Ateno
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.

97
Um fator importantssimo a ser considerado na escolha dos critrios de anlise e

dos temas que todos devem ser capazes de entender o significado de cada
critrio de anlise e serem capazes de avaliar cada tema relativo a esses critrios.
Por exemplo, aps a escolha podemos ter um quadro conforme apresentado:
Devemos agora escolher um tema como baseline (no nosso exemplo, o Tema C)
, isto , um tema que servir de base de comparao para todos os demais
temas. Procure buscar sempre um tema que tenha uma prioridade intermediria
entre os temas escolhidos.
Agora, comparamos cada critrio de anlise com o nosso baseline, ou seja,
perguntamos para os nossos envolvidos se determinado tema melhor ou pior
que o baseline em cada critrio de anlise. No nosso exemplo usamos + quando
o tema comparativamente melhor que o tema base para o critrio, - se o tema
contribui menos ou 0 se tem a mesma contribuio (Lembre-se de que essa
percepo subjetiva).
Somemos o total para cada tema e teremos uma pontuao total para o tema.
Basta ento ordenar nossos temas, veja como ficou a priorizao de nosso
exemplo.
98
Ateno
Existem 2 grandes riscos nessa tcnica. O primeiro a escolha
de critrios equivocados, geralmente quando no foi bem
desenvolvida a viso do produto. O segundo risco est associado
escolha do baseline, um com prioridade muito alta far com
que muitos temas pontuem negativo. Um baseline muito baixo
far com que muitos temas pontuem muito alto. Assim, a
escolha de um baseline intermedirio na escala de prioridade
bem importante. Se errarmos na escolha do baseline poderemos
criar distores nos resultados.
Kano Model
A tcnica Kano baseada em entrevistas com os usurios e experts. Ela bem
interessante quando a opinio de todos tem o mesmo valor (diferentemente da
tcnica de Priority Markets, onde podemos atribuir pesos maiores para os
Decision Makers). Essa tcnica foi desenvolvida por um professor de

gerenciamento de qualidade chamado Noriaki Kano que estudou e classificou as
preferncias dos clientes em 3 categorias:
Mandatrio (Basic expectations): so caractersticas consideradas bsicas que
devem estar presentes no produto. A ausncia delas ir frustrar o cliente mas a
99
sua presena no ir aumentar a satisfao dele, j que o cliente espera que

aquela caracterstica esteja presente.
Linear (Satisfiers): so caractersticas que quanto mais, melhor, e que podem
aumentar ou diminuir a satisfao do cliente. Geralmente esto ligadas
performance.
Desejadas (Delighters): so caractersticas que satisfazem o cliente quando
esto presentes no produto, porm, caso no estejam no iro causar
insatisfao.
Aps a identificao das funcionalidades, realizamos questionrios com grupos
de 10 a 30 usurios com perfis variados, com uma pergunta funcional e outra
disfuncional.
Pergunta Funcional: Como voc se sentir se essa funcionalidade estiver
presente?
Por exemplo:
Se o prximo release incluir o carrinho de compras, como voc se
sentir?
( ) Eu gostaria que fosse desta forma
(X) Eu ficarei neutro
( ) Eu posso viver desta forma
( ) Eu no gostaria que fosse desta forma
Pergunta Disfuncional: Como voc se sentir se esta funcionalidade estiver
ausente?
Por exemplo:
Se o prximo release NO incluir o carrinho de compras, como voc se
sentir?
( ) Eu gostaria que fosse desta forma
( ) Eu ficarei neutro
100
( ) Eu posso viver desta forma

(X) Eu no gostaria que fosse desta forma
Ento, utilizando-se a seguinte categorizao para cada conjunto de respostas
(funcional e no funcional):
No caso do exemplo, essa funcionalidade seria Desejada. Agora, agregando os

resultados s funcionalidades que estamos verificando, o grau de satisfao que
elas apresentam:
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 Mandatria. 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.
101
Para se manter o Product Backlog priorizado por esse modelo necessrio que
todas as funcionalidades/caractersticas mandatrias estejam no Road Map (sem
exceder a quantidade de esforo necessria para alcanar o bsico esperado),
fazer o mximo de funcionalidades/caractersticas lineares e sempre tentar deixar
um espao para as funcionalidades desejadas, pois essas podem aumentar o
grau de satisfao do cliente rapidamente a seu favor.
MMF - Minimum Marketable Feature

A Tcnica de MMF pode ser utilizada para priorizao de seu backlog de produto
e para o planejamento de verses. Seu princpio est baseado na identificao
das caractersticas mnimas comercializveis de seu produto.
Ela baseia-se no princpio de priorizar o essencial para a gerao de valor, por
exemplo, para o desenvolvimento de um telefone celular as funcionalidades
essenciais so as de ligar e desligar e o envio de mensagens de texto, assim,
essas funcionalidades devem ser priorizadas e estarem na primeira verso do
produto (ou no topo do backlog de produto), ouvir msica, registrar fotografias
e outras podem aparecer em verses mais avanadas (base do backlog de
produto). A regra de ouro : desenvolva as caractersticas de maior valor
primeiro (maximizao do seu retorno).
Dica: Para simplificar o planejamento de verses, elimine dependncias tcnicas,
lembre-se de que as histrias devem respeitar o conceito de Invest.
Atividade proposta
Priorizao dos itens no backlog a chave do sucesso de um projeto orientado a
valor. Muitas empresas tratam projetos orientados a valor com tcnicas e
ferramentas inadequadas, seguindo um plano inflexvel, o que acaba gerando
baixo retorno no investimento e funcionalidades sem uso. Nos projetos em que
voc j se envolveu, ocorreu esse tipo de situao? Faa um reflexo sobre como
o projeto poderia ser diferente se utilizasse tcnicas e ferramentas de projetos
orientados planos, como as apresentadas nesta aula.
102
Chave de resposta: esta atividade serve para voc relembrar que o valor
esperado (Retorno sobre Investimento) tem uma forte relao com as
priorizaes dos itens que entraro na Sprint, assim um P.O. que priorize de
maneira equivocada poder provocar retarno no retorno sobre o esforo investido
no projeto. Atualmente, quando utilizamos tcnicas mais apropriadas para
cenrios simples ou complicados (como o PMBoK) em cenrios complexos
identificamos este problema com elevado numero de mudanas nos planos e
muito retrabalho.
Aprenda Mais
Para saber mais sobre as tcnicas para criao de priorizao de backlog,
acesse os links indicados:
Fram ew ork Scrum
Mind the Product
Elevator Statement
Priority Markets
Agile UX
Innovation Games
Referncias
SCRUM
GUIDE.
Disponvel
em:
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-PortugueseBR.pdf Acesso em: 20 jan. 2015.
103
Exerccios de fixao
Questo 1
Quem responsvel pela priorizao do backlog?
a) Todos do Time
b) Scrum Master
c) Dev. Team
d) Product Owner
e) Desenvolvedor Chefe
Questo 2
As histrias utilizam os conceitos conhecidos com Invest. Marque a opo correta
sobre o significado de Invest.
a) Independente Negocivel Valiosa Estimvel Small Testvel
b) Individual Negocivel Verificavel Estruturada Simples
Transparente
c) Individual Negocivel- Valiosa Estimvel Small Transparente
d) Independente Negocivel Verificavel Estimvel Small Testvel
e) Independente Negocivel Verificavel Estimvel Superficial
Testvel
Questo 3
Marque V para verdadeiro e F para Falso.
( ) A tcnica Kano baseada em entrevistas com os usurios e experts. Ela
bem interessante quando a opinio de todos tem o mesmo valor (diferentemente
104
da tcnica de Priority Markets, onde podemos atribuir pesos maiores para os
Decision Makers).
( ) Uma outra tcnica bem interessante de priorizao a Theme Screening.
Para essa tcnica, geralmente selecionamos de 5 a 9 critrios para avaliar o que
mais importante para o prximo sprint.
( ) A Tcnica de MMF (Minimum Marketable Feature) pode ser utilizada para
priorizao de seu backlog de produto e para o planejamento de verses. Ela
baseia-se em identificar as caractersticas mnimas comercializveis de seu
produto.
a) V V V
b) V V F
c) F V V
d) F V F
e) F F V
Questo 4
Analisando a imagem abaixo e com as informaes apresentadas nesta aula,
marque a opo INCORRETA.
a) O planejamento realizado em etapas, para cada entrega combinada no

incio da iterao (ou Sprint).
105
b) A etapa de iniciao concentra-se em definir de maneira eficaz a viso do

projeto e no em criar o plano de projeto.
c) A entrega do trabalho do projeto acontece em intervalos regulares de
tempo com aes de planejamento e execuo em cada um destes
intervalos.
d) O nvel de atividade tende a ser muito similar em cada iterao (ou Sprint)
e representa a capacidade de execuo do time.
e) Nas primeiras iteraes (ou Sprints) gerado todo o plano de projeto que
dever ser seguido at todo o escopo do projeto ser entregue.
Questo 5
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 investimento).
Analisando a frase acima, marque a opo mais correta:
a) Com a priorizao, o mais importante para o momento do projeto feito
primeiro e assim, mesmo que o projeto no esteja completo, a parte
pronta j pode ser utilizada pelo cliente.
b) Com a priorizao, o mais importante para o do projeto feito primeiro e
assim, mesmo que o projeto no esteja completo, a parte pronta j pode
ser testada e no tem mais riscos de perder o investimento destinado
originalmente pelo cliente.
c) Com a priorizao, as atividades mais simples e rpidas so desenvolvidas
primeiro e assim, a evoluo do trabalho previsto em relao ao realizado
ser melhor e mais bem avaliada pelo cliente.
d) Com a priorizao as atividades podero ser feitas e testadas com mais
tempo antes que seja entregue para a rea operacional diminuindo o
retrabalho e o numero de defeitos.
106
e) O Scrum Master deve priorizar o que ser feito primeiro de acordo com as
habilidades e competncias da equipe de desenvolvimento, acelerando o
processo de desenvolvimento.
Aula 8: Estimativas de Produtividade

Introduo
Um dos maiores desafios dos profissionais da rea de desenvolvimento de
software estimar o esforo para a criao de novas funcionalidades, tarefas ou

histrias.
Sabemos que estimar fundamental, porm, grande parte do esforo
empreendido em estimar com preciso acaba sendo perdida.
Sendo assim, nesta aula voc conhecer ferramentas e outras formas mais
comuns para realizar as estimativas de maneira efetiva.
Objetivo:
Estimar o esforo para a criao de novas funcionalidades, tarefas ou histrias.
Contedo
Estimativas geis
Um dos grandes desafios de profissionais da rea de desenvolvimento de
software como estimar o esforo para a criao de novas funcionalidades,

tarefas ou histrias. O principal objetivo de se estimar criar uma mtrica comum
para definio e comparao de esforos, e consequentemente definies de
prazos (e oramentos) para projetos e/ou atividades. Temos diversas formas de
estimar software desde os antigos KLOCs (KiloLlines of Code ou mil linhas de
cdigo), homem-hora, pontos de funo, entre outras. inegvel que estimar
fundamental, mas vemos que grande parte do esforo empreendido em estimar
com preciso perdido, devido a alguma premissa que no se tornou verdadeira
ou porque medida que trabalhamos no projeto, com mais conhecimento, somos

obrigados a ajustar nossas estimativas.
As formas mais comuns em estimativas so as apresentadas pelo PMBok, Guia
de Boas Prticas do Project Management Institute e esto expostas a seguir:
Estimativa de um ponto: Apresenta a estimativa por atividade. Pode ser
baseada na opinio especializada, informaes histricas ou simplesmente
adivinhao.
Estimativa
Anloga
(Top
Dow n ): Usam opinio especializada e
informaes histricas para prever o futuro.

Estimativa Paramtrica: Observa os relacionamentos entre as variveis em
uma atividade para calcular estimativas.
Estimativa de Trs Pontos (Anlise PERT): Considera a mdia entre a
estimativa no melhor cenrio (O), adicionada quatro vezes estimativa mais
provvel (M), mais a estimativa do pior cenrio (P) , dividida por seis.
( P + 4M +O ) / 6
108
Atividades de desenvolvimento de software

Atividades de desenvolvimento de software (projetos orientados a valor)
geralmente so bem mais complexas do que atividades da construo civil, como
uma pintura de corredor, por exemplo, (projetos orientados a planos) pois em
um novo projeto de software os requisitos nunca sero completamente
conhecidos at que o usurio os tenha utilizado, assim, o grande desafio nas
estimativas de software est relacionado s dificuldades da clara definio do
109
escopo do produto, da definio da estratgia de como uma atividade ser

realizada e pelo simples fato que em um grupo distinto a experincia,
conhecimento tcnico, cultura etc. iro influenciar na estimativa de cada um, por
isso todas as estimativas tendem a apresentar impreciso.
Lembre-se de que quando utilizamos horas ou dias como unidade de medida,
estamos estimando no s o esforo necessrio para a tarefa, mas tambm a
velocidade individual dos membros que trabalharo nela.
A comunidade adepta aos mtodos e frameworks geis geralmente procura
utilizar estimativas que levam em considerao apenas o esforo para a
realizao de determinada tarefa (histrias), onde todos os envolvidos no
desenvolvimento medem as diversas tarefas e assim definem estimativas
comparativas (com margens de erro) entre todo o trabalho que precisa ser
realizado.
Veja a histria relatada por James Surowiecki que em seu trabalho intitulado A
Sabedoria das Multides apresenta 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). A expectativa de Sir
Francis era que os peritos (aougueiros profissionais) estavam sempre bem e iria
superar com folga uma multido, o que no ocorreu.
Planning Poker
Quando estamos jogando o Planning Poker, uma tcnica de estimativa utilizada
pela comunidade gil, ns igualmente estamos aproveitando a sabedoria das
110
multides com relao a nossas estimativas. Estamos apostando que o pblico

ser capaz de chegar a um melhor palpite do que qualquer indivduo nico.
O Planning Poker uma tcnica de estimativa baseada no consenso de toda a
equipe, onde utilizado um conjunto de cartas com valores especficos (pontos)
relativos.
Como funciona:
111
Uma pessoa apresenta a tarefa ou histria para o time, e, aps uma breve
discusso, cada um escolhe uma carta e coloca virada para baixo sobre uma
mesa.
Quando todas as cartas estiverem lanadas, elas so viradas e caso no haja
consenso nos valores escolhidos, essas diferenas so discutidas de forma breve.
Geralmente, quem estimou com os maiores e menores valores explicam o motivo
de sua estimativa, e uma nova rodada acontece at que haja a convergncia.
Exemplo de cartas que geralmente so utilizadas no Planning Poker.
O Planning Poker funciona porque utiliza opinio de diversos especialistas (que
iro realmente realizar a tarefa) e promove o dilogo que permite
maior acuracidade das estimativas, principalmente em itens com maior incerteza.
Alm de ser uma tcnica de estimar considerando a experincia de todos da
equipe, proporciona um conhecimento do negcio mais homogneo e mais
atraente (e divertida) que as demais tcnicas.
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 ser empreendido. Existe
tambm a opo infinito, carta com a marcao , geralmente quando o time
identificou um histria que considera EPIC.
Grfico da Sequncia de Fibonacci
112
Tcnica PMG
Outra forma de estimativa muito utilizada no mundo gil a tcnica PMG, uma
analogia as medidas de roupas, onde cada item classificado como P para
pequeno, M para mdio e G para grande, de acordo com a percepo de esforo
do time para entreg-la.
Sempre devemos lembrar que:
A definio do pontos de cada histria de exclusividade do Time.
Lembre-se de que o esforo empreendido em cada Sprint (ou interao) pode
variar de acordo com cada time. 18 pontos para o time A e 18 pontos para o
time B no so o mesmo esforo. A percepo de quanto esforo
necessrio para realizar um ponto subjetiva e diferente para cada time.
Os pontos definidos em cada histria devem envolver todo o esforo
para entreg-la pronta para funcionar no ambiente real. Significa que
devemos considerar a complexidade devido ao desconhecimento ou incertezas,
o esforo do trabalho e os riscos associados em nossas estimativas.
O tamanho do esforo deve ser relativo. Isto , quando dizemos que para
entregar a histria A definimos 8 pontos e para a histria B 16 pontos,
113
significa que o esforo para entregar B o dobro de A (mesmo que haja uma
pequena variao devida natureza imprecisa das estimativas geis). Observe
que neste ponto devemos estar atentos s estimativas por afinidade, podemos
agrupar as histrias por proximidade de esforo pontuado (pelo time), o que
facilita o dimensionamento do trabalho como um todo.
Um pouco mais sobre times geis

Como podemos ver, nos diversos mtodos geis temos processos
e eventos como as reunies de planejamento, reunies dirias, retrospectivas e
outras, porm o primeiro valor do manifesto gil :
Indivduos e interaes mais que processos e ferramentas
Os processos e eventos so facilmente descritos (at seguidos), porm eles
sempre dependero dos indivduos e suas interaes, e estes j so mais difceis
de serem generalizados e documentados como regras. Veja que cada indivduo
possui caractersticas nicas como personalidade, conhecimento tcnico, cultura,
valores, momento de vida etc. e todos esses fatores influenciaro nas interaes
e em como o trabalho fluir. Esse valor do manifesto gil reflete a seguinte
sentena mensagem:
Bons profissionais mesmo com poucos processos (ou at mesmo sem nenhum)
conseguem superar os maiores desafios. Mesmo utilizando os melhores
processos, um time ruim ir falhar at mesmo em algumas tarefas simples.
Lderes de times geis devem concentrar-se nos fatores humanos (pessoas e
relacionamentos) para obterem o melhor resultado.
Liderana adaptativa
O termo liderana adaptativa se refere a como devemos lidar com o time
dependendo da maturidade do time e de cada circunstncia. O autor Bruce
114
Tuckman, no trabalho Developmental Sequences in Small Groups
Psychological Bulletins 63 (1965), foi um dos primeiros a identificar as fases em

que um time pode se encontrar desde a sua formao at chegar a um estado
de time de alta performance. Avance para entender melhor.
FORMAO
TEMPESTADE
(storming)
NORMALIZAO
PERFORMANCE
SUSPENSO
Na fase de Formao os membros (ainda no so um time) comeam a
trabalhar em grupo. Eles iniciam o processo de aprendizado uns sobre os outros
e nesse 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.

A formao ocorre sempre que um novo membro introduzido no time (mesmo
que os demais, ou a maior parte do time permanea). Nesses casos o tempo
tende a ser menor do que a formao de um time completamente novo.
Com o andamento do trabalho diversos conflitos e divergncias iro surgir. O
grupo passou para a fase de tempestade, onde se torna um pseudo-time. Os
seus membros desafiam-se entre si para a realizao dos trabalhos. Durante a
fase da tempestade observa-se dilogos mais speros, conflitos abertos e at
115
insatisfao, por isso a liderana precisa atuar orientando o time nos diversos
aspectos e auxiliando na soluo de questes.
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.
O Project Management Body of Knowledge (PMBok), Guia de Boas Prticas do
Project Management Institute (PMI), sugere que podemos mitigar os conflitos,

sempre lembrando e relembrando ao time:
Exatamente para onde o projeto est direcionado;
As restries e objetivo do projeto;
O contedo do Termo de Abertura do Projeto;
Mudanas;
Decises Importantes;
Tornar as tarefas desafiadoras;
Seguir as boas prticas de gerenciamento de projetos.
O PMBoK, apresenta as sete origens de Conflitos em ordem de frequncia:
1) Cronogramas;
2) Prioridades do Projeto;
3) Recursos;
4) Opinies Tcnicas;
5) Procedimentos Administrativos;
6) Custo;
7) Personalidade.
116
Na fase de normalizao o time em potencial comea a se tornar um verdadeiro

time, aprendendo como trabalhar uns com os outros. Neste momento o time
deve criar regras para ajudar/governar o prprio trabalho. A liderana um
pouco mais tmida e concentra-se mais no auxlio 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 perform ance 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 fase
final devido a mudanas na sua composio.
117
Inteligncia emocional
Inteligncia emocional a nossa capacidade de identificar, avaliar e influenciar
nossas prprias emoes, de outros indivduos e de grupos. O quadro a seguir
identifica os diferentes aspectos da inteligncia emocional. Veja:
Prprio
118
Outro
Autogerenciamento
Autocontrole;
Conscincia;
Adaptabilidade;
Direcionamento e motivao.
Habilidades Sociais
Autocontrole;
Liderana inspiradora;
Desenvolvimento dos demais;
Trabalho em equipe e colaborao.
Regular
Autoconhecimento;
Autoconfiana;
Autoconhecimento emocional;
Precisa autoavaliao.
Conscincia Social
Empatia;
Conscincia organizacional;
Compreender o ambiente.
Reconhcer
A separao dos aspectos da inteligncia emocional nos quadrantes significa que
primeiro precisamos conhecer nossas emoes para poder control-las, isto ,
precisamos saber o que nos irrita, nos frustra, nos faz perder o foco para depois
escolhermos uma estratgia para tratar e responder a essas situaes e
sentimentos. Devemos desenvolver essas habilidades para decidir se vamos

deixar essas emoes nos afetar ou se iremos responder de maneira diferente.
Daniel Goleman, no artigo Primal Leadership: The Hidden Driver of Great
Performance, publicado na Harvad Business Review, em 2001, afirma:
"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.
Ateno
Como lderes de times devemos trabalhar as habilidades que nos
permitam identificar as situaes que influenciam negativamente
os membros do time a ajud-los (os membros) a desenvolver
estratgicas para mitigar ou elimin-las. Reconhecer que outros
precisam de ajuda nos ajuda a melhorar a performance individual
e do time, promove a colaborao e o trabalho em equipe.
Comunicao e o ambiente de trabalho

Segundo o Antigo Testamento (Gnesis 11,1-9), os descendentes de No, com a
inteno de eternizar seus nomes, iniciaram o projeto da construo da torre do
templo de Marduk, (nome cuja forma em hebraico Babel ou Bavel e significa
"porta de Deus"), uma torre to alta que chegaria cu.
O projeto provocou a ira de Deus que para puni-los, decidiu criar os diversos
idiomas para o povo da Terra, assim o processo de comunicao entre os
construtores foi comprometido e a torre no foi terminada.
Esse mito uma tentativa de se explicar as diversas origens dos idiomas e
apresenta um risco real em todos os projetos (inclusive nos projetos atuais).
Se o projeto possui 5 integrantes, existem 10 canais de comunicao.
120
Pode-se descobrir o nmero de canais de comunicao de uma forma

relativamente simples, veja:
[N * (N-1)]/ 2
Onde: N o nmero de pessoas envolvidas no projeto.
Segundo o Project Management Institute (PMI) existe uma correlao direta
entre a capacidade de comunicao e o desempenho do projeto, isto , um bom
gerenciamento de comunicaes fator determinante de sucesso ou fracasso em
projetos. Segundo o Project Management Body of Knowledge (PMBok) que
um conjunto de boas prticas em gerenciamento de projetos, o gerenciamento
das comunicaes do projeto inclui os processos necessrios para assegurar que
as informaes do projeto sejam geradas, coletadas, distribudas, armazenadas,
recuperadas e organizadas de maneira oportuna e apropriada.
Observe que muitas vezes no dedicamos o tempo necessrio nesse
gerenciamento, mas vamos a um simples exemplo:
121
Plano de comunicao
Existem vrias barreiras no processo de comunicao, como:
Ambientes ruidosos;
Distncia;
122
Codificao inadequada da mensagem;

Hostilidade;
Fazer declaraes negativas;
Cultura;
Idioma;
E outros.
Um ponto crtico das interaes dentro do projeto deixar claro que as
comunicaes precisam de formalidade e devem necessariamente passar pelo
gerente de projeto. Caso contrrio, os riscos de problemas de comunicao
podem crescer significativamente.
O primeiro passo para um bom plano de comunicao identificar todas as partes
interessadas em um projeto - elas so: quem influencia ou influenciado pelo
projeto ou pelo resultado do projeto j que podem 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.
Um conceito bsico que as comunicaes devem ser eficientes (fornecendo
apenas as informaes necessrias) e eficazes (informaes nos formatos certos
e no momento certo). Veja:
Quem deve receber quais informaes?
Quais so as reais necessidades de informao?
123
Qual informao necessria, de que tipo?

Em que formato e meio deve ser transmitida a informao?
Com que frequncia?
Qual o fluxo de informaes?
Existem diversos tipos de comunicao: escrita, verbal, formal, informal, no
formal, paralingustica, interativa, passiva, ativa etc.
A cultura da empresa pode ser uma barreira ou um facilitador, por isso uma
anlise da cultura organizacional fundamental no papel do gerente de projetos
como integrador de reas, ou seja, inteligncia conversacional.
Um gerente de projeto passa aproximadamente 90% do seu tempo se
comunicando e para que o projeto tenha maiores chances de sucesso, entre
outras coisas, um bom plano de comunicao fundamental.
Comunicao osmtica
Muitas tcnicas, ferramentas e recomendaes geis preveem a interao caraa-cara, assim o espao onde o time ir trabalhar pode ser um fator de melhora
nos processos. Times geis preferivelmente devem trabalhar em espaos sem
barreiras e de fcil acesso. Agrupar os times em um mesmo ambiente facilita a
interao, diminui o desperdcio (provocado por espera por uma informao ou
deslocamento), alm de promover a comunicao osmtica.
Voc sabe o que comunicao osmtica?
Comunicao osmtica refere-se a toda informao til que flui de membros da
equipe como parte de conversas e perguntas dirias, quando trabalham em
estreita proximidade um do outro. Alistair Cockburn, em seu trabalho Agile
Software Development define a comunicao osmtica como: Campos de

energia que irradiam de pessoas. Se voc est muito longe, voc recebe muito
124
pouco, mas se voc estiver trabalhando em estreita proximidade, voc obter

todos os benefcios.
Para facilitar a comunicao cara a cara e o compartilhamento de conhecimentos,
recomendado que os times sejam de tamanho reduzido, geralmente com at
12 membros ou menos (Lembre-se de 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.
Equipes virtuais
Quando trabalhamos com equipes virtuais (distantes geograficamente) temos
que utilizar os recursos tecnolgicos, como por exemplo, programas de
mensagens instantneas, videoconferncias, VoIPs, interfaces remotas e
colaborativas etc. para promover a comunicao constante.
Sempre que possvel promova pelo menos uma reunio onde todos os membros
do time estejam presentes, mesmo que no dia a dia eles trabalhem distantes,
125
uma atividade para que eles se conheam (fisicamente) catalisa a fase de

formao e melhora as futuras comunicaes.
Acompanhamento de produtividade
Um dos grandes desafios de projetos geis o acompanhamento de
produtividade. A medio fundamental para planejarmos cronologicamente as
verses e itens que sero entregues em cada Sprint.
126
Antes de apresentarmos as formas de acompanhamento de produtividade,

devemos lembrar que:
A mudana do tamanho do Sprint ou da composio do time (mesmo que seja a
sada ou entrada de apenas um novo membro) alterar a base histrica de
entrega do time e as medies devero ser novamente contabilizadas.
R elease Burndow n Chart

A ferramenta de Release Burndown permite acompanhar a evoluo das verses
de seu produto de maneira simples e visual. O eixo vertical apresenta o esforo
da release (este esforo foi estimado pelo time, em pontos, horas ou outra
mtrica pr-acordada), o eixo horizontal representa as sprints. Observe que o
eixo tem comportamento decrescente e inicia-se no topo do eixo vertical e
termina na base (ponto O) desse mesmo eixo.
O grfico Burndown Chart tambm pode ser aplicado para o acompanhamento

do Sprint, seguido os mesmos princpios. A diferena est no eixo horizontal,
127
onde, ao invs de marcar o nmero do Sprint, ele acompanha a evoluo dos

dias do Sprint, conforme apresentado na figura a seguir:
Observe na imagem que baseado no nmero de pontos (eixo vertical) podemos
planejar a evoluo do trabalho at que ele esteja completamente pronto,
representado pela linha azul na imagem. Com o Sprint iniciada, atualizamos o
grfico e medimos nossa evoluo em relao ao planejado, representado pela
linha vermelha.
Cumulative Flow Diagram (CFD)

O CFD uma tima ferramenta para monitoramento do trabalho de
desenvolvimento. Com ele podemos acompanhar o trabalho que falta, o trabalho
em progresso (WIP) e o trabalho pronto. Seu funcionamento simples, no eixo
vertical temos o trabalho estimado em pontos, horas ou outra mtrica predefinida
pelo time, no eixo horizontal, o tempo (em dias, semanas ou sprints). Uma
grande diferena entre o CFD e o Burndown Chart que podemos visualizar o
trabalho em progresso.
128
Veja na imagem que a rea em cor amarela apresenta o trabalho que est
pendente, isto , trabalho no iniciado, a rea laranja representa o trabalho em
progresso e a azul o trabalho pronto.
Observe que o grfico pode ajudar o Scrum Master e o time a analisarem o
comportamento do processo e auxiliar os ajustes necessrios. No exemplo da
imagem temos uma rea com grande amplitude na cor laranja (WIP), significa
que o time iniciou mais tarefas em paralelo antes de finalizar as que j estavam
em desenvolvimento, essa ao, em geral, deve ser evitada, lembre-se que
mais importante entregar tarefas do que iniciar novas (acumulo de WIP no
bom sinal).
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 histrias em paralelo, para evitar o acmulo do
trabalho em andamento e o atraso nas entregas.
129
Atividade proposta
Em seu dia a dia, quantos canais de comunicao existem? Voc acredita que o
nmero de canais colabora com a evoluo do trabalho ou a prejudica?
Chave de resposta: Para calcular o nmero de canais utilizamos a frmula [N
* (N-1)]/ 2, onde N o nmero de pessoas da equipe.
Em geral, quanto maior o nmero, mais complexo se torna o trabalho.
Aprenda Mais
Para saber mais sobre direito processual acesse o link, Scrum Aliance .
Referncias
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-GuidePortuguese-BR.pdf ;. Acesso em: 20 jan. 2015.
Exerccios de fixao
Questo 1
Quantos canais de comunicao existem em um time composto por 8 membros
?
a) 8
b) 16
c) 32
d) 28
e) 36
130
Questo 2
Marque V para verdadeiro, F para Falso:
( ) O time de Renata composto por 5 membros e historicamente consegue
entregar 25 pontos por Sprint, Renata precisou sair do time e em seu lugar entrou
Juliana, que possui a mesma formao tcnica que Renata, assim a capacidade
do time se manter com a mesma capacidade, 25 pontos por Sprint.
( ) Quando trabalhamos com equipes virtuais (distantes geograficamente) demos
utilizar os recursos tecnolgicos (programas de mensagens instantneas,
videoconferncias, VoIPs, interfaces remotas e colaborativas etc. para promover
a comunicao constante.
( ) 8 pontos para o time A e 18 pontos para o time B no so o mesmo
esforo. A percepo de quanto esforo necessrio para realizar um ponto
subjetiva e diferente para cada time.
a) F V V
b) F V F
c) V V V
d) V F V
e) F F V
Questo 3
Seguindo o PMBoK, as sete origens de Conflitos, em ordem de frequncia, so:
a) Cronogramas prioridades do projeto recursos opinies tcnicas
procedimentos administrativos custo personalidade.
b) Personalidade cronogramas prioridades do projeto recursos
opinies tcnicas procedimentos administrativos custo.
131
c) Personalidade custo cronogramas prioridades do projeto recursos

opinies tcnicas procedimentos administrativos.
d) Personalidade custo cronogramas prioridades do projeto opinies
tcnicas recursos procedimentos administrativos.
e) Custo cronogramas prioridades do projeto recursos opinies
tcnicas procedimentos administrativos personalidade.
Questo 4
O termo comunicao osmtica refere-se a:
a) Toda informao til que flui de membros da equipe como parte de
conversas e perguntas dirias, quando trabalham em estreita proximidade
um do outro.
b) Toda informao recebida pelos canais oficiais de comunicao
estabelecidos no incio do projeto.
c) Toda comunicao planejada e contida no plano de comunicao.
d) A fofoca entre membros do time, que poder prejudicar os
relacionamentos futuros.
e) Comunicao obtida pela percepo visual, como o comportamento
corporal do emissor e receptor das mensagens.
Questo 5
Analise o grfico e marque a opo correte:
132
a)
A linha azul representa o planejado para a Sprint, a linha pontilhada
o realizado pelo time.

b) No dia 6 o trabalho apresentou grande evoluo produzindo 110 pontos.
c) No dia 9 ainda restavam 37 pontos para serem entregues.
d) Podemos afirmar que este time poder entregar 125 pontos toda Sprint.
e) O Sprint Burndown Chart auxilia o time a planejar revises tcnicas nos
produtos prontos.
133
Chaves de resposta
Aula 1
Exerccios de fixao
Questo 1 - E
Justificativa: Inovao contnua uma caracterstica de projetos de profissionais
do conhecimento e no de projetos de construo (trabalho industrial).
Questo 2 - A
Justificativa: Trabalho visvel uma caracterstica de projetos de construo
(trabalho industrial) e no de projetos de profissionais do conhecimento.
Questo 3 - A
Justificativa: Catico - impossvel discernir a relao entre causa e efeito.
Complexo - causas e efeitos so to entrelaadas e intrincadas que as coisas s
fazem sentido em retrospecto.
Simples - a relao entre causa e efeito bvia para todos.
Complicado - relao entre causa e efeito requer uma anlise ou alguma outra
forma de investigao e/ou a aplicao de conhecimento especializado.
Questo 4 - A
Justificativa: Projetos no so atividades que repetem-se todos os meses.
Projetos criam um resultado nico e um esforo temporrio. Geralmente o que
se repete todos os meses so os processos organizacionais.
Processo como uma sequncia de passos, tarefas e atividades que convertem
entradas em uma sada. Um processo contnuo e repetitivo.
Questo 5 - A
Justificativa: Tm objetivos definidos. Escopo elaborado progressivamente ao
longo do ciclo de vida.
134
Tm grande alcance e Proporcionam benefcios mais significativos. DIZ

RESPEITO A PROGRAMA.
Tm um mbito organizacional, e mudam de acordo com os objetivos
estratgicos da organizao. DIZ RESPEITO A PORTFLIO.
Tm mbito processual e Proporcionam a melhoria contnua organizacional.
TRATA DE GESTO DA QUALIDADE DE PROCESSOS ORGANIZACIONAIS E NO
PROJETOS.
Tem objetivos claros e devem surpreender o solicitante adicionando novas
funcionalidades que podero ser teis no futuro, mesmo quando no solicitadas.
ERRADO POIS ESCOPO NO PREVISTO NO UMA BOA PRTICA POIS GERA O
GOLD
PLATING,
ESCOPO
NO
SOLICITADO
CONDENAGO
EM
GERENCIAMENTO DE PROJETOS.
Questo 6 - A
Justificativa: Os gerentes esperam mudanas e implementam processos para
manter o gerenciamento e o controle de mudana.
Gestores esperam mudanas a partir de dentro e de fora do programa e esto
preparados para administr-las. DIZ RESPEITO A PROGRAMAS
Gestores monitoram continuamente as mudanas no ambiente interno e externo
da organizao. DIZ RESPEITO A PORTFLIO
Os gerentes no autorizam mudanas pois aps planejamento a mudana
inviabiliza o plano de gerenciamento. MUDANAS PODEM OCORRER, MAS
DEVEM SER AVALIADAS ASSIM COMO SEUS IMPACTOS E ALTERNATIVAS PELO
PROCESSO DE GERENCIAMENTO DE MUDANAS.
Todos as mudanas so bem aceitas e incorporadas imediatamente no plano de
projeto atendendo as necessidades de negcio. MUDANAS PODEM OCORRER,
MAS DEVEM SER AVALIADAS ASSIM COMO SEUS IMPACTOS E ALTERNATIVAS
PELO PROCESSO DE GERENCIAMENTO DE MUDANAS.
Questo 7 - B
135
Justificativa: Um programa um grupo de PROJETOS relacionados gerenciados

de modo coordenado para a obteno de benefcios e controle que no estariam
disponveis se eles fossem gerenciados individualmente.
Questo 8 - A
Justificativa: UM SUBPROJETO Uma parte menor do PROJETO total, que pode
ter certa autonomia, mas sua existncia no faz sentido sozinha. Normalmente,
terceirizada ou delegada a outra rea.
Questo 9 - A
Justificativa: As tcnicas de gerenciamento de projetos complicados, como as
boas prticas do PMBoK (ex: Plano de comunicaes, estimativas de custo,
declaraes de trabalho de aquisio etc.), podem ser aplicadas em projetos
complexos, assim como tcnicas de agilidade (ex: Reunio de Retrospectiva,
Reunio de Planejamento da Interao, Definio de Viso do Produto,
planejamento de release etc.), de projetos complexos, podem ser aplicadas em
cenrios complicados e simples, tudo depende da anlise do gerente do projeto.
Aula 2
Exerccios de fixao
Questo 1 - A
Justificativa: Indivduos e interaes mais que processos e ferramentas
Observe que o primeiro valor do manifesto deixa claro uma importante
mensagem, processo e as ferramentas provavelmente sero necessrio no
projeto, porm, devemos tentar concentrar a ateno da equipe sobre os
indivduos e interaes envolvidos no projeto. Lembre-se que projetos so
realizados por pessoas, e no por ferramentas, assim como os problemas so
resolvidos por pessoas, e no processos.
Focando primariamente no desenvolvimento dos indivduos envolvidos no projeto
e enfatizando as interaes produtivas e eficazes, melhoramos as chances de
sucesso do projeto.
136
Lembre-se que isso no dizer que processos e ferramentas no podem

ajudar na concluso com xito de um projeto. Processos e ferramentas
bem desenhados e adequados so ativos de grande importncia.
Responder a mudanas mais que seguir um plano
Em projetos com grande nmero de incertezas, quase certo que os planos
iniciais sero alterados. Em vez de investir esforos na tentativa de trazer o
projeto de volta aos planos originais, ns deveramos gastar esforo e energia
responder s inevitveis mudanas no projeto. Observe que este valor no
est sugerindo abandonar o planejamento e apenas reagir s
mudanas. Ns ainda precisamos planejar, mas temos de reconhecer
que os planos iniciais foram criados quando conhecamos menos sobre
o Projeto (no incio), e com o desenvolvimento do trabalho, vamos
precisar atualizar o plano. Muitos dos mtodos geis focam em macro planos
superficiais (criao de histrias, product release, casos de uso etc.), e um
planejamento mais especfico para iteraes (ou sprints).
Questo 2 - B
Justificativa: Mudanas nos requisitos so bem-vindas, mesmo tardiamente no
desenvolvimento. Processos geis tiram vantagem das mudanas visando
vantagem competitiva para o cliente.
Questo 3 - B
Justificativa: No enunciado, a pergunta contextualizada de memorizao, isto
, resposta direta com a justificativa no enunciado.
Questo 4 - B
Justificativa: No enunciado, a pergunta contextualizada de memorizao, isto
, resposta direta com a justificativa no enunciado.
Questo 5 - B
Justificativa: Prever problemas futuros se antecipando as necessidades futuras
do cliente uma prtica que no deve ser seguida, j que em projetos de
software, as mudanas so rotineiras e para se prever uma necessidade, estamos

partindo de premissas (eventos incertos que tratamos como verdade para se
planejar) que muitas vezes so falhas. Assim os mtodos geis defendem o fazer
o simples, o que realmente foi solicitado no momento atual.
Aula 3
Exerccios de fixao
Questo 1 - A
Justificativa: Adiar decises: Parece estranho esse conceito mas a mensagem
aqui equilibrar o planejamento antecipado com a tomada de decises e decidir
o mais tarde possvel. Veja que no se est defendendo a procrastinao, mas
sim esperar o mximo possvel antes de decidir. Em muitos projetos na fase inicial
estamos decidindo baseado em vrias premissas (lembrando, premissa - eventos
incertos que para fins de planejamento consideramos como verdadeiros, o que
na execuo do projeto no necessariamente ser verdadeira), o que sempre
traz riscos ao projeto, como estar restrito a uma soluo limitada por uma
tecnologia disponvel at o momento.
Questo 2 - E
Justificativa: O desperdcio com erros por falta de planejamento tambm
combatido pelo Lean, porm classificado como MURI, desperdcio gerado pela
falta de planejamento (ou planejamento malfeito). Na MURI tambm
classificamos o desperdcio causado pelo excesso de burocracia.
Questo 3 - A
Justificativa: O KanBan no elimina o planejamento. As atividades/itens que so
inseridos no quadro na rea que representa trabalhos no iniciados so frutos de
planejamentos prvios, o KanBan torna visuais esses itens e o fluxo de
acompanhamento at que eles estejam prontos.
Questo 4 - A
138
Justificativa: Questo auto explicativa

Questo 5 - A
Justificativa: Opo correta letra A
Aula 4
Exerccios de fixao
Questo 1 - A
Justificativa: De acordo com a sequncia a resposta correta A.
Questo 2 - A
Justificativa: Transparncia
Todo o processo deve estar visvel a todos os envolvidos. Essa 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, o novo processo proposto testado e validado.
Questo 3 - D
Justificativa: De acordo com as alternativas a resposta correta D.
Questo 4 - E
Justificativa: O tamanho do Sprint influenciado (ou pode ser alterado)
dependendo do escopo, tamanho do time, disponibilidade do cliente,
conhecimento do time sobre agilidade, conhecimento do time sobre a tecnologia,
mudanas na formao do time. Porm sempre que um novo tamanho definido,
as mtricas de produtividade devero ser refeitas. A deciso isolada do Scrum
139
Master no pode alterar o tamanho do Sprint. Essa deciso do time e sob

alguma(s) da(s) justificativa(s) apresentada(s) acima.
Questo 5 - B
Justificativa: O Scrum classificado como um mtodo emprico porque todas as
decises so baseadas no desejo do membros do time, buscando um ambiente
mais agradvel.
Aula 5
Exerccios de fixao
Questo 1 - A
Justificativa: Backlog de Produto e Backlog do Sprint so os artefatos do Scrum.
Questo 2 - C
Justificativa: Reunio de Planejamento, Scrum Dirio, Reunio de Reviso e
Reunio de Retrospectiva so os eventos do Scrum.
Questo 3 - B
Justificativa: Backlog de Produto e Backlog do Sprint so os artefatos do Scrum.
Scrum Master, Product Owner e Dev. Team so os papis do Scrum.
Questo 4 - A
Justificativa: De acordo com a situao apresentada, possvel afirmar que o
evento um Scrum Dirio - Daily Scrum.
Questo 5 - B
Justificativa: De acordo com a situao apresentada, possvel afirmar que o
evento um Reunio de Planejamento - Planning meeting.
140
Aula 6
Exerccios de fixao
Questo 1 - B
Justificativa: O verdadeiro objetivo das reunies de retrospectiva identificar
oportunidades de melhorias em seu trabalho para a evoluo do time.
Questo 2 - A
Justificativa: Essa tcnica tem como objetivo apresentar as habilidade e
competncias de cada membro do time e planejar formas de compartilhamento
de habilidades e conhecimentos. Em geral, para times recm-formados.
Questo 3 - A
Justificativa: O Scrum Guide recomenda que a durao da reunio de
restrospectiva no deve ser superior a 3,75% do Sprint.
Questo 4 - F, V, F
Justificativa: A reunio de retrospectiva obrigatria, pois um recurso de
melhoria contnua e permanente. O Product Owner s participa da reunio de
retrospectiva se o Dev. Team e o Scrum Master convidarem-no.
Aula 7
Exerccios de fixao
Questo 1 - D
Justificativa: A responsabilidade sobre a priorizao do que mais importante
para a empresa de responsabilidade do Product Owner, assim como as aes
que dizem respeito ao negcio. J o Scrum Master deve cuidar das aes sobre
processos e o Dev. Team sobre solues tecnolgicas do projeto.
Questo 2 - A
Justificativa: As histrias tambm utilizam os conceitos conhecidos com INVEST:
141
Independente A histrias so mais fceis de se trabalhar quando so

independentes, isto , no dependem de outras histrias para acontecerem.
Negocivel A histria no um contrato com definio de funcionalidades, ela
negocivel para melhor atender as necessidades do negcio.
Valiosa para usurios e clientes - A histria precisa estar associada a um valor
para o usurio ou clientes, sem isso, no existe razo para ela existir.
Estimvel A histria precisa ser estimvel, mesmo que com alguma impreciso,
precisamos dimensionar o esforo para implement-la.
Small(pequena) Histrias representam situaes simples, com poucos
personagens.
Testvel Toda histria precisa ser testvel. O cliente deve identificar quais
seriam as condies de testes da histria escrita. As condies de teste definidas
pelo cliente ajudam o time a entender se a meta da histria foi bem sucedida.
Questo 3 - A
Justificativa: Como vimos na aula, todas as opes esto corretas j quea tcnica
Kano baseada em entrevistas com os usurios e experts. Ela bem interessante
quando a opinio de todos tem o mesmo valor (diferentemente da tcnica de
Priority Markets, onde podemos atribuir pesos maiores para os Decision Makers).
Na tcnica Theme Screening, geralmente selecionamos de 5 a 9 critrios para
avaliar o que mais importante para o prximo Sprint. E j na MMF (Minimum
Marketable Feature) pode ser utilizada para priorizao de seu backlog de
produto e para o planejamento de verses. Ela baseia-se em identificar as
caractersticas mnimas comercializveis de seu produto.
Questo 4 - E
Justificativa: Como o planejamento iterativo e se adapta as necessidades do
cliente e momento de mercado, geramos planos para cada Sprint ou iterao e
nunca para todo o projeto j que mudanas ocorrero. O esforo na iniciao
no gerar um plano detalhado e sim um viso madura do projeto.
Questo 5 - A
142
Justificativa: O ROI o retorno sobre investimento, ns aceleramos o ROI quando

entregamos de maneira funcional a demanda mais importante para o momento
do projeto.
Aula 8
Exerccios de fixao
Questo 1 - D
Justificativa: [8*(8-1)]/2 = 28
Questo 2 - A
Justificativa: A mudana do tamanho do Sprint ou da composio do time
(mesmo que seja a sada ou entrada de apenas um novo membro) alterar a
base histrica de entrega do time e as medies devero ser novamente
contabilizadas, invalidando as anteriores.
Questo 3 - A
Justificativa: O PMBoK apresenta as sete origens de conflitos em ordem de
frequncia:
1) Cronogramas;
2) Prioridades do projeto;
3) Recursos;
4) Opinies tcnicas;
5) Procedimentos administrativos;
6) Custo;
7) Personalidade.
Questo 4 - A
Justificativa: "A" Pendente
Questo 5 - A
143
Justificativa: A linha azul representa o planejado para a Sprint, a linha pontilhada

o realizado pelo time.
No. Na verdade o oposto. A linha azul representa o realizado e a pontilhada o
planejado.
No dia 6 o trabalho apresentou grande evoluo produzindo 110 pontos.
Observe na imagem acima que no dia 5, ainda faltavam 93 pontos para a equipe,
mas no dia 6, estes pontos cresceram para 110, isso pode ocorrer por algumas
razes:
Negociao do Product Owner com o time para adicionar novo item a
Sprint (caso raro, s justificado por emerg6encias do negcio);
O time identificou um erro e retornou um item que estava prontopara a
fase de trabalho em progresso;
Trabalho de refatorao ou ajuste.
Podemos afirmar que este time poder entregar 125 pontos toda Sprint.
No. A medio de apenas uma Sprint no pode ser utilizada como parmetro, o
aconselhvel medir no mnimo ou 5 Sprints para avaliar a perfornace do time.
O Sprint Burndown Chart auxilia o time a planejar revises tcnicas nos produtos
prontos.
Produto pronto est pronto, se precisa de reviso ele no est pronto. O Sprint
Burndown Chart uma ferramenta para acompanhar a produo do time na
Sprint.
144
Conteudista
Rafael Dias Ribeiro professor em cursos de Graduao e Ps Graduao nas
reas de TI, Gerenciamento de Projetos, Mtodos geis, Governana e Negcios
para instituies como Universidade Estcio de S, FEUC e Instituto Superior de
Tecnologia em Cincias da Computao do Rio de Janeiro.
Profissional com habilidades e cometncias nas reas de TI, Gesto de equipes,
Mtodos geis, Gerncia de Equipe de Software, Gerenciamento de Projetos de
TI e Negcios.
Atuao em Projetos como:
- Clula de Desenvolvimento web - IST/Rio
- Projeto de Treinamento em Gerncia de Projetos - Marinha do Brasil - Centro
de Adestramento Almirante Newton Braga
- Projeto de criao do Novo Modelo de Ensino - Estcio Participaes
- Projeto Programa 30 - Unitec
- Projeto Favela-Bairro
- Projeto de Capacitao em TI para CBMERJ
Formao Acadmica:
Mestre em Sistemas e Computao - Instituto Militar de Engenharia - 2007
Bacharel em Informtica (nfase em Anlise de Sistemas)- Unesa - 2001
Certificaes Internacionais:
Project Management Institute (PMI)
Project Management Professional- PMP
Agile Certified Practitioner - ACP
ScrumAlliance
145
Certified Scrum Master CSM

Certified Scrum Product Owner CSPO
Information Systems Audit and Control Association (ISACA)
COBIT Foundation Certificate
Human Change Management Institute
Certificao em Gesto de Mudanas HCMBOK Certified Professional
146

Gerenciamento de Projetos de Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerenciamento de Projetos de Software

Enviado por

Direitos autorais:

Formatos disponíveis

ENGENHARIA DE SOFTWARE

GERENCIAMENTO DE PROJETOS DE SOFTWARE

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Gerenciamento de Projetos de Software Apostila

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Aula 1: Fundamentos do Gerenciamento de Projetos

GERENCIAMENTO DE PROJETOS DE SOFTWARE

A definio do PMBoK-Project Management Body of Knowledge, sobre projeto,

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Dave Snowden, que descreve uma perspectiva sobre a natureza evolutiva de

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Teoria de Cynefin - Simples

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Teoria de Cynefin - Complicado

GERENCIAMENTO DE PROJETOS DE SOFTWARE

O sistema imprevisvel em detalhes, mais ainda podemos discernir padres.

Teoria de Cynefin Catico e desordem

Desordem o quinto domnio. o estado de no saber que tipo de causalidade

food (cenrio simples) e o atendimento demore por volta de 20 minutos, voc

Projetos complexos como softwares, desenhos e redesenhos de processos,

Projetos direcionados a valor e projetos direcionados a planos

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Em projetos direcionados a plano, como o prprio nome sugere, temos um

Projetos orientados a valor

que melhor, o martelo ou o alicate? A resposta depende se voc

gerenciamento eficaz desse trabalho, a fim de atingir os objetivos de negcios

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Preparamos uma tabela com as principais consideraes sobre portflio e

GERENCIAMENTO DE PROJETOS DE SOFTWARE

GERENCIAMENTO DE PROJETOS DE SOFTWARE

http://exame.abril.com.br/carreira/noticias/por-que-gerenciar-projetosm0042508; Acesso em: 25 nov. 2013.

e) Foco nas perguntas certas

abordagem orientada a valor, visto que a entrega final tem grande

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Aula 2: Mtodos geis

gerenciamento. A abordagem gil muito utilizada em projetos orientados a

software de alta qualidade, mas muitas vezes h entregas em partes

software no agrega absolutamente nada a nenhuma organizao.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Colaborao com o cliente

sprint), pagamento por pontos, histrias, ou outras que permitem a flexibilidade

release, casos de uso etc.), e um planejamento mais especfico para iteraes

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Os doze princpios do Manifesto

desenvolvimento. Processos geis tiram vantagem das mudanas visando

Software funcionando a medida primria de progresso.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Simplicidade - a arte de maximizar a quantidade de trabalho no realizado

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Existem diversas metodologias e frameworks geis, os mais comuns e utilizados

Dynamic Systems Development Method (DSDM), Crystal, Lean, KanBan, e outros.

Desenvolvimento dirigido a funcionalidades

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Modelagem de Domnio do Objeto: as equipes devem explorar e explicar o

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Metodologia de desenvolvimento de sistemas dinmicos

Development (RAD) - Desenvolvimento Rpido de Aplicaes, o DSDM enfatiza o

Ciclo de vida DSDM

Desenvolvimento incremental com bases slidas

GERENCIAMENTO DE PROJETOS DE SOFTWARE

Segurana pessoal (Crystal defende um ambiente seguro para que todos

desenvolvimento de uma ou mais funcionalidades em intervalos de duas semanas

Times Dinmicos: Estes so pequenas equipes, formadas dinamicamente de