1. Universidade de São Paulo
Escola de Artes, Ciências e Humanidades
Gestão de Produtividade :
eXtreme Programming
Prof. Dr. Edimir Parada Vasques Prado
Disciplina: Fundamentos de Sistemas de Informação
Alunos: Lucas Sabbag Leonel nºUsp 5365730
George Pio Rigato nºUsp 5365622
Leandro Timossi de Almeida n.º USP 5364861
Mário Januário Filho n.º USP 5365372
São Paulo - 2007

2. Sumário
1. Resumo 4
2. Objetivos 5
3. Justificativa 6
4. Fundamentação Teórica 7
4.1 Produtividade 7
4.2 Gestão de Produtividade 7
4.3 Sistemas de Informação 8
5. Perspectivas Metodológicas 10
5.1 Gestão de Produtividade Sistêmica 10
5.2 Lógica de Ganho 10
6. Extreme Programming (XP) 11
6.1 Características de XP 11
6.1.1 Valores 12
6.1.1.1 Feedback 12
6.1.1.2 Comunicação 13
6.1.1.3 Simplicidade 13
6.1.1.4 Coragem 14
6.2 Práticas de XP 15
6.2.1 Jogo de Planejamento (Planning Game) 16
6.2.2 Pequenas Versões (Small Releases) 16
6.2.3 Metáfora (Metaphor) 16
6.2.4 Projeto Simples (Simple Design) 17
6.2.5 Time Coeso (Whole Team) 17
6.2.6 Testes de Aceitação (Custome Tests) 17
6.2.7 Ritmo Sustentável (Sustaninable Pace) 17
6.2.8 Reuniões em Pé (Stand-usp Meeting) 17
6.2.9 Posse Coletiva (Collective Ownership) 18
6.2.10 Programação em Pares (Pair Programming) 18
6.2.11 Padrões de Codificação (Coding Standards) 18
6.2.12 Desenvolvimento Orientado a Testes (Test Driven Development) 18
2

3. 6.2.13 Refatoração (Refactoring) 18
6.2.14 Integração Contínua (Continuous Integration) 19
6.3 Estrutura da Equipe 19
6.3.1 Gerente do Projeto 19
6.3.2 Coach 19
6.3.3 Analista de Teste 20
6.3.4 Redator Técnico 20
6.3.5 Desenvolvedor 20
7. Estudo de Caso 21
7.1 Introdução 21
7.2 O Projeto Gestão de Frotas 22
7.3 Aspectos do Projeto 23
6.3.1 Ambiente Informativo 23
6.3.2 Programação em Par 26
6.3.3 Cliente Presente 26
6.3.4 Reuniões em Pé 27
6.3.5 Desenvolvimento Orientado a Testes 27
6.3.6 Código Coletivo 27
6.3.7 Código Padronizado 28
6.3.8 Design Incremental ou Design Simples 28
6.3.9 Metáforas 29
6.3.10 Ritmo Sustentável e Trabalho Energizado 29
6.3.11 Contrato de Escopo Negociável 29
6.3.12 Considerações 30
8. Conclusão 31
9. Bibliografia 32
3

4. 1. Resumo
Este trabalho apresenta uma pesquisa sobre gestão de Tecnologia da Informação com
ênfase em produtividade, identificando os principais pontos em que a produtividade influi nas
organizações e seu ambiente de atividade, e também o inverso, onde as organizações podem
influenciar sua produtividade.
Abordamos como foco principal do trabalho, a metodologia eXtreme Programming,
técnica utilizada para otimização no desenvolvimento de software, como toda sua estrutura,
maneira de implementação, entre outros fatores que afetam diretamente a gestão de produtividade
da organização.
E para mostrarmos o uso no cotidiano desse processo, optamos por fazer um estudo de
caso, fazendo uma entrevista com os implementadores dessa técnica, no Departamento de
Informática da Universidade de São Paulo.
4

5. 2. Objetivos
Como proposto pela disciplina de Fundamentos de Sistemas de Informação, pretendemos
elaborar um texto científico para o estudo da relação da produtividade dentro das organizações,
como suas características básicas, suas esferas de influência bem como sua relação com Tecnologia
da Informação, como ferramenta para gerenciar, analisar e como coadjuvante na hora de tomar
decisões que influenciam na produtividade de uma organização.
Com o surgimento de novas tecnologias e modos de se analisar e monitorar estágios da
produção de um produto ou serviço, surgiu uma técnica altamente produtiva para a otimização no
desenvolvimento de software, chamada de eXtreme Programming.
Portanto, apresentaremos um estudo sobre o eXtreme Programming (XP), uma técnica de
desenvolvimento de software que possibilita a criação de softwares de alta qualidade, de uma
maneira altamente produtiva.
5

6. 3. Justificativa
Vivemos na chamada era do conhecimento que gera e disponibiliza milhares informações
divulgadas e acessíveis através de diversos meios. Entende-se por conhecimento a captação, a
compreensão e a expressão de todas as dimensões da realidade e a sua ampliação integral; entende-
se como capacidade o uso do conhecimento para atividades e fins específicos; e, entende-se por
gestão do conhecimento a forma como se faz a criação, a partilha, a distribuição e a utilização do
conhecimento para atingir plenamente os objetivos da organização.[10]
Com tanta informação armazenada em forma de conhecimento e cada vez mais necessárias
para as organizações reduzir erros na tomada de decisões, surgiu a Gestão do Conhecimento, que
segundo a Fundação Getulio Vargas é um processo sistemático, articulado e intencional, apoiado na
geração, codificação, disseminação e apropriação de conhecimentos, com o propósito de atingir a
excelência organizacional. [10]
Para as organizações tempo é dinheiro, então elas estudam métodos para a tomada de
decisão cada vez mais otimizados e precisos, e metodologias como o XP (Extreme Programming)
vem promovendo esse objetivo. O processo do XP estrutura o planejamento, execução e controle
das atividades e artefatos gerados, ajudando a criar sistemas de melhor qualidade, que são
produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são
alcançados através de um pequeno conjunto de valores, princípios e práticas, que diferem
substancialmente da forma tradicional de se desenvolver software. Dessa maneira o XP, é
considerado por muitos estudiosos como uma grande solução para suprir a demanda e o
crescimento do mercado do conhecimento.[10]
6

