Uma análise sobre gestão de pessoas baseada nos métodos ágeis

C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO
RECIFE
LUIZ SANCHES
UMA ANÁLISE SOBRE GESTÃO DE PESSOAS BASEADA
NOS MÉTODOS ÁGEIS
Recife
2012

LUIZ SANCHES
UMA ANÁLISE SOBRE GESTÃO DE PESSOAS
BASEADA NOS MÉTODOS ÁGEIS
Artigo apresentado ao programa de
Especialização em Engenharia de Software do
Centro de Estudos e Sistemas Educacionais do
Recife – C.E.S.A.R, como requisito para a
obtenção do título de Especialista em
Engenharia de Software com ênfase em Gestão
Ágil de Projetos.
Orientação: Prof. Felipe Furtado
Coorientação: Renato Willi
Recife
2012

Uma análise sobre gestão de pessoas baseada nos métodos
ágeis
Luiz Sanches
C.E.S.A.R – Centro de Estudos e Sistemas Avançados do Recife
luizsanches@opmbx.org
Resumo. Gerir o capital humano continua sendo o desafio de pequenas e
grandes corporações desde a era industrial, que formulou a base da gestão
tradicional de pessoas e que continua sendo aplicada pelos departamentos de
recursos humanos. Particularmente em empresas de tecnologia, onde a
essência do trabalho é o conhecimento e não a força ou repetição, métodos
ágeis se voltam para o ser humano no objetivo de encontrar maneiras
sustentáveis, envolvendo colaboradores e clientes, para entregar produtos de
qualidade e manter as equipes saudáveis. Nesse contexto, será apresentado
um estudo sobre métodos tradicionais e ágeis com foco em pessoas e um
estudo de caso onde Scrum e XP foram aplicados na gestão de pessoas.
1. Introdução
As pessoas são o maior patrimônio de uma organização de software e representam o seu
capital intelectual. É responsabilidade dos gerentes de software garantir que a
organização obtenha o melhor retorno sobre o investimento em pessoas. O
gerenciamento inadequado de pessoas é uma das mais significativas contribuições para a
falha do projeto (MELNIKOFF et al., 2007).
A gestão de pessoas procura obter o melhor do funcionário enquanto membro da
empresa. O capítulo 9 do PMBOK, que trata sobre gerenciamento dos recursos humanos
do projeto, e o P-CMM (Modelo de Maturidade de Capacitação de Pessoal) do SEI
(Software Engineering Institute) formam uma base sólida de conhecimento para guiar
equipes de desenvolvimento de software quanto à gestão de pessoas.
Métodos ágeis como Scrum e XP, tomam como base a colaboração entre as
pessoas envolvidas no processo para que possam entregar produtos com qualidade e
constância. O uso dos métodos ágeis em equipes de desenvolvimento de software está se
difundindo bastante no meio acadêmico e corporativo e pode ajudar, consideravelmente,
as empresas da área de tecnologia a solucionarem seus problemas relacionados à gestão
de pessoas.
1.1 Objetivos
Este trabalho apresenta uma revisão da literatura sobre gestão de pessoas em equipes de
desenvolvimento de software, bem como, um estudo dos métodos ágeis Scrum e XP
com foco na gestão de pessoas. Ao final, tenta-se evidenciar isto tudo por meio de um
estudo de caso concreto.
O objetivo deste trabalho é mostrar que, a partir dos valores, princípios e práticas
presentes nos métodos ágeis, é possível fazer-se uma gestão adequada de recursos
humanos alinhada às recomendações presentes no PMBOK e P-CMM.

1.2 Justificativa
Os modelos de referência para gestão de pessoas, como o presente no PMBOK e o P-
CMM, muitas vezes são implementados à risca, sem levar-se em consideração aspectos
práticos e do dia a dia da cultura das organizações.
Com isso, colocar-se em prática uma adoção descuidada desses modelos muitas
vezes resulta em sobrecarga e inclusão de burocracias no processo de software. Além
disso, uma cultura corporativa voltada para valorização das pessoas também é
fundamental para uma gestão de pessoas bem sucedida.
Uma forma de ilustrar isso é o fato de muitas empresas que adotam os valores e
princípios ágeis deixarem de se referirem aos membros de suas equipes como mais um
tipo de recurso da empresa como outro qualquer, e tratá-los apenas como pessoas.
A motivação deste trabalho vem da curiosidade de se identificar que impactos a
forma de ver as coisas sob a ótica das metodologias tem sobre aspectos como a gestão
de pessoas.
1.3 Estrutura do Artigo
Este artigo está estruturado como se segue. O capítulo 2 abrange o que é a gestão de
pessoas. O capítulo 3 apresenta e conceitua métodos ágeis. Já o capítulo 4 fala sobre
aprimoramento e desenvolvimento de pessoas. Um estudo de caso mostrando práticas de
gestão de pessoas no contexto de métodos ágeis é apresentado no capítulo 5. E por fim,
no capítulo 6 estão as conclusões deste trabalho.
2. Gestão de pessoas em projetos de software
A maioria dos problemas na área de tecnologia da informação não é de natureza
tecnológica, e sim de natureza sociológica. Ter a última tecnologia ou bugs1
em sua
linguagem de programação não são páreos para problemas de comunicação, falta de
motivação ou desentendimentos (DEMARCO; LISTER, 1999).
FRANÇA (2009) relata que pesquisas recentes demonstram que os profissionais
de engenharia de software estão entre os profissionais mais estressados e desmotivados
e, que os modelos de motivação existentes são excessivamente teóricos e com pouca
aplicabilidade prática, dificultando assim a interpretação e implementação destes modelos
por gerentes de projetos de software.
O gerenciamento eficiente está, portanto, relacionado ao gerenciamento de
pessoas em uma organização. O gerenciamento inadequado de pessoas é uma das mais
significativas contribuições para a falha do projeto (MELNIKOFF et al., 2007).
Segundo MELNIKOFF et al. (2007) existem quatro fatores críticos no
gerenciamento de pessoal:
– consistência, em que as pessoas de uma equipe de projeto devem ser tratadas de
maneira uniforme;
– respeito, que conhece que pessoas diferentes têm habilidades diferentes e os
gerentes devem respeitar essas diferenças;
– inclusão, no qual as pessoas contribuem efetivamente quando sentem que os
outros ouvem e levam em conta suas propostas;
1 É um erro no funcionamento comum de um software ou hardware.

– e honestidade, que prega que, na posição de gerente, deve-se sempre ser honesto
sobre o que vai ou não bem na equipe.
Veremos, a seguir, os modelos de gestão de pessoas baseados no Guia PMBOK e
P-CMM.
2.1 O Guia PMBOK
O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK), criado e
gerido pelo Instituto de Gerenciamento de Projeto (Project Management Institute -
PMI), é utilizado como padrão para gerenciar a maioria dos projetos na maior parte das
vezes em vários tipos de setores da indústria. Ele descreve os processos, ferramentas e
técnicas de gerenciamento de projetos usados até a obtenção de um resultado bem-
sucedido.
Importante frisar que ele, como é uma referência básica, não é abrangente nem
completo. Ele é mais um guia que uma metodologia. É possível usar metodologias e
ferramentas distintas para implementar a sua estrutura.
2.1.1 Gerenciamento de projetos
Segundo o PMI (2008), um projeto é um esforço temporário empreendido para criar um
produto, serviço ou resultado exclusivo. Um projeto pode envolver uma única pessoa,
uma única ou múltiplas unidades organizacionais e, devido à natureza exclusiva dos
projetos, pode haver incertezas quanto aos produtos, serviços ou resultados criados por
ele (PMI, 2008).
Ainda de acordo com o PMI (2008), o gerenciamento de projetos é a aplicação
de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de
atender aos seus requisitos e para gerenciar um projeto deve-se: identificar os requisitos;
adaptar-se às diferentes necessidades, preocupações e expectativas das partes
interessadas à medida que o projeto é planejado e realizado e, balancear as restrições
conflitantes do projeto (escopo, qualidade, cronograma, orçamento, recursos e risco).
O PMI (2008) referencia o gerente de projetos como a pessoa designada pela
organização executora para atingir os objetivos do projeto e garantir que o plano do
mesmo esteja alinhado com o plano do programa central. Compreender e aplicar o
conhecimento, as ferramentas e as técnicas reconhecidas como boas práticas não é
suficiente para um gerenciamento eficaz (PMI, 2008).
Além das habilidades específicas da área e das competências de gerenciamento
geral exigidas, o gerenciamento de projetos eficaz requer que o gerente tenha as
seguintes características (PMI, 2008):
– o conhecimento sobre gerenciamento de projetos;
– desempenhe com eficiência seus conhecimentos em gerenciamento de projetos;
– no lado pessoal, seja efetivo em suas atitudes e tenha capacidade para orientar sua
equipe na obtenção de seus objetivos mantendo o equilíbrio das restrições do
projeto.

2.1.2 Fatores ambientais da empresa
São os fatores internos e externos que influenciam o sucesso do projeto, servindo como
aumento ou restrição das opções de gerenciamento de projetos e influenciam positiva ou
negativamente no resultado do mesmo (PMI, 2008).
Alguns dos fatores ambientais que o PMI (2008) elenca são: cultura, estrutura e
processos organizacionais; normas governamentais ou do setor; infraestrutura; recursos
humanos existentes; administração de pessoal; sistemas de autorização do trabalho da
empresa; canais de comunicação estabelecidos da organização; sistemas de informações
do gerenciamento de projetos.
2.1.3 Gerenciamento dos recursos humanos do projeto
Segundo o PMI (2008), o gerenciamento dos recursos humanos do projeto, que é
coberto no capítulo 9 do Guia PMBOK, inclui os processos que organizam e gerenciam
a equipe do projeto.
A equipe do projeto consiste nas pessoas com papéis e responsabilidades
designadas para a conclusão do projeto. O envolvimento e a participação dos membros
da equipe desde o início agrega seus conhecimentos durante o processo de planejamento
e fortalece o compromisso com o projeto (PMI, 2008).
De acordo com o PMI (2008), o gerenciamento dos recursos humanos do
projeto envolve os processos de:
– desenvolvimento do plano de recursos humanos, onde é identificado e
documentado as funções, responsabilidades, habilidades necessárias e relações
hierárquicas do projeto, além da criação de um plano de gerenciamento do
pessoal;
– mobilização da equipe do projeto, onde ocorre a confirmação da
disponibilidade dos recursos humanos e obtenção da equipe necessária para
concluir as designações do projeto;
– desenvolvimento da equipe do projeto, onde ocorre a melhoria de
competências, interação da equipe e ambiente global da equipe para aprimorar o
desempenho do projeto;
– gerenciamento da equipe do projeto, onde acompanha-se o desempenho de
membros da equipe, fornecendo feedback, resolvendo questões e gerenciando
mudanças para otimizar o desempenho do projeto.
Para que essas tarefas sejam realizadas é necessário a criação da equipe de
gerenciamento de projetos. Para projetos menores, as responsabilidades de
gerenciamento do projeto podem ser compartilhadas por toda a equipe ou administradas
exclusivamente pelo gerente de projetos (PMI, 2008).
O PMI (2008) acrescenta que para gerenciar e liderar a equipe do projeto deve-
se também:
– conhecer, e influenciar quando possível, os fatores de recursos humanos que
podem impactar o projeto, como: o ambiente da equipe, localizações geográficas
dos membros da equipe, comunicações entre as partes interessadas, questões
políticas internas e externas, questões culturais, singularidade organizacional e
outros fatores de pessoal que podem alterar o desempenho do projeto;

– estar ciente e assumir o compromisso de garantir que todos os membros da
equipe tenham um comportamento ético.
2.2 O modelo P-CMM
Na busca de melhorias na área de engenharia de software, o SEI (Software Engineering
Institute) vem desenvolvendo o Modelo de Maturidade de Capacitação (Capability
Maturity Model – CMM) que agrega disciplinas e práticas que contribuem diretamente
para o desempenho dos negócios de uma organização, visando a alta qualidade de seus
produtos e serviços (CURTIS et al., 2001).
O Modelo de Maturidade de Capacitação de Pessoal (People Capability
Maturity Model – P-CMM) foi concebido com o propósito de aumentar a capacidade da
força de trabalho de uma organização (CURTIS et al., 2001).
2.2.1 Níveis de maturidade
Segundo CURTIS et al. (2001), o P-CMM é projetado para que as mudanças de
comportamento de uma organização possam apoiar as melhorias nas práticas da força de
trabalho da mesma, fornecendo um roteiro para transformar uma organização com
aprimoramento constante de suas práticas profissionais.
O P-CMM é composto por cinco níveis de maturidade, sendo que em cada um
deles, um novo sistema de práticas é sobreposto sobre os implementados em níveis
anteriores, provocando uma evolução das práticas e processos da força de trabalho. Em
um ambiente como esse, os indivíduos obtêm a oportunidade de desenvolver sua carreira
profissional motivando-os a alinhar seu desempenho com os objetivos da organização
(CURTIS et al., 2001).
Os cinco níveis de maturidade do P-CMM são elencados, brevemente, a seguir
(JOSKO, 2004):
– nível 1 (inicial): Devido a apresentarem gestores despreparados, a organização
trata de forma inconsistente a gestão de pessoas enfrentando sérios problemas;
– nível 2 (gerenciado): A organização executa, com disciplina, práticas básicas de
gestão de pessoas. Mas a prioridade desse nível é que os gestores sejam
preparados para executarem as atividades de gestão de pessoas em seus
respectivos setores;
– nível 3 (definido): Com o intuito de alinhar a força de trabalho aos seus
objetivos de negócio a organização desenvolve uma infraestrutura para servir de
apoio aos indivíduos;
– nível 4 (previsível): Através da infraestrutura de desenvolvimento de
competências, a organização quantifica e gerencia a capacidade de sua força de
trabalhado e de seus processos;
– nível 5 (em otimização): Os grupos e indivíduos se dedicam na melhoria
contínua de seus métodos de trabalho fazendo com que toda a organização se
beneficie e mantenha uma cultura de produtos e serviços de excelência.
2.2.2 Áreas de processo
Segundo CURTIS et al. (2001), com exceção do nível inicial, cada nível de maturidade
do P-CMM agrupa de três a sete áreas de processo que identificam um conjunto de

