SlideShare uma empresa Scribd logo

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

s4nx
s4nx

TCC da especialização: Uma análise sobre gestão de pessoas baseada nos métodos ágeis

1 de 24
Baixar para ler offline
C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO
RECIFE
LUIZ SANCHES
UMA ANÁLISE SOBRE GESTÃO DE PESSOAS BASEADA
NOS MÉTODOS ÁGEIS
Recife
2012
LUIZ SANCHES
UMA ANÁLISE SOBRE GESTÃO DE PESSOAS
BASEADA NOS MÉTODOS ÁGEIS
Artigo apresentado ao programa de
Especialização em Engenharia de Software do
Centro de Estudos e Sistemas Educacionais do
Recife – C.E.S.A.R, como requisito para a
obtenção do título de Especialista em
Engenharia de Software com ênfase em Gestão
Ágil de Projetos.
Orientação: Prof. Felipe Furtado
Coorientação: Renato Willi
Recife
2012
Uma análise sobre gestão de pessoas baseada nos métodos
ágeis
Luiz Sanches
C.E.S.A.R – Centro de Estudos e Sistemas Avançados do Recife
luizsanches@opmbx.org
Resumo. Gerir o capital humano continua sendo o desafio de pequenas e
grandes corporações desde a era industrial, que formulou a base da gestão
tradicional de pessoas e que continua sendo aplicada pelos departamentos de
recursos humanos. Particularmente em empresas de tecnologia, onde a
essência do trabalho é o conhecimento e não a força ou repetição, métodos
ágeis se voltam para o ser humano no objetivo de encontrar maneiras
sustentáveis, envolvendo colaboradores e clientes, para entregar produtos de
qualidade e manter as equipes saudáveis. Nesse contexto, será apresentado
um estudo sobre métodos tradicionais e ágeis com foco em pessoas e um
estudo de caso onde Scrum e XP foram aplicados na gestão de pessoas.
1. Introdução
As pessoas são o maior patrimônio de uma organização de software e representam o seu
capital intelectual. É responsabilidade dos gerentes de software garantir que a
organização obtenha o melhor retorno sobre o investimento em pessoas. O
gerenciamento inadequado de pessoas é uma das mais significativas contribuições para a
falha do projeto (MELNIKOFF et al., 2007).
A gestão de pessoas procura obter o melhor do funcionário enquanto membro da
empresa. O capítulo 9 do PMBOK, que trata sobre gerenciamento dos recursos humanos
do projeto, e o P-CMM (Modelo de Maturidade de Capacitação de Pessoal) do SEI
(Software Engineering Institute) formam uma base sólida de conhecimento para guiar
equipes de desenvolvimento de software quanto à gestão de pessoas.
Métodos ágeis como Scrum e XP, tomam como base a colaboração entre as
pessoas envolvidas no processo para que possam entregar produtos com qualidade e
constância. O uso dos métodos ágeis em equipes de desenvolvimento de software está se
difundindo bastante no meio acadêmico e corporativo e pode ajudar, consideravelmente,
as empresas da área de tecnologia a solucionarem seus problemas relacionados à gestão
de pessoas.
1.1 Objetivos
Este trabalho apresenta uma revisão da literatura sobre gestão de pessoas em equipes de
desenvolvimento de software, bem como, um estudo dos métodos ágeis Scrum e XP
com foco na gestão de pessoas. Ao final, tenta-se evidenciar isto tudo por meio de um
estudo de caso concreto.
O objetivo deste trabalho é mostrar que, a partir dos valores, princípios e práticas
presentes nos métodos ágeis, é possível fazer-se uma gestão adequada de recursos
humanos alinhada às recomendações presentes no PMBOK e P-CMM.
1.2 Justificativa
Os modelos de referência para gestão de pessoas, como o presente no PMBOK e o P-
CMM, muitas vezes são implementados à risca, sem levar-se em consideração aspectos
práticos e do dia a dia da cultura das organizações.
Com isso, colocar-se em prática uma adoção descuidada desses modelos muitas
vezes resulta em sobrecarga e inclusão de burocracias no processo de software. Além
disso, uma cultura corporativa voltada para valorização das pessoas também é
fundamental para uma gestão de pessoas bem sucedida.
Uma forma de ilustrar isso é o fato de muitas empresas que adotam os valores e
princípios ágeis deixarem de se referirem aos membros de suas equipes como mais um
tipo de recurso da empresa como outro qualquer, e tratá-los apenas como pessoas.
A motivação deste trabalho vem da curiosidade de se identificar que impactos a
forma de ver as coisas sob a ótica das metodologias tem sobre aspectos como a gestão
de pessoas.
1.3 Estrutura do Artigo
Este artigo está estruturado como se segue. O capítulo 2 abrange o que é a gestão de
pessoas. O capítulo 3 apresenta e conceitua métodos ágeis. Já o capítulo 4 fala sobre
aprimoramento e desenvolvimento de pessoas. Um estudo de caso mostrando práticas de
gestão de pessoas no contexto de métodos ágeis é apresentado no capítulo 5. E por fim,
no capítulo 6 estão as conclusões deste trabalho.
2. Gestão de pessoas em projetos de software
A maioria dos problemas na área de tecnologia da informação não é de natureza
tecnológica, e sim de natureza sociológica. Ter a última tecnologia ou bugs1
em sua
linguagem de programação não são páreos para problemas de comunicação, falta de
motivação ou desentendimentos (DEMARCO; LISTER, 1999).
FRANÇA (2009) relata que pesquisas recentes demonstram que os profissionais
de engenharia de software estão entre os profissionais mais estressados e desmotivados
e, que os modelos de motivação existentes são excessivamente teóricos e com pouca
aplicabilidade prática, dificultando assim a interpretação e implementação destes modelos
por gerentes de projetos de software.
O gerenciamento eficiente está, portanto, relacionado ao gerenciamento de
pessoas em uma organização. O gerenciamento inadequado de pessoas é uma das mais
significativas contribuições para a falha do projeto (MELNIKOFF et al., 2007).
Segundo MELNIKOFF et al. (2007) existem quatro fatores críticos no
gerenciamento de pessoal:
– consistência, em que as pessoas de uma equipe de projeto devem ser tratadas de
maneira uniforme;
– respeito, que conhece que pessoas diferentes têm habilidades diferentes e os
gerentes devem respeitar essas diferenças;
– inclusão, no qual as pessoas contribuem efetivamente quando sentem que os
outros ouvem e levam em conta suas propostas;
1 É um erro no funcionamento comum de um software ou hardware.
– e honestidade, que prega que, na posição de gerente, deve-se sempre ser honesto
sobre o que vai ou não bem na equipe.
Veremos, a seguir, os modelos de gestão de pessoas baseados no Guia PMBOK e
P-CMM.
2.1 O Guia PMBOK
O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK), criado e
gerido pelo Instituto de Gerenciamento de Projeto (Project Management Institute -
PMI), é utilizado como padrão para gerenciar a maioria dos projetos na maior parte das
vezes em vários tipos de setores da indústria. Ele descreve os processos, ferramentas e
técnicas de gerenciamento de projetos usados até a obtenção de um resultado bem-
sucedido.
Importante frisar que ele, como é uma referência básica, não é abrangente nem
completo. Ele é mais um guia que uma metodologia. É possível usar metodologias e
ferramentas distintas para implementar a sua estrutura.
2.1.1 Gerenciamento de projetos
Segundo o PMI (2008), um projeto é um esforço temporário empreendido para criar um
produto, serviço ou resultado exclusivo. Um projeto pode envolver uma única pessoa,
uma única ou múltiplas unidades organizacionais e, devido à natureza exclusiva dos
projetos, pode haver incertezas quanto aos produtos, serviços ou resultados criados por
ele (PMI, 2008).
Ainda de acordo com o PMI (2008), o gerenciamento de projetos é a aplicação
de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de
atender aos seus requisitos e para gerenciar um projeto deve-se: identificar os requisitos;
adaptar-se às diferentes necessidades, preocupações e expectativas das partes
interessadas à medida que o projeto é planejado e realizado e, balancear as restrições
conflitantes do projeto (escopo, qualidade, cronograma, orçamento, recursos e risco).
O PMI (2008) referencia o gerente de projetos como a pessoa designada pela
organização executora para atingir os objetivos do projeto e garantir que o plano do
mesmo esteja alinhado com o plano do programa central. Compreender e aplicar o
conhecimento, as ferramentas e as técnicas reconhecidas como boas práticas não é
suficiente para um gerenciamento eficaz (PMI, 2008).
Além das habilidades específicas da área e das competências de gerenciamento
geral exigidas, o gerenciamento de projetos eficaz requer que o gerente tenha as
seguintes características (PMI, 2008):
– o conhecimento sobre gerenciamento de projetos;
– desempenhe com eficiência seus conhecimentos em gerenciamento de projetos;
– no lado pessoal, seja efetivo em suas atitudes e tenha capacidade para orientar sua
equipe na obtenção de seus objetivos mantendo o equilíbrio das restrições do
projeto.
2.1.2 Fatores ambientais da empresa
São os fatores internos e externos que influenciam o sucesso do projeto, servindo como
aumento ou restrição das opções de gerenciamento de projetos e influenciam positiva ou
negativamente no resultado do mesmo (PMI, 2008).
Alguns dos fatores ambientais que o PMI (2008) elenca são: cultura, estrutura e
processos organizacionais; normas governamentais ou do setor; infraestrutura; recursos
humanos existentes; administração de pessoal; sistemas de autorização do trabalho da
empresa; canais de comunicação estabelecidos da organização; sistemas de informações
do gerenciamento de projetos.
2.1.3 Gerenciamento dos recursos humanos do projeto
Segundo o PMI (2008), o gerenciamento dos recursos humanos do projeto, que é
coberto no capítulo 9 do Guia PMBOK, inclui os processos que organizam e gerenciam
a equipe do projeto.
A equipe do projeto consiste nas pessoas com papéis e responsabilidades
designadas para a conclusão do projeto. O envolvimento e a participação dos membros
da equipe desde o início agrega seus conhecimentos durante o processo de planejamento
e fortalece o compromisso com o projeto (PMI, 2008).
De acordo com o PMI (2008), o gerenciamento dos recursos humanos do
projeto envolve os processos de:
– desenvolvimento do plano de recursos humanos, onde é identificado e
documentado as funções, responsabilidades, habilidades necessárias e relações
hierárquicas do projeto, além da criação de um plano de gerenciamento do
pessoal;
– mobilização da equipe do projeto, onde ocorre a confirmação da
disponibilidade dos recursos humanos e obtenção da equipe necessária para
concluir as designações do projeto;
– desenvolvimento da equipe do projeto, onde ocorre a melhoria de
competências, interação da equipe e ambiente global da equipe para aprimorar o
desempenho do projeto;
– gerenciamento da equipe do projeto, onde acompanha-se o desempenho de
membros da equipe, fornecendo feedback, resolvendo questões e gerenciando
mudanças para otimizar o desempenho do projeto.
Para que essas tarefas sejam realizadas é necessário a criação da equipe de
gerenciamento de projetos. Para projetos menores, as responsabilidades de
gerenciamento do projeto podem ser compartilhadas por toda a equipe ou administradas
exclusivamente pelo gerente de projetos (PMI, 2008).
O PMI (2008) acrescenta que para gerenciar e liderar a equipe do projeto deve-
se também:
– conhecer, e influenciar quando possível, os fatores de recursos humanos que
podem impactar o projeto, como: o ambiente da equipe, localizações geográficas
dos membros da equipe, comunicações entre as partes interessadas, questões
políticas internas e externas, questões culturais, singularidade organizacional e
outros fatores de pessoal que podem alterar o desempenho do projeto;