7. 4. Fundamentação Teórica
4. 1 Produtividade
Produtividade é, basicamente, a relação entre o volume de produção de um determinado
item ou serviço e os recursos necessários a esta produção, em uma escala que quando se têm maior
produção e menor recursos consumidos, melhor é a produtividade, evento que certamente é
resultado de uma boa gestão.[4]
Não só apenas itens teóricos definem Produtividade, a visão das organizações também é
importante para entende-la, a Japan Productivity Center define Produtividade, como o meio que
minimiza cientificamente o uso de recursos materiais, mão-de-obra, máquinas, equipamentos etc.,
para reduzir custos de produção, expandir mercados, aumentar o número de empregados, lutar por
aumentos reais de salários e pela melhoria do padrão de vida, no interesse comum do capital, do
trabalho e dos consumidores.
Quando estudamos produtividade, buscamos identificar, analisar e minimizar a influência
de fatores que, de uma forma direta ou indireta, interferem para que algo indesejado distorça os
resultados esperados.
4.2 Gestão de Produtividade
Tendo em mente o ponto de vista da produtividade, gerir uma organização faz-se
extremamente necessário hoje, devido à competição acirrada do mercado. Portanto uma
produtividade eficiente possibilita chegar-se ao nível de competir com o mercado.[4]
Existem três procedimentos básicos que a gestão da produtividade incorpora à suas
técnicas:
Identificação da produtividade;
Identificação e análise de pontos de estrangulamento da produtividade;
Criação e aplicação de propostas a fim de eliminar estes “gargalos”;
Estes procedimentos são genericamente, uma forma de melhor aproveitamento dos
recursos disponíveis e um re-conhecimento dos processos inerentes ao processo de produção assim
7

8. como do meio ambiente que influem nestes processos.[4]
Com todos os processos existentes bem definidos, têm-se como ações acompanhar a
execução dos mesmos, identificando e alocando recursos humanos mais adequados, preparados e
habilidosos, resultando numa melhor qualidade do produto final de qualquer processo; Selecionar e
manter os equipamentos mais adequados aos processos em questão, evitando desperdício ou falta de
maquinário; Adequar as quantidades necessárias de material, evitando a falta e principalmente o
desperdício.[5]
Todos estes recursos além de fazerem parte do processo de produção, também geram custo
para a organização, assim influindo no índice de produtividade da empresa.[5]
4. 3 Sistemas de Informação
Sabe-se que a tecnologia já não pode ser ignorada em uma gestão que deseja alcançar o
sucesso, e essa tecnologia traz diversas opções ao ambiente organizacional. Os sistemas de
informação são poderosas ferramentas que as organizações vem usando para auxiliar em suas
políticas e práticas de produtividade.
Os Sistemas de informação surgiram para automatizar processos de transformar dados em
informações e, possivelmente, em conhecimento. É importante entender e definir as diferenças entre
dado, informação e conhecimento.
Dados são valores “jogados” no sistema que não possuem sentido por si só e são
transformados em informação apenas depois de processados, manipulados e agrupados de forma
que tenham algum sentido concreto. Segundo Laudon e Laudon (2004), dados são correntes de
fatos brutos que representam eventos que estão ocorrendo nas organizações ou no ambiente físico,
antes de terem sido organizados e arranjados de uma forma que as pessoas possam entende-los e
usa-los. Depois dos dados processados e organizados de forma a gerar informações úteis, as
informações podem ser transformadas em conhecimento. Informação nem sempre significa
conhecimento. [9]
O conhecimento é o modo como a informação é interpretada e aproveitada, é um fluído
composto por experiências, valores, informações do contexto e apreensão sobre o próprio domínio
de atuação que fornece uma aparelhagem cognitiva para avaliar e incorporar novas experiências e
8

9. informação.
Tecnicamente, um sistema de informação pode ser definido como um conjunto de
componentes inter-relacionados que coletam (ou recuperam), processam, armazenam e distribuem
informações para a tomada de decisão e controle em uma organização, contendo informações
significativas sobre pessoas, lugares e coisas dentro da organização ou em seu ambiente (Laudon e
Laudon, 1996). Esses sistemas têm como objetivo auxiliar no controle da informação e na análise
de dados, facilitar o planejamento estratégico e a tomada de decisão dentro de uma organização.[8]
9

10. 5. Perspectivas Metodológicas
Métodos e práticas estudadas, a se aplicar em uma organização onde se analisa todos os
processos, recursos humanos, forças externas e internas e/ou objetivos estratégicos da mesma, com
o intuito de compreender todos os eventos que envolvem a produção da empresa, assim sendo
possível uma melhora na produtividade da organização.
5.1 Gestão de Produtividade Sistêmica:
A principal técnica desta abordagem é a geração de valor adicionado através do processo
produtivo e não mais a produção física. A análise da empresa é feita como uma unidade sistêmica
integrada, não como um conjunto de departamentos.[4]
5.2 Lógica do Ganho:
Uma ampliação do prisma da gestão de produtividade sistêmica, mantendo a técnica de
geração de valor adicionado, porém esta abordagem passa a ser todo eixo de estratégias da empresa.
Todo processo produtivo e sua relação com a lucratividade passam a ser à base de planejamento da
empresa.[4]
10

11. 6. Extreme Programing (XP)
6.1 Características de Extreme Programing
Extreme Programming é uma técnica utilizada para criar software flexível e de alta
qualidade, empregando a equipe de desenvolvimento (geralmente com até 12 desenvolvedores), em
atividades que produzam resultados rápidos na forma de software testado, e ainda customizando o
produto de acordo com a necessidade do usuário.
Os fundamentos principais da metodologia XP originaram de tradições de
desenvolvimento em Smaltalk nos meados da década de 80. Quando Kent Beck e Ward
Cunningham definiram as seguintes práticas: refatoração, programação em par, mudanças rápidas,
feedback constante do cliente, desenvolvimento iterativo, testes automatizados, entre outras, são
elementos centrais da cultura de Smalltalk. Fazendo com que a metodologia XP, possa ser
considerada como o modo de agir da comunidade de Smaltalk, generalizando para outros
ambientes.
De 1986 a 1996, Kent e Ward desenvolveram várias práticas que foram condensadas no
padrão de linguagem Episodes (publicado em 1996, Pattern Langugages of Program Design 2).
Neste mesmo período surgiram importantes avanços na área de refatoração. Destaca-se
nesta área a tese de Bill Opdyke “Refactoring Object-Oriented Frameworks”. Essa tese mostrou o
ganho que as pessoas obtinham usando a prática de Refatoração.
Também em 96, Kent publicou o livro “Smaltalk Best Pratices Patterns”, que apresentava
boas técnicas de desenvolvimento, grande parte das quais foi combinada no trabalho de Martin
Fowler et al.(2000). [1]
Citando a organização padrão da metodologia de XP, pela enciclopédia “Wikipedia”:
“Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade,
feedback e coragem. A partir desses valores, possui como princípios básicos: feedback rápido,
assumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade. Dentre as
variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em
escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor
possível para o negócio. Desta forma, caso seja necessário à diminuição de escopo, as
11