práticas relacionadas que devem ser executadas em conjunto para aumentar a capacidade
da força de trabalho para que possam alcançar seus objetivos. Acada nível de maturidade
as áreas de processo criam um sistema inter-relacionado que transformam a capacidade
da organização para o gerenciamento de sua força de trabalho (CURTIS et al., 2001).
A Figura 1 apresenta as áreas de processo dentro de cada nível de maturidade do
P-CMM:
O Guia PMBOK e o modelo P-CMM são bastante difundidos em empresas de
grande porte. Eles fornecem aos gestores ferramentas e técnicas que os ajudam na
coordenação de equipes. Ultimamente, os chamados métodos ágeis de desenvolvimento
de software vêm sendo bastante discutidos por darem mais de flexibilidade na gestão e
execução de projetos e, que ao mesmo tempo podem se adequar em algumas etapas de
modelos conhecidos como tradicionais. Serão vistos a seguir, os métodos Scrum e XP.
3. Métodos ágeis
Em fevereiro de 2001, dezessete renomados engenheiros de software se reuniram em
Utah, numa estação de esqui, para tentar consolidar seus conhecimentos e experiências
em uma nova metodologia que fosse na contramão da engenharia de software tradicional.
No final do encontro, eles chegaram à conclusão de que a melhor forma de estruturar
suas ideias seria na criação de um manifesto com seus valores e princípios (BECK et al.,
2001).
O documento gerado nesse encontro, o Manifesto para Desenvolvimento Ágil
de Software, contradiz as metodologias ditas tradicionais valorizando: os indivíduos e
interações entre eles do que focar no uso cego de processos e ferramentas que na
maioria das vezes os engessam; o software em funcionamento sendo mais importante
que a documentação do sistema em si; a colaboração com o cliente em virtude da falsa
segurança baseada em rígidos contratos; e, a resposta a mudanças caso o projeto não
saia como planejado (BECK et al., 2001).
Dos doze princípios do manifesto, nota-se que os seguintes estão relacionados a
gestão de pessoas:
– as pessoas de negócio e desenvolvimento devem trabalhar juntas;
– construa projetos em torno de indivíduos motivados;
Figura 1: Áreas de processo do P-CMM (CURTIS et al.,
2001, adaptado)

– transmissão de informação através de conversa face a face;
– incentivo de que a equipe obtenha a auto-organização e que a mesma reflita e
melhore seus processos na busca da eficiência.
Entre várias metodologias ágeis que surgiram antes mesmo do manifesto, se
destacam Scrum e XP que serão explanadas a seguir.
3.1 O Framework Scrum
No artigo chamado The New New Product Development Game, NONAKA e
TAKEUCHI (1986) discorrem sobre mudanças nas regras do jogo no desenvolvimento
de novos produtos tratando o trabalho de uma forma análoga a um time de rugby onde a
equipe deve ser multidisciplinar e auto-organizada trabalhando junta do início ao fim, em
constante interação, para que um processo de desenvolvimento de produto possa emergir
daí.
Em 1995, Ken Schwaber apresentou uma abordagem de desenvolvimento de
produtos chamado Scrum, que é uma jogada realizada após alguma penalização ou
jogada irregular, baseado no trabalho de Nonaka e Takeuchi (SCHWABER, 1995). Os
oito jogadores do time se agrupam para enfrentar o adversário juntos e recuperar a bola
do meio do túnel criado pela formação, que é jogada por outro jogador de fora do
agrupamento (SCHWABER, 1995).
O framework Scrum pode empregar vários processos ou técnicas com o objetivo
de que as pessoas tratem e resolvam problemas complexos e adaptativos de forma
produtiva e criativa entregando produtos com o mais alto valor possível (SCHWABER,
1995).
Segundo SCHWABER e SUTHERLAND (2011), ele tem seus fundamentos nas
teorias empíricas de controle de processo onde o conhecimento é obtido da experiência e
de tomada de decisões fundamentadas no que é conhecido, sendo apoiado pelos pilares
transparência, inspeção e adaptação. Para aprimorar a previsibilidade e controlar riscos,
emprega uma abordagem iterativa e incremental (SCHWABER; SUTHERLAND, 2011).
A Figura 2 apresenta o processo idealizado por Schwaber em 1995:
O Scrum promove a integração do time entre seus eventos e artefatos, que serão
vistos a seguir.
Figura 2: A Metodologia Scrum (SCHWABER, 1995, adaptado)

3.1.1 O Time do Scrum
Se acordo com SCHWABER (1995), os Times Scrum são auto-organizáveis e
multifuncionais, compostos pelo Product Owner que conhece o negócio e prioriza os
itens de maior valor de retorno de investimento; a Equipe de Desenvolvimento que é
encarregada de entregar um produto funcional a cada iteração; o Scrum Master que
serve o time para que possam entregar o produto. Com essa formação e características,
eles optam pela melhor maneira de realizarem seu trabalho (SCHWABER, 1995).
3.1.2 Os eventos do Scrum
Scrum utiliza o conceito de time-box, onde todo evento tem uma duração máxima,
garantindo que o planejamento seja utilizando em uma quantidade adequada de tempo
sem causar perdas no processo (SCHWABER; SUTHERLAND, 2011).
SCHWABER e SUTHERLAND (2011) relatam que para criar uma rotina e
reduzir a necessidade de reuniões não definidas, são utilizados eventos prescritivos que
utilizam a inspeção e adaptação para permitir uma transparência minuciosa. São
apresentados a seguir:
– Sprint: é uma iteração com time-box de um mês ou menos que deve entregar um
produto potencialmente utilizável.
– Reunião de Planejamento da Sprint: no time-box de oito horas, a Equipe de
Desenvolvimento se reúne para decidir o que será desenvolvido durante a Sprint.
– Reunião Diária: é um evento com time-box de quinze minutos onde o Scrum
Master se reúne com a Equipe de Desenvolvimento para atualizar o status do
projeto fazendo três perguntas para cada um dos membros: O que foi feito no dia
anterior? O que será feito hoje? Existe algum problema a ser resolvido? No
Scrum, a inspeção do processo é diária.
– Revisão da Sprint: no final de cada Sprint o time e partes interessadas se
reúnem, em um time-box de quatro horas, para apresentar o resultado da iteração
e, se necessário, adaptar o Backlog do produto. Ela é bastante útil para colher
feedback, promover a motivação e colaboração no time.
– Retrospectiva da Sprint: é uma reunião realizada, em três horas, para inspeção
do próprio time com o objetivo da realização de melhorias para a próxima Sprint.
3.1.3 Os artefatos do Scrum
Os artefatos do Scrum foram criados com o objetivo de fornecer transparência na
entrega das funcionalidades e oferecer a oportunidade do Time Scrum de inspecionar e
adaptar o processo (SCHWABER; SUTHERLAND, 2011). São apresentados a seguir:
– Backlog do Produto: é uma lista de requisitos ordenados, normalmente, por
valor de retorno de investimento, ou seja, os itens mais importantes para o
negócio serão prioritariamente estimados e construídos pela Equipe de
Desenvolvimento. Ele é criado sobre a responsabilidade do Product Owner e de
forma dinâmica, pois os requisitos do negócio podem mudar a qualquer
momento.
– Backlog da Sprint: são os itens, em aberto, priorizados pelo Product Owner que
farão parte da Sprint corrente. Desses itens, a Equipe de Desenvolvimento extraí
as tarefas, estimando seu tempo, para serem construídas durante a Sprint.