Recomendados

Aplicação das abordagens Scrum e XP
Aplicação das abordagens Scrum e XPAplicação das abordagens Scrum e XP
Aplicação das abordagens Scrum e XPs4nx
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Flávio Steffens
 
Comparativo entre Processos Ágeis
Comparativo entre Processos ÁgeisComparativo entre Processos Ágeis
Comparativo entre Processos ÁgeisDaniel Ferreira
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumRaphael Donaire Albino
 
Metodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo RochaMetodologias ágeis de desenvolvimento de software por Givanaldo Rocha
Metodologias ágeis de desenvolvimento de software por Givanaldo RochaFernando Palma
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANFernando Palma
 

Mais conteúdo relacionado

Mais procurados

Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareThiago Reis da Silva
 
METODOLOGIA ÁGIL: Família Crystal de Cockbum
METODOLOGIA ÁGIL: Família Crystal de CockbumMETODOLOGIA ÁGIL: Família Crystal de Cockbum
METODOLOGIA ÁGIL: Família Crystal de Cockbumvanessa finoto
 
Msf microsoft solutions framework - Apresentação
Msf  microsoft solutions framework -  ApresentaçãoMsf  microsoft solutions framework -  Apresentação
Msf microsoft solutions framework - Apresentaçãocesaraks
 
Apresentação Crystal Clear
Apresentação Crystal ClearApresentação Crystal Clear
Apresentação Crystal ClearThiago Sinésio
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixCris Fidelix
 
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...Elisangela Paulino
 
MPS.BR Lições Aprendidas
MPS.BR Lições AprendidasMPS.BR Lições Aprendidas
MPS.BR Lições AprendidasGorio Eduardo
 
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixCris Fidelix
 
Formação de Equipes de Alto Desempenho para Desenvolvimento de Software: O Pa...
Formação de Equipes de Alto Desempenho para Desenvolvimento de Software: O Pa...Formação de Equipes de Alto Desempenho para Desenvolvimento de Software: O Pa...
Formação de Equipes de Alto Desempenho para Desenvolvimento de Software: O Pa...Alejandro Olchik
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Maicon Zerbielli
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Diógenes Almeida
 
Microsoft solutions framework
Microsoft solutions frameworkMicrosoft solutions framework
Microsoft solutions frameworkAlbert José
 
Crystal - Engenharia de Software
Crystal - Engenharia de SoftwareCrystal - Engenharia de Software
Crystal - Engenharia de SoftwareFelipe Bastos
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL Gjrnavarro
 

Mais procurados (20)

Artigo
ArtigoArtigo
Artigo
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
 
Artigo23
Artigo23Artigo23
Artigo23
 
METODOLOGIA ÁGIL: Família Crystal de Cockbum
METODOLOGIA ÁGIL: Família Crystal de CockbumMETODOLOGIA ÁGIL: Família Crystal de Cockbum
METODOLOGIA ÁGIL: Família Crystal de Cockbum
 
Métodos ágeis
Métodos ágeisMétodos ágeis
Métodos ágeis
 
Msf microsoft solutions framework - Apresentação
Msf  microsoft solutions framework -  ApresentaçãoMsf  microsoft solutions framework -  Apresentação
Msf microsoft solutions framework - Apresentação
 
Apresentação Crystal Clear
Apresentação Crystal ClearApresentação Crystal Clear
Apresentação Crystal Clear
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
 
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
 
Metodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de SistemaMetodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de Sistema
 
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
MPS.BR Lições Aprendidas
MPS.BR Lições AprendidasMPS.BR Lições Aprendidas
MPS.BR Lições Aprendidas
 
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
 
Crystal
CrystalCrystal
Crystal
 
Formação de Equipes de Alto Desempenho para Desenvolvimento de Software: O Pa...
Formação de Equipes de Alto Desempenho para Desenvolvimento de Software: O Pa...Formação de Equipes de Alto Desempenho para Desenvolvimento de Software: O Pa...
Formação de Equipes de Alto Desempenho para Desenvolvimento de Software: O Pa...
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
 
Microsoft solutions framework
Microsoft solutions frameworkMicrosoft solutions framework
Microsoft solutions framework
 
Crystal - Engenharia de Software
Crystal - Engenharia de SoftwareCrystal - Engenharia de Software
Crystal - Engenharia de Software
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
 

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

Habilidades e-competencias-em-favor-da-gestao-de-projetos
Habilidades e-competencias-em-favor-da-gestao-de-projetosHabilidades e-competencias-em-favor-da-gestao-de-projetos
Habilidades e-competencias-em-favor-da-gestao-de-projetosHelena Gregório
 
Gerencia deprojeos modulo_1_final_
Gerencia deprojeos modulo_1_final_Gerencia deprojeos modulo_1_final_
Gerencia deprojeos modulo_1_final_Marcelo Aires
 
07 metodologia gerenciamento projetos
07 metodologia gerenciamento projetos07 metodologia gerenciamento projetos
07 metodologia gerenciamento projetosAnderson Mota Dematte
 
Gestão de pessoas e sua aplicação imprescindível junto às metodologias para g...
Gestão de pessoas e sua aplicação imprescindível junto às metodologias para g...Gestão de pessoas e sua aplicação imprescindível junto às metodologias para g...
Gestão de pessoas e sua aplicação imprescindível junto às metodologias para g...Alexandre Zappelloni
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxtrabs52
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxtrabs51
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxtrabs50
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxtrabs53
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxtrabs54
 
Workshop - Como avaliar e planejar competências para um PMO
Workshop - Como avaliar e planejar competências para um PMOWorkshop - Como avaliar e planejar competências para um PMO
Workshop - Como avaliar e planejar competências para um PMOPaulo Campos PMP/PMO-CP/SMAC/SPOC
 
Gestão e Liderança de Pessoas - Aulas 13 e 14
Gestão e Liderança de Pessoas - Aulas 13 e 14Gestão e Liderança de Pessoas - Aulas 13 e 14
Gestão e Liderança de Pessoas - Aulas 13 e 14Wandick Rocha de Aquino
 
Como medir-a-eficacia-dos-programas-de-treinamento-e-desenvolvimento
Como medir-a-eficacia-dos-programas-de-treinamento-e-desenvolvimentoComo medir-a-eficacia-dos-programas-de-treinamento-e-desenvolvimento
Como medir-a-eficacia-dos-programas-de-treinamento-e-desenvolvimentoNegrao Alexandre
 
Apresentação Competência de gestores de projeto.pdf
Apresentação Competência de gestores de projeto.pdfApresentação Competência de gestores de projeto.pdf
Apresentação Competência de gestores de projeto.pdfssuser8451c6
 
Artigo - Implantação do escritório de projetos - Aragon salvador
Artigo - Implantação do escritório de projetos - Aragon salvadorArtigo - Implantação do escritório de projetos - Aragon salvador
Artigo - Implantação do escritório de projetos - Aragon salvadorAragon Vieira
 

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

Habilidades e-competencias-em-favor-da-gestao-de-projetos
Habilidades e-competencias-em-favor-da-gestao-de-projetosHabilidades e-competencias-em-favor-da-gestao-de-projetos
Habilidades e-competencias-em-favor-da-gestao-de-projetos
 
Gestão de projetos
Gestão de projetosGestão de projetos
Gestão de projetos
 
Mr10
Mr10Mr10
Mr10
 
Gerencia deprojeos modulo_1_final_
Gerencia deprojeos modulo_1_final_Gerencia deprojeos modulo_1_final_
Gerencia deprojeos modulo_1_final_
 
Project Methodologies and Best Practices
Project Methodologies and Best PracticesProject Methodologies and Best Practices
Project Methodologies and Best Practices
 
07 metodologia gerenciamento projetos
07 metodologia gerenciamento projetos07 metodologia gerenciamento projetos
07 metodologia gerenciamento projetos
 
Gestão de pessoas e sua aplicação imprescindível junto às metodologias para g...
Gestão de pessoas e sua aplicação imprescindível junto às metodologias para g...Gestão de pessoas e sua aplicação imprescindível junto às metodologias para g...
Gestão de pessoas e sua aplicação imprescindível junto às metodologias para g...
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docx
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docx
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docx
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docx
 
Atividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docxAtividade 1 - Gestão de Pessoas.docx
Atividade 1 - Gestão de Pessoas.docx
 
Artigo daniel lopes_da_silva
Artigo daniel lopes_da_silvaArtigo daniel lopes_da_silva
Artigo daniel lopes_da_silva
 
04 sintese2
04  sintese204  sintese2
04 sintese2
 
Workshop - Como avaliar e planejar competências para um PMO
Workshop - Como avaliar e planejar competências para um PMOWorkshop - Como avaliar e planejar competências para um PMO
Workshop - Como avaliar e planejar competências para um PMO
 
Gestão e Liderança de Pessoas - Aulas 13 e 14
Gestão e Liderança de Pessoas - Aulas 13 e 14Gestão e Liderança de Pessoas - Aulas 13 e 14
Gestão e Liderança de Pessoas - Aulas 13 e 14
 
Projetos
ProjetosProjetos
Projetos
 
Como medir-a-eficacia-dos-programas-de-treinamento-e-desenvolvimento
Como medir-a-eficacia-dos-programas-de-treinamento-e-desenvolvimentoComo medir-a-eficacia-dos-programas-de-treinamento-e-desenvolvimento
Como medir-a-eficacia-dos-programas-de-treinamento-e-desenvolvimento
 
Apresentação Competência de gestores de projeto.pdf
Apresentação Competência de gestores de projeto.pdfApresentação Competência de gestores de projeto.pdf
Apresentação Competência de gestores de projeto.pdf
 
Artigo - Implantação do escritório de projetos - Aragon salvador
Artigo - Implantação do escritório de projetos - Aragon salvadorArtigo - Implantação do escritório de projetos - Aragon salvador
Artigo - Implantação do escritório de projetos - Aragon salvador
 

Mais de s4nx

Pra não dizer que não falei de devops
Pra não dizer que não falei de devopsPra não dizer que não falei de devops
Pra não dizer que não falei de devopss4nx
 
Além das big techs
Além das big techsAlém das big techs
Além das big techss4nx
 
Alem do google
Alem do googleAlem do google
Alem do googles4nx
 
Trabalhe de onde você quiser
Trabalhe de onde você quiserTrabalhe de onde você quiser
Trabalhe de onde você quisers4nx
 
Jenkins, o CI ao seu dispor
Jenkins, o CI ao seu disporJenkins, o CI ao seu dispor
Jenkins, o CI ao seu dispors4nx
 
Manifeste-se!
Manifeste-se!Manifeste-se!
Manifeste-se!s4nx
 
Entregando software com DevOps Tools
Entregando software com DevOps ToolsEntregando software com DevOps Tools
Entregando software com DevOps Toolss4nx
 
Explicando DevOps
Explicando DevOpsExplicando DevOps
Explicando DevOpss4nx
 
Migrando de Shell para Ruby script
Migrando de Shell para Ruby scriptMigrando de Shell para Ruby script
Migrando de Shell para Ruby scripts4nx
 
Técnicas e ferramentas para manter a sanidade em uma startup
Técnicas e ferramentas para manter a sanidade em uma startupTécnicas e ferramentas para manter a sanidade em uma startup
Técnicas e ferramentas para manter a sanidade em uma startups4nx
 
Como manter um Ambiente Sustentável em Times Ágeis
Como manter um Ambiente Sustentável em Times ÁgeisComo manter um Ambiente Sustentável em Times Ágeis
Como manter um Ambiente Sustentável em Times Ágeiss4nx
 
Sistemas Operacionais *nix
Sistemas Operacionais *nixSistemas Operacionais *nix
Sistemas Operacionais *nixs4nx
 
