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 [email protected]

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 PCMM, 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 bemsucedido. 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 devese 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. A cada 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:

Figura 1: Áreas de processo do P-CMM (CURTIS et al., 2001, adaptado)

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;

– 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:

Figura 2: A Metodologia Scrum (SCHWABER, 1995, adaptado)

O Scrum promove a integração do time entre seus eventos e artefatos, que serão vistos a seguir.

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

Figura 3: As práticas reforçam umas as outras (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

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 autoorganizadas, 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 Desenvolvedores

Agilidade; Podem assumir vários papéis;

Tradicional Orientados pelo plano; Geralmente assumem um único papel dentro do projeto; de Baixa rotatividade dentro da equipe;

Alta rotatividade nas equipes desenvolvedores; Conhecimento tácito sobre o domínio do Conhecimento formal e documentado; projeto; Preferência por desenvolvedores mais Sem preferência. capacitados. 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;

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 Comprometida com datas de entrega, e na equipe; cronogramas e planos detalhados; Pouco apegada às estimativas. Apegada às estimativas.

Equipe

Projeto apoiado na equipe; Projeto apoiado no gerente de projeto; Atuação colaborativa em todas as Atuação da equipe com papéis claros e atividades do projeto; bem definidos; Alta rotatividade dentro da equipe; Baixa rotatividade dentro da equipe; Equipe conhece o estado do trabalho de Equipe não conhece o estado do trabalho cada membro; de cada membro; Cliente faz parte da equipe. Cliente não sabe quem é a equipe.

Testes alfa, beta e de homologação.

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.

Figura 4: Estrutura organizacional

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.

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

Figura 5: Sprint Planning

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

advindas das estórias, pois ele é quem conhece as técnicas de desenvolvimento de software.

Figura 6: Cartões de estórias do usuário

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.

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

Figura 7: Quadro de tarefas da segunda Sprint do projeto

A Figura 8 mostra o quadro de tarefas após a retrospectiva, depois de limpar o que já estava pronto.

Figura 8: Quadro de retrospectiva da Sprint 2

tarefas

após

a

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

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: . 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: . 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: . 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: . 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 AddisonWesley, 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: . Acesso em: 05/12/2011. SCHWABER, K. SCRUM Development process. OOPSLA’95, Austin, 1995. Disponível em: . Acesso em: 12/12/2010. SILVEIRA, V. et al. Os Modelos de Maturidade e a Gestão de Pessoas: O Modelo PCMM. 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.