– Definição de “Pronto”: é como o Time Scrum define de qual forma o produto
deve estar pronto ao final de cada Sprint.
O Scrum realiza o trabalho na camada de gestão de projetos, mas para times de
desenvolvimento de software é necessário uma metodologia que norteie seus membros
com relação a engenharia de software, em nosso caso veremos a Programação Extrema a
seguir.
3.2 Programação Extrema
Segundo FOWLER (2005), a XP (eXtreme Programming - XP) nasceu das boas práticas
de engenharia de software exercidas pela comunidade da linguagem de programação
Smalltalk no final da década de 1980, sendo que Kent Beck e Ward Cunningham
passaram a utilizá-las em seus projetos, adaptando-as para que se tornassem mais
orientadas a pessoas.
No início de 1996, Kent Beck foi chamado para reestruturar o projeto da folha
de pagamento da empresa Chrysler, optando por jogar tudo o que tinha sido construído
fora e dado uma semana de folga para a equipe. Nesse ambiente, foram utilizadas em um
grande projeto as práticas que sustentam a XP (BECK, 2004).
BECK (2004) descreve a Programação Extrema como uma disciplina de
desenvolvimento de software em face a requisitos vagos que se modificam rapidamente.
As ideias e práticas de XP são tão velhas quanto a programação, o que torna XP
inovadora é: colocar todas as práticas juntas, sob um só teto; garantir que elas sejam
praticadas a fundo; garantir que as práticas apoiem umas às outras ao máximo (BECK,
2004).
Segundo BECK (2004), a XP promete aos programadores que eles possam
tomar as decisões técnicas do projeto trabalhando no que realmente importa, dando o
melhor de si para que o software seja desenvolvido da melhor forma possível. E aos
clientes e gerentes, que no intervalo de poucas semanas, perceberão suas metas
progredirem com a possibilidade de mudança nas regras do negócio sem causar impactos
negativos na equipe e nem nos custos do projeto (BECK, 2004).
A XP é baseada em valores, práticas e as pessoas possuem papéis, que serão
vistos a seguir.
3.2.1 Os valores da XP
Segundo BECK (2004), as sociedades aprenderam a lidar com o problema no qual as
metas individuais de curto prazo frequentemente entram em conflito com metas sociais
de longo prazo, para isso, acabaram criando um grupo de valores a serem
compartilhados.
XP segue o preceito de que para se obter sucesso em equipe, precisamos de
valores que consistam em aspectos tanto humanos quanto comerciais como:
comunicação face a face; simplicidade para resolver apenas os problemas de hoje;
feedback rápidos para obter soluções rápidas; coragem para assumir riscos (BECK,
2004).

3.2.2 Os papéis da XP
Os papéis da XP foram pensados analogamente a um time esportivo que apresenta
indivíduos com habilidades distintas, mas que juntas e coordenadas por um treinador
formam uma equipe coesa e eficiente (BECK, 2004).
De acordo com BECK (2004), os papéis da XP são: programador que
desenvolve em par, guiado a testes projetando o sistema; cliente que toma as decisões de
negócio; testador que ajuda na escrita dos testes funcionais; rastreador que cuida da
coleta de dados referentes desempenho do time; treinador que ajuda o time a não desviar
a atenção.
3.2.3 As práticas da XP
De acordo com BECK (2004), o uso de práticas simples, muitas delas bem antigas,
combinadas sistematicamente e seguidas pela equipe com disciplina podem trazer efeitos
positivos e sucesso para todos envolvidos no projeto.
Entre as práticas da XP, as que enfocam as pessoas são: jogo do planejamento
que força o diálogo entre as áreas de negócio e técnica; programação em pares onde
ocorre o compartilhamento de conhecimento do sistema; propriedade coletiva que
incentiva todos a estudar e melhorar o sistema; semana de quarenta horas que tenta
evitar horas extras de trabalho; cliente presente onde podem ser esclarecidas dúvidas de
negócios com a equipe técnica o mais rápido possível (BECK, 2004).
Para BECK (2004), cada prática por si só não se sustenta, a Figura 3 mostra que
uma prática reforça a outra criando uma sinergia entre elas. Para mais detalhes sobre as
prática da XP, consultar (BECK, 2004).
Metodologias ágeis estão bastante difundidas hoje em dia contribuindo
significativamente para o desenvolvimento de software e, principalmente, das pessoas
envolvidas no processo, conforme tratado no próximo capítulo.
4. Desenvolvimento de pessoas
Um estudo realizado por TURNER e BOEHM (2003) comparando métodos ágeis e
orientados a plano (ditos tradicionais) consideram cinco fatores pessoais como críticos
para o sucesso de um projeto: pessoal onde nos métodos ágeis o cliente faz parte da
equipe; cultura indicando que métodos ágeis criam um ambiente confortável; valores
Figura 3: As práticas reforçam umas as outras (BECK, 2004)

onde métodos ágeis priorizam o desenvolvimento de requisitos que possuem mais valor
para o cliente; comunicação onde métodos ágeis utilizam comunicação direta entre
equipe e cliente; gestão da expectativa onde, em métodos ágeis, todos guiam o
desenvolvimento do produto gerindo as mudanças que possam vir durante o percurso.
BROOKS (2009) argumenta que a construção de grandes sistemas de informação
é análoga à luta que animais pré-históricos realizavam, em vão, nos poços de alcatrão
(piche): quanto mais se moviam mais afundavam. Brooks comenta que precisamos
compreender os problemas que levam projetos a chegarem nesse ponto para então poder
solucioná-los.
TURNER e BOEHM (2003) e BROOKS (2009) enfatizam que relacionar
homens e meses em projetos onde há indivíduos que se comuniquem entre si tornar-se
perigoso e enganoso. Em qualquer grupo de pessoas que precisem se comunicar, a
complexidade da comunicação pode ser dada por n(n-1)/2, onde n é o número de
pessoas. Assim, vê-se que em atividades onde a intercomunicação é intensa, por
exemplo, a complexidade da comunicação cresce exponencialmente em relação à
quantidade de interlocutores. Por exemplo, um projeto com cinco pessoas vai requerer
dez vezes mais comunicação entre pares do que um projeto com apenas duas pessoas.
Este fato é sintetizado na famosa lei de Brooks: “A adição de recursos humanos a um
projeto de software atrasado irá atrasá-lo ainda mais” (BROOKS, 2009, p. 24).
COCKBURN (2000) questiona o tratamento das pessoas como recursos
humanos na literatura tradicional de gerência de projetos de software, dizendo que as
pessoas acabam virando “componentes” previsíveis, quando, pelo contrário, são por
natureza altamente variáveis e não-lineares.
No entanto, observa-se que grande parte das metodologias tradicionais não
atentam esse aspecto, se importando principalmente em seguir o planejamento e
cronograma, ignorando os fatores humanos recorrentes em um projeto.
A motivação e o enfoque que métodos tradicionais e ágeis dão às pessoas são
temas importantes sobre o desenvolvimento de pessoas, que será visto a seguir.
4.1 Motivação
MELNIKOFF e outros (2007) citam como uma das principais funções do gerente de
projetos é a de cuidar da motivação das pessoas envolvidas, criando nelas o interesse
pelo trabalho a ser realizado.
Em uma experiência, na década de 1940, com macacos e um quebra-cabeça
mecânico simples, Harry F. Harlow e seus alunos de psicologia na University of
Winsconsin constaram que os macacos descobriram rapidamente como os dispositivos
funcionavam. Isso, sem ao menos os ter ensinado ou recompensado. Analisando o fato
de que eles não tinham sido acionados pelo comportamento biológico (comida, água ou
gratificação sexual) nem por motivações extrínsecas (recompensas e punições), Harlow
deduziu uma terceira motivação, a intrínseca, ou seja, o prazer da tarefa era a própria
recompensa (HARLOW, 1950 apud PINK, 2010, p. 1-3).
PINK (2010) relata duas importantes evoluções ao trabalho de Harlow. O
primeiro, na década de 1950, no qual Abraham Maslow, antigo aluno de Harlow,
desenvolveu o campo da psicologia humanística. E o segundo, em 1960, em que Douglas
McGregor, professor de administração do MIT, importou algumas ideias de Maslow

