C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO

RECIFE

LUIZ SANCHES

UMA ANÁLISE SOBRE GESTÃO DE PESSOAS BASEADANOS MÉTODOS ÁGEIS

Recife2012

LUIZ SANCHES

UMA ANÁLISE SOBRE GESTÃO DE PESSOASBASEADA NOS MÉTODOS ÁGEIS

Artigo apresentado ao programa deEspecialização em Engenharia de Software doCentro de Estudos e Sistemas Educacionais doRecife – C.E.S.A.R, como requisito para aobtenção do título de Especialista emEngenharia de Software com ênfase em GestãoÁgil de Projetos.

Orientação: Prof. Felipe Furtado

Coorientação: Renato Willi

Recife2012

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 egrandes corporações desde a era industrial, que formulou a base da gestãotradicional de pessoas e que continua sendo aplicada pelos departamentos derecursos humanos. Particularmente em empresas de tecnologia, onde aessê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 maneirassustentáveis, envolvendo colaboradores e clientes, para entregar produtos dequalidade e manter as equipes saudáveis. Nesse contexto, será apresentadoum estudo sobre métodos tradicionais e ágeis com foco em pessoas e umestudo 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 seucapital intelectual. É responsabilidade dos gerentes de software garantir que aorganização obtenha o melhor retorno sobre o investimento em pessoas. Ogerenciamento inadequado de pessoas é uma das mais significativas contribuições para afalha do projeto (MELNIKOFF et al., 2007).

A gestão de pessoas procura obter o melhor do funcionário enquanto membro daempresa. O capítulo 9 do PMBOK, que trata sobre gerenciamento dos recursos humanosdo 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 guiarequipes de desenvolvimento de software quanto à gestão de pessoas.

Métodos ágeis como Scrum e XP, tomam como base a colaboração entre aspessoas envolvidas no processo para que possam entregar produtos com qualidade econstância. O uso dos métodos ágeis em equipes de desenvolvimento de software está sedifundindo bastante no meio acadêmico e corporativo e pode ajudar, consideravelmente,as empresas da área de tecnologia a solucionarem seus problemas relacionados à gestãode pessoas.

1.1 Objetivos

Este trabalho apresenta uma revisão da literatura sobre gestão de pessoas em equipes dedesenvolvimento de software, bem como, um estudo dos métodos ágeis Scrum e XPcom foco na gestão de pessoas. Ao final, tenta-se evidenciar isto tudo por meio de umestudo de caso concreto.

O objetivo deste trabalho é mostrar que, a partir dos valores, princípios e práticaspresentes nos métodos ágeis, é possível fazer-se uma gestão adequada de recursoshumanos 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 aspectospráticos e do dia a dia da cultura das organizações.

Com isso, colocar-se em prática uma adoção descuidada desses modelos muitasvezes resulta em sobrecarga e inclusão de burocracias no processo de software. Alémdisso, 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 eprincípios ágeis deixarem de se referirem aos membros de suas equipes como mais umtipo 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 aforma de ver as coisas sob a ótica das metodologias tem sobre aspectos como a gestãode pessoas.

1.3 Estrutura do Artigo

Este artigo está estruturado como se segue. O capítulo 2 abrange o que é a gestão depessoas. O capítulo 3 apresenta e conceitua métodos ágeis. Já o capítulo 4 fala sobreaprimoramento e desenvolvimento de pessoas. Um estudo de caso mostrando práticas degestã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 naturezatecnológica, e sim de natureza sociológica. Ter a última tecnologia ou bugs1 em sualinguagem de programação não são páreos para problemas de comunicação, falta demotivação ou desentendimentos (DEMARCO; LISTER, 1999).

FRANÇA (2009) relata que pesquisas recentes demonstram que os profissionaisde engenharia de software estão entre os profissionais mais estressados e desmotivadose, que os modelos de motivação existentes são excessivamente teóricos e com poucaaplicabilidade prática, dificultando assim a interpretação e implementação destes modelospor gerentes de projetos de software.

O gerenciamento eficiente está, portanto, relacionado ao gerenciamento depessoas em uma organização. O gerenciamento inadequado de pessoas é uma das maissignificativas contribuições para a falha do projeto (MELNIKOFF et al., 2007).

Segundo MELNIKOFF et al. (2007) existem quatro fatores críticos nogerenciamento de pessoal:

– consistência, em que as pessoas de uma equipe de projeto devem ser tratadas demaneira uniforme;

– respeito, que conhece que pessoas diferentes têm habilidades diferentes e osgerentes devem respeitar essas diferenças;

– inclusão, no qual as pessoas contribuem efetivamente quando sentem que osoutros 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 honestosobre o que vai ou não bem na equipe.

Veremos, a seguir, os modelos de gestão de pessoas baseados no Guia PMBOK eP-CMM.

2.1 O Guia PMBOK