12. funcionalidades menos valiosas serão adiadas ou canceladas. A XP incentiva o controle da
qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao
diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.”
[3]
O modo de trabalho é eficaz e rápido, eliminando atividades redundantes, utilizando dois
profissionais e uma máquina, onde um profissional interage com o outro, corrigindo-o e
planejando.[6]
Ocorrem ciclos de duas em duas semanas, onde há planejamento, execução e feedback.
Assim a cada duas semanas o cliente pode, ao não se satisfazer, redirecionar esforços para corrigir
erros.[6]
Do ponto de vista da gestão, a técnica de desenvolvimento de software de extreme
programming é voltada para alcançar níveis de produtividade muito altos, ao combinar poucos
recursos humanos, e técnicas de rápido desenvolvimento, assim podendo produzir muito, com
poucos gastos e ainda manter um padrão alto de qualidade.[6]
6.1.1 Valores
6.1.1.1 Feedback
O conceito de feedback aqui é aplicado como a troca de conhecimentos entre cliente e a
equipe de desenvolvimento sobre o universo que o software estará imerso, capacidades e limitações
de desenvolvimento e principalmente o levantamento de requisitos do sistema, que se faz
extremamente complexo. Normalmente, o cliente não compreende ou prevê todas as
funcionalidades do sistema no nível exigido pela equipe de desenvolvimento na fase de análise de
requisitos, o que gera em todos os casos, ruídos e falhas, independentes da técnica de
desenvolvimento utilizada.
Então, a fase da compreensão das necessidades do cliente, é considerada uma das mais
difíceis de todo o projeto, pois é a partir dela que todos os caminhos são projetados, escopos e
objetivos são definidos, e uma vez definidos, voltar e corrigir os requisitos é uma tarefa muito
complicada e sensível.
12

13. Portando, a tática utilizada em XP é organizar ciclos curtos de feedback, onde em cada
ciclo poucas funcionalidades são priorizadas e implementadas, com o intuito de possibilitar o
cliente requisitar novas funcionalidades a cada ciclo, e ainda conhecer funcionalidades que já foram
implementadas, corrigindo eventuais falhas ainda um estágio onde é relativamente barato realizar as
correções. E então, o desenvolvimento segue, somente após a certeza de que o resultado está
correto.[1]
6.1.1.2 Comunicação
A necessidade de comunicação entre a equipe de desenvolvimento e usuários é
desafiadora, ao se pensar nos usuários expressando idéias que sempre vêem no seu cotidiano como
conceitos implícitos no contexto, e a equipe de desenvolvimento tentando compreender estas
mesmas idéias, através do meio de comunicação que estiverem usando, que pode tanto complicar
como facilitar a troca de conhecimento.
Extreme Programming incentiva o envolvimento ativo dos participantes, através de
encontros presenciais onde a equipe de desenvolvimento trabalha, criando meios de comunicação
ricos e que aceleram o fluxo de informações.[1]
6.1.1.3 Simplicidade
O valor simplicidade trata sobre direcionar recursos a funcionalidades e esforços realmente
necessários ao projeto, assim não desperdiçando recursos humanos, tempo e dinheiro em itens que
não serão utilizados no futuro.
A cada ciclo de desenvolvimento, as funcionalidades definidas são implementadas coma
melhor qualidade possível, porém sem sair do escopo pré-definido, limitando-se somente ao
requisitado pelo usuário. Assim evita-se as comuns “prevenções”, onde se pensa antecipar um
futuro requisito do usuário, mas com a incerteza de ser realmente uma necessidade, porque logo
após a implementação, o usuário vai testar e confirmar se a funcionalidade está aprovada ou não.[1]
13

14. 6.1.1.4 Coragem
Ambas as partes de um projeto de desenvolvimento de software possui temores de que
certos aspectos do projeto podem não acontecer do modo como deseja, ou não acontecer de modo
algum. Confiança não é acreditar que todos os aspectos do planejamento irão ocorrer sem
problemas, e sim confiar nos mecanismos utilizados pela XP que amenizam ou eliminam os
problemas que ocorrem no decorrer do projeto.
Citando Teles, as principais formas de conter erros, aumentando a confiança da equipe
envolvida em projetar e desenvolver:
“O cliente teme não obter o que pediu, ou ainda pior, pedir a coisa errada. Para protegê-
lo, o XP adota iterações curtas (normalmente de uma a três semanas) e fixas (se a equipe opta por
duas semanas, por exemplo, todas as iterações do projeto terão sempre esta duração). Desta
forma, ao final de cada iteração, é possível avaliar se a equipe implementou o que foi pedido e se o
que foi pedido realmente fazia sentido. O problema não é eliminado em função do desenvolvimento
iterativo. O cliente pode ter solicitado algo errado no início da iteração ou a equipe pode ter
implementado de forma incorreta, mas isso é descoberto cedo. Como a iteração é curta, poucas
funcionalidades são implementadas. Portanto, caso haja um erro, o mesmo se refere a um conjunto
reduzido de funcionalidades, o que facilita eventuais correções e evita que a equipe invista muitos
recursos em funcionalidades incorretas, caso o cliente tenha errado ao solicitá-las”
(POPPENDIECK & POPPENDIECK, 2003).[1]
“O desenvolvimento iterativo também ajuda a lidar com o medo que o cliente tem de
pagar demais por muito pouco. Ao receber funcionalidades com freqüência, em prazos curtos, o
cliente passa a ter diversas oportunidades de avaliar o trabalho das 68 equipes com base em
feedback concreto: software executável. Assim ele pode decidir se continua ou não a empregar
aquela equipe ou se é preferível trocar (TELES, 2004). Além disso, o feedback constante, produzido
ao longo das iterações, faz com que o cliente possa saber exatamente o que está acontecendo no
projeto” (BECK & FOWLER, 2001).[1]
“Finalmente, o processo de planejamento não é estático. A cada início de iteração o
planejamento geral do projeto é revisado e atualizado com base em informações mais recentes. Isto
é, o processo de planejamento é contínuo e procura incorporar feedback ao longo do tempo. Isso
permite a elaboração de planos para cada iteração que têm maiores chances de acerto. Além disso,
no processo de priorização, o cliente pode incorporar novas decisões de negócios de forma
natural” (BECK & FOWLER, 2001).[1]
14

