Você está na página 1de 147

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

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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 (...)

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

12

Preparamos uma tabela com as principais consideraes sobre portflio e


gerenciamento de projetos organizados.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
produto, servio ou resultado exclusivo.
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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE 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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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).

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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).

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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).
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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)

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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?

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:&#60;

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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&#60;Card&#62; cards = new List&#60;Card&#62;( );
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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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( ) );
}
}

Black Jack - teste 2


Teste 2: Existem 13 cartas de cada naipe?
Classe que testa se existem 52 cartas no baralho e se so 13 de cada naipe.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

50

public class DeckTest2


{
public void Verify_Deck_contains_52_cards( )
{
var deck = new Deck( );
Assert.AreEqual(52,deck.Count( ) );
}
public void
Verify_Deck_contains_13_cards_for_each_suit( )
{
var deck = new Deck( );
Assert.AreEqual(13,deck.NumberofCopas( ) );
Assert.AreEqual(13,deck.NumberofEspadas( ) );
Assert.AreEqual(13,deck.NumberofOuros( ) );
Assert.AreEqual(13,deck.NumberofPaus( ) );
}
}

GERENCIAMENTO DE PROJETOS DE SOFTWARE

51

Black Jack - teste 3

Teste 3: H carta Coringa?


public class DeckTest2
{
//..Continuao
GERENCIAMENTO DE PROJETOS DE SOFTWARE

52

public void Verify_Deck_contains_no_joker( )


{
var deck = new Deck( );
Assert.IsFalse(deck.Contains(Card.Coringa ) );
}
}
Classe que testa se h coringa nas cartas geradas.

Black Jack - teste 4

Teste 4: Existe apenas uma carta de cada tipo?


public class DeckTest2
{
//..Continuao
public void Verify_Every_Card_in_the_Deck ( )
{
var deck = new Deck( );
Assert.IsTrue(deck.Contains(Card. Dois_de_Copas ) );
Assert.IsTrue(deck.Contains(Card. Tres_de_Copas ) );
//...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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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".

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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;
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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;
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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/>.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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?

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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)


GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

73

d) Incrementos do produto prontos


e) Todas as respostas acima

Questo 2
Marque a alternativa correta. So eventos 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
d) Incrementos do produto prontos
e) Todas as respostas acima

Questo 3
Marque a alternativa correta. So papis 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
d) Incrementos do produto prontos
e) Todas as respostas acima

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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).
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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;
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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!

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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?

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
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
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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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).

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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?
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.


GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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 &#62; B &#62; C.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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).
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE 107

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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,
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE 119

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:

GERENCIAMENTO DE PROJETOS DE SOFTWARE

121

Plano de comunicao
Existem vrias barreiras no processo de comunicao, como:
Ambientes ruidosos;
Distncia;
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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?
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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,
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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,
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
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
Quantos canais de comunicao existem em um time composto por 8 membros
?
a) 8
b) 16
c) 32
d) 28
e) 36
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE 137

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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:
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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.

GERENCIAMENTO DE PROJETOS DE SOFTWARE

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
GERENCIAMENTO DE PROJETOS DE SOFTWARE

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

GERENCIAMENTO DE PROJETOS DE SOFTWARE

146