O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK), criado egerido pelo Instituto de Gerenciamento de Projeto (Project Management Institute -PMI), é utilizado como padrão para gerenciar a maioria dos projetos na maior parte dasvezes em vários tipos de setores da indústria. Ele descreve os processos, ferramentas eté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 nemcompleto. Ele é mais um guia que uma metodologia. É possível usar metodologias eferramentas 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 umproduto, serviço ou resultado exclusivo. Um projeto pode envolver uma única pessoa,uma única ou múltiplas unidades organizacionais e, devido à natureza exclusiva dosprojetos, pode haver incertezas quanto aos produtos, serviços ou resultados criados porele (PMI, 2008).

Ainda de acordo com o PMI (2008), o gerenciamento de projetos é a aplicaçãode conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim deatender aos seus requisitos e para gerenciar um projeto deve-se: identificar os requisitos;adaptar-se às diferentes necessidades, preocupações e expectativas das partesinteressadas à medida que o projeto é planejado e realizado e, balancear as restriçõesconflitantes do projeto (escopo, qualidade, cronograma, orçamento, recursos e risco).

O PMI (2008) referencia o gerente de projetos como a pessoa designada pelaorganização executora para atingir os objetivos do projeto e garantir que o plano domesmo esteja alinhado com o plano do programa central. Compreender e aplicar oconhecimento, 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 gerenciamentogeral exigidas, o gerenciamento de projetos eficaz requer que o gerente tenha asseguintes 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 suaequipe na obtenção de seus objetivos mantendo o equilíbrio das restrições doprojeto.

2.1.2 Fatores ambientais da empresa

São os fatores internos e externos que influenciam o sucesso do projeto, servindo comoaumento ou restrição das opções de gerenciamento de projetos e influenciam positiva ounegativamente no resultado do mesmo (PMI, 2008).

Alguns dos fatores ambientais que o PMI (2008) elenca são: cultura, estrutura eprocessos organizacionais; normas governamentais ou do setor; infraestrutura; recursoshumanos existentes; administração de pessoal; sistemas de autorização do trabalho daempresa; canais de comunicação estabelecidos da organização; sistemas de informaçõesdo 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 gerenciama equipe do projeto.

A equipe do projeto consiste nas pessoas com papéis e responsabilidadesdesignadas para a conclusão do projeto. O envolvimento e a participação dos membrosda equipe desde o início agrega seus conhecimentos durante o processo de planejamentoe fortalece o compromisso com o projeto (PMI, 2008).

De acordo com o PMI (2008), o gerenciamento dos recursos humanos doprojeto envolve os processos de:

– desenvolvimento do plano de recursos humanos, onde é identificado edocumentado as funções, responsabilidades, habilidades necessárias e relaçõeshierárquicas do projeto, além da criação de um plano de gerenciamento dopessoal;

– mobilização da equipe do projeto, onde ocorre a confirmação dadisponibilidade dos recursos humanos e obtenção da equipe necessária paraconcluir as designações do projeto;

– desenvolvimento da equipe do projeto, onde ocorre a melhoria decompetências, interação da equipe e ambiente global da equipe para aprimorar odesempenho do projeto;

– gerenciamento da equipe do projeto, onde acompanha-se o desempenho demembros da equipe, fornecendo feedback, resolvendo questões e gerenciandomudanças para otimizar o desempenho do projeto.

Para que essas tarefas sejam realizadas é necessário a criação da equipe degerenciamento de projetos. Para projetos menores, as responsabilidades degerenciamento do projeto podem ser compartilhadas por toda a equipe ou administradasexclusivamente 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 quepodem impactar o projeto, como: o ambiente da equipe, localizações geográficasdos membros da equipe, comunicações entre as partes interessadas, questõespolíticas internas e externas, questões culturais, singularidade organizacional eoutros fatores de pessoal que podem alterar o desempenho do projeto;

– estar ciente e assumir o compromisso de garantir que todos os membros daequipe tenham um comportamento ético.

2.2 O modelo P-CMM

Na busca de melhorias na área de engenharia de software, o SEI (Software EngineeringInstitute) vem desenvolvendo o Modelo de Maturidade de Capacitação (CapabilityMaturity Model – CMM) que agrega disciplinas e práticas que contribuem diretamentepara o desempenho dos negócios de uma organização, visando a alta qualidade de seusprodutos e serviços (CURTIS et al., 2001).

O Modelo de Maturidade de Capacitação de Pessoal (People CapabilityMaturity Model – P-CMM) foi concebido com o propósito de aumentar a capacidade daforç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 decomportamento de uma organização possam apoiar as melhorias nas práticas da força detrabalho da mesma, fornecendo um roteiro para transformar uma organização comaprimoramento constante de suas práticas profissionais.

O P-CMM é composto por cinco níveis de maturidade, sendo que em cada umdeles, um novo sistema de práticas é sobreposto sobre os implementados em níveisanteriores, provocando uma evolução das práticas e processos da força de trabalho. Emum ambiente como esse, os indivíduos obtêm a oportunidade de desenvolver sua carreiraprofissional 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çãotrata 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 degestão de pessoas. Mas a prioridade desse nível é que os gestores sejampreparados para executarem as atividades de gestão de pessoas em seusrespectivos setores;