para o mundo dos negócios, reforçando que as pessoas têm outros impulsos que
poderiam beneficiar os negócios se gestores e lideres empresariais os respeitassem.
Um pouco mais tarde, Teresa Amabile (AMABILE, 1996 apud PINK, 2010, p.
26), da Havard Business School, verificou que recompensas e punições externas
funcionam muito bem nas tarefas repetitivas. Entretanto, podem ser devastadoras para o
trabalho criativo. Amabile diz que “a motivação intrínseca conduz à criatividade; a
motivação extrínseca controladora é prejudicial à criatividade”.
GABARDO e GOMES (2009) reforçam a ideia de que os métodos ágeis
promovem a autonomia das equipes e favorecem a motivação dos colaboradores. E em
(Tessem, et al., 2007 apud GABARDO; GOMES, 2009, p. 9-10) é mostrado que os
fatores como autonomia, feedback e a habilidade de completar uma tarefa são fatores
significativos dos métodos ágeis que aumentam a satisfação e motivação dos
trabalhadores.
Diversas pesquisas demonstram que aqueles que trabalham em equipes auto-
organizadas, como em times ágeis, estão mais satisfeitos do que os que trabalham em
equipes já estabelecidas (PARKER, WALL e HACKSON, 1997 apud PINK, 2010, p.
93).
CORREA e TANIGUCHI (2009) comentam em seu trabalho que as
metodologias ágeis promovem na equipe o sentimento de que todos estão no controle do
projeto, o qual não pertence à empresa, ao cliente ou a um gerente de projeto, e sim a
todos os envolvidos. Desta forma, todos sentem-se mais valorizados e comprometidos
com o objetivo que, ao ser alcançado, motivará ainda mais estes indivíduos em busca de
conhecimento e crescimento profissional por meio da adaptação constante empregada no
processo.
4.2 Métodos tradicionais e ágeis
Segundo FOWLER (2005), os métodos ágeis surgem com as principais características de
adaptabilidade e foco nas pessoas, enquanto que os métodos tradicionais objetivam a
definição de processos e execução dos planos com a tentativa de adequar as pessoas ao
processo, frustrando muitas vezes o desempenho do projeto devido as pessoas serem
difíceis de prever e quantificar.
FOWLER (2005) aponta a aceitação, ao invés da imposição, do processo como
elemento fundamental para se gerenciar um processo orientado a pessoas. Geralmente, a
implantação de processos sofre resistência por parte dos colaboradores pelo fato de
serem impostos pela administração da empresa sem ao menos detectarem os reais
problemas enfrentados no dia a dia. FOWLER (2005) enfatiza que a aceitação de um
processo requer o comprometimento de toda equipe envolvida no projeto.
Segundo COCKBURN e HIGHSMITH (2001), o projeto é construído dentro de
uma cultura organizacional, em um ambiente físico e a partir de pessoas com
personalidades e habilidades diferentes tornando-os um complexo ecossistema, fazendo
com que um fator influencie o outro naturalmente. No momento da implantação de um
processo dentro de um ecossistema, há opções a serem feitas: adequar o ecossistema ao
processo ou o processo ao ecossistema. Nesse ponto é que os métodos ágeis tentam se
adequar ao ambiente e não o contrário.
COCKBURN e HIGHSMITH (2001) distinguem a colaboração da comunicação,
sendo que ao se comunicar há ocorrência apenas da emissão e recepção de informação.

Já com a colaboração ocorre um trabalho em conjunto para elaboração de um produto
ou tomada de decisões compartilhadas. TURNER e BOEHM (2003) identificam canais
de comunicação nas práticas ágeis de reunião em pé, programação em par e reuniões de
planejamento como preferência para a colaboração.
CISCON (2009) realiza uma comparação entre as abordagens tradicional e ágil
de gerência de projetos referente a pessoas.
Pessoas
Ágil Tradicional
Desenvolvedores Agilidade;
Podem assumir vários papéis;
Alta rotatividade nas equipes de
desenvolvedores;
Conhecimento tácito sobre o domínio do
projeto;
Preferência por desenvolvedores mais
capacitados.
Orientados pelo plano;
Geralmente assumem um único papel
dentro do projeto;
Baixa rotatividade dentro da equipe;
Conhecimento formal e documentado;
Sem preferência.
Testadores Testadores trabalham com estreita
relação com os desenvolvedores;
Necessidade de conhecimento em
programação, a fim de automatizarem
os testes;
Abordagem do teste primeiro.
Geralmente os testadores trabalham
separados dos desenvolvedores;
Conhecimento restrito a área de testes;
Testes alfa, beta e de homologação.
Clientes Clientes on site;
Clientes participam de todo o
desenvolvimento;
Cliente contribui na tomada de decisões.
Clientes não muito presentes;
Clientes geralmente não participam de
todo o desenvolvimento;
Cliente nem sempre contribui nas
decisões tomadas.
Direção Executiva Confia no trabalho do gerente de projeto
e na equipe;
Pouco apegada às estimativas.
Comprometida com datas de entrega,
cronogramas e planos detalhados;
Apegada às estimativas.
Equipe Projeto apoiado na equipe;
Atuação colaborativa em todas as
atividades do projeto;
Alta rotatividade dentro da equipe;
Equipe conhece o estado do trabalho de
cada membro;
Cliente faz parte da equipe.
Projeto apoiado no gerente de projeto;
Atuação da equipe com papéis claros e
bem definidos;
Baixa rotatividade dentro da equipe;
Equipe não conhece o estado do trabalho
de cada membro;
Cliente não sabe quem é a equipe.
Será apresentado, a seguir, um estudo de caso sobre um projeto executado com
métodos ágeis e que foi realizado em um órgão militar.
5. Estudo de caso: práticas de gestão de pessoas no contexto de métodos ágeis
A empresa SEA Tecnologia, sediada em Brasília, Distrito Federal, surgiu como uma
parceira da empresa Rational e era especializada em implantação da metodologia de
desenvolvimento RUP (Processo Unificado Rational). Mesmo contando com equipes
qualificadas e depois da tentativa de implantação de modelos de qualidade de processos
como o MPS.BR (modelo de Melhoria de Processos do Software Brasileiro), a empresa

