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

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

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.

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.

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]

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

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

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]

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]

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

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.

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]

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]

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]

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.

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

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

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.

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.

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.

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

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

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.

25

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.

Pessoa 1 Pessoa 2 Pessoa 3 Pessoa 4

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.

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.

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.

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.

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.

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.

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.