– nível 3 (definido): Com o intuito de alinhar a força de trabalho aos seusobjetivos de negócio a organização desenvolve uma infraestrutura para servir deapoio aos indivíduos;

– nível 4 (previsível): Através da infraestrutura de desenvolvimento decompetências, a organização quantifica e gerencia a capacidade de sua força detrabalhado e de seus processos;

– nível 5 (em otimização): Os grupos e indivíduos se dedicam na melhoriacontínua de seus métodos de trabalho fazendo com que toda a organização sebeneficie 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 maturidadedo 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 capacidadeda força de trabalho para que possam alcançar seus objetivos. A cada nível de maturidadeas áreas de processo criam um sistema inter-relacionado que transformam a capacidadeda 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 doP-CMM:

O Guia PMBOK e o modelo P-CMM são bastante difundidos em empresas degrande porte. Eles fornecem aos gestores ferramentas e técnicas que os ajudam nacoordenação de equipes. Ultimamente, os chamados métodos ágeis de desenvolvimentode software vêm sendo bastante discutidos por darem mais de flexibilidade na gestão eexecução de projetos e, que ao mesmo tempo podem se adequar em algumas etapas demodelos 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 emUtah, numa estação de esqui, para tentar consolidar seus conhecimentos e experiênciasem 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 estruturarsuas 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 Ágilde Software, contradiz as metodologias ditas tradicionais valorizando: os indivíduos einterações entre eles do que focar no uso cego de processos e ferramentas que namaioria das vezes os engessam; o software em funcionamento sendo mais importanteque a documentação do sistema em si; a colaboração com o cliente em virtude da falsasegurança baseada em rígidos contratos; e, a resposta a mudanças caso o projeto nãosaia como planejado (BECK et al., 2001).

Dos doze princípios do manifesto, nota-se que os seguintes estão relacionados agestã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 emelhore seus processos na busca da eficiência.

Entre várias metodologias ágeis que surgiram antes mesmo do manifesto, sedestacam Scrum e XP que serão explanadas a seguir.

3.1 O Framework Scrum

No artigo chamado The New New Product Development Game, NONAKA eTAKEUCHI (1986) discorrem sobre mudanças nas regras do jogo no desenvolvimentode novos produtos tratando o trabalho de uma forma análoga a um time de rugby onde aequipe deve ser multidisciplinar e auto-organizada trabalhando junta do início ao fim, emconstante interação, para que um processo de desenvolvimento de produto possa emergirdaí.

Em 1995, Ken Schwaber apresentou uma abordagem de desenvolvimento deprodutos chamado Scrum, que é uma jogada realizada após alguma penalização oujogada irregular, baseado no trabalho de Nonaka e Takeuchi (SCHWABER, 1995). Osoito jogadores do time se agrupam para enfrentar o adversário juntos e recuperar a bolado meio do túnel criado pela formação, que é jogada por outro jogador de fora doagrupamento (SCHWABER, 1995).

O framework Scrum pode empregar vários processos ou técnicas com o objetivode que as pessoas tratem e resolvam problemas complexos e adaptativos de formaprodutiva e criativa entregando produtos com o mais alto valor possível (SCHWABER,1995).

Segundo SCHWABER e SUTHERLAND (2011), ele tem seus fundamentos nasteorias empíricas de controle de processo onde o conhecimento é obtido da experiência ede tomada de decisões fundamentadas no que é conhecido, sendo apoiado pelos pilarestransparê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ãovistos 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 emultifuncionais, compostos pelo Product Owner que conhece o negócio e prioriza ositens 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 queserve 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 temposem causar perdas no processo (SCHWABER; SUTHERLAND, 2011).

SCHWABER e SUTHERLAND (2011) relatam que para criar uma rotina ereduzir a necessidade de reuniões não definidas, são utilizados eventos prescritivos queutilizam a inspeção e adaptação para permitir uma transparência minuciosa. Sãoapresentados a seguir:

– Sprint: é uma iteração com time-box de um mês ou menos que deve entregar umproduto potencialmente utilizável.

– Reunião de Planejamento da Sprint: no time-box de oito horas, a Equipe deDesenvolvimento 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 ScrumMaster se reúne com a Equipe de Desenvolvimento para atualizar o status doprojeto fazendo três perguntas para cada um dos membros: O que foi feito no diaanterior? O que será feito hoje? Existe algum problema a ser resolvido? NoScrum, a inspeção do processo é diária.

– Revisão da Sprint: no final de cada Sprint o time e partes interessadas sereúnem, em um time-box de quatro horas, para apresentar o resultado da iteraçãoe, se necessário, adaptar o Backlog do produto. Ela é bastante útil para colherfeedback, promover a motivação e colaboração no time.

– Retrospectiva da Sprint: é uma reunião realizada, em três horas, para inspeçãodo 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 naentrega das funcionalidades e oferecer a oportunidade do Time Scrum de inspecionar eadaptar o processo (SCHWABER; SUTHERLAND, 2011). São apresentados a seguir:

– Backlog do Produto: é uma lista de requisitos ordenados, normalmente, porvalor de retorno de investimento, ou seja, os itens mais importantes para onegócio serão prioritariamente estimados e construídos pela Equipe deDesenvolvimento. Ele é criado sobre a responsabilidade do Product Owner e deforma dinâmica, pois os requisitos do negócio podem mudar a qualquermomento.

– Backlog da Sprint: são os itens, em aberto, priorizados pelo Product Owner quefarã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 produtodeve estar pronto ao final de cada Sprint.

O Scrum realiza o trabalho na camada de gestão de projetos, mas para times dedesenvolvimento de software é necessário uma metodologia que norteie seus membroscom relação a engenharia de software, em nosso caso veremos a Programação Extrema aseguir.

3.2 Programação Extrema

Segundo FOWLER (2005), a XP (eXtreme Programming - XP) nasceu das boas práticasde engenharia de software exercidas pela comunidade da linguagem de programaçãoSmalltalk no final da década de 1980, sendo que Kent Beck e Ward Cunninghampassaram a utilizá-las em seus projetos, adaptando-as para que se tornassem maisorientadas a pessoas.

No início de 1996, Kent Beck foi chamado para reestruturar o projeto da folhade pagamento da empresa Chrysler, optando por jogar tudo o que tinha sido construídofora e dado uma semana de folga para a equipe. Nesse ambiente, foram utilizadas em umgrande projeto as práticas que sustentam a XP (BECK, 2004).

BECK (2004) descreve a Programação Extrema como uma disciplina dedesenvolvimento 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 XPinovadora é: colocar todas as práticas juntas, sob um só teto; garantir que elas sejampraticadas 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 possamtomar as decisões técnicas do projeto trabalhando no que realmente importa, dando omelhor de si para que o software seja desenvolvido da melhor forma possível. E aosclientes e gerentes, que no intervalo de poucas semanas, perceberão suas metasprogredirem com a possibilidade de mudança nas regras do negócio sem causar impactosnegativos 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ãovistos a seguir.

3.2.1 Os valores da XP

Segundo BECK (2004), as sociedades aprenderam a lidar com o problema no qual asmetas individuais de curto prazo frequentemente entram em conflito com metas sociaisde longo prazo, para isso, acabaram criando um grupo de valores a seremcompartilhados.

XP segue o preceito de que para se obter sucesso em equipe, precisamos devalores 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 apresentaindivíduos com habilidades distintas, mas que juntas e coordenadas por um treinadorformam uma equipe coesa e eficiente (BECK, 2004).

De acordo com BECK (2004), os papéis da XP são: programador quedesenvolve em par, guiado a testes projetando o sistema; cliente que toma as decisões denegócio; testador que ajuda na escrita dos testes funcionais; rastreador que cuida dacoleta de dados referentes desempenho do time; treinador que ajuda o time a não desviara 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 efeitospositivos e sucesso para todos envolvidos no projeto.

Entre as práticas da XP, as que enfocam as pessoas são: jogo do planejamentoque força o diálogo entre as áreas de negócio e técnica; programação em pares ondeocorre o compartilhamento de conhecimento do sistema; propriedade coletiva queincentiva todos a estudar e melhorar o sistema; semana de quarenta horas que tentaevitar horas extras de trabalho; cliente presente onde podem ser esclarecidas dúvidas denegó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 queuma prática reforça a outra criando uma sinergia entre elas. Para mais detalhes sobre asprática da XP, consultar (BECK, 2004).

Metodologias ágeis estão bastante difundidas hoje em dia contribuindosignificativamente para o desenvolvimento de software e, principalmente, das pessoasenvolvidas 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 eorientados a plano (ditos tradicionais) consideram cinco fatores pessoais como críticospara o sucesso de um projeto: pessoal onde nos métodos ágeis o cliente faz parte daequipe; 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 valorpara o cliente; comunicação onde métodos ágeis utilizam comunicação direta entreequipe e cliente; gestão da expectativa onde, em métodos ágeis, todos guiam odesenvolvimento 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 precisamoscompreender os problemas que levam projetos a chegarem nesse ponto para então podersolucioná-los.

TURNER e BOEHM (2003) e BROOKS (2009) enfatizam que relacionarhomens e meses em projetos onde há indivíduos que se comuniquem entre si tornar-seperigoso e enganoso. Em qualquer grupo de pessoas que precisem se comunicar, acomplexidade da comunicação pode ser dada por n(n-1)/2, onde n é o número depessoas. Assim, vê-se que em atividades onde a intercomunicação é intensa, porexemplo, a complexidade da comunicação cresce exponencialmente em relação àquantidade de interlocutores. Por exemplo, um projeto com cinco pessoas vai requererdez 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 umprojeto de software atrasado irá atrasá-lo ainda mais” (BROOKS, 2009, p. 24).

COCKBURN (2000) questiona o tratamento das pessoas como recursoshumanos na literatura tradicional de gerência de projetos de software, dizendo que aspessoas acabam virando “componentes” previsíveis, quando, pelo contrário, são pornatureza altamente variáveis e não-lineares.

No entanto, observa-se que grande parte das metodologias tradicionais nãoatentam esse aspecto, se importando principalmente em seguir o planejamento ecronograma, 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ãotemas 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 deprojetos é a de cuidar da motivação das pessoas envolvidas, criando nelas o interessepelo trabalho a ser realizado.

Em uma experiência, na década de 1940, com macacos e um quebra-cabeçamecânico simples, Harry F. Harlow e seus alunos de psicologia na University ofWinsconsin constaram que os macacos descobriram rapidamente como os dispositivosfuncionavam. Isso, sem ao menos os ter ensinado ou recompensado. Analisando o fatode que eles não tinham sido acionados pelo comportamento biológico (comida, água ougratificação sexual) nem por motivações extrínsecas (recompensas e punições), Harlowdeduziu uma terceira motivação, a intrínseca, ou seja, o prazer da tarefa era a própriarecompensa (HARLOW, 1950 apud PINK, 2010, p. 1-3).

PINK (2010) relata duas importantes evoluções ao trabalho de Harlow. Oprimeiro, 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 DouglasMcGregor, 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 quepoderiam 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 externasfuncionam muito bem nas tarefas repetitivas. Entretanto, podem ser devastadoras para otrabalho criativo. Amabile diz que “a motivação intrínseca conduz à criatividade; amotivação extrínseca controladora é prejudicial à criatividade”.

GABARDO e GOMES (2009) reforçam a ideia de que os métodos ágeispromovem 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 osfatores como autonomia, feedback e a habilidade de completar uma tarefa são fatoressignificativos dos métodos ágeis que aumentam a satisfação e motivação dostrabalhadores.

Diversas pesquisas demonstram que aqueles que trabalham em equipes auto-organizadas, como em times ágeis, estão mais satisfeitos do que os que trabalham emequipes já estabelecidas (PARKER, WALL e HACKSON, 1997 apud PINK, 2010, p.93).

CORREA e TANIGUCHI (2009) comentam em seu trabalho que asmetodologias ágeis promovem na equipe o sentimento de que todos estão no controle doprojeto, o qual não pertence à empresa, ao cliente ou a um gerente de projeto, e sim atodos os envolvidos. Desta forma, todos sentem-se mais valorizados e comprometidoscom o objetivo que, ao ser alcançado, motivará ainda mais estes indivíduos em busca deconhecimento e crescimento profissional por meio da adaptação constante empregada noprocesso.

4.2 Métodos tradicionais e ágeis

Segundo FOWLER (2005), os métodos ágeis surgem com as principais características deadaptabilidade e foco nas pessoas, enquanto que os métodos tradicionais objetivam adefinição de processos e execução dos planos com a tentativa de adequar as pessoas aoprocesso, frustrando muitas vezes o desempenho do projeto devido as pessoas seremdifíceis de prever e quantificar.

FOWLER (2005) aponta a aceitação, ao invés da imposição, do processo comoelemento fundamental para se gerenciar um processo orientado a pessoas. Geralmente, aimplantação de processos sofre resistência por parte dos colaboradores pelo fato deserem impostos pela administração da empresa sem ao menos detectarem os reaisproblemas enfrentados no dia a dia. FOWLER (2005) enfatiza que a aceitação de umprocesso requer o comprometimento de toda equipe envolvida no projeto.

Segundo COCKBURN e HIGHSMITH (2001), o projeto é construído dentro deuma cultura organizacional, em um ambiente físico e a partir de pessoas compersonalidades e habilidades diferentes tornando-os um complexo ecossistema, fazendocom que um fator influencie o outro naturalmente. No momento da implantação de umprocesso dentro de um ecossistema, há opções a serem feitas: adequar o ecossistema aoprocesso ou o processo ao ecossistema. Nesse ponto é que os métodos ágeis tentam seadequar 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 produtoou tomada de decisões compartilhadas. TURNER e BOEHM (2003) identificam canaisde comunicação nas práticas ágeis de reunião em pé, programação em par e reuniões deplanejamento como preferência para a colaboração.

CISCON (2009) realiza uma comparação entre as abordagens tradicional e ágilde gerência de projetos referente a pessoas.

Pessoas

Ágil Tradicional

Desenvolvedores Agilidade;

Podem assumir vários papéis;

Alta rotatividade nas equipes dedesenvolvedores;

Conhecimento tácito sobre o domínio doprojeto;

Preferência por desenvolvedores maiscapacitados.

Orientados pelo plano;

Geralmente assumem um único papeldentro do projeto;

Baixa rotatividade dentro da equipe;

Conhecimento formal e documentado;

Sem preferência.

Testadores Testadores trabalham com estreitarelação com os desenvolvedores;

Necessidade de conhecimento emprogramação, a fim de automatizaremos testes;

Abordagem do teste primeiro.

Geralmente os testadores trabalhamseparados dos desenvolvedores;

Conhecimento restrito a área de testes;

Testes alfa, beta e de homologação.

Clientes Clientes on site;

Clientes participam de todo odesenvolvimento;

Cliente contribui na tomada de decisões.

Clientes não muito presentes;

Clientes geralmente não participam detodo o desenvolvimento;

Cliente nem sempre contribui nasdecisões tomadas.

Direção Executiva Confia no trabalho do gerente de projetoe 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 asatividades do projeto;

Alta rotatividade dentro da equipe;

Equipe conhece o estado do trabalho decada membro;

Cliente faz parte da equipe.

Projeto apoiado no gerente de projeto;

Atuação da equipe com papéis claros ebem definidos;

Baixa rotatividade dentro da equipe;

Equipe não conhece o estado do trabalhode cada membro;

Cliente não sabe quem é a equipe.

Será apresentado, a seguir, um estudo de caso sobre um projeto executado commé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 umaparceira da empresa Rational e era especializada em implantação da metodologia dedesenvolvimento RUP (Processo Unificado Rational). Mesmo contando com equipesqualificadas e depois da tentativa de implantação de modelos de qualidade de processoscomo o MPS.BR (modelo de Melhoria de Processos do Software Brasileiro), a empresa

alcançou melhores resultados em termos de estabilidade, satisfação, sustentabilidade erotatividade depois de adotar metodologias ágeis quatro anos depois de sua fundação.

Baseado em entrevistas, é transcrevido a seguir, um estudo de caso sobre oprojeto SIGPAER (Sistema de Gerenciamento Integrado da Prevenção de AcidentesAeronáuticos), iniciado no ano de 2008 e realizado em instituições consideradas rígidascomo as forças armadas, mas que trouxeram a possibilidade de o tradicional conviver emharmonia com novos processos de desenvolvimento de software trazendo um benefíciomú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 deScrum para planejamento e práticas de engenharia de software da XP como testesautomatizados, integração contínua, programação em par, entre outras. É dada maisênfase aos valores ágeis. Como se dissessem aos desenvolvedores: “sigam esses valores efaçam do jeito que acharem melhor”.

Renato Willi, coordenador de projetos, relata que para tranquilizar o cliente nointuito de que ele tivesse a visão de como o software seria desenvolvido não acarretandoriscos contratuais ou prejuízos para eles, era realizado um trabalho de conscientizaçãodas práticas que iriam ser utilizadas no projeto, explicando como e o por que eram feitasde tal maneira. Tudo isso era feito antes de iniciar o projeto e alocação da equipe. Foiimportante repassar que tudo que constava objetivamente no contrato seria atendidopelo 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 dosistema, 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 passosnecessários para um bom desenvolvimento do projeto. Serão evidenciadas apenas asseçõ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 detrabalho, 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 daAeroná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 emconformidade 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 fluxoda 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 alocadasfuturamente no projeto. Os papéis identificados para o projeto foram: um gerente deprojeto; um analista de sistemas; um designer; seis desenvolvedores, sendo quatro daSEA 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 daAeronáutica.

5.1.1.2 Plano de gerenciamento de projeto

Segundo o Guia PMBOK, desenvolver o plano de gerenciamento de projeto é oprocesso de documentação das ações necessárias para definir, preparar, integrar ecoordenar todos os planos auxiliares. É o principal processo de planejamento, pois,integra os demais planos complementando-os, e provavelmente, o processo maisimportante para o gerente de projeto (PMI, 2008).

No contexto da gestão de pessoas, é importante ressaltar os itens do Plano deGerência de Comunicação do SIGPAER:

– Semanalmente, o coordenador de desenvolvimento deveria enviar um e-mail parao gerente e demais interessados, informando o resultado das atividades dasemana anterior, frente aos objetivos nela definidos, e os objetivos da próximasemana.

– Deveria ser criada uma lista de e-mails para centralizar e manter histórico dasmensagens eletrônicas trocadas no ambiente do projeto.

– Os meios de contato dos componentes da equipe deveriam estar centralizados edisponibilizados para todos.

– Uma vez por semana, haveria uma reunião de ponto de controle e objetivos dasemana com toda a equipe. Nela seriam efetuadas avaliações do desenvolvimentodo 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 consideraradequados (telefone, e-mail ou reunião presencial).

– A equipe deveria se reportar ao coordenador de desenvolvimento, e este aogerente de desenvolvimento. Caso as equipes crescessem, cada equipe sereportaria ao seu respectivo coordenador, e este ao coordenador dedesenvolvimento.

– Ao final de cada iteração, o coordenador registraria as lições aprendidas sobrecomunicação na avaliação da iteração e tomaria as medidas corretivas senecessá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 entreExército e Aeronáutica. Cada entidade tinha ramificações do sistema que deveriam sermescladas antes do começo do novo projeto. Para utilização das práticas ágeis, tiveramapoio 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 eferramentas distintas para implementar a sua estrutura, os papéis, eventos e artefatos doScrum 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, comomostrado na Figura 5.

O Product Owner, um Tenente da Aeronáutica, que avaliava e gerenciava oprojeto, levantava um número suficiente de estórias de usuário para a Sprint, depoisentrava em acordo com um Capitão do Exército sobre as funcionalidades paraencaminhá-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 naFigura 6. Isso cria um ambiente no qual o time e o cliente possam interagir de umamaneira que resulte em confiança mútua. O cliente escreve as estórias, pois é ele quemconhece 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 desoftware.

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, semproblemas ou sem dependências decompondo a estória pensando em todas as atividadesaté 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á aestimativa definitiva para a estória. O primeiro Planning Poker do projeto ocorreu eresultou em cinco estórias e vinte e um pontos.

A definição de pronto foi acordada da seguinte maneira: o incremento deveriaestar programado, testado, código-fonte documentado, apresentado e aprovado. Comisso, o próximo passo era estimar as estórias em ordem de prioridade. O tamanho daiteração foi definido em aproximadamente duas semanas, por conta de particularidadesdo expediente e feriados. Seriam dez dias úteis. Foram consideradas três pessoas emtempo integral, já que nem todos eram dedicados exclusivamente ao projeto (não é umaboa prática, mas a realidade era essa). O total era de trinta pontos. Foi considerada umataxa de setenta porcento (70%) de produtividade, que é alta, mas jogar abaixo dissoparecia incômodo para o cliente. A velocidade projetada para a primeira Sprint foi devinte e um pontos para as primeiras duas semanas.

Os cartões de estórias ficavam no quadro, colados com uma massa especial, paraque todos pudessem ter a visão atual do projeto. Devido a equipe não ter conhecimentoprévio do código-fonte do projeto, não havia muita base para estimativas econhecimento sobre a produtividade da mesma. Com isso, o time foi preparadopsicologicamente para errar provavelmente as três primeiras estimativas,fundamentando-se na literatura e experiência prévia de outros projetos. Para não gerarfrustraçõ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 pelocoordenador 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 deusuários.

3 Sequência de números naturais, na qual os primeiros dois termos são 1 e 1, e cada termosubsequente 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 daequipe por gerência ou coaching4. A equipe deve aprender que as reuniões são para elamesma, e deve aprender a se gerenciar.

Na primeira Sprint, foram criados vários testes automatizados e resolvido apenasum cartão de oito pontos, dos vinte e um planejados, como foi previsto na reunião deplanejamento. Esse aprendizado foi motivador para a iteração seguinte e que obteve umresultado muito melhor. Ao final da Sprint, em um dia inteiro foi realizado aapresentação, retrospectiva e reunião de planejamento da próxima Sprint.

Alguns pontos positivos foram destacados na retrospectiva. A criação de testesautomatizados unitários e funcionais utilizando Junit5 e Selenium6, dando à equipecoragem 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 problemasemergiram 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 queadmitiram falta de disponibilidade para cuidar do projeto, ainda não estava sendo geradoum build7 por semana. Também havia outros problemas como falhas de comunicação, ocódigo que não estava documentado a contento, problemas na padronização de nomes eera necessário aumentar a granularidade das estórias para ter a percepção de algo estarficando pronto. Interessante notar positivamente o fator psicológico do prazer em trocaros 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 retrospectivafoi a criação de alguns mantras para que fossem colados no quadro de tarefas para quetodos os dias a equipe pudesse visualizar e lembrar o que deveria melhorar. Exemploscomo: “Vou me comunicar mais”, “Vou documentar mais o código” e outras coisas dogênero. Para os demais, foi definida uma padronização de nomes e anotadas no quadro, eque 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 deoito pontos mais três pontos de tarefas não planejadas mas que foram realizadas naSprint anterior. O coordenador do projeto comenta que só pôde visitar a equipe noquarto dia da iteração e viu, pelo quadro de tarefas, que a equipe já estava acabandotodas 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á estavamapresentando constantemente as funcionalidades, gerando builds semanalmente, os bugseram poucos e estavam sob controle, os problemas de padronização de nomes egranularidade 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 aum objetivo desejado pelo cliente.

5 Framework, criado por Erich Gamma e Kent Beck, com suporte à criação de testes automatizados nalinguagem 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 Figura7 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 oque 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 sabiade nada do código, o time não tinha um ambiente totalmente preparado e estavamtrabalhando no núcleo do sistema. Na segunda iteração, as barreiras iniciais estavamtodas vencidas e o time estava pronto. A simplicidade das funcionalidades tambémcolaborou.

5.1.7 Gerenciamento de expectativasFoi decido alterar a duração da próxima iteração. Isso não é boa prática, mas era precisodiminuir o tempo das reuniões gerenciais relativas ao tempo das iterações. E como nãohavia mais feriados no ano, foi pensando em dar um dia de folga como recompensa sefosse tudo bem. Quinzenalmente o custo disso seria alto. Era desejado também acertar

Figura 7: Quadro de tarefas da segunda Sprintdo projeto

Figura 8: Quadro de tarefas após aretrospectiva da Sprint 2

cada iteração com o mês. Algo próximo da realidade do time. Com isso, a terceira Sprintficou acordada em cinco semanas, a velocidade do time em dez pontos por semana e apriorização com a estimativa em cinquenta pontos.

Na retrospectiva da terceira Sprint, o time admitiu que estava falhando nasreuniões diárias, e que isso estava gerando problemas de comunicação. Observaram queera preciso separar um tempo para os refactorings8 e a documentação no código aindanão estava satisfatória. A parte considerada positiva tinha sido a especificação dos testesfuncionais para aprovação das estórias. Ficou acordado de escrevê-los no verso doscartões, a partir de então.

No planejamento, as estimativas foram bem mais precisas. Todos estavam bemmais conscientes do que deveria ser feito para desenvolver cada estória. Coisas que otime achava ser pequenas foram se mostrando complexas. Foram encontrados diversos“efeitos colaterais” de algumas alterações. Foi considerado modificar novamente umaparte 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 contaminarpor ele. O desafio era em se manterem realistas. O projeto foi indo bem porque aexpectativa 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 complanejamentos meticulosos e previsíveis causando o engessamento de todos osenvolvidos. Geram contratos rígidos para assegurar que suas tarefas sejam executadas ecom penalidades altíssimas caso isso não ocorra. É dada mais importância aos artefatos eferramentas que circundam o projeto levando as pessoas ao desgaste muitas das vezes osdesviando de suas reais competências, que são de entregar produtos com constância equalidade.

O estudo de caso mostrou o projeto exigia uma extensa documentação com oobjetivo de fornecer garantias aos envolvidos, tanto que o desenvolvimento do projetodeveria estar em conformidade com o MPS.BR nível G. Entretanto, Scrum e XP seadequaram aos processos de gestão do projeto e, principalmente, na gestão das pessoascom seus valores, princípios, eventos e práticas. Com isso, as falhas que aconteciam emuma iteração eram mitigadas na próxima, o time e cliente ganhavam mais confiança eautonomia. Com o tempo, podendo ser equiparado ao nível gerenciado do P-CMM, noqual os problemas que contribuem para que as pessoas deixem de executar eficazmentesuas atividades incluem: a) sobrecarga de trabalho; b) distração ambiental; c) objetivosde 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 umatecnologia já obsoleta, tendo o controle como objetivo central e motivadores extrínsecoscomo principais ferramentas. Métodos ágeis distribuem a gestão do projeto entre osenvolvidos de uma maneira organizada e democrática, separando os papéis dosresponsáveis em suas respectivas atribuições resultando, com o tempo, em uma sintonizafina entre cliente, negócios e técnica.

8 Processo de modificar um sistema de software para melhorar a estrutura interna do código semalterar seu comportamento externo.

O estudo de caso mostrou que o projeto foi desenvolvido e implantado em umambiente rígido, como as forças armadas, poderiam ter sido implementados processoscomo RUP, P-CMM ou PMBOK, para gerir o projeto como um todo. Mas devido aexperiência dos colaboradores, principalmente do coordenador e do líder técnico, foipassado ao cliente a garantia de que problemas poderiam a acontecer e que eles seriamresolvidos da melhor forma possível, pois a imprevisibilidade faz parte de qualquerprojeto. 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 grandesempresas, reforçando a importância das pessoas como indivíduos e de desenvolver duascapacidades. O PMBOK também, em seu capítulo sobre gerenciamento de recursoshumanos, discorre sobre equipes pequenas e coesas que obtêm melhor desempenho. Eexistem vários estudos sobre a aderência de métodos ágeis em processos como oMPS.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 humanocomo 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 deJaneiro: Elsevier, 2009.

CISCON, L. Um estudo e uma ferramenta de gerência de projetos comdesenvolvimento ágil de software. Dissertação de Mestrado, UFMG, 2009.

COCKBURN, A. Characterizing people as non-linear, first-order components insoftware 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 emProjetos 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 EngineeringInstitute, 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. NewYork: 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 deDesenvolvimento de Software. Dissertação de Mestrado, UFPE, 2009.

GABARDO, M; GOMES, A. Discussão sobre Motivação de Equipes naImplementação de Métodos Ágeis no Desenvolvimento de Sistemas naAdministração Pública Federal. UCB, 2009.

JOSKO, J. Gestão de Pessoas em Tecnologia da Informação – Uma visãoperspectiva 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. HarvardBusiness 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 fromcomparing agile and plan-driven methods. The Journal of Defense SoftwareEngineering, 2003.