alcançou melhores resultados em termos de estabilidade, satisfação, sustentabilidade e
rotatividade depois de adotar metodologias ágeis quatro anos depois de sua fundação.
Baseado em entrevistas, é transcrevido a seguir, um estudo de caso sobre o
projeto SIGPAER (Sistema de Gerenciamento Integrado da Prevenção de Acidentes
Aeronáuticos), iniciado no ano de 2008 e realizado em instituições consideradas rígidas
como as forças armadas, mas que trouxeram a possibilidade de o tradicional conviver em
harmonia com novos processos de desenvolvimento de software trazendo um benefício
mútuo tanto para o time de desenvolvimento quanto para o cliente.
5.1 Projeto SIGPAER
A SEA Tecnologia não utiliza uma metodologia por completo. Utiliza conceitos de
Scrum para planejamento e práticas de engenharia de software da XP como testes
automatizados, integração contínua, programação em par, entre outras. É dada mais
ênfase aos valores ágeis. Como se dissessem aos desenvolvedores: “sigam esses valores e
façam do jeito que acharem melhor”.
Renato Willi, coordenador de projetos, relata que para tranquilizar o cliente no
intuito de que ele tivesse a visão de como o software seria desenvolvido não acarretando
riscos contratuais ou prejuízos para eles, era realizado um trabalho de conscientização
das práticas que iriam ser utilizadas no projeto, explicando como e o por que eram feitas
de tal maneira. Tudo isso era feito antes de iniciar o projeto e alocação da equipe. Foi
importante repassar que tudo que constava objetivamente no contrato seria atendido
pelo trabalho da empresa, independente do processo de desenvolvimento.
5.1.1 Documentação utilizada
5.1.1.1 Plano de desenvolvimento de software
A proposta deste documento é planejar o desenvolvimento da fase de construção do
sistema, nele estará contida a organização do projeto, processo de gerenciamento,
planejamento da equipe, aquisição de recursos, treinamento, iterações, monitoração,
controle do projeto, planejamento técnico e suporte. Ele foca as características e passos
necessários para um bom desenvolvimento do projeto. Serão evidenciadas apenas as
seções relacionadas à gestão de pessoas.
5.1.1.1.1 Lista de restrições
A lista de restrições é uma seção importante, que envolve os itens referentes ao local de
trabalho, carga horária, infraestrutura e definição do processo a ser utilizado no projeto:
– A equipe deverá trabalhar nas dependências do Centro de Computação da
Aeronáutica (CCA-BR);
– O horário de trabalho é de 9 da manhã às 17 horas;
– Os equipamentos serão providos pela Aeronáutica;
– O projeto constitui de 3.100 horas, podendo ser aditivado em até 25%;
– Não haverá recursos para aquisição de ferramentas ou equipamentos;
– O processo de desenvolvimento do projeto (SEAUP) deverá estar em
conformidade com o MPS.BR nível G.

5.1.1.1.2 Estrutura organizacional
A Figura 4 mostra a estrutura organizacional, que é um diagrama no qual exibe o fluxo
da comunicação entre os envolvidos no projeto.
5.1.1.1.3 Recursos humanos
Cada um dos integrantes da equipe de desenvolvimento atuaria em um ou mais papéis,
dentro de cada iteração, de acordo com a demanda. Mais pessoas poderiam ser alocadas
futuramente no projeto. Os papéis identificados para o projeto foram: um gerente de
projeto; um analista de sistemas; um designer; seis desenvolvedores, sendo quatro da
SEA e dois Sargentos da Aeronáutica; um arquiteto de software; uma analista de teste,
sendo uma Suboficial da Aeronáutica; demais interessados, um Coronel e um Tenente da
Aeronáutica.
5.1.1.2 Plano de gerenciamento de projeto
Segundo o Guia PMBOK, desenvolver o plano de gerenciamento de projeto é o
processo de documentação das ações necessárias para definir, preparar, integrar e
coordenar todos os planos auxiliares. É o principal processo de planejamento, pois,
integra os demais planos complementando-os, e provavelmente, o processo mais
importante para o gerente de projeto (PMI, 2008).
No contexto da gestão de pessoas, é importante ressaltar os itens do Plano de
Gerência de Comunicação do SIGPAER:
– Semanalmente, o coordenador de desenvolvimento deveria enviar um e-mail para
o gerente e demais interessados, informando o resultado das atividades da
semana anterior, frente aos objetivos nela definidos, e os objetivos da próxima
semana.
– Deveria ser criada uma lista de e-mails para centralizar e manter histórico das
mensagens eletrônicas trocadas no ambiente do projeto.
– Os meios de contato dos componentes da equipe deveriam estar centralizados e
disponibilizados para todos.
– Uma vez por semana, haveria uma reunião de ponto de controle e objetivos da
semana com toda a equipe. Nela seriam efetuadas avaliações do desenvolvimento
do projeto, definidas ações corretivas e divulgações de decisões tomadas.
Figura 4: Estrutura organizacional

– As comunicações entre as organizações envolvidas e empresas contratadas,
seriam feitas pelo gerente de desenvolvimento nos meios que considerar
adequados (telefone, e-mail ou reunião presencial).
– A equipe deveria se reportar ao coordenador de desenvolvimento, e este ao
gerente de desenvolvimento. Caso as equipes crescessem, cada equipe se
reportaria ao seu respectivo coordenador, e este ao coordenador de
desenvolvimento.
– Ao final de cada iteração, o coordenador registraria as lições aprendidas sobre
comunicação na avaliação da iteração e tomaria as medidas corretivas se
necessário.
5.1.2 O uso do Scrum na execução dos planos do projeto
O objetivo desse novo projeto era a manutenção de um sistema feito em parceria entre
Exército e Aeronáutica. Cada entidade tinha ramificações do sistema que deveriam ser
mescladas antes do começo do novo projeto. Para utilização das práticas ágeis, tiveram
apoio total da equipes que participaram dos dois projetos. Conhecimento eles já
obtinham, faltava um ambiente favorável para colocá-los em prática.
Como o próprio Guia PMBOK cita que é possível usar metodologias e
ferramentas distintas para implementar a sua estrutura, os papéis, eventos e artefatos do
Scrum foram utilizados para guiar o projeto de forma flexível e interativa (PMI, 2008).
Após a junção dos projetos, foi iniciado o primeiro Sprint Planning, como
mostrado na Figura 5.
O Product Owner, um Tenente da Aeronáutica, que avaliava e gerenciava o
projeto, levantava um número suficiente de estórias de usuário para a Sprint, depois
entrava em acordo com um Capitão do Exército sobre as funcionalidades para
encaminhá-las ao time de desenvolvimento.
5.1.3 Transparência a partir de práticas da XP
As funcionalidades do sistema foram escritas em cartões de estórias do usuário, vistas na
Figura 6. Isso cria um ambiente no qual o time e o cliente possam interagir de uma
maneira que resulte em confiança mútua. O cliente escreve as estórias, pois é ele quem
conhece as regras de negócio e o time estima quanto tempo levará para realizar as tarefas
Figura 5: Sprint Planning

