Escolar Documentos
Profissional Documentos
Cultura Documentos
Gestão de Produtividade :
eXtreme Programming
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
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
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.
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
2. Objetivos
5
3. Justificativa
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
4. Fundamentação Teórica
4. 1 Produtividade
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.
7
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.
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]
8
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
5. Perspectivas Metodológicas
10
6. Extreme Programing (XP)
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.
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).
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]
11
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]
6.1.1 Valores
6.1.1.1 Feedback
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
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
6.1.1.3 Simplicidade
13
6.1.1.4 Coragem
“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]
14
“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
15
6.2.1 Jogo de Planejamento (Planning Game)
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.
16
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.
São testes desenvolvidos em conjunto pelos analistas, testadores e pelo cliente, para aceitar
um certo requisito do sistema.
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.
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
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.
18
mais fácil reaproveitamento, evitando assim a duplicata de código fonte.
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.
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.2 Coach
19
6.3.3 Analista de Teste
6.3.5 Desenvolvedor
20
7. Estudo de Caso
7.1 Introduçã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.
21
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.
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
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.
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.
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
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.
24
Pessoa 1 Pessoa 2 Pessoa 3 Pessoa 4
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
Figura 2 – Gráfico de Desempenho
26
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.
À 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.
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
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.
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
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.
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.
29
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
8. Conclusão
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.
31
9. Bibliografia
3 - Enciclopédia Wikipédia -
http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema - Último acesso em
23/06/2007
10- Moran, J., Interferência dos meios de comunicação no nosso conhecimento, INTERCOM
Revista Brasileira de comunicação, 1994.
32