Desenvolvimento de produtos web com ruby on rails
Desenvolvimento de produtos web com ruby on railsDesenvolvimento de produtos web com ruby on rails
Desenvolvimento de produtos web com ruby on railss4nx
 
A linguagem Ruby e o framework Rails
A linguagem Ruby e o framework RailsA linguagem Ruby e o framework Rails
A linguagem Ruby e o framework Railss4nx
 
Compartilhe!
Compartilhe!Compartilhe!
Compartilhe!s4nx
 
Ruby and Rails for womens
Ruby and Rails for womensRuby and Rails for womens
Ruby and Rails for womenss4nx
 
Mais humano que exato
Mais humano que exatoMais humano que exato
Mais humano que exatos4nx
 
Ruby e Rails
Ruby e RailsRuby e Rails
Ruby e Railss4nx
 
Bem antes de 2001
Bem antes de 2001Bem antes de 2001
Bem antes de 2001s4nx
 
Seja burro e preguiçoso! v2
Seja burro e preguiçoso! v2Seja burro e preguiçoso! v2
Seja burro e preguiçoso! v2s4nx
 

Mais de s4nx (20)

Pra não dizer que não falei de devops
Pra não dizer que não falei de devopsPra não dizer que não falei de devops
Pra não dizer que não falei de devops
 
Além das big techs
Além das big techsAlém das big techs
Além das big techs
 
Alem do google
Alem do googleAlem do google
Alem do google
 
Trabalhe de onde você quiser
Trabalhe de onde você quiserTrabalhe de onde você quiser
Trabalhe de onde você quiser
 
Jenkins, o CI ao seu dispor
Jenkins, o CI ao seu disporJenkins, o CI ao seu dispor
Jenkins, o CI ao seu dispor
 
Manifeste-se!
Manifeste-se!Manifeste-se!
Manifeste-se!
 
Entregando software com DevOps Tools
Entregando software com DevOps ToolsEntregando software com DevOps Tools
Entregando software com DevOps Tools
 
Explicando DevOps
Explicando DevOpsExplicando DevOps
Explicando DevOps
 
Migrando de Shell para Ruby script
Migrando de Shell para Ruby scriptMigrando de Shell para Ruby script
Migrando de Shell para Ruby script
 
Técnicas e ferramentas para manter a sanidade em uma startup
Técnicas e ferramentas para manter a sanidade em uma startupTécnicas e ferramentas para manter a sanidade em uma startup
Técnicas e ferramentas para manter a sanidade em uma startup
 
Como manter um Ambiente Sustentável em Times Ágeis
Como manter um Ambiente Sustentável em Times ÁgeisComo manter um Ambiente Sustentável em Times Ágeis
Como manter um Ambiente Sustentável em Times Ágeis
 
Sistemas Operacionais *nix
Sistemas Operacionais *nixSistemas Operacionais *nix
Sistemas Operacionais *nix
 
Desenvolvimento de produtos web com ruby on rails
Desenvolvimento de produtos web com ruby on railsDesenvolvimento de produtos web com ruby on rails
Desenvolvimento de produtos web com ruby on rails
 
A linguagem Ruby e o framework Rails
A linguagem Ruby e o framework RailsA linguagem Ruby e o framework Rails
A linguagem Ruby e o framework Rails
 
Compartilhe!
Compartilhe!Compartilhe!
Compartilhe!
 
Ruby and Rails for womens
Ruby and Rails for womensRuby and Rails for womens
Ruby and Rails for womens
 
Mais humano que exato
Mais humano que exatoMais humano que exato
Mais humano que exato
 
Ruby e Rails
Ruby e RailsRuby e Rails
Ruby e Rails
 
Bem antes de 2001
Bem antes de 2001Bem antes de 2001
Bem antes de 2001
 
Seja burro e preguiçoso! v2
Seja burro e preguiçoso! v2Seja burro e preguiçoso! v2
Seja burro e preguiçoso! v2
 

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

  • 1. 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
  • 2. 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
  • 3. Uma análise sobre gestão de pessoas baseada nos métodos ágeis Luiz Sanches C.E.S.A.R – Centro de Estudos e Sistemas Avançados do Recife luizsanches@opmbx.org Resumo. Gerir o capital humano continua sendo o desafio de pequenas e grandes corporações desde a era industrial, que formulou a base da gestão tradicional de pessoas e que continua sendo aplicada pelos departamentos de recursos humanos. Particularmente em empresas de tecnologia, onde a essência do trabalho é o conhecimento e não a força ou repetição, métodos ágeis se voltam para o ser humano no objetivo de encontrar maneiras sustentáveis, envolvendo colaboradores e clientes, para entregar produtos de qualidade e manter as equipes saudáveis. Nesse contexto, será apresentado um estudo sobre métodos tradicionais e ágeis com foco em pessoas e um estudo de caso onde Scrum e XP foram aplicados na gestão de pessoas. 1. Introdução As pessoas são o maior patrimônio de uma organização de software e representam o seu capital intelectual. É responsabilidade dos gerentes de software garantir que a organização obtenha o melhor retorno sobre o investimento em pessoas. O gerenciamento inadequado de pessoas é uma das mais significativas contribuições para a falha do projeto (MELNIKOFF et al., 2007). A gestão de pessoas procura obter o melhor do funcionário enquanto membro da empresa. O capítulo 9 do PMBOK, que trata sobre gerenciamento dos recursos humanos do projeto, e o P-CMM (Modelo de Maturidade de Capacitação de Pessoal) do SEI (Software Engineering Institute) formam uma base sólida de conhecimento para guiar equipes de desenvolvimento de software quanto à gestão de pessoas. Métodos ágeis como Scrum e XP, tomam como base a colaboração entre as pessoas envolvidas no processo para que possam entregar produtos com qualidade e constância. O uso dos métodos ágeis em equipes de desenvolvimento de software está se difundindo bastante no meio acadêmico e corporativo e pode ajudar, consideravelmente, as empresas da área de tecnologia a solucionarem seus problemas relacionados à gestão de pessoas. 1.1 Objetivos Este trabalho apresenta uma revisão da literatura sobre gestão de pessoas em equipes de desenvolvimento de software, bem como, um estudo dos métodos ágeis Scrum e XP com foco na gestão de pessoas. Ao final, tenta-se evidenciar isto tudo por meio de um estudo de caso concreto. O objetivo deste trabalho é mostrar que, a partir dos valores, princípios e práticas presentes nos métodos ágeis, é possível fazer-se uma gestão adequada de recursos humanos alinhada às recomendações presentes no PMBOK e P-CMM.
  • 4. 1.2 Justificativa Os modelos de referência para gestão de pessoas, como o presente no PMBOK e o P- CMM, muitas vezes são implementados à risca, sem levar-se em consideração aspectos práticos e do dia a dia da cultura das organizações. Com isso, colocar-se em prática uma adoção descuidada desses modelos muitas vezes resulta em sobrecarga e inclusão de burocracias no processo de software. Além disso, uma cultura corporativa voltada para valorização das pessoas também é fundamental para uma gestão de pessoas bem sucedida. Uma forma de ilustrar isso é o fato de muitas empresas que adotam os valores e princípios ágeis deixarem de se referirem aos membros de suas equipes como mais um tipo de recurso da empresa como outro qualquer, e tratá-los apenas como pessoas. A motivação deste trabalho vem da curiosidade de se identificar que impactos a forma de ver as coisas sob a ótica das metodologias tem sobre aspectos como a gestão de pessoas. 1.3 Estrutura do Artigo Este artigo está estruturado como se segue. O capítulo 2 abrange o que é a gestão de pessoas. O capítulo 3 apresenta e conceitua métodos ágeis. Já o capítulo 4 fala sobre aprimoramento e desenvolvimento de pessoas. Um estudo de caso mostrando práticas de gestão de pessoas no contexto de métodos ágeis é apresentado no capítulo 5. E por fim, no capítulo 6 estão as conclusões deste trabalho. 2. Gestão de pessoas em projetos de software A maioria dos problemas na área de tecnologia da informação não é de natureza tecnológica, e sim de natureza sociológica. Ter a última tecnologia ou bugs1 em sua linguagem de programação não são páreos para problemas de comunicação, falta de motivação ou desentendimentos (DEMARCO; LISTER, 1999). FRANÇA (2009) relata que pesquisas recentes demonstram que os profissionais de engenharia de software estão entre os profissionais mais estressados e desmotivados e, que os modelos de motivação existentes são excessivamente teóricos e com pouca aplicabilidade prática, dificultando assim a interpretação e implementação destes modelos por gerentes de projetos de software. O gerenciamento eficiente está, portanto, relacionado ao gerenciamento de pessoas em uma organização. O gerenciamento inadequado de pessoas é uma das mais significativas contribuições para a falha do projeto (MELNIKOFF et al., 2007). Segundo MELNIKOFF et al. (2007) existem quatro fatores críticos no gerenciamento de pessoal: – consistência, em que as pessoas de uma equipe de projeto devem ser tratadas de maneira uniforme; – respeito, que conhece que pessoas diferentes têm habilidades diferentes e os gerentes devem respeitar essas diferenças; – inclusão, no qual as pessoas contribuem efetivamente quando sentem que os outros ouvem e levam em conta suas propostas; 1 É um erro no funcionamento comum de um software ou hardware.
  • 5. – e honestidade, que prega que, na posição de gerente, deve-se sempre ser honesto sobre o que vai ou não bem na equipe. Veremos, a seguir, os modelos de gestão de pessoas baseados no Guia PMBOK e P-CMM. 2.1 O Guia PMBOK O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK), criado e gerido pelo Instituto de Gerenciamento de Projeto (Project Management Institute - PMI), é utilizado como padrão para gerenciar a maioria dos projetos na maior parte das vezes em vários tipos de setores da indústria. Ele descreve os processos, ferramentas e técnicas de gerenciamento de projetos usados até a obtenção de um resultado bem- sucedido. Importante frisar que ele, como é uma referência básica, não é abrangente nem completo. Ele é mais um guia que uma metodologia. É possível usar metodologias e ferramentas distintas para implementar a sua estrutura. 2.1.1 Gerenciamento de projetos Segundo o PMI (2008), um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Um projeto pode envolver uma única pessoa, uma única ou múltiplas unidades organizacionais e, devido à natureza exclusiva dos projetos, pode haver incertezas quanto aos produtos, serviços ou resultados criados por ele (PMI, 2008). Ainda de acordo com o PMI (2008), o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos e para gerenciar um projeto deve-se: identificar os requisitos; adaptar-se às diferentes necessidades, preocupações e expectativas das partes interessadas à medida que o projeto é planejado e realizado e, balancear as restrições conflitantes do projeto (escopo, qualidade, cronograma, orçamento, recursos e risco). O PMI (2008) referencia o gerente de projetos como a pessoa designada pela organização executora para atingir os objetivos do projeto e garantir que o plano do mesmo esteja alinhado com o plano do programa central. Compreender e aplicar o conhecimento, as ferramentas e as técnicas reconhecidas como boas práticas não é suficiente para um gerenciamento eficaz (PMI, 2008). Além das habilidades específicas da área e das competências de gerenciamento geral exigidas, o gerenciamento de projetos eficaz requer que o gerente tenha as seguintes características (PMI, 2008): – o conhecimento sobre gerenciamento de projetos; – desempenhe com eficiência seus conhecimentos em gerenciamento de projetos; – no lado pessoal, seja efetivo em suas atitudes e tenha capacidade para orientar sua equipe na obtenção de seus objetivos mantendo o equilíbrio das restrições do projeto.
  • 6. 2.1.2 Fatores ambientais da empresa São os fatores internos e externos que influenciam o sucesso do projeto, servindo como aumento ou restrição das opções de gerenciamento de projetos e influenciam positiva ou negativamente no resultado do mesmo (PMI, 2008). Alguns dos fatores ambientais que o PMI (2008) elenca são: cultura, estrutura e processos organizacionais; normas governamentais ou do setor; infraestrutura; recursos humanos existentes; administração de pessoal; sistemas de autorização do trabalho da empresa; canais de comunicação estabelecidos da organização; sistemas de informações do gerenciamento de projetos. 2.1.3 Gerenciamento dos recursos humanos do projeto Segundo o PMI (2008), o gerenciamento dos recursos humanos do projeto, que é coberto no capítulo 9 do Guia PMBOK, inclui os processos que organizam e gerenciam a equipe do projeto. A equipe do projeto consiste nas pessoas com papéis e responsabilidades designadas para a conclusão do projeto. O envolvimento e a participação dos membros da equipe desde o início agrega seus conhecimentos durante o processo de planejamento e fortalece o compromisso com o projeto (PMI, 2008). De acordo com o PMI (2008), o gerenciamento dos recursos humanos do projeto envolve os processos de: – desenvolvimento do plano de recursos humanos, onde é identificado e documentado as funções, responsabilidades, habilidades necessárias e relações hierárquicas do projeto, além da criação de um plano de gerenciamento do pessoal; – mobilização da equipe do projeto, onde ocorre a confirmação da disponibilidade dos recursos humanos e obtenção da equipe necessária para concluir as designações do projeto; – desenvolvimento da equipe do projeto, onde ocorre a melhoria de competências, interação da equipe e ambiente global da equipe para aprimorar o desempenho do projeto; – gerenciamento da equipe do projeto, onde acompanha-se o desempenho de membros da equipe, fornecendo feedback, resolvendo questões e gerenciando mudanças para otimizar o desempenho do projeto. Para que essas tarefas sejam realizadas é necessário a criação da equipe de gerenciamento de projetos. Para projetos menores, as responsabilidades de gerenciamento do projeto podem ser compartilhadas por toda a equipe ou administradas exclusivamente pelo gerente de projetos (PMI, 2008). O PMI (2008) acrescenta que para gerenciar e liderar a equipe do projeto deve- se também: – conhecer, e influenciar quando possível, os fatores de recursos humanos que podem impactar o projeto, como: o ambiente da equipe, localizações geográficas dos membros da equipe, comunicações entre as partes interessadas, questões políticas internas e externas, questões culturais, singularidade organizacional e outros fatores de pessoal que podem alterar o desempenho do projeto;
  • 7. – 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
  • 8. práticas relacionadas que devem ser executadas em conjunto para aumentar a capacidade da força de trabalho para que possam alcançar seus objetivos. Acada nível de maturidade as áreas de processo criam um sistema inter-relacionado que transformam a capacidade da organização para o gerenciamento de sua força de trabalho (CURTIS et al., 2001). A Figura 1 apresenta as áreas de processo dentro de cada nível de maturidade do P-CMM: O Guia PMBOK e o modelo P-CMM são bastante difundidos em empresas de grande porte. Eles fornecem aos gestores ferramentas e técnicas que os ajudam na coordenação de equipes. Ultimamente, os chamados métodos ágeis de desenvolvimento de software vêm sendo bastante discutidos por darem mais de flexibilidade na gestão e execução de projetos e, que ao mesmo tempo podem se adequar em algumas etapas de modelos conhecidos como tradicionais. Serão vistos a seguir, os métodos Scrum e XP. 3. Métodos ágeis Em fevereiro de 2001, dezessete renomados engenheiros de software se reuniram em Utah, numa estação de esqui, para tentar consolidar seus conhecimentos e experiências em uma nova metodologia que fosse na contramão da engenharia de software tradicional. No final do encontro, eles chegaram à conclusão de que a melhor forma de estruturar suas ideias seria na criação de um manifesto com seus valores e princípios (BECK et al., 2001). O documento gerado nesse encontro, o Manifesto para Desenvolvimento Ágil de Software, contradiz as metodologias ditas tradicionais valorizando: os indivíduos e interações entre eles do que focar no uso cego de processos e ferramentas que na maioria das vezes os engessam; o software em funcionamento sendo mais importante que a documentação do sistema em si; a colaboração com o cliente em virtude da falsa segurança baseada em rígidos contratos; e, a resposta a mudanças caso o projeto não saia como planejado (BECK et al., 2001). Dos doze princípios do manifesto, nota-se que os seguintes estão relacionados a gestão de pessoas: – as pessoas de negócio e desenvolvimento devem trabalhar juntas; – construa projetos em torno de indivíduos motivados; Figura 1: Áreas de processo do P-CMM (CURTIS et al., 2001, adaptado)
  • 9. – transmissão de informação através de conversa face a face; – incentivo de que a equipe obtenha a auto-organização e que a mesma reflita e melhore seus processos na busca da eficiência. Entre várias metodologias ágeis que surgiram antes mesmo do manifesto, se destacam Scrum e XP que serão explanadas a seguir. 3.1 O Framework Scrum No artigo chamado The New New Product Development Game, NONAKA e TAKEUCHI (1986) discorrem sobre mudanças nas regras do jogo no desenvolvimento de novos produtos tratando o trabalho de uma forma análoga a um time de rugby onde a equipe deve ser multidisciplinar e auto-organizada trabalhando junta do início ao fim, em constante interação, para que um processo de desenvolvimento de produto possa emergir daí. Em 1995, Ken Schwaber apresentou uma abordagem de desenvolvimento de produtos chamado Scrum, que é uma jogada realizada após alguma penalização ou jogada irregular, baseado no trabalho de Nonaka e Takeuchi (SCHWABER, 1995). Os oito jogadores do time se agrupam para enfrentar o adversário juntos e recuperar a bola do meio do túnel criado pela formação, que é jogada por outro jogador de fora do agrupamento (SCHWABER, 1995). O framework Scrum pode empregar vários processos ou técnicas com o objetivo de que as pessoas tratem e resolvam problemas complexos e adaptativos de forma produtiva e criativa entregando produtos com o mais alto valor possível (SCHWABER, 1995). Segundo SCHWABER e SUTHERLAND (2011), ele tem seus fundamentos nas teorias empíricas de controle de processo onde o conhecimento é obtido da experiência e de tomada de decisões fundamentadas no que é conhecido, sendo apoiado pelos pilares transparência, inspeção e adaptação. Para aprimorar a previsibilidade e controlar riscos, emprega uma abordagem iterativa e incremental (SCHWABER; SUTHERLAND, 2011). A Figura 2 apresenta o processo idealizado por Schwaber em 1995: O Scrum promove a integração do time entre seus eventos e artefatos, que serão vistos a seguir. Figura 2: A Metodologia Scrum (SCHWABER, 1995, adaptado)
  • 10. 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.
  • 11. – 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).
  • 12. 3.2.2 Os papéis da XP Os papéis da XP foram pensados analogamente a um time esportivo que apresenta indivíduos com habilidades distintas, mas que juntas e coordenadas por um treinador formam uma equipe coesa e eficiente (BECK, 2004). De acordo com BECK (2004), os papéis da XP são: programador que desenvolve em par, guiado a testes projetando o sistema; cliente que toma as decisões de negócio; testador que ajuda na escrita dos testes funcionais; rastreador que cuida da coleta de dados referentes desempenho do time; treinador que ajuda o time a não desviar a atenção. 3.2.3 As práticas da XP De acordo com BECK (2004), o uso de práticas simples, muitas delas bem antigas, combinadas sistematicamente e seguidas pela equipe com disciplina podem trazer efeitos positivos e sucesso para todos envolvidos no projeto. Entre as práticas da XP, as que enfocam as pessoas são: jogo do planejamento que força o diálogo entre as áreas de negócio e técnica; programação em pares onde ocorre o compartilhamento de conhecimento do sistema; propriedade coletiva que incentiva todos a estudar e melhorar o sistema; semana de quarenta horas que tenta evitar horas extras de trabalho; cliente presente onde podem ser esclarecidas dúvidas de negócios com a equipe técnica o mais rápido possível (BECK, 2004). Para BECK (2004), cada prática por si só não se sustenta, a Figura 3 mostra que uma prática reforça a outra criando uma sinergia entre elas. Para mais detalhes sobre as prática da XP, consultar (BECK, 2004). Metodologias ágeis estão bastante difundidas hoje em dia contribuindo significativamente para o desenvolvimento de software e, principalmente, das pessoas envolvidas no processo, conforme tratado no próximo capítulo. 4. Desenvolvimento de pessoas Um estudo realizado por TURNER e BOEHM (2003) comparando métodos ágeis e orientados a plano (ditos tradicionais) consideram cinco fatores pessoais como críticos para o sucesso de um projeto: pessoal onde nos métodos ágeis o cliente faz parte da equipe; cultura indicando que métodos ágeis criam um ambiente confortável; valores Figura 3: As práticas reforçam umas as outras (BECK, 2004)
  • 13. 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
  • 14. para o mundo dos negócios, reforçando que as pessoas têm outros impulsos que poderiam beneficiar os negócios se gestores e lideres empresariais os respeitassem. Um pouco mais tarde, Teresa Amabile (AMABILE, 1996 apud PINK, 2010, p. 26), da Havard Business School, verificou que recompensas e punições externas funcionam muito bem nas tarefas repetitivas. Entretanto, podem ser devastadoras para o trabalho criativo. Amabile diz que “a motivação intrínseca conduz à criatividade; a motivação extrínseca controladora é prejudicial à criatividade”. GABARDO e GOMES (2009) reforçam a ideia de que os métodos ágeis promovem a autonomia das equipes e favorecem a motivação dos colaboradores. E em (Tessem, et al., 2007 apud GABARDO; GOMES, 2009, p. 9-10) é mostrado que os fatores como autonomia, feedback e a habilidade de completar uma tarefa são fatores significativos dos métodos ágeis que aumentam a satisfação e motivação dos trabalhadores. Diversas pesquisas demonstram que aqueles que trabalham em equipes auto- organizadas, como em times ágeis, estão mais satisfeitos do que os que trabalham em equipes já estabelecidas (PARKER, WALL e HACKSON, 1997 apud PINK, 2010, p. 93). CORREA e TANIGUCHI (2009) comentam em seu trabalho que as metodologias ágeis promovem na equipe o sentimento de que todos estão no controle do projeto, o qual não pertence à empresa, ao cliente ou a um gerente de projeto, e sim a todos os envolvidos. Desta forma, todos sentem-se mais valorizados e comprometidos com o objetivo que, ao ser alcançado, motivará ainda mais estes indivíduos em busca de conhecimento e crescimento profissional por meio da adaptação constante empregada no processo. 4.2 Métodos tradicionais e ágeis Segundo FOWLER (2005), os métodos ágeis surgem com as principais características de adaptabilidade e foco nas pessoas, enquanto que os métodos tradicionais objetivam a definição de processos e execução dos planos com a tentativa de adequar as pessoas ao processo, frustrando muitas vezes o desempenho do projeto devido as pessoas serem difíceis de prever e quantificar. FOWLER (2005) aponta a aceitação, ao invés da imposição, do processo como elemento fundamental para se gerenciar um processo orientado a pessoas. Geralmente, a implantação de processos sofre resistência por parte dos colaboradores pelo fato de serem impostos pela administração da empresa sem ao menos detectarem os reais problemas enfrentados no dia a dia. FOWLER (2005) enfatiza que a aceitação de um processo requer o comprometimento de toda equipe envolvida no projeto. Segundo COCKBURN e HIGHSMITH (2001), o projeto é construído dentro de uma cultura organizacional, em um ambiente físico e a partir de pessoas com personalidades e habilidades diferentes tornando-os um complexo ecossistema, fazendo com que um fator influencie o outro naturalmente. No momento da implantação de um processo dentro de um ecossistema, há opções a serem feitas: adequar o ecossistema ao processo ou o processo ao ecossistema. Nesse ponto é que os métodos ágeis tentam se adequar ao ambiente e não o contrário. COCKBURN e HIGHSMITH (2001) distinguem a colaboração da comunicação, sendo que ao se comunicar há ocorrência apenas da emissão e recepção de informação.
  • 15. Já com a colaboração ocorre um trabalho em conjunto para elaboração de um produto ou tomada de decisões compartilhadas. TURNER e BOEHM (2003) identificam canais de comunicação nas práticas ágeis de reunião em pé, programação em par e reuniões de planejamento como preferência para a colaboração. CISCON (2009) realiza uma comparação entre as abordagens tradicional e ágil de gerência de projetos referente a pessoas. Pessoas Ágil Tradicional Desenvolvedores Agilidade; Podem assumir vários papéis; Alta rotatividade nas equipes de desenvolvedores; Conhecimento tácito sobre o domínio do projeto; Preferência por desenvolvedores mais capacitados. Orientados pelo plano; Geralmente assumem um único papel dentro do projeto; Baixa rotatividade dentro da equipe; Conhecimento formal e documentado; Sem preferência. Testadores Testadores trabalham com estreita relação com os desenvolvedores; Necessidade de conhecimento em programação, a fim de automatizarem os testes; Abordagem do teste primeiro. Geralmente os testadores trabalham separados dos desenvolvedores; Conhecimento restrito a área de testes; Testes alfa, beta e de homologação. Clientes Clientes on site; Clientes participam de todo o desenvolvimento; Cliente contribui na tomada de decisões. Clientes não muito presentes; Clientes geralmente não participam de todo o desenvolvimento; Cliente nem sempre contribui nas decisões tomadas. Direção Executiva Confia no trabalho do gerente de projeto e na equipe; Pouco apegada às estimativas. Comprometida com datas de entrega, cronogramas e planos detalhados; Apegada às estimativas. Equipe Projeto apoiado na equipe; Atuação colaborativa em todas as atividades do projeto; Alta rotatividade dentro da equipe; Equipe conhece o estado do trabalho de cada membro; Cliente faz parte da equipe. Projeto apoiado no gerente de projeto; Atuação da equipe com papéis claros e bem definidos; Baixa rotatividade dentro da equipe; Equipe não conhece o estado do trabalho de cada membro; Cliente não sabe quem é a equipe. Será apresentado, a seguir, um estudo de caso sobre um projeto executado com métodos ágeis e que foi realizado em um órgão militar. 5. Estudo de caso: práticas de gestão de pessoas no contexto de métodos ágeis A empresa SEA Tecnologia, sediada em Brasília, Distrito Federal, surgiu como uma parceira da empresa Rational e era especializada em implantação da metodologia de desenvolvimento RUP (Processo Unificado Rational). Mesmo contando com equipes qualificadas e depois da tentativa de implantação de modelos de qualidade de processos como o MPS.BR (modelo de Melhoria de Processos do Software Brasileiro), a empresa
  • 16. 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.
  • 17. 5.1.1.1.2 Estrutura organizacional A Figura 4 mostra a estrutura organizacional, que é um diagrama no qual exibe o fluxo da comunicação entre os envolvidos no projeto. 5.1.1.1.3 Recursos humanos Cada um dos integrantes da equipe de desenvolvimento atuaria em um ou mais papéis, dentro de cada iteração, de acordo com a demanda. Mais pessoas poderiam ser alocadas futuramente no projeto. Os papéis identificados para o projeto foram: um gerente de projeto; um analista de sistemas; um designer; seis desenvolvedores, sendo quatro da SEA e dois Sargentos da Aeronáutica; um arquiteto de software; uma analista de teste, sendo uma Suboficial da Aeronáutica; demais interessados, um Coronel e um Tenente da Aeronáutica. 5.1.1.2 Plano de gerenciamento de projeto Segundo o Guia PMBOK, desenvolver o plano de gerenciamento de projeto é o processo de documentação das ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares. É o principal processo de planejamento, pois, integra os demais planos complementando-os, e provavelmente, o processo mais importante para o gerente de projeto (PMI, 2008). No contexto da gestão de pessoas, é importante ressaltar os itens do Plano de Gerência de Comunicação do SIGPAER: – Semanalmente, o coordenador de desenvolvimento deveria enviar um e-mail para o gerente e demais interessados, informando o resultado das atividades da semana anterior, frente aos objetivos nela definidos, e os objetivos da próxima semana. – Deveria ser criada uma lista de e-mails para centralizar e manter histórico das mensagens eletrônicas trocadas no ambiente do projeto. – Os meios de contato dos componentes da equipe deveriam estar centralizados e disponibilizados para todos. – Uma vez por semana, haveria uma reunião de ponto de controle e objetivos da semana com toda a equipe. Nela seriam efetuadas avaliações do desenvolvimento do projeto, definidas ações corretivas e divulgações de decisões tomadas. Figura 4: Estrutura organizacional
  • 18. – As comunicações entre as organizações envolvidas e empresas contratadas, seriam feitas pelo gerente de desenvolvimento nos meios que considerar adequados (telefone, e-mail ou reunião presencial). – A equipe deveria se reportar ao coordenador de desenvolvimento, e este ao gerente de desenvolvimento. Caso as equipes crescessem, cada equipe se reportaria ao seu respectivo coordenador, e este ao coordenador de desenvolvimento. – Ao final de cada iteração, o coordenador registraria as lições aprendidas sobre comunicação na avaliação da iteração e tomaria as medidas corretivas se necessário. 5.1.2 O uso do Scrum na execução dos planos do projeto O objetivo desse novo projeto era a manutenção de um sistema feito em parceria entre Exército e Aeronáutica. Cada entidade tinha ramificações do sistema que deveriam ser mescladas antes do começo do novo projeto. Para utilização das práticas ágeis, tiveram apoio total da equipes que participaram dos dois projetos. Conhecimento eles já obtinham, faltava um ambiente favorável para colocá-los em prática. Como o próprio Guia PMBOK cita que é possível usar metodologias e ferramentas distintas para implementar a sua estrutura, os papéis, eventos e artefatos do Scrum foram utilizados para guiar o projeto de forma flexível e interativa (PMI, 2008). Após a junção dos projetos, foi iniciado o primeiro Sprint Planning, como mostrado na Figura 5. O Product Owner, um Tenente da Aeronáutica, que avaliava e gerenciava o projeto, levantava um número suficiente de estórias de usuário para a Sprint, depois entrava em acordo com um Capitão do Exército sobre as funcionalidades para encaminhá-las ao time de desenvolvimento. 5.1.3 Transparência a partir de práticas da XP As funcionalidades do sistema foram escritas em cartões de estórias do usuário, vistas na Figura 6. Isso cria um ambiente no qual o time e o cliente possam interagir de uma maneira que resulte em confiança mútua. O cliente escreve as estórias, pois é ele quem conhece as regras de negócio e o time estima quanto tempo levará para realizar as tarefas Figura 5: Sprint Planning
  • 19. advindas das estórias, pois ele é quem conhece as técnicas de desenvolvimento de software. Para estimar cada estória foram utilizadas rodadas de Planning Poker2 em que, cada pessoa do time se imagina trabalhando um dia inteiro sem interrupções, sem problemas ou sem dependências decompondo a estória pensando em todas as atividades até o estado de “pronto” e anota-se um número pertencente à sequencia de Fibonacci3 . Depois todos mostram sua estimativa para que entrem em um acordo sobre qual será a estimativa definitiva para a estória. O primeiro Planning Poker do projeto ocorreu e resultou em cinco estórias e vinte e um pontos. A definição de pronto foi acordada da seguinte maneira: o incremento deveria estar programado, testado, código-fonte documentado, apresentado e aprovado. Com isso, o próximo passo era estimar as estórias em ordem de prioridade. O tamanho da iteração foi definido em aproximadamente duas semanas, por conta de particularidades do expediente e feriados. Seriam dez dias úteis. Foram consideradas três pessoas em tempo integral, já que nem todos eram dedicados exclusivamente ao projeto (não é uma boa prática, mas a realidade era essa). O total era de trinta pontos. Foi considerada uma taxa de setenta porcento (70%) de produtividade, que é alta, mas jogar abaixo disso parecia incômodo para o cliente. A velocidade projetada para a primeira Sprint foi de vinte e um pontos para as primeiras duas semanas. Os cartões de estórias ficavam no quadro, colados com uma massa especial, para que todos pudessem ter a visão atual do projeto. Devido a equipe não ter conhecimento prévio do código-fonte do projeto, não havia muita base para estimativas e conhecimento sobre a produtividade da mesma. Com isso, o time foi preparado psicologicamente para errar provavelmente as três primeiras estimativas, fundamentando-se na literatura e experiência prévia de outros projetos. Para não gerar frustrações na equipe, foi estimado a melhoria progressiva a partir da quarta iteração. 5.1.4 Equipes auto-organizadas e maturidade As duas semanas seguintes foram seguidas por reuniões diárias assistidas pelo coordenador e líder técnico do projeto. Mas, aos poucos, foram deixando apenas o time 2 Técnica baseada no consenso, utilizada para estimar esforço ou tamanho relativo de estórias de usuários. 3 Sequência de números naturais, na qual os primeiros dois termos são 1 e 1, e cada termo subsequente corresponde à soma dos dois precedentes. Figura 6: Cartões de estórias do usuário
  • 20. 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.
  • 21. começaria a ser colocado brevemente em produção nas Organizações Militares. A Figura 7 mostra o quadro de tarefas da segunda Sprint do projeto. Na primeira coluna encontra- se o Product backlog. Os post-its, que são as tarefas decompostas das estórias, “prontos” ficavam fora do quadro, devido o mesmo ser pequeno. A Figura 8 mostra o quadro de tarefas após a retrospectiva, depois de limpar o que já estava pronto. A retrospectiva da Sprint foi muito boa. Foi realizada uma revisão na iteração, avaliando por que tudo tinha ido bem dessa vez, pois na primeira iteração, ninguém sabia de nada do código, o time não tinha um ambiente totalmente preparado e estavam trabalhando no núcleo do sistema. Na segunda iteração, as barreiras iniciais estavam todas vencidas e o time estava pronto. A simplicidade das funcionalidades também colaborou. 5.1.7 Gerenciamento de expectativas Foi decido alterar a duração da próxima iteração. Isso não é boa prática, mas era preciso diminuir o tempo das reuniões gerenciais relativas ao tempo das iterações. E como não havia mais feriados no ano, foi pensando em dar um dia de folga como recompensa se fosse tudo bem. Quinzenalmente o custo disso seria alto. Era desejado também acertar Figura 7: Quadro de tarefas da segunda Sprint do projeto Figura 8: Quadro de tarefas após a retrospectiva da Sprint 2
  • 22. 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.
  • 23. O estudo de caso mostrou que o projeto foi desenvolvido e implantado em um ambiente rígido, como as forças armadas, poderiam ter sido implementados processos como RUP, P-CMM ou PMBOK, para gerir o projeto como um todo. Mas devido a experiência dos colaboradores, principalmente do coordenador e do líder técnico, foi passado ao cliente a garantia de que problemas poderiam a acontecer e que eles seriam resolvidos da melhor forma possível, pois a imprevisibilidade faz parte de qualquer projeto. A transparência, um dos pilares dos métodos ágeis, é um dos motores que provê a confiança entre cliente e time, seja em qualquer tipo de projeto. MELNIKOFF et al. (2007) comenta que o P-CMM é projetado para grandes empresas, reforçando a importância das pessoas como indivíduos e de desenvolver duas capacidades. O PMBOK também, em seu capítulo sobre gerenciamento de recursos humanos, discorre sobre equipes pequenas e coesas que obtêm melhor desempenho. E existem vários estudos sobre a aderência de métodos ágeis em processos como o MPS.BR. O PMI já possui uma certificação ACP (Profissional Certificado em Métodos Ágeis), sinal de que os processos estão se convergindo e colocando o fator humano como principal peça da engrenagem no desenvolvimento de software. Referências BECK, K. Programação extrema explicada: acolha as mudanças. Porto Alegre: Bookman, 2004. BECK, K. et al. (2001) Manifesto for Agile Software Development. Disponível em: <http://agilemanifesto.org>. Acesso em: 05 mar. 2011. BROOKS, F. O mítico homem-mês: ensaios sobre engenharia de software. Rio de Janeiro: Elsevier, 2009. CISCON, L. Um estudo e uma ferramenta de gerência de projetos com desenvolvimento ágil de software. Dissertação de Mestrado, UFMG, 2009. COCKBURN, A. Characterizing people as non-linear, first-order components in software development. Orlando: 4th International Multi-Conference on Systems, Cybernetics and Informatics, 2000. Disponível em: <http://alistair.cockburn.us/ Characterizing+people+as+non-linear%2c+first-order+components+in+software+ development>. Acesso em: 15/06/2011. COCKBURN, A; HIGHSMITH, J. Agile Software Development: the people factor, Computer, 2001. CORREA, F; TANIGUCHI, K. Metodologias Ágeis e a Motivação de Pessoas em Projetos de Desenvolvimento de Software. Revista de Ciências Exatas e Tecnologia, Vol. IV, Nº 4, São Paulo, 2009. CURTIS, B. et al. People Capability Maturity Model. Pittsburg: Software Engineering Institute, 2001. Disponível em: <http://www.sei.cmu.edu/reports/ 01mm001.pdf>. Acesso em: 16/08/2011. DEMARCO, T; LISTER, T. Peopleware: productive projects and teams. 2nd ed. New York: Dorset House Publishing, 1999. FOWLER, M. The new methodoly, 2005. Disponível em: <http://martinfowler.com/articles/newMethodology.html>. Acesso em: 05/06/2011.
  • 24. FRANÇA, A. Um Estudo sobre Motivação em Integrantes de Equipes de Desenvolvimento de Software. Dissertação de Mestrado, UFPE, 2009. GABARDO, M; GOMES, A. Discussão sobre Motivação de Equipes na Implementação de Métodos Ágeis no Desenvolvimento de Sistemas na Administração Pública Federal. UCB, 2009. JOSKO, J. Gestão de Pessoas em Tecnologia da Informação – Uma visão perspectiva das abordagens. Dissertação de Mestrado, UNICAMP, 2004. MELNIKOFF, S. et al. Engenharia de software. 8ª ed. São Paulo: Pearson Addison- Wesley, 2007. NONAKA, I.; TAKEUCHI, H. The new new product development game. Harvard Business Review, Boston, 1986. PINK, D. Motivação 3.0. Rio de Janeiro: Elsevier, 2010. PMI. Guia PMBOK. 4ª ed. Newtown Square: PMI, 2008. SCHWABER, K; SUTHERLAND, J. Guia do Scrum. Scrum.org, 2011. Disponível em: <http://www.scrum.org/storage/Scrum%20Guide%202011%20-%20PTBR.pdf>. Acesso em: 05/12/2011. SCHWABER, K. SCRUM Development process. OOPSLA’95, Austin, 1995. Disponível em: <http://home.hib.no/ai/data/master/mod251/2009/articles/scrum.pdf>. Acesso em: 12/12/2010. SILVEIRA, V. et al. Os Modelos de Maturidade e a Gestão de Pessoas: O Modelo P- CMM. XXXI EnANPAD, Rio de Janeiro, 2007. TURNER, R; BOEHM, B. People factors in software management: lessons from comparing agile and plan-driven methods. The Journal of Defense Software Engineering, 2003.