advindas das estórias, pois ele é quem conhece as técnicas de desenvolvimento de
software.
Para estimar cada estória foram utilizadas rodadas de Planning Poker2
em que,
cada pessoa do time se imagina trabalhando um dia inteiro sem interrupções, sem
problemas ou sem dependências decompondo a estória pensando em todas as atividades
até o estado de “pronto” e anota-se um número pertencente à sequencia de Fibonacci3
.
Depois todos mostram sua estimativa para que entrem em um acordo sobre qual será a
estimativa definitiva para a estória. O primeiro Planning Poker do projeto ocorreu e
resultou em cinco estórias e vinte e um pontos.
A definição de pronto foi acordada da seguinte maneira: o incremento deveria
estar programado, testado, código-fonte documentado, apresentado e aprovado. Com
isso, o próximo passo era estimar as estórias em ordem de prioridade. O tamanho da
iteração foi definido em aproximadamente duas semanas, por conta de particularidades
do expediente e feriados. Seriam dez dias úteis. Foram consideradas três pessoas em
tempo integral, já que nem todos eram dedicados exclusivamente ao projeto (não é uma
boa prática, mas a realidade era essa). O total era de trinta pontos. Foi considerada uma
taxa de setenta porcento (70%) de produtividade, que é alta, mas jogar abaixo disso
parecia incômodo para o cliente. A velocidade projetada para a primeira Sprint foi de
vinte e um pontos para as primeiras duas semanas.
Os cartões de estórias ficavam no quadro, colados com uma massa especial, para
que todos pudessem ter a visão atual do projeto. Devido a equipe não ter conhecimento
prévio do código-fonte do projeto, não havia muita base para estimativas e
conhecimento sobre a produtividade da mesma. Com isso, o time foi preparado
psicologicamente para errar provavelmente as três primeiras estimativas,
fundamentando-se na literatura e experiência prévia de outros projetos. Para não gerar
frustrações na equipe, foi estimado a melhoria progressiva a partir da quarta iteração.
5.1.4 Equipes auto-organizadas e maturidade
As duas semanas seguintes foram seguidas por reuniões diárias assistidas pelo
coordenador e líder técnico do projeto. Mas, aos poucos, foram deixando apenas o time
2 Técnica baseada no consenso, utilizada para estimar esforço ou tamanho relativo de estórias de
usuários.
3 Sequência de números naturais, na qual os primeiros dois termos são 1 e 1, e cada termo
subsequente corresponde à soma dos dois precedentes.
Figura 6: Cartões de estórias do usuário

tomando conta das cerimônias para dar-lhes mais confiança e diminuir a dependência da
equipe por gerência ou coaching4
. A equipe deve aprender que as reuniões são para ela
mesma, e deve aprender a se gerenciar.
Na primeira Sprint, foram criados vários testes automatizados e resolvido apenas
um cartão de oito pontos, dos vinte e um planejados, como foi previsto na reunião de
planejamento. Esse aprendizado foi motivador para a iteração seguinte e que obteve um
resultado muito melhor. Ao final da Sprint, em um dia inteiro foi realizado a
apresentação, retrospectiva e reunião de planejamento da próxima Sprint.
Alguns pontos positivos foram destacados na retrospectiva. A criação de testes
automatizados unitários e funcionais utilizando Junit5
e Selenium6
, dando à equipe
coragem e confiança e ao código mais robustez. A cooperação de todos foi notória,
todos trabalharam como um time, buscando objetivos comuns. Todos os problemas
emergiram da própria equipe, isso mostra o quão responsável e madura é a equipe.
5.1.5 Inspeção e adaptação
Os pontos negativos também foram enfatizados como a de algumas pessoas que
admitiram falta de disponibilidade para cuidar do projeto, ainda não estava sendo gerado
um build7
por semana. Também havia outros problemas como falhas de comunicação, o
código que não estava documentado a contento, problemas na padronização de nomes e
era necessário aumentar a granularidade das estórias para ter a percepção de algo estar
ficando pronto. Interessante notar positivamente o fator psicológico do prazer em trocar
os cartões de lugar e ainda mais em jogá-los no lixo ao concluí-los.
Uma solução criativa e excelente para tratar os pontos negativos da retrospectiva
foi a criação de alguns mantras para que fossem colados no quadro de tarefas para que
todos os dias a equipe pudesse visualizar e lembrar o que deveria melhorar. Exemplos
como: “Vou me comunicar mais”, “Vou documentar mais o código” e outras coisas do
gênero. Para os demais, foi definida uma padronização de nomes e anotadas no quadro, e
que se aumentaria a granularidade das estórias e atividades para a próxima iteração.
5.1.6 Colaboração e confiança
A segunda Sprint foi iniciada com a velocidade de onze pontos, baseada na estória de
oito pontos mais três pontos de tarefas não planejadas mas que foram realizadas na
Sprint anterior. O coordenador do projeto comenta que só pôde visitar a equipe no
quarto dia da iteração e viu, pelo quadro de tarefas, que a equipe já estava acabando
todas as estórias planejadas. Todos os envolvidos estavam muito felizes com o resultado.
A equipe estava andando muito bem.
Nas iterações seguintes não havia mais apresentação oficial, pois já estavam
apresentando constantemente as funcionalidades, gerando builds semanalmente, os bugs
eram poucos e estavam sob controle, os problemas de padronização de nomes e
granularidade foram resolvidos. Estava indo tão bem que foi decidido que o projeto
4 Processo definido com um acordo entre o coach (profissional) e o coachee (cliente) para atingir a
um objetivo desejado pelo cliente.
5 Framework, criado por Erich Gamma e Kent Beck, com suporte à criação de testes automatizados na
linguagem de programação Java.
6 Ferramenta para testar aplicações web pelo navegador de forma automatizada.
7 Processo de empacotamento do código-fonte do projeto para ser enviado ao ambiente de produção.

começaria a ser colocado brevemente em produção nas Organizações Militares. A Figura
7 mostra o quadro de tarefas da segunda Sprint do projeto. Na primeira coluna encontra-
se o Product backlog. Os post-its, que são as tarefas decompostas das estórias,
“prontos” ficavam fora do quadro, devido o mesmo ser pequeno.
A Figura 8 mostra o quadro de tarefas após a retrospectiva, depois de limpar o
que já estava pronto.
A retrospectiva da Sprint foi muito boa. Foi realizada uma revisão na iteração,
avaliando por que tudo tinha ido bem dessa vez, pois na primeira iteração, ninguém sabia
de nada do código, o time não tinha um ambiente totalmente preparado e estavam
trabalhando no núcleo do sistema. Na segunda iteração, as barreiras iniciais estavam
todas vencidas e o time estava pronto. A simplicidade das funcionalidades também
colaborou.
5.1.7 Gerenciamento de expectativas
Foi decido alterar a duração da próxima iteração. Isso não é boa prática, mas era preciso
diminuir o tempo das reuniões gerenciais relativas ao tempo das iterações. E como não
havia mais feriados no ano, foi pensando em dar um dia de folga como recompensa se
fosse tudo bem. Quinzenalmente o custo disso seria alto. Era desejado também acertar
Figura 7: Quadro de tarefas da segunda Sprint
do projeto
Figura 8: Quadro de tarefas após a
retrospectiva da Sprint 2

cada iteração com o mês. Algo próximo da realidade do time. Com isso, a terceira Sprint
ficou acordada em cinco semanas, a velocidade do time em dez pontos por semana e a
priorização com a estimativa em cinquenta pontos.
Na retrospectiva da terceira Sprint, o time admitiu que estava falhando nas
reuniões diárias, e que isso estava gerando problemas de comunicação. Observaram que
era preciso separar um tempo para os refactorings8
e a documentação no código ainda
não estava satisfatória. A parte considerada positiva tinha sido a especificação dos testes
funcionais para aprovação das estórias. Ficou acordado de escrevê-los no verso dos
cartões, a partir de então.
No planejamento, as estimativas foram bem mais precisas. Todos estavam bem
mais conscientes do que deveria ser feito para desenvolver cada estória. Coisas que o
time achava ser pequenas foram se mostrando complexas. Foram encontrados diversos
“efeitos colaterais” de algumas alterações. Foi considerado modificar novamente uma
parte complicada do sistema, mas dessa vez o time estava bem mais preparado.
O clima de otimismo tomou conta geral do time, mas não podia-se contaminar
por ele. O desafio era em se manterem realistas. O projeto foi indo bem porque a
expectativa foi bem gerenciada. Um otimismo desse poderia frustrar a todos.
6. Conclusões
Todo projeto possui riscos. Métodos de gestão tradicionais tentam mitigá-los com
planejamentos meticulosos e previsíveis causando o engessamento de todos os
envolvidos. Geram contratos rígidos para assegurar que suas tarefas sejam executadas e
com penalidades altíssimas caso isso não ocorra. É dada mais importância aos artefatos e
ferramentas que circundam o projeto levando as pessoas ao desgaste muitas das vezes os
desviando de suas reais competências, que são de entregar produtos com constância e
qualidade.
O estudo de caso mostrou o projeto exigia uma extensa documentação com o
objetivo de fornecer garantias aos envolvidos, tanto que o desenvolvimento do projeto
deveria estar em conformidade com o MPS.BR nível G. Entretanto, Scrum e XP se
adequaram aos processos de gestão do projeto e, principalmente, na gestão das pessoas
com seus valores, princípios, eventos e práticas. Com isso, as falhas que aconteciam em
uma iteração eram mitigadas na próxima, o time e cliente ganhavam mais confiança e
autonomia. Com o tempo, podendo ser equiparado ao nível gerenciado do P-CMM, no
qual os problemas que contribuem para que as pessoas deixem de executar eficazmente
suas atividades incluem: a) sobrecarga de trabalho; b) distração ambiental; c) objetivos
de desempenho e feedback obscuros; d) falta de conhecimento ou habilidade relevantes;
e) comunicação ineficiente; e f) moral baixo (SILVEIRA et al., 2007).
Em PINK (2010), Garyl Hamel, um guru da estratégia, cita a gerência como uma
tecnologia já obsoleta, tendo o controle como objetivo central e motivadores extrínsecos
como principais ferramentas. Métodos ágeis distribuem a gestão do projeto entre os
envolvidos de uma maneira organizada e democrática, separando os papéis dos
responsáveis em suas respectivas atribuições resultando, com o tempo, em uma sintoniza
fina entre cliente, negócios e técnica.
8 Processo de modificar um sistema de software para melhorar a estrutura interna do código sem
alterar seu comportamento externo.

O estudo de caso mostrou que o projeto foi desenvolvido e implantado em um
ambiente rígido, como as forças armadas, poderiam ter sido implementados processos
como RUP, P-CMM ou PMBOK, para gerir o projeto como um todo. Mas devido a
experiência dos colaboradores, principalmente do coordenador e do líder técnico, foi
passado ao cliente a garantia de que problemas poderiam a acontecer e que eles seriam
resolvidos da melhor forma possível, pois a imprevisibilidade faz parte de qualquer
projeto. A transparência, um dos pilares dos métodos ágeis, é um dos motores que provê
a confiança entre cliente e time, seja em qualquer tipo de projeto.
MELNIKOFF et al. (2007) comenta que o P-CMM é projetado para grandes
empresas, reforçando a importância das pessoas como indivíduos e de desenvolver duas
capacidades. O PMBOK também, em seu capítulo sobre gerenciamento de recursos
humanos, discorre sobre equipes pequenas e coesas que obtêm melhor desempenho. E
existem vários estudos sobre a aderência de métodos ágeis em processos como o
MPS.BR. O PMI já possui uma certificação ACP (Profissional Certificado em Métodos
Ágeis), sinal de que os processos estão se convergindo e colocando o fator humano
como principal peça da engrenagem no desenvolvimento de software.
Referências
BECK, K. Programação extrema explicada: acolha as mudanças. Porto Alegre:
Bookman, 2004.
BECK, K. et al. (2001) Manifesto for Agile Software Development. Disponível em:
<http://agilemanifesto.org>. Acesso em: 05 mar. 2011.
BROOKS, F. O mítico homem-mês: ensaios sobre engenharia de software. Rio de
Janeiro: Elsevier, 2009.
CISCON, L. Um estudo e uma ferramenta de gerência de projetos com
desenvolvimento ágil de software. Dissertação de Mestrado, UFMG, 2009.
COCKBURN, A. Characterizing people as non-linear, first-order components in
software development. Orlando: 4th International Multi-Conference on Systems,
Cybernetics and Informatics, 2000. Disponível em: <http://alistair.cockburn.us/
Characterizing+people+as+non-linear%2c+first-order+components+in+software+
development>. Acesso em: 15/06/2011.
COCKBURN, A; HIGHSMITH, J. Agile Software Development: the people factor,
Computer, 2001.
CORREA, F; TANIGUCHI, K. Metodologias Ágeis e a Motivação de Pessoas em
Projetos de Desenvolvimento de Software. Revista de Ciências Exatas e Tecnologia,
Vol. IV, Nº 4, São Paulo, 2009.
CURTIS, B. et al. People Capability Maturity Model. Pittsburg: Software Engineering
Institute, 2001. Disponível em: <http://www.sei.cmu.edu/reports/ 01mm001.pdf>.
Acesso em: 16/08/2011.
DEMARCO, T; LISTER, T. Peopleware: productive projects and teams. 2nd ed. New
York: Dorset House Publishing, 1999.
FOWLER, M. The new methodoly, 2005. Disponível em:
<http://martinfowler.com/articles/newMethodology.html>. Acesso em: 05/06/2011.

FRANÇA, A. Um Estudo sobre Motivação em Integrantes de Equipes de
Desenvolvimento de Software. Dissertação de Mestrado, UFPE, 2009.
GABARDO, M; GOMES, A. Discussão sobre Motivação de Equipes na
Implementação de Métodos Ágeis no Desenvolvimento de Sistemas na
Administração Pública Federal. UCB, 2009.
JOSKO, J. Gestão de Pessoas em Tecnologia da Informação – Uma visão
perspectiva das abordagens. Dissertação de Mestrado, UNICAMP, 2004.
MELNIKOFF, S. et al. Engenharia de software. 8ª ed. São Paulo: Pearson Addison-
Wesley, 2007.
NONAKA, I.; TAKEUCHI, H. The new new product development game. Harvard
Business Review, Boston, 1986.
PINK, D. Motivação 3.0. Rio de Janeiro: Elsevier, 2010.
PMI. Guia PMBOK. 4ª ed. Newtown Square: PMI, 2008.
SCHWABER, K; SUTHERLAND, J. Guia do Scrum. Scrum.org, 2011. Disponível em:
<http://www.scrum.org/storage/Scrum%20Guide%202011%20-%20PTBR.pdf>.
Acesso em: 05/12/2011.
SCHWABER, K. SCRUM Development process. OOPSLA’95, Austin, 1995.
Disponível em: <http://home.hib.no/ai/data/master/mod251/2009/articles/scrum.pdf>.
Acesso em: 12/12/2010.
SILVEIRA, V. et al. Os Modelos de Maturidade e a Gestão de Pessoas: O Modelo P-
CMM. XXXI EnANPAD, Rio de Janeiro, 2007.
TURNER, R; BOEHM, B. People factors in software management: lessons from
comparing agile and plan-driven methods. The Journal of Defense Software
Engineering, 2003.

Uma análise sobre gestão de pessoas baseada nos métodos ágeis

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Uma análise sobre gestão de pessoas baseada nos métodos ágeis

Similar a Uma análise sobre gestão de pessoas baseada nos métodos ágeis (20)

Más de s4nx

Más de s4nx (20)

Uma análise sobre gestão de pessoas baseada nos métodos ágeis