Escolar Documentos
Profissional Documentos
Cultura Documentos
SCRUM
São Paulo
2009
LEONARDO BRUNO PEREIRA DE ARAUJO
SCRUM
São Paulo
2009
LEONARDO BRUNO PEREIRA DE ARAUJO
SCRUM
BANCA EXAMINADORA
Dedico
AGRADECIMENTOS
RESUMO
A história registra grandes feitos da humanidade, desde o início das civilizações, que
podem ser classificados como projetos. Contudo, muitos desses projetos foram
realizados de forma empírica, sem os conhecimentos e as habilidades necessárias
de gerenciamento de projetos, ou melhor, sem a aplicação organizada, racionalizada
e coordenada de esforços e recursos. Gerenciar projetos com excelência é um
desafio, fator essencial para sobrevivência das organizações. Isso necessita ser feito
de forma excepcional, conduzido por profissionais qualificados e, observando as
novas exigências da globalização – quer para atender organizações privadas,
governamentais ou ONGs.
8
LISTA DE GRÁFICOS
LISTA DE TABELAS
LISTA DE SIGLAS
HP Hewlett-Packard
Framework
TI Tecnologia da Informação
XP Extreme Programming
12
SUMÁRIO
INTRODUÇÃO ...................................................................................................... 14
1 METODOLOGIAS ÁGEIS .............................................................................. 20
1.1 Extreme Programming .................................................................................. 23
1.1.1 Estórias .................................................................................................... 25
1.1.2 Planejamento ........................................................................................... 26
1.1.3 Desenvolvimento iterativo ...................................................................... 26
1.1.4 Iterações de uma semana ....................................................................... 27
1.1.5 Teste antecipado ..................................................................................... 28
1.1.6 Refactoring .............................................................................................. 29
1.1.7 Programação em par............................................................................... 29
1.1.8 Envolvimento dos clientes ..................................................................... 30
1.2 Feature Driven Development ........................................................................ 30
1.2.1 Desenvolver um modelo geral ............................................................... 32
1.2.2 Construir uma lista de funcionalidades ................................................ 33
1.2.3 Planejar por funcionalidade ................................................................... 33
1.2.4 Projetar por funcionalidade .................................................................... 33
1.2.5 Construir por funcionalidade ................................................................. 34
1.3 Microsoft Solutions Framework ................................................................... 39
1.3.1 Release Manager ..................................................................................... 37
1.4 SCRUM............................................................................................................ 39
1.4.1 Como funciona? ...................................................................................... 40
1.4.2 Papéis e responsabilidades ................................................................... 41
1.4.3 Artefatos, conceitos e fases ................................................................... 42
1.4.3.1 Product Backlog ............................................................................... 42
1.4.3.2 Planejamento da Sprint .................................................................... 42
1.4.3.3 Execução e controle da Sprint......................................................... 42
1.4.3.4 Final da Sprint .................................................................................. 51
2. PMI® e PMBOK® ............................................................................................. 52
2.1 O gerenciamento de projeto ......................................................................... 52
2.2 História ........................................................................................................... 53
13
INTRODUÇÃO
Nos anos 60, houve a difusão dos chamados mainframes, estas máquinas
marcaram início da substituição do relês e válvulas pelo o uso de circuitos
integrados, uma melhora surpreendente no desempenho do hardware, profundas
modificações na arquitetura, aumento significativo na memória, capacidade de
armazenamento e uma variedade incomum de dispositivos de entrada e saída.
O navio da marinha americana USS Vicennes derrubou um Airbus 320, o qual foi
confundido por um F-14. 290 pessoas morreram. O software do radar não
diferenciou um avião de passageiros de um caça inimigo de ataque.
A pior falha no sistema elétrico dos Estados Unidos da America (EUA) em toda
sua história, o blackout deixou mais de 50 milhões de clientes sem energia
elétrica, mais de 100 centrais geradoras foram desligadas, as perdas
econômicas foram estimadas em US$ 6.0 bilhões, um bug de software foi
identificado como o grande fator determinante para a causa do blackout.
• Por que não podemos achar todos os erros antes de entregar o software aos
clientes?
• Por que continuamos a ter dificuldade em avaliar o progresso enquanto o
software é desenvolvido?
• Por que os cronogramas e custos são imprecisos?
• Por que não existem dados históricos sobre o processo de desenvolvimento?
• Por que a comunicação é deficiente?
• Por que os usuários ficam insatisfeitos?
• Por que há carência de conceitos quantitativos sobre confiabilidade, qualidade
e reusabilidade?
Por outro lado, uma nova abordagem para desenvolvimento de software tem
despertado grande interesse entre as organizações de todo o mundo. Vivemos uma
tendência para o desenvolvimento acelerado de aplicações devido ao ritmo das
mudanças na tecnologia da informação, pressões por constantes inovações,
concorrência acirrada e grande dinamismo no ambiente de negócios (BOEHM,
2006).
Criada por Jeff Sutherland, Ken Schwaber e John Scumniotales na década de 1990,
a SCRUM é uma metodologia ágil para gerenciamento de projetos, geralmente de
software, mas pode ser utilizada para outros tipos, como desenvolvimento de
produtos físicos, ou projetos diversos. Baseada no Pensamento Lean (Lean
19
1 METODOLOGIAS ÁGEIS
Mesmo com a evolução dos computadores, das técnicas e ferramentas nos últimos
anos, a produção de software confiável, correto e entregue dentro dos prazos e
custos estipulados ainda é muito difícil. Dados de 1995 segundo a Standish Group -
Chaos Report, usando como exemplos 8380 projetos, mostram que apenas 16,2%
dos projetos foram entregues respeitando os prazos e os custos e com todas as
funcionalidades especificadas. Aproximadamente 31% dos projetos foram
cancelados antes de estarem completos e 52,7% foram entregues, porém com
prazos maiores, custos maiores ou com menos funcionalidades do que especificado
no início do projeto (SOARES, 2009).
Dentre os projetos que não foram finalizados de acordo com os prazos e custos
especificados, a média de atrasos foi de 222%, e a média de custo foi de 189% a
mais do que o previsto. Considerando todos os projetos que foram entregues além
do prazo e com custo maior, na média, apenas 61% das funcionalidades originais
foram incluídas. Mesmo os projetos cuja entrega é feita respeitando os limites de
prazo e custos possuem qualidade suspeita, uma vez que provavelmente foram
feitos com muita pressão sobre os desenvolvedores, o que pode quadruplicar o
número de erros de software, segundo a mesma pesquisa. As principais razões
destas falhas estavam relacionadas com o processo em cascata (COCKBURN;
HIGHSMITH, 2001).
21
Para ser realmente considerada ágil a metodologia deve aceitar a mudança ao invés
de tentar prever o futuro. O problema não é a mudança em si, mesmo porque ela
ocorrerá de qualquer forma. O problema é como receber, avaliar e responder às
mudanças. Enquanto as metodologias ágeis variam em termos de práticas e
ênfases, elas compartilham algumas características, como desenvolvimento iterativo
e incremental, comunicação e redução de produtos intermediários, como
documentação extensiva. Desta forma existem maiores possibilidades de atender
aos requisitos do cliente, que muitas vezes são mutáveis (SOARES, 2009).
Atualmente, existem algumas metodologias ágeis, cada uma exposta pela The Agile
Alliance. Nesse estudo, apresentarei quatro propostas ágeis, são elas: Extreme
Programming (XP), Feature Driven Development (FDD), SCRUM e Microsoft
Solutions Framework (MSF). Darei ênfase na metodologia ágil SCRUM, que será
objeto de análise desse trabalho de conclusão de curso.
23
1.1.1 Estórias
1.1.2 Planejamento
Como é difícil avaliar o custo e o valor de cada estória, fica difícil fazer o
planejamento do projeto. As informações utilizadas para fazer este tipo de avaliação
mudam no tempo. O planejamento não é uma previsão do futuro. No melhor caso,
ele expressa tudo que se conhece hoje sobre o que pode acontecer amanhã. O
plano representa um ponto de partida (MARTINS, 2009).
releases devem ser do menor tamanho possível e que ainda possam produzir algum
valor para o negócio (POPPENDIECK; POPPENDIECK, 2003).
Numa implementação do tipo big-bang1, a equipe pode gastar meses sem adicionar
nenhuma nova funcionalidade ao sistema, mas preparando-se para o dia D, fazendo
horas extras e trabalhando em finais de semana. Mesmo que o projeto tenha
sucesso, após a implantação a equipe fica exausta e pode precisar de várias
semanas para se recuperar. Se o projeto não tiver sucesso os custos são ainda
maiores. Implantações do tipo big-bang têm altos riscos e grandes custos humanos
e econômicos.
O trabalho deve ser planejado uma semana de cada vez, que é o horizonte da
iteração. Deve haver uma reunião no começo de cada semana para fazer o
planejamento, nesta reunião serão abordados os seguintes assuntos (TELES, 2004):
1
O método do big bang é o mais usado por empresas de software comercial. A idéia é manter o
máximo de segredo possível, e só liberar o software para aquisição quando cada pequena parte dele
estiver funcionando bem.
28
As rotinas de teste são construídas antes que qualquer código seja escrito. Os
critérios para os testes de aceitação são gerados e escritos pela área de negócios
assim que os requisitos, na forma de estórias, são documentados, os testes de
unidade são criados pelos os desenvolvedores logo antes da programação, e todo
programa gerado precisa passar por todos estes testes (JEFFRIES et al., 2001).
• Mudança de escopo – é fácil divagar e programar algo apenas porque pode vir a
ser necessário no futuro. Ao definir claramente o que o sistema precisa fazer, o
programador terá um foco maior ao fazer a programação;
• Acoplamento e coesão – se for muito difícil desenvolver uma rotina de teste, isto
pode ser um sinal de que há algum problema quanto à forma como o sistema foi
projetado, e não um problema com a rotina de teste propriamente dita. Programas
com baixo acoplamento e alta coesão são fáceis de testar;
• Confiança – é difícil confiar num desenvolvedor que escreve um programa que
não funciona. Ao escrever um código que funciona e que pode ser demonstrado
através de uma rotina automatizada de teste, o desenvolvedor consegue
conquistar a confiança do seu grupo com muito mais facilidade;
• Ritmo – é fácil o programador perder-se por horas quando está programando. Ao
desenvolver antes a rotina de teste, fica mais claro o que deve ser feito na
29
1.1.6 Refactoring
Criado no final da década 90 em Cingapura por um time liderado por Jeff De Luca é
uma simples compilação de práticas estabelecidas nos últimos 30 anos. Um de seus
maiores desenvolvedores, Peter Coad, definiu a idéia de Feature Definition e
Feature List. Renomados autores participaram da concepção das idéias do FDD,
entre eles: Tom De Marco, Tim Lister, Jerry Weinberg e Frederic Brooks. Em sua
essência o FDD é um processo ágil e adaptativo com as seguintes características
(ABRAHAMSSOM, 2002):
• Iterativo;
• Enfatiza a qualidade;
• Entrega resultados tangíveis e freqüentes;
31
As funcionalidades são atribuídas aos lideres técnicos que são responsáveis pelo
seu desenvolvimento. O líder técnico seleciona as próximas funcionalidades para
desenvolvimento a partir da sua lista de prioridades, e compõe seus pacotes de
trabalho. Algumas delas podem ser desenvolvidas simultaneamente quando elas
estão baseadas no mesmo conjunto de classes (LAURINDO, 2007).
O FDD é definido ao redor de um conjunto central de práticas que embora não sejam
inovadoras, são utilizadas de forma inovadora: elas reforçam e complementam umas
as outras. A equipe pode implementar somente algumas das práticas, mas se não
considerar todas elas não obterá todos os benefícios previstos pelo FDD. As práticas
propostas são: Modelagem de Objetos do Domínio, Desenvolvimento por
funcionalidade, o código fonte de cada classe pertence a um programador, Equipes
por funcionalidades, inspeções, builds constantes, gerenciamento de configuração e
controle do progresso (LAURINDO, 2007).
Uma característica marcante do FDD é que este é um processo definido para fazer
repetidamente entregas constantes, tangíveis e funcionais. O FDD é um método
35
simples, objetivo e fácil de seguir, possui técnicas objetivas para lidar com os
problemas de desenvolvimento de software, técnicas claras para informar o
progresso e permitir que as decisões possam ser tomadas em tempo oportuno
(LAURINDO, 2007).
O MSF 4.2 possui duas novas instâncias: MSF for Agile Software Development e
MSF for CMMI Process Improvement. Podemos afirmar que o MSF Agile é a soma
de posições equilibradas, pois defende um Software Development Life Cycle (SDLC)
mais curto com iterações de no máximo quatro semanas, contudo preserva a
importância dos papéis definidos previamente e abomina a linha "todo mundo pode
fazer tudo no projeto". Outro quesito de destaque nesta fusão são os testes unitários
e a preocupação com a cobertura de 100% do código fonte (MICROSOFT, 2009).
Veja a Figura 3.
Figura 3 – MSF – Fonte: MSF for Agile Software Development Process Guidance, Microsoft, 2009.
36
Quando você pensa iterativo e incremental, você organiza a "cultura" do seu projeto
de forma econômica, com foco absoluto no produto e com elementos de motivação.
Esta abordagem de trabalho também propicia o gerenciamento de risco, pois a
informação para a tomada de decisão acontece em períodos curtos (RODRIGUES et
al, 2009).
• Aprendizado contínuo: O próprio projeto é uma rica lição a cada iteração. Você
percebe a evolução da curva de produtividade e acompanha a autonomia técnica
crescente dos colaboradores a cada dia dentro do projeto. Para o MSF, um
projeto precisa dos seguintes papéis, entendem-se papéis como
responsabilidades que devem ser assumidas por algum membro da equipe:
o Program Manager
o Product Manager
o User Experience
o Tester
o Developer
o Architect
Cada membro da equipe é bem autônomo, e espera-se que saibam o que fazer e
planejam como vão fazer a entrega de sua parte do trabalho. Esta valorização do
poder de cada membro da equipe é um dos conceitos que a maioria dos gerentes
tradicionais de projeto precisa aprender ao aplicar o MSF (GARCIA, 1999). Veja a
Figura 4.
38
Figura 4 – MSF – Fonte: MSF for Agile Software Development Process Guidance, Microsoft, 2009
1.4 SCRUM
Segundo Schwaber (2004), SCRUM não é um processo previsível, ele não define o
que fazer em toda circunstância. Ele é usado em trabalhos complexos nos quais não
é possível prever tudo o que irá ocorrer e oferece um framework e um conjunto de
práticas que torna tudo visível. Isso permite aos praticantes do SCRUM saber
exatamente o que acontece ao longo do projeto e fazer os devidos ajustes para
manter o projeto se movendo ao longo do tempo, visando alcançar os seus objetivos
40
Logo, o SCRUM não vai dizer exatamente o que fazer, não irá resolver todos os
seus problemas, mas com certeza os problemas serão mais facilmente identificados.
Por ser um framework, irá servir como um guia de boas práticas para atingir o
sucesso. Entretanto, as decisões de quando e como usá-Io, quais táticas e
estratégias seguir para obter produtividade e realizar as entregas ficam por conta de
quem aplicar. O conhecimento das suas práticas permite a aplicação das mesmas
de forma variada e este é um dos aspectos positivos do SCRUM, a adaptabilidade
(SCHWABER, 2004).
O ciclo do SCRUM tem o seu progresso baseado em uma série de iterações bem
definidas, chamada Sprints, cada uma com duração de duas a quatro semanas,
chamada de Time-box. Antes de cada Sprint, realiza-se uma Reunião de
Planejamento - Sprint Planning Meeting em que o time de desenvolvedores tem
contato com o cliente - Product Owner para priorizar o trabalho que precisa ser feito,
selecionar e estimar as tarefas que o time pode realizar dentro da Sprint. A próxima
fase é a Execução da Sprint (MOUNTAIN, 2009).
Ao final da Sprint, deve-se realizar uma Reunião de Revisão - Sprint Review, em que
o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. Logo
em seguida, realiza-se a Reunião de Retrospectiva - Sprint Retrospective, uma
reunião de lições aprendidas, com o objetivo de melhorar o processo/time e/ou
produto para a próxima Sprint (FIGUEIREDO, 2009).
• Product Owner
• SCRUM Master
• SCRUM Team
Um dos conceitos mais importantes são o Backlog do produto (ou Product Backlog)
e o Backlog de Impedimentos - lmpediment Backlog, ambos considerados o coração
do SCRUM. O Product Backlog contém uma lista de itens priorizados que incluem
tudo o que precisa ser realizado, que possa ser associado com valor de negócio e
para a finalização do projeto, sejam requisitos funcionais ou não. É importante
ressaltar que cada item no Backlog do produto deve ter um valor de negócio
associado - Business Value, no qual podemos medir o retorno do projeto e priorizar
a realização dos itens. O Impediment Backlog contém todos os itens que impedem o
progresso do projeto e geralmente estão associados a riscos. Estes itens não
possuem uma priorização, mas estão geralmente associados a algum item de
Backlog do produto ou ás tarefas do item, exemplos: "instalar ambiente para os
desenvolvedores", "Instalação de banco de dados do projeto" e etc. O controle
desses itens é muito importante e o SCRUM Master é o grande responsável pela
liberação desses impedimentos, abrindo caminho para o time de desenvolvimento
executar a realização dos itens do Backlog do produto (SCHWABER, 2004).
É lógico que a equipe precisa de tempo para poder estimar com segurança, mas ela
deve ser sempre guiada pelo SCRUM Master para que seja produtiva e não disperse
e perca o foco (PEREIRA et al, 2009).
44
Com o Product Backlog priorizado, o time seleciona os itens que acha possível de
executar durante a Sprint. As dúvidas do time são esclarecidas e ao final temos
então o Sprint Backlog, que são os itens do Backlog priorizados para a Sprint. Para
cada item, o time inicia o detalhamento de suas atividades, estimando em horas, a
duração de cada uma delas. Não é mandatário, mas é sugerido que cada tarefa não
ultrapasse a duração de 16h. Se for necessário, deve-se quebrar a tarefa até que
individualmente todas as tarefas estejam dentro do limite de 16h. Uma vez que todas
as tarefas foram estimadas, o time questiona se realmente consegue assumir o
45
Uma vez decidido o item, o time passa para o próximo e esse processo continua até
que todos os itens do Sprint Backlog sejam validados. Nesse momento, não são
alocados os recursos para as tarefas; apenas se estabelece as estimativas em horas
para cada uma. Após a estimativa refinada, pode-se calcular o total de horas
necessário para realizar todas as tarefas. É importante deixar sempre uma folga, já
que mesmo detalhando a estimativa sempre podem aparecer surpresas (PEREIRA
et al, 2009).
Uma vez ajustados os valores e com o time se comprometendo com a execução das
tarefas, existe um ambiente completo para a produção do resultado final da Sprint. O
próximo passo é iniciar a execução da Sprint. É importante lembrar que a Sprint
possui um limite de horas disponível. Este limite é conhecido por LHS (Limite de
Horas da Sprint) que pode ser medido utilizando uma fórmula simples (PEREIRA et
al, 2009):
LHS= (R x H) x D
Onde:
R = Total de recursos do time
H = Total de horas disponíveis para cada recurso
D = Total de dias úteis da Sprint
Note que se você tiver o H variando para alguns recursos, é importante considerar
isso na fórmula. A relação de 1 homem/dia efetivo = 6 homens/hora efetiva é mais
real dependendo do tipo do projeto. Isso significa que se devem considerar apenas
seis horas efetivas de cada recurso das oito normalmente trabalhadas, apenas 75%
do tempo real do recurso é considerado produtivo para a Sprint. Esta sobra é
importante, pois fornece uma idéia mais realista da produtividade de cada recurso e
também garante uma margem de segurança para eventuais imprevistos. Com a
simulação a seguir, pode se entender melhor como calcular o LHS (KNIBERG,
2006).
46
Para uma Sprint com time-box padronizado em 5 dias e um time possui 5 recursos
em que 3 são de 8h, um de 6h e outro de 8h, mas apenas alocado por 50% de seu
tempo, temos o LHS diário considerando a relação acima sugerida de (MOUNTAIN,
2009):
8hx75% = 6h (3)
6hx75% = 4,5h (1)
8hx50% = 4h x 75% =3h (1)
Dias úteis da Sprint = 5
logo,
((3x6) + (4,5) + (3)) = 31,50 (dia)
LHS= 5 x 31,50 = 157,50 h
Esses são cálculos bem simples e você vai precisar usá-los apenas antes de cada
planejamento da Sprint, pois o LHS é que vai indicar se você está alocando as horas
corretas para a equipe (SCHWABER, 2004).
É importante salientar que uma vez estabelecido a duração da Sprint não deve
alterar sua data final, pois todo o projeto é guiado por essa duração. Logo, adiantar
ou atrasar não é interessante para ninguém. Outro motivo importante para se manter
o padrão de duração da Sprint é a relação de produtividade do time dentro da Sprint.
A métrica de esforço (velocity) para o grupo de itens que foram priorizados na Sprint
é que vai dizer se conseguimos medir para um mesmo time-box o total de itens que
foram finalizados por Sprint, e isso comparado a um histórico. Esta métrica é muito
importante, e apenas será real se as Sprints forem de tamanhos iguais
(SCHWABER, 2004)
47
Durante a Sprint, o time, de forma organizada, controla como as tarefas devem ser
executadas. Durante a Sprint não deve existir interferência externa, esse é um dos
principais papéis do SCRUM Master, blindar o time de qualquer desvio do objetivo
traçado. O acompanhamento do progresso é feito realizando reuniões diárias,
chamada de daily meeting. Essas reuniões devem ser rápidas, não mais que 15
minutos, e objetivas. Todos participam, o SCRUM Master e o time. Visitantes são
bem-vindos, mas devem ser apenas ouvintes, pois o daily meeting resume-se ao
time. No daily meeting, a equipe trabalha apenas três perguntas, que são
respondidas por cada membro (PEREIRA et al, 2007):
Todo e qualquer problema encontrado durante o daily meeting deve ser tratado em
uma outra reunião, apenas com os envolvidos. Durante a execução da Sprint, a
alocação de recursos para cada tarefa é dirigida pelo próprio time, cada membro da
equipe seleciona as tarefas que podem realizar e o time estabelece a ordem e
dependência entre elas. Um fator importante de sucesso para o time com o uso do
SCRUM é o controle da disciplina. O time é considerado auto-gerenciável e deve
responder como tal. Para isso, todos os membros do time devem reportar as horas
utilizadas em tarefas para que o valor de horas restantes seja calculado
corretamente e o time possa verificar o seu progresso. Para esse acompanhamento,
o time usa um gráfico chamado de Sprint Burndown, ele exibe o progresso diário do
time em função do total de horas estabelecido pela soma de horas das tarefas dos
itens do Product Backlog selecionados. (PEREIRA et al, 2007), O Gráfico 1 ilustra
um exemplo:
48
O Gráfico 2 indica que a Sprint irá acabar depois da data final. Logo, é preciso rever
as estimativas, pois muitos imprevistos não apareceram durante a preparação da
Sprint, e a indicação é que não será possível terminar o que foi previsto. Talvez seja
necessário rever os itens do Product Backlog remanescentes e eliminar aqueles com
grau de importância menor (ANDERSON, 2003).
50
O Gráfico 3 ilustra uma situação inversa. Nesse caso, é preciso adicionar novos
itens do Product Backlog, pois o gráfico indica que a Sprint será concluída antes do
esperado.
Em ambos os casos, as decisões sempre devem ser tomadas junto com o Product
Owner, nunca apenas pelo time. O time também possui um "quadro de trabalho" no
qual organiza as atividades, dos itens de Backlog da Sprint, separando-as em
basicamente quatro estados: Para fazer, Em andamento (inclui o nome do
responsável por executar a tarefa), Para Verificar e Concluído. Esse "quadro" é
muito produtivo, pois basta olhar para ele para realizar a leitura do progresso da
Sprint, inclusive nele pode-se indicar se existe algum impedimento para que as
atividades sejam executadas conforme planejado (ANDERSON, 2003). Veja
sugestão na Figura 6:
51
1.4.3.4Final da Sprint
2. PMI® e PMBOK®
As pessoas têm planejado e gerenciado projetos desde o início dos tempos. Toda
vez que uma civilização criou suas raízes houve projetos a serem gerenciados:
prédios a construir, estradas a pavimentar e leis a serem escritas. Mesmo sem as
ferramentas, técnicas e metodologias avançadas de que dispomos hoje, as pessoas
criaram linhas de tempo, alocaram materiais e recursos e avaliaram os riscos
envolvidos em seus projetos. Com o passar do tempo, as pessoas perceberam que
as técnicas para controle de custo, desenvolvimento da programação, procura e
compra de recurso e gerenciamento de riscos poderia ser aplicado a uma variedade
de projetos, seja erguendo pontes, realizando colheitas sazonais ou decidindo como
se governar. Estas idéias foram precursoras do estabelecimento de técnicas de
gerenciamento que hoje conhecemos como "Gerenciamento de Projetos Moderno”.
(PMI® -SP, 2009).
2.2 História
O Project Management Institute (PMI® ) foi fundado em 1969 por cinco voluntários. A
Comunidade da Pensilvânia emitiu as Cláusulas de Incorporação do PMI® ,
oficializando sua fundação. Durante aquele mesmo ano, o primeiro PMI® Seminars &
Symposium aconteceu em Atlanta, Geórgia EUA, com a participação de 83 pessoas.
Nos anos setenta, a primeira edição do Project Management Quarterly (PMQ) foi
publicada, e posteriormente renomeada para Project Management Journal (PMJ). O
primeiro Capítulo do PMI® foi oficializado e o primeiro Programa de Prêmios
Profissionais estabelecido. Ao final da década, o PMI® somava mais de 2.000
associados no mundo (PMI® -SP 2009).
Em 1990, o PMI® somava mais de 8.500 associados e em 1993 este número crescia
cerca de 20% ao ano. Durante os anos noventa foram formados os Grupos de
Interesses Específicos, os Colleges e o Seminars USA, uma série de programas
educacionais em Gerenciamento de Projeto. O PMI® também marcou presença na
rede mundial da Internet e publicou o "A Guide to the Project Management Body of
Knowledge (PMBOK® Guide)", um guia englobando todas as áreas do
conhecimento que regem as regras do gerenciamento de projetos. O PMI Today® ,
boletim informativo mensal do PMI® , foi impresso pela primeira vez e o Programa de
54
No inicio do século 21, o PMI® tinha mais de 50.000 associados, mais de 10.000
Profissionais de Gerenciamento de Projeto (PMP) credenciados e mais de 270.000
cópias do guia PMBOK® estavam em circulação (PMI® -SP 2009).
2.3 Hoje
• Governo
• Construção
2.4 PMBOK®
®
“O principal objetivo do Guia PMBOK é identificar o subconjunto do
Conjunto de conhecimentos em gerenciamento de projetos que é
amplamente reconhecido como boa prática. “Identificar” significa fornecer
uma visão geral, e não uma descrição completa. “Amplamente reconhecido”
significa que o conhecimento e as práticas descritas são aplicáveis à
56
2.5 Projeto
Projeto é descrito pelo guia PMBOK® (PMBOK® , 2008) como “um esforço
temporário empreendido para criar um produto, serviço ou resultado exclusivo”.
Quando diz temporário, significa que o projeto deve ter um inicio e fim definidos.
Basicamente quando os objetivos do mesmo são alcançados chegasse ao fim, logo
para isso é importante ter bem claro quais os objetivos do projeto. Quando se fala
em temporário pensa-se instintivamente em um curto espaço de tempo, porém
projetos podem levar dias, meses ou até anos, no entanto precisa ter uma data de
fim já que um projeto não é eterno. O produto gerado pelo projeto até pode ter vida
“eterna” e/ou indeterminada, mas não o projeto.
Quando diz produto, serviço ou resultado exclusivo significa que as entregas são
únicas, pois há elementos que os tornam únicos, sejam a data, as pessoas que
estão envolvidas, os recursos. O guia exemplifica através do exemplo da construção
de prédios. Cada prédio é diferente um do outro, pois possuem diferentes
proprietários, locais diferentes, construtoras diferentes. Embora haja elementos que
se repetem, ainda assim cada prédio possui sua singularidade.
O guia PMBOK® (2008) possui 42 processos onde cada um recebe Entradas que
são utilizadas por Ferramentas e/ou Técnicas que geram Saídas, conforme ilustrado
na Figura 7.
®
Figura 7 - Formato de Processo. Fonte: PMBOK , 2008, p. 19.
®
Figura 8 - Grupos de Processos. Fonte: PMBOK , 2008, p. 19.
Desenvolver
time do projeto
Gerenciar time
do projeto
61
Gerenciar
expectativas de
partes
interessadas
®
Fonte: PMBOK , 2008, p. 21-22
Ao olhar para esta tabela, é perceptível o forte foco do guia em planejamento, já que
boa parte, 20 dos processos estão concentrados no grupo de planejamento.
62
Como ele foi concebido para ser um guia genérico, ele desconsidera as
peculiaridades da execução de produtos e serviços de software. Sua implantação
prática na área de software exige um investimento importante na concepção de um
processo adequado, que venha realmente alavancar o negócio e facilitar a vida dos
envolvidos, sem requerer trabalho adicional somente para atender aos seus
requisitos.
63
Uma proposta de compatibilização pode vir de uma série quatro artigos intitulados
“Relating PMBOK® Practices to Agile Practices” escritos por Michele Sliger (2006),
ela é certificada PMP e entende a dificuldade que é percorrer entre as melhores
práticas do PMBOK® e a abordagem ágil, nos artigos, ela descreve as similaridades
entre PMBOK® e os métodos ágeis, não SCRUM especificamente, mas as
abordagens de um modo geral. Ela discute com muita propriedade a maneira de
como trabalhar com PMBOK® e Metodologias Ágeis. Segundo ela, apesar das
diferenças de filosofias entre as duas, muitas das práticas do PMBOK® são
compatíveis com as práticas ágeis. Nos artigos, Sliger (2006) trafega com muita
desenvoltura pelos cinco grupos de processos do guia PMBOK® , com uma visão
não apenas didática, mas ao que parece de quem tem experiência prática sobre o
que está descrevendo. Ela diz que para cada uma das áreas do PMBOK® , suas
práticas têm práticas relativas nas Metodologias Ágeis, porém a forma de executar é
diferente. Michele escreve que muitos autores e profissionais do PMI® declaram que
seu modelo é um guia de melhores práticas e que cada organização deve usar os
seus próprios critérios no uso destas práticas. De acordo com ela, por muito tempo o
PMBOK® tem sido associado ao modelo em cascata, quando não é verdade uma
vez que ele é perfeitamente aplicável com um modelo iterativo.
Uma terceira abordagem pode vir do artigo escrito por Alan S. Koch publicado em
2004 intitulado “Are Agile Methods Compatible with the PMBOK?”, ele faz um
mapeamento dos grupos de processos do PMBOK® segundo o desenvolvimento
iterativo, retratado na Figura 10 (KOCK, 2004):
69
®
Figura 10 – Desenvolvimento Iterativo – Grupos de processos do PMBOK . Adaptação da
apresentação de Koch (KOCH, 2004).
Na apresentação, Koch (2004) navega por cada um dos grupos de processo e faz
um paralelo entre os processos do PMBOK® e discutindo o impacto com o enfoque
iterativo. Ele elenca para cada grupo de processo a compatibilidade e
incompatibilidade entre o PMBOK® e as metodologias ágeis e o que pode ser feito.
Koch conclui dizendo que “nada nas metodologias ágeis é incompatível com os
processos do PMBOK® ” e “pode ser oportuno reforçar as metodologias ágeis com
processos do PMBOK® , porém somente onde realmente é necessário e sem
comprometer a agilidade”.
70
4. ESTUDO DE CASO
O estudo de caso que será retratado a seguir, originalmente intitulado “Agile and
PMBOK® Guide Project Management Techniques: closer than you think”, foi escrito
por Peter Bennison em 2008 e publicado no site do PMI® . Ele descreve de maneira
bem objetiva a integração dos dois frameworks em um projeto de referência
realizado para o Governo do Canadá entre 2007-2008. Como em muitos projetos de
TI, enfrentaram desafios de gerenciamento e de aceitação do cliente.
4.1.1 Introdução
O projeto apresentado neste trabalho foi parte de um grande plano para revisar e
atualizar a presença na internet de um grande departamento do governo canadense
em 2007-2008. O objetivo do programa foi analisar o website existente, entrevistar
os stakeholders e desenvolver estruturas de governança, procedimentos e
estratégias de desenvolvimento de conteúdo. O plano também desenvolveu
requisitos para o Sistema de Gerenciamento de Conteúdo de Web (WCMS),
estabeleceu e executou o projeto de implementação para o WCMS. O projeto
discutido aqui cobre a parte de implementação.
71
SCRUM não tem muito a dizer sobre planejamento e coordenação. De acordo com
Schwaber (2004, p.68), "projetos utilizando SCRUM necessitam de menos
planejamento que projetos utilizando diagramas de Gantt porque aqueles que estão
envolvidos na entrega proporcionam visibilidade do seu progresso no final de cada
sprint". Os defensores do SCRUM sentem que proporcionando apenas uma visão do
projeto e uma lista de funcionalidades com prioridade, os patrocinadores ficarão
satisfeitos desde que estejam envolvidos ativamente. De acordo com Sliger (2006), a
definição do plano do projeto é um exercício de cooperação entre o cliente e o
fornecedor, resultando em "diversas previsões e exercícios de planejamento
realizados de um modo iterativo".
De fato, o Termo de Abertura não foi aprovado antes do final das atividades de
desenvolvimento da solução. A principal razão para este atraso foi o cliente não ver
benefícios, em termos de tempo e esforço, para definir formalmente o Termo de
Abertura, satisfazendo as diretrizes exigidas pelo EMF antes do início da analise e
implementação. Isto não prejudicou o pagamento da fase inicial, mas mesmo assim
causou um impacto no projeto. Por exemplo, sem o Termo de Abertura, os papéis e
responsabilidades não foram definidos formalmente antes que o desenvolvimento já
estivesse bem adiantado. A aprovação do orçamento do projeto foi mais tênue e
negociada mês a mês.
Embora o lado financeiro acabasse sendo acertado, houve uma preocupação depois
da definição de requisitos e antes do início do desenvolvimento, que o projeto não
73
Contra este cenário, SCRUM trouxe efetivamente processo e disciplina nas áreas de
escopo e planejamento. Usando os requisitos desenvolvidos na fase inicial de
análise, a equipe de desenvolvimento realizou uma revisão com o cliente onde cada
requisito foi avaliado em termos de seu valor no negócio e no critério de aceitação
de alto nível.
Estes sete elementos foram repetidos em cinco iterações. O tempo aproximado para
cada iteração foi de 20 dias úteis. A equipe de desenvolvimento e o cliente usaram
as estimativas iniciais para propor uma distribuição das funcionalidades de tal modo
que cada iteração ficou com aproximadamente o mesmo esforço mantendo a
prioridade por valor de negócio.
bem claro que o escopo deve ser gerenciado e controlado utilizando ferramentas
centralizadas e processos de tomada de decisão (PMBOK® , 2008, p.121), mas
como foi notado por Griffiths (2004), as ferramentas que foram implementadas para
gerenciar o escopo (por exemplo: WBS, Análise de variação) são difíceis de atualizar
e rapidamente ficam obsoletas.
A equipe usou o artefato do SCRUM chamado burndowm chart para garantir que
cada iteração completou as funcionalidades exigidas no período de 20 dias. Ajustes
diários refletiam a avaliação de cada membro da equipe do tempo restante da tarefa
designada a cada um. A atribuição de tarefas foi realizada de acordo com o
interesse/especialidade. O prazo inicial designado a cada tarefa foi baseada na
estimativa inicial mais "um acréscimo" devido a alguma mudança de escopo da
funcionalidade. Diariamente, a equipe podia ver o tempo restante relativo ao
baseline. Cada iteração seguia uma curva "S" de conclusão, e por diversas vezes,
membros da equipe julgaram que não conseguiram progredir o suficiente no
começo. Os motivos para o início vagaroso foram discutidos em iterações
posteriores.
Por exemplo, foi identificado que a estimativa não considerou o número de reuniões
de revisão que ocorriam no começo de cada iteração. Como resultado, tarefas foram
explicitamente adicionadas ou modificadas para garantir que o diagrama capturasse
todas as atividades relacionadas ao projeto.
4.1.9 Conclusões
CONCLUSÃO
REFERÊNCIAS
AGILE. Agile Alliance. Disponível em: < http://www. agilealliance. org>. Acesso em:
18 maio 2009.
BOEHM, B. A View of 20th and 21st century software engineering, ICSE, 2006.
GARCIA, M. Visual Studio Team System. Team Foundation Server. São Paulo:
Brasport, 1999.
KNIBERG, H, Scrum and XP from the Trenches, How we do Scrum, nov. 2006, p.
90.
TURNER, R.; JAIN, A., Agile Meets CMMI: Culture clash or common cause,
proceedings of the Second XP Universe and First Agile Universe Conference on
Extreme Programming and Agile Methods XP/Agile Universe, p. 153-165, 2002.
WILLIAMS, L.; KESSLER, R.R. Strengthening the case for pair programming. IEEE
Software, n. 17, v. 4, p. 19-25, 2003.