xp scrum pmbook
TRANSCRIPT
UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO
FACULDADE DE TECNOLOGIA
CAMPUS REGIONAL DE RESENDE
PÓS-GRADUAÇÃO EM ENGENHARIA DE PRODUÇÃO COM ÊNFASE EM
GESTÃO DE PROJETOS
TRABALHO FINAL DE CURSO
SCRUM e XP: Aderentes ou Divergentes ao
PMBOK?
Anderson Moysés de Araújo
Diego da Silva Marcato
Resende - RJ
Novembro / 2010
2
SUMÁRIO
1. Introdução..........................................................................................................3
2. Revisão da Literatura.........................................................................................4
2.1. Guia do Conhecimento em Gerenciamento de Projetos (PMBOK)....................4
2.2. SCRUM..........................................................................................................5
2.3. Extreme Programming (XP).............................................................................6
3. Metodologia........................................................................................................7
4. Projetos de Softwares..........................................................................................7
5. Áreas Divergentes...............................................................................................9
5.1. Gerenciamento de Escopo................................................................................9
5.2. Gerenciamento do Tempo..............................................................................10
5.3. Gerenciamento de Recursos Humanos...........................................................12
5.4. Gerenciamento da Comunicação....................................................................14
Conclusão...............................................................................................................17
Referências Bibliográficas.......................................................................................18
3
1. Introdução
O processo gradativo de evolução da humanidade se deu através de vários projetos. No
início desse processo, os feitos que hoje podemos conceituar de projetos, foram realizados de
maneira totalmente empírica. No século XIX com os ensaios de Auguste Comte o método
científico e o positivismo mudaram o rumo da nossa sociedade, onde agora o empirismo
passou a ser substituído pela observação dos fatos e de práticas já utilizadas. Com o passar do
tempo os feitos agora já no século XX sendo chamados de projetos, foram se tornando cada
vez mais complexos.
Existem as mais variadas metodologias de projetos para os mais diversos segmentos
da sociedade. Este trabalho irá apresentar três “metodologias de gerenciamento de projetos”
(PMBOK, SCRUM e XP), sendo duas últimas conhecidas como metodologias ágeis, que
prezam por fatores como indivíduos e as suas interações, constante aproximação e feedback
dos clientes além de resposta imediata a mudanças. Dentre as metodologias ágeis uma é
voltada especificamente para o setor de TI (Tecnologia da Informação), desenvolvimento de
software, e a outra apresentam utilizações em outros segmentos. Após apresentá-las, este
estudo confronta seus pontos fortes e práticas utilizadas por cada uma delas além de extrair o
que há de melhor, a fim que atendam as necessidades de gestores que buscam gerenciar
projetos de forma efetiva com o mínimo de prazo possível, utilizando de princípios
apresentados inicialmente pelos autores do Agile Manifest (2001), que prezam por:
“Indivíduos e interações mais que processos e ferramentas;
Software em funcionamento mais que documentação abrangente;
Colaboração com o cliente mais que negociação de contratos;
Responder a mudanças mais que seguir um plano.” (Agile Manifest,
2001)”.
4
Devido à alta complexidade que é exigida no gerenciamento de projetos, uma grande
dose de experiência e assertividade, são fundamentais para aos gerentes de projetos. Para tal
temos uma enorme gama de metodologias a serem aplicadas em projetos. Com isso gerentes
de projeto tendem a ter dificuldades em definir qual é a melhor metodologia a ser aplicada em
seu projeto. Alguns gerentes optam pela metodologia que ele possui mais experiência, outros
optam pela metodologia de acordo com o perfil do projeto e das premissas reportadas no
contrato, alegando que muitas metodologias não podem ser aplicadas simultaneamente.
Diante da dificuldade apresentada anteriormente, o presente artigo se propõe a
observar as práticas do PMBOK, SCRUM e XP, e apontar quais são as melhores ferramentas
e métodos de cada uma das “metodologias”, a fim de refinar o processo de gerenciamento de
projetos eliminando possíveis erros decorrentes da falta de experiência
O estudo foca em projetos de Tecnologia de Informação, mais precisamente, projetos
de desenvolvimento de software. Além do uso de casos de sucesso, serão adotados artigos
científicos de relevância sobre o assunto.
2. Revisão da Literatura
2.1. Guia do Conhecimento em Gerenciamento de Projetos (PMBOK)
O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK) é uma
norma reconhecida para a profissão de gerenciamento de projetos. Um padrão, um documento
formal que descreve normas, processos e práticas estabelecidas. Assim como em outras
profissões como advocacia, medicina e contabilidade, o conhecimento contido nesse padrão
evoluiu a partir das boas práticas reconhecidas de profissionais de gerenciamento de projetos
que contribuíram para o seu desenvolvimento. (PMI, 2008)
Segundo o PMI, o objetivo do 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 à maioria dos projetos na maior parte do
tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade.
“Boa prática” significa que existe acordo geral de que a aplicação correta dessas
5
habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em
uma ampla série de projetos diferentes. Uma boa prática não significa que o
conhecimento descrito deverá ser sempre aplicado uniformemente em todos os
projetos; a equipe de gerenciamento de projetos é responsável por determinar o
que é adequado para um projeto específico” (PMI, 2008, p. 9).
O conceito de projeto do PMBOK está ligado diretamente ao esforço despendido de
caráter temporário, havendo assim um início e fim. Durante o período de vida do projeto este
conjunto de boas práticas busca controlar o bom andamento do projeto através de nove
competências (Integração, Escopo, Tempo, Custos, Qualidade, Recursos Humanos,
Comunicações, Riscos e Aquisições) de maneira que na falta de uma delas pelo menos outra
competência seja afetada.
2.2. SCRUM
O SCRUM não é uma técnica, ou processo para o desenvolvimento de um produto, e
sim uma espécie de ambiente, onde técnicas e processos podem ser empregados,
transparecendo eficiência e eficácia, na melhoria do desenvolvimento de determinado
produto. Segundo Neto (2008), sua origem ocorreu na segunda metade da década de 80, em
um artigo escrito por Takeuchi e Nonaka, que apresenta as dez melhores e mais inovadoras
práticas em empresas japonesas, denominado “The New New Product Development Game,
Harvard Business Review” (NETO, 2008).
Com nome originado em uma jogada do rúgbi, que os jogadores planejam a jogada
seguinte, assim como na condução de um projeto, onde utiliza de pequenos ciclos, mas com
um foco, que é ganhar o jogo.
Conforme Soares (2009) esclarece a respeito do SCRUM:
É um processo ágil que permite manter o foco na entrega do maior valor de
negócio, no menor tempo possível. As necessidades do negócio é que
determinam as prioridades do desenvolvimento de um sistema. As equipes se
auto-organizam para definir a melhor maneira de entregar as funcionalidades de
maior prioridade. (SOARES, A.P., 2009, p.28)
6
Chapiewski (2009) diz que as práticas do SCRUM podem ser aplicadas em qualquer
contexto onde pessoas precisem trabalhar juntas para atingir um objetivo comum. SCRUM é
recomendado para projetos de outras áreas além de software principalmente para projetos de
pesquisa e inovação;
A filosofia SCRUM, como é chamada por alguns seguidores, é sustenta sob três
importantes pilares, que prezam: a transparência, a inspeção e a adaptação. Estes sempre
devem permanecer em harmonia, cada um com sua designação para que haja a garantia de
uma eficaz utilização (SCHWABER, 2009).
Outras importantes vertentes são as Equipes/Times (flexíveis, produtivos, auto-
organizáveis, interdisciplinares e iterativos), Time-Boxes (Eventos com duração fixa),
Artefatos (itens de controle necessários para o desenvolvimento) e as Regras (elo entre os
eventos com duração fixa (Time-Boxes), a equipe e os artefatos) (SCHWABER, 2009).
Dentre os papéis da Equipe SCRUM, há dois que se diferem das tradicionais formas
de Gerenciamento de Projeto, são eles:
O ScrumMaster é responsável por garantir que o Time SCRUM esteja aderindo
aos valores do SCRUM, às práticas e às regras. O ScrumMaster ajuda o Time
SCRUM e a organização a adotarem o SCRUM. O ScrumMaster educa o Time
SCRUM treinando-o e levando-o a ser mais produtivo e a desenvolver produtos
de maior qualidade. O ScrumMaster ajuda o Time SCRUM a entender e usar
autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não
gerencia o Time SCRUM; o Time SCRUM é auto-organizável. (SCHWABER,
K., 2009, p. 6)
O outro papel é o de Product Owner, representa os interesses de todos os envolvidos,
define e prioriza as funcionalidades do produto que será desenvolvido. Toda essa estrutura do
SCRUM está sob importantes itens que não poderiam deixar de serem abordados. De acordo
com Soares (2009), os mesmos são Product Backlog (uma lista de funcionalidades desejadas
para o produto), Sprint (que se julga possível desenvolver num ciclo/iteração) e Burndown
Chart (Gráfico de Consumo, que é utilizado para acompanhar o progresso e a velocidade da
equipe de desenvolvimento).
2.3.Extreme Programming (XP)
7
A Extreme Programming (XP) é uma metodologia ágil para equipes de pequeno e
médio porte onde os requisitos de um software são vagos ou estão em constante mudança. A
sua premissa maior é o contato com o cliente através de reuniões diárias, afim de que haja um
constante ajuste da necessidade real do cliente. O cliente descreve as funcionalidades
predizendo o que será feito para os desenvolvedores. A idéia é que de posse desses
formulários a equipe de desenvolvedores possa entregar um produto que o cliente
efetivamente tenha condições de usar (BECK, 2004).
Esta metodologia de desenvolvimento de software, nascida nos Estados Unidos ao
final da década de 90. Tem por objetivo ajudar a criar sistemas de melhor qualidade, que são
produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são
alcançados através de um pequeno conjunto de valores, princípios e práticas, que diferem
substancialmente da forma tradicional de se desenvolver um software (TELES, 2005).
3. Metodologia
O processo de construção deste trabalho será baseado nas áreas de conhecimento do
PMBOK onde haja pontos com visões e forma de atuação divergente entre as três
metodologias citadas. Divergências essas que serão apresentadas dentro das áreas de
conhecimento do PMBOK, que sofrem os maiores impactos em projetos de software (Escopo,
Tempo, Recursos Humanos e Comunicações).
Haverá uma secção para que os projetos de softwares sejam apresentados, mostrando
suas principais características e diferenças em relação aos demais tipos de projetos com os da
construção civil e projeto das da área de defesa, dos quais originaram o PMBOK.
Para a obtenção das informações necessárias para a construção deste trabalho, serão
utilizados os mais diversos tipos de literatura, como livros, trabalhos acadêmicos, periódicos
especializados e até sites que apresentem informações contextualizadas e confiáveis. Através
de todo esse estudo poderá ser feito um correto cruzamento das características do PMBOK,
SCRUM e XP.
4. Projetos de Softwares
O projeto de um sistema de software tem muitas características em comum com
projetos de engenharia, do ponto de vista do mapeamento dos requisitos funcionais em
8
soluções tecnológicas (PIMENTEL, 2007). Apesar de se tratar de um serviço prestado, o dito
produto de um projeto de software possui características e processos específicos. Segundo
Falbo (2009):
No que se refere ao produto, a primeira coisa a se fazer é definir o escopo do
projeto. Para tal, é necessário fazer um levantamento de requisitos inicial. A idéia é
decompor o problema, em uma abordagem “dividir para conquistar”. Inicialmente,
o sistema deve ser decomposto em subsistemas que são, por sua vez, decompostos
em módulos. Os módulos podem, ainda, ser recursivamente decompostos em sub-
módulos ou funções, até que se tenha uma visão geral das funcionalidades a serem
tratadas no projeto. (FALBO, 2009)
Segundo Sommerville (2007), o gerenciamento eficiente de software depende de um
planejamento minucioso do progresso do projeto. Os gerentes devem prever os problemas que
podem ocorrer e preparar soluções experimentais para esses problemas. Um plano elaborado
no início de um projeto deve ser usado como guia, Esse plano inicial deve ser o melhor
possível em face de das informações disponíveis. Ele deve evoluir à medida que o projeto
progride e melhores informações se tornem disponíveis.
Em projeto de software o escopo é normalmente trabalhado de forma fechada, onde
são feitas reuniões iniciais com cliente, a fim de se definir com ele o tempo necessário a ser
utilizado no planejamento e execução do projeto. Este processo traz para a equipe de projeto
todo o risco decorrente das mudanças de escopo, aumentando as chances de mudanças de
escopo, a em casos mais extremos, paralisação do projeto. É de suma importância a
participação do cliente. Para Teles (2005), ao colocar as pessoas com as necessidades de
negócio em contato direto com os desenvolvedores facilita a compreensão dos requisitos,
além de acelerar o feedback. O usuário que participa da equipe pode dar um feedback rápido e
ajudar a definir prioridades.
Outro grande desafio no projeto de software é alocação de recursos humanos no
projeto. Você pode precisar montar sua equipe usando engenheiros relativamente
inexperientes. Isso pode trazer problemas, pois os membros da equipe não compreendem o
domínio da aplicação ou tecnologia. Entretanto, em um projeto de longo prazo, a
compreensão de conceitos e de domínio da aplicação é mais importante que o conhecimento
específico, particularmente de linguagens de programação e métodos. (SOMMERVILLE,
2007).
9
Pimentel (2009) cita que estimar e calcular a complexidade de um sistema de software
é um parâmetro importante para o desenvolvimento com qualidade. É importante ter-se uma
estimativa do tamanho do sistema para se conseguir estimar o esforço necessário na sua
construção. Para tal são usadas métricas específicas para a medição de esforço de
desenvolvimento de software. Estas métricas avaliam o tamanho e a complexidade do
produto/software desenvolvido, tendo como objetivo servir de base para estimativas de
esforço para futuros desenvolvimentos e para avaliar a produtividade das equipes. As métricas
de software são quantitativas e, por este motivo, não tem como dizer se um conjunto de
classes e objetos é o mais adequado para satisfazer um determinado conjunto de requisitos
funcionais, mas apenas dizer se um conjunto de classes é mais complexo que outro.
5. Áreas Divergentes
5.1.Gerenciamento de Escopo
O Gerenciamento do Escopo do projeto é definido com muita propriedade por Sotille
(2010):
O Gerenciamento do escopo do projeto é o processo que garante que o projeto
inclui todo o trabalho requerido, e somente o trabalho requerido, para completá-lo
com sucesso. O gerenciamento do escopo é a base para o planejamento do projeto
e para a criação de sua linha base, e deve ser conduzido de forma precisa, uma
vez que forma a base do trabalho a ser desenvolvido no projeto. (SOTILLE et. al,
2010, p. 19).
Assim como todas as áreas de conhecimentos do PMBOK trabalham baseadas em
processos, que muitas vezes são rígidos, e de difícil aceitação às mudanças, com o escopo,
não seria diferente, este processos são:
Coletar os requisitos – O processo de definição e documentação
das necessidades das partes interessadas para alcançar os objetivos
do projeto.
10
Definir o escopo – O processo de desenvolvimento de uma
descrição detalhada do projeto e do produto.
Criar o EAP1 – O processo de subdivisão das entregas e do
trabalho do projeto em componentes menores e mais facilmente
gerenciáveis.
Verificar o escopo – O processo de formalização da aceitação das
entregas terminadas do projeto.
Controlar o escopo – O processo de monitoramento do progresso
do escopo do projeto e escopo do produto e gerenciamento das
mudanças feitas na linha de base do escopo.
(PMI, 2008, p. 92).
Dentro do SCRUM, o Product Backlog (Backlog do Produto), assume o papel do
escopo, como explanado por Schwaber (2009):
O Backlog do Produto representa tudo que é necessário para desenvolver e lançar
um produto de sucesso. É uma lista de todas as características, funções,
tecnologias, melhorias e correções de defeitos que constituem as mudanças que
serão efetuadas no produto para versões futuras. Os itens do Backlog do Produto
possuem os atributos de descrição, prioridade e estimativa. A prioridade é
determinada por risco, valor e necessidade. Há diversas técnicas para dar valor a
esses atributos. (...)
Os requisitos nunca param de mudar. O Backlog do Produto é um documento
vivo. Mudanças nos requisitos de negócios, condições do mercado, tecnologia e
equipe causam mudanças no Backlog do Produto. Para minimizar o retrabalho,
apenas os itens de maior prioridade precisam ser mais detalhados.
(SCHWABER, K., 2009, p. 17).
No XP, o processo de gerenciamento do escopo, passa diretamente pela área de
comunicação, pois conforme Araújo [1] (2009), o planejamento funciona de forma iterativa,
ou seja, através de ciclos/loopings, o que garante e exige uma maior proximidade dos usuários
(solicitantes), forçando para que haja uma validação e priorização a cada entrega. Toda essa
proximidade com os usuários vem antes mesmo do desenvolvimento, inicia-se no
1 Estrutura Analítica de Projetos, inglês Work Breakdown Structure (WBS) é uma ferramenta de decomposição do trabalho do projeto em partes manejáveis
11
planejamento do projeto, pois são os solicitantes quem escreve as “estórias de usuários”, que
descreve todos os cenários com situações de utilização, na qual o projeto deverá realizar após
sua conclusão.
5.2.Gerenciamento do Tempo
O bom desenvolvimento do projeto está relacionado com um planejamento de tempo
coerente com a expertise dos recursos e a complexidade do projeto. Segundo o PMBOK
(2008), o gerenciamento de tempo do projeto inclui os processos necessários para gerenciar o
término pontual do projeto. São eles:
Definir as atividades – O processo de identificação das ações
específicas a serem realizadas para produzir as entregas de projeto.
Sequenciar as atividades – O processo de identificação e
documentação dos relacionamentos entre as atividades do projeto.
Estimar os recursos da atividade – O processo de estimativa dos
tipos e quantidades de material, pessoas, equipamentos ou
suprimentos que serão necessários para realizar cada atividade.
Estimar as durações da atividade – O processo de estimativa do
número de períodos de trabalho que serão necessários para terminar
as atividades específicas com os recursos estimados.
Desenvolver o cronograma – O processo de análise das sequências
das atividades, suas durações, recursos necessários e restrições do
cronograma visando criar o cronograma do projeto.
Controlar o cronograma – O processo de monitoramento do
andamento do projeto para atualização do seu progresso e
gerenciamento de mudanças feitas na linha de base do cronograma.
(PMI, 2008, p. 181).
Esses processos interagem entre si e com os de outras áreas de conhecimento. Podem
envolver esforços de um grupo ou de uma pessoa, com base nas necessidades de projeto. Cada
processo ocorre pelo menos uma vez em todo projeto e em uma ou mais fases do mesmo, se
dividido em fases (PMI, 2008, p. 112).
12
O processo de definição de datas e prazos no XP normalmente é definido
semanalmente através do Planning Game. Nestes encontros a equipe de desenvolvimento se
reúne com o cliente onde são priorizadas as funcionalidades a serem desenvolvidas além de
neste momento estimá-las. Segundo Leonel et. al. (2007), a cada começo de semana o escopo
do projeto é reavaliado, girando em torno de um contrato de escopo negociável, que é
diferente das formas normais de contratação de desenvolvimento de software. Ao final de
cada semana, os desenvolvedores entregam resultado desenvolvido durante a semana,
podendo assim o cliente já colocar as funcionalidades desenvolvidas em ação.
De acordo com Decarlo (2004), para a realização da estimativa do esforço requerido a
cada interação, devem ser levadas três considerações:
Incertezas que possam vir a ocorrer no projeto e que devem ser revisadas pela
equipe através o arquivamento de incertezas para acompanhamento dos riscos;
Levantar o nível de qualidade requerido para condições vencedoras. Sem essa
diretriz o projeto pode vir a ser um fracasso. Esteja certo de que as métricas
definidas por você tenham sido aceitas pela equipe.
Definir para cada entrega o esforço melhor, pior e o razoável levando em
consideração para cada recurso 6 horas/dia, já que apesar do dia ter 8 horas
úteis, parte de este tempo ser gasto em outras atividades
Araújo [2] (2009) cita que no SCRUM a equipe de projeto junto com o cliente deve
colaborar para definir o cronograma, a sua sequência e a forma de controle adequada
enquanto no PMBOK a confecção do cronograma é uma responsabilidade inerente ao gerente
de projetos. As abordagens do SCRUM e do PMBOK no tocante a confecção do são
semelhantes nas definições de atividades e processos de estimativas.
Para o SCRUM, estimativa de esforço combinada com velocidade é igual ao
orçamento e cronograma de um projeto, sendo ele desenvolvido de forma iterativa através do
sprint e gerenciado através do gráfico de burndown (SEVERINO, 2009).
5.3.Gerenciamento de Recursos Humanos
Não é possível falar de Recursos Humanos, sem fazer algumas definições prévias,
conceitos que podem parecer simples, mas algumas vezes acabam passando despercebido ao
13
longo dos estudos, definições como as de grupo e equipe por exemplo. Conforme Macêdo
(2010) explana, um grupo é uma reunião de pessoas com um ou mais objetivos comuns e que
se percebem como seus integrantes. Já uma equipe são grupos que evoluíram, ou seja, quando
este grupo em questão passa a prestar atenção à sua própria forma de operar e procura
resolver problemas que impactam suas atividades, aplicando assim habilidades e experiências.
Segundo o PMI (2008), o gerenciamento dos recursos humanos do projeto é composto
por processos (que organizam e gerenciam a equipe de projeto), equipes (que são as pessoas
com papéis e responsabilidades designadas). Ainda no PMBOK, pode-se observar os
processos:
Desenvolver o plano de recursos humanos – O processo de
identificação e documentação de funções, responsabilidades,
habilidades necessárias e relações hierárquicas do projeto, além da
criação de um plano de gerenciamento pessoal.
Mobilizar a equipe do projeto – O processo de melhoria de
confirmação da disponibilidade dos recursos humanos e obtenção da
equipe necessária para concluir as designações do projeto.
Desenvolver a equipe de projeto – O processo de melhoria de
competências, interação da equipe e ambiente global da equipe para
aprimorar o desempenho do projeto.
Gerenciar a equipe do projeto – O processo de acompanhar o
desempenho de membros da equipe, fornecer feedback, resolver
questões e gerenciar mudanças para otimiza o desempenho.
(PMI, 2008, p. 181).
Para as equipes de projeto, deve-se definir os papéis, autoridade, responsabilidades e
competências que são necessárias para a conclusão de um projeto:
Papel – A designação que descreve a parte de um projeto pela qual
uma pessoa é responsável e responde pelos resultados. (...) A
clareza do papel em relação a autoridade, responsabilidades e
limites deve ser documentada.
Autoridade – O direito de aplicar recursos do projeto, tomar
decisões e assinar aprovações.
Responsabilidade – O trabalho que se espera que um membro da
equipe do projeto execute para concluir as atividades do projeto.
14
Competência – A habilidade e a capacidade necessárias para
concluir atividades do projeto.
(PMI, 2008, p. 187).
As práticas de XP impactam diretamente no gerenciamento de recursos humanos de
um projeto e até mesmo de uma organização como um todo conforme Teles (2008) apresenta:
Projetos XP afetam as práticas de recursos humanos de uma organização, em
particular no que se refere a contratações e avaliações periódicas dos
funcionários. O fato de os programadores trabalharem em pares, por exemplo,
leva à necessidade de pessoas que não apenas tenham boas habilidades
técnicas, mas também saibam interagir socialmente com naturalidade.
Portanto, a contratação não pode se basear apenas em critérios técnicos e as
avaliações individuais se tornam complexas porque é difícil isolar o
rendimento do trabalho individual quando se trabalha em par a maior parte do
tempo. (...)
Papéis em uma equipe XP não são fixos e rígidos. O objetivo é fazer com que
cada um contribua com o melhor que tem a oferecer para que a equipe tenha
sucesso. Em princípio, papéis fixos podem ser úteis para se aprender novos
hábitos, como por exemplo, fazer com que as decisões técnicas sejam
deixadas para o pessoal técnico e decisões de negócio, com pessoas de
negócio.
(TELES, 2008).
Conforme Pacheco (2010), “o SCRUM provê, através de um método simples - uma
instância do PDCA -, uma forma de forçar a conversação na equipe e a reflexão dos atos das
pessoas”, integrando assim duas áreas, Comunicação e Recursos Humanos, que na grande
maioria dos projetos são críticas. Além disso, percebe-se sob a visão de Severino (2009), que
o gerenciamento de Recursos Humanos dentro do SCRUM, preza que as equipes sejam
multidisciplinares, ou seja, necessita que todos tenham a consciência e a liberdade para fazer
um pouco de tudo.
5.4.Gerenciamento da Comunicação
Comunicação é muito bem definida por Eischen (2002):
15
Como os sociólogos sabem, comunicação é intrinsecamente difícil, mediadas por
códigos que são sempre contextuais, normas, culturas e percepções. (...)
A construção de requisitos básicos, por exemplo, envolve um processo de
comunicação de conhecimento tácito, o que explica grande parte da dificuldade
no desenvolvimento de software. Traduzir conhecimento de um contexto para
outro, como traduzir qualquer língua, não envolve apenas gramática básica e
regras sintáticas, mas também questões de significado e intenção que são
contextuais e subjetivas. (EISCHEN 2002, apud TELES, 2005, p.60).
A partir da definição e do dimensionamento da comunicação num projeto, seja qual
for a área de desenvolvimento, do mesmo, sabe-se há diversas formas e canais para a
execução desta tarefa que não é das mais simples, mas conforme Teles (2005), projetos XP
procuram envolver ativamente seus usuários(representantes/clientes), tornando-os parte
integrante da equipe de desenvolvimento, deixando presente muita das vezes no mesmo
ambiente onde o projeto está sendo feito, possibilitando que o acesso aos especialistas seja
mais rápido, direto e consistente. Dentro do XP há diversas outras práticas que otimizam o
processo de comunicação dentro do projeto, dentre as principais práticas estão a
“Programação em Par” e o Feedback. A primeira conforme explanado por Warden et al.
(2003 apud URDANGARIN, R.G., 2008, p.31), o objetivo principal da programação em par é
disseminar o conhecimento, a experiência e as idéias. Através de dois desenvolvedores
trabalhando juntos em uma mesma atividade, em um mesmo computador, simultaneamente.
Já a segunda prática citada anteriormente é o feedback, que conforme Teles (2005), “é o
mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente e
garanta que a equipe direcione as suas atenções para aquilo que irá gerar mais valor. Mas para
que haja um bom feedback, o ideal é que a uma boa comunicação interpessoal seja realizada,
assim como explica Macêdo et al.(2010):
A comunicação interpessoal face a face é considerada a mais completa de todas,
visto que propicia uma troca instantânea, feedback em caso de eventuais dúvidas
e várias pistas que vão muito além das palavras: gestos, expressões faciais, tom
de voz etc. (MACÊDO et al., 2010, p.80)
Como é uma prática do PMBOK, o quesito gerenciamento de comunicação, é
composto por “processos necessários para assegurar que as informações sejam geradas,
16
coletadas distribuídas, armazenadas, recuperadas e organizadas de maneira oportuna e
apropriada.” (PMI, 2008).
O PMBOK (2008) apresenta os seguintes processos para o gerenciamento da
comunicação:
Identificar as partes interessadas – O processo de identificação de todas as
pessoas ou organizações que podem ser afetadas pelo projeto e de
documentação das informações relevantes relacionadas aos seus interesses,
envolvimento e impacto;
Planejar as comunicações – O processo de determinação das necessidades de
informação das partes interessadas no projeto e definição de uma abordagem
de comunicação;
Distribuir informações – O processo de colocar as informações necessárias à
disposição das partes interessadas no projeto, conforme planejado;
Gerenciar as expectativas das partes interessadas – O processo de
comunicação e interação com as partes interessadas para atender às suas
necessidades e solucionar as questões à medida que ocorrem;
Reportar o desempenho – O processo de coleta e distribuição de informações
sobre o desempenho, incluindo relatórios de andamento, medições do
progresso e previsões.
(PMI, 2008, p. 204).
Ainda no PMBOK (2008), cabe a observação, que todos esses processo explanados
anteriormente, interagem entre si, e com ou com processos de outras áreas de conhecimento.
Quando se trata de SCRUM, fica praticamente impossível não falar de comunicação,
que encontra as reuniões como principal forma de contato entre os integrantes da equipe e os
interessados no projeto. Há o mais variado tipo de reunião, mas segundo Schwaber (2009) as
principais são: Reunião de planejamento da versão para entrega, Reunião de planejamento da
SPRINT, Revisão da SPRINT, Retrospectiva da SPRINT e Reunião diária. Ordenando por
ocorrências (necessidades), primeiramente vem Reunião de planejamento da versão para
entrega:
O propósito do planejamento da versão para entrega é o de estabelecer um plano
e metas que o Time SCRUM e o resto da organização possam entender e
17
comunicar. O planejamento da versão para entrega responde às questões: “Como
podemos transformar a visão em um produto vencedor da melhor maneira
possível? Como podemos alcançar ou exceder a satisfação do cliente e o Retorno
sobre Investimento (ROI) desejado?” (SCHWABER, K., 2009, p. 9).
Em seguida, vem a Reunião de planejamento da SPRINT, que simplesmente define a
iteração (grupo de tarefas) em questão. Acompanhando as ocorrências (necessidades), vem
Revisão da SPRINT, que verifica como foi o andamento de tudo que foi planejado na reunião
de planejamento. Já a Retrospectiva da SPRINT:
A finalidade da Retrospectiva é inspecionar como correu a última Sprint em se
tratando de pessoas, das relações entre elas, dos processos e das ferramentas. A
inspeção deve identificar e priorizar os principais itens que correram bem e
aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda
melhores. Isso inclui a composição do time, preparativos para reuniões,
ferramentas, definição de “pronto”, métodos de comunicação e processos para
transformar itens do Backlog do Produto em alguma coisa “pronta”. No final da
Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria
factíveis que ele implementará na próxima Sprint. Essas mudanças se tornam a
adaptação para a inspeção empírica. (SCHWABER, K., 2009, p. 14).
Por fim a Reunião diária:
Cada time se encontra diariamente para uma reunião de 15 minutos chamada
Reunião Diária. Essa reunião é sempre feita no mesmo horário e no mesmo local
durante as Sprints. Durante a reunião, cada membro explica:
O que ele realizou desde a última reunião diária;
O que ele vai fazer antes da próxima reunião diária; e
Quais obstáculos estão em seu caminho.
(SCHWABER, K., 2009, p. 15).
Conclusão
Concluímos que as metodologias ágeis SCRUM e XP muito aderem e pouco divergem
em relação ao PMBOK.
18
Nas áreas de conhecimento do PMBOK como Custos, Qualidade e Risco na realidade
têm por objetivo quantificar e qualificar os pontos a serem desenvolvidos pelo gerente de
projeto. A proposta do desenvolvimento ágil está diretamente ligada à proposta de ganho na
fase de execução do projeto, integrando várias áreas de conhecimento através de um processo
de comunicação conciso e eficaz envolvendo todos os interessados no projeto ao nível de
recurso. Desta maneira, envolvendo o usuário, reduz-se o risco ligado à dificuldade de
entendimento por parte da contratação de um projeto de software, decorrente do alto seu nível
de abstração.
Diferente do PMBOK, as metodologias ágeis focam no planejamento iterativo, pois
não estão focadas no quesito prazo (este passa ser uma conseqüência já que o nível de
retrabalho do projeto diminui), e sim na aderência do usuário em relação ao escopo definido e
qualidade esperada.
Desenvolver softwares em que o usuário não conhece bem o escopo é algo muito
complexo. Para tal a mescla entre o PMBOK, SCRUM e o XP facilita muito o processo de
gerenciamento do ciclo de vida do software por parte do gerente de projeto, já que ele tem um
processo de desenvolvimento baseado na efetividade da comunicação entre os envolvidos, e
por trás disso existindo o arcabouço dos processos do PMBOK, como o de aquisições e custos
para medir os ruídos que inviabilizariam o projeto, garantindo assim que as metodologias
ágeis atuem de forma complementar ao PMBOK. Assegurando que de forma implícita ao
projeto as demais áreas de conhecimento (Custo, Qualidade, Riscos, Integração e Aquisições)
sejam aplicadas.
19
Referências Bibliográficas
Agile Manifest. Manifesto para Desenvolvimento Ágil de Software. [S.l.], 2001.
Disponível em: <http://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 18 nov.
2010.
CHAPIEWSKI, G. Como estamos indo com a adoção de SCRUM na Globo.com. [S.l.],
2008. Disponível em: <http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de
scrum-na-globocom>. Acesso em: 13 nov. 2010.
TELES, V. Extreme Programming, XP: metodologia desenvolvimento ágil. [S.l.], 2008.
Disponível em: <http://www.improveit.com.br/xp>. Acesso em 28 out. 2010.
PACHECO, D. Scrum e a gestão de pessoas. [S.l.], 2009. Disponível em:
<http://imasters.com.br/artigo/12620/agile/scrum_e_a_gestao_de_pessoas>. Acesso em 25 nov. 2010.
PMI - PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento do
Gerenciamento de Projetos (Guia PMBOK), 4. ed. 2008. 337 p.
BECK, K. Programação extrema (XP) explicada: acolha as mudanças. 1. ed. Porto
Alegre: Bookman, 2004. 182 p.
SOMMERVILLE, I. Engenharia de Software. Xx. ed. São Paulo: Pearson, 2007. xx p.
SOTILLE et al., Gerenciamento do escopo em projetos. 2. ed. Rio de Janeiro: Editora FGV,
2010. xx p.
MACÊDO et al. Aspectos comportamentais de gestão de pessoas. 9. ed. Rio de Janeiro:
Editora FGV, 2010. xx p.
WARDEN, S. Extreme Programming Pocket Guide. 1 ed. Sebastopol:
O’Reilly, 2003. 83p.
20
EISCHEN, K. Software development: an outsider's view. IEEE. Computer, v. 35, n. 5, 2002. p.
36-44.
ARAUJO [2], L. Estudo Comparativo da Compatibilidade entre as melhores práticas do
PMI e SCRUM. 2009. xx f. Trabalho de Conclusão de Curso (Graduação em xxxxxx),
Faculdade de Informática e Administração Paulista, São Paulo, 2009.
SEVERINO, L. O poder do PMBOK no gerenciamento de um projeto SCRUM. 2009. xx
f. Trabalho de Conclusão de Curso (Graduação em xxxxxxxxxxx), Universidade Estadual de
Londrina, Londrina, 2009.
SOARES, A. Processo Ágil de Desenvolvimento de Software para Equipes Separadas
Remotamente que Utilizam Ferramentas de Software Livre como Suporte ao
Desenvolvimento. 2009. xx f. Trabalho de Conclusão de Curso (Graduação em Engenharia
da Computação), Universidade Federal de Pernambuco, Recife, 2009.
ARAÚJO [1], R. Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva
Ágil. 2009. xx f. Estudo Bibliográfico (Bacharelado em Sistemas de Informação), São Leopoldo, 2009.
TELES, V. Um Estudo de Caso da Adoção das Práticas e Valores do Extreme
Programming. 2005. 179 f. Dissertação (Mestrado em Informática) – Universidade Federal
do Rio de Janeiro, Rio de Janeiro, 2005.
URDANGARIN, R. Uma Investigação sobre o Uso de Práticas Extreme Programming no
Desenvolvimento Global de Software. 2008. 118 f. Dissertação (Mestrado em Ciência da Computação) –
Pontifíca Universidade Católica do Rio Grande do Sul, 2008
PIMENTEL, A. Uma Abordagem para o projeto de software orientado a objetos baseado
na teoria de projeto axiomático. 2007. 189 f. Tese (Doutorado em Ciências) - Universidade
Tecnológica Federal do Paraná, Paraná, 2007.
FALBO, R. Engenharia de Software. 2005. 99 f. Notas de Aula (Disciplina de Engenharia
de Software) – Universidade Federal do Espírito Santo, Espírito Santo 2005.
SCHWABER, K., GUIA DO SCRUM. 2009. (Tradução)
21
NETO, E.I., Scrumming: Ferramenta Educacional para Ensino de Práticas do SCRUM.,
2008.
LEONEL, L.S., et. al., Gestão da Produtividade: Extreme Programming, São Paulo -
2007.
DECARLO, D. Extreme Project Management. San Francisco, California: Jossey-Bass,
2004.
22