Your SlideShare is downloading. ×
  • Like
2007 gestão de produtividade   xp
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

2007 gestão de produtividade xp

  • 301 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
301
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Universidade de São PauloEscola 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ário1. Resumo 42. Objetivos 53. Justificativa 64. Fundamentação Teórica 7 4.1 Produtividade 7 4.2 Gestão de Produtividade 7 4.3 Sistemas de Informação 85. Perspectivas Metodológicas 10 5.1 Gestão de Produtividade Sistêmica 10 5.2 Lógica de Ganho 106. 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 207. 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 308. Conclusão 319. 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 nasorganizações e seu ambiente de atividade, e também o inverso, onde as organizações podeminfluenciar 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 produtividadeda organização. E para mostrarmos o uso no cotidiano desse processo, optamos por fazer um estudo decaso, fazendo uma entrevista com os implementadores dessa técnica, no Departamento deInformática da Universidade de São Paulo. 4
  • 5. 2. Objetivos Como proposto pela disciplina de Fundamentos de Sistemas de Informação, pretendemoselaborar 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 Tecnologiada Informação, como ferramenta para gerenciar, analisar e como coadjuvante na hora de tomardecisões que influenciam na produtividade de uma organização. Com o surgimento de novas tecnologias e modos de se analisar e monitorar estágios daprodução de um produto ou serviço, surgiu uma técnica altamente produtiva para a otimização nodesenvolvimento de software, chamada de eXtreme Programming. Portanto, apresentaremos um estudo sobre o eXtreme Programming (XP), uma técnica dedesenvolvimento de software que possibilita a criação de softwares de alta qualidade, de umamaneira altamente produtiva. 5
  • 6. 3. Justificativa Vivemos na chamada era do conhecimento que gera e disponibiliza milhares informaçõesdivulgadas e acessíveis através de diversos meios. Entende-se por conhecimento a captação, acompreensã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 porgestão do conhecimento a forma como se faz a criação, a partilha, a distribuição e a utilização doconhecimento para atingir plenamente os objetivos da organização.[10] Com tanta informação armazenada em forma de conhecimento e cada vez mais necessáriaspara as organizações reduzir erros na tomada de decisões, surgiu a Gestão do Conhecimento, quesegundo a Fundação Getulio Vargas é um processo sistemático, articulado e intencional, apoiado nageração, codificação, disseminação e apropriação de conhecimentos, com o propósito de atingir aexcelência organizacional. [10] Para as organizações tempo é dinheiro, então elas estudam métodos para a tomada dedecisã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 controledas atividades e artefatos gerados, ajudando a criar sistemas de melhor qualidade, que sãoproduzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos sãoalcançados através de um pequeno conjunto de valores, princípios e práticas, que diferemsubstancialmente 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 ocrescimento 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 determinadoitem ou serviço e os recursos necessários a esta produção, em uma escala que quando se têm maiorproduçã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 queminimiza 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 poraumentos reais de salários e pela melhoria do padrão de vida, no interesse comum do capital, dotrabalho e dos consumidores. Quando estudamos produtividade, buscamos identificar, analisar e minimizar a influênciade fatores que, de uma forma direta ou indireta, interferem para que algo indesejado distorça osresultados esperados. 4.2 Gestão de Produtividade Tendo em mente o ponto de vista da produtividade, gerir uma organização faz-seextremamente necessário hoje, devido à competição acirrada do mercado. Portanto umaprodutividade 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 à suasté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 dosrecursos 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 aexecução dos mesmos, identificando e alocando recursos humanos mais adequados, preparados ehabilidosos, resultando numa melhor qualidade do produto final de qualquer processo; Selecionar emanter os equipamentos mais adequados aos processos em questão, evitando desperdício ou falta demaquinário; Adequar as quantidades necessárias de material, evitando a falta e principalmente odesperdício.[5] Todos estes recursos além de fazerem parte do processo de produção, também geram custopara 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 osucesso, e essa tecnologia traz diversas opções ao ambiente organizacional. Os sistemas deinformação são poderosas ferramentas que as organizações vem usando para auxiliar em suaspolíticas e práticas de produtividade. Os Sistemas de informação surgiram para automatizar processos de transformar dados eminformações e, possivelmente, em conhecimento. É importante entender e definir as diferenças entredado, informação e conhecimento. Dados são valores “jogados” no sistema que não possuem sentido por si só e sãotransformados em informação apenas depois de processados, manipulados e agrupados de formaque tenham algum sentido concreto. Segundo Laudon e Laudon (2004), dados são correntes defatos 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 eusa-los. Depois dos dados processados e organizados de forma a gerar informações úteis, asinformações podem ser transformadas em conhecimento. Informação nem sempre significaconhecimento. [9] O conhecimento é o modo como a informação é interpretada e aproveitada, é um fluídocomposto por experiências, valores, informações do contexto e apreensão sobre o próprio domíniode 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 decomponentes inter-relacionados que coletam (ou recuperam), processam, armazenam e distribueminformações para a tomada de decisão e controle em uma organização, contendo informaçõessignificativas sobre pessoas, lugares e coisas dentro da organização ou em seu ambiente (Laudon eLaudon, 1996). Esses sistemas têm como objetivo auxiliar no controle da informação e na análisede 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 osprocessos, recursos humanos, forças externas e internas e/ou objetivos estratégicos da mesma, como intuito de compreender todos os eventos que envolvem a produção da empresa, assim sendopossí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 processoprodutivo e não mais a produção física. A análise da empresa é feita como uma unidade sistêmicaintegrada, 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 degeraçã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 daempresa.[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 altaqualidade, empregando a equipe de desenvolvimento (geralmente com até 12 desenvolvedores), ematividades que produzam resultados rápidos na forma de software testado, e ainda customizando oproduto de acordo com a necessidade do usuário. Os fundamentos principais da metodologia XP originaram de tradições dedesenvolvimento em Smaltalk nos meados da década de 80. Quando Kent Beck e WardCunningham 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ãoelementos centrais da cultura de Smalltalk. Fazendo com que a metodologia XP, possa serconsiderada como o modo de agir da comunidade de Smaltalk, generalizando para outrosambientes. De 1986 a 1996, Kent e Ward desenvolveram várias práticas que foram condensadas nopadrã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-senesta área a tese de Bill Opdyke “Refactoring Object-Oriented Frameworks”. Essa tese mostrou oganho que as pessoas obtinham usando a prática de Refatoração. Também em 96, Kent publicou o livro “Smaltalk Best Pratices Patterns”, que apresentavaboas técnicas de desenvolvimento, grande parte das quais foi combinada no trabalho de MartinFowler 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 asvariáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito emescopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valorpossí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 daqualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, aodiminuir 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 doisprofissionais e uma máquina, onde um profissional interage com o outro, corrigindo-o eplanejando.[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 corrigirerros.[6] Do ponto de vista da gestão, a técnica de desenvolvimento de software de extremeprogramming é voltada para alcançar níveis de produtividade muito altos, ao combinar poucosrecursos humanos, e técnicas de rápido desenvolvimento, assim podendo produzir muito, compoucos 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 aequipe de desenvolvimento sobre o universo que o software estará imerso, capacidades e limitaçõesde desenvolvimento e principalmente o levantamento de requisitos do sistema, que se fazextremamente complexo. Normalmente, o cliente não compreende ou prevê todas asfuncionalidades do sistema no nível exigido pela equipe de desenvolvimento na fase de análise derequisitos, o que gera em todos os casos, ruídos e falhas, independentes da técnica dedesenvolvimento utilizada. Então, a fase da compreensão das necessidades do cliente, é considerada uma das maisdifíceis de todo o projeto, pois é a partir dela que todos os caminhos são projetados, escopos eobjetivos são definidos, e uma vez definidos, voltar e corrigir os requisitos é uma tarefa muitocomplicada e sensível. 12
  • 13. Portando, a tática utilizada em XP é organizar ciclos curtos de feedback, onde em cadaciclo poucas funcionalidades são priorizadas e implementadas, com o intuito de possibilitar ocliente requisitar novas funcionalidades a cada ciclo, e ainda conhecer funcionalidades que já foramimplementadas, corrigindo eventuais falhas ainda um estágio onde é relativamente barato realizar ascorreçõ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 comoconceitos implícitos no contexto, e a equipe de desenvolvimento tentando compreender estasmesmas idéias, através do meio de comunicação que estiverem usando, que pode tanto complicarcomo facilitar a troca de conhecimento. Extreme Programming incentiva o envolvimento ativo dos participantes, através deencontros presenciais onde a equipe de desenvolvimento trabalha, criando meios de comunicaçãoricos 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 realmentenecessários ao projeto, assim não desperdiçando recursos humanos, tempo e dinheiro em itens quenão serão utilizados no futuro. A cada ciclo de desenvolvimento, as funcionalidades definidas são implementadas comamelhor qualidade possível, porém sem sair do escopo pré-definido, limitando-se somente aorequisitado pelo usuário. Assim evita-se as comuns “prevenções”, onde se pensa antecipar umfuturo requisito do usuário, mas com a incerteza de ser realmente uma necessidade, porque logoapó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 quecertos aspectos do projeto podem não acontecer do modo como deseja, ou não acontecer de modoalgum. Confiança não é acreditar que todos os aspectos do planejamento irão ocorrer semproblemas, e sim confiar nos mecanismos utilizados pela XP que amenizam ou eliminam osproblemas que ocorrem no decorrer do projeto. Citando Teles, as principais formas de conter erros, aumentando a confiança da equipeenvolvida 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 porduas semanas, por exemplo, todas as iterações do projeto terão sempre esta duração). Destaforma, ao final de cada iteração, é possível avaliar se a equipe implementou o que foi pedido e se oque foi pedido realmente fazia sentido. O problema não é eliminado em função do desenvolvimentoiterativo. O cliente pode ter solicitado algo errado no início da iteração ou a equipe pode terimplementado de forma incorreta, mas isso é descoberto cedo. Como a iteração é curta, poucasfuncionalidades são implementadas. Portanto, caso haja um erro, o mesmo se refere a um conjuntoreduzido de funcionalidades, o que facilita eventuais correções e evita que a equipe invista muitosrecursos 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 depagar demais por muito pouco. Ao receber funcionalidades com freqüência, em prazos curtos, ocliente passa a ter diversas oportunidades de avaliar o trabalho das 68 equipes com base emfeedback concreto: software executável. Assim ele pode decidir se continua ou não a empregaraquela equipe ou se é preferível trocar (TELES, 2004). Além disso, o feedback constante, produzidoao longo das iterações, faz com que o cliente possa saber exatamente o que está acontecendo noprojeto” (BECK & FOWLER, 2001).[1] “Finalmente, o processo de planejamento não é estático. A cada início de iteração oplanejamento 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. Issopermite 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 formanatural” (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 vinhafuncionando corretamente. Por isso, o XP adota a prática de desenvolvimento orientado a testescomo mecanismo básico de proteção. O desenvolvimento orientado a testes é uma forma de lidarcom o medo durante a programação (BECK, 2003, p.x, tradução nossa). Ele leva osdesenvolvedores a criar uma base de testes automatizados que possam ser executados toda vez queum novo fragmento de código é adicionado ao sistema. Embora isso não impeça a ocorrência deerros, representa um instrumento útil para detectá-los rapidamente, o que agiliza a correção eevita que eventuais bugs se acumulem ao longo do tempo. Os desenvolvedores temem não sabersolucionar alguns problemas e não serem capazes de se atualizar tecnicamente. O XP utiliza aprogramação em par para permitir que os membros desenvolvedores aprendam continuamente unscom os outros. Além disso, a possibilidade de contar sempre com a ajuda imediata de um colegagera 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 servecomo uma rede de proteção adicional contra eventuais erros cometidos durante a codificação denovas funcionalidades ou alteração de outras previamente existentes”(WILLIAMS & KESSLER,2003).[1] “Outra preocupação permanente dos desenvolvedores é não ter tempo suficiente pararealizar um trabalho de qualidade. O XP trata essa questão dividindo claramente aresponsabilidade por decisões técnicas e de negócio. O cliente tem soberania nas decisões denegócio. Portanto, ele decide que funcionalidades devem ser implementadas e em que ordem. Osdesenvolvedores, 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 prazosimpossíveis impostos por pessoas que não possuam a qualificação técnica para estimar o esforçode 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 indicaalgumas práticas. Há uma ligação muito forte entre as práticas, pois elas se completam, fazendocom que os pontos fracos de uma, sejam recuperados pelos pontos fortes de outra. Na seqüênciaapresentamos 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ãodesenvolvidas semanalmente. No começo de cada semana é feito uma reunião chamada de Jogo dePlanejamento, aonde o cliente e os desenvolvedores participam. O cliente tem papel fundamental nareunião, pois é nela que ele identifica as prioridades, e os desenvolvedores as estimam, com isso ocliente fica ciente do que está acontecendo, e o que irá acontecer. Como a cada começo de semana oescopo 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 cadasemana, os desenvolvedores entregam o resultado desenvolvido durante a semana toda, podendoassim 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 chegamainda ser menores que as produzidas por outras metodologias incrementais, como o RUP. Conformeessas pequenas partes vão sendo desenvolvidas, a equipe de desenvolvimento libera elas para osusuário, e os usuários já colocam elas em ação. Com isso os clientes vão tendo uma visão dosistema, e com isso auxilia muito no processo de aceitação do cliente, que já pode testar uma partedo sistema. 6.2.3 Metáfora (Metaphor) As metáforas fazem com que a comunicação entre os clientes e os desenvolvedores. Porexemplo, o conceito de rápido para um cliente de um sistema jurídico é diferente do conceito derápido para um programador experiente em controlar a comunicação de sistemas em tempo real. Porisso 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 oque 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 funcionalidadeseja implementada, sem pensar em coisas a mais. A uma grande confusão, que acaba fazendo comque os programadores cometam um erro, que é confundir código simples com código fácil. Semsempre o código mais fácil de ser implementado resultará na solução mais simples do projeto. Parater um bom andamento do XP, é bom saber distinguir o código fácil do simples, fazendo a alteraçãodo 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 aceitarum 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 foipara 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 ofoco 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 paramodificar o código, tendo livre acesso. Com isso, faz com que todos passam a conhecer todas aspartes do sistema. 6.2.10 Programação em Pares (Pair Programming) Programar em dupla em um mesmo computador. Essa dupla é composta por um iniciantena linguagem usada e uma pessoa que domine a linguagem para servir de instrutor. Sendo oinstrutor 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 ocó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 programadorestêm que seguir estas regras, com isso todo o código fonte parecerá que apenas uma pessoa odesenvolveu, 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 ocódigo para que os testes funcionem. Esta abordagem parece difícil no inicio, pois vai contra aoprocesso de desenvolvimento de muito tempo. Mas os testes unitários são fundamentais para que oprojeto mantenha sua qualidade. 6.2.13 Refatoração (Refactoring) Processo no qual permite a melhora continuada da programação, mantendo acompatibilidade 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 naversão atual do sistema. Pois demorando muito para integra-la, aumenta a possibilidade de conflitose de ocorrer erros no código fonte. A integração contínua do sistema, faz com que você semprepossa 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, paraalguns 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 ocontato da equipe de desenvolvimento com questões que não estejam ligadas à atividade diária dedesenvolvimento. Faz também o relacionamento com o cliente, fazendo com que o cliente participedo desenvolvimento ativamente e que forneça informações para que a equipe possa atender suasnecessidades, 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 XPrecomenda que essa função seja ocupada por um profissional bem preparado, para que ele oriente aequipe de modo que ela siga as boas práticas recomendadas pelo XP. Sua principal tarefa é o bomfuncionamento do processo e buscar formas de melhora-lo continuamente, o coach pode tambématuar 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 doprojeto, quando os testes não forem automatizados. O analista fornece o feedback para a equiperapidamente, logo que os eventuais erros do sistema são identificados. Fazendo com que a equipede 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 naimplementação do sistema, fazendo ele toda à parte de documentação do sistema. A equipe técnicarealiza 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 é apessoa 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 cadadesenvolvedor 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 softwareque 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. Oprojeto 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 pormanutençã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ãoligado à Coordenadoria de Administração Geral (Codage), criado em 1993 para promover umaimportante modernização da informática administrativa na USP. O DI é responsável pela criação emanutenção de softwares para agilizar o dia-a-dia de alunos, funcionários e professores, tais comoos 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 comprase pedidos no almoxarifado, e o Proteos, que acompanha o andamento dos protocolos. Todos essesSistemas são integrados. Em 2006 surgiu o interesse por Extreme Programming (XP), devido à necessidade deentrega 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 revezarentre o treinamento e o desenvolvimento do projeto. Dessa forma, mesmo com um dosdesenvolvedores em treinamento, o projeto continuava em progresso. O aprendizado do Extreme Programming se deu através de treinamento oferecido pelodiretor do departamento ao grupo, aproximadamente quatro horas, uma vez por semana. Com oprojeto já em andamento, as técnicas do XP foram sendo implantadas à medida que eramtransmitidas à equipe. 21
  • 22. 7.2 O Projeto Gestão de Frotas A Universidade de São Paulo possui atualmente - 2007 - uma frota de aproximadamente 800veículos. Esses veículos estão distribuídos entre as faculdades e instituições da USP, de acordo como seu tamanho e necessidades. Existem diversas funcionalidades e práticas que se operam sobre estes patrimônios daUniversidade. A USP possui postos de gasolina, entre eles um no Campus da Capital (PCO), noCampus de Piracicaba e de Ribeirão Preto, destinados ao abastecimento de seus veículos e, alémdisso, possui convênios com outros postos, para abastecimentos externos. Um dos motivos é aexistência de motores movidos a gás natural veicular. O Campus Armando de Salles Oliveira possuiuma oficina própria, localizada na Prefeitura do campus da Cidade Universitária (PCO). Essaoficina 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 econtrole 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 softwaresdesagregados, que não compartilhavam informações. As práticas, além de terem alta carga detrabalho, duplicação de tarefas, se mostravam ineficazes e ineficientes. Para saber quantos ônibusestavam atuando no percurso de Circular, no Campus da Capital, era necessário ir até oestacionamento 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 condutorrealizou no mês, eram onerosas e lentas. Por essas razões, entre diversas outras, a USP decidiu investir na aquisição de um softwarede Gestão de Frotas, que atendesse às suas demandas. Mas, como os softwares apresentados pelomercado não foram completamente aceitos, resolveu-se que o desenvolvimento do software seria dapró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ôniosda 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 implementadopor 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 grandeparte 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 umcontribua 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ésde reuniões com usuários e clientes, a equipe definia os requisitos, fixava as prioridades e guiava oprojeto. O time possuía quatro programadores, os quais também absorveram a tarefa de ajudar ocliente a definir os testes de aceitação e os requisitos. Além destes, existia um gerente que proviarecursos, mantinha a comunicação externa e coordenar as atividades. Nenhum destes papéis foinecessariamente de propriedade exclusiva de um só indivíduo. Todos os membros do timecontribuí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 entrena sala da equipe deve conseguir obter, em poucos segundos, uma noção clara de como está oandamento do projeto. Um dos primeiros passos na implantação do XP e talvez a mais visível de todas as práticasfoi à aquisição de um quadro de avisos. Os cartões são colocados na parede, nesse mural, de modoque possam ser acompanhados facilmente por todos os participantes do projeto, incluindodesenvolvedores, gerentes, clientes, entre outros. Existem softwares que procuram ajudar noplanejamento 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 tornarevidente 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 alheiasao projeto, surgiu mais uma divisão no quadro: Externas. Foram preenchidos pequenos cartões para serem anexados nessas áreas. Cada cartãocontinha o nome da tarefa, uma descrição e a quantidade de tempo que se presumia levar para otérmino da mesma. A escolha de quais seriam as tarefas e o tempo geralmente eram definidossemanalmente após reuniões. Partindo-se dos princípios de que nenhuma tarefa leva menos de duas horas para sercompletada, já que podem surgir dificuldades no caminho, e de que uma tarefa que leve mais dedois dias para ser concluída deve ser dividida em outras menores, a equipe adotou as seguintesmetá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 deprioridade. O membro da equipe escolhe uma tarefa e atribuí ao seu nome. Dessa forma é possívelvisualizar rapidamente quem está ocupado e com o que se está trabalhando no momento. Issotambém evita que mais de uma pessoa esteja trabalhando sobre um mesmo arquivo. Odesenvolvedor 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 aquantidade 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 deesferas que foram necessárias para a conclusão das tarefas, é gerado um gráfico que mede a relaçãoda produção que se esperava ter da equipe na semana e a que realmente ocorreu. A tendência seria aequipe descobrir qual a quantidade de esferas (tempo total) que se deveria prever semanalmentepara 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 emsituações especiais. Devido ao fato de a equipe ter aprendido a trabalhar com as diversasferramentas, como PHP e Sybase, somente com o decorrer do processo, tornou-se necessário queaqueles mais experientes nos métodos se sentassem com aquele que necessitasse de auxílio. Dessaforma, além da transferência de conhecimento para futuras tarefas, houve um aumento daprodutividade 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çãoe implantação. Isso se deu através de sucessivas reuniões, às vezes semanais, a medida que surgiamnecessidades 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 eadaptando-se a interface conforme os critérios definidos por aqueles que antes trabalhavam commétodos não informatizados. À medida que o sistema era desenvolvido, testado e implantado, o cliente expunha suasnovas 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. Nessasreuniõ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 aequipe 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, odesenvolvedor testava todas as suas funções. Seu trabalho era repassado ao coach que entãocolocava 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áriofinal. Isso preveniu erros e diminuiu a carga de trabalho gerada quando o usuário encontra erros nosistema 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 eranecessário esperar por outros desenvolvedores sempre que havia a necessidade de editar um arquivodo sistema. Além disso, o revezamento entre as diversas funcionalidades permitiu que osdesenvolvedores 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 aimplementação, os membros da equipe transmitiam seus códigos para o coach, que os agregavacom 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 dosistema. Isso foi muito útil para as práticas de código coletivo e da programação em par. Ambasajudaram a assegurar que os desenvolvedores aderissem aos padrões. Uma parte da padronizaçãofoi baseada em um documento do Departamento de Informática que regula o uso de siglas emsistemas, como a criação de banco de dados. Esse documento contém uma lista de palavras e suasrespectivas siglas, com três letras. Como muitas palavras, como pneu, eram específicas e nãoestavam presentes na documentação, a equipe também passou a criar siglas padronizadas para essaspalavras. Entre outras utilizações dessas siglas, pode-se citar o caso de nomeação de campos detabelas e a nomenclatura das diversas variáveis presentes no sistema. Os nomes das páginas webtambém foram padronizados. Códigos semelhantes, como consultas ao banco de dados e scripts, foram agregados emarquivos 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 naarquitetura 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 criavamecanismos para sustentar a construção futura dos mesmos. A equipe se focava basicamente nas tarefas que estavam sendo implementadas, não sepreocupando com futuras funcionalidades. Isso se mostrou vital a partir do momento que novasnecessidades 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 tarefase 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 doprojeto. Foram utilizadas figuras como peças, pneus e ferramentas nas funcionalidades de ordem deserviços para reparos em oficinas. Outro ponto foi a transposição do processo de preenchimento dopapel 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 deforma mais inteligente. A equipe de desenvolvimento trabalhou das 8h às 19h, devido à diferençaentre turnos dos membros. Contudo, o que se mostrou primordial foi a força, inteligência esustentabilidade que os membros desempenharam no decorrer do processo. Métodos como o doquadro de avisos ajudaram a focar o trabalho no necessário. Com um ritmo de produção constante oprojeto foi se encaminhando. Porém houveram ocasiões em que foram necessárias estender a jornada de trabalho dealguns 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 é feitoum documento levantando, entre outros, os requisitos e cases do software a ser desenvolvido. Como XP esse escopo não é fixo. Assim o cliente pode fazer ajustes, os desenvolvedores têm a liberdadepara questionar funcionalidades e propor o que é mais prioritário. O escopo negociável tevefacilidade 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çãopú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. Oenvolvimento do todos os membros da equipe, juntamente com o apoio dos próprios clientes doprojeto, 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 queessa metodologia pode se tornar uma tendência nas outras equipes de desenvolvimento dentro doDepartamento de Informática da USP. O próximo passo seria a implantação total de todas asprá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 eousadia foram marcantes no processo. Segundo o coach da equipe, “O resultado só não foi melhordevido à necessidade inicial da equipe no método de desenvolvimento XP.”. Ele prevê que oresultado será aprimorado nos futuros projetos. Parte da equipe possuía trabalhos externos a seremrealizadas. Isso muitas vezes onerou sobre a dedicação exclusiva. Outro ponto que atrapalhou oandamento inicial foi a falta de conhecimento de parte dos desenvolvedores sobre as linguagens deprogramação utilizadas. Porém, a aplicação do XP, os treinamentos oferecidos e a prática obtidacom o projeto tornaram a equipe capacitada para enfrentar novos desafios, afrontar tendências eacolher 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 demonitoramento e controle, e sistemas de apoio administrativos, é evidente que a essência dasorganizações está não só ligada, como também dependente da tecnologia, como uma ferramenta quepotencializa um alto índice de produtividade dentro da empresa. Através dos estudos realizados, notamos que eXtreme Programming é uma técnicaaltamente produtiva e confiável, porém que só pode ser empregada em certos projetos ounecessidades 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 aprodutividade 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óriapara o cliente. Há um alto índice de produtividade, devido ao baixo custo de tempo de implementação emXP, 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 equalidade do produção quanto na facilidade de gestão de todo o processo que se decorreu no casoavaliado por esse estudo. Com a aplicação das diferentes práticas, o Departamento de Informáticada 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 asgrandes virtudes do desenvolvimento do Projeto Gestão de Frotas. O XP se mostra como umaferramenta útil, simples e barata, que poderá transformar os velhos dogmas presentes nas equipes dedesenvolvimento de softwares. 31
  • 32. 9. Bibliografia 1 - Teles, V. M., Um estudo de caso da adoção das práticas e valores do extremeprogramming, 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 em23/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_empresas.pdf - Último acesso em 23/06/2007 5 - Geranegócio - www.geranegocio.com.br/html/geral/p13.html – Último acesso em23/06/2007 6 - Medeiros, M. P., Implementando Pair Programming em sua equipe - Conhecendo asdificuldades 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 Tecnologiahttp://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 andTechnology. 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, INTERCOMRevista Brasileira de comunicação, 1994. 32