15. “Desenvolver software de forma iterativa e incremental não tem apenas vantagens.
Também gera alguns riscos, como por exemplo o de introduzir falhas em algo que vinha
funcionando corretamente. Por isso, o XP adota a prática de desenvolvimento orientado a testes
como mecanismo básico de proteção. O desenvolvimento orientado a testes é uma forma de lidar
com o medo durante a programação (BECK, 2003, p.x, tradução nossa). Ele leva os
desenvolvedores a criar uma base de testes automatizados que possam ser executados toda vez que
um novo fragmento de código é adicionado ao sistema. Embora isso não impeça a ocorrência de
erros, representa um instrumento útil para detectá-los rapidamente, o que agiliza a correção e
evita que eventuais bugs se acumulem ao longo do tempo. Os desenvolvedores temem não saber
solucionar alguns problemas e não serem capazes de se atualizar tecnicamente. O XP utiliza a
programação em par para permitir que os membros desenvolvedores aprendam continuamente uns
com os outros. Além disso, a possibilidade de contar sempre com a ajuda imediata de um colega
gera maior confiança na capacidade de resolver os desafios apresentados pelo cliente. Finalmente,
a programação em par estabelece um processo permanente de inspeção de código, o que serve
como uma rede de proteção adicional contra eventuais erros cometidos durante a codificação de
novas funcionalidades ou alteração de outras previamente existentes”(WILLIAMS & KESSLER,
2003).[1]
“Outra preocupação permanente dos desenvolvedores é não ter tempo suficiente para
realizar um trabalho de qualidade. O XP trata essa questão dividindo claramente a
responsabilidade por decisões técnicas e de negócio. O cliente tem soberania nas decisões de
negócio. Portanto, ele decide que funcionalidades devem ser implementadas e em que ordem. Os
desenvolvedores, por sua vez, têm autoridade e responsabilidade sobre as decisões técnicas.
Portanto, são eles que estimam os prazos. Isso ajuda a lidar com o medo de ter que cumprir prazos
impossíveis impostos por pessoas que não possuam a qualificação técnica para estimar o esforço
de um determinado trabalho de programação (BECK & FOWLER, 2001).” [1]
6.2 Práticas de XP
Para conseguir atingir os valores e princípios no desenvolvimento de software, o XP indica
algumas práticas. Há uma ligação muito forte entre as práticas, pois elas se completam, fazendo
com que os pontos fracos de uma, sejam recuperados pelos pontos fortes de outra. Na seqüência
apresentamos as práticas, falando um pouco sobre cada uma: [2]
15

16. 6.2.1 Jogo de Planejamento (Planning Game)
O desenvolvimento do software, é divido em várias etapas, e essas etapas são
desenvolvidas semanalmente. No começo de cada semana é feito uma reunião chamada de Jogo de
Planejamento, aonde o cliente e os desenvolvedores participam. O cliente tem papel fundamental na
reunião, pois é nela que ele identifica as prioridades, e os desenvolvedores as estimam, com isso o
cliente fica ciente do que está acontecendo, e o que irá acontecer. Como a cada começo de semana o
escopo do projeto é reavaliado, o projeto gira em torno de um contrato de escopo negociável, que é
diferente das formas normais de contratação de desenvolvimento de software. Ao final de cada
semana, os desenvolvedores entregam o resultado desenvolvido durante a semana toda, podendo
assim o cliente já colocar as funcionalidades desenvolvidas em ação.
6.2.2 Pequenas Versões (Small Releases)
A metodologia XP usa o desenvolvimento por partes, partes tão pequenas, que chegam
ainda ser menores que as produzidas por outras metodologias incrementais, como o RUP. Conforme
essas pequenas partes vão sendo desenvolvidas, a equipe de desenvolvimento libera elas para os
usuário, e os usuários já colocam elas em ação. Com isso os clientes vão tendo uma visão do
sistema, e com isso auxilia muito no processo de aceitação do cliente, que já pode testar uma parte
do sistema.
6.2.3 Metáfora (Metaphor)
As metáforas fazem com que a comunicação entre os clientes e os desenvolvedores. Por
exemplo, o conceito de rápido para um cliente de um sistema jurídico é diferente do conceito de
rápido para um programador experiente em controlar a comunicação de sistemas em tempo real. Por
isso a necessidade das metáforas, que assim facilita a comunicação entre ambas às partes.
16

17. 6.2.4 Projeto Simples (Simple Design)
XP tem como principio a simplicidade. Projeto simples significa você fazer exatamente o
que o cliente pedir, e não se preocupar em desenvolver coisas mais, como restrições, segurança,
entre outros, isso na fase de teste. Fazendo o código preocupando apenas em que a funcionalidade
seja implementada, sem pensar em coisas a mais. A uma grande confusão, que acaba fazendo com
que os programadores cometam um erro, que é confundir código simples com código fácil. Sem
sempre o código mais fácil de ser implementado resultará na solução mais simples do projeto. Para
ter um bom andamento do XP, é bom saber distinguir o código fácil do simples, fazendo a alteração
do código fácil pelo simples.
6.2.5 Time Coeso (Whole Team)
A equipe de desenvolvimento é composta pelos desenvolvedores e também pelo cliente.
6.2.6 Testes de Aceitação (Customer Tests)
São testes desenvolvidos em conjunto pelos analistas, testadores e pelo cliente, para aceitar
um certo requisito do sistema.
6.2.7 Ritmo Sustentável (Sustaninable Pace)
Trabalho com qualidade, buscando o ritmo de trabalho saudável, sem horas extras.
Trabalho saudável é (40 horas semanais, 8 horas diárias). Fazer horas extras, somente quando foi
para trazer produtividade para a execução do projeto.
6.2.8 Reuniões em pé (Stand-up Meeting)
Reuniões rápidas, apenas para discutir tarefas realizadas e a ser realizadas, sem perder o
foco nos assuntos. Por isso chamadas reuniões em pé.
17

18. 6.2.9 Posse Coletiva (Collective Ownership)
O código fonte não possui dono, com isso ninguém precisa pedir a permissão para
modificar o código, tendo livre acesso. Com isso, faz com que todos passam a conhecer todas as
partes do sistema.
6.2.10 Programação em Pares (Pair Programming)
Programar em dupla em um mesmo computador. Essa dupla é composta por um iniciante
na linguagem usada e uma pessoa que domine a linguagem para servir de instrutor. Sendo o
instrutor fica apenas acompanhando e assessorando o iniciante, que fica a frente do computador.
Com isso sempre busca a evolução da equipe, melhorando a qualidade do código fonte, pois o
código acaba sendo revisto por duas pessoas, evitando e diminuindo a possibilidade de erros (bugs).
6.2.11 Padrões de Codificação (Coding Standards)
A equipe de desenvolvimento estabelece regras para programar, e todos os programadores
têm que seguir estas regras, com isso todo o código fonte parecerá que apenas uma pessoa o
desenvolveu, não importando o número de pessoas que pertence à equipe.
6.2.12 Desenvolvimento Orientado a Testes (Test Driven Development)
Primeiramente se criam testes de acordo com as partes do desenvolvimento, depois crie o
código para que os testes funcionem. Esta abordagem parece difícil no inicio, pois vai contra ao
processo de desenvolvimento de muito tempo. Mas os testes unitários são fundamentais para que o
projeto mantenha sua qualidade.
6.2.13 Refatoração (Refactoring)
Processo no qual permite a melhora continuada da programação, mantendo a
compatibilidade com o código já existente e com pelo menos um pouco de introdução de erros.
Recriar o código, melhora a leitura do mesmo, divide ele em partes que o torna mais coeso, e de
18

19. mais fácil reaproveitamento, evitando assim a duplicata de código fonte.
6.2.14 Integração Contínua (Continuous Integration)
Quando produzir uma nova funcionalidade, sempre integra-la em menos de uma semana na
versão atual do sistema. Pois demorando muito para integra-la, aumenta a possibilidade de conflitos
e de ocorrer erros no código fonte. A integração contínua do sistema, faz com que você sempre
possa saber o status real da programação.
6.3 Estrutura da Equipe
Uma equipe utilizando técnicas de XP, normalmente nomeia funções específicas, para
alguns integrantes. Estes integrantes, acabam “representando estes papéis” destas funções: [2]
6.3.1 Gerente do Projeto
O gerente do projeto responde pelos assuntos administrativos do projeto. Procura evitar o
contato da equipe de desenvolvimento com questões que não estejam ligadas à atividade diária de
desenvolvimento. Faz também o relacionamento com o cliente, fazendo com que o cliente participe
do desenvolvimento ativamente e que forneça informações para que a equipe possa atender suas
necessidades, para que o sistema quando pronto satisfaça o cliente.
6.3.2 Coach
O coach (técnico) é o responsável pela parte técnica do projeto. A metodologia XP
recomenda que essa função seja ocupada por um profissional bem preparado, para que ele oriente a
equipe de modo que ela siga as boas práticas recomendadas pelo XP. Sua principal tarefa é o bom
funcionamento do processo e buscar formas de melhora-lo continuamente, o coach pode também
atuar na implementação do sistema.
19

20. 6.3.3 Analista de Teste
O analista de teste é responsável por assessorar o cliente a escrever os testes de aceitação.
O analista deve fazer com que os testes sejam executados diversas vezes ao longo das iterações do
projeto, quando os testes não forem automatizados. O analista fornece o feedback para a equipe
rapidamente, logo que os eventuais erros do sistema são identificados. Fazendo com que a equipe
de desenvolvimento possa fazer as correções com rapidez, e evitando maiores problemas.
6.3.4 Redator Técnico
O redator técnico permite que a equipe de desenvolvimento concentre-se apenas na
implementação do sistema, fazendo ele toda à parte de documentação do sistema. A equipe técnica
realiza algumas documentações, mais a maioria delas são realizadas pelo redator técnico.
6.3.5 Desenvolvedor
O desenvolvedor é a pessoa que analisa, projeta e codifica o sistema, em palavras gerais é a
pessoa que realmente constrói o sistema. Na metodologia XP, não existe a distinção entre analista,
projetista e programador. Todos são considerados desenvolvedores, mais só que cada
desenvolvedor exerce papeis diferentes em diversos momentos do projeto.
20

21. 7. Estudo de Caso
XP no Departamento de Informática da USP
7.1 Introdução
Este estudo de caso representa o resultado de um projeto de desenvolvimento de software
que utilizou os valores e práticas do Extreme Programming durante um período de quatro meses,
após o projeto permanecer um ano e meio parado depois da conclusão da parte de documentação. O
projeto foi orientado para o uso interno e desenvolvido no Brasil. Vale salientar que o software, até
a produção desse estudo de caso, não estava completamente concluído e continua a passar por
manutenção e acréscimo de funções, conforme o surgimento de novos requisitos.
O Departamento de Informática (DI) da Universidade de São Paulo (USP) é um órgão
ligado à Coordenadoria de Administração Geral (Codage), criado em 1993 para promover uma
importante modernização da informática administrativa na USP. O DI é responsável pela criação e
manutenção de softwares para agilizar o dia-a-dia de alunos, funcionários e professores, tais como
os sistemas Júpiter, que cuida da vida acadêmica dos alunos da graduação, o Fênix, para a pós-
graduação, o Marte, que controla a folha de pagamentos, o Mercúrio, para a requisição de compras
e pedidos no almoxarifado, e o Proteos, que acompanha o andamento dos protocolos. Todos esses
Sistemas são integrados.
Em 2006 surgiu o interesse por Extreme Programming (XP), devido à necessidade de
entrega rápida e a aceitação da alta administração, culminando em sua implantação.
Durante o segundo semestre de 2006, parte da equipe recebeu treinamento em PHP e SQL.
Este foi realizado em períodos semanais, de modo que cada membro da equipe pudesse se revezar
entre o treinamento e o desenvolvimento do projeto. Dessa forma, mesmo com um dos
desenvolvedores em treinamento, o projeto continuava em progresso.
O aprendizado do Extreme Programming se deu através de treinamento oferecido pelo
diretor do departamento ao grupo, aproximadamente quatro horas, uma vez por semana. Com o
projeto já em andamento, as técnicas do XP foram sendo implantadas à medida que eram
transmitidas à equipe.
21

22. 7.2 O Projeto Gestão de Frotas
A Universidade de São Paulo possui atualmente - 2007 - uma frota de aproximadamente 800
veículos. Esses veículos estão distribuídos entre as faculdades e instituições da USP, de acordo com
o seu tamanho e necessidades.
Existem diversas funcionalidades e práticas que se operam sobre estes patrimônios da
Universidade. A USP possui postos de gasolina, entre eles um no Campus da Capital (PCO), no
Campus de Piracicaba e de Ribeirão Preto, destinados ao abastecimento de seus veículos e, além
disso, possui convênios com outros postos, para abastecimentos externos. Um dos motivos é a
existência de motores movidos a gás natural veicular. O Campus Armando de Salles Oliveira possui
uma oficina própria, localizada na Prefeitura do campus da Cidade Universitária (PCO). Essa
oficina realiza desde serviços de reparo simples à funilaria. Abastecimento, manutenção e reparo,
solicitação de ônibus para viagens, carros para transporte de passageiros, controle de condutores e
controle de tráfego estão entre as problemáticas que ocorrem no processo de gestão de uma frota.
O controle dessas funcionalidades era realizado através de papéis e de softwares
desagregados, que não compartilhavam informações. As práticas, além de terem alta carga de
trabalho, duplicação de tarefas, se mostravam ineficazes e ineficientes. Para saber quantos ônibus
estavam atuando no percurso de Circular, no Campus da Capital, era necessário ir até o
estacionamento e contar quantos estavam parados e procurar saber se algum estava na oficina.
Consulta a dados, como o histórico de reparos em um veículo ou das viagens que um condutor
realizou no mês, eram onerosas e lentas.
Por essas razões, entre diversas outras, a USP decidiu investir na aquisição de um software
de Gestão de Frotas, que atendesse às suas demandas. Mas, como os softwares apresentados pelo
mercado não foram completamente aceitos, resolveu-se que o desenvolvimento do software seria da
própria Universidade, sendo a tarefa de tal repassada ao Departamento de Informática da USP.
Entre os clientes e futuros usuários do sistema estão os responsáveis pelo controle de patrimônios
da USP, Diretoria de Transporte, responsáveis pela manutenção, utilização dos veículos,
abastecimento e solicitantes de transporte.
O sistema, que começou a ser desenvolvido em fevereiro de 2006, está sendo implementado
por uma equipe interna do DI, composta de cinco pessoas mais o Coordenador do Projeto,
utilizando PHP e Sybase, com interface desktop e acesso através da WEB. O projeto utiliza grande
parte das práticas originais do Extreme Programming, que foram sendo implantadas no primeiro e
22

23. início do segundo mês de desenvolvimento, à medida que as necessidades iam surgindo.
Papéis em uma equipe XP não são fixos e rígidos. O objetivo é fazer com que cada um
contribua com o melhor que tem a oferecer para que a equipe tenha sucesso.
Todos os contribuintes do projeto sentavam-se juntos como membros de um time. Através
de reuniões com usuários e clientes, a equipe definia os requisitos, fixava as prioridades e guiava o
projeto. O time possuía quatro programadores, os quais também absorveram a tarefa de ajudar o
cliente a definir os testes de aceitação e os requisitos. Além destes, existia um gerente que provia
recursos, mantinha a comunicação externa e coordenar as atividades. Nenhum destes papéis foi
necessariamente de propriedade exclusiva de um só indivíduo. Todos os membros do time
contribuíram de todas as formas que puderam, conforme suas capacidades.
7.3 Aspectos do Projeto
7.3.1 Ambiente Informativo
O ambiente de trabalho de uma equipe XP deve ser um reflexo do projeto. Alguém que entre
na sala da equipe deve conseguir obter, em poucos segundos, uma noção clara de como está o
andamento do projeto.
Um dos primeiros passos na implantação do XP e talvez a mais visível de todas as práticas
foi à aquisição de um quadro de avisos. Os cartões são colocados na parede, nesse mural, de modo
que possam ser acompanhados facilmente por todos os participantes do projeto, incluindo
desenvolvedores, gerentes, clientes, entre outros. Existem softwares que procuram ajudar no
planejamento de projetos XP. Entretanto, eles não são tão eficazes quanto os cartões em papel.
Como o projeto não é distribuído, optou-se pelo papel e caneta.
Com o intuito de coordenar as atividades, estabelecer uma harmonização das tarefas e tornar
evidente os objetivos do período, o quadro foi dividido em quatro partes.
Disponíveis: tarefas a serem escolhidas por alguém disponível e realizadas;
Atribuídas: tarefas escolhidas por um membro e que estão em andamento;
Concluídas: tarefas completadas;
Pendentes: tarefas que necessitam de outrem para serem iniciadas ou que ainda deverão ser
23

24. discutidas.
Posteriormente, devido à necessidade de membros da equipe que realizavam tarefas alheias
ao projeto, surgiu mais uma divisão no quadro:
Externas.
Foram preenchidos pequenos cartões para serem anexados nessas áreas. Cada cartão
continha o nome da tarefa, uma descrição e a quantidade de tempo que se presumia levar para o
término da mesma. A escolha de quais seriam as tarefas e o tempo geralmente eram definidos
semanalmente após reuniões.
Partindo-se dos princípios de que nenhuma tarefa leva menos de duas horas para ser
completada, já que podem surgir dificuldades no caminho, e de que uma tarefa que leve mais de
dois dias para ser concluída deve ser dividida em outras menores, a equipe adotou as seguintes
metáforas:
- uma esfera vazia equivale a 2 horas;
- uma esfera meia-lua equivale a 4 horas;
- uma esfera cheia equivale a um dia;
- duas esferas cheias equivalem a dois dias.
Os cartões com as tarefas eram anexados como disponíveis, de acordo com a sua ordem de
prioridade. O membro da equipe escolhe uma tarefa e atribuí ao seu nome. Dessa forma é possível
visualizar rapidamente quem está ocupado e com o que se está trabalhando no momento. Isso
também evita que mais de uma pessoa esteja trabalhando sobre um mesmo arquivo. O
desenvolvedor escolhe a tarefa com a qual possui maior familiaridade e que mais lhe agrade.
Conseqüentemente há uma melhora significativa na produtividade.
Ao término da tarefa, é atribuída ao cartão uma data, o nome de quem a realizou e a
quantidade real de tempo que ficou com o mesmo. Ele então é movido para a seção dos concluídos.
24

25. Pessoa 1 Pessoa 2 Pessoa 3 Pessoa 4
Figura 1 – Quadro de Cartões de Tarefas
Com os dados da soma semanal de esferas que estavam disponíveis e a quantidade real de
esferas que foram necessárias para a conclusão das tarefas, é gerado um gráfico que mede a relação
da produção que se esperava ter da equipe na semana e a que realmente ocorreu. A tendência seria a
equipe descobrir qual a quantidade de esferas (tempo total) que se deveria prever semanalmente
para a conclusão dos cartões.
25

26. Figura 2 – Gráfico de Desempenho
7.3.2 Programação em Par
Essa prática do Extreme Programming foi utilizada somente em algumas tarefas ou em
situações especiais. Devido ao fato de a equipe ter aprendido a trabalhar com as diversas
ferramentas, como PHP e Sybase, somente com o decorrer do processo, tornou-se necessário que
aqueles mais experientes nos métodos se sentassem com aquele que necessitasse de auxílio. Dessa
forma, além da transferência de conhecimento para futuras tarefas, houve um aumento da
produtividade da equipe como um todo.
7.3.3 Cliente Presente
O requerente e os usuários finais estiveram presentes durante toda a fase de implementação
e implantação. Isso se deu através de sucessivas reuniões, às vezes semanais, a medida que surgiam
necessidades de correções, dúvidas ou para definir as novas funcionalidades a serem produzidas.
26

27. Esse contato permanente com os solicitantes e usuários do software, foi de grande valia,
pois possibilitou um melhor encaminhamento do projeto, prevenindo erros de requisitos e
adaptando-se a interface conforme os critérios definidos por aqueles que antes trabalhavam com
métodos não informatizados.
À medida que o sistema era desenvolvido, testado e implantado, o cliente expunha suas
novas carências, sugeria alterações e relatava os possíveis erros do sistema.
7.3.4 Reuniões em Pé
Foram realizadas reuniões breves, entre 10 e 15 minutos, algumas vezes por semana. Nessas
reuniões eram discutidos os andamentos do projeto, progresso e entraves que surgiam.
Muitos problemas foram resolvidos nessas reuniões. Também foram importantes para que a
equipe pudesse ter uma melhor noção do todo, através do relato de seus colegas.
7.3.5 Desenvolvimento Orientado a Testes
À medida que as telas do site eram concluídas com as suas devidas funcionalidades, o
desenvolvedor testava todas as suas funções. Seu trabalho era repassado ao coach que então
colocava a função no ambiente de testes. O desenvolvedor testava novamente os métodos e só
depois de tudo verificado a nova página com sua funcionalidade era disponibilizada para o usuário
final. Isso preveniu erros e diminuiu a carga de trabalho gerada quando o usuário encontra erros no
sistema e a função volta à pauta.
7.3.6 Código Coletivo
A prática de código coletivo foi usada durante todo o projeto e não apresentou problemas.
Tornar o código coletivo permitiu que a equipe avançasse com agilidade, na medida em que não era
necessário esperar por outros desenvolvedores sempre que havia a necessidade de editar um arquivo
do sistema. Além disso, o revezamento entre as diversas funcionalidades permitiu que os
desenvolvedores obtivessem vivência em todos os aspectos do projeto.
27

28. Porém, houve uma centralização da responsabilidade de implantar o código. Após a
implementação, os membros da equipe transmitiam seus códigos para o coach, que os agregava
com o existente e disponibilizava-os ao sistema.
7.3.7 Código Padronizado
Nos primeiros dias do desenvolvimento a equipe estabeleceu um padrão para o código do
sistema. Isso foi muito útil para as práticas de código coletivo e da programação em par. Ambas
ajudaram a assegurar que os desenvolvedores aderissem aos padrões. Uma parte da padronização
foi baseada em um documento do Departamento de Informática que regula o uso de siglas em
sistemas, como a criação de banco de dados. Esse documento contém uma lista de palavras e suas
respectivas siglas, com três letras. Como muitas palavras, como pneu, eram específicas e não
estavam presentes na documentação, a equipe também passou a criar siglas padronizadas para essas
palavras. Entre outras utilizações dessas siglas, pode-se citar o caso de nomeação de campos de
tabelas e a nomenclatura das diversas variáveis presentes no sistema. Os nomes das páginas web
também foram padronizados.
Códigos semelhantes, como consultas ao banco de dados e scripts, foram agregados em
arquivos próprios para o grupo desses.
7.3.8 Design Incremental ou Design Simples
A cada renovação, a equipe de desenvolvimento implementava novas características na
arquitetura do sistema que fossem suficientes para comportar apenas as funcionalidades da criação.
Ou seja, mesmo que cartões de iterações futuras fossem conhecidos, a equipe não criava
mecanismos para sustentar a construção futura dos mesmos.
A equipe se focava basicamente nas tarefas que estavam sendo implementadas, não se
preocupando com futuras funcionalidades. Isso se mostrou vital a partir do momento que novas
necessidades do cliente iam surgindo enquanto outras previstas se mostraram não mais necessárias.
Outro ponto é que o desvio de atenção ou uma implementação mais complexa poderia gerar tarefas
e funções desnecessárias ao usuário.
28

29. 7.3.9 Metáforas
Um dos principais usos desse instrumento se deu na criação de figuras para os ícones do
projeto. Foram utilizadas figuras como peças, pneus e ferramentas nas funcionalidades de ordem de
serviços para reparos em oficinas. Outro ponto foi a transposição do processo de preenchimento do
papel do controle de viagem para o formato digital.
7.3.10 Ritmo Sustentável e Trabalho Energizado
A metodologia XP prega que o mais importante não é trabalhar mais e sim trabalhar de
forma mais inteligente. A equipe de desenvolvimento trabalhou das 8h às 19h, devido à diferença
entre turnos dos membros. Contudo, o que se mostrou primordial foi a força, inteligência e
sustentabilidade que os membros desempenharam no decorrer do processo. Métodos como o do
quadro de avisos ajudaram a focar o trabalho no necessário. Com um ritmo de produção constante o
projeto foi se encaminhando.
Porém houveram ocasiões em que foram necessárias estender a jornada de trabalho de
alguns membros, devido às datas de entregas curtas de partes do sistema.
7.3.11 Contrato de Escopo Negociável
Esse princípio se mostrou de grande valia no decorrer do projeto. Tradicionalmente é feito
um documento levantando, entre outros, os requisitos e cases do software a ser desenvolvido. Com
o XP esse escopo não é fixo. Assim o cliente pode fazer ajustes, os desenvolvedores têm a liberdade
para questionar funcionalidades e propor o que é mais prioritário. O escopo negociável teve
facilidade de ser implantado devido às condições do projeto. Por não se tratar de um software pago,
ou destinado à venda, mas sim uma solicitação de um departamento para outro em uma instituição
pública. Sem um custo, prazo e escopo previsível.
29

30. 7.3.12 Considerações
Um dos aspectos que se mostrou mais positivo foi a entrega de etapas para o usuário final. O
envolvimento do todos os membros da equipe, juntamente com o apoio dos próprios clientes do
projeto, se expôs como um grande auxílio no crescente desempenho na produtividade do software,
reforçado pelo compartilhamento do conhecimento e das informações. Os resultados apontam que
essa metodologia pode se tornar uma tendência nas outras equipes de desenvolvimento dentro do
Departamento de Informática da USP. O próximo passo seria a implantação total de todas as
práticas do extreme - programming.
A ocupação da Reitoria, por parte de manifestantes, que durou cerca de cinqüenta dias,
adiou a conclusão de tarefas. Prazos de entrega apertados, cobranças por resultados, expectativa e
ousadia foram marcantes no processo. Segundo o coach da equipe, “O resultado só não foi melhor
devido à necessidade inicial da equipe no método de desenvolvimento XP.”. Ele prevê que o
resultado será aprimorado nos futuros projetos. Parte da equipe possuía trabalhos externos a serem
realizadas. Isso muitas vezes onerou sobre a dedicação exclusiva. Outro ponto que atrapalhou o
andamento inicial foi a falta de conhecimento de parte dos desenvolvedores sobre as linguagens de
programação utilizadas. Porém, a aplicação do XP, os treinamentos oferecidos e a prática obtida
com o projeto tornaram a equipe capacitada para enfrentar novos desafios, afrontar tendências e
acolher as novas necessidades que a Universidade de São Paulo venha a ter.
30

31. 8. Conclusão
Percebemos que com o avanço de tecnologias da informação, novas formas de
monitoramento e controle, e sistemas de apoio administrativos, é evidente que a essência das
organizações está não só ligada, como também dependente da tecnologia, como uma ferramenta que
potencializa um alto índice de produtividade dentro da empresa.
Através dos estudos realizados, notamos que eXtreme Programming é uma técnica
altamente produtiva e confiável, porém que só pode ser empregada em certos projetos ou
necessidades de clientes.
Observamos também que eXtreme Programming é uma forma de produção pura e única,
altamente produtiva, e não alguma tecnologia a ser instalada/implementada, para então melhorar a
produtividade de algum processo já em funcionamento.
A forma como o software é desenvolvido, utilizando o feedback e as avaliações periódicas,
permite que seja altamente customizavel ao usuário, gerando uma qualidade muito alta e satisfatória
para o cliente.
Há um alto índice de produtividade, devido ao baixo custo de tempo de implementação em
XP, porém, dependendo da quantidade de funcionalidades e erros de comunicação/implementação,
o custo final do produto pode ser variável.
A utilização da metodologia de Extreme Programming culminou tanto no aumento e
qualidade do produção quanto na facilidade de gestão de todo o processo que se decorreu no caso
avaliado por esse estudo. Com a aplicação das diferentes práticas, o Departamento de Informática
da USP demonstrou que é possível angariar novas predileções mediante ao novo patamar que é
sobrepujado pelas tendências modernas.
A organização da produção, os papéis maleáveis e a integração da equipe estão entre as
grandes virtudes do desenvolvimento do Projeto Gestão de Frotas. O XP se mostra como uma
ferramenta útil, simples e barata, que poderá transformar os velhos dogmas presentes nas equipes de
desenvolvimento de softwares.
31

32. 9. Bibliografia
1 - Teles, V. M., Um estudo de caso da adoção das práticas e valores do extreme
programming, UFRJ, 2005
2 - Teles, V. M., Extreme Programming, NOVATEC, 2004.
3 - Enciclopédia Wikipédia -
http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema - Último acesso em
23/06/2007
4 - Macedo, M. de M., Gestão de produtividade nas Empresas – Revista FAE Business,
nº 3, set 2002 -
www.fae.edu/.../n3_setembro_2002/ambiente_economico3_gestao_da_produtividade_nas_empresa
s.pdf - Último acesso em 23/06/2007
5 - Geranegócio - www.geranegocio.com.br/html/geral/p13.html – Último acesso em
23/06/2007
6 - Medeiros, M. P., Implementando Pair Programming em sua equipe - Conhecendo as
dificuldades e as vantagens dessa prática XP -
http://www.devmedia.com.br/articles/viewcomp.asp?comp=1694 - Último acesso em 23/06/2007
7 - Bleinroth, C. E., Produtividade e Tecnologia
http://www.webpack.com.br/biblioteca_upload/119/artigo_05_produtividade_e_%20tecnologia.pdf
Último acesso em 23/06/2007
8 - LAUDON, K. e Laudon, J., Management Information Systems-Organization and
Technology. Macmillan Publishing Company, 1996.
9 - LAUDON, Kenneth C. & Laudon, Jane P., Sistemas de Informações Gerenciais,
Prentice Hall, 2004.
10- Moran, J., Interferência dos meios de comunicação no nosso conhecimento, INTERCOM
Revista Brasileira de comunicação, 1994.
32