A INFLUÊNCIA DA CULTURA E DA ESTRUTURA …livros01.livrosgratis.com.br/cp049624.pdf ·...
161
CRISTIANO TOLFO A INFLUÊNCIA DA CULTURA E DA ESTRUTURA ORGANIZACIONAL NA ADOÇÃO DA EXTREME PROGRAMMING Florianópolis/SC 2005
Transcript of A INFLUÊNCIA DA CULTURA E DA ESTRUTURA …livros01.livrosgratis.com.br/cp049624.pdf ·...
CRISTIANO TOLFO
A INFLUÊNCIA DA CULTURA E DA ESTRUTURA
ORGANIZACIONAL NA ADOÇÃO DA EXTREME
PROGRAMMING
Florianópolis/SC
2005
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA
COMPUTAÇÃO
CRISTIANO TOLFO
A INFLUÊNCIA DA CULTURA E DA ESTRUTURA
ORGANIZACIONAL NA ADOÇÃO DA EXTREME
PROGRAMMING
Dissertação submetida à Universidade Federal de
Santa Catarina como parte dos requisitos para a
obtenção do grau de Mestre em Ciência da
Computação
Orientador: Raul Sidnei Wazlawick, Dr.
A INFLUÊNCIA DA CULTURA E DA ESTRUTURA
ORGANIZACIONAL NA ADOÇÃO DA EXTREME
PROGRAMMING
CRISTIANO TOLFO
Esta Dissertação foi julgada adequada para a obtenção do título de Mestre em
Ciência da Computação e aprovada em sua forma final pelo Programa de Pós-
Graduação em Ciência da Computação.
________________________________
Raul Sidnei Wazlawick, Dr. (Coordenador do Curso)
Banca Examinadora
________________________________
Raul Sidnei Wazlawick, Dr. (Orientador)
________________________________
Ricardo Pereira e Silva, Dr.
________________________________
Vitório Bruno Mazzola, Dr.
________________________________
Alfredo Goldman vel Lejbman, Dr.
“Uma dificuldade final, e que pode facilmente afundar
um projeto XP, é que redirecionar é simplesmente
inaceitável em muitas culturas de empresas.”
Kent Beck
DEDICATÓRIA
À minha esposa Andréia, pelo seu amor,
carinho, compreensão e constante ajuda nesta
caminhada.
AGRADECIMENTOS
Ao Professor Raul Sidnei Wazlawick, por ter acreditado no sucesso deste
trabalho desde o seu início, oferecendo dedicada orientação, a qual possibilitou a
conclusão dessa dissertação.
A todos os Professores do Mestrado, pelos conhecimentos a mim transmitidos ao
longo do curso, bem como aos colegas do curso, pelas contribuições, apoio e incentivo
recebidos ao longo da jornada.
Sumário
Lista de Figuras ............................................................................................................ 10
Lista de Tabelas ............................................................................................................ 11
Resumo .......................................................................................................................... 12
Abstract ......................................................................................................................... 13
1. INTRODUÇÃO ........................................................................................................ 14
1.1 Tema e Problema de Pesquisa ............................................................................... 14
1.2 Trabalhos Relacionados......................................................................................... 16
1.3 Objetivos.................................................................................................................. 18
1.3.1 Objetivo Geral ..................................................................................................... 18
1.3.2 Objetivos Específicos........................................................................................... 18
1.4 Justificativa ............................................................................................................. 19
1.5 Metodologia............................................................................................................. 20
1.6 Estrutura do Trabalho ........................................................................................... 21
2. EXTREME PROGRAMMING – XP ..................................................................... 22
2.1 Os Métodos Ágeis e a XP ....................................................................................... 22
2.2 Papéis da Equipe XP .............................................................................................. 25
2.3 Valores do Método XP ........................................................................................... 27
2.4 Práticas do Método XP........................................................................................... 29
2.4.1 Jogo de Planejamento.......................................................................................... 29
2.4.2 Reuniões em Pé .................................................................................................... 30
2.4.3 Releases................................................................................................................. 30
2.4.4 Metáforas.............................................................................................................. 31
2.4.5 Projeto Simples .................................................................................................... 31
2.4.6 Testes .................................................................................................................... 31
2.4.7 Refatoração .......................................................................................................... 32
2.4.8 Programação pareada ......................................................................................... 33
2.4.9 Integração Contínua............................................................................................ 34
2.4.10 Propriedade Coletiva......................................................................................... 34
2.4.11 Ritmo Sustentável .............................................................................................. 35
2.4.12 Cliente Presente ................................................................................................. 35
2.4.13 Padrões de Programação .................................................................................. 36
2.5 Ciclo de Vida do Método XP ................................................................................. 37
2.6 A Sinergia das Práticas XP.................................................................................... 40
2.7 XP e os Métodos Tradicionais de Desenvolvimento de Software....................... 43
2.8 Adoção do Método XP............................................................................................ 44
3. CULTURA E ESTRUTURA ORGANIZACIONAL ............................................ 52
3.1 Cultura Organizacional ......................................................................................... 52
3.1.1 Definição............................................................................................................... 52
3.1.2 Elementos da Cultura Organizacional .............................................................. 58
3.1.2.1 Valores ............................................................................................................... 59
3.1.2.2 Ritos, Rituais e Cerimônias.............................................................................. 59
3.1.2.3 Mitos e Estórias................................................................................................. 60
3.1.2.4 Tabus ................................................................................................................. 60
3.1.2.5 Heróis................................................................................................................. 60
3.1.2.6 Crenças e Pressupostos .................................................................................... 61
3.1.2.7 Normas da Empresa ......................................................................................... 61
3.1.2.8 Processos de Comunicação .............................................................................. 62
3.1.3 Análise da Cultura Organizacional ................................................................... 63
3.1.4 Dimensões da Cultura Organizacional .............................................................. 67
3.1.5 Mudança da Cultura Organizacional ................................................................ 69
3.2 Estrutura Organizacional ...................................................................................... 74
3.2.1 Definição............................................................................................................... 74
3.2.2 Dimensões da Estrutura Organizacional........................................................... 75
4. A INFLUÊNCIA DA CULTURA E DA ESTRUTURA ORGANIZACIONAL
NA ADOÇÃO DA EXTREME PROGRAMMING .................................................. 81
4.1 Cultura Organizacional e a Extreme Programming ........................................... 82
4.1.1 Dimensão: Inovação e Risco ............................................................................... 82
4.1.2 Dimensão: Orientação para Detalhes ................................................................ 87
4.1.3 Dimensão: Orientação para Resultados ............................................................ 89
4.1.4 Dimensão: Orientação para Pessoas .................................................................. 92
4.1.5 Dimensão: Orientação para Equipe................................................................... 94
4.1.6 Dimensão: Agressividade.................................................................................. 100
4.1.7 Dimensão: Estabilidade..................................................................................... 104
4.2 Estrutura Organizacional e a Extreme Programming...................................... 106
4.2.1 - Dimensão: Especialização do Trabalho ........................................................ 106
4.2.2 - Dimensão: Departamentalização ................................................................... 108
4.2.3 Dimensão: Cadeia de Comando ....................................................................... 111
4.2.4 Dimensão: Margem de Controle ...................................................................... 114
4.2.5 Dimensão: Centralização e Descentralização.................................................. 116
4.2.6 Dimensão: Formalização................................................................................... 119
4.3 Aspectos Culturais e Estruturais Favoráveis ou Desfavoráveis à Adoção da XP
...................................................................................................................................... 121
5. APLICAÇÃO DA LISTA DE VERIFICAÇÃO.................................................. 124
5.1 Apresentação dos Dados Coletados .................................................................... 125
5.2 Aspectos Culturais e Estruturais da “Empresa X” Favoráveis à Adoção da XP
...................................................................................................................................... 131
5.3 Aspectos Culturais e Estruturais da “Empresa X” Desfavoráveis à Adoção da
XP................................................................................................................................. 132
5.4 Considerações Finais ............................................................................................ 134
6. CONCLUSÃO......................................................................................................... 136
REFERÊNCIAS ......................................................................................................... 139
ANEXOS ..................................................................................................................... 148
Lista de Figuras
Figura 1: Ciclo de vida XP. Adaptado de Abrahamsson (2002). ................................... 40
Figura 2: A interligação das práticas XP. Adaptado de Beck (2004)............................. 41
Figura 3: Dificuldades na aplicação de práticas e valores XP. Adaptado de Rumpe
(2002). ............................................................................................................................ 45
Figura 4: Fatores de sucesso identificados em projetos XP. Adaptado de Rumpe (2002).
........................................................................................................................................ 46
Figura 5: Fatores de riscos em projetos XP. Adaptado de Rumpe (2002). .................... 49
Figura 6: Iceberg da cultura organizacional. Adaptado de Chiavenato (1999). ............. 64
Figura 7: Itens de verificação - dimensão Inovação e Risco .......................................... 86
Figura 8: Itens de verificação - dimensão Orientação para Detalhes ............................. 89
Figura 9: Itens de verificação - dimensão Orientação para Resultados.......................... 92
Figura 10: Itens de verificação - dimensão Orientação para Pessoas............................. 94
Figura 11: Itens de verificação - dimensão Orientação para Equipes ............................ 99
Figura 12: Itens de verificação - dimensão Agressividade........................................... 104
Figura 13: Itens de verificação - dimensão Estabilidade.............................................. 105
Figura 14: Itens de verificação - dimensão Especialização do Trabalho ..................... 108
Figura 15: Itens de verificação - dimensão Departamentalização................................ 110
Figura 16: Itens de verificação - dimensão Cadeia de Comando ................................. 114
Figura 17: Itens de verificação - dimensão Margem de Controle ................................ 115
Figura 18: Itens de verificação - dimensão Centralização e Descentralização............. 119
Figura 19: Itens de verificação - dimensão Formalização............................................ 121
Lista de Tabelas
Tabela 1: Método Tradicional versus XP. Adaptado de Wege (2001)........................... 43
Tabela 2: Valores organizacionais.................................................................................. 68
Tabela 3: Elementos fundamentais da estrutura organizacional. Adaptado de Robbins
(1999). ............................................................................................................................ 75
Tabela 4: Cultura Organizacional: aspectos favoráveis e desfavoráveis à XP............. 122
Tabela 5: Estrutura Organizacional: aspectos favoráveis e desfavoráveis à XP .......... 123
Resumo
Os métodos ágeis de desenvolvimento de software prometem alto desempenho
para equipes pequenas, porém implantar um método ágil como a Extreme Programming
em uma empresa de software pode requerer mudanças consideráveis, as quais afetam as
relações de trabalho, aumentam as responsabilidades na condução do projeto e refletem
no sistema de poder da organização. Para que as práticas e valores do método XP
realmente se efetivem não basta satisfazer aspectos técnicos, mas é imprescindível que
no ambiente de trabalho estejam presentes determinados aspectos culturais e estruturais
que são decisivos para a adoção satisfatória da XP, como políticas da empresa
relacionadas à motivação dos desenvolvedores, coesão da equipe de desenvolvimento,
descentralização de poder e liderança democrática. Neste contexto, surge a preocupação
referente ao desgaste gerado pela implantação da Extreme Programming em empresas
cuja cultura e estrutura organizacional se revelem altamente incompatíveis com as
práticas e valores do método. Neste sentido, o presente trabalho procura fazer uma
contribuição identificando aspectos culturais e estruturais favoráveis ou desfavoráveis à
adoção da Extreme Programming, de forma a elaborar uma lista de verificação da
adequação dos fatores organizacionais.
Palavras chaves: Extreme Programming, Empresas de Software, Cultura
Organizacional, Estrutura Organizacional.
Abstract
The agile methods for the development of software promised a higher
performance to smaller teams. However, to implement an agile method such as the
Extreme Programming within a software company may require considerable changes,
which affect work relationships, increase responsibility on the project execution and
reflects on the balance of power in the organization. For the practices and values of the
XP method to become really effective it is not enough to satisfy technical aspects, but it
is fundamental that in the work environment certain cultural and structural aspects are
present which are decisive for a satisfactory adoption of XP, as company policies
related to the motivation of developers, connectivity of the team, non-centralized power
and democratic leadership. In this context, there are concerns about the effects that
come with the implementation of the Extreme Programming into companies where
culture and organizational structure turn out to be highly incompatible with the
method’s practice and values. In this sense, the present work identifies the cultural and
structural aspects that are either favorable or unfavorable to the adoption of Extreme
Programming and elaborates a list for the identification on how appropriate the
organizational factors are.
Keywords: Extreme Programming, Company of Software, Organizational
Culture, Organizational Structure.
14
1. INTRODUÇÃO
1.1 Tema e Problema de Pesquisa
Métodos ágeis de desenvolvimento de software como Scrum (SCHWABER,
1995), Dynamic Systems Development Method – DSDM (STAPLETON, 1997), Feature
Driven Development - FDD (PALMER, 2002) e Extreme Programming - XP (BECK,
2004) apresentam-se como alternativas à complexidade e formalidade das metodologias
tradicionais.
Dentre os métodos ágeis destaca-se a Extreme Programming – XP, que foi
criada em 1996 por Kent Beck no departamento de computação da multinacional
Daimler Chrysler. O método XP visa garantir desenvolvimento de software com sucesso
na presença de requisitos vagos que se modificam rapidamente (BECK, 2004).
Esta dissertação dedica-se ao estudo da adoção da XP pelas empresas de
desenvolvimento de software procurando investigar suas implicações organizacionais.
Quanto à adoção de um novo método de desenvolvimento de software, Cockburn
(2001) alerta que o fato de um método ter sido usado com sucesso por muitas equipes
não significa que todas as equipes estejam aptas à sua adoção de forma satisfatória.
As dificuldades de mudar para um método diferente nunca devem ser
subestimadas, pois levará um tempo considerável para ajustar a organização ao mesmo
e provavelmente este processo será acompanhado por uma queda inicial na
produtividade (COCKBURN, 2001).
A adoção satisfatória da XP depende de vários aspectos da empresa de
desenvolvimento de software, como seu mercado alvo, tipo de software desenvolvido,
perfil do cliente, tamanho e grau de criticidade dos projetos e eventual terceirização dos
mesmos. Entretanto, esta dissertação privilegia aspectos importantes para o uso da XP
que têm sido pouco abordados na literatura: cultura e estrutura organizacional.
15
Os paradigmas da XP diferem dos encontrados nos métodos tradicionais de
desenvolvimento de software porque estão profundamente focados em relações
humanas. Ou seja, diferentemente dos métodos prescritivos, sua concepção e evolução
dependem da interação entre as pessoas, neste caso, desenvolvedores de software,
gerência e cliente.
Uma das maiores dificuldades de se adotar o método XP é justamente fazer com
que suas práticas, fundamentalmente dependentes de aspectos humanos, sejam
realmente implementadas. Para realizá-las é preciso dispor de um ambiente em que
dirigentes da empresa e desenvolvedores possuam valores culturais compatíveis com as
exigências da XP.
Para verificar a adequação dos valores culturais da empresa de software à XP
torna-se inicialmente necessária a compreensão do conceito de cultura organizacional,
bem como de estrutura organizacional - na qual, segundo Tamoyo (1997) estão
presentes certos valores culturais de forma subjacente.
A cultura organizacional refere-se ao sistema de significados compartilhados por
todos os membros da organização. Ou seja, constitui o modo institucionalizado de
pensar e agir, sendo que sua essência é expressa pela maneira como a empresa faz seus
negócios, a forma como trata seus clientes e funcionários, o grau de autonomia dado aos
seus membros (CHIAVENATO, 1999).
Já a estrutura organizacional é definida por Stoner (1999) como sendo “a forma
pela qual as atividades de uma organização são divididas, organizadas e coordenadas.”
Assim, devem ser considerados aspectos como a hierarquia de poder, a organização dos
departamentos, a forma como são delegadas tarefas, como é disseminada a
comunicação, como é organizado o ambiente de trabalho.
Muitas vezes, para se adequar a uma nova metodologia de desenvolvimento de
software os membros da organização precisam mudar sua forma de agir e seus valores,
o que não se pode esperar que aconteça facilmente. Mudança de cultura organizacional
é um assunto intrigante, mas raramente é algo que se está disposto a considerar, portanto
16
é preciso escolher um método de desenvolvimento de software que se ajuste à cultura da
organização (McBREEN, 2002).
McBreen (2002) afirma que provavelmente o que pode acontecer com uma
organização que acha que é fácil mudar para uma metodologia cujos pressupostos são
diferentes da sua cultura organizacional é ter um desastre completo e absoluto de um
projeto.
Tendo em vista estes pressupostos, a presente dissertação propõe uma reflexão
sobre as influências dos fatores organizacionais na adoção do método XP,
considerando-se todas as suas práticas e valores, ou seja, sua adoção na íntegra.
Analisando-se as dimensões da cultura e da estrutura organizacional sob a perspectiva
das práticas e valores XP, pretende-se identificar aspectos favoráveis ou desfavoráveis à
adoção do método, a fim de se elaborar uma lista de verificação da adequação dos
fatores organizacionais das empresas de software.
Neste sentido, o problema investigado na pesquisa é: Quais os aspectos culturais
e estruturais das empresas de software que influenciam na implantação do método
Extreme Programming?
1.2 Trabalhos Relacionados
Levando em conta vários fatores, dentre eles a cultura organizacional, Jim
Highsmith (2002) - um dos especialistas em métodos ágeis que participou do Manifesto
Ágil (AGILLE, 2001) - preocupa-se em determinar a metodologia de desenvolvimento
de software mais adequada à realidade de cada empresa.
O título de sua obra “Ecossistemas de Desenvolvimento de Software Ágeis” está
associado à oposição de Jim Highsmith à adoção do termo “metodologia” para se referir
aos métodos ágeis. Segundo o referido autor, a palavra metodologia não se ajusta ao
foco do desenvolvimento ágil, que envolve pessoas, relações e incertezas, além disso,
usando-se a palavra “metodologia” as práticas ágeis são erroneamente comparadas a
metodologias de desenvolvimento de software tradicionais.
17
Assim, o autor prefere o termo ecossistemas de desenvolvimento de software
ágeis – ASDE. Porém, apesar da opinião de Highsmith, nesta dissertação se utiliza a
expressão “metodologia”, mesmo em se tratando de XP.
Em sua pesquisa Highsmith recomenda que para adotar uma metodologia de
desenvolvimento de software - seja ágil ou tradicional - a empresa deve considerar
fatores como o seu mercado alvo, as suas oportunidades e estratégias e a sua cultura
organizacional.
Em relação as oportunidade e estratégias Highsmith elegeu o modelo de
Geoffrey Moore que classifica as empresas de acordo o seu estágio de mercado.
Quanto à cultura organizacional, Highsmith considera 5 tipos de cultura -
também determinadas por Geoffrey Moore (MOORE, 1995) - a saber:
a) Cultura de colaboração: em que predominam ajuda mútua e decisões em
equipes. A liderança é participava e não apenas um cargo controlador.
b) Cultura de cultivo: prioriza a ajuda entre as pessoas, mas com ênfase em
indivíduos ao invés da ênfase na equipe.
c) Cultura de competência: enfatiza responsabilidade e comprometimento
individual.
d) Cultura de controle: baseado em hierarquia de poder e orientado à segurança.
e) Cultura de relativismo: influenciada pelos meios culturais.
Highsmith acredita que as características culturais e o foco de mercado definem
e condicionam o método de desenvolvimento de software mais apropriado para a
empresa. Desta forma, as organizações devem adotar estratégias para evitar a adoção de
um método incompatível com seu mercado ou inviável para sua cultura organizacional.
A pesquisa realizada nesta dissertação está relacionada com o estudo de Jim
Highsmith, já que ambos possuem o propósito de identificar a compatibilidade do
método de desenvolvimento de software com a realidade da empresa. Porém, as
18
propostas diferem, já que na parte do seu trabalho que envolve a cultura organizacional,
Highsmith apenas relaciona cada tipo de cultura com o método mais adequado, mas não
realizou um estudo específico de todos os aspectos culturais que possuem implicação na
adequação.
Já a presente dissertação, utiliza-se de um conjunto de dimensões recomendadas
para avaliação de aspectos da cultura e também da estrutura organizacional, as quais são
analisadas sob a perspectiva dos pressupostos de um método de desenvolvimento de
software em especial: Extreme Programming. Assim, a preocupação está em identificar
os aspectos favoráveis e desfavoráveis à adoção do método XP, de forma a elaborar-se
uma lista de verificação da adequação dos fatores organizacionais.
1.3 Objetivos
1.3.1 Objetivo Geral
Verificar a influência da cultura e da estrutura organizacional das empresas de
software na adoção da Extreme Programming, a fim de estabelecer uma lista de
verificação da adequação dos fatores organizacionais.
1.3.2 Objetivos Específicos
a) Analisar as dimensões da cultura e da estrutura organizacional sob a
perspectiva das práticas e valores XP;
b) Identificar aspectos culturais e estruturais favoráveis ou desfavoráveis à
adoção do método XP;
19
c) Elaborar uma lista de verificação que permita uma reflexão prévia a respeito
da adequação dos fatores organizacionais das empresas de software que pretendam
adotar o método XP;
d) Aplicar a lista de verificação em uma empresa de desenvolvimento de
software a fim de verificar a existência dos aspectos organizacionais identificados na
dissertação.
1.4 Justificativa
De acordo com Moore (1995), os fracassos na implantação de metodologias
ocorrem porque muitas vezes as mesmas são adotadas para solucionar problemas de
desenvolvimento de software, porém há pouca análise da compatibilidade entre as
implicações da solução encontrada (nova metodologia) e a cultura organizacional.
Neste sentido torna-se pertinente o entendimento de Larsen e Kerievsky (2003)
segundo o qual a XP é viável em muitos projetos se forem considerados apenas seus
aspectos técnicos. Sendo que os riscos maiores na sua utilização estão nos aspectos
culturais das organizações.
A XP não é apenas um processo, mas ela contém princípios e práticas que
orientam o projeto e a equipe de desenvolvimento. Estes princípios e práticas devem
estar arraigados na cultura dos membros da equipe (ASTELS, 2002).
Salienta-se que o método XP está fundamentado em premissas que exigem
equipes comunicativas e com alto desempenho, envolvidas em um ambiente
colaborativo, com autonomia para tomada de decisões e para correr riscos,
desenvolvendo software de forma iterativa e incremental. Desta forma, vários valores
culturais são solicitados.
Cunningham (2003) chama atenção para o fato de que em algumas empresas de
software determinados valores organizacionais podem ser totalmente contrários aos
valores XP, caso em que a adoção do método pode ser inviável.
20
Ao se decidir implantar o método XP integralmente deve-se estar ciente dos
desafios impostos. Assim, este estudo justifica-se pela importância de se verificar
previamente a adequação dos fatores organizacionais da empresa de software e o
método XP a fim de se evitar que as empresas fiquem sujeitas aos desgastes
provenientes da implantação irrefletida do método.
A escassez de estudos específicos sobre o tema proposto torna esta pesquisa uma
contribuição para a área. Também se salienta que a lista de verificação da adequação
dos fatores organizacionais elaborada nesta dissertação pretende ser um modelo
genérico, ou seja, seus aspectos podem ser considerados independentemente das
especificidades das empresas de software.
1.5 Metodologia
Conforme Gil (1996) é usual a classificação das pesquisas com base em seus
objetivos gerais, sendo possível identificar três grupos: estudos exploratórios,
descritivos e explicativos.
Em relação aos objetivos, a presente dissertação situa-se na categoria de
pesquisa exploratória, devido ao assunto ser pouco explorado na literatura. Quanto à
forma de abordagem, a pesquisa tem caráter qualitativo, que se justifica por ser a forma
adequada para entender a natureza de um fenômeno social, sobretudo em relação ao
entendimento das particularidades do comportamento dos indivíduos. As informações
são obtidas por meio de revisão bibliográfica e experimentadas através de entrevistas e
questionários aplicados na empresa de software selecionada para este estudo.
21
1.6 Estrutura do Trabalho
O trabalho está dividido em 6 partes.
No primeiro capítulo é apresentado o tema da pesquisa, a sua limitação, a
caracterização do problema, os objetivos gerais e específicos, a justificativa e a estrutura
do trabalho.
O segundo capítulo é dedicado ao método de desenvolvimento de software XP,
abordando suas características e princípios, sobretudo no que diz respeito a suas práticas
e valores.
No terceiro capítulo aborda-se a cultura e a estrutura organizacional, sendo
apresentada a definição, a caracterização e as diversas dimensões de cada um destes
fatores organizacionais.
No quarto capítulo são analisadas as dimensões da cultura e da estrutura
organizacional sob a perspectiva das práticas e valores XP, a fim de se identificar
aspectos culturais e estruturais favoráveis ou desfavoráveis à adoção do método. Essa
análise possibilita a elaboração da lista de verificação da adequação dos fatores
organizacionais.
No quinto capítulo é apresentada uma aplicação da lista de verificação em uma
empresa de desenvolvimento de software da grande Florianópolis, identificada como
“Empresa X”.
O estudo finaliza com o sexto capítulo, em que se apresenta a conclusão da
pesquisa.
22
2. EXTREME PROGRAMMING – XP
2.1 Os Métodos Ágeis e a XP
Introduzindo uma abordagem diferenciada das técnicas tradicionais de
desenvolvimento de software, os métodos ágeis procuram superar problemas verificados
em projetos de desenvolvimento como código de baixa qualidade, necessidade de
entregas freqüentes de software funcional e a saída de membros da equipe que possuem
conhecimento exclusivo sobre os processos elaborados.
Fowler (2000) destaca que os métodos ágeis também representam uma reação a
modelos extremamente conceituais e a metodologias “monumentais”, as quais são
consideradas burocráticas devido à quantidade de material a ser produzido, o que causa
diminuição na velocidade do desenvolvimento. Os métodos ágeis tentam estabelecer um
compromisso útil entre não ter um processo e ter um processo complexo demais.
Os valores adotados pelos métodos ágeis são os determinados pela Agile
Alliance (2001), sendo: indivíduos e interações valem mais que processos e ferramentas;
software funcionando vale mais que documentação extensa; colaboração do cliente vale
mais que negociação de contrato; responder a mudanças vale mais que seguir um plano.
Os membros da Agile Alliance, no seu manifesto ágil, também definiram um
conjunto de 12 princípios considerados diretrizes gerais para o sucesso de um projeto de
desenvolvimento ágil de software. Esses princípios são (ALVIM, 2002):
1) A prioridade é a satisfação do cliente através da liberação mais rápida e
contínua de software de valor;
2) Receber bem mudanças de requisitos, mesmo em estágios avançados de
desenvolvimento. Os processos ágeis devem admitir mudanças que trazem vantagens
competitivas para o cliente;
23
3) Entregar software com freqüência de duas semanas até dois meses, de
preferência na menor escala de tempo;
4) Manter as pessoas de negócio e os desenvolvedores trabalhando juntos a
maior parte do tempo;
5) Construir projetos com indivíduos motivados, dando-lhes um ambiente de
suporte que necessitam e confiar neles para realizar o trabalho;
6) O método mais eficiente de repassar as informações para a equipe de
desenvolvimento é a conversa face a face;
7) Software funcionando é a principal medida de progresso;
8) Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter conversação pacífica
indefinidamente;
9) Atenção contínua para a excelência técnica e um bom projeto aprimora a
agilidade;
10) É essencial adotar sempre a solução mais simples possível;
11) As melhores arquiteturas, requisitos e projetos emergem de equipes auto-
organizadas;
12) Em intervalos regulares, as equipes devem refletir sobre como se tornarem
mais efetivas, e então refinarem e ajustarem seu comportamento.
Um dos métodos ágeis que vêm despertando interesse e conquistando vários
adeptos é a denominada Extreme Programming, ou simplesmente XP, a qual teve início
em 1996, por meio de seu mentor Kent Beck, que buscava melhores formas para
desenvolver software.
Em meados da década de 90 Kent Beck foi contratado pela Multinacional
Chrysler para trabalhar no projeto de um sistema para a folha de pagamento da empresa,
denominado C3. O desenvolvimento do sistema também deveria servir como forma de
24
capacitação dos desenvolvedores de software em tecnologias orientadas a objetos.
Nesse projeto Beck teve a oportunidade de realizar quase todas as práticas que mais
tarde formaram o método de desenvolvimento de software XP (LARMAN, 2003).
O termo “extreme” (extremo) enfatiza o uso extremo de práticas que se mostram
funcionais, como revisão de código, testes, simplicidade e ciclos curtos e iterativos
(BECK, 2004).
Segundo Beck (2004), a XP é um método leve e flexível para ser utilizado por
equipes de tamanho pequeno a médio que desenvolvem software com requisitos vagos.
Esse método enfatiza o rápido desenvolvimento do projeto e visa a satisfação do cliente,
estando fundamentado em valores e práticas que são complementares umas as outras.
Beck (2004) distingue a XP de outras metodologias por:
a) apresentar feedback contínuo e concreto em ciclos curtos de
desenvolvimento de software;
b) abordar planejamento incremental, apresentando rapidamente um plano
global que evolui durante o ciclo de vida do projeto;
c) possuir habilidade flexível de programar implementação de funcionalidades,
respondendo às mudanças de regras do negócio;
d) confiar nos testes automatizados escritos pelos programadores e clientes para
monitorar o progresso do desenvolvimento, permitindo a evolução do sistema e
detectando antecipadamente os problemas;
e) acreditar na comunicação oral, na colaboração íntima dos programadores,
nos testes e no código fonte, definindo uma estrutura do sistema e os objetivos;
f) confiar no processo de evolução do projeto, que subsiste tanto quanto o
sistema.
Apesar de a XP ser um dos métodos ágeis bastante difundidos, a mesma também
é um dos métodos mais polêmicos, por possuir propostas consideradas radicais frente às
25
premissas dos métodos tradicionais de desenvolvimento de software. A seguir são
apresentados os princípios e regras que caracterizam o método XP.
2.2 Papéis da Equipe XP
Beck (2004) define alguns papéis que precisam ser preenchidos para que uma
equipe funcione de acordo com a filosofia XP, são eles:
a) Programador:
O programador é a pessoa que analisa, projeta, codifica e testa o sistema, pois
durante a execução do método XP não existem divisões claras para as atividades de
analista, projetista e programador.
Nesta dissertação dá-se preferência ao termo “desenvolvedor” para se referir às
pessoas diretamente envolvidas com atividades do desenvolvimento de software, como
análise, design, programação e testes (com exceção do cliente).
O desenvolvedor do método XP possui diferentes responsabilidades, entre elas
estão tarefas como: estimar prazos das histórias dos clientes; definir e estimar cartões de
tarefas a partir das histórias; implementar testes unitários (deve ser feito antes do
código); implementar o código de produção; desenvolver software em par; efetuar
refatoração sempre que necessário; solicitar ao cliente que esclareça ou divida histórias
quando necessário.
b) Cliente:
No método XP é fundamental a participação do cliente no projeto, para Beck
(2004) o programador sabe programar e o cliente sabe o que deve ser programado.
O cliente ideal para a XP participa como um membro da equipe, e, se possível,
com disponibilidade integral para realizar tarefas como: definir o que o sistema deve
fazer (requisitos do sistema que são repassados para os cartões de histórias); escrever
26
testes de aceitação; definir o que deve ser implementado primeiro (prioridades para os
cartões de história); validar e definir os testes de aceitação sempre que solicitado;
esclarecer dúvidas.
Um dos problemas freqüentes em projetos XP é a não disponibilidade do cliente
para estar presente durante o desenvolvimento do software. Nesta situação, alguém com
conhecimento do domínio deve realizar o papel do cliente e gerar as histórias, podendo
ser, inclusive, um dos membros da equipe de desenvolvimento.
c) Analista de testes:
Na XP o papel de analista de teste é geralmente desempenhado pelo próprio
programador. O analista de testes é responsável por ajudar o cliente a definir os testes
do projeto, escrever e executar os testes de aceitação e também executar os testes de
unidades.
d) Treinador:
O treinador é representado por uma pessoa com conhecimentos sólidos no
método XP. Um dos programadores da equipe também pode desempenhar o papel de
treinador. As principais tarefas do treinador são manter a equipe focada nas práticas XP,
buscar formas de melhorar o processo e re-encaminhar a equipe quando a mesma estiver
se desviando das práticas e valores XP.
e) Gerente de projeto:
Na literatura o gerente de projeto é também identificado pelo termo Big Boss
(grande chefe). É responsável pelos assuntos administrativos do projeto como gerenciar
a equipe, agendar e coordenar reuniões de planejamento e angariar recursos com os
responsáveis pelas finanças. Além disso, administra o relacionamento com o cliente,
assegurando que o mesmo participe ativamente do desenvolvimento e forneça
informações essenciais para que a equipe possa implementar o sistema desejado.
27
f) Diretoria da empresa:
Identificado na literatura pelo termo Gold Owner (proprietário do ouro), este
papel pode ser identificado na figura dos dirigentes da empresa e/ou investidores de um
determinado projeto.
Os proprietários do ouro são os provedores de recursos para o projeto. Os
recursos podem configurar-se na remuneração das pessoas envolvidas, nas instalações,
nos equipamentos e nas demais necessidades para o andamento do projeto (JEFFRIES,
2001).
2.3 Valores do Método XP
A filosofia de trabalho da XP está fundamentada em 4 valores que viabilizam
um conjunto de práticas do referido método. Esses valores são:
a) Comunicação:
A XP pressupõe que a maioria dos problemas em projetos de software ocorre por
dificuldades na comunicação (LARMAN, 2003). A comunicação intensa e facilitada
necessária na XP pretende evitar problemas comuns em projetos de software - como
compreensão errada ou incompleta dos requisitos do cliente - e fornecer segurança e
coragem para a tomada de decisões sobre alterações no rumo do projeto.
A proximidade entre as pessoas é fundamental para que o valor XP comunicação
se configure e para que o método possa ser executado de forma satisfatória. Wuestefeld
(2001) sintetiza a importância que deve ser dada à comunicação na XP por meio da
seguinte consideração: deve-se preferir sala de discussão (chat) a correio (e-mail),
telefonemas a chat, conversar pessoalmente a telefonemas, trabalhar na mesma sala a ter
salas isoladas, trabalhar em conjunto a revisar o resultado final.
28
b) Simplicidade:
Em um processo ágil como a XP onde a comunicação e o feedback são intensos,
torna-se fundamental que as ações de cada membro sejam suficientemente simples,
facilitando assim, ajustes e adaptações. Deve-se projetar e codificar o que realmente é
necessário para o momento, a fim de se evitar que uma codificação seja feita e depois se
descubra que não há mais motivo para realizá-la.
É possível classificar um projeto como sendo simples se o mesmo contiver as
seguintes características: executar todos os testes, revelar todas as intenções, não
envolver duplicação e contiver o menor número de classes ou métodos (BECK, 2004).
Segundo Beck (2004), a simplicidade em projetos XP sugere que sejam
implementados apenas os requisitos fornecidos pelo cliente, isto implica em codificar
uma funcionalidade que trate apenas do determinado requisito, sem a preocupação com
uma estrutura genérica para futuras modificações. É preciso que a equipe esteja
consciente que deverá modificar o código, se necessário no futuro.
c) Feedback:
Para Teles (2004) a XP procura romper com o modelo mental tradicional de
desenvolvimento de software que apresenta uma forte divisão entre produção e
consumo. Na XP o cliente e a equipe atuam como produtor e consumidor
permanentemente, isto ocorre por meio de constante feedback .
No método XP, o feedback do cliente ocorre quando ele fornece novas
informações e requisitos do software para a equipe – desempenhando o papel de
produtor. Também ocorre o feedback quando ele desempenha o papel de consumidor,
utilizando o modulo funcional do sistema que lhe foi entregue pela equipe e retornando
seu parecer. A equipe fornece feedback ao cliente, retornando estimativas, apontando
riscos técnicos, sugerindo alternativas de design, entre outras (TELES, 2004).
Em relação à importância de manter o feedback em projetos de software,
Wuestefeld (2001) afirma que todo problema deve ser evidenciado o mais cedo possível
29
para que possa ser corrigido o mais cedo possível. Isto significa coletar a opinião do
cliente sobre o que foi feito o mais cedo possível.
d) Coragem:
A XP é um processo fundamentado em diversas premissas que contrariam os
processos tradicionais de desenvolvimento, portanto é preciso coragem para mudar
conceitos e valores dos membros do projeto.
Conforme Teles (2004), a adoção da XP exige que a equipe de desenvolvimento
tenha coragem para: desenvolver software de forma incremental; manter o sistema
simples; permitir ao cliente priorizar funcionalidades; incentivar os desenvolvedores a
trabalhar em par; investir tempo em refatoração; investir tempo em testes
automatizados; estimar as histórias na presença do cliente; expor código a todos os
membros da equipe; integrar o sistema diversas vezes ao dia; adotar um ritmo
sustentável; abrir mão de documentação; propor contratos de escopo variável; propor a
adoção de um processo novo.
2.4 Práticas do Método XP
Conforme Beck (2004), as práticas que compõem o método XP são:
2.4.1 Jogo de Planejamento
Certo grau de planejamento é requerido pela XP, mas o diferencial deste método
encontra-se em quanto tempo a equipe deve dedicar-se a esta tarefa, neste caso o
planejamento deve ser mínimo e a curto prazo. Segundo Jeffries (2001), a ênfase está
em guiar o projeto, ao invés de determinar exatamente o que será necessário e o tempo
que levará.
Um projeto XP é dividido em períodos de tempos denominados releases, por
exemplo, um projeto de oito meses pode ser dividido em 4 entregas de 2 meses,
30
seguindo um processo de desenvolvimento iterativo e incremental. Cada release
representa um determinado período de tempo estimado para entregar uma parte do
software para o cliente.
Dentro de cada release são estipuladas algumas iterações, que são espaços de
tempo menores que servem para definir quais histórias do usuário serão codificadas e,
então, executar o trabalho que foi definido.
No início de cada release e de cada iteração ocorre o jogo de planejamento, que
se trata de uma reunião em que o cliente e os desenvolvedores avaliam o que será
codificado naquele determinado período de tempo (release ou iteração) e priorizam as
funcionalidades que deverão compor o próximo release ou iteração. As funcionalidades
são escritas em pequenos cartões, sendo chamadas de histórias.
Assim, o jogo de planejamento pode ocorrer em uma reunião, cujo tempo varia
conforme o tamanho e a complexidade do release ou iteração.
2.4.2 Reuniões em Pé
Devem ser realizadas reuniões no início de cada manhã, ocasião em que os
desenvolvedores descrevem o que fizeram no dia anterior e o que pretendem fazer
durante o dia que está iniciando. Mas essas reuniões não servem para discussões
detalhadas, as quais devem ser realizadas em particular, somente com as partes
envolvidas.
2.4.3 Releases
Conforme mencionado ao descrever-se o jogo de planejamento, os projetos XP
são caracterizados por releases e iterações. Os releases constituem entregas de software
funcional ao cliente no decorrer do projeto. Assim, há mais probabilidade de que os
requisitos do cliente sejam todos satisfeitos e ele não precisa esperar o final do projeto
para receber o software de uma única vez. Durante os releases os clientes podem sugerir
alterações nas funcionalidades requeridas e realizar feedback.
Já as iterações são curtos períodos de tempo em que a equipe implementa um
conjunto de funcionalidades acordado com o cliente objetivando um release. O
31
intervalo entre a distribuição dos releases deve ser o menor possível, geralmente entre
um a três meses.
2.4.4 Metáforas
A metáfora constitui uma forma de representação das informações para que o
cliente possa entender os requisitos mais facilmente. Geralmente se utiliza de um
exemplo ou uma comparação com algo que esteja presente na realidade do cliente para
descrever uma determinada situação do sistema. As metáforas podem ser utilizadas
tanto com o cliente como entre a equipe de desenvolvimento (FOWLER, 1999).
2.4.5 Projeto Simples
O sistema deve ser projetado o mais simples possível, satisfazendo apenas os
requisitos atuais. Esta prática vai contra o modelo tradicional de um projeto
generalizado, em que se projeta todo o sistema para só então iniciar a codificação. Beck
(2004) sugere que um projeto XP seja simples o suficiente para implementar apenas as
tarefas das histórias em que se está trabalhando, sem se preocupar com implementações
futuras.
Na XP é muito importante um projeto apropriado. Para Wells (2002), um projeto
simples requer menos tempo para terminar que um projeto complexo. Assim, deve-se
fazer um projeto simples e suficiente para se trabalhar.
2.4.6 Testes
Todo o processo do método XP é orientado a testes, já que a equipe se concentra
na validação do software durante todo o processo. A proposta de Beck (2004) é
desenvolver software com contínuos testes e feedback, permitindo aos programadores
identificar erros em curtos períodos de tempo e evitar que os mesmos problemas se
repitam.
A XP utiliza dois tipos de testes que devem ser escritos antes do código ser
construído: testes de unidades e testes de aceitação. Antes de implementar as classes do
sistema o programador primeiramente escreve testes de unidade, que são realizados em
cada classe do sistema, para verificar se os resultados gerados estão corretos.
32
As histórias e funcionalidades devem ser implementadas depois de passarem
pelos testes de aceitação escritos pelo cliente (geralmente os testes de aceitação são
escritos por meio dos cartões de histórias). Os testes deverão ser automatizados, de
modo que possam ser executados uma infinidade de vezes ao longo do
desenvolvimento. Assim, é possível verificar não apenas uma classe em particular, mas
a iteração entre um conjunto de classes que implementam uma dada funcionalidade.
Wells (2002), destacando a importância dos testes na XP, afirma que os testes de
unidade proporcionam a economia de custo ao identificar os erros. Desta forma, um
conjunto de testes de unidade deve estar disponível no início do projeto e não no final.
Os testes de aceitação, por sua vez, constituem a primeira indicação de que as histórias
dos clientes são válidas (ASTELS, 2002).
Os testes garantem que o código desenvolvido não apresenta falhas. Quando os
testes são realizados tem-se a certeza de que o código produzido está atendendo os
requisitos e pode-se iniciar o desenvolvimento de outro código, integrando o código já
testado e aprovado ao release.
2.4.7 Refatoração
Conforme Fowler (1999), “refatoração é o processo de alterar o sistema de
software de tal forma que ele não altere o comportamento externo do código e melhore
sua estrutura interna. Essa é uma forma disciplinada de limpar o código que minimiza as
chances de erros”. A refatoração também permite evitar o remover duplicação de
código, por exemplo, a verificação uma consulta em sistema que deva ser implementada
de forma centralizada em um único lugar em todo o código. Eliminando a duplicação de
código, o design torna-se limpo e reutilizável.
Na XP procura-se aperfeiçoar o projeto do sistema por meio de transformações
no código, o qual é constantemente testado e revisado. Wuestefeld (2001) afirma que se
deve realizar refatoração onde for possível e sempre que possível.
Para Astels (2002), a refatoração deve ser feito em pequenas etapas. Após cada
uma delas, deve-se verificar se o comportamento continua inalterado, caso tenha sido
33
introduzido algum erro será fácil de identificá-lo, pois foram feitas pequenas alterações
desde a última versão funcional.
2.4.8 Programação pareada
A programação pareada constitui uma técnica em que dois desenvolvedores
compartilham o mesmo computador, desenvolvendo software de forma colaborativa. Os
desenvolvedores trocam informações, sugerindo o interesse em fazer algum código
específico de forma que os colegas que tenham interesse em comum formam um par.
Mas os pares não devem ser sempre os mesmos, devendo ocorrer revezamento para
aproximar todo o grupo e disseminar as informações sobre o processo (BECK, 2004).
É necessário também que haja um revezamento do controle do mouse e do
teclado, e que o programador que não está digitando faça sugestões de alterações
quando achar necessário, assim todo o código produzido é revisado pelo outro
programador (JEFFRIES, 2001). É importante que ambos os programadores evitem que
as sugestões se tornem discussões.
A prática de programação pareada é bastante discutida, com argumentações
contra e a favor, porém para efetivar esta prática dois requisitos básicos são necessários:
um ambiente físico apropriado para dois desenvolvedores se colocarem em frente à
estação de trabalho e um bom relacionamento entre os membros da equipe.
Para Williams (2000) o código produzido por dois programadores
desenvolvendo em par é mais revisado e de melhor qualidade, a velocidade de
programação é semelhante a de um programador isolado. Williams ainda faz outras
considerações referentes à programação pareada:
a) Revisões contínuas: a técnica de programação pareada consiste em estar
sempre projetando e revisando código, conduzindo a taxas de remoção de defeito mais
eficientes. Conforme Williams, os programadores admitem trabalhar de forma mais
intensa e inteligente porque eles não querem decepcionar seus colegas;
b) Resolução de problemas: constantemente os participantes recorrem à
habilidade da equipe para resolver problemas mais rapidamente;
34
c) Aprendizado: os pares de programadores afirmam que aprendem um com o
outro;
d) Equipe construindo e se comunicando: as pessoas aprendem a discutir e a
trabalhar juntas, melhorando a comunicação e a efetividade da equipe;
e) Gerência da equipe e do projeto: Considerando que múltiplas pessoas estão
familiarizadas com cada parte do código, a programação pareada reduz os riscos na
perda de pessoal.
2.4.9 Integração Contínua
Diversas vezes ao dia são atualizadas e integradas novas versões ao sistema.
Assim, sempre que um código é gerado e testado o máximo possível ele é adicionado ao
projeto, de forma que a todo o momento uma nova tarefa é completada. Após a
integração do código ao projeto maior, ocorrem novos testes para verificar se a
integração alterou algo que já estava funcionado.
Astels (2002) caracteriza a integração contínua no método XP como um
processo de tomar as alterações dos membros da equipe, juntá-las e em seguida corrigir
todos os erros que ocorrem quando o trabalho de um membro entra em conflito com o
trabalho de outro. O resultado esperado é uma construção funcional.
A integração deve ser realizada ao menos uma vez ao dia, mas o ideal é que a
cada tarefa concluída seja realizada integração (BECK, 2004).
2.4.10 Propriedade Coletiva
Em projetos de software é comum dividir as tarefas em partes diferentes para
cada desenvolvedor, ou seja, cada desenvolvedor é responsável por uma determinada
quantidade de código. Segundo Teles (2004), neste caso podem ocorrer problemas
quando apenas um membro da equipe detém o conhecimento sobre determinada parte
do sistema, pois a equipe fica atrelada a sua presença para alterar seu código e a
documentação gerada por ele muitas vezes pode não ser atualizada.
35
Para que o método XP possa impor seu ritmo todos os membros da equipe
devem fazer alterações em qualquer parte do código quando necessário. A equipe XP
como um todo é responsável por cada arquivo de código (WUESTEFELD, 2001).
Ou seja, o código pertence a toda a equipe, sendo que qualquer um pode alterá-
lo, a qualquer momento, independentemente de quem o tenha escrito. Contudo, para que
todos possam alterar o código, os testes de unidade devem ser bem elaborados,
permitindo segurança aos desenvolvedores.
Além disso, com a prática Código Coletivo todos os membros da equipe devem
conhecer todas as partes do sistema, mesmo que com diferentes níveis de conhecimento,
assim qualquer um está habilitado a modificar e melhorar o código, desde que este seja
mantido funcional.
2.4.11 Ritmo Sustentável
Trabalhadores exaustos e/ou estressados podem cometer mais erros e não
alcançar o máximo de seu desempenho. O método XP recomenda trabalhar
intensamente apenas no horário estipulado, de preferência 40 horas semanais, e
descansar no tempo restante. Neste caso, é fundamental um bom planejamento a fim de
se evitar a necessidade de trabalhar além das horas normais e ficar sob pressão.
2.4.12 Cliente Presente
O cliente ou um representante do mesmo deve se tornar um membro efetivo da
equipe XP, determinando requisitos, realizando testes de aceitação e respondendo as
dúvidas. Na XP os clientes não devem ser vistos como simples usuários do sistema, mas
devem interagir durante o processo de desenvolvimento.
Para Wuestefeld (2001) a principal vantagem em se ter o cliente sempre presente
é que ele poderá fornecer detalhes do sistema quando surgirem dúvidas. Deve-se
considerar que quando os programadores estão implementando uma funcionalidade
realmente surgem muitas dúvidas e, se o cliente estiver presente, as mesmas podem ser
prontamente esclarecidas.
36
O cliente deve conduzir o desenvolvimento a partir do feedback que recebe do
sistema e para que a troca de feedback possa ocorrer e o cliente possa obter o máximo
de valor do projeto é essencial que o mesmo participe ativamente do processo de
desenvolvimento de software (TELES, 2004).
Caso não seja possível obter a presença do cliente, deve existir alguém que tenha
conhecimento do domínio para realizar o papel de cliente e gerar as histórias, podendo
ser alguém da própria equipe de desenvolvimento.
McBreen (2002) sublinha os benefícios de ter o cliente sempre presente,
afirmando que desta forma é possível reduzir o risco de os desenvolvedores entenderem
mal o negócio, além disso, estes podem receber rapidamente feedback do cliente sobre
possíveis mudanças.
Entretanto, McBreen (2002) comenta que mesmo com o acompanhamento de
um analista de sistemas, a pessoa que representa o cliente deve possuir sólidos
conhecimentos sobre o domínio da aplicação e autoridade suficiente para tomar
decisões rápidas sobre a direção global do projeto.
2.4.13 Padrões de Programação
Os desenvolvedores devem escrever o código da mesma forma, respeitando as
regras que enfatizam comunicação através de código. Conforme Astels (2002) salienta,
é possível programar em par porque os parceiros trabalham no mesmo formato; todos
podem ter a propriedade do código porque todos escrevem o código no mesmo estilo; o
refactoring é possível porque todos entendem o formato do código; pode-se trabalhar de
forma ágil porque não precisa reformatar o código durante o trabalho.
Jeffries (2001) afirma que as particularidades do código não são importantes, o
que é importante é que todo o código deve parecer familiar.
37
2.5 Ciclo de Vida do Método XP
O ciclo de vida do método XP consiste em seis fases: Exploração, Planejamento,
Iteração, Produção, Manutenção e Fase Final. Cada uma destas fases possui práticas
distintas que devem ser executadas de forma a validar a passagem para a próxima fase.
Os tópicos a seguir detalham estas fases.
a) Exploração:
De acordo com Wake (2002) a fase de exploração é o momento em que se
obtém a visão geral do sistema a ser desenvolvido e se começa a estimar a partir deste
conhecimento. Esta fase inicia com a participação do cliente criando histórias em
pequenos cartões (suficientes para a primeira iteração), que são utilizados para definir
um escopo inicial do sistema e devem compor o primeiro release (ABRAHAMSSON,
2002).
O programador estima o tempo e as dificuldades para implementar as histórias.
Isso ocorre consecutivamente até que todas as histórias requeridas para a fase do
planejamento estejam estimadas (WAKE, 2002).
Uma atividade inicial da fase de exploração consiste na equipe de
desenvolvimento eleger, configurar e testar as ferramentas que serão usadas no projeto.
Enquanto a equipe estiver treinando com a tecnologia, o cliente está praticando a escrita
de histórias (BECK, 2004).
b) Planejamento:
Após a fase de exploração inicia-se a fase de planejamento, nela ocorre o jogo de
planejamento, cujo propósito é que a equipe e o cliente definam uma data de entrega de
um conjunto de histórias a ser implementado, ou seja, o final do release. Segundo Beck
(2004), esse planejamento gera um cronograma de comprometimento definido de
acordo com estimativas entre cliente e desenvolvedores.
38
O jogo de planejamento é um exercício cooperativo de determinação de
prioridades (ASTELS, 2002). Nessa fase, o jogo de planejamento permite ao cliente
definir quais são as histórias vitais que devem fazer parte da primeira versão. Os
desenvolvedores devem utilizar sua experiência para estimar o tempo necessário para
implementar as histórias.
Os desenvolvedores escolhem as histórias que irão implementar a cada dia de
trabalho. Porém, existem casos em que o cliente formula histórias maiores que o
tamanho usual e os cartões acabam representando histórias que consomem mais tempo
para a implementação. Nestes casos, é comum dividir-se o conteúdo do cartão em
tarefas menores, assim, cada desenvolvedor escolhe a tarefa que irá implementar
(WAKE, 2002).
c) Iteração:
Conforme já mencionado, no método XP mesmo que as entregas sejam
realizadas em freqüentes períodos de tempo elas são divididas por um determinado
número de iterações. Uma iteração é basicamente um espaço de tempo dedicado ao
desenvolvimento do software, incluindo modelagem, programação, teste e integração.
A primeira iteração é especial no método XP porque define a arquitetura do
sistema a partir do qual todas as outras serão criadas. A entrega de uma primeira versão
central do sistema é um marco importante, pois ela pode provar para o cliente que a XP
funciona e ao mesmo tempo isto aumenta a motivação da equipe, que passa a acreditar
mais no trabalho (ASTELS, 2002).
Beck (2004) lembra que para cada história executada em uma iteração é
produzido um conjunto de testes funcionais, assim do final de cada iteração o cliente
terá completado a execução de todos os testes funcionais e no final da última iteração o
sistema estará pronto para entrar em produção.
39
d) Produção:
A fase de produção do sistema pode iniciar quando o ciclo de feedback é
encerrado, ou seja, no final de uma versão.
Ambler (2004) afirma que a fase de produção deve representar a garantia de que
o software esteja pronto para entrar em produção. Nesta fase intensificam-se os testes de
sistema, de carga e de instalação a fim de se avaliar se o software realmente está pronto
para ser e entregue ao cliente (BECK, 2004).
e) Manutenção:
A fase de manutenção é o estado normal de um projeto XP. Nesta fase deve-se
produzir novas funcionalidades, manter o sistema existente funcional, e fazer ajustes na
equipe de desenvolvimento, caso seja necessário, como substituir e incorporar novos
membros no projeto (BECK, 2004).
Desta forma, na fase de manutenção pode-se tentar fazer refactoring maiores,
testar novas tecnologias que podem ser incorporadas nas próximas versões e até mudar
a tecnologia que se está usando, além disso, o cliente pode escrever novas histórias.
Depois que o primeiro release é produzido para o uso do cliente, o projeto XP
deve manter o sistema de produção executando enquanto produz novas iterações. Para
fazer isto, a fase de manutenção requer o esforço do cliente para ajudar nas tarefas.
f) Fim do Projeto:
A XP recomenda que quando o cliente e a equipe perceberem a inexistência de
novas histórias para produzir presume-se que as funcionalidades requeridas foram todas
implementadas e é chegada a hora de finalizar o projeto (BECK, 2004).
Durante essa fase é importante documentar, de forma não muito intensa, a
funcionalidade do sistema, como uma garantia de que existirá uma referência para
futuras alterações no sistema (BECK, 2004).
40
Beck (2004) recomenda que no final do projeto é interessante que a equipe se
reúna para reavaliação do projeto. Nesta reunião se faz o levantamento de que aspectos
positivos e negativos servirão como experiência para projetos futuros.
A figura 1 demonstra um exemplo das fases do ciclo de vida de um projeto XP.
Exploração Atualizações freqüentes
Histórias
Planejamento
Histórias para o
próximo release
Propriedades
Estimativas de esforço
Iteração
Programação pareada
Análise Planejamento
para testes Design Testes
Produção
Release
Manutenção
Atualização do
release
Final
Release
final
Figura 1: Ciclo de vida XP. Adaptado de Abrahamsson (2002).
2.6 A Sinergia das Práticas XP
Para Abrahamsson (2003) grande parte da XP é formada por práticas já
conhecidas da engenharia de software, mas no método XP as práticas são alinhadas e
agrupadas de forma a se interligarem umas as outras, conforme demonstra a figura 2.
Testes
Feedback
Código coletivo
Integração contínua
Aprovação do cliente
Revisão continua
41
Figura 2: A interligação das práticas XP. Adaptado de Beck (2004).
Beck (2004) ressalta que as práticas apóiam-se umas nas outras. A seguir são
relatadas algumas das interligações possíveis entre as práticas XP que permitem que os
pontos fracos de algumas práticas sejam compensados pelos pontos fortes de outras
(BECK, 2004):
a) Jogo do Planejamento: Além de definir as histórias da primeira iteração a
equipe XP deve usar o jogo de planejamento para definir uma estrutura básica do
sistema, mesmo sabendo que esta será incrementalmente modificada. Durante o jogo de
planejamento o cliente, reunido com a equipe, avalia as funcionalidades que devem ser
implementadas e prioriza aquelas que farão parte do próximo release e da próxima
iteração.
b) Releases: Esta prática relaciona-se com a prática Jogo de Planejamento, que
define as prioridades das histórias que deverão ser implementadas; com a prática
Integração Contínua, que minimiza o custo de empacotar uma versão, e com os testes,
que reduzem a taxa de erros.
Metáfora
Código coletivo
Cliente sempre presente
Jogo de planejamento
Integração continua
Ritmo sustentável
Design simples
Refactoring
Programação em par
Código padronizado
Desenvolvimento guiado por testes
Entregas
42
c) Metáfora: As metáforas representam uma linguagem mais simples e
acessível ao cliente, sendo que o grau de sucesso ao serem transformadas em código
funcional dependerá de práticas como feedback do código e testes para verificar se a
metáfora funciona na prática.
d) Design Simples: Na Programação pareada, a comunicação entre os
desenvolvedores deve gerar confiança para que se tome a decisão mais simples, porém
coerente. A prática refactoring, com o tempo, também deve gerar maior confiança para
a simplificação do projeto.
e) Integração Contínua: A viabilidade da integração contínua está associada a
práticas como a programação pareada (reduzindo o número de modificações que devem
ser integradas); à prática de testes (valida a metáfora); e à prática de refactoring (divide
o código em partes menores e mais fáceis de identificar possíveis erros).
f) Propriedade Coletiva: A prática da propriedade coletiva do código também
necessita de outras práticas XP para viabilizá-la, como: integração contínua (integrando
a mudanças em um período de tempo relativamente curto, os conflitos deverão ser de
menor impacto); testes (diminui as chances de prejudicar a funcionalidade do código
acidentalmente); programação pareada (diálogo e revisão entre a dupla podem diminuir
a probabilidade de ocorrer alterações que prejudiquem a funcionalidade do código);
padrões de programação (facilita a compreensão do código por toda a equipe).
g) Padrão de Programação: É imprescindível que a equipe esteja disposta a
seguir um padrão de programação, sendo que diversas práticas XP dependem
diretamente dela para terem sucesso, como a programação pareada, propriedade coletiva
e refactoring.
Beck (2004) ressalta que com exceção da prática de testes, as demais práticas
XP podem não fazer muito sentido ou não funcionarem bem sozinhas, requerendo
outras práticas para manterem-se equilibradas.
43
2.7 XP e os Métodos Tradicionais de Desenvolvimento de Software
Para se ter noção das inovações propostas pelo método XP, Wege (2001) realiza
uma comparação entre aspectos presentes nos métodos tradicionais de desenvolvimento
de software e os aspectos do método XP, conforme a tabela 1.
Métodos Tradicionais Método XP
Contatos limitados com o cliente Cliente dedicado à equipe
Design amplo e centralizado Design aberto e evolutivo
Projetar para funcionalidades futuras Projetar apenas os requisitos atuais
Implementação complexa Simplicidade radical
Desenvolvedores programando de forma isolada
Programação pareada
Tarefas determinadas Tarefas a serem determinadas
Poucas e grandes integrações de código Pequenas e contínuas integrações de código
Receio Agressividade
Ambiente de testes ad hoc Testes de unidade e testes de aceitação
Comunicação limitada e de cima para baixo Intensa comunicação
Tabela 1: Método Tradicional versus XP. Adaptado de Wege (2001).
Conforme se infere da tabela acima, a XP consiste numa série de práticas e
regras que se opõem às premissas adotadas pelos métodos tradicionais de engenharia de
software, baseando-se na integração permanente entre a equipe de desenvolvimento e o
cliente.
O método XP pressupõe a presença do cliente como um membro efetivo do
processo de desenvolvimento ao invés de manter apenas contatos esporádicos. A
presença do cliente no ambiente de desenvolvimento viabiliza o feedback constante com
44
a equipe e permite a especificação dos requisitos do software, os quais são projetados
apenas para determinadas funcionalidades. Estas funcionalidades serão implementadas
em um período de tempo e modificadas conforme a necessidade, ao contrário do
habitual planejamento inicial e completo de todo o sistema.
O método XP exige desenvolvedores de software programando em par, sendo
que estes também devem possuir autonomia para escolher junto com o cliente quais as
prioridades a serem codificadas e para adotar a solução mais simples para suas tarefas.
A evolução do projeto é garantida por um rigoroso sistema de testes (inclusive
com a participação do cliente) e várias integrações de código durante o dia de trabalho.
Os desenvolvedores devem desenvolver o software com simplicidade e manter
comunicação intensa, a fim de que todos estejam informados sobre o trabalho dos
colegas.
2.8 Adoção do Método XP
Rumpe (2002), ao realizar pesquisas em empresas produtoras de software que
utilizaram o método XP em seus projetos, constatou diferentes aspectos relacionados à
adaptação ao método. Entre os aspectos averiguados encontra-se o grau de dificuldade
sentido pelas equipes em relação à realização das práticas XP, bem como seu índice de
adoção - conforme pode ser visto na figura 3.
45
Figura 3: Dificuldades na aplicação de práticas e valores XP. Adaptado de Rumpe (2002).
As pesquisas de Rumpe (2002) demonstram que o uso de metáforas para
expressar as funcionalidades do projeto é a prática XP que as equipes mais encontraram
dificuldade de realizar. Quanto à participação permanente do cliente como um membro
efetivo da equipe, as respostas dos entrevistados dividiram-se entre as seguintes
afirmações (RUMPE, 2002):
a) É difícil convencer o cliente a participar efetivamente do projeto;
b) O cliente geralmente está muito ocupado com preocupações do próprio
negócio;
c) Alguns acreditam que não é necessária a participação do cliente o tempo
todo no projeto;
d) O cliente não está capacitado para escrever histórias.
2,2%
27,4%
4,4%
6,7%
15,6%
15,6%
20,0%
20,0%
31,1%
66,7%
68,9%
0% 10% 20% 30% 40% 50% 60% 70% 80%
Integração Continua
Código Compartilhado
Releases Curtos
40 horas semanais
Programação em par
Projeto Simples
Código Padronizado
Refactory
Jogo de Planejamento
Cliente Local
Metáfora
46
Em relação aos fatores que contribuem para o sucesso dos projetos XP, os
entrevistados atribuíram a efetividade do projeto principalmente aos testes e à
programação pareada (conforme a figura 4).
Figura 4: Fatores de sucesso identificados em projetos XP. Adaptado de Rumpe (2002).
Apesar de se reconhecer que a efetividade dos projetos XP depende da
programação pareada, é comum surgirem nas empresas de software mitos em relação a
esta prática. Williams e Kessler (2002) enumeram os mitos mais comuns:
a) “Dobrará a carga de trabalho, pois dois desenvolvedores fazem o trabalho
que um poderia fazer”: Gerentes podem entender que o custo de desenvolvimento de
software irá aumentar com a prática de programação pareada. Cockburn (2003)
investigou os custos e os benefícios da programação do par e concluiu que há um
aumento no custo de aproximadamente 15% no tempo de desenvolvimento de software,
2,2%
8,9%
11,1%
11,1%
13,3%
17,8%
17,8%
17,8%
0% 2% 4% 6% 8% 10% 12% 14% 16% 18% 20%
Integração Continua
Equipe Motivada
Desenvolvedores bem treinados
Priorização de tarefas e planejamento de cartões de
histórias
Comunicação com o cliente
Objetivos XP: qualidade, reuniões frequentes com o cliente
Programação em Par
Testes
47
porém foram registradas melhoras na qualidade do projeto, redução de defeitos,
melhoras na qualidade técnica e na comunicação entre os membros da equipe.
b) “Ao adotar a programação pareada se estará eliminando a programação
individual”: Este mito definitivamente não condiz com a realidade, pois não há nenhum
mecanismo que obrigue os desenvolvedores a programar em par em tempo integral. A
técnica pode ser usada apenas durante uma parte do dia ou durante a realização de
tarefas mais complexas, sendo que no restante do tempo pode prevalecer a programação
individual.
c) “Programação pareada funciona apenas com o par ideal”: Para Williams e
Kessler (2002) a programação pareada funciona com a maioria das pessoas, porém
certamente há circunstâncias em que ela não se ajusta, como por exemplo, em caso de
pessoas que possuam personalidade difícil e imponham seu modo de pensar e
desenvolver software.
Sobre a possibilidade de formar um par de programadores contendo um
programador experiente e um programador novato - o que geralmente gera
questionamentos – é aconselhável que o experiente assuma o papel de mentor da dupla,
enquanto o novato procura aprender com seu colega. Williams e Kessler (2002)
afirmam que neste caso, o conhecimento absorvido gradativamente pelo programador
novato deverá contribuir para o desempenho da equipe.
d) “Programação de Par é boa para treinar, porém, quando certo nível de
conhecimento for obtido passa a ser desperdício de tempo”: Certamente são gerados
benefícios no caso da prática ser realizada entre um programador novato e um
programador experiente. Porém a programação pareada pode ser também benéfica para
uma dupla de programadores experientes, a qual pode ser alocada para resolver tarefas
com complexidade maiores.
e) “É dispendioso manter um dos desenvolvedores concentrado apenas em
erros de sintaxe na programação pareada”: Um dos principais benefícios da
programação pareada é a revisão de código ininterrupta. É válido considerar que quando
um desenvolvedor explica seu trabalho para o outro já está difundindo o conhecimento
48
sobre suas tarefas, e na XP todos devem estar informados sobre o andamento geral do
processo de desenvolvimento. Além da revisão de erros de sintaxe, o programador pode
questionar e guiar o parceiro para o caminho desejado.
f) “Os desenvolvedores só conseguem concentração e rendimento
programando de forma isolada”: Segundo Williams e Kessler (2002), muitos dos que
acreditavam que não conseguiriam o fluxo mental necessário programando em par
verificaram que as duas mentes juntas são melhores que uma sozinha. Os dois
programadores operam como um organismo inteligente e compartilham um aumento de
fluxo em comum, explorando mais possibilidades.
As pesquisas de Rumpe (2002) também abordam os fatores de riscos que podem
impedir o sucesso de projetos XP. Os entrevistados responderam que os aspectos mais
críticos são: a ausência ou pouca disposição do cliente local, a oposição à XP por parte
dos envolvidos no projeto e os problemas técnicos (conforme figura 5).
Alguns dos entrevistados consideram que a ausência do cliente local pode ser
suprida com objetivos claros e reuniões freqüentes, para outros a ausência do cliente
local poderia gerar falta de foco no projeto. Alguns entrevistados acham extremamente
difícil trabalhar com o cliente devido a sua falta de conhecimentos técnicos e por uma
suposta relação de adversidade entre o cliente e os desenvolvedores.
Em relação à oposição à XP, Rumpe (2002) afirma que esta pode ocorrer tanto
na equipe quanto por parte da gerência ou até mesmo por parte do cliente.
49
Figura 5: Fatores de riscos em projetos XP. Adaptado de Rumpe (2002).
Conforme demonstrado anteriormente, Rumpe (2002) disponibiliza uma série de
evidências empíricas sobre o uso da XP em projetos de software, porém pode-se notar
que suas pesquisas possuem um escopo limitado. Para McBreen (2002), os aspectos que
refletem na aceitação da XP e que devem ser considerados pelas empresas de software
são:
a) A possibilidade de ter o cliente sempre presente: É necessário poder contar
com o cliente ou um representante do mesmo que esteja capacitado para tomar as
decisões que lhe cabe. Se isto não for possível, um dos desenvolvedores pode fazer o
papel do cliente, mas isto não é recomendado no primeiro projeto XP.
b) Requisitos flexíveis: O real benefício dos métodos ágeis é que estes
possibilitam que a equipe desenvolva software apesar das alterações dos requisitos que
foram originalmente definidos. Assim, torna-se necessário que os requisitos sejam
flexíveis para que se utilize a XP de forma satisfatória.
c) A possibilidade de se adquirir um bom treinador para a equipe: É preciso
contar com um treinador que realmente conheça a XP, que já tenha presenciado sua
utilização em outra equipe e observado como o método desenvolve-se.
8,9%
11,1%
15,6%
15,6%
28,9%
0% 5% 10% 15% 20% 25% 30%
Desenvolvedores pouco
capacitados
Treinamento XP insuficiente
Problemas tecnológicos -
ferramentas insuficientes
Oposição ao XP por alguns
participantes
Ausência do cliente
50
d) O tamanho e a complexidade do projeto: O projeto deve possibilitar à equipe
entregar a funcionalidade desejada em aproximadamente 6 a 18 meses. Os melhores
projetos são os aqueles em que o cliente pode presenciar os reais benefícios da entrega
rápida e parcial, de forma que a equipe possa fazer uma produção e entregar dentro de
dois ou três meses. Se não for possível realizar entregas parciais dentro de três meses, o
projeto provavelmente é muito complexo para a primeira experiência com a XP.
e) A possibilidade de alocar a equipe em um mesmo ambiente: Segundo
McBreen, depois de se ter experiência com a XP é possível realizá-la com equipes
maiores e/ou distribuídas, mas inicialmente é necessário que os desenvolvedores
trabalhem em um ambiente único.
f) O comprometimento da equipe: Se a equipe toda não estiver comprometida
com a XP, a tentativa de adotá-la acabará fracassando. Se os desenvolvedores se
recusarem a programar em par, realizar testes continuamente e utilizar código coletivo o
projeto torna-se inviável.
g) A flexibilidade no tempo de entrega: Se houver uma data fixa (de forma
rígida) na qual uma certa quantia de funcionalidade deve ser entregue é arriscado adotar
qualquer processo de desenvolvimento de software novo. Com o tempo a equipe XP
alcança uma maior previsibilidade das entregas, mas inicialmente pode ser difícil.
Além dos aspectos destacados pelos autores anteriormente citados, ainda
existem outros que exercem influência na adoção da XP, como por exemplo, mercado
alvo da empresa, tipo de software desenvolvido, perfil do cliente, eventual terceirização
de projetos, bem como a cultura e a estrutura organizacional da empresa de software.
Esta dissertação privilegia o estudo da influência dos aspectos culturais e
estruturais da empresa na adoção da XP, tendo em vista que esse método não deve ser
concebido apenas como um processo, pois os princípios que o orientam devem estar
consolidados na cultura das pessoas que formam a empresa de software (ASTELS,
2002).
Torna-se necessário considerar que a XP baseia-se na criação de software de alta
qualidade sendo fortemente orientada para pessoas, indo contra o senso comum de
51
gerenciamento de que os desenvolvedores são peças intercambiáveis dentro de suas
máquinas de processar software (ASTELS, 2002).
Pelo que se pode inferir na verificação das práticas e valores XP, para realizá-las
é preciso dispor de equipes de desenvolvimento de software altamente capacitadas,
motivadas e comunicativas, formadas por desenvolvedores que codificam intensamente
e sejam capazes de programar em par. Por outro lado, também é necessário que a
estrutura administrativa lhes proporcione as condições ideais para a forma de trabalho
requerida pela XP.
Para ter realizado todas as práticas que deram origem ao método XP certamente
Kent Beck encontrou na empresa em que trabalhava fatores organizacionais favoráveis
que lhe permitiram desenvolver software de tal modo.
No entanto, as organizações diferem em aspectos culturais e estruturais, de
forma que se torna importante que as empresas de software que pretendam adotar a XP
verifiquem se existe adequação dos seus fatores organizacionais ao método. Neste
exercício, há possibilidade de se constatar até mesmo a incompatibilidade dos fatores
organizacionais, o que pode inviabilizar a adoção da XP.
Beck (2004) afirma que a maior barreira para o sucesso de um projeto XP é a
cultura organizacional. Qualquer negócio que gerencie projetos tentando mudar
aspectos culturais se deparará com conflitos na equipe de desenvolvimento. Conforme
McBreen (2002), quando se resolve adotar um método de desenvolvimento de software
é preciso ter certeza que o mesmo se ajusta à organização e às pessoas que trabalham
nos projetos. Ou seja, o novo método tem que ser compatível com o perfil dos membros
da organização.
Desta maneira, torna-se necessário inicialmente entender o que significam
cultura e estrutura organizacional (capítulo 3) e, posteriormente, verificar como estes
fatores influenciam na adoção da XP (capítulo 4).
52
3. CULTURA E ESTRUTURA ORGANIZACIONAL
3.1 Cultura Organizacional
3.1.1 Definição
Cultura é definida pelo antropólogo inglês Tylor (apud LARAIA, 1996) como
sendo "todo complexo que inclui conhecimento, crença, arte, moral, lei, costume e
quaisquer outras capacidades e hábitos adquiridos pelo homem como membro da
sociedade". Laraia (1996) salienta que o conceito de cultura que é apresentado por Tylor
tem a vantagem de abranger todas as possibilidades de realização humana, além de
marcar fortemente o caráter de aprendizado da cultura em oposição à idéia de aquisição
inata.
De acordo com o dicionário de sociologia (JOHNSON, 1997), “cultura é o
conjunto acumulado de símbolos, idéias e produtos materiais associados a um sistema
social, seja ele uma sociedade inteira ou uma família”.
Das áreas da sociologia e da antropologia os estudos a respeito da cultura foram
levados ao âmbito das organizações, já que estas representam, em menores proporções,
as características e valores da sociedade em que estão inseridas e, além disso, são de
fato organismos sociais de menor porte que criam, desenvolvem ou manifestam uma
cultura própria (COSTA, 1999).
Relacionando esses significados do termo “cultura” - antropológico e
sociológico – com as organizações, verifica-se que cultura se refere a um conjunto de
conhecimentos que foram criados e são desenvolvidos pelos integrantes de uma
empresa. Da mesma forma que em um país, em uma região ou em uma família se
desenvolve uma cultura, em uma organização também ocorre a criação e o
53
desenvolvimento de uma cultura própria, a qual encerra aspectos antropológicos,
sociológicos e históricos da empresa.
A cultura de uma empresa reflete suposições a respeito de seus objetivos, as
quais se convertem em atividades que são consideradas por todos como adequadas para
a organização, sendo continuamente repetidas até se transformarem em normas de
conduta que se espera que os membros respeitem.
A organização é então entendida como estrutura social, ou seja, como um
sistema em que coexistem grupos de pessoas interagindo segundo padrões de
comportamento aceitáveis mutuamente, cada uma com plena ciência do que dela espera
o grupo e do que ela pode esperar do grupo (COSTA, 1999).
A idéia de encarar as organizações como culturas - onde há concepções
compartilhadas entre os membros - é um fenômeno relativamente recente. Há vinte anos
as organizações eram vistas como instrumentos racionais - numa visão tipicamente
mecanicista - para coordenar e controlar um grupo de pessoas (ROBBINS, 1999).
Assim, departamentos, linhas de autoridade e hierarquias constituíam a visão
que as pessoas possuíam das organizações, mas estas tendem a ser muito mais do que
isso, já que, de maneira similar aos indivíduos, elas possuem sua própria personalidade,
podendo ser rígidas ou flexíveis, inovadoras ou conservadoras, etc. (ROBBINS, 1999).
Embora alguns estudos sobre cultura organizacional já tivessem sido realizados
antes da década de 80, o tema consolidou-se e passou a ser mais abordado na literatura a
partir do surgimento das obras dos seguintes autores (BAKER, 2000): William Ouchi
(1981); Pascale e Athos (1982); Deal e Kennedy (1982); Peters e Waterman (1982).
O interesse pela cultura organizacional decorreu principalmente da necessidade
de reverter o declínio da produtividade das empresas norte-americanas em contraponto
ao aumento da competitividade das empresas japonesas. Os estudos na área têm por
base a premissa de que por meio da análise de cultura organizacional é possível
encontrar respostas para problemas como a perda de coesão e de uniformidade dos
padrões culturais, os quais geram heterogeneidade e fragmentação nas interações sociais
e provocam a baixa da produtividade (FREITAS, 1990).
54
As obras dos autores acima citados sugerem que a cultura organizacional pode
ser a chave para melhorar o desempenho da organização, podendo ser gerenciada para
aperfeiçoar a competitividade. Essas obras fornecem prescrições práticas para os líderes
dos negócios americanos, que necessitavam de ajuda para obter sucesso em face da
crescente competição japonesa (BAKER, 2000).
Conceituar o termo “cultura organizacional” não é uma tarefa fácil. Nos últimos
anos, um grande número de pesquisadores tem tentado definir, entender e
operacionalizar o conceito de cultura organizacional, mas, como salienta Ott. J. Steven
(1989), não há nenhuma definição estabelecida na literatura.
Para Dennison (1990), a cultura de uma organização inclui seus costumes, suas
tradições e a maneira de trabalhar, estando largamente ligada à história da empresa, isto
é, como a empresa tradicionalmente trabalha e como alcança seus objetivos. Uma
definição mais simples de cultura organizacional é dada por Johnson (1999): “o modo
como se faz as coisas por aqui”.
Edgar H. Schein (1985), um pioneiro no estudo de cultura organizacional e um
dos autores mais citados na literatura especializada, define-a como sendo “um conjunto
padrão de suposições básicas que o grupo inventou, descobriu, ou desenvolveu ao
aprender a enfrentar problemas de adaptação externa e integração interna e que
funcionou bem o suficiente para ser considerado válido e, então, ser ensinado aos novos
membros como o modo correto de perceber, pensar e sentir em relação a esses
problemas”.
Para Chiavenato (1999) a cultura organizacional refere-se ao sistema de
significados compartilhados por todos os membros e que distingue uma organização das
demais. Constitui o modo institucionalizado de pensar e agir em uma organização,
sendo que sua essência é expressa pela maneira como ela faz seus negócios, pela forma
como trata seus clientes e funcionários, e pelo grau de autonomia dado aos seus
membros.
Além do mais, a cultura organizacional representa as percepções dos dirigentes e
funcionários da organização, refletindo a mentalidade que predomina na empresa,
55
condicionando, por esta razão, a administração das pessoas. A cultura da organização
proporciona um referencial de padrões de desempenho entre os funcionários,
influenciando sua produtividade e a preocupação com a qualidade e o serviço ao cliente
(CHIAVENATO, 1999).
Os diversos conceitos e definições dados pelos estudiosos da área têm causado
muitas discussões a respeito de cultura organizacional, sendo que Schein (1985) alerta
para o fato de que a ausência de uma definição clara leva a confundir as manifestações
culturais e o próprio conceito de cultura.
De qualquer forma, tem-se por indiscutível a importância da cultura nas
organizações, uma vez que as empresas são influenciadas pelo ambiente no qual estão
situadas e também pela visão e decisões de seus membros. Robbins (1999) entende que
a cultura organizacional desempenha função de:
a) definir os limites, ou seja, cria distinções entre uma organização e outra;
b) transmitir um sentido de identidade aos membros da organização;
c) facilitar a criação de um compromisso pessoal com algo mais amplo que os
interesses individuais;
d) intensificar a estabilidade do sistema social. A cultura é o vínculo social que
ajuda a manter unida a organização (é a “cola social”);
e) servir como mecanismo de controle que guia o comportamento dos membros
da organização.
Nesse sentido, Martin e Siehl, (1983) sublinham que a cultura organizacional é
uma poderosa alavanca para orientar o comportamento organizacional, aprovando ou
restringindo informalmente alguns padrões de comportamento. Desta forma, a cultura
organizacional representa padrões culturais que regem os comportamentos individuais
na organização, estabelecendo um senso comum e uma integração interna. Além disso,
a cultura ajuda a organização a se adaptar ao ambiente externo.
56
As pessoas que transformam a organização (fundadores e dirigentes) ao
transacionar com o meio ambiente e ao criar as estruturas internas para responder a essa
interação externa, estabelecem uma maneira própria de agir e interagir. Com isso criam
a identidade da empresa. Uma cultura estabelece uma marca reconhecível, pelos de
dentro e pelos de fora, através da exteriorização em formas variadas, de uma visão de
mundo, de um modo próprio de fazer as coisas e de interagir, que emerge - pela
estrutura interna do poder - da configuração especial criada internamente para responder
às peculiaridades no meio externo (TAVARES, 2002).
A cultura de uma organização é ensinada para os novos membros através do
processo de socialização, sendo que os verdadeiros aspectos da cultura somente são
repassados quando o novo membro é efetivamente aceito socialmente na empresa
(SCHEIN, 1985).
A princípio, os novos membros só aprendem os aspectos superficiais da cultura,
visto que a sua essência só é revelada aos membros que passam a entrar nos círculos dos
grupos onde estão os valores partilhados. Desta forma, a cultura é entendida e
compartilhada, sendo que os novos membros são expostos aos valores e crenças que já,
inicialmente, desenvolveram-se na empresa, passando a assimilá-las.
Mesmo admitindo-se que dentro de uma organização possam surgir subculturas,
isto é, culturas próprias em cada grupo ou departamento da organização, Schein (1985)
afirma que se for possível observar certos pressupostos compartilhados entre diversas
unidades, pode-se falar de uma única cultura organizacional (cultura dominante) mesmo
que as subunidades tenham peculiaridades próprias.
A cultura dominante expressa os valores centrais que são partilhados pela
maioria dos membros da organização, e quando se fala em cultura de uma organização,
trata-se da sua cultura dominante. Embora se reconheça que muitas empresas tenham
subculturas que possam orientar o comportamento dos membros, é o aspecto
compartilhado que está presente na cultura dominante que a torna capaz de orientar e
moldar o comportamento dos membros (ROBBINS, 1999).
57
Nesse panorama, distingue-se cultura forte de cultura fraca. A cultura é forte se
os valores centrais da organização são intensamente mantidos e amplamente
partilhados, sendo que a cultura tem um impacto maior sobre o comportamento dos
membros. Neste caso verificam-se baixos níveis de rotatividade dos membros - há
menor probabilidade dos membros deixarem a empresa – e de formalização – face à
coesão do grupo há menor necessidade de documentação escrita (ROBBINS, 1999).
Muitos autores têm ressaltado que a cultura organizacional reflete na
produtividade, no desempenho, no comprometimento, no comportamento ético e na
autoconfiança dos membros de uma empresa. Chiavenato (1999) salienta que certas
culturas podem ser mais propensas a adaptação a mudanças e a melhorias do
desempenho da organização, enquanto outras não. Para Deal e Kennedy (1982), a
cultura é o fator mais importante no sucesso ou no fracasso da organização.
É importante ressaltar que quando se conhece a cultura de uma organização
entende-se um pouco melhor fatores como processos internos de tomada de decisão, a
comunicação entre os membros, a evolução do desempenho e do controle, além disso,
também se pode compreender o produto ou serviços que a empresa presta ao
consumidor, já que os mesmos são condicionados pela cultura organizacional.
58
3.1.2 Elementos da Cultura Organizacional
Além da variedade de conceitos a respeito da cultura organizacional, existe
ainda uma variedade de elementos da mesma que são identificados pelos autores da
área. Ott. J. Steven (1989), realiza um extenso estudo a respeito do conceito de cultura
organizacional e, ao tratar dos elementos, apresenta uma lista compostas por setenta e
três palavras ou frases usadas pelos autores para defini-los. Dentre as quais se destacam:
• Visão compartilhada
• Atitudes
• Crenças
• Celebrações
• Padrões de comunicação
• Costumes
• Modo de fazer as coisas
• Ética organizacional
• Sentimentos
• Hábitos
• Heróis
• Ideologia
• Padrões de interação
• Justificativa para o padrão
comportamental
• Práticas de gerenciamento
• Normas
• Organização física do local
• Ritos
• Sistemas de regras informais
• Estórias
• Símbolos
• Tradições
• Valores
• Reflexo dos mitos na forma de
agir e de se relacionar
59
Os elementos da cultura organizacional mais freqüentemente mencionados pela
literatura são:
3.1.2.1 Valores
Para Alves (1997) valores são noções compartilhadas que as pessoas têm do que
é importante e acessível para o grupo ao qual pertencem. Deal e Kennedy (1982)
conceituam valores como sendo as crenças e conceitos básicos de uma organização. Os
valores definem o sucesso em termos concretos para os membros da organização e
estabelecem os padrões que devem ser atingidos, representando um senso de direção
comum para todos, sendo, desta forma, compartilhados pelo grupo.
Em outras palavras, os valores são as definições do que é importante para que a
empresa atinja as suas metas. Os valores tendem a ser personalizados pelas
organizações conforme sua realidade, porém é possível identificar características
comuns em todas as organizações, como: importância do cliente, padrão de desempenho
excelente, qualidade e inovação, importância da motivação dos membros da
organização (FREITAS, 1991).
3.1.2.2 Ritos, Rituais e Cerimônias
Constituem um conjunto relativamente elaborado, dramático e planejado de
atividades, que consolidam várias formas de expressão cultural de um evento, o qual é
realizado por meio de interações sociais, geralmente para o beneficio da audiência e
com múltiplas conseqüências sociais (TRICE; BEYER, 1984).
Bass (1990) define rito como um conjunto de atividades que consolida formas de
expressão cultural, sendo transmitido através de interações sociais, usualmente em
beneficio do grupo.
Trice e Beyer (1984) identificaram seis tipos de ritos: 1- Ritos de passagem: o
processo de introdução e treinamento básico; 2- Ritos de degradação: o processo de
despedir e substituir alguém; 3- Ritos de confirmação: seminários para reforçar a
identidade social e seu poder de coesão; 4- Ritos de reprodução: atividades de
desenvolvimento organizacional; 5-Ritos para redução de conflito: processos de
60
negociação coletiva; 6- Ritos de integração: por exemplo, festa de natal nas
organizações.
Os ritos são atividades planejadas e têm conseqüências práticas e expressivas
que determinam o comportamento dos membros na organização e tornam a cultura
organizacional mais coesa (FREITAS, 1991).
3.1.2.3 Mitos e Estórias
Trata-se de uma crença inquestionável sobre os benefícios práticos de certas
técnicas e comportamentos que não estão baseados em fatos reais. Por sua vez, estórias
são uma narrativa baseada em eventos reais – freqüentemente uma combinação de
realidade e ficção (BASS, 1990).
Ambos relacionam-se a eventos. As estórias referem-se a eventos ocorridos
(fatos) que estão ligados à organização, reforçando o comportamento existente. Esses
fatos informam aos integrantes da organização como os grupos fazem determinadas
coisas e desta forma, estabelecem regras.
3.1.2.4 Tabus
Tabus são demarcações criadas informalmente nas empresas a respeito de
“áreas” proibidas, com o propósito de indicar um comportamento aceitável e proteger a
empresa de contestações e questionamentos. Os tabus enfatizam o “não-permitido” (por
exemplo, impõe a não discussão sobre as decisões da gerência) e evidenciam o aspecto
disciplinar. Quanto menos tabus existirem, mais íntegra e democrática poderá ser a
empresa (ALVES, 1997).
3.1.2.5 Heróis
Possuem a função de personificar os valores e condensar a força da empresa. Os
heróis tendem a apresentar características como: ser experimentado, apreciar
cerimônias, ter visão, ser intuitivo. O exemplo do herói pode estimular os membros a
estabelecer determinados padrões de desempenho (FREITAS, 1991). Os gerentes não
são necessariamente a personificação do herói, este pode ser um membro da equipe que
represente os principais valores compartilhados.
61
Freitas (1991) relaciona algumas funções dos heróis: tornam o sucesso atingível
e humano, assim os membros podem seguir seu exemplo; fornecem modelos a serem
seguidos pelos membros da empresa que almejam alcançar as qualidades do herói;
simbolizam a empresa para o mundo exterior; estabelecem padrões de desempenho;
motivam os empregados, fornecendo influência duradoura.
3.1.2.6 Crenças e Pressupostos
Crença é a compreensão que as pessoas têm como certa e que serve de base para
o entendimento das coisas. É a concordância com um juízo produzido sob a influência
de alguém ou de algo em que se confia (ALVES, 1997).
Já os pressupostos são conjunturas antecipadas ou respostas prévias sobre um
determinado assunto. Um problema resolvido satisfatoriamente em uma empresa
desaparece da consciência e pode se tornar um pressuposto, ou seja, passa a ser uma
solução pronta, disponível e, até certo ponto, inquestionável para o grupo (ALVES,
1997).
As crenças e os pressupostos representam o que há de consolidado na empresa,
são geralmente conceitos tidos por inquestionáveis. Exemplos de conteúdo das crenças
são fornecidos por Peters e Waterman apud Freitas (1991): assistência e qualidade
superiores, membros inovadores, informalidade e estimulo à comunicação, lucros e
crescimento econômico.
Em relação aos pressupostos, Schein (1985) assevera que a resolução de
problemas em uma empresa depende de fatores como o seu grau de experiência em
determinado assunto e suas hipóteses sobre a realidade. Se o sucesso na resolução do
problema ocorre, então aqueles fatores podem passar a ser considerados válidos e
corretos, transformando-se em pressupostos.
3.1.2.7 Normas da Empresa
As normas da organização podem ser entendidas como a maneira de se realizar
as tarefas, a qual influencia seus membros, ou seja, “a norma é o comportamento
62
sancionado através do qual as pessoas são recompensadas ou punidas, confrontadas ou
encorajadas, ou postas em ostracismo quando violam as normas (FREITAS, 1991)”.
Freitas (1991) afirma que as normas são definidas e repassadas através de outros
elementos culturais, como uma espécie de síntese. Por exemplo: a escolha de normas é
precedida pelas crenças e pressupostos, pela avaliação de valores mais compatíveis com
a empresa e pela definição do que é tabu, assim as normas são vinculadas através dos
sistemas formais de comunicação, bem como através dos heróis, ritos, rituais, estórias e
mitos.
Da mesma forma, Fleury (1996) salienta que para criar e manter a cultura, a rede
de concepções, normas e valores devem ser afirmados e comunicados aos membros da
organização de uma forma tangível que são as formas culturais - os ritos, rituais, mitos,
estórias, gestos e artefatos.
O convívio entre os membros de uma empresa gera certas expectativas a respeito
de seus comportamentos. As normas referem-se ao comportamento que é esperado e
prescrito aos membros de uma empresa, tendo por base definições do que é certo e do
que é errado.
3.1.2.8 Processos de Comunicação
Trata-se de um modo de interação entre os indivíduos, no qual ocorre troca de
mensagens a partir da verbalização e também de comportamentos não-verbais A
comunicação pressupõe o desenvolvimento de uma linguagem na organização, isto é, de
um conjunto de signos com a capacidade de comunicar significados (SCHALL apud
Freitas, 1991).
63
3.1.3 Análise da Cultura Organizacional
Schein (1999) - que faz uma abordagem mais propriamente psicológica da
cultura organizacional - ensina que a cultura existe em três níveis diferentes: artefatos,
valores, e suposições subjacentes básicas.
1º nível: Artefatos Visíveis - incluem os fenômenos que podem ser vistos,
ouvidos e sentidos na cultura. Neste nível, embora sejam de fácil obtenção, os dados são
difíceis de decifrar, dificultando a compreensão lógica subjacente ao comportamento
dos grupos. Desta forma, no primeiro nível estão aspectos como o ambiente de
trabalho, tecnologia, rotinas de trabalho, padrões de comportamento dos membros da
organização, linguagem, modo de se vestir, mitos e estórias.
2º nível: Valores Compartilhados - trata-se dos valores conscientes comuns aos
membros do grupo e que justificam a razão do seu comportamento, ou melhor, “o que é
certo e o que é errado”. São valores que se manifestam em aspectos como crenças,
estratégias, regras, metas e filosofias da empresa. Neste nível há maior possibilidade de
apreender a cultura do que no primeiro nível, mas como esses valores são apenas
expressões das razões do comportamento do grupo, as razões mesmas, permanecem
subjacentes ou inconscientes.
3º nível: Pressupostos Básicos – são valores que foram internalizados como
sendo o modo certo de os membros de um grupo sentir, perceber e pensar as coisas.
Estes pressupostos são oriundos de valores conscientes que são compartilhados pelo
grupo e que conduzem a certos comportamentos. Estes, tendo se mostrado adequados
para resolver problemas, vão gradualmente sendo admitidos como certos até assumirem
o caráter de pressupostos inconscientes, tornando-se inquestionáveis e naturais. O 3º
nível de análise permite uma compreensão mais profunda da cultura organizacional do
que nos dois níveis anteriores.
De acordo com a abordagem de Schein, entender a cultura de uma organização
significa penetrar em seu íntimo onde se encontram seus valores e padrões de
64
comportamentos, os quais foram forjados por pressupostos que se estabeleceram
gradativamente. Trata-se de compreender a subjetividade da organização.
Chiavenato (1999) traz uma analogia entre o estudo da cultura organizacional e a
observação de um iceberg. Na comparação, o autor afirma que assim como um iceberg
possui uma parte superior visível - por se encontrar na superfície das águas - e uma
parte inferior que está fora da visão das pessoas - por estar submersa - a cultura
organizacional também possui uma parte visível e outra oculta.
A cultura organizacional revela aspectos formais facilmente perceptíveis, tratam-
se dos artefatos - políticas e diretrizes, métodos e procedimentos, objetivos, estrutura
organizacional e a tecnologia adotada -, os quais formam o primeiro nível da cultura
organizacional e representam a ponta do iceberg.
Contudo, alguns aspectos informais estão ocultos na cultura organizacional,
como as percepções, sentimentos, atitudes, valores, normas grupais, os quais formam o
segundo e o terceiro nível da cultura organizacional e constituem a parte submersa do
iceberg.
Figura 6: Iceberg da cultura organizacional. Adaptado de Chiavenato (1999).
ASPECTOS INFORMAIS E OCULTOS • Padrões de influência e de poder • Percepção e atitudes das empresas • Sentimentos e normas de grupo • Valores e expectativas • Padrões de interações informais • Normas Grupais • Relações afetivas
ASPECTOS FORMAIS E ABERTOS • Estrutura organizacional • Títulos e descrição de cargos • Objetivos e estratégias • Tecnologia e práticas operacionais • Políticas e diretrizes de pessoal • Métodos e procedimentos • Medidas de produtividade física e financeira
65
A compreensão dos níveis da cultura, além de facilitar o gerenciamento da
empresa, torna possível a avaliação das conseqüências de mudanças que se pretende
implementar na organização.
Portanto, a identificação de uma cultura está diretamente relacionada com o que
o pesquisador considera como cultura e o que ele pretende avaliar na determinada
cultura organizacional, daí a existência de uma variedade de métodos, recomendações e
passos, que abordam aspectos diferentes (FREITAS, 1991).
Fleury (1996) observa que há vários caminhos para se desvendar a cultura de
uma organização. Dentre eles se destacam:
a) O Histórico das organizações: recuperar e analisar o momento de criação de
uma organização e sua inserção no contexto político e econômico da época propicia o
pano de fundo necessário para compreensão da natureza da organização, suas metas,
seus objetivos. O fundador tem um papel fundamental, pois detém a concepção global
sobre o projeto da organização e tem o poder para estruturá-la, desenvolvê-la e tecer
elementos simbólicos consistentes com esta visão.
b) O Processo de socialização de novos membros: o momento de socialização é
crucial para a reprodução do universo simbólico. É através de estratégias de integração
do indivíduo à organização que os valores e os comportamentos vão sendo transmitidos
e incorporados pelos novos membros.
c) As Políticas de Recursos Humanos: ao mediar a relação entre capital e
trabalho em uma organização, as políticas de recursos humanos têm papel relevante no
processo de construção de identidade da organização. Analisando as políticas explícitas
e principalmente as políticas implícitas de recursos humanos de uma organização, é
possível decifrar e interpretar os padrões culturais desta organização;
d) O Processo de comunicação: a comunicação constitui um dos elementos
essenciais no processo de criação, transmissão e cristalização do universo simbólico de
uma organização. É preciso identificar os meios formais orais (contactos diretos,
66
reuniões, telefonemas) e escritos (jornais, circulares) e os meios informais, como por
exemplo, a "rádio-peão". O mapeamento dos meios permite o desvendar das relações
entre categorias, grupos e áreas da organização;
e) A Organização do processo de trabalho: a análise da organização do
processo de trabalho em sua componente tecnológica e em sua componente social,
como forma de gestão da força de trabalho, possibilita a identificação das categorias
presentes na relação de trabalho. Esse estudo subsidia também o mapeamento das
relações de poder entre as categorias de empregado e entre áreas da organização.
Além disso, há diferentes técnicas de investigação da cultura. Na ênfase
quantitativa, utiliza-se levantamento de opinião, através de questionários e entrevistas.
Na ênfase qualitativa são utilizados dados secundários da organização, como
documentos, relatórios manuais de pessoal, organogramas, jornais, etc. As técnicas mais
utilizadas para coleta de dados primários são entrevistas, observação participante e não
participante e dinâmicas de grupo (FLEURY, 1996).
67
3.1.4 Dimensões da Cultura Organizacional
O'Reilly, Chatman e Caldwell apud Robbins (1999) identificaram sete
características, que, quando vistas como um todo, definem a essência da cultura
organizacional. São elas:
1. Inovação e tomada de risco: o grau em que os funcionários são motivados a
usar a criatividade, inovar e assumir riscos na tomada de decisões.
2. Atenção para detalhes: o grau que se espera que os funcionários demonstrem
precisão, análise e atenção aos detalhes.
3. Orientação para resultados: o grau em que a administração se concentra em
resultados mais que nas técnicas e processos usados para alcançá-los.
4. Orientação para pessoas: o grau em que as decisões da administração
consideram seus efeitos em relação às pessoas da empresa.
5. Orientação para equipe: o grau em que as atividades de trabalho são feitas,
tendo por base a equipe mais do que cada membro da equipe individualmente.
6. Agressividade: o grau em que as pessoas da empresa são agressivas e
competitivas mais do que cooperativas.
7. Estabilidade: o grau em que as atividades da empresa se concentram em
manter os status quo.
De acordo com Robbins (1999), essas sete dimensões estão presentes em todas
as organizações em algum grau, e ao se avaliá-las em uma empresa, a cultura da
organização pode ser entendida. Isto ocorre porque estas características fornecem a
imagem de como as coisas são feitas na organização e a maneira que se espera que os
membros se comportem.
Nesta dissertação, são adotadas as sete dimensões da cultura organizacional
acima descritas, as quais estão relacionadas seguintes valores organizacionais:
68
Inovação e Risco Criatividade
Conhecimento
Confiança
Autonomia
Atenção para detalhes: Precisão
Análise
Percepção
Atenção para pessoas: Motivação
Satisfação
Comprometimento
Atenção para resultados: Satisfação do cliente
Satisfação dos funcionários
Lucratividade
Orientação para equipes Individualismo
Cooperação
Espírito de equipe
Comunicação
Coesão
Agressividade: Colaboração
Competição
Conflito
Respeito
Formalidade/Informalidade
Estabilidade: Adaptação
Segurança
Previsibilidade
Tabela 2: Valores organizacionais.
Ao comentar as sete dimensões da cultura que O’Reilly, Chatman e Caldwell
estabeleceram, Noorderhaven (2002) ressalta que uma organização que apresenta alto
nível de inovação é vista como sendo rápida para tirar proveito de oportunidades,
assume risco e exibe iniciativa para experimentação.
Por outro lado, organizações que apresentam alto nível de atenção para detalhes
são precisas, detalhistas e analíticas. A dimensão de orientação para resultado refere-se
à atenção para a realização, orientação para a ação e altas expectativas para desempenho
(NOORDERHAVEN, 2002).
69
Orientação para pessoas refere-se ao respeito pelo direito do indivíduo, justiça e
tolerância. A organização que é orientada para equipe caracteriza-se pelo trabalho em
colaboração com outros. A dimensão agressividade diz respeito a características de
organizações que apresentam alto nível de competitividade, em detrimento da
sociabilidade (NOORDERHAVEN, 2002).
Quanto à estabilidade, a organização que apresenta um alto nível desta dimensão
enfatiza a previsibilidade e a segurança em detrimento à adaptabilidade a novas formas
de trabalhos e tecnologias (NOORDERHAVEN, 2002).
Os aspectos da cultura organizacional podem ser identificados de acordo com o
foco determinado pelo avaliador. Na mesma medida, o diagnóstico também é
influenciado pelos conhecimentos que o avaliador detém a respeito do foco escolhido.
Além disso, o resultado obtido nesta pesquisa dependerá dos artefatos utilizados no
processo de diagnóstico.
3.1.5 Mudança da Cultura Organizacional
Existe muita polêmica em torno da possibilidade de se mudar a cultura de uma
organização de forma planejada, o que implica na mudança da maneira dos membros da
organização pensar, comunicar-se, relacionar-se, bem como a sua forma de fazer as
tarefas.
Os pressupostos básicos, principalmente, funcionam como um fator de
estabilidade da cultura, e a tentativa de modificá-los tende a desestabilizar o mundo
cognitivo do grupo, desencadeando grande quantidade de ansiedade. As pessoas tendem
a evitar altos níveis de ansiedade e criar mecanismos de defesa contra ela.
Assim, é preciso considerar que uma vez estabelecida a cultura de uma
organização, ela poderá atuar como uma barreira em relação a mudanças na empresa
(SCHOLL, 2003). Em algumas situações a mudança é imposta à organização que não a
70
deseja; ao passo que em outras, a mudança é abertamente adotada e procurada, contudo
é sabido que as organizações resistem fortemente à mudança (HALL, 1998).
Schein (1999) nota que a cultura é:
a) Profunda - não pode ser manipulada e mudada conforme a vontade. Ela
fornece significado e previsibilidade.
b) Total - as convicções e suposições penetram todas as partes da organização e
todas as relações internas e externas.
c) Estável – as pessoas não gostam de situações caóticas, imprevisíveis e então
tentam estabilizar e normalizar a cultura. Uma tentativa para mudar a cultura produz
grande ansiedade e resistência.
Segundo Motta (1999) a "mudança é um ônus, pois requer que a pessoa reveja
sua maneira de pensar, agir, comunicar, relacionar-se e criar significados para a sua
própria vida". Katz e Kahn (1978) enumeram seis fatores que contribuem para a
resistência das organizações à mudança:
a) a estabilidade existente nas organizações, as quais são asseguradas por
mecanismos como a seleção de pessoal, treinamento e sistema de recompensa;
b) as organizações tendem a assumir um determinismo local; na qual as
condições ambientais são os fatores determinantes das variações nas formas de
organização social e nas configurações culturais
c) a existência de inércia individual ou de grupo, sendo que a força do hábito é
muito difícil de superar;
d) a mudança pode representar ameaça para grupos ocupacionais, pois algumas
pessoas com tarefas especializadas podem perceber que não serão mais necessárias se
mudanças forem implementadas;
e) mudanças podem ameaçar o sistema de poder estabelecido na organização –
o poder pode ser redistribuído.
71
f) mudanças podem ameaçar membros que se beneficiam da alocação atual de
recompensa e recursos.
Não se pode tratar a resistência à mudança como uma questão trivial, um
empecilho a mais nos projetos de desenvolvimento da empresa, pois se as premissas
básicas da cultura organizacional permanecem válidas, mesmo as propostas de
indiscutível qualidade técnica ou e de prioridade estratégica não se viabilizam (FISHER,
1996).
Os agentes organizacionais reagirão para evitar as mudanças, que se lhes
apresentam como uma ruptura da identidade e uma negação dos valores estabelecidos
que lhes transmitiam um sentimento de segurança. Apenas estes atributos já são
suficientes para se perceber que esta especificidade precisa ser percebida, prevista e
tratada enquanto tal, porque omiti-la sob o rótulo das resistências significa minimizar,
perigosamente, o poder que detêm os aspectos culturais de impedirem a implantação de
mudanças organizacionais (FISHER, 1996).
O aspecto básico é que as organizações são conservadoras por sua própria
natureza, sendo que até mesmo as organizações que tentam causar um impacto radical
na sociedade demonstram esse conservadorismo (HALL, 1998).
Ressalta-se que essa constatação não deve conduzir à conclusão de que não é
possível gerenciar uma cultura organizacional, pois conforme afirma Pettigrew (1996),
há possibilidade de gerenciamento, porém com grandes dificuldades.
Ainda que o planejamento da mudança seja assumido como possível, existe o
consenso entre os autores que o processo não é simples nem barato, e não se faz sem
provocar alguns traumas (FREITAS, 1991).
Então, para ocorrer a mudança cultural é necessário que as justificativas do
comportamento dos membros da organização sejam mudadas. Caso se imponha a
mudança de comportamento dos membros com justificativa baseada em motivos
externos, as pessoas continuarão apegadas a valores e crenças antigos. Assim sendo, a
mudança cultural deve se basear em causas intrínsecas (SATHE, apud Freitas, 1991).
72
A mudança efetiva verifica-se somente quando as pessoas percebem que seus
pressupostos não são mais validados pela realidade, ou seja, estão sendo negados por ela
(SATHE, apud Freitas, 1991). Isso ocorre quando as pessoas constatam que os velhos
modos de fazer as coisas já não mais funcionam, comprometendo a sobrevivência ou o
desenvolvimento empresarial (ALVES, 1997).
Por conseguinte, a mudança requer a aquisição de um novo sistema de valores e
crenças pelos membros da organização, o que não é tarefa fácil de se realizar, já que
nem sempre as justificativas para a mudança estão baseadas em causas intrínsecas, que
ocorre, por exemplo, quando há adaptação da organização à evolução natural do
ambiente.
Pettigrew (1996) entende que a cultura é pensada como um conjunto complexo
de valores, crenças e pressupostos que definem os modos pelos quais a empresa conduz
seus negócios. Esse núcleo de crenças e pressupostos manifesta-se nas estruturas, nos
sistemas, nos símbolos, nos mitos e nos padrões dentro da organização.
Seria muito mais fácil ajustar as manifestações de cultura do que modificar o
núcleo de crenças e pressupostos básicos de uma organização. No entanto, qualquer
estratégia para modificar a cultura organizacional terá de envolver pensamentos e ação
tanto no nível das crenças básicas como no de suas manifestações.
Segundo Pettigrew (1996), as dificuldades de se gerenciar e modificar a cultura
de uma organização decorrem dos seguintes problemas:
a) Problema dos níveis: a cultura existe em uma variedade de níveis diferentes
na empresa. O nível mais profundo refere-se às crenças e pressupostos dos membros, ao
funcionamento interno da organização e ao seu posicionamento quanto ao ambiente
externo. Crenças e pressupostos são muito difíceis de mudar.
b) Problema da infiltração: a cultura refere-se também aos produtos da
empresa, às estruturas, aos sistemas, à missão da empresa, às recompensas, à
socialização;
73
c) Problema do implícito: é difícil modificar valores que são implícitos no
pensamento e no comportamento das pessoas, e que raramente emergem explicitamente
para discussão;
d) Problema do impresso: a história da cultura organizacional tem grande peso
na administração presente e futura na maioria das organizações;
e) Problema do político: refere-se às conexões entre a cultura organizacional e
à distribuição do poder na empresa. Certos grupos de poder têm interesses associados a
crenças e pressupostos, e não estão dispostos a abandonar tais crenças sem que se
apresente um desafio consistente;
f) Problema da pluralidade: a maioria das empresas não possui uma única
cultura organizacional, podendo apresentar uma série de subculturas;
g) Problema da interdependência: a cultura está interconectada não apenas com
a política da empresa, mas com a estrutura, com os sistemas, com as pessoas e com as
prioridades da empresa.
Para Chiavenato (1999) a cultura de uma organização pode ser mudada, mas é
preciso estar ciente de que mudança cultural é um processo lento, medido em anos não
em meses. Pettigrew (1987) afirma que os fatores capazes de precipitar mudanças
organizacionais são basicamente extra-organizacionais, isto é, mudanças no ambiente de
negócios e recessão econômica.
Conforme a circunstância, a tentativa de mudança na organização pode ser
benéfica ou prejudicial, podendo trazer o crescimento ou o declínio da empresa (HALL,
1998). Sendo necessário, antes de concretizar-se uma mudança, realizar-se uma reflexão
a respeito das suas implicações a fim de não pôr em risco o desempenho e até a
sobrevivência da organização-.
Dessa forma, para se implementar mudanças na organização de forma bem
sucedida, devem ser consideradas as múltiplas dimensões da cultura organizacional, eis
que esta ao mesmo tempo em que necessariamente será afetada pela mudança,
configura-se uma condicionante para o sucesso das inovações pretendidas.
74
3.2 Estrutura Organizacional
3.2.1 Definição
Segundo Vasconcellos e Hemsley (1997), estrutura organizacional é o resultado
de um processo através do qual a autoridade é distribuída, as atividades desde os níveis
mais baixos até a alta administração são especificadas e um sistema de comunicação é
delineado, permitindo que as pessoas realizem atividades e exerçam autoridade que lhes
compete para o alcance dos objetivos organizacionais.
Blau apud Hall (1998) oferece uma conceituação mais simples para estrutura.
Para o autor, a mesma refere-se às “distribuições, em diversos sentidos, das pessoas
entre posições sociais que influenciam as relações de papel entre as pessoas”.
Assim, estrutura organizacional é a forma como o ambiente de trabalho é
estruturado na organização, o que traz reflexos consideráveis, uma vez que influencia o
comportamento de cada membro da equipe de trabalho, e, por conseguinte, afeta o
funcionamento global da empresa.
Chiavenato (2002) identifica uma série de aspectos que fazem parte da estrutura
organizacional, como: a forma como está estabelecida a autoridade, a forma dos cargos,
competência para as tarefas, processo decisório, formalização, mutabilidade do
ambiente, etc.
Vários autores ressaltam a importância da estrutura organizacional de uma
empresa não apenas como um organograma em que são definidos os cargos e funções,
mas como uma forma de planejamento estratégico da empresa.
Conforme destacam Huber e Glick (1995), o estudo da estrutura organizacional
é muito importante, pois determina a distribuição de autoridade, de recursos e de
75
informações, impactando a habilidade individual de gerenciamento. Além disso, a
estrutura organizacional afeta a habilidade de coordenar e controlar as atividades dos
subordinados.
3.2.2 Dimensões da Estrutura Organizacional
Para Robbins (2002) a estrutura organizacional define como as tarefas de
trabalho são divididas, agrupadas e coordenadas. Segundo o autor, existem seis
elementos fundamentais que precisam ser considerados quando se projeta a estrutura
organizacional de uma empresa.
A tabela abaixo apresenta a forma como Robbins estabelece esses elementos por
meio de perguntas e respostas:
Perguntas: As Respostas são Fornecidas Por:
1- Em que grau as tarefas são subdivididas em cargos diferentes?
Especialização do trabalho
2- Em que base os trabalhos serão agrupados? Departamentalização
3- A quem os indivíduos e os grupos se reportam?
Cadeia de comando
4- Quantos indivíduos um gerente pode comandar com eficiência e eficácia?
Margem de controle
5- Em que reside a autoridade para a tomada de decisão?
Centralização e descentralização
6- Em que grau há regras e regulamentos para dirigir empregados e gerentes?
Formalização
Tabela 3: Elementos fundamentais da estrutura organizacional. Adaptado de Robbins (1999).
Para o autor, esses são elementos que os gerentes precisam considerar para
esquematizar a estrutura organizacional. Robbins (1999) estabelece a definição de cada
uma das dimensões da estrutura organizacional, conforme segue abaixo:
76
1) Especialização do trabalho:
A especialização, ou divisão de trabalho, refere-se ao grau em que as tarefas na
organização são subdivididas em cargos separados. Com o Fordismo surge a divisão do
trabalho total em inúmeras tarefas distintas, baseada na concepção de que a repetição da
operação aumenta o nível de qualificação do empregado na realização da tarefa
específica, reduz as margens de falhas e aumenta a eficiência do sistema.
A essência da especialização do trabalho está na idéia de que o trabalho
completo não é executado por apenas um indivíduo, mas ele é dividido em etapas e cada
uma é realizada por uma pessoa diferente. Os indivíduos especializam-se para realizar
parte de uma atividade, em lugar de se especializarem na atividade inteira.
As administrações das empresas viam a alta especialização do trabalho como um
meio para utilização mais eficiente das qualificações dos funcionários: enquanto
algumas tarefas requerem habilidades altamente desenvolvidas, outras podem ser
realizadas por pessoas com menos experiência. Se todos os funcionários estivessem
envolvidos em cada etapa do processo de produção, todos teriam que possuir as
habilidades necessárias para executar tanto o trabalho menos exigente quanto o mais
exigente.
Os gerentes também perceberam que é mais fácil e menos dispendioso encontrar
e treinar trabalhadores para realizarem tarefas específicas que encontrar e treinar
trabalhadores para realizarem todas as tarefas. Entretanto, os efeitos colaterais da
especialização sobre os indivíduos não tardaram em aparecer manifestadas em
monotonia, fadiga, estresse e desinteresse, baixa qualidade e produtividade. Percebeu-
se, então, que se fosse permitido aos funcionários realizar o trabalho completo e se
fossem distribuídos em equipes geralmente alcançavam maior produtividade e ficavam
mais satisfeitos com o trabalho que os funcionários especializados.
Hoje a especialização não é encarada nem como obsoleta, nem como fonte
inesgotável de aumento de produtividade, mas reconhece-se que ela se adequa melhor
em certos tipos de trabalho; ou seja, ela pode ser adequada para certos tipos de atividade
ou estratégias e inadequada para outros.
77
2) Departamentalização:
É a forma de agrupar as tarefas de trabalho. Existem várias formas de agrupar as
atividades, sendo que a departamentalização pode ser dar por funções, por produtos,
com base geográfica, por processo e por clientes.
Na departamentalização funcional, dá-se a colocação de especialistas de mesma
espécie juntos, ocorrendo agrupamento por habilidades e orientações similares em
unidades comuns. Na departamentalização por produto, coloca-se cada produto da
empresa sob a responsabilidade de um grupo de funcionários, desta forma todas as
atividades relacionadas a um produto ficam sob cuidados do grupo.
Outra forma de departamentalizar é com base geográfica, a qual se refere ao
ambiente físico em que a empresa se organiza, pois é possível que os departamentos ou
grupos de trabalho se situem em locais diferentes (salas, prédios, cidades, regiões). É
possível ainda que a empresa esteja organizada de tal forma que cada departamento
especialize-se em uma fase específica da produção, neste caso a departamentalização
será por processo. Também é possível agrupar as tarefas de trabalho tendo em vista o
tipo de cliente que a empresa busca alcançar, pois estabelecer departamentos diferentes
para cada tipo de cliente pode garantir um melhor atendimento dado por especialistas.
Chiavenato (2002) salienta que boa parte das empresas está deixando a
tradicional departamentalização para se organizar em torno de equipes, as quais
apresentam a vantagem de serem mais ágeis e apresentarem maior adaptabilidade.
3) Cadeia de Comando:
A cadeia de comando é a linha de autoridade que se estabelece desde o comando
de alto nível até o escalão mais abaixo na hierarquia da organização. A Cadeia de
comando possui dois conceitos complementares: a Autoridade, que se refere aos direitos
atribuídos a uma posição de comando de forma a controlar os cargos situados dentro da
esfera de comando; e o Princípio de Unidade-de-Comando, que estabelece a ausência de
quebras na linha de autoridade, de forma que cada comandado tenha um superior a
quem se reporta.
78
O importante na Cadeia de Comando é que esta hierarquia de autoridade
estabelece o canal de comunicação, direção e interação entre comandantes e
comandados (HAMPTON, 1990). A comunicação é um instrumento importante para a
assimilação da cultura. Por outro lado é a cultura quem determina o tipo de
comunicação da empresa, bem como sua forma e veículos e, também, seu conteúdo e
fluxos (BARICHELLO, 2005).
A comunicação é o processo através do qual uma mensagem é transmitida de um
ponto a outro. MEGGINSON (1998) classifica estes fluxos de informações através da
organização da seguinte forma:
a) Descendente: vem de cima para baixo na estrutura organizacional, ou seja,
dos níveis mais altos para os níveis mais baixos da organização;
b) Ascendente: são informações ou retroinformação de dados dos níveis mais
baixos para os níveis mais altos da organização;
c) Lateral ou Horizontal: acontece entre unidades organizacionais e entre
pessoas de mesma função dentro da organização;
d) Diagonal: cruza diagonalmente a cadeia de comando de uma organização, ou
seja, entre unidades organizacionais e níveis diferentes ao mesmo tempo.
4) Margem de Controle:
A margem de controle define o número de subordinados que pode ser controlado
de forma eficaz por uma gerência. Uma esfera de controle pequena – em que poucos
funcionários estão sob o controle de um gerente - pode implicar num melhor grau de
gerenciamento, mas aumenta os custos envolvidos com níveis gerenciais. Esferas
maiores de controle – em que muitos funcionários estão sob o controle de um gerente -
requerem um esforço maior para aumentar a maturidade profissional dos indivíduos e
dos grupos da organização, para aumentar o grau de delegação, para melhorar a clareza
da comunicação e dos objetivos comuns da organização.
79
5) Centralização e Descentralização:
Em algumas organizações os gerentes de topo tomam todas as decisões e os
gerentes de níveis mais baixo apenas as levam adiante. Por outro lado, existem
organizações onde a decisão é tomada pelos funcionários que estão mais perto da
“ação”, ou seja, do ambiente em que a decisão é demandada.
A centralização refere-se ao nível em que a tomada de decisão está
concentrada, neste caso as pessoas do nível mais alto tomam decisões sem nenhuma
participação das pessoas dos níveis mais baixos.
Já a descentralização refere-se ao grau em que são delegados poderes, de forma
que as pessoas dos níveis mais baixos detenham autonomia para tomar decisões. Em
uma organização descentralizada a decisão pode ser tomada mais rapidamente, já que
quem vai tomá-la estará mais perto do problema a ser resolvido, tendo inclusive mais
conhecimento sobre a questão.
Em organizações altamente centralizadas, não há confiança suficiente nas
pessoas para que estas tomem decisões; já em organizações com menor grau de
centralização existe confiança para permitir que as atividades sejam desempenhadas
com maior autonomia (HALL, 1998). Assim, conforme a atribuição do poder de uma
organização estabelece-se o nível de centralização ou descentralização do processo de
tomada de decisão.
6) Formalização:
A formalização refere-se ao nível em que as atividades estão padronizadas na
organização. A formalização das funções afeta o nível de autonomia atribuído ao
ocupante do cargo no processo de tomada de decisão.
Organizações com alto grau de formalidade fornecem um grau mínimo de
autonomia ao ocupante do cargo para decidir o que deve ser feito, quando deve ser feito
e como deve ser feito. Neste caso, existem descrições explícitas das tarefas, muitas
regras organizacionais e procedimento claramente definidos a respeito dos processos de
80
trabalho. Vasconcellos e Hemsley (1997) observam que neste caso as decisões são
tomadas de acordo com as normas e sempre que possível são colocadas em escrito.
Em contrapartida, em organizações com baixo grau de formalização, os
comportamentos de trabalho são relativamente não-programados e os empregados têm
uma grande liberdade para exercitar autonomia em seu trabalho. Assim, quanto maior a
formalização, menor será possibilidade dos funcionários adotarem comportamentos
alternativos. Na verdade, se o trabalho for padronizado se estará eliminando a
possibilidade e a necessidade dos empregados considerarem alternativas.
O grau de formalização pode variar entre as organizações e dentro das
organizações, já que certos cargos podem ter alta formalização e outros podem possuir
baixa formalização.
Tamayo (1997) observa que a estrutura organizacional define o sistema social da
organização, as funções que devem ser executadas e as relações entre as diversas
unidades e entre os membros da organização. Neste contexto, podem estar presentes
certos valores culturais que expressam preferência nítida pela hierarquia (autoridade,
poder social, influência, supervisão) e também podem estar presentes valores culturais
que expressam igualitarismo, valorização das pessoas, equidade, responsabilidade.
Dessa forma, promover a mudança da estrutura organizacional pode ser uma
tarefa árdua e sujeita à resistência, pois implica em modificar valores culturais
subjacentes à estrutura. Neste caso, tratando-se de mudança na estrutura organizacional
é preciso considerar as dificuldades apontadas anteriormente em relação à mudança da
cultura organizacional.
81
4. A INFLUÊNCIA DA CULTURA E DA ESTRUTURA ORGANIZACIONAL
NA ADOÇÃO DA EXTREME PROGRAMMING
Conforme Freitas (1991) salienta, um dos fatores que torna as empresas bem
sucedidas é a compatibilidade cultural. Neste sentido, a harmonia dos pressupostos do
método de desenvolvimento de software com os fatores organizacionais da empresa de
software é crucial para sua implantação de forma satisfatória.
Assim sendo, torna-se importante a prévia verificação da adequação dos fatores
organizacionais ao método XP a fim de evitar-se experiências malfadadas e desgastes na
empresa ou, se for o caso, gerenciar melhor a implantação do método.
Trata-se de uma reflexão muito pertinente tendo em vista a grande dificuldade
de se mudar a cultura organizacional, e conseqüentemente a estrutura - que está baseada
em valores culturais - conforme salientado no capítulo 3.
Tendo por base essas premissas, neste capítulo busca-se demonstrar a influência
dos fatores organizacionais na adoção da XP identificando-se os aspectos culturais e
estruturais das empresas de software que sejam favoráveis ou desfavoráveis ao método.
Para alcançar tal objetivo, são analisadas as 7 dimensões da cultura e as 6
dimensões da estrutura organizacional, identificadas anteriormente, sob a perspectiva
das práticas e valores XP. Essa análise - baseada na bibliografia sobre o tema e
observações e relatos empíricos - possibilita a formulação de uma lista de verificação
da adequação dos fatores organizacionais das empresas de software que pretendam
adotar o método XP.
82
4.1 Cultura Organizacional e a Extreme Programming
4.1.1 Dimensão: Inovação e Risco
Conforme já mencionado, o método XP é um conjunto de práticas já conhecidas
pela engenharia de software, porém a sua inovação configura-se na forma como estas
práticas estão organizadas e como elas são executadas, modificando bastante as relações
de trabalho e a forma de desenvolver software.
Ao se desenvolver software com a XP não se segue um processo prescritivo,
mas há um planejamento mínimo e curto, com constante possibilidade de mudança.
Beck (2004) afirma que os integrantes de uma equipe XP tornam-se nômades
intelectuais, sempre preparados para levantar acampamento e seguir o bando. Neste
caso, o bando pode ser um projetista que quer seguir uma direção diferente da
antecipada, ou um cliente que quer modificar algo, ou uma tecnologia nova.
O simples fato de ter o cliente dentro da empresa diariamente tendo contato
direto com os desenvolvedores representa uma mudança considerável e implica
alterações no status quo. O cliente pode mudar os requisitos durante a implementação,
introduzir novas histórias e até mudar a direção do projeto, sendo que os
desenvolvedores devem estar aptos para lidar com estas mudanças.
Como na XP se trabalha com requisitos vagos, os desenvolvedores deverão ser
criativos, inovadores, capacitados e estar sempre preparados para o inesperado, pois não
contam com um plano dirigido a longo prazo.
Além disso, o processo iterativo e incremental utilizado na XP enfatiza
características humanas de aprendizagem e suposição, assim os desenvolvedores estão
sujeitos a erros quando estão estimando, analisando requisitos, projetando e testando,
sendo que não há como evitar riscos de erro. O problema é que muitos gerentes de
software têm resistências ao processo iterativo e incremental justamente por causa do
83
risco, preferindo falhar do modo conservador ao invés de correr risco de modo diferente
(COCKBURN, 2001).
Para que os desenvolvedores possam agir de forma criativa e correr riscos o
valor XP Coragem deve estar presente. Por isso é preciso verificar quais os aspectos
organizacionais que influenciam na disposição dos desenvolvedores para inovar e correr
riscos.
Ao se perguntar aos membros de uma empresa de software se a mesma está
aberta a inovações a resposta provavelmente será positiva, porém algumas vezes a
inovação pode ser apenas um valor desejado pelo gerente ou pela própria equipe. É
possível verificar a efetivação destes valores, observando os mecanismos criados para
gerar inovação e também se os integrantes da empresa são propensos a inovar.
Algumas atitudes que ajudam a revelar se o funcionário possui perfil inovador
podem ser identificadas no hábito de se questionar e de questionar os outros para ver se
existe uma forma melhor para fazer as atividades, adaptar idéias colocando-as em seu
contexto de trabalho, aceitar com facilidade as mudanças na rotina, expressar desejo de
aprender e experimentar novas tecnologias (MAYO, 2001).
Por outro lado, para impulsionar a inovação e a criatividade é fundamental que a
empresa se mantenha aberta às idéias e sugestões dos desenvolvedores, escutando-as e
implementando-as. Os desenvolvedores precisam sentir que suas opiniões são
valorizadas no trabalho para terem motivação para desenvolver software de forma
criativa.
A forma como são tratados os erros dos desenvolvedores também possui forte
influência sobre o quanto os mesmos estão propícios a inovar. A empresa que possui o
hábito de “apontar o culpado”, repreender abertamente ou até punir os desenvolvedores
que cometem falhas acaba inibindo a inovação e a pré-disposição dos mesmos para
correr riscos.
No ambiente de trabalho favorável à XP, os desenvolvedores precisam poder dar
más notícias aos clientes e à gerência - o quanto antes – e fazê-lo sem ter medo de ser
punidos (BECK, 2004). Existindo um sistema de punição de erros, os desenvolvedores
84
procurarão apenas seguir o plano do projeto e serão relutantes a se reportar à gerência
em caso de dúvidas ou identificação de falhas.
Além disso, a punição dos erros reflete diretamente no desempenho dos
desenvolvedores. As pessoas agem com cautela quando lhes é negada a permissão para
errar, nunca ultrapassam seus limites e costumam estabelecer metas mais baixas das que
podem realizar (TRACY, 1994). Em conseqüência, a empresa perde a oportunidade de
obter a programação intensa e produtiva que a XP requer.
Claro que não se está sugerindo que se permita que as pessoas errem a qualquer
tempo e em qualquer lugar, mas é preciso estabelecer diretrizes para o erro, deixando
claras as situações em que falhas não são toleradas - como em caso de omissão e
desleixo (TRACY, 1994).
O sistema de punição pode funcionar como um tabu, servindo para orientar
comportamentos e enfocar atitudes não bem-vistas ou não permitidas, desestimulando a
inovação. A forma de tratar os erros acaba atuando como fator de sustentação da cultura
existente na empresa. Se a cultura é no sentido de apenas se cumprir normas e não
correr riscos, o sistema de identificar, criticar publicamente e até punir os “culpados”
garante a permanência da referida cultura.
Assim, mesmo que cometer erros faça parte do processo de desenvolvimento de
software, em algumas empresas a forma como eles são tratados pode caracterizar um
inibidor para os desenvolvedores. É possível identificar o tratamento dado aos erros
através das estórias existentes na empresa, nas quais são relatadas as falhas cometidas e
como elas foram tratadas pelos superiores.
Na XP, o gerente deve ser um motivador que estimula a tensão criativa dos
desenvolvedores, assim sendo, os erros devem ser encarados como parte do processo de
aprendizagem, até porque a XP requer um desenvolvedor que esteja em aprendizado
contínuo.
O sistema de recompensa (pecuniário ou não) também pode influenciar na
disposição dos membros da empresa para trabalhar de forma criativa e correr riscos. A
recompensa funciona como reforço positivo e como sinalizador do comportamento que
85
a organização espera dos funcionários (CHIAVENATO, 2002). Desta forma, se o
sistema for direcionado para valores como criatividade e desempenho dos
desenvolvedores se estará diante de um ambiente favorável à XP.
O reconhecimento do comportamento exemplar costuma forjar heróis na
organização, o qual passa a servir de modelo para os outros funcionários. Assim o perfil
do funcionário padrão vai sendo moldado na empresa (inovador ou conservador). Além
disso, através das estórias e dos mitos as experiências anteriores relacionadas ao sistema
de punição e recompensa vão sendo repassadas aos novos funcionários, de forma a
orientar seu comportamento.
Também é fundamental que os desenvolvedores tenham autonomia para fazer
alterações sem necessidade de autorização prévia. Chiavenato (2002) observa que
quando a empresa determina tarefas altamente padronizadas para os funcionários está
eliminando totalmente sua capacidade de criar, mudar e inovar. Quando a empresa
encoraja a expressão individual acaba por se renovar e se revitalizar.
Os aspectos organizacionais apontados como favoráveis à adoção da XP devem
ser interpretados à luz das exigências do método, assim, não se deve confundir, por
exemplo, gerência facilitadora - que trata os erros como processo de aprendizagem -
com ausência de controle ou omissão em relação às suas responsabilidades.
Da mesma forma, assumir riscos e ter coragem não deve significar imprudência,
assim como inovação e simplicidade não deve corresponder à falta de planejamento.
Neste sentido, Bossavit (2002) comenta sobre um projeto XP que participou que é
bastante esclarecedor.
Bossavit (2002) identificou três aspectos organizacionais existentes na empresa
que determinam seu modo de agir e sua visão de mundo. O autor chamou estes
aspectos de “cultura”. Para Bossavit (2002), estes aspectos são os que contribuíram para
o fracasso do projeto XP, mas apesar disso, o autor nomeou-os de Paixão, Ousadia e
Fascínio - utilizou expressões positivas para denominá-los.
As culturas “Paixão” e “Ousadia” representam os valores que levaram a empresa
- que era formada por uma equipe jovem e sem sólidas experiências – a cometer a
86
imprudência de firmar um contrato para desenvolver um sistema de software complexo
em um período de tempo extremamente curto (BOSSAVIT, 2002).
Estas culturas “Paixão” e “Ousadia” também influenciaram na decisão de adotar
um novo método de desenvolvimento de software neste projeto (método XP). Além
disso, as culturas permitiram que a empresa cometesse deslizes, como não procurar
manter o cliente presente e não mantê-lo informado sobre as dúvidas e problemas que a
equipe vinha enfrentando durante o processo de desenvolvimento (BOSSAVIT, 2002).
Assim, é incorreto acreditar que um projeto XP será bem sucedido apenas pelo
fato dos desenvolvedores se mostrarem motivados e dispostos a inovar e assumir riscos.
Embora esses valores sejam fundamentais, eles são apenas alguns, de uma gama de
valores que são necessários, como conhecimento, responsabilidade e coerência. É
preciso haver um equilíbrio entre estes valores.
Bossavit (2002) identificou a cultura “Fascínio” ao perceber que a equipe
direcionava sua atenção apenas para a elegância do código, descuidando de importantes
medidas internas de qualidade, como o nível de abstração, modularidade e redundância.
Desta forma, verifica-se que a preocupação superficial e visual com a qualidade
de software, não garante que os desenvolvedores realmente sejam cuidadosos e
orientados para detalhes – aspectos organizacionais importantes para a próxima
dimensão a ser abordada (Orientação para Detalhes).
Itens de verificação relacionados à dimensão Inovação e Risco
1. Os desenvolvedores procuram fazer sugestões para melhorias no processo de
desenvolvimento de software?
2. As sugestões dos desenvolvedores costumam ser consideradas e implementadas?
3. Como são tratados os erros na empresa?
4. O sistema de recompensa encoraja a inovação?
Figura 7: Itens de verificação - dimensão Inovação e Risco
87
4.1.2 Dimensão: Orientação para Detalhes
A orientação para detalhes é uma premissa básica para a viabilidade da XP. Uma
das concepções mais equivocadas sobre a XP é que a mesma se refere a uma
metodologia caótica de desenvolvimento de software que satisfaz os hackers. Na
verdade, a XP requer programadores cuidadosos e orientados para detalhes que se
orgulham do seu trabalho (BURKE, 2003).
Asproni (2004) lembra que a XP, assim como todos os métodos ágeis, requer um
alto padrão de excelência, o qual se manifesta na contínua satisfação do cliente com o
prazo de entrega e com o software, que deve ser funcional, totalmente testado, simples,
fácil de ser modificado e com pouco ou nenhum erro.
O programador deve ser cuidadoso por hábito (BECK, 2004). É preciso existir
uma filosofia de melhoria constante, de forma a compreender o todo sem perder de vista
suas partes. A XP requer que os programadores sejam analíticos e detalhistas, já que o
código deve ser exaustivamente testado e revisado.
O desenvolvedor deve ter orientação para detalhes, sobretudo, para:
a) manter o código o mais simples e compreensível possível a fim de se realizar
refactoring e alterações na versão coletiva com segurança;
b) realizar testes intensivamente;
c) compreender o cliente e ajudá-lo a criar os cartões de histórias e de tarefas,
bem como a realizar testes de aceitação;
d) identificar erros do colega quando estiver programando em par;
e) realizar integração contínua.
Uma forma de identificar a afinidade da empresa de software com o método XP
no que diz respeito a esta dimensão é descobrir a importância dada à qualidade do
88
software, mais precisamente a importância que os desenvolvedores e a gerência dão aos
testes.
A adoção da XP requer uma mudança radical de comportamento de gerentes e
desenvolvedores que não possuem um alto grau de orientação para detalhes. Várias
barreiras culturais podem surgir, como por exemplo, a mentalidade de que testar ou
realizar revisões no código é perda de tempo.
Além disso, as resistências podem ter origens de aspectos como a falta de
qualificação dos desenvolvedores ou planejamento deficiente, os quais acarretam
atrasos na entrega de software e acabam limitando o percentual de testes.
A adoção da XP pode ser difícil se esses valores decorrentes das barreiras
culturais estiverem arraigados, pois conforme surjam dificuldades é possível que se
volte a forma de agir que se estava habituado.
Diante desta situação, percebe-se a preocupação de Kent Beck em definir o
papel do treinador XP, o qual deve conduzir os desenvolvedores conforme as premissas
do método e redirecioná-los quando tenderem a trabalhar de acordo com seus valores e
pressupostos já consolidados.
O papel do treinador pode ser visto como o de um disseminador da cultura
adequada ao método XP, porém estudos sobre cultura organizacional revelam que
mudanças culturais são lentas e, em alguns casos, até inviáveis. Desta forma, destaca-se
a importância de não haver uma discrepância acentuada entre os valores culturais da
empresa e os pressupostos pela XP.
Outra implicação identificada nesta dimensão relaciona-se ao processo de
desenvolvimento de software iterativo e incremental com pequenos releases, o qual é
realizado na XP. Isto torna evidente a constante preocupação com a qualidade do
software que será entregue para o cliente e, consequentemente, exige mais orientação
para detalhes se comparado com o processo tradicional.
89
Itens de verificação relacionados à dimensão Orientação para Detalhes:
1. Qual a porcentagem de tempo que os desenvolvedores costumam dedicar aos testes em
um ciclo de vida do sistema?
2. Qual a opinião dos desenvolvedores sobre intensificação de testes?
3. Os desenvolvedores costumam ser cuidadosos e detalhistas em relação a cada módulo do
software?
Figura 8: Itens de verificação - dimensão Orientação para Detalhes
4.1.3 Dimensão: Orientação para Resultados
Bossavit (2002) realizou um estudo de caso que pode auxiliar na compreensão
desta dimensão. O referido autor relata seu trabalho como treinador para um projeto de
software de caráter experimental da XP em uma empresa de desenvolvimento de
software fortemente orientada para resultados, pois a mesma possui uma cultura
organizacional fortemente direcionada para a minimização de custos.
Segundo Bossavit (2002), ao se implementar o projeto XP a empresa não
disponibilizou as condições necessárias para atender as exigências que este método de
desenvolvimento de software requer. Por exemplo, não foi providenciado hardware
apropriado, nem um ambiente adequado para se realizar programação pareada. Além
disso, a maioria dos desenvolvedores mais experientes foram designados para trabalhar
em outros projetos que a empresa considerava mais importantes e rentáveis, restando ao
projeto XP apenas os desenvolvedores novatos.
Tendo o treinador sugerido um treinamento prévio dos programadores que iriam
trabalhar no projeto XP, a empresa relutou em realizá-lo, considerando que tal atividade
seria um custo que poderia ser evitado. Estes foram alguns dos aspectos que Bossavit
vivenciou e que lhe possibilitaram observar que a cultura dessa empresa está baseada na
filosofia de “fazer mais com menos despesa”, de forma a comprometer a adoção da XP
(BOSSAVIT, 2002).
90
Muitas vezes a cultura de minimizar custos pode ser oriunda de fatores externos
como a competitividade do mercado e a escassez de recursos financeiros, de forma que
o equilíbrio entre a busca pela lucratividade e a valorização dos funcionários e a
qualidade do software pode ser uma preocupação importante, porém difícil de realizar.
A orientação para resultados apropriada na XP está na satisfação e motivação
dos desenvolvedores e na entrega de produto de qualidade para o cliente dentro do prazo
estipulado, desta forma a lucratividade da empresa torna-se uma conseqüência destas
práticas.
Empresas de software com cultura fortemente orientada para minimização de
custos ou maximização do lucro podem apresentar maiores resistências ao método XP,
havendo inclusive chances de se estabelecer mitos da prática XP Programação pareada
(identificados no capítulo 2), como “programar em par é colocar duas pessoas fazendo o
trabalho de uma”.
Também é comum que empresas com esse aspecto cultural exijam desempenho
dos desenvolvedores em forma de horas extras, de maneira a obter o máximo de
rendimento no dia de trabalho. A XP tem uma abordagem muito clara em relação a isto,
recomendando que o trabalho além da jornada normal não seja utilizado, pois segundo
Teles (2004) tal prática não é compatível com a criatividade intensiva que é exigida de
um desenvolvedor de software XP.
Nos projetos XP, a prática Ritmo Sustentável requer que os desenvolvedores
trabalhem basicamente 8 horas por dia (40 horas por semana), desta forma se demonstra
respeito à integridade de cada membro da equipe e a agilidade do projeto aumenta
(TELES, 2004).
Assim, é necessário verificar se a empresa de software que deseja adotar a XP
equilibra a busca da lucratividade (e/ou minimização de custos) com a atenção aos
funcionários e ao cliente. Isso pode ser observado através de políticas e atitudes como: o
tratamento dispensado aos empregados, exigência de desempenho em forma de horas
extras, promoção de incentivos para o crescimento profissional do desenvolvedor, forma
de relacionamento com o cliente, a satisfação dos requisitos do cliente.
91
Outro exemplo de como a forte orientação para a maximização do lucro pode
prejudicar a adoção da XP é fornecido por uma empresa que teve seus aspectos culturais
alterados. A empresa de pequeno porte, que já adotava XP, se lançou na produção de
um novo game idealizado pelos sócios, em um projeto considerado audacioso e
inovador para suas proporções. Para viabilizar o negócio foi preciso angariar capital
junto a investidores do mercado de desenvolvimento de software.
Os recursos da empresa passaram a depender dos investidores deste projeto, já
que a mesma se dedicou exclusivamente a ele. Todos na equipe de desenvolvimento
estavam conscientes de que o projeto era vital para sobrevivência da empresa e
manutenção de seus empregos, criando-se apreensão sobre o lançamento do produto no
mercado.
Contudo, como os investidores criaram grandes expectativas - encarando o
projeto como um negócio que deve rapidamente render altos índices de lucratividade
para compensar seus investimentos –, passaram a fazer cobranças a respeito do
resultado do projeto. A exigência de entrega de software em curtos períodos de tempo
acabou reduzindo o uso das práticas XP que a equipe já estava acostumada.
As práticas testes e refatoração foram as mais prejudicadas, pois para cumprir os
prazos estipulados os testes passaram a ser vistos como algo que poderia ser
minimizado ou até excluído do processo de desenvolvimento. Em função dos erros que
começaram a se tornar cada vez mais freqüentes (pela falta de testes e revisões), a
integração contínua também ficou prejudicada.
Instalou-se um ambiente de insegurança e apreensão na equipe, que acabou
perturbado o desempenho dos desenvolvedores. Além disso, as horas extras passaram a
ser rotina. Desta forma, a forte orientação para a lucratividade que se estabeleceu na
empresa reduziu a utilização da maioria das práticas XP e inviabilizou outras.
92
Itens de verificação relacionados à dimensão Orientação para Resultados:
1. A empresa viabiliza o crescimento intelectual dos desenvolvedores?
2. Os programadores costumam fazer horas extras?
3. Os softwares costumam satisfazer todos os requisitos dos clientes?
4. Como são resolvidas as reclamações do cliente?
Figura 9: Itens de verificação - dimensão Orientação para Resultados
4.1.4 Dimensão: Orientação para Pessoas
De acordo com o Manifesto Ágil (Agile Alliance, 2001), é melhor ter pessoas
capacitadas e motivadas do que ferramentas e tecnologias caras. Highsmith (2002)
observa que os métodos ágeis são voltados para os desenvolvedores porque a forma
como o software é produzido depende essencialmente das pessoas.
Uma das coisas que é fundamental na XP, e a torna tão difícil, é que os
programadores precisam aceitar suas tarefas como uma responsabilidade e não como
uma ordem de trabalho. O programador precisa estar motivado para tentar primar o
máximo pela qualidade e simplicidades e testar continuamente as funcionalidades e
códigos (BECK, 2004).
Na XP o trabalho dos programadores não deve ser imposto de cima para baixo,
como por exemplo, o gerente simplesmente determinar as atividades e o tempo para
fazê-las, mas é necessário que a equipe assuma a responsabilidade de fazer o trabalho.
Ou seja, a equipe deve encarar o trabalho como algo que está disposta a realizar e não
simplesmente como uma ordem a cumprir.
Para que os desenvolvedores estejam dispostos a encarar as atividades de
trabalho como uma responsabilidade, eles precisam estar motivados. Segundo Mayo
(2001), o ambiente de trabalho afeta o nível de motivação dos funcionários,
comprometendo a lealdade e podendo encorajar ou inibir o uso total de suas habilidades.
93
Existem muitas teorias que tentam caracterizar a motivação, cada uma delas têm
pontos fortes e fracos, não sendo genéricas o suficiente. Mas, segundo Asproni (2004),
pode-se considerar que existem dois fatores que influenciam a motivação dos
desenvolvedores de software: fatores intrínsecos e fatores extrínsecos.
Os primeiros referem-se a metas e a aspirações individuais: realização,
reconhecimento, expectativa de crescimento e relações sociais; enquanto que os
segundos dependem do ambiente que cerca as pessoas e de suas necessidades básicas:
salário, ambiente de trabalho e responsabilidade (ASPRONI, 2004).
A empresa que pretende utilizar a XP deve estar preocupada em promover
políticas de valorização do capital humano e demonstrar zelo pelos seus funcionários, a
fim de que estes se encontrem suficientemente motivados para que possam atingir o
desempenho desejado no referido método. Assim, benefícios e participação nos lucros
podem concorrer para a satisfação da equipe de desenvolvimento de software.
Também é importante que o salário dos desenvolvedores atenda suas
necessidades e expectativas, pois se os mesmos estiverem insatisfeitos com sua
condição na empresa dificilmente encontrarão motivação para se adequar às práticas e
valores XP. O plano de carreira também é um importante motivador para os
desenvolvedores, que tendo em vista oportunidades de crescimento profissional estarão
mais dispostos a se empenhar no trabalho.
Quanto ao reconhecimento, Asproni (2004) destaca que o simples fato de
mostrar apreciação ao trabalho bem feito pelo desenvolvedor de software é um poderoso
motivador. Isto ajuda na auto-estima do desenvolvedor e estabelece um crescente nível
de confiança entre gerência, desenvolvedores e clientes, o que conduz para melhor
comunicação e melhor software.
A atenção que a empresa dedica aos desenvolvedores de software também pode
promover a fidelidade dos mesmos, o que pode refletir na aceitação de mudanças
realizadas no ambiente de trabalho. No caso da adoção da XP, é interessante atentar
para as considerações de Fowler (2003) de que os processos ágeis, por serem totalmente
94
dependentes das pessoas, não podem ser impostos na empresa, mas deve haver sua
ampla aceitação tanto pela gerência quanto pelos desenvolvedores.
Desta forma, primeiramente as pessoas devem estar dispostas a adotar a XP,
porém se houver uma relação de lealdade entre a equipe de desenvolvimento de
software e a empresa - de forma que ocorra o engajamento com os ideais e valores da
organização - poderá haver menos resistência para a adoção do método.
Itens de verificação relacionados à dimensão Orientação para Pessoas:
1. Quais os benefícios que a empresa concede aos funcionários?
2. Os desenvolvedores estão satisfeitos com o salário?
3. Existe um plano de carreira na empresa?
4. Os desenvolvedores estão comprometidos com o trabalho?
Figura 10: Itens de verificação - dimensão Orientação para Pessoas
4.1.5 Dimensão: Orientação para Equipe
Esta dimensão está relacionada com a forma como a gerência da empresa
costuma orientar as tarefas de trabalho: para indivíduos ou para a equipe. Isto é, se os
trabalhos são dirigidos para cada desenvolvedor ou são direcionados para a equipe como
um todo.
Atividades de trabalho mais direcionadas para equipe configuram um aspecto
favorável para a adoção da XP, pois suas práticas e valores necessitam de trabalho
integrado. Neste método o trabalho em equipe é supervalorizado, sendo viabilizado
através da comunicação, feedback, vocabulário comum e preferência por formas mais
diretas de comunicação.
95
Empresas que costumam direcionar as atividades mais para indivíduos podem
encontrar dificuldades na adoção do método XP, pois assim agindo a empresa está -
indiretamente - desestimulando o “espírito de equipe” e a visão compartilhada dos
objetivos do trabalho, criando espaços para o individualismo.
É possível que uma empresa de software acredite que esteja orientando o
trabalho para equipe, quando na verdade isto não está ocorrendo. Uma empresa que
possui como valor desejado o trabalho em equipe muitas vezes pode estar apenas
dividindo as tarefas entre os indivíduos do grupo. Esta situação pode ser identificada
quando se verifica a intensidade da cooperação entre os desenvolvedores e o quanto eles
conhecem as funcionalidades que os colegas estão codificando.
Kirby (2003) diferencia desenvolvimento de software em equipe de
desenvolvimento de software em grupo. O autor considera um cenário em que um grupo
de desenvolvedores recebe o documento do projeto sem ter maiores contatos com a
pessoa que especificou os requisitos. Posteriormente, o líder da equipe ou gerente do
projeto divide o documento em módulos que são entregues para cada desenvolvedor, os
quais tratam de implementar a sua parte e quando todas estiverem prontas são
integradas e testadas.
Segundo Kirby (2003), este cenário mostra que houve apenas uma divisão de
trabalho para o grupo, mas não houve o trabalho em equipe. Em uma verdadeira equipe
seus integrantes compartilham um conjunto de metas, possuem uma visão direcionada e
colaboram continuamente. Então, para que um grupo de desenvolvedores seja realmente
uma equipe de desenvolvimento de software é necessário compartilhar mais do que o
ambiente físico, ou seja, devem existir objetivos compartilhados e ajuda mútua.
Asproni (2004), ao tratar de equipes de desenvolvimento de software, afirma que
o espírito de equipe existe quando os indivíduos estão envolvidos em um forte
sentimento de identificação e comprometimento com a equipe - o que não é fácil de
acontecer. Ele ocorre quando todos os membros desejam se dedicar à equipe e as
energias para a realização das metas em comum orientam as pessoas na mesma direção.
Desta forma haverá um motivador para se estabelecer metas claras e envolver a equipe
em todas as fases do projeto.
96
Segundo Sharifabdi (2002), criar uma equipe de desenvolvimento é um processo
de transformar um grupo de desenvolvedores com interesses diferentes e com
experiências anteriores em uma equipe integrada e efetiva em uma única tarefa.
Sommerville (2003) enumera uma série de fatores que influenciam no trabalho
em equipe: composição (se existe equilíbrio de habilidades, experiência e
personalidade); coesão (se o grupo pensa em si como equipe); comunicação (se os
membros da equipe se comunicam eficazmente); e organização (se a equipe está
organizada de forma que todos se sintam valorizados e satisfeitos com seu papel).
Para Somerville (2003), os gerentes podem encorajar a coesão da equipe de
desenvolvimento de software de diversas maneiras, por exemplo, através da realização
de eventos de confraternização e de esportes coletivos que reforcem a socialização entre
os membros. Estas práticas, conhecidas como Ritos de Integração, podem contribuir
para que o trabalho em equipe realmente aconteça.
Por outro lado, Bossavit (2002), relatando suas experiências pessoais como
treinador de XP, identificou a diferença entre a cultura de comunicação e a cultura de
convivência em uma equipe de desenvolvimento de software. O referido autor notou
que fora do ambiente de trabalho os desenvolvedores possuíam uma convivência aberta
e descontraída, o que não condizia com o ambiente de trabalho, onde a comunicação
parecida ofuscada pelo controle rígido da gerência e pela pressão do tempo para entrega
de software.
Na equipe XP não deve haver formalidade e burocracia entre os
desenvolvedores, de forma a comunicarem-se sem barreiras, sendo que as decisões
devem ser buscadas por meio de discussão e consenso entre os membros. É preciso uma
equipe coesa em que os desenvolvedores podem contar uns com os outros, pois
confiança é essencial para a performance e a interação da equipe.
Para usar a XP os desenvolvedores precisam estar comprometidos com uma
visão compartilhada, já que as suas atividades estão interligadas, complementando-se
mutuamente. A visão dos desenvolvedores deverá ser também sistêmica, ou seja,
97
abrangente de tal forma que se consiga interligar todas as implicações da tarefa que se
está realizando.
Algumas políticas da empresa também podem ter repercussões no trabalho em
equipe. Se o sistema de recompensa da empresa estiver voltado para o indivíduo, pode
gerar concorrência entre os desenvolvedores e dificultar ou até impedir o “espírito de
equipe”. Por outro lado, se o referido sistema estiver voltado para a equipe, pode
estimular a coesão entre os desenvolvedores, bem como a motivação.
Outra política que pode ter reflexos importantes no trabalho em equipe é o
sistema de avaliação de desempenho utilizado na empresa. A avaliação de forma
individual acaba fomentando a busca de desempenho individual e pode gerar
competição. Já a avaliação por equipe desencadeia sentimento de união e esforço
conjunto para alcançar um bom desempenho, podendo surgir inclusive preocupação
com as dificuldades dos colegas.
Além do trabalho em equipe dos desenvolvedores de software, o método XP
contempla um princípio bem particular, trata-se da prática Cliente sempre presente. De
acordo com esta prática, o cliente deverá trabalhar diretamente no projeto, como um
membro efetivo da equipe de desenvolvimento de software, projetando, priorizando
funcionalidades e realizando testes de aceitação.
Para implementar software junto com o cliente a equipe precisa ser atenta,
prestativa e disposta a escutar. Os desenvolvedores devem ter paciência para usar
metáfora, dialogar com alguém que provavelmente não tem seu nível técnico, tentar
entender as prioridades do cliente e ser flexíveis e tolerantes para as possíveis mudanças
que ele possa pretender fazer no software.
Desta forma, é preciso investigar a predisposição da equipe de desenvolvimento
de software para manter contatos constantes com o cliente, bem como se os
desenvolvedores possuem as habilidades necessárias.
Em um estudo de caso, Rising (2002) demonstra a importância do trabalho em
equipe, bem como da prática de reuniões freqüentes para a resolução de problemas e o
progresso de um projeto de software.
98
A experiência vivida por Rising (2002) está relacionada a uma equipe de
software que enfrentava problemas de comunicação e coordenação. Esta equipe era
composta por pessoas de vários projetos e tinha a tarefa de criar um conjunto integrado
de ferramentas. Como os integrantes da equipe pertenciam a diferentes departamentos, a
mesma não possuía um local de trabalho fixo.
Em cada departamento que a equipe se reunia, um novo líder de equipe era
nomeado. A equipe era composta por desenvolvedores experientes - acostumados a
pensar e resolver problemas por conta própria – mas, neste caso, o grupo não vinha
obtendo bons resultados.
A mudança começou a ocorrer quando foi nomeado um líder de equipe com
estilo gerencial, isto é, diferente do sistema hierárquico de gerência adotado até aquele
momento. Ao identificar o problema de comunicação que estava ocorrendo, o novo líder
propôs a adoção de um método de desenvolvimento ágil - Scrum - e a realização de
pequenas reuniões, de 2 a 3 vezes por semana.
No início a idéia de fazer reuniões enfrentou resistência por parte dos
desenvolvedores, que afirmavam estar muito ocupados com o seu trabalho. Porém, com
a persistência do líder, as reuniões começaram a ocorrer e ao invés de um controle
severo do mesmo sobre a pauta da reunião, a tática adotada foi proporcionar um
ambiente onde as pessoas pudessem falar sobre o que estavam desenvolvendo e sobre as
dificuldades que estavam enfrentando.
As reuniões eram de curta duração e não possuíam o intuito de resolver
problemas no momento, mas serviam para exposição dos problemas, oferta de ajuda e
acordo sobre troca de experiências que deveriam ocorrer depois da reunião.
Rising observou que conforme as reuniões foram ocorrendo, a equipe começou a
se unir. Ao invés das pessoas participarem das reuniões apenas para procurar ajuda, elas
demonstraram interesse espontâneo em tentar ajudar os colegas. Assim, quando um
membro da equipe encontrava um obstáculo todo o conhecimento da equipe era
mobilizado para tratar do problema.
99
Rising (2002) concluiu que se não tivessem ocorrido reuniões com discussões
sobre os problemas os desenvolvedores continuariam perdendo muito tempo tentando
resolvê-los antes de pedir ajuda aos colegas. Após esta experiência os desenvolvedores
conseguiram entregar mais facilmente o produto com qualidade dentro do prazo
estabelecido. A autora salienta também, que a partir deste projeto o grupo passou a ser
entusiasta da prática de reuniões freqüentes e do trabalho em equipe.
No estudo de caso de Rising (2002), as reuniões demonstraram a importância
da comunicação em um projeto de software. Esta experiência está relacionada com a
orientação para equipe, que por sua vez, depende de outros aspectos como o estilo de
liderança da gerência ( relacionado com a dimensão Centralização e Descentralização) e
o relacionamento satisfatório entre as pessoas envolvidas no projeto (relacionado com a
dimensão Agressividade).
Itens de verificação relacionados à dimensão Orientação para Equipes:
1. As atividades relacionadas ao desenvolvimento de software são mais orientadas para
tarefas individuais ou para tarefas em equipe?
2. São realizados Ritos de Integração na empresa?
3. Existe “espírito de equipe” entre os desenvolvedores?
4. O sistema de recompensa está direcionado para o indivíduo ou para a equipe?
5. A avaliação do desempenho é feita de forma individual ou por equipe?
6. Os desenvolvedores já tiveram alguma experiência de contato direto com o cliente?
Como ocorreu?
Figura 11: Itens de verificação - dimensão Orientação para Equipes
100
4.1.6 Dimensão: Agressividade
Referindo-se aos métodos ágeis, Miller (2003) afirma que mesmo que a
orientação para pessoas seja uma questão cultural, os métodos ágeis podem
proporcionar mecanismos para os desenvolvedores colaborarem entre si. Porém o autor
ressalta que é necessária uma equipe formada por profissionais qualificados para obter
esta evolução.
A partir das considerações de Miller é possível sugerir que uma empresa que
pretenda adotar um método ágil como a XP precisa ter um percentual considerável de
desenvolvedores bons e motivados em sua equipe, de forma que por meio de
colaboração se encarreguem de capacitar e conduzir os colegas menos experientes. No
entanto, a questão cultural parece não ser tão simples, pois está baseada em convicções
e valores dos membros da empresa.
A colaboração deve estar envolvida nas práticas, nos valores e em todo o
ambiente de trabalho de um projeto XP. A ênfase na comunicação face a face, ambiente
de trabalho compartilhado, interação com o cliente e desenvolvimento de software
iterativo e incremental são alguns dos fatores que comprovam essa premissa.
Na prática Programação pareada, por exemplo, se duas pessoas formam um par
de manhã, à tarde elas podem facilmente fazer duplas com outros colegas, assim, se o
desenvolvedor ficar responsável por uma área que não lhe é familiar, terá que pedir para
alguém com experiência recente para fazer uma dupla (BECK, 2004). Neste caso, um
desenvolvedor deve estar disposto a ensinar o outro, transmitindo-lhe seu conhecimento.
Alguns indícios podem ajudar a detectar se existe colaboração entre os
desenvolvedores. É preciso verificar se costumam recorrer aos colegas quando surgem
dúvidas, se resolvem problemas de forma colaborativa, se compartilham conhecimentos
e informações sobre suas tarefas, se a comunicação entre eles ocorre de forma informal
e franca. Estes aspectos culturais também podem revelar se há honestidade e confiança
para se expor diante dos colegas - aspectos essenciais para adoção da XP.
101
Cockburn (2001) ressalta que é preciso ser cauteloso em ambiente que haja
excessivo zelo e respeito pelos colegas a ponto dos desenvolvedores não discordarem
sobre decisões técnicas por medo de ofenderem-se. Torna-se necessário não confundir
discussão técnica com discussão pessoal.
A discussão técnica é benéfica para o projeto e pode ocorrer, por exemplo, na
escolha da linguagem de programação. Já a discussão pessoal pode ser originada de
diferenças pessoais que geram competição e conflitos internos no projeto.
A necessidade de contar-se com um ambiente colaborativo, em que as pessoas
possam confiar umas na outras, torna-se bem clara na prática Código Coletivo, em que
qualquer desenvolvedor pode modificar qualquer parte do código, em qualquer lugar do
sistema e a qualquer momento.
A ruptura com os métodos tradicionais de software é grande, considerando-se
que na propriedade individual somente o proprietário do trecho do código pode alterá-
lo, e se alguém perceber que o código precisa de alteração vai precisar da autorização do
proprietário para fazer a modificação. Na XP, usando-se a propriedade coletiva do
código todos são responsáveis pelo sistema inteiro.
Para apontar erros e alterar o código dos outros programadores é preciso haver
honestidade e respeito na equipe e também coragem para corrigir o que está errado,
mesmo que o erro seja do colega. Os desenvolvedores precisam ter liberdade para
expressar seus receios e precisam receber e dar apoio.
A colaboração pode ser estimulada através de Ritos de Integração, como
confraternizações e esportes praticados em grupo. Por mais que existam divergências e
conflito entre os funcionários, estas práticas forçam o convívio e podem amenizar a falta
de colaboração que possa existir.
Por outro lado, a gerência pode também promover a competição entre os
desenvolvedores acenando a possibilidade de recompensa e reconhecimento individuais.
Entretanto, uma atmosfera de competição pode ser criada pelos próprios membros da
equipe, se este for o perfil dos desenvolvedores. Neste caso a competição pode surgir
102
como uma disputa de egos. De qualquer forma, a competição entre os membros da
equipe configura-se em um aspecto desfavorável à adoção da XP.
Conflitos pessoais existentes na equipe de desenvolvimento também são
desfavoráveis à XP, já que dificilmente se conseguirá realizar práticas como
Programação pareada e Código Coletivo com desenvolvedores que possuem barreiras
emocionais entre si.
Em relação ao cliente, Highsmith (2002) diz que sempre há conflito nas relações
cliente-desenvolvedor, pois “os clientes sempre querem mais, mais rápido, custo mais
baixo e alta qualidade, já os programadores querem mais tempo, exigências estáveis e
pagamentos adicionais”.
Conforme Kent Beck (apud HIGHSMITH, 2002) afirma, quando os clientes não
adquirem tudo o que querem e os programadores não são pressionados demais é
possível alcançar um equilíbrio razoável. Os conflitos podem ser inevitáveis, mas o que
faz a diferença é como se lida com eles. Conflitos poucos controlados reduzem a
confiança, enquanto conflitos bem controlados melhoram a confiança, assim se pode ter
um ambiente virtuoso ou destrutivo (HIGHSMITH, 2002).
Também é muito importante para a XP a existência de um bom relacionamento
entre a gerência e os desenvolvedores de forma que estes possam obter rapidamente as
informações que precisam sem empecilhos resultantes de formalidade e subordinação.
A equipe XP precisa ter confiança e proximidade com a gerência, pois os contatos
exigidos aumentam bastante neste método, sendo que o gerente deve estar disposto a dar
atenção à equipe.
A observação do departamento de informática de uma instituição de ensino que
estava tentando adotar XP permitiu identificar alguns aspectos da cultura e estrutura
organizacional relacionados com a dimensão Agressividade.
Em conversa com um desenvolvedor do departamento de informática, foram
obtidas informações sobre a forte disputa pelo poder dentro da organização, a qual
pressupõe o insucesso na tentativa da adoção da XP. Segundo o desenvolvedor, o
103
gerente do departamento possui um forte anseio de ascensão profissional, visando
assumir cargos mais importantes dentro da organização.
Conforme o relato, estes valores do gerente do departamento conduzem a
comportamentos que revoltam os colegas. Por exemplo, ao apresentar os resultados do
trabalho da equipe de desenvolvimento aos seus superiores, o gerente do departamento
costumava atribuir a si os méritos e conquistas - quando na maioria das vezes são do
grupo.
Com esta atitude o gerente acredita estar se fortalecendo na hierarquia de poder
da organização. Suas crenças e valores geram um clima de desconfiança no
departamento, de forma que os colegas são vistos como rivais que podem ameaçar sua
posição.
Porém, observando o local de trabalho e conversando com outros membros da
equipe de desenvolvimento de software, percebeu-se que esta disputa pelo poder acabou
contaminando toda a equipe. A competição faz parte da cultura organizacional e não se
limita ao gerente do departamento, pois existe um sentimento de desconfiança e forte
disputa de poder na instituição.
Embora os desenvolvedores estivessem programando em um ambiente único e já
tenham adotados algumas práticas XP, como integração de código, refatoração e
padrões de programação, pelo que se verificou a programação em par praticamente não
é utilizada porque os desenvolvedores achavam que o trabalho “rende mais se for
individual”.
Na verdade, a equipe não conseguiu adotar a XP, limitando-se a utilizar algumas
práticas isoladas que demandam trabalho individual, o que certamente decorre da falta
de confiança e colaboração entre os desenvolvedores.
104
Itens de verificação relacionados à dimensão Agressividade:
1. Os desenvolvedores costumam recorrer aos colegas quando surgem dúvidas ou
dificuldades? Há ajuda mútua?
2. Os desenvolvedores compartilham conhecimentos e informações?
3. Há um bom entrosamento na equipe de desenvolvimento?
4. Há competição entre os desenvolvedores?
5. Há conflitos entre os desenvolvedores? Como são resolvidos?
6. Como é o relacionamento entre a equipe e a gerência?
Figura 12: Itens de verificação - dimensão Agressividade
4.1.7 Dimensão: Estabilidade
A cultura de uma empresa pode ser não-adaptativa e voltada para o status quo,
de forma que apresente baixa capacidade de mudança e conservadorismo. Estas
organizações mantêm idéias, valores, costumes e tradições que permanecem arraigados
e que não mudam ao longo do tempo, ou seja, permanecem como se nada tivesse
ocorrido ao seu redor (CHIAVENATO, 1999).
A adoção do método XP sempre requer mudanças em qualquer empresa de
software. Porém, alguns elementos organizacionais relativos à dimensão Estabilidade
podem representar uma barreira para a adoção do referido método. A mudança sempre
cria problemas, independentemente do grau de planejamento, mas o número e os tipos
de problemas dependem da organização e da sua capacidade de mudar (ASTELS,
2002).
Algumas empresas são pouco dedicadas a sua adaptação ao mercado e às novas
tecnologias, valorizando mais a previsibilidade e a segurança já alcançada através das
técnicas que tiveram sucesso confirmado na empresa com o passar do tempo. Já outras
105
empresas estão preocupadas em incorporar novas tecnologias e compreender as
tendências do mercado.
Geralmente as empresas de software admitem a necessidade de adaptabilidade,
mas nem sempre se empenham para torná-la realidade. Neste sentido, é preciso verificar
se a empresa costuma adotar novas tecnologias, se tem lançado software novo no
mercado, se costuma adotar novas formas de trabalho.
A adoção da XP pode ser aceita com mais facilidade em empresas que possuem
valores culturais relacionados à inovação, pois empresas que possuem dificuldades de
mudar o status quo, priorizando segurança e previsibilidade, podem preferir continuar
apegadas a sua forma habitual de desenvolver software.
O perfil dos desenvolvedores também influencia na aceitação do método XP.
Dois extremos podem ser citados como exemplo: programadores novatos que acreditam
que ao adotar a XP terão menos formalidade e mais produção de código; e
programadores mais experientes que já possuem pressupostos formados sobre como
devem desenvolver software - eventuais experiências frustrantes com outras mudanças
podem estar presentes - preferindo, assim, continuar usando o método que já estão
acostumados.
Itens de verificação relacionados à dimensão Estabilidade:
1. A empresa é aberta a novas tecnologias?
2. A empresa tem lançado novos softwares no mercado?
Figura 13: Itens de verificação - dimensão Estabilidade
106
4.2 Estrutura Organizacional e a Extreme Programming
4.2.1 - Dimensão: Especialização do Trabalho
Mesmo em ambientes dinâmicos como os verificados em empresas de
desenvolvimento de software, o trabalho tende a gerar uma certa rotina em relação a
determinadas responsabilidades assumidas e problemas a serem resolvidos. Contudo, a
adoção do método XP requer que os desenvolvedores assumam mais responsabilidades
ao invés de desempenharem apenas os papéis que estão habituados.
Conforme Teles (2004), no método XP os desenvolvedores deverão analisar,
projetar e codificar o sistema, pois neste método não existem divisões claras para
analista, projetista e programador, mas cada desenvolvedor exerce estes diferentes
papéis em diversos momentos do projeto. Anderson (2003) afirma que o método XP
necessita de desenvolvedores generalistas e experientes.
Mesmo que o desenvolvedor seja especialista em alguma função, no método XP
o mesmo deverá conhecer e atuar em um número maior de tarefas, pois a tarefa
individual muda constantemente como resultado da interação com os demais
desenvolvedores da equipe.
Na programação pareada, por exemplo, todos formam pares com todos, sendo
que os pares mudam tanto que qualquer um pode assumir qualquer tarefa, desta forma,
há poucas chances de apenas uma ou duas pessoas compreenderem o sistema (BECK,
2004).
Vários fatores culturais poderão ter implicações ao se pretender que
desenvolvedores que não costumam assumir outras funções além da sua passem a
desempenhar atividades como realizar testes, realizar código coletivo e manter contatos
constantes com o cliente. Os desenvolvedores podem não estar dispostos a assumir
107
mais responsabilidades, podem não deter conhecimento para realizar outras funções ou
até mesmo não ter aptidões para determinadas tarefas.
Empresas que possuem flexibilidade funcional de forma que os desenvolvedores
costumam assumir tarefas diferentes - mesmo que eventualmente - podem encontrar
mais facilidade de se adaptar ao método XP. Já empresas que possuem desenvolvedores
de software com papéis rigidamente definidos - que sejam especialistas em apenas uma
determinada função nos projetos de software, como banco de dados, qualidade do
software, análise de sistemas - estão mais sujeitas à resistência para se ajustar à XP.
Porém, para a XP não basta ter desenvolvedores generalistas se predomina entre
eles a baixa qualificação técnica, pois a sinergia das práticas XP pressupõe uma equipe
disposta, flexível e experiente. Caso haja um desnível de conhecimento técnico na
equipe é necessário que os desenvolvedores mais experientes transfiram conhecimento
para os menos experientes. Entretanto uma equipe formada somente por novatos pode
enfrentar grandes dificuldades nas práticas XP.
Quanto a um grande desnível de experiência entre os desenvolvedores, McBreen
(2002) afirma que após se adquirir experiência no uso da XP até se pode ter uma equipe
formada de desenvolvedores experientes, intermediários, e novatos, mas isto não deve
ocorrer no primeiro projeto XP, o qual requer desenvolvedores com bastante
experiência.
Além de possuir habilidades técnicas, os desenvolvedores XP devem possuir
também habilidades pessoais, que nem sempre se verificam nos programadores, por
exemplo: desenvoltura para tratar com o cliente, equilíbrio para se impor ou aceitar
quando necessário, coordenar-se e comunicar-se intensamente com outros
programadores.
Asproni (2004) entende que as habilidades pessoais fazem a diferença no método
XP. O autor diz que em sua experiência percebeu que é mais importante para um
desenvolvedor ágil ter habilidade para aprender novas técnicas e adaptar-se às
mudanças da situação. Desta forma, ao considerar os aspectos culturais e estruturais da
empresa para a adoção do método XP é fundamental avaliar o potencial de
108
conhecimento, habilidades pessoais e flexibilidade funcional dos membros da equipe de
desenvolvimento de software.
Itens de verificação relacionados à dimensão Especialização do Trabalho:
1. Os desenvolvedores de software costumam assumir mais de uma função, por
exemplo, acumular papéis como programador, projetista, testador?
2. Considerando o conhecimento e as habilidades dos desenvolvedores, os mesmos
teriam condições de assumir mais de uma função num projeto?
3. Os programadores são relutantes para assumir mais responsabilidades pessoais?
4. Qual o nível de experiência dos membros da equipe de desenvolvimento de
software?
Figura 14: Itens de verificação - dimensão Especialização do Trabalho
4.2.2 - Dimensão: Departamentalização
Segundo o MCT – Ministério da Ciência e Tecnologia (2004), a maioria das
empresas de software brasileiras é micro ou pequena, por isso as empresas deste porte
podem não possuir departamentos para cada atividade do processo de desenvolvimento
de software (departamento de design, departamento de programação, departamento de
qualidade, etc.). Por outro lado, é comum os desenvolvedores estarem separados por
baias ou salas.
A departamentalização pode gerar concorrência, fragmentação do trabalho e
dificultar a comunicação entre os desenvolvedores de software. As práticas XP
implicam em trabalho conjunto e integrado, de forma que se os desenvolvedores que
estejam trabalhando num mesmo projeto de software estiverem separados por baias, por
salas, ou estiverem em andares ou até em cidades diferentes haverá dificuldade para a
109
adoção da XP. A dificuldade aumenta proporcionalmente à distância física verificada
entre os desenvolvedores.
A organização física do espaço de trabalho exerce grande influência na adoção
do método XP, pois suas práticas dependem de um espaço físico apropriado. Da mesma
forma, a eficácia dos valores XP como comunicação e feedback dependem da
proximidade das pessoas.
Segundo Williams (2000-a), para a realização da prática Programação pareada
um ambiente físico adequado é fundamental. O ambiente deve disponibilizar um certo
conforto, os desenvolvedores devem ficar sentados lado a lado, ambos tendo acesso ao
teclado e ao mouse, com boa visualização do monitor. A sala deve ser ampla para conter
todos os desenvolvedores e não devem existir divisórias ou cubículos que isolem as
duplas, já que a conversa com as outras duplas pode contribuir para determinadas
tarefas.
O ambiente único propicia a baixa documentação, pois a informação circula com
mais facilidade sendo mais informal.. Também proporciona a possibilidade dos
desenvolvedores acompanharem e estarem bem informados a respeito do trabalho dos
colegas, o que é necessário para alterar o código coletivo, realizar refactoring, definir os
cartões de tarefas a partir dos cartões de histórias e outras atividades que são realizadas
por praticamente todos os desenvolvedores.
Deve-se verificar se a empresa que pretende adotar o método XP possui o
ambiente físico adequado para sua implementação, de forma a viabilizar a efetivação de
suas práticas e valores. Caso o ambiente físico da empresa não esteja adequado, é
preciso investigar se é possível alterá-lo e, principalmente, se as pessoas estão dispostas
a se ajustar ao novo meio.
Criar um ambiente único para os desenvolvedores que estão acostumados a
trabalhar em baias ou em salas diferentes pode ser uma tarefa sujeita à resistência. Em
alguns casos remover baias ou divisórias pode gerar sensação de perda da
individualidade, ou de um espaço que o programador possua sentimento de posse, de
110
forma que este possa entender que está sendo desrespeitado em relação a seus domínios
e privacidade.
É importante que os desenvolvedores estejam pré-dispostos a trabalhar em um
sistema de colaboração. Para tanto, deve-se procurar identificar se há incidência de
conflitos pessoais ou graus elevados de concorrência entre os desenvolvedores, caso em
que estes aspectos culturais podem barrar a efetivação da Programação pareada, a
utilização de Código Coletivo, a flexibilidade funcional e a comunicação informal e
franca.
A postura da empresa em relação aos funcionários também pode ser um fator
importante na viabilidade da criação de um espaço único de trabalho para os
desenvolvedores de software. É preciso identificar políticas da empresa que possam
incentivar ou desestimular o trabalho em equipe, pois estes aspectos podem influenciar
na disposição dos desenvolvedores de trabalharem em um ambiente único.
Tais fatores podem ser encontrados ao se verificar aspectos como: se a empresa
costuma direcionar o trabalho mais para a equipe que para o indivíduo, se os sistemas de
recompensa e de avaliação são individuais ou por equipe e se estimula a competição
como forma de alcançar o poder (Itens de verificação relacionados à dimensão
Orientação para Equipe).
Itens de verificação relacionados à dimensão Departamentalização:
1. Como está organizado o ambiente de trabalho dos desenvolvedores de software que
estejam envolvidos em um mesmo projeto?
2. Considerando aspectos culturais como colaboração, comunicação, espírito de equipe e o
entrosamento entre os desenvolvedores, é possível criar um ambiente de trabalho único?
Figura 15: Itens de verificação - dimensão Departamentalização
111
4.2.3 Dimensão: Cadeia de Comando
As empresas de software podem possuir vários níveis hierárquicos ou
apresentarem níveis mínimos de hierarquia. Na hierarquia da empresa podem estar
presentes proprietários, gerentes administrativos, gerente de software, gerente de
qualidade de produto, etc.
A empresa que pretende adotar a XP precisa ter agilidade para atender demandas
como, manter contatos constantes com o cliente, estabelecer relacionamento e
comunicação aberta com a equipe de desenvolvimento de software e tomar decisões
rápidas sobre o projeto. Desta maneira, o número de níveis hierárquicos pode exercer
influência na adaptação ao referido método.
Além disso, caso a decisão de adotar a XP depender de várias pessoas, como
proprietários da empresa, gerentes e de subgerentes, é possível que sejam impostas
barreiras culturais que decorrem da necessidade de aceitação de valores que podem ser
considerados contrários ao mercado ou contrários a procedimentos e normas comum das
empresas como:
a) fazer contrato de escopo aberto - por causa do risco de desistência do
cliente, o que causa insegurança na negociação;
b) trabalhar com pouca documentação - pode parecer que se terá menos
segurança;
c) programação pareada – pode estar presente o mito de que haverá custo de
manter dois funcionários desenvolvendo o trabalho que apenas um poderia fazer;
d) disponibilizar mais tempo para testes – pode ser encarado como desperdício
de tempo.
Ou seja, a presença de crenças e alguns mitos a respeito da XP - os quais são
muito comuns - podem impedir a aceitação do método, e quanto mais pessoas tiverem
que dar seu parecer a respeito mais aumentam as chances de rejeição. Cabe considerar
112
que mesmo que a escolha da uma nova tecnologia pareça uma decisão técnica, ela é na
verdade uma decisão de negócios, que pode depender inclusive do cliente da empresa.
Nos cargos hierárquicos pode estar presente o responsável por aprovar e destinar
recursos para os projetos de software, o qual é identificado como “Proprietário do ouro”
na XP. Na literatura que trata da XP, o papel do “Proprietário do ouro” normalmente é
negligenciado por se pressupor que a empresa já obteve o seu consentimento e o apoio
financeiro para o projeto de software.
Entretanto, um fator fundamental para a implantação da XP é a aceitação dos
responsáveis pela destinação de recursos para o projeto. Salvo os casos em que o
gerente do projeto possua a autonomia para decidir sobre o método, o “Proprietário do
ouro” deverá estar de acordo em investir recursos em projetos XP.
Níveis hierárquicos também podem se estabelecer dentro de equipes de
desenvolvimento de software por meio de cargos - mesmo que informalmente. Os níveis
hierárquicos podem estar configurados em cargos como líder de equipe, programador
sênior, programador júnior.
Tomayko (2004) diferencia 2 tipos de estruturas de equipes de desenvolvimento
de software, identificando equipes com estrutura hierárquica e equipes com estrutura
democrática.
a) Na estrutura da equipe democrática os membros são encarados como colegas,
e as opiniões dos programadores são consideradas como tendo o mesmo peso. As
equipes democráticas tendem a nivelar as pessoas e mesmo que seja necessário
estabelecer níveis hierárquicos isso ocorre mais informalmente, de forma que os
desenvolvedores menos experientes reconheçam os que detêm maior conhecimento na
área e a quem se reportar quando necessário (TOMAYKO, 2004).
b) Em equipes com estrutura hierárquica existem diferentes níveis de hierarquia.
Neste caso pode haver um bom grau de delegação de poder ou uma concentração de
poder nos níveis mais altos. Se o poder fica mais concentrado o programador de nível
mais baixo deve transpor os níveis superiores para atingir a pessoa que detém poder de
decisão (TOMAYKO, 2004).
113
Mesmo que a equipe de desenvolvimento de software não possua muitos níveis
hierárquicos, é importante identificar como os papéis estão definidos dentro da mesma e
qual a sua implicação no relacionamento entre as pessoas, ou seja, qual a importância
que as pessoas dão ao status dos papéis. Para a XP o ideal é que os cargos e níveis sejam
quase despercebidos dentro da equipe.
Para Sommerville (2003) pessoas em grupos informalmente estruturados se
comunicam mais efetivamente do que em grupos com uma estrutura formal. Em grupos
hierárquicos, a comunicação tende a fluir de cima para baixo e as pessoas do mesmo
nível podem não conversar entre si.
A diferença de status entre os membros da equipe pode significar que a
comunicação é feita geralmente em uma única direção, pois os membros com status
superior tendem a dominar a comunicação e os membros de status inferior muitas vezes
relutam em dar início a uma conversa ou fazer observações críticas.
Segundo Robbins (1999), a Cadeia de Comando está diretamente relacionada ao
grau de autoridade. Quanto mais forte for a cadeia de comando, os membros terão
menos informação e poder de tomada de decisões. Quanto mais fraca for a cadeia de
comando os membros terão mais informações e maior possibilidade de se auto-
gerenciar.
Além disso, quanto mais forte for a cadeia de comando maior será o número de
níveis através dos quais a comunicação passará, aumentando a possibilidade de
distorção e o tempo gasto para que a comunicação seja completada (VASCONSELLOS;
HEMSLEY, 1997).
Asproni (2004) lembra que “um estilo de gerência comando de controle não é
adequado para um ambiente em que os indivíduos e a comunicação são mais valiosos
que processos e ferramentas”. O achatamento do sistema hierárquico permite a difusão
da informação de maneira mais fácil e rápida, permitindo que os contatos pessoais
substituam as comunicações escritas. Assim, a comunicação passa a se basear mais na
confiança entre as pessoas do que nos papéis e regras que as norteiam.
114
A XP não prescreve que sejam destituídos cargos, mas requer que os
desenvolvedores tenham autonomia para tomar decisões sobre o processo de
desenvolvimento de software e interagir com o cliente. Porém este requisito da XP pode
gerar resistência quando o gerente não confia no potencial de sua equipe, ou quando
simplesmente a cultura da empresa é hierárquica.
Itens de verificação relacionados à dimensão Cadeia de Comando:
1. Quantos níveis hierárquicos (relacionados ao desenvolvimento de software) existem na
empresa?
2. Existem níveis hierárquicos (formais ou informais) na equipe de desenvolvimento de
software?
3. Como é a comunicação entre os membros da equipe de desenvolvimento?
4. Como é a comunicação entre a equipe de desenvolvimento e a gerência?
Figura 16: Itens de verificação - dimensão Cadeia de Comando
4.2.4 Dimensão: Margem de Controle
Leblanc (2004) relata alguns fatores da XP que devem ser observados, entre eles
o autor chama a atenção para o tamanho da equipe de desenvolvimento de software.
Segundo Leblanc, a XP foi idealizada para pequenas equipes que contenham de 2 a 12
desenvolvedores, pois está baseada na premissa de que equipes pequenas são mais
flexíveis e se adaptam melhor a mudanças no projeto.
Outra consideração de Leblanc (2004) é que as equipes devem partir de dois
integrantes para que ocorra a prática Programação pareada. Estas duas pessoas se
revezam conforme necessário e trocam idéias para encontrar a melhor solução para um
problema específico.
115
Além disso, processos ágeis como a XP necessitam de equipes pequenas porque
nestas condições se promove melhor o espírito de equipe e a sensação de que cada
pessoa é importante e não apenas um funcionário a mais da empresa. Isso ajuda a dar
motivação aos desenvolvedores para que eles façam parte da evolução do processo e
melhorem sua produtividade, qualidade e desempenho (ASTELS, 2002).
Á medida que o grupo aumenta em tamanho, torna-se mais difícil garantir que
todos os membros se comuniquem eficazmente uns com os outros (SOMMERVILLE,
2003). No método XP a comunicação é supervalorizada, pois os desenvolvedores têm
que ter conhecimento das atividades dos colegas para trabalhar num ambiente de intensa
interação.
De acordo com Hampton (1990), o tamanho e a estrutura do grupo podem
influenciar na sua capacidade de operar de forma satisfatória e eficaz, sendo que
diversas pesquisas confirmam os efeitos do tamanho sobre a capacidade do grupo de
resolver problemas.
A partir destas pesquisas Hampton (1990) faz algumas generalizações: grupos de
aproximadamente 5 a 11 membros tendem a tomar decisões mais precisas que grupos
que estão fora desta faixa; grupos menores são mais capazes de obter consenso que
grupos maiores; em grupos grandes pode ocorrer a formação de subgrupos com metas
próprias que são incompatíveis com as do grupo maior.
Itens de verificação relacionados à dimensão Margem de Controle:
1. Qual é o número de desenvolvedores que costumam trabalhar num mesmo projeto
de software?
Figura 17: Itens de verificação - dimensão Margem de Controle
116
4.2.5 Dimensão: Centralização e Descentralização
Fowler (2003) ressalta que para um processo orientado para pessoas como a XP,
é fundamental a delegação de poderes para que os desenvolvedores possam tomar
decisões técnicas e realizarem estimativas. O autor também afirma que esta mudança
deve influenciar diretamente no nivelamento de autonomia e autoridade entre gerentes e
desenvolvedores.
Práticas XP como Cliente sempre presente, Jogo de Planejamento e entregas
freqüentes requerem poder de ação e de reação por parte dos desenvolvedores. Para
deter estes poderes é preciso que a empresa conceda mais autoridade e informação a
quem está mais perto da “ação” – isto é, para quem está mais próximo do produto
(software) ou do cliente.
Na XP, a velocidade e a eficiência estabelecem a necessidade de que muitos
problemas precisam ser resolvidos pelos desenvolvedores sem ter que recorrer a
superiores. Se isto não ocorrer a equipe de desenvolvimento pode ficar presa a uma
burocracia que inviabiliza a utilização do método.
Além do mais, Práticas XP como Jogo de Planejamento e Reuniões em Pé
apenas farão sentido em um ambiente em que os desenvolvedores se sintam ouvidos e
respeitados pela gerência.
Se os investidores, os proprietários ou os gerentes forem muito exigentes e
controladores podem encarar a delegação de poder como aumento de risco para a
empresa. Ao não delegar poder e, por conseguinte, restringir o arbítrio dos
desenvolvedores, podem tornar a empresa propensa a um processo de desenvolvimento
de software mais prescritivo.
Para que os superiores hierárquicos estejam dispostos a delegar poderes é
preciso haver confiança nos desenvolvedores de software, sobretudo no que diz respeito
a seus conhecimentos, isto é, a gerência deverá sentir que os desenvolvedores são
capazes de tomar decisões. Por outro lado, os desenvolvedores deverão estar dispostos a
117
assumir mais responsabilidade e riscos, já que na medida em que se recebe delegação, o
trabalho e a margem de risco aumentam.
Na XP as decisões sobre os negócios devem ser tomadas pelo cliente e pela
gerência e as decisões técnicas devem ficar sob responsabilidade da equipe de
desenvolvimento. Beck (2004) enumera os seguintes assuntos que devem ser decididos
pela equipe:
a) estimativas - tempo que levará para implementar uma funcionalidade;
b) conseqüências das alternativas técnicas – ao estimar as conseqüências
técnicas a equipe fornece dados para a gerência tomar decisões estratégicas do negócio;
c) processo - de que forma o trabalho e a equipe serão organizados, o conjunto
de práticas que serão usadas, o processo para revisar as práticas;
d) cronograma - dentro do ciclo de entrega, decidir quais histórias serão feitas
primeiro.
Assim, para utilizar o método XP, o ambiente de trabalho deve ser colaborativo
e não pode se prender tanto a regras predeterminadas por superiores, mas precisa existir
uma boa margem de escolha à disposição dos desenvolvedores. Além disso, a gerência
deve assumir o papel de motivadora e facilitadora no processo de desenvolvimento de
software.
A gerência deverá estabelecer uma liderança que viabilize a disseminação dos
valores organizacionais requeridos pelo método XP. Chiavenato (2002), baseando-se
nos estudos de White e Lipitt, descreve três tipos de liderança:
a) Liderança Autocrática: apenas o líder decide e fixa as diretrizes sem
qualquer participação do grupo, determinando qual tarefa que cada um deverá executar.
b) Liderança Liberal: há total liberdade para tomada de decisões grupais ou
individuais, sendo que a participação do líder é limitada a apresentar alternativas ao
grupo e fornecer informações. As tarefas ficam à escolha do grupo.
118
c) Liderança Democrática: as diretrizes são debatidas e decididas pelo grupo
que é estimulado e assistido pelo líder. O próprio grupo define as providências e
técnicas para atingir os objetivos com aconselhamento técnico do líder, quando
necessário, desta forma, as tarefas ganham novas perspectivas e debates. A divisão das
tarefas fica a critério do grupo.
Mesmo contando-se com desenvolvedores ideais para a XP, a adoção da mesma
pode tornar-se inviável se a gerência da empresa tiver uma liderança autocrática com
uma visão mecanicista, em que as decisões sejam de cima para baixo.
No método XP os desenvolvedores devem descobrir por si mesmos como
melhorar e agilizar seu trabalho. Se a organização é fundamentalmente hierárquica e
top-down um processo de software mais passível de controle torna-se mais adequado –
método tradicional. Já os métodos ágeis como a XP são mais adequados e se ajustam
com mais facilidade em uma cultura colaborativa (HIGHSMITH, 2002).
Provavelmente será difícil migrar de um modo de trabalho em que são
fornecidas orientações detalhadas das tarefas e partir para uma forma de trabalho na
qual as decisões devem ser tomadas pelos desenvolvedores juntamente com o cliente, de
forma a ser necessário assumir mais riscos e delegar poderes.
A distribuição do poder também pode ter implicações na própria equipe de
desenvolvimento de software. A prática XP Código Coletivo fornece um exemplo claro
desta situação: um programador menos experiente precisa estar à vontade dentro da
equipe e ter coragem para alterar o código de um programador mais experiente ou
questionar alguma decisão no desenvolvimento de software. Equipes hierárquicas, com
desnível de poder fornecem um ambiente desfavorável à adoção da XP.
Ademais, no método XP a autoridade pode mudar dependendo de quem estiver
mais capacitado para realizar determinada tarefa, e o conteúdo das comunicações tende
a ter mais informações e conselhos do que ordens ou instruções.
119
Itens de verificação relacionados à dimensão Centralização e Descentralização:
1. A equipe possui participação ativa na resolução de problemas relacionados ao
projeto?
2. Qual o estilo de liderança na empresa?
Figura 18: Itens de verificação - dimensão Centralização e Descentralização
4.2.6 Dimensão: Formalização
A formalização dos cargos afeta o nível de autonomia do ocupante do cargo no
processo de tomada de decisão. Empresas altamente formais fornecem um grau mínimo
de autonomia ao ocupante do cargo sobre o que deve ser feito (ROBBINS, 1999).
A alta formalização garante que os membros ajam de maneira uniforme e
previsível e está relacionada ao grau em que o gerente acredita que seus subordinados
possuem capacidade de autonomia. Assim, quanto maior o nível de formalização
(documentos e normas) menor o nível de confiança do gerente nos membros da equipe
(TRACY, 1994).
Se a formalização está presente em níveis altos na empresa haverá mais
necessidade de documentação. Ou seja, a comunicação entre os programadores,
gerência e clientes se dá em grande parte através de documentação em detrimento da
comunicação direta, de maneira que as informações são transmitidas de forma mais
lenta, podendo ser inclusive mal interpretadas.
De acordo com Ambler (2004), muitas organizações acabam supervalorizando a
documentação em seus projetos de software principalmente por medo de perder
membros da equipe de desenvolvimento que possuam informações e conhecimentos não
documentados.
O autor considera esta atitude uma crença que se mostra impotente na prática,
pois segundo ele os desenvolvedores dificilmente seguem a documentação deixada por
120
outra pessoa e tendem a investigar o código deixado ou partir para uma nova
implementação. Ambler (2004) sugere que a atenção excessiva com documentação deve
ceder lugar para a preocupação em desenvolver código de qualidade.
A XP representa uma alternativa ao excesso de documentação visando garantir o
conhecimento de todos sobre o projeto, o que pode ser observado em práticas como
Código Coletivo, Refactoring, Padrão de Programação e Programação pareada. Estas
práticas procuram permitir que todos possuam conhecimento sobre o que os colegas
estão desenvolvendo e que o sistema seja simples e revisado o suficiente para sua fácil
compreensão, de forma que a ausência de um membro da equipe não gere uma lacuna
no conhecimento sobre o projeto.
Assim, empresas de software que exigem altos níveis de documentação podem
encontrar dificuldades na migração para o método XP, o qual requer que a
documentação deva ser apenas a essencial para o entendimento do sistema, sendo que
grande parte da mesma é convertida em comunicação oral. Nesse caso, os aspectos
culturais desfavoráveis à adoção da XP são oriundos principalmente da dificuldade de
se abrir mão da segurança que os membros da empresa encontram na documentação.
Para Ambler (2004) um dos fatores que dificultam a adoção de uma abordagem
ágil em empresas de desenvolvimento de software é a cultura organizacional voltada
para processos de software muito prescritivos. Segundo Ambler, este aspecto cultural é
mais comum em grandes empresas que possuem seu processo de desenvolvimento de
software bem-definido. É possível presumir que tais empresas – devido à sua história e
porte - possuam um nível considerável de departamentos, regras e formalismo, porém
esta característica também pode estar presente em algumas empresas de software de
menor porte.
Ambler (2004) chama a atenção para os possíveis desafios estruturais e culturais
de adotar uma metodologia ágil em empresas que buscam certificação ou seguem algum
programa de qualidade, como a linha ISO ou CMM, pois nestas empresas muitas vezes
seguem processos mais prescritivos e bem documentados. Apesar de algumas pesquisas
buscarem demonstrar que é possível compatibilizar estas tecnologias (PAULK, 2001;
121
JEFFRIES, 2000), certamente as barreiras culturais ao método XP devem se acentuar
em empresas com este perfil.
Segundo dados do MCT (2004), no cenário nacional apenas 7% das empresas de
software estavam certificadas com ISO ou CMM até o ano de 1999. Este número pode
estar relacionado ao fato desses programas serem projetados para empresas de grande
porte, sendo difícil de ajustá-los à realidade das pequenas empresas.
Empresas de pequeno porte costumam possuir uma esfera de controle reduzida,
poucos níveis hierárquicos e geralmente não apresentam muita formalidade. A princípio
estas características representam um ambiente apropriado para a XP. Porém a baixa
formalização, muitas vezes também pode caracterizar deficiências organizacionais
como a informalidade do processo de software e um sistema de gerenciamento ineficaz.
Itens de verificação relacionados à dimensão Formalização:
1. As orientações da gerência são repassadas aos desenvolvedores de forma precisa e
detalhada ou de forma ampla, deixando margem para escolha?
2. Qual o nível de documentação de software exigido na empresa?
3. A Empresa possui algum programa de qualidade ou obteve algum tipo de
certificação?
Figura 19: Itens de verificação - dimensão Formalização
4.3 Aspectos Culturais e Estruturais Favoráveis ou Desfavoráveis à Adoção da XP
Ao analisar as dimensões dos fatores organizacionais sob a perspectiva das
práticas e valores XP tornou-se possível a identificação de aspectos culturais e
estruturais favoráveis ou desfavoráveis à adoção da XP. Estes aspectos estão expostos
na tabela abaixo:
122
CULTURA ORGANI-ZACIONAL
ASPECTOS
FAVORÁVEIS À XP
ASPECTOS DESFAVORÁVEIS À XP
Inovação e Risco
- Desenvolvedores criativos e inovadores
- Receptividade das sugestões por parte da gerência
- Sistema de Recompensa que incentiva criatividade e desempenho
- Erros tratados como parte do processo de aprendizagem
- Desenvolveres com perfil conservador
- Gerência não receptível às sugestões
- Sistema de Punição de erros
Orientação para Detalhes
- Desenvolvedores analíticos
- Filosofia de melhoria constante
- Intensificação de testes
- Atenção voltada para o todo
- Resistência à intensificação de testes
Orientação para Resultados
- Valorização dos funcionários
- Preocupação com a satisfação do cliente
- Forte orientação para lucratividade e redução de custos em detrimento da valorização dos funcionários e do cliente
- Exigência de desempenho dos desenvolvedores em forma de horas extras
Orientação para Pessoas
- Motivação
- Benefícios
- Salário satisfatório
- Plano de carreira
- Reconhecimento
- Desenvolvedores desmotivados
- Inexistência de políticas de valorização do capital humano da empresa
Orientação para Equipes
- Tarefas direcionadas para a equipe
- Sistema de recompensa por equipe
- Sistema de avaliação por equipe
- Ritos de Integração
- Espírito de equipe e coesão
- Tarefas direcionadas para o indivíduo
- Sistema de recompensa por indivíduo
- Sistema de avaliação individual
- Falta de coesão na equipe de desenvolvimento
Agressividade
- Colaboração
- Compartilhamento de conhecimentos e informações
- Confiança e informalidade
- Solução de conflito democrática
- Competição
- Formalidade
- Conflitos pessoais
- Solução de conflitos por meio de imposição
Estabilidade
- Novas tecnologias
- Novos produtos
- Segurança (técnicas consagradas)
- Previsibilidade
Tabela 4: Cultura Organizacional: aspectos favoráveis e desfavoráveis à XP
123
ESTRUTURA ORGANIZACIONAL
Dimensões
ASPECTOS
FAVORÁVEIS À XP
ASPECTOS DESFAVORÁVEIS À XP
Especialização do Trabalho
- Generalistas
- Experiência
- Responsabilidade
- Habilidades pessoais
- Especialistas
- Novatos
- Baixa qualificação
- Falta de habilidades pessoais
Departamentalização - Ambiente único - Departamentos/salas/baias
Cadeia de Comando
- Poucos níveis hierárquicos
- Relações informais
- Equipe com estrutura democrática
- Comunicação rápida e aberta
- Vários níveis hierárquicos
- Relações formais
- Equipe com estrutura hierárquica
- Comunicação lenta e reservada
Margem de Controle - Equipes pequenas - Equipes grandes
Centralização e Descentralização
- Delegação
- Liderança democrática
- Concentração de poder
- Liderança autocrática
Formalização
- Menor ênfase em regras e normas
- Baixo nível de documentação
- Alto nível de comunicação oral
- Forte ênfase em regras e normas
- Alto nível de documentação
- Alto nível de comunicação escrita em detrimento da comunicação oral
Tabela 5: Estrutura Organizacional: aspectos favoráveis e desfavoráveis à XP
124
5. APLICAÇÃO DA LISTA DE VERIFICAÇÃO
Este capítulo apresenta uma aplicação da lista de verificação elaborada no
decorrer do capítulo 4 a fim de confirmar a sua capacidade de captar as informações
necessárias ao seu propósito. Desta forma, a partir da lista de verificação, formulou-se
um questionário que foi aplicado em uma empresa de desenvolvimento de software da
grande Florianópolis identificada nesta dissertação como “Empresa X”.
O questionário foi submetido aos 10 desenvolvedores da “Empresa X”, bem
como ao gerente de software, sendo que as respostas obtidas - que são comentadas
durante este capítulo - encontram-se no anexo da presente dissertação.
Além do questionário, utilizou-se entrevistas - cujo roteiro também se baseou na
lista de verificação -, o que possibilitou a complementação da verificação dos aspectos
culturais e estruturais da empresa. Neste caso, a amostragem desenvolveu-se a partir do
conceito de saturação das respostas que são conhecidas pelos entrevistados. Assim, a
partir do momento que as respostas dos participantes demonstraram haver repetição ou
semelhanças mais constantes em seu sentido, concluiu-se o processo de coleta de dados
em relação a cada questão.
Em sua totalidade foram entrevistados 7 membros na “Empresa X”: 1 gerente de
software e 6 desenvolvedores. As entrevistas seguiram um roteiro de perguntas semi-
abertas realizadas individualmente com os membros da empresa, de forma que as
questões básicas forneceram um amplo campo de questionamentos (TRIVINÕS, 1994).
A investigação foi desenvolvida sob um enfoque qualitativo, utilizando-se de pesquisa
de campo, em face da coleta dos dados primários executada na organização selecionada
neste estudo.
A observação direta do espaço organizacional também fez parte da coleta de
dados, tendo por finalidade constatar alguns aspectos culturais e estruturais, bem como
confirmar os dados obtidos através do questionário e das entrevistas.
125
Quanto à confiabilidade das respostas, os entrevistados não precisaram se
identificar, garantindo-se o anonimato, bem como foi dada garantia de que o nome da
empresa não seria divulgado neste trabalho.
5.1 Apresentação dos Dados Coletados
A “Empresa X” atua no mercado há aproximadamente 3 anos, dedicando-se ao
desenvolvimento de software para web. Em sua composição incluem-se um
proprietário, um gerente de projeto de software e 10 desenvolvedores. Entre os
desenvolvedores, os dois programadores mais experientes são os líderes da equipe, os
quais prestam suporte ao restante do grupo.
Pelo fato de existirem apenas dois níveis hierárquicos na estrutura
organizacional da empresa ficam evidenciados aspectos como comunicação direta e
informal. Na equipe de desenvolvimento, mesmo havendo dois líderes, a relação entre
os desenvolvedores não parece envolver subordinação ou formalidade, estabelecendo-se
uma estrutura democrática.
O gerente considera que dos 10 desenvolvedores da empresa 8 são “juniores”, já
que ainda não possuem conhecimentos sólidos na área. Cada projeto da “Empresa X”
costuma envolver em média 3 a 4 desenvolvedores.
As políticas da empresa em relação aos funcionários envolvem flexibilização do
horário de trabalho para possibilitar-lhes a participação em cursos de aperfeiçoamento,
bonificação por tempo de serviço (a cada ano de trabalho), assistência médica e
participação nos lucros. Ressalta-se que durante as entrevistas, vários desenvolvedores
destacaram a participação nos lucros da empresa, assim pode-se perceber que este é um
aspecto bastante valorizado pelos mesmos.
Quanto ao salário, a maioria dos desenvolvedores entrevistados considera-se
satisfeita, neste sentido, o índice de satisfação verificado no questionário variou de
médio a alto. A empresa possui um sistema de avaliação de desempenho em forma
126
individual, sendo que em reuniões de trabalho faz-se a análise do desempenho semanal
de cada desenvolvedor.
No caso de erros cometidos nas atividades, tanto os desenvolvedores quanto a
gerência afirmaram que se costuma identificar o culpado e criticá-lo abertamente. Este
aspecto foi inclusive ressaltado por vários desenvolvedores durante as entrevistas, os
quais consideram que a empresa é bastante rígida em relação aos erros. Pelo que se
investigou, já ocorreram vários casos de críticas aos desenvolvedores na presença de
toda a equipe, mas não houve punição com dispensa do trabalho.
O horário de trabalho na empresa é bastante flexível, pois os desenvolvedores
não precisam seguir rigidamente os horários de entrada e de saída. Conforme se
observou, a jornada de trabalho é condicionada a metas a serem cumpridas, sendo que
pelas informações coletadas nas entrevistas, os desenvolvedores costumam trabalhar em
torno de 7 e meia a 8 horas por dia. Porém, freqüentemente se trabalha além desta
jornada por causa dos atrasos nos projetos, de forma que se ultrapassa o horário normal
de trabalho aproximadamente 3 vezes por semana.
Quanto ao comprometimento dos desenvolvedores com o trabalho, o gerente de
software considera que o nível é baixo, pois acha que os mesmos preferem apenas
realizar suas atividades sem levantar questionamento sobre formas mais eficientes de
desempenhá-las. Em entrevista o gerente afirmou que os desenvolvedores poderiam se
empenhar mais para conseguir cumprir os prazos dos projetos e suas metas semanais.
Não se verificou a existência de departamentos ou formas de divisão física no
local de trabalho da empresa, sendo que o proprietário, o gerente e os desenvolvedores
trabalham em um ambiente único, em que se percebe constante comunicação e
movimentação dos mesmos entre as estações de trabalho.
No entanto, permanecendo mais tempo na empresa foi possível perceber que o
fato do gerente e o proprietário estarem situados no mesmo ambiente de trabalho dos
desenvolvedores acaba gerando uma certa formalidade. Mesmo havendo trânsito pela
sala e bastante comunicação, há impressão de que os desenvolvedores estão sendo
127
observados o tempo todo, o que parece causar até mesmo uma espécie de regulação no
seu comportamento.
Considerando a adoção da XP neste ambiente de trabalho, os desenvolvedores
poderiam se sentir constrangidos para discutir abertamente sobre aspectos do projeto ou
funcionalidade do software, pois terão que enfrentar a sensação de estarem sendo
monitorados.
Existem poucos clientes locais da empresa, os quais são atendidos diretamente
pelo gerente de software e pelo analista de sistemas. Este desenvolvedor é o único
membro da equipe que possui contato direto com o cliente, o que ele considera muito
importante porque acha que o cliente pode prestar informações claras sobre os requisitos
do software e esclarecer dúvidas.
Como a maioria dos clientes da empresa é de outras cidades (principalmente de
outros estados) e o gerente não possui disponibilidade para viajar tão freqüentemente,
optou-se por terceirizar o serviço de especificação de requisitos de software para
profissionais que estejam localizados na mesma cidade do cliente.
Estes profissionais terceirizados mantêm contato com o cliente e definem os
requisitos, os quais posteriormente são repassados para o gerente da “Empresa X”.
Assim que o gerente de software recebe o modelo de requisitos, divide-o em partes
diferentes, as quais são destinadas para cada um dos desenvolvedores. Desta forma, os
desenvolvedores apenas recebem suas tarefas sem discutir o esboço geral do projeto
com o gerente ou com os colegas.
Segundo os entrevistados, as tarefas são designadas de acordo com o grau de
complexidade das mesmas e a capacidade técnica de cada um. Desta forma, cada
desenvolvedor possui sua tarefa individual definida pela gerência, sendo que esta
constatação confirmou as respostas do questionário aplicado, pois 9 entre 10
desenvolvedores, assim como a gerência, responderam que as tarefas são mais
orientadas para indivíduos do que para equipe.
Neste sentido, percebe-se que os desenvolvedores não possuem um objetivo
comum em suas tarefas, não tendo muito conhecimento do trabalho dos outros, mas
128
ficam restritos às suas tarefas designadas pela gerência. Mesmo estando num ambiente
único, tendo um relacionamento informal e havendo ajuda em caso de dificuldades com
as tarefas, não se pode identificar “espírito de equipe” entre os desenvolvedores.
Mediante as informações a respeito da forma de trabalho praticada na empresa
também se confirmou as respostas dadas no questionário referentes à forma como a
gerência repassa as orientações. No caso, as orientações são feitas de maneira ampla
deixando margem de escolha da maneira como executar as tarefas.
Alguns desenvolvedores relataram problemas ocorridos pelo fato do cliente estar
distante e a definição dos requisitos ser terceirizada, pois acham que estão mais
suscetíveis à distorções entre as reais necessidades do cliente e o que é repassado à
empresa. Segundos os mesmos, tais distorções acarretam reclamações do cliente, que se
convertem em críticas da gerência sobre a qualidade do trabalho da equipe.
Embora admitam que nem sempre os softwares desenvolvidos atendem todos os
requisitos do cliente – o que pode ser resultado da má qualidade da comunicação com o
mesmo – os desenvolvedores se dizem preocupados em satisfazê-lo, sendo que em caso
de reclamação procura-se imediatamente resolver o problema.
No decorrer dos projetos de software da empresa é bastante comum a
modificação dos requisitos, o que ocorre basicamente por dois motivos. O primeiro é
que a distorção das informações repassadas pelos profissionais terceirizados causa
necessidade de esclarecimentos e correções freqüentes. O segundo motivo deriva de
pedidos de alterações feitos pelos clientes.
Perguntados a respeito da variação dos requisitos decorrente de pedidos do
cliente – o que acaba modificando o modelo conceitual e as tarefas já realizadas – os
entrevistados consideraram que esta variação é inevitável “porque geralmente o cliente
não sabe exatamente o quer” e fica difícil captar todas as suas necessidades.
Considera-se favorável este pressuposto manifestado pelos desenvolvedores,
pois funciona como um indicativo de que possuem potencial para a inovação e
flexibilidade em relação a mudanças na rotina de trabalho.
129
No que diz respeito à documentação utilizada na empresa, verificou-se que são
produzidos modelos de especificação funcional (use cases, diagramas de classe,
diagramas de seqüência) e outros que eventualmente sejam exigidos pelo cliente.
Porém, tanto os desenvolvedores quanto a gerência consideram que o nível de
documentação exigido na empresa é baixo, pois geralmente a mesma é gerada a pedido
do cliente. Com exceção destes casos, a documentação é realizada no próprio código.
No questionário, tanto os desenvolvedores como a gerência declararam que a
empresa está orientada para a satisfação do cliente. Em entrevista alguns
desenvolvedores afirmaram que preferem e utilizam sempre que possível um processo
de desenvolvimento de software iterativo e incremental, pois acham que entregando
módulos funcionais de aplicação para o cliente é possível que este forneça retorno
rápido sobre possíveis alterações.
A relação entre os desenvolvedores é considerada amigável e colaborativa,
sendo que em caso de dificuldade nas tarefas uns ajudam os outros - o que foi possível
observar durante as várias visitas feitas à empresa - não se verificando competição entre
os colegas. Porém, na entrevista alguns afirmaram que às vezes ocorrem conflitos
pessoais na equipe, que se salientam principalmente quando estão sob forte pressão por
causa de prazo de entrega do software.
No caso de conflitos relacionados a assuntos técnicos, alguns membros da
equipe acham que a solução geralmente é democrática, já outros acham que a tendência
é prevalecer a opinião dos líderes da equipe. Quanto aos conflitos pessoais mencionados
pelos desenvolvedores, seria necessário um convívio maior com a equipe para
identificar a sua intensidade.
A empresa promove poucos encontros para confraternização, sendo citado que
acontecem alguns jantares entre os membros da empresa, porém estes eventos não são
realizados com muita freqüência, não havendo, por exemplo, comemorações de
aniversário.
Observou-se que na empresa, toda semana é feita uma reunião de trabalho para
tratar de assuntos relacionados aos projetos de software em andamento. Em entrevista,
130
um desenvolvedor destacou os benefícios destas reuniões para o desempenho da equipe,
afirmando que depois que as reuniões semanais passaram a acontecer houve redução
nos atrasos de entrega de software. O entrevistado considerou que quando as reuniões
eram menos freqüentes acumulavam-se mais problemas.
Questionados sobre sua participação na resolução de problemas relacionados aos
projetos de software da empresa, a maioria dos desenvolvedores respondeu que as
decisões do projeto são tomadas em nível gerencial.
Embora sejam realizadas reuniões semanais nas quais é discutido o andamento
do trabalho, em entrevista os desenvolvedores afirmaram que até procuram fazer
sugestões e participar das decisões, mas a opinião do gerente acaba sempre
prevalecendo. Já a gerência, em sua resposta no questionário, afirmou que as sugestões
dos desenvolvedores são consideradas e implementadas.
Em relação à flexibilidade funcional, no questionário alguns desenvolvedores
responderam que às vezes desempenham atividades diferentes das suas, mas pelo que se
apurou nas visitas à empresa estas tarefas são basicamente aprimorar o layout do site em
construção, fazer cadastro de conteúdo e, às vezes, realizar teste de unidade.
Ao se perguntar aos membros da equipe de desenvolvimento se estariam aptos a
desempenhar diferentes papéis num projeto – como programador, projetista e testador -
5 consideraram ser difícil, 2 afirmaram que já assumem diferentes papéis e 3 acham que
é impossível.
Já o gerente considera que poucos desenvolvedores da empresa têm
possibilidade de assumir diferentes papéis por causa da pouca experiência da equipe.
Além disso, o mesmo respondeu no questionário que os desenvolvedores são relutantes
em assumir mais responsabilidades.
Um dos integrantes da equipe de desenvolvimento que afirmou desempenhar
apenas sua função específica foi o analista de testes de software. As atividades do
mesmo se alternam entre simular operações de usuário por meio de testes de interface e
monitorar os erros no portal já em execução no servidor do cliente. Além disso, também
realiza testes de carga para verificar a capacidade do sistema.
131
Sobre a possibilidade de intensificação dos testes, a resposta unânime dos
desenvolvedores foi no sentido de que não seria possível por causa das dificuldades em
cumprir os prazos de entrega de software.
Na “Empresa X” não se verificou a implantação de nenhum programa de
qualidade. Por outro lado, a empresa é considerada aberta a novas tecnologias, tendo
sido relatado pelos desenvolvedores que freqüentemente se busca adotar novas
ferramentas.
Neste sentido, foi lembrado por alguns entrevistados que atualmente se está
migrando da linguagem de programação coldfusion para uma linguagem mais conhecida
(Java). Durante as entrevistas também foi constatado que os desenvolvedores definiram
um padrão de programação para facilitar a compreensão e as integrações de código.
5.2 Aspectos Culturais e Estruturais da “Empresa X” Favoráveis à Adoção da XP
a) A empresa mostra-se orientada para o cliente, pois se percebe tanto no gerente
como nos desenvolvedores uma preocupação constante com a satisfação do mesmo.
b) Os desenvolvedores consideram importante o contato direto com o cliente.
c) A preocupação com a orientação para detalhes na “Empresa X” pode ser
identificada na disponibilidade de um desenvolvedor exclusivamente para realizar
testes, bem como na importância dada a tarefas como testes de unidade, testes de carga
e a criação de um estilo padrão de programação.
d) A equipe de desenvolvimento é relativamente pequena e todos os
desenvolvedores trabalham em um mesmo ambiente físico.
e) A empresa mostra-se preocupada com a satisfação dos funcionários, o que
pode ser presumido dos benefícios fornecidos aos mesmos e da satisfação com o salário
manifestada pelos desenvolvedores.
132
f) Poucos níveis hierárquicos e comunicação de forma rápida e informal.
g) Estrutura da equipe democrática (embora alguns desenvolvedores considerem
que em caso de conflito técnico prevalece a opinião dos líderes – o que pode ser
justificável tendo em vista sua maior experiência).
h) Relacionamento entre os desenvolvedores marcado por colaboração e
informalidade.
i) Ritos de Integração - embora sejam poucos, são importantes para o
entrosamento da equipe.
j) Baixo nível de documentação.
l) Empresa aberta a novas tecnologias.
m) Desenvolvedores com potencial para inovação.
n) Baixa formalização (orientações da gerência repassadas de forma ampla).
5.3 Aspectos Culturais e Estruturais da “Empresa X” Desfavoráveis à Adoção da
XP
a) O sistema de recompensa é individual, mas neste caso não gera competição
porque está baseado em tempo de serviço. Por outro lado, o sistema não estimula a
inovação ou desempenho do desenvolvedor.
b) Não se verificou “espírito de equipe” – os desenvolvedores não têm muito
conhecimento do trabalho dos colegas. A colaboração verificada entre os
desenvolvedores se estabelece mais no sentido de resolver dúvidas das suas tarefas.
c) Distribuição das tarefas de forma individual.
133
d) Embora tenha se percebido que tanto os membros da equipe quanto o gerente
consideram que seja importante a realização de testes, acreditam que não se poderia
intensificá-los por causa da dificuldade em cumprir os prazos do projeto.
e) Tratamento dos erros na empresa (identificar e criticar abertamente o
culpado).
f) Baixa receptividade das sugestões dos desenvolvedores.
g) As decisões sobre problemas no projeto são tomadas em nível gerencial, com
baixos níveis de participação dos desenvolvedores.
h) Horas extras de trabalho freqüentes.
i) Sistema de avaliação individual.
j) A comunicação com o cliente é deficiente.
l) Desenvolvedores com pouca experiência e qualificação.
m) A maioria dos desenvolvedores desempenha somente um papel. Além disso,
considerando sua capacidade, os mesmos acham difícil assumir outros papéis.
n) Liderança autocrática.
o) Baixo nível de delegação (é o gerente de software quem determina as tarefas
de cada desenvolvedor).
p) Existência de conflitos pessoais entre os desenvolvedores.
q) Baixo nível de comprometimento com o trabalho.
r) Desenvolvedores relutantes em assumir mais responsabilidades.
134
5.4 Considerações Finais
É interessante atentar para uma questão que foi respondida de maneira
totalmente conflitante no questionário aplicado, a qual diz respeito ao seguinte
questionamento: “Os desenvolvedores preferem cumprir ordens ou assumir
responsabilidades e correr riscos?” Todos os desenvolvedores responderam que
preferem assumir responsabilidades, enquanto a gerência respondeu que os
desenvolvedores preferem seguir ordens ao invés de assumir responsabilidades e correr
riscos.
Neste caso identificou-se que o perfil “assumir responsabilidades e correr riscos”
pode se tratar de um valor desejado pelos desenvolvedores, o qual pode estar sendo
inibido ou mesmo barrado pela forma como a gerência trata os erros cometidos pelos
membros da equipe. Ressalta-se que vários entrevistados manifestaram desconforto em
ser criticados de forma dura e aberta durante as reuniões realizadas entre a equipe e a
gerência.
Isto é, o fato de haver severidade na forma de tratar os erros pode estar inibindo
as iniciativas dos desenvolvedores, a sua disposição para assumir mais
responsabilidades, bem com a possibilidade de exercitarem suas habilidades e
capacidades mais intensamente. Por isso os mesmos podem estar se limitando a cumprir
as ordens dos superiores.
Outro aspecto que pode estar influenciando nesta situação é o fato da gerência
ser bastante controladora e haver pouca delegação, não oferecendo oportunidade para os
desenvolvedores exercer autonomia na determinação das tarefas. Por outro lado,
também há que se considerar que estes aspectos culturais detectados na gerência podem
estar relacionados com a falta de conhecimentos técnicos dos desenvolvedores, já que se
trata de uma equipe com baixo nível de experiência.
Também se pode perceber que alguns aspectos desfavoráveis identificados na
“Empresa X” podem estar relacionados com a dificuldade em cumprir os prazos de
entrega de software. Nesta situação os desenvolvedores trabalham sob pressão e
135
extrapolam a jornada de trabalho normal, assim sendo, é comum surgirem fatores como
cansaço e frustração, os quais podem abalar as relações entre os envolvidos no projeto,
inclusive, originando conflitos pessoais.
Ainda sobre a dificuldade em cumprir os prazos de entrega do software, nota-se
que esta situação repercute também no nível de testes realizados. A empresa procura
encontrar formas de aumentar o rendimento no trabalho para amenizar ou evitar os
atrasos, e, às vezes, a alternativa adotada é diminuir a atenção à qualidade do software
em termos de revisões e testes.
Na “Empresa X” também chamam atenção os aspectos decorrentes da
dificuldade de contato direto com o cliente, como comunicação deficiente, distorções
das informações, não atendimento de todos os requisitos do cliente e conseqüente
necessidade de retrabalho.
Quanto à constatação de que não há “espírito de equipe” entre os
desenvolvedores, várias políticas da empresa podem ter relação direta com este fato,
como a orientação das tarefas de forma individual, sistema de avaliação por indivíduo e
sistema de recompensa de forma individual (tempo de serviço). Nesta situação, a
própria empresa está desestimulando o trabalho em equipe.
136
6. CONCLUSÃO
Neste trabalho foram apresentadas algumas reflexões a respeito de como a
cultura e a estrutura organizacional podem influenciar na adoção do método Extreme
Programming pelas empresas de desenvolvimento de software.
A lista de verificação da adequação dos fatores organizacionais elaborada nesta
dissertação, bem como a aplicação do questionário e das entrevistas na empresa de
software selecionada, configuram-se em alguns dos mecanismos que compõem o estudo
realizado. Entretanto, considera-se que a maior contribuição desta dissertação é a
identificação dos aspectos organizacionais favoráveis ou desfavoráveis à adoção da XP,
o que se alcançou mediante a análise das dimensões da cultura e da estrutura
organizacional sob a perspectiva das práticas e valores XP.
A XP tem sido apresentada por muitos autores como sendo uma alternativa
viável e vantajosa para empresas de software que possuem equipes pequenas e
trabalham com requisitos vagos, pois se aplicado em sua íntegra o referido método pode
proporcionar bons resultados como agilidade nos projetos e qualidade do código.
Porém, a literatura que trata da XP geralmente parece presumir a existência de
um ambiente em que desenvolvedores motivados e colaborativos trabalhem em equipe,
desenvolvendo código de qualidade, o qual é amplamente testado e revisado. Também
se pressupõe que os desenvolvedores tenham autonomia para decidir junto com o cliente
o que deve ser implementado e seus respectivos prazos de entrega.
Neste sentido, esta dissertação procurou destacar que existem vários aspectos
organizacionais necessários para praticar XP de forma satisfatória e que os mesmos nem
sempre estão presentes nas empresas de software e, além disso, há possibilidade de
constar-se a presença de aspectos que dificultam a implantação do referido método.
A cultura e a estrutura organizacional permitem a análise da realidade da empresa
e, conforme aqui proposto, a identificação das suas potencialidades e limitações em
relação à adoção da XP. A divisão dos fatores organizacionais em dimensões dá
137
condições ao pesquisador de fazer uma análise ampla e, se necessário, aprofundá-la com
base nos aspectos específicos de cada dimensão.
Embora alguns autores afirmem que as práticas XP possam melhorar a
colaboração e a comunicação entre os envolvidos em um projeto de software, sua
efetivação depende de aspectos que configuram o perfil de cada empresa e que são
difíceis de gerenciar, como relacionamento entre as pessoas, sistema de poder,
concepções sobre como o trabalho deve ser realizado e sentimentos como motivação e
comprometimento.
Ao subestimar a influência do fator cultural as organizações cometem equívocos
estratégicos, ficando sujeitas ao fracasso decorrente da incompatibilidade cultural. Com
os resultados deste estudo, pode-se notar que para que a adoção do método XP tenha
sucesso é preciso considerar não só aspectos técnicos, mas também a adequação dos
aspectos culturais e estruturais da organização, os quais fornecem o suporte necessário
para a realização das práticas e valores XP.
Torna-se importante a ponderação a respeito da possibilidade de adoção da XP
sem causar grandes turbulências na empresa de software, já que mudar valores culturais
que norteiam a organização pode provocar profundas transformações na sua identidade,
colocando em risco seu desempenho.
Referindo-se à mudança na cultura da organização, Luppi (1995) afirma que é
preciso considerar que as pessoas só mudam se a mudança for realmente desejada, pois
querer mudar o outro é uma posição muito autoritária. A pessoa precisa estar
convencida de que a mudança traz benefícios para ela própria.
Ainda segundo Luppi (1995), em casos em que se verifique incompatibilidade
cultural poderá ser necessário até mesmo substituir os dirigentes ou funcionários por
outros que tenham valores pessoais mais alinhados com o que se quer disseminar, pois
transformar os valores de um indivíduo pode requerer um trabalho de reeducação que
pode levar anos.
De qualquer forma, identificar os aspectos organizacionais favoráveis e
desfavoráveis à XP é o primeiro passo para se refletir sobre a viabilidade da
138
implantação do referido método. A partir desta reflexão, torna-se possível avaliar a
profundidade das transformações que serão necessárias para adotar a XP, bem como a
possibilidade de remoção das barreiras culturais eventualmente verificadas.
Desta forma, a pesquisa realizada procura demonstrar que embora a XP tenha
sido idealizada para equipes pequenas trabalhando em projetos com requisitos vagos
nem sempre a empresa que adotá-la terá sucesso, pois fatores organizacionais podem até
mesmo inviabilizar sua utilização.
Os resultados deste trabalho também podem explicar um dos motivos pelos
quais várias empresas de desenvolvimento de software não conseguem adotar a XP na
íntegra, utilizando apenas algumas de suas práticas. Isto ocorre porque algumas práticas
encontram um ambiente favorável na empresa – decorrente dos aspectos culturais e
estruturais necessários para sua efetivação – enquanto outras se deparam com aspectos
hostis à sua implementação.
139
REFERÊNCIAS
ABRAHAMSSON, Pekka; SALO, Outi; RONKAINEN, Jussi; WARSTA, Juhani.
Agile software development methods: review and analysis. Espoo, Finland: Technical
Research Centre of Finland, VTT Publications, 2002. Disponível em: < www.inf.vtt.fi/
pdf/publication/2002/p478.Pdf>. Acesso em: 04 jan. 2005.
ABRAHAMSSON, Pekka; SALO, Outi; RONKAINEN, Jussi; WARSTA, Juhani. New
directions on agile methods: A comparative analisys. IEEE Proceedings of the 25th
International Conference on Software Engineering, 2003. p.114-120.
Agile Alliance. 2001. Disponível em: <www.agilealliance.org> Acesso em: 22 fev.
2005.
ASPRONI, Giovanni. Motivation, Teamwork, and Agile Development. The Agile
Times. Fev. 2004, vol.4, n 1. Disponível em: <www.agilealliance.org/membership/vol
4.pdf>. Acesso em: 20 dez. 2004.
ALVES, Sérgio. Revigorando a Cultura da Empresa: uma abordagem cultural da
mudança nas organizações na era da globalização. São Paulo: Makron Books, 1997.
ALVIM, Paulo. Gestão Ágil de Projetos: Scrum na Prática. Extreme Programming
Brasil. Primeiro Congresso Brasileiro de Metodologias Ágeis de Software. São Paulo:
04-06, Dezembro, 2002.
AMBLER, Scott W. Modelagem Ágil: Práticas Eficazes para a Programação
eXtrema e o Processo Unificado. Trad. Acauan Fernandes. Bookman: Porto Alegre,
2004.
ANDERSON, David J.; SCHRAGENHEIM, Eli. Agile Management for Software
Engineering: Applying the Theory of Constraints for Business Results. Prentice
Hall PTR, 2003.
ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming:
Guia Prático. Trad. Kátia Roque. Rio de Janeiro: Campus, 2002.
140
BARICHELLO, Eugenia Mariano da Rocha; POZZOBON, Camille de Medeiros;
RIBEIRO, Michelle Braga. Comunicação Informal e Cultura Organizacional. 2005. In:
Revista Comunicação Organizacional. Disponível em: < http://www.pucrs.br/
famecos/ eacor/texto4-03.html>. Acesso em: 23 abr. 2005.
BASS, Bernard M. Bass & Stogdill´s handbook of leadership: theory, research &
management applications. New York: Free Press, 1990.
BAKER, Kathryn A. Organizational Culture. 2000. Disponível em:
<www.science.doe.gov/sc5/benchmark/Ch%2011%20Organizational%20Culture%2006
.08. 02.pdf>. Acesso em: 10 jan. 2005.
BECK, Kent. Programação Extrema - XP Explicada: acolha as mudanças. Trad.
Adriana Machado e Natália Lopes. Porto Alegre: Bookman, 2004.
BOSSAVIT, Laurent. The Unbearable Lightness of Programming: A Tale of Two
Cultures. In: Cutter IT Journal, vol. 15, n. 12, December 2002. Disponível em:
<http://www.cutter.com/itjournal/2002toc.html>. Acesso em: 16 abril 2005.
BURKE, Eric M.; COYNER, Brian M. Java Extreme Programming Cookbook.
O'Reilly, 2003.
CHIAVENATO, Idalberto. Administração nos novos tempos: os novos horizontes da
administração. Rio de Janeiro: Campus, 1999.
CHIAVENATO, Idalberto. Gerenciando Pessoas. São Paulo: Prentice Hall, 2002.
COCKBURN, Alistair. Agile Software Development. Boston: Addison-Wesley, 2001.
COCKBURN, Alistair. People and Methodologies in Software Development. PhD
thesis, University of Oslo, 2003. Disponível em: <alistair.cockburn.us/crystal/books/
pamisd/peopleandmethodologiesinsoftwareDevelopMent.pdf >. Acesso em: 12 dez.
2004.
COSTA, Geraldo Vieira da. Cultura e Valores Organizacionais. Florianópolis:
Insular, 1999.
141
CUNNINGHAM, Ward. General Chair Address. 2003. Disponível em:
<http://www.agileuniverse.com/schedule/GeneralChairAddress>. Acesso em: 05 nov.
2004.
DEAL, Terrence; KENNEDY, Alan. Corporate culture: the rites and rituals of
corporate life. Masschusets: Addison Wasley, 1982.
DENNISON, D.R. Corporate culture and organizational effectiveness. New York:
Wiley, 1990.
FISHER, Rosa Maria. O círculo do Poder: As práticas invisíveis de sujeição nas
Organizações Complexas. In: FLEURY, Leme Tereza Maria (org). Cultura e Poder
nas Organizações. 2. ed. São Paulo: Atlas, 1996.
FLEURY, Leme Tereza Maria. Desvendar a Cultura de uma Organização: Uma
discussão metodológica. In: FLEURY, Tereza Maria Leme (org). Cultura e Poder nas
Organizações. 2. ed. São Paulo: Atlas, 1996.
FOWLER, Martin. New Methodology. 2003. Disponível em: < http://www.Martin
fowler.com/articles/newMethodology.html>. Acesso em: 22 jun. 2005
FOWLER, Martin. Refactoring: Improving the Desing of Existing Code. Addison-
Wesley Longman, 1999.
FOWLER, Martin; SCOTT, Kendall. UML Essencial: Um breve guia para a
linguagem-padrão de modelagem de objetos. Porto Alegre: Bookman, 2000.
FREITAS, Maria E. de. Cultura Organizacional: formação, tipologias e impacto.
São Paulo: MacGraw-Hill, 1991.
FREITAS, Maria E. de. Cultura Organizacional: Grandes Temas em Debate. In:
Revista Administração de Empresas. São Paulo, vol. 31, n. 3, p.73-82 , jul-set, 1991.
GIL, Antônio C. Como elaborar projetos de pesquisa. São Paulo: Atlas, 1996.
HALL, Richard H. Structure and Process. Englewood Cliffs: Prentice Hall, 1998.
142
HAMPTON, David R. Administração: Comportamento Organizacional. Trad.
André Olympio Castro. São Paulo: McGraw-Hill, 1990.
HIGHSMITH, Jim. Agile Software Development Ecosystems. Publisher: Addison
Wesley, 2002.
HUBER, G.P.; GLICK, W.H. Organizational Change and redesing. New York:
Oxford University Press, 1995.
JEFFRIES, Ron. Extreme Programming and the Capability Maturity Model. 2000.
Disponível em: <http://www.xprogramming.com/xpmag/xp_and_cmm.htm>. Acesso
em: 23 jun. 2005.
JEFFRIES, Ron. What is Extreme Programming? In: XP magazine. 2001. Disponível
em: <www.xprogramming.com/xpmag/index.htm>. Acesso em 03 jan. 2005.
JOHNSON, Allan G.. Dicionário de sociologia: guia prático da linguagem
sociológica. Trad. Ruy Jungmann. Rio de Janeiro: Zahar, 1997.
JOHNSON, K.W. The role of culture in achieving organizational integrity and
managing conflicts between cultures. 1999. Disponível em:
<www.ethicaledge.com/quest_5.html.> Acesso em: 25 mar. 2005.
KATZ, D.; KAHN, R. The social psychology of organizations. New York: John
Wiley, 1978.
KIRBY, Dave. Multiple Choices. 2003. Disponível em: < http://www.thedevelopers
coach.com /TAL01.htm> Acesso em: 12 fev. 2005.
LARAIA, Roque de B. Cultura: um conceito antropológico. 11. ed. Rio de Janeiro:
Jorge Zahar, 1996.
LARMAN, Craig. Agile and Iterative Development: A Manager's Guide. Addison
Wesley, 2003.
143
LARSEN, Diana; KERIEVSKY, Joshua. XP/Agile Organizational Change - Tools
for Successful Adoption. 2003. Disponível em: <http://www.agileuniverse.com/
schedule /T13>. Acesso em: 12 dez. 2004.
LEBLANC, Dee-Ann. When eXtreme Programming Makes Sense. 2004. Disponível
em:<http://www.devsource.ziffdavis.com/article2/0,1759,1609523,00.asp>. Acesso em:
05 jan. 2005.
LUPPI, Galvani. Cultura Organizacional: Passos para a mudança. Belo Horizonte:
Luzazul Editorial, 1995.
MARTIN, Joanne; SIEHL, Caren. Organizational culture and counterculture: an uneasy
symbiosis. In: Organizational dynamics. vol. 12, n. 2, 1983.
MAYO, Andrew. The Human Value of the Enterprise. Nicholas Brealey Publishing:
London, 2001.
MCT - Ministério da Ciência e Tecnologia. Disponível em: <http:\\www.mct.gov.br>.
Acesso em: 10 dez. 2004.
MCBREEN, Pete. Questioning Extreme Programming. Indianapolis: Addison
Wesley, 2002.
MEGGINSON, Leon C; MOSLEY, Donald C.; PIETRI JR, Paul H. Administração:
conceitos e aplicações. Trad. Aria Isabel Hopp. 4. ed. São Paulo: Harbra, 1998.
MILLER, Randy. The Dynamics of Agile Software Processes. 2003. Disponível em:
<http://thecoadletter.com/article/0,1410,29726,00.html>. Acesso em: 15 jan. 2005.
MOTTA, P. R. Transformação Organizacional: a teoria e a prática de inovar. Rio
de Janeiro: Qualitymark, 1999.
MOORE, Geoffrey A. Inside the Tornado: Marketing Strategies from Silicon
Valley's Cutting Edge. New York: HarperBusiness, 1995.
144
NOORDERHAVEN Niels G.; KOEN Carla; BEUGELSDIJK, Sjoerd. Organizational
Culture and Networkembeddedness. 2002. Disponível em: < http://greywww.uvt.nl:
2080/greyfiles/center/2002/doc/91.pdf.>. Acesso em: 17 abril 2005.
PALMER, S. R.; FELSING, J. M. A Pratical Guide to Feature-Driven Development.
Upper Saddle River. NJ: Prentice-Hall, 2002.
PAULK, Mark. Extreme Programming from a CMM Perspective. 2001. Disponível
em: <hristov.com/andrey/fht-stuttgart/xp-cmm-paper.pdf>. Acesso em: 21 jun. 2005.
PETTIGREW, Andrew. Theoretical, methodological, and empirical issues in studying
change: a response to Starkey. In: Journal of Management Studies, v. 24, n. 4, 1987.
PETTIGREW, Andrew. A cultura das organizações é administrável? In: Cultura e
Poder nas organizações. FLEURY, Maria Tereza Leme (org). São Paulo: Atlas, 1996.
RISING, Linda. The benefits of frequent, small meetings, STQE, May/June 2002, 42-
46. disponível em: http://members.cox.net/risingl1/articles/STQE.pdf, acesso em 10
set. 2005.
ROBBINS, Stephen P. Administração: Mudanças e Perspectivas. Trad. Cid Knipel
Moreira. São Paulo: Saraiva, 2002.
ROBBINS, Stephen P. Comportamento Organizacional. 8. ed. Trad. Cristina Ávila de
Menezes. Rio de Janeiro: LTC, 1999.
RUMPE, Bernhard; SCHRÖDER, Astrid. Quantitative Survey on Extreme
Programming Projects. In Third International Conference on Extreme Program-
ming and Flexible Processes in Software Engineering, XP2002, May 26-30 pages
95–100, Alghero, Italy, 2002. Disponível em: < http://www4.in.tum.de/~rumpe/ps/
XP02.RumpeSchroeder.Study.pdf >. Acesso em: 12 dez. 2004.
SCHWABER, K. Scrum Development Process. OOPSLA’95 workshop on Bussiness
Object Planejament and Implementation. Springer-Verlag. 1995.
145
SCHEIN, Edgar H. Organizational culture and leadership. San Francisco: Jossey-
Bass, 1985.
SCHEIN, Edgar H. The Corporate Culture Survival Guide. San Francisco: Jossey-
Bass, 1999.
SCHOLL, Richard W. Organizational Culture- The Social Inducement System.
2003. Disponível em: < http://www.cba.uri.edu/Scholl/Notes/Culture.html>. Acesso
em: 24 fev. 2005.
SHARIFABDI, Kamran. Team Development and Pair Programming - tasks and
challenges of the XP coach. In: Proceedings of 3rd International Conferenceon
Extreme Programming and Flexible Processes in Software Engineering (XP2002),
Sardinia, Italy, May 26-30, 2002, 166-169. Disponível em:
<http://www.agilealliance.org/articles/articles/Sharifabdi-Grot--TeamDevelopmentand
PairProgramming.pdf>. Acesso em: 09 mar. 2005.
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. Trad. André Maurício de
Andrade Ribeiro. São Paulo: Addison Wesley, 2003.
STAPLETON, J. Dynamic Systems Development Method – The Method in Practice.
Addison Wesley, 1997.
STEVEN, Ott, J. The Organizational Culture Perspective. Califórnia: Pacific Grove,
1989.
STONER, James A. F.; FREEMAN, R. Edward. Administração. 5. ed. Rio de Janeiro:
LTC, 1999.
TAMAYO, Álvaro. Valores Organizacionais. In: TAMAYO, Álvaro; ANDRADE, Jairo
Eduardo Borges; CODO, Wanderley. (Org.). Trabalho, Organizações e Cultura. São
Paulo: Cooperativa de Autores Associados, 1997.
TAVARES, Maria das Graças de Pinho. Cultura Organizacional: Uma abordagem
Antropológica da Mudança. Rio de Janeiro: Qualitymark, 2002.
146
TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar seus
usuários desenvolvendo software com agilidade e alta qualidade. São Paulo:
Novatec, 2004.
TOMAYKO, James E.; HAZZAN, Orit. Human Aspects of Software Development.
Charles River Media, 2004.
TRACY, Diane. 10 passos para o empowerment: um guia sensato para gestão de
pessoas. 4. ed. Rio de Janeiro: Campus, 1994.
TRICE, H.; BEYER, J. Studying technical, political and ceremonials. In: Academy of
Management Review. vol. 9, n. 4, 1984, pp. 653-669.
TRIVINÕS, A. S. Introdução à pesquisa em ciências sociais. São Paulo: Atlas, 1994.
VASCONCELLOS, Eduardo; HEMSLEY, James. Estrutura das Organizações:
estruturas tradicionais, estrutura para inovação, estrutura matricial. São Paulo:
Pioneira, 1997.
WAKE, C. William. Extreme Programming Explored. Massachusetts: Addison
Wesley, 2002.
WEGE, Chris. Extreme Programming Introduction and Experiences. 2001.
Disponível em: <http://www-ti.informatik.uni-tuebingen.de/~wege/presentations/
XpIntro.pdf>. Acesso em: 22 abril 2005.
WELLS, Don. Extreme Programming: A gentle introduction. 2002. Disponível em:
<www.extremeprogramming.org>. Acesso em: 17 mar. 2005.
WILLIAMS, Laurie. The Collaborate Software Process. PhD Dissertation –
University of Utah, 2000-a.
WILLIAMS, Laurie; KESSLER, Robert. Pair Programming Illuminated. Addison
Wesley, 2002.
147
WILLIAMS, Laurie; KESSLER, Robert R.; CUNNINGHAM, Ward; JEFFRIES, Ron.
Strengthening the Case for Pair-Programming. IEEE Software, vol. 17, p. 19-25
2000. Disponível em: <http://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftware.PD
F>. Acesso em: 21 fev. 2005.
WUESTEFELD, Klaus. Xispê – Extreme Programming. 2001. Disponível em:
<www.xispe.com.br/index.html>. Acesso em: 15 fev. 2005.
148
ANEXOS
149
Questionário utilizado no trabalho de dissertação no curso de Pós Graduação em Ciência da Computação da Universidade Federal de Santa Catarina – UFSC Mestrando: Cristiano Tolfo Orientador: Prof. Raul S. Wazlawick E-mail: [email protected] QUESTIONÁRIO PARA OS DESENVOLVEDORE DE SOFTWARE Q-1. Os desenvolvedores procuram fazer sugestões para melhorias no processo de desenvolvimento de software?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-2. As opiniões e sugestões dos desenvolvedores têm sido consideradas e implementadas?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-3. Os desenvolvedores preferem:
a) ( ) Cumprir ordens ao invés de assumir responsabilidades e correr riscos b) ( ) Assumir responsabilidades e correr riscos
Q-4. Como são tratados os erros cometidos pelos desenvolvedores que possam atrasar ou comprometer os projetos de software?
a) ( ) São tratados como parte do processo de aprendizagem b) ( ) Busca-se identificar o culpado, o qual é criticado abertamente c) ( ) Busca-se identificar o culpado, o qual é criticado de forma reservada d) ( ) Busca-se identificar o culpado, o qual é criticado e punido e) ( ) Não se prioriza a identificação do culpado, mas se critica abertamente o erro
Q-5 Qual a porcentagem de tempo, em média, que os desenvolvedores costumam dedicar ao testes em um ciclo de vida do sistema?
a) ( ) até 10% do tempo total b) ( ) até 30% do tempo total c) ( ) mais que 30% do tempo total
Q-6. Quais as dificuldades encontradas para se intensificar os testes?
a) ( ) Não existem dificuldades b) ( ) Falta de tempo c) ( ) Disponibilizar uma pessoa exclusiva para realizar testes d) ( ) Resistência por parte dos desenvolvedores e) ( ) Outras_________________________________
150
Q-7. A empresa está mais orientada à:
a) ( ) Satisfação do cliente b) ( ) Satisfação dos funcionários c) ( ) Redução de custos
Q-8. Qual o nível de satisfação dos desenvolvedores com o salário?
a) ( ) Alto b) ( ) Médio c) ( ) Baixo
Q-9. As atividades relacionadas ao desenvolvimento de software são mais orientadas:
a) ( ) Para tarefas individuais b) ( ) Para tarefas em equipe
Q-10. Durante o processo de desenvolvimento do software predominam:
a) ( ) Objetivos individuais dos desenvolvedores b) ( ) Objetivos comuns da equipe
Q-11. Os desenvolvedores acreditam que: a) ( ) O cliente geralmente não compreende a complexidade do desenvolvimento de software, é intolerante quanto aos prazos e a qualidade do produto, portanto é melhor minimizar o contato entre o mesmo e os desenvolvedores b) ( ) O cliente pode fornecer informações e sugestões importantes para o desenvolvimento do produto, portanto contatos constantes entre o mesmo e os desenvolvedores são positivos
Q-12. No relacionamento entre os desenvolvedores verifica-se:
a) ( ) Subordinação e formalidade b) ( ) Informalidade
Q-13. No relacionamento entre os desenvolvedores e a gerência verifica-se:
a) ( ) Subordinação e formalidade b) ( ) Informalidade
Q-14. Os desenvolvedores costumam recorrer aos colegas quando surgem dúvidas ou dificuldades?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
151
Q-15. Os desenvolvedores costumam compartilhar conhecimentos e informações? a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-16. Qual o grau competição entre os desenvolvedores? a) ( ) Alto b) ( ) Médio c) ( ) Baixo d) ( ) Não há competição entre os desenvolvedores
Q-17. Como são resolvidos os conflitos que ocorrem entre os desenvolvedores?
a) ( ) Prevalece a opinião do líder da equipe b) ( ) Ocorre medição de forças c) ( ) Encontra-se uma solução de forma democrática
Q-18. A empresa costuma experimentar novos modos de trabalho e novas tecnologias?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-19. Os desenvolvedores de software costumam assumir mais de uma função, por exemplo, acumular papéis como programador, projetista, testador?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-20. Considerando o conhecimento e as habilidades dos desenvolvedores, os mesmos teriam condições de acumular mais de uma função num projeto?
a) ( ) Já assumem mais de uma função b) ( ) É possível c) ( ) É difícil d) ( ) É impossível
152
Q-21. A equipe possui participação ativa na resolução de problemas relacionados ao projeto?
a) ( ) Sempre, deste o início do projeto são realizadas reuniões de trabalho com sugestões de melhorias e tomada de decisões relativas ao processo. b) ( ) Quase sempre, grande parte das resoluções de problemas de projeto é resolvida por meio de reuniões com a equipe. c) ( ) Quase nunca, a maioria das resoluções de problemas de projeto é tratada em nível gerencial. d) ( ) Nunca, todas as resoluções de problemas de projeto são tratadas em nível gerencial.
Q-22. As orientações da gerência são repassadas de forma:
a) ( ) Precisa e detalhada, determinando passo a passo como as tarefas devem ser executadas b) ( ) Ampla, deixando margem para escolha da forma de executar as tarefas
Q-23. Qual o nível de documentação de software exigido na empresa?
a) ( ) Alto b) ( ) Médio c) ( ) Baixo
153
Questionário utilizado no trabalho de dissertação no curso de Pós Graduação em Ciência da Computação da Universidade Federal de Santa Catarina – UFSC Mestrando: Cristiano Tolfo Orientador: Prof. Raul S. Wazlawick E-mail: [email protected]
QUESTIONÁRIO PARA O GERENTE DA EMPRESA Q-1. Os desenvolvedores de software envolvidos em um mesmo projeto trabalham:
a) ( ) No mesmo ambiente b) ( ) No mesmo ambiente, mas divididos por baias c) ( ) Em salas diferentes d) ( ) Em locais diferentes da mesma cidade e) ( ) Em cidades diferentes
Q-2. Considerando aspectos culturais como colaboração, comunicação, espírito de equipe e o relacionamento entre os desenvolvedores, é possível criar um ambiente de trabalho único?
a) ( ) Já existe um ambiente único b) ( ) É possível c) ( ) É difícil d) ( ) É impossível
Q-3. Quantos níveis hierárquicos (relacionados ao desenvolvimento de software) existem na empresa?
a) ( ) 1 nível hierárquico b) ( ) 2 níveis hierárquicos c) ( ) 3 níveis hierárquicos d) ( ) mais que 3 níveis hierárquicos
Q-4. Existem níveis hierárquicos (formais ou informais) na equipe de desenvolvimento de software?
a) ( ) 1 nível hierárquico b) ( ) 2 níveis hierárquicos c) ( ) 3 níveis hierárquicos d) ( ) mais que 3 níveis hierárquicos
Q-5. Qual é o número médio de desenvolvedores que costumam trabalhar num mesmo projeto de software?
a) ( ) Até 5 b) ( ) De 5 a 12 c) ( ) Mais que 12
154
Q-6. Quais dos eventos abaixo são realizados na empresa? a) ( ) Práticas esportivas b) ( ) Comemorações de aniversários c) ( ) Confraternizações d) ( ) Comemorações por resultados positivos obtidos pela empresa (como aumento do faturamento da empresa, sucesso de algum produto desenvolvido) e) ( ) Outros: ____________________________________________________ f) ( ) Nenhum evento é realizado
Q-7. Como são tratados os erros cometidos pelos desenvolvedores que possam atrasar ou comprometer os projetos de software?
a) ( ) São tratados como parte do processo de aprendizagem b) ( ) Busca-se identificar o culpado, o qual é criticado abertamente c) ( ) Busca-se identificar o culpado, o qual é criticado de forma reservada d) ( ) Busca-se identificar o culpado, o qual é criticado e punido e) ( ) Não se prioriza a identificação do culpado, mas se critica abertamente o erro
Q-8. O sistema de recompensa está baseado em:
a) ( ) Tempo de serviço b) ( ) Inovação e Criatividade c) ( ) Disciplina (cumprimento das normas e ordens) d) ( ) Outro:_______________________________ e) ( ) Não existe sistema de recompensa
Q-9. O sistema de recompensa está direcionado para:
a) ( ) Recompensa individual b) ( ) Recompensa por equipe c) ( ) Não há sistema de recompensa
Q-10. O sistema de avaliação está baseado em:
a) ( ) Avaliação individual b) ( ) Avaliação por equipe c) ( ) Não há sistema de avaliação
Q-11. A empresa costuma tomar providências como flexibilizar o horário ou custear despesas dos desenvolvedores que pretendem participar de eventos como congressos, cursos de graduação e pós-graduação?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-12. Quanto à jornada de trabalho da equipe de desenvolvimento:
a) ( ) São respeitadas, com poucos momentos de horas extras b) ( ) Freqüentemente se trabalha além da jornada de trabalho proposta
155
Q-13. Quais os benefícios que a empresa concede aos desenvolvedores? a) ( ) Vale transporte b) ( ) Vale refeição c) ( ) Participação nos lucros d) ( ) Plano de carreira e) ( ) Assistência médica f) ( ) Outros benefícios:_________________________________ g) ( ) Nenhum benefício
Q-14. Qual o nível de capacitação e de experiência dos membros da equipe de desenvolvimento de software?
a) ( ) Alto b) ( ) Médio c) ( ) Baixo
Q-15. Considerando o conhecimento e as habilidades dos desenvolvedores, os mesmos teriam condições de acumular mais de uma função num projeto?
a) ( ) Já assumem mais de uma função b) ( ) É possível c) ( ) É difícil d) ( ) É impossível
Q-16. As atividades relacionadas ao desenvolvimento de software são mais orientadas:
a) ( ) Para tarefas individuais b) ( ) Para tarefas em equipe
Q-17. Os programadores são relutantes para assumir mais responsabilidades pessoais?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-18. Os desenvolvedores preferem:
a) ( ) Cumprir ordens ao invés de assumir responsabilidades e correr riscos b) ( ) Assumir responsabilidades e correr riscos
Q-19. Os desenvolvedores procuram fazer sugestões para melhorias no processo de desenvolvimento de software?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
156
Q-20. As opiniões e sugestões dos desenvolvedores têm sido consideradas e implementadas?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-21. Os softwares costumam satisfazer todos os requisitos dos clientes?
a) ( ) Sempre b) ( ) Quase sempre c) ( ) Às vezes d) ( ) Raramente e) ( ) Nunca
Q-22. Qual o nível de comprometimento dos desenvolvedores com o trabalho?
a) ( ) Alto b) ( ) Médio c) ( ) Baixo
157
Gráfico de respostas do questionário submetido aos desenvolvedores
0 1 2 3 4 5 6 7 8 9 10
Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Q9
Q10
Q11
Q12
Q13
Q14
Q15
Q16
Q17
Q18
Q19
Q20
Q21
Q22
Q23
Qu
estõ
es
Número de respostas
e
d
c
b
a
158
Respostas do questionário submetido ao gerente de software:
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11
a a b a a c b a a a b
Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22
b c/e b c a b a d a c c
Livros Grátis( http://www.livrosgratis.com.br )
Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas
Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo
