Universidade Estadual de Maring Centro de Tecnologia - Departamento de Informtica Especializao em Desenvolvimento de Sistemas para Web - Turma 8

EVERTON ANTONIO RAMOS

METODOLOGIAS GEIS: EXTREME PROGRAMMING (XP)

Um exemplo de aplicao em uma empresa do setor de leo e gs

MONOGRAFIA DE ESPECIALIZAO

MARING - PR 2013

EVERTON ANTONIO RAMOS

METODOLOGIAS GEIS: EXTREME PROGRAMMING (XP)

Um exemplo de aplicao em uma empresa do setor de leo e gs

Trabalho submetido Universidade Estadual de Maring como requisito parcial para obteno do ttulo de Especialista em Desenvolvimento de Sistemas para Web. Orientador: Prof. MSc. Gcen Dacome de Marchi

MARING - PR 2013

TERMO DE APROVAO

METODOLOGIAS GEIS: EXTREME PROGRAMMING (XP)

Um exemplo de aplicao em uma empresa do setor de leo e gs

por

Everton Antonio Ramos

Esta monografia foi apresentada s 14:00 do dia 18 de janeiro de 2013, como requisito parcial para a obteno do ttulo de Especialista em Desenvolvimento de Sistemas para Web pelo Departamento de Informtica da Universidade Estadual de Maring. O candidato apresentou o trabalho para a Banca Examinadora composta pe-

los professores abaixo assinados. Aps a deliberao, a Banca Examinadora considerou o trabalho ________________________.

Prof. MSc. Gcen Dacome de Marchi (Orientador) (UEM)

Prof. MSc. Munif Gebara Junior (UEM)

Prof. MSc. Flvio Rogrio Uber (UEM)

DEDICATRIA
A meus filhos Heitor e Mariana, que tenham a opo e a escolha das prprias forma es. Aos amigos que fiz durante esta especializao e que ajudaram a vencer os desafios para alcanar mais esta conquista.

AGRADECIMENTOS
Agradeo enormemente minha me, Prof. Maria Jos Pereira Ramos, por nunca ter deixado de lutar para que seus filhos recebessem a melhor educao e tivessem as melhores oportunidades. Agradeo a UNIBRASPE por confiar, acreditar e viabilizar todos os recursos necessrios para que o projeto fosse bem sucedido. Agradeo a todos os envolvidos, em especial ao Josiel, que desde o incio acreditou no projeto e que sempre esteve presente e disposto para tirar dvidas e orientar sobre os procedimentos.

EPGRAFE
No necessrio pintar um grande quadro ou fazer uma grande descoberta para ser criativo, porquanto criativos so todo pensamento e toda ao que nos sublimam, afastando-nos dos instintos arcaicos e tornandonos mais humanos. GIACOMO DAQUINO

RESUMO
Este trabalho aborda o uso da metodologia de desenvolvimento gil XP em uma empresa brasileira do setor de leo e gs. Uma pesquisa exploratria e qualitativa buscou analisar a aplicao dos valores, prticas e princpios da metodologia na implementao de um projeto na empresa. Foram analisados os desafios, benefcios e adaptaes que foram necessrias para sua aplicao e os resultados alcanados. Palavras-chave: Engenharia de software, Metodologias geis, Programao extrema, XP, Valores, Prticas, Princpios.

ABSTRACT
This work discusses the use of agile development methodology XP in a oil and gas company. An exploratory and qualitative research sought to analyze the application of the values, practices and principles of the methodology to implementing a project in the company. We considered the challenges, benefits and adjustments that were necessary for its implementation and the results achieved. Keywords: Software engineering, Agile methodologies, Extreme programming, XP, Values, Practices, Principles.

LISTA DE ILUSTRAES
Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Ciclos de planejamento e feedback Prticas da Extreme Programming Tela padro para buscas Tela padro para inseres/alteraes Ambiente de trabalho Pgina 18 20 27 28 29

LISTA DE TABELAS
Tabela 1 Tabela 2 Tabela 3 Prticas da XP na UNIBRASPE Tabela 4 Tabela 5 Princpios da XP na UNIBRASPE Princpios do Agile Manifesto na UNIBRASPE 33 34 Principais papeis na XP Valores da XP na UNIBRASPE 31 Pgina 17 30

LISTA DE ABREVIATURAS E SIGLAS

ERP FDD MVC OC OOP REPAR SACC SGBD TDD XP Enterprise Resource Planning (Sistema Integrado de Gesto Empresarial) Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) Model View Controller (Modelo Viso Controle) Ordem de Carregamento Object-Oriented Programming (Programao Orientada a Objetos) Refinaria Presidente Getlio Vargas Sistema de Administrao e Controle de Combustveis Sistema de Gerenciamento de Banco de Dados Test Driven Development (Desenvolvimento Orientado a Testes) Extreme Programming (Programao Extrema)

SUMRIO
1. Introduo 2. Fundamentao Terica 2.1 Engenharia de Software 2.2 Surgimento dos Mtodos geis de Desenvolvimento de Software 2.3 Surgimento da Extreme Programming 2.4 Agile Alliance 2.5 Agile Manifesto 3. Extreme Programming 3.1 Valores da Extreme Programming 3.2 Prticas da Extreme Programming 3.3 Princpios da Extreme Programming 3.4 Quando no Utilizar a Extreme Programming 4. Exemplo de Aplicao da Extreme Programming 4.1 Empresa UNIBRASPE 4.2 Projeto 4.3 Valores da XP na UNIBRASPE 4.4 Prticas da XP na UNIBRASPE 4.5 Princpios da XP na UNIBRASPE 4.6 Princpios do Agile Manifesto na UNIBRASPE 5. Apresentao e Discusso dos Resultados 5.1 Aplicao dos Valores, Prticas e Princpios 5.2 Desafios 5.3 Benefcios 5.4 Adaptaes 6. Consideraes Finais Referncias Bibliogrficas Pgina 13 14 14 14 14 15 15 17 18 19 22 23 25 25 25 30 31 33 34 37 37 37 38 38 40 41

14

1. Introduo
Desde a criao da linha de pesquisa engenharia de software na dcada de 1960 a indstria de software busca tcnicas para reduzir os riscos e aumentar a produtividade. O desenvolvimento de software em cascata ou ciclo de vida do software foi o primeiro grande avano, este modelo focado no planejamento e documentao, seguindo passos rigorosos desde o levantamento de requisitos, anlise, projeto, codificao, testes e manuteno (SOMMERVILLE, 2007). No modelo gil, se enfatiza a obteno de funcionalidades executveis que possam ser agregadas e disponibilizadas aos usurios no menor tempo possvel, porm no significa negligenciar as atividades da engenharia de software, apenas pratic-las de forma no convencional. Em 1996, Kent Beck e Ward Cunningham criaram a metodologia Extreme Programming (XP) (FIGUEIREDO, 2005), baseada numa srie de princpios e boas prticas, esta tcnica permite o desenvolvimento de forma gil, o Extreme se deve ao fato dela empregar ao extremo boas prticas da engenharia de software (BECK, 1999), sem esquecer-se do custo e qualidade. Este trabalho pretende mostrar de forma terica os valores, prticas e princpios da metodologia XP. A metodologia adotada foi um levantamento bibliogrfico em livros, artigos, trabalhos acadmicos e materiais encontrados na Internet. Para subsidiar a teoria, foi efetuada uma pesquisa exploratria e qualitativa, dentro de uma empresa brasileira do setor de leo e gs, onde a metodologia XP foi aplicada.

15

2. Fundamentao Terica
2.1 Engenharia de Software Engenharia de software a rea de conhecimento dentro da cincia da computao que estuda formas de se especificar, construir e manter software. Desde meados da dcada de 1960 tcnicas de engenharia comearam a ser usadas no de senvolvimento de software, buscando criar processos capazes de ser documentados e depois replicados.
Essas tcnicas tornaram-se parte da engenharia de software e so amplamente usadas hoje em dia. No entanto, assim como aumentou a habilidade de produzir software, cresceu tambm a necessidade por sistemas de software mais complexos. Novas tecnologias resultantes da convergncia de computadores e sistemas de comunicao, e as complexas interfaces com o usurio, impuseram novos desafios aos engenheiros de software. Como muitas empresas ainda no aplicam as tcnicas de engenharia de software de forma efetiva, muitos projetos produzem software de baixa confiabilidade, com atraso e com custo alm do oramento. (SOMMERVILLE, 2007, p. 4)

2.2 Surgimento dos Mtodos geis de Desenvolvimento de Software O surgimento dos mtodos geis de desenvolvimento de software ocorreu quando dezessete especialistas, criadores de mtodos como Extreme Programming (XP), Scrum e Feature Driven Development (FDD), delinearam princpios comuns compartilhados por todos. O resultado foi a formao da Agile Alliance e o estabelecimento do Agile Manifesto, no ano de 2001 (BECK et al., 2001). Apesar das metodologias geis terem prticas e nfases diferentes, fundamentalmente pregam o desenvolvimento leve, iterativo e incremental. 2.3 Surgimento da Extreme Programming Kent Beck, publicou em 1996 um livro com suas melhores tcnicas de programao (BECK, 1996). Foi convidado no mesmo ano para liderar um projeto na Chrysler (fabricante de veculos). O projeto j havia ultrapassado os prazos e custos sem alcanar os resultados esperados. Com o auxlio de sua equipe, Beck conse guiu entregar um sistema de qualidade, comeando do zero e terminando em menos tempo que nas tentativas anteriores. Beck agrupou tcnicas que de forma isolada j haviam demonstrado sua eficincia, multiplicando assim os resultados, surgia a a Extreme Programming. Seu objetivo era maximizar a utilizao destas tcnicas ao

16

extremo, com reviso constante do cdigo, atravs da programao em pares, testes automatizados e acompanhamento constante do projeto com o cliente presente. 2.4 Agile Alliance Em fevereiro de 2001, nas montanhas Wasatch em Utah (Estados Unidos), formou-se a Agile Alliance, uma organizao sem fins lucrativos, com o compromisso de promover princpios e prticas de desenvolvimento gil de software. Eles apoiam quem explora e aplica estes princpios, tornando a indstria de software mais produtiva, humana e sustentvel. 2.5 Agile Manifesto Na formao da Agile Alliance foi publicado o Agile Manifesto (BECK et al., 2001). Os autores, mesmo reconhecendo valor em tcnicas e princpios j consagrados na engenharia de software, declararam: Indivduos e interaes mais que processos e ferramentas; Software funcionando mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder as mudanas mais que seguir um plano. Este manifesto no se limitou a estas declaraes, foram definidos doze princpios: 1. 2. 3. 4. 5. 6. 7. 8. 9. Satisfao do cliente com entrega de software com valor agregado; Aceitao a mudanas nos requisitos, mesmo que tardiamente; Maior frequncia na entrega de software funcionando; Pessoas de negcio e desenvolvedores devem trabalhar prximas; Motivao; Comunicao face a face; Software executvel como mtrica primria de progresso; Ritmo constante e sustentvel; Excelncia tcnica;

17

10. 11. 12.

Simplicidade; Equipes auto-organizveis geram melhores resultados; Reflexo peridica.

18

3. Extreme Programming
XP uma metodologia gil para desenvolvimento de software, recomendada sua utilizao em projetos com requisitos incertos e que mudam com frequncia, que possuam equipes pequenas (mximo de doze desenvolvedores), onde o sistema possa ser desenvolvido de forma incremental (ou iterativa) e que a programao seja feita usando o paradigma da orientao a objetos (OOP).
O XP um processo de desenvolvimento que busca assegurar que o cliente receba o mximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele organizado em torno de um conjunto de valores e prticas que atuam de forma harmnica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software. (TELES, 2004, p. 21)

Na XP o foco principal o escopo, prioriza-se desenvolver as funcionalidades que agreguem o maior valor para o negcio do cliente, para isso a equipe deve reunir todas as habilidades tcnicas e de negcios para produzir o software (BASSI FILHO, 2008). Em XP existem quatro papeis principais conforme a tabela abaixo (Tabela 1): Papel Programador Funo O programador um papel chave em XP (FIGUEIREDO, 2005), a ideia que no exista hierarquia, o mesmo tem como funo codificar o sistema, na metodologia XP os programadores precisam ser experientes e qualificados. O mais experiente do time de desenvolvimento recebe o papel de coach, ele deve orientar a equipe sobre as prticas da XP, o coach no necessariamente o melhor programador e sim quem mais entende da metodologia XP. Responsvel por manter a equipe consciente do andamento do projeto, ele deve trazer informaes que ajudem a equipe a tomar decises sobre a arquitetura, design e implementao, muitas vezes o prprio coach exerce este papel. Em XP o cliente faz parte da equipe, ele deve estar sempre presente e disposto a tirar dvidas e esclarecer procedimentos. Tabela 1 - Principais papeis na XP Na XP o ciclo de planejamento e feedback (Figura 1) devem ser dirios, a equipe deve se reunir e discutir sobre os resultados e dificuldades encontradas at o

Coach (Treinador)

Tracker (Acompanhador)

Cliente

19

momento, priorizar aquilo que mais importante para o cliente e focar seus esforos para entregar software funcionando.

Figura 1 - Ciclos de planejamento e feedback Fonte: www.extremeprogramming.org

3.1 Valores da Extreme Programming Feedback: O feedback do cliente parte essencial de uma iterao (CARDOSO, 2004), atravs dele os desenvolvedores conseguem avaliar o nvel de sucesso de uma nova verso e se as funcionalidades apresentadas atenderam as expectativas dos usurios. A troca de informaes deve ser constante, isso gera uma unio e reciprocidade entre todos os membros da equipe. Comunicao (Communication): Para que exista feedback a comunicao precisa ser constante e intensa. A melhor forma de comunicao entre duas pessoas uma conversa face a face, conversas pelo telefone ou atravs de mensagens instantneas acabam no tendo a mesma eficincia. A forma como nos comunicamos tem influncia direta na compreenso da mensagem, uma conversa face a face agrega valores como gestos, expresses faciais, tom de voz, entre outros, isso acaba facilitando a transmisso da mensagem e sua compreenso (TELES, 2004).

20

Simplicidade (Simplicity): Em projetos onde os requisitos podem mudar a qualquer momento, criar funcionalidades desnecessrias s tornam o software complexo e de difcil manuteno (BECK, 1999). Todo o cdigo escrito deve ser focado em criar funcionalidades priorizadas pelo cliente e que tero seu uso de forma imediata. Fazer exatamente aquilo que o cliente precisa, da forma mais simples possvel, garante velocidade no desenvolvimento e facilidade na manuteno. Respeito (Respect): O respeito o valor que sustenta os demais, sem respeito os outros valores perdem o sentido e a aplicao da metodologia se torna in vivel. Respeitar opinies diversas, necessidades individuais, saber ouvir e ter compreenso entre todos os membros da equipe fundamental. Coragem (Courage): Por ser uma metodologia relativamente nova e ser contrria a vrios processos tradicionais de desenvolvimento de software, a adoo e aplicao exigem coragem da equipe (TELES, 2004). preciso coragem para manter o projeto simples, permitindo que o cliente priorize as funcionalidades que devero ser implementadas, aceitando mudanas constantes nos requisitos e permitindo que todos tenham acesso aos cdigos e possam modificar os mesmos a qualquer momento. 3.2 Prticas da Extreme Programming Prticas em XP so derivadas de seus valores (CARDOSO, 2004) e representam aquilo que a equipe executa diariamente (Figura 2), sua utilizao depende do contexto, conforme o contexto muda a aplicao da prtica tambm deve mudar.

21

Figura 2 - Prticas da Extreme Programming Fonte: www.xprogramming.com Cliente presente (Whole Team): Na XP a presena do cliente fundamental, as informaes que o mesmo fornece de forma rpida, permitem a obteno do mximo de valor do projeto, essencial que ele participe ativamente do processo de desenvolvimento (TELES, 2004). Jogo de planejamento (Planning Game): O objetivo do jogo de planejamento que o cliente priorize aquilo que importante para ele no momento. O mesmo des creve de forma sucinta as funcionalidades que ele deseja no sistema. O mesmo fica ciente do tempo e custo necessrio para desenvolver cada nova funcionalidade, esta prtica assegura que o trabalho seja direcionado para aquilo que mais importante para o cliente (ASTELS; MILLER; NOVAK, 2002). Pequenas verses (Small Releases): A entrega constante de pequenas verses, com novas funcionalidades, faz com que o cliente sinta confiana no projeto. O mesmo ao iniciar o uso de uma nova verso, com as funcionalidades que ele elegeu como prioritrias e que agregam valor ao negcio, produz um ambiente de colaborao, motivando toda a equipe. Metfora (Metaphor): Numa equipe multidisciplinar onde os nveis de conhecimento tendem a ser desproporcionais, ou seja, o desenvolvedor entende muito de programao e o cliente entende muito das regras de negcio, a comunicao pode se tornar complicada. O uso de metforas possibilita a transmisso de ideias de uma

22

forma mais clara e simples. Esta prtica facilita a comunicao entre o desenvolvedor e o cliente, estabelecendo um vocabulrio comum (BECK, 2004). Projeto simples (Simple Design): Quanto mais simples for o sistema, mais rapidamente o mesmo poder ser adaptado mudanas. A reduo do tempo e custo das mudanas depende de um projeto simples, ser simples no significa que o mesmo no dispe dos recursos necessrios para atender o cliente, significa que o projeto tem exatamente aquilo que o cliente precisa, no nvel de complexidade e flexibilidade necessrios naquele momento (BASSI FILHO, 2008). Ritmo sustentvel (Sustainable Pace): Pessoas cansadas no conseguem aplicar a metodologia XP, o respeito pelos limites fsicos e necessidades individuais essencial para a produo de um bom trabalho. A XP recomenda que a carga ho rria de trabalho no ultrapasse oito horas dirias e quarenta horas semanais (GONALVES JR., 2009). Posse coletiva (Collective Ownership): Todos os desenvolvedores devem ter acesso a todas as partes do cdigo, podendo efetuar alteraes naquilo que for necessrio. Esta prtica essencial para agilizar eventuais correes ou revises. Programao em pares (Pair Programming): Dois programadores, de forma coletiva, utilizam o mesmo computador para implementar determinadas funcionalidades. Esta prtica traz vrios benefcios: reviso constante do cdigo; reduo de erros; replicao de conhecimentos. As duplas devem ser trocadas frequentemente, aumentando a unio e disseminao das experincias. Padres de codificao (Coding Standard): O padro de codificao essencial para garantir uma manuteno rpida do software, o mesmo s pode ser de posse coletiva se todos da equipe entenderem o cdigo. Seguir um padro torna o cdigo homogneo, permitindo manutenes rpidas e seguras (TELES, 2004). Desenvolvimento orientado a testes (Test Driven Development): Testes so escritos para cada funcionalidade, antes de codific-las, isto obriga um planejamento das interfaces, classes e mtodos, esta prtica gera uma massa de testes que pode ser usada a qualquer momento para validar todo o sistema (TELES, 2004). Refatorao (Refactoring): Consiste em organizar o cdigo fonte de um software, melhorando sua qualidade e facilitando o processo de manuteno. Isso

23

fundamental para tornar o cdigo mais legvel e detectar possveis erros (GONALVES JR., 2009). Integrao contnua (Continuous Integration): Logo aps terminar determinada rotina, o programador deve integr-la ao projeto principal. Isso deve ser feito vrias vezes ao dia, visando a sincronizao das atividades individuais (BECK, 2004).
Depois de algum tempo, adeptos de XP perceberam que simplesmente aplicar todas as prticas, sem considerar os princpios e valores por trs delas no era uma abordagem efetiva. O que faz sentido, de acordo com a prpria filosofia que XP segue: mtodos geis devem ser adaptativos e no-prescritivos. Esta observao levou criao de uma nova prtica, chamada Conserte XP quando ela no funciona, que sugere que quando no for possvel aplicar XP em sua totalidade, as prticas devem ser adaptadas de acordo com o ambiente. Desta forma, as prticas de XP no devem ser vistas como dogmas, mas como orientaes para organizar o comportamento da equipe e como base para reflexo contnua. (BASSI FILHO, 2008, p. 57)

3.3 Princpios da Extreme Programming Uma caracterstica dos mtodos geis de desenvolvimento de software que sua aplicao varia conforme o contexto encontrado. Mesmo assim, estas variaes so direcionadas atravs de uma srie de princpios (OLIVEIRA, 2012). Feedback rpido (Fast feedback): O tempo decorrido aps a implantao de uma nova funcionalidade e o feedback do usurio fundamental para a aprendizagem (CASADEI; LODDI; PEREIRA; SOUZA, 2010), facilitando a correo de problemas e ajustes necessrios para melhorar o uso do software. Presumir simplicidade (Assuming simplicity): Um sistema grande e complexo formado por partes pequenas e simples, desenvolvedores tradicionalmente so orientados a planejar para o futuro visando o reuso, a XP orienta que o esforo de desenvolvimento seja direcionado para resolver o problema atual, da forma mais rpida e simples possvel (BECK, 2004). Mudanas incrementais (Incremental changes): A busca pela soluo mais simples fora a equipe a estar preparada para mudanas constantes. A evoluo do projeto e entendimento do problema acabam gerando alteraes nos requisitos e escopo, a equipe deve estar preparada para estas mudanas, executando as mesmas no menor tempo e custo possvel (MACEDO, 2009).

24

Abraar mudanas (Embracing changes): Desenvolvedores geralmente no lidam bem com mudanas de requisitos ou escopo, porm estas mudanas devem ser encaradas como a oportunidade de tornar o cliente mais competitivo, entregando software que ser til e que atende as necessidades atuais. Trabalho de alta qualidade (High quality work): Qualidade no um fator negocivel, ela deve ser uma meta, o aumento da qualidade traz mais motivao para os membros da equipe, satisfaz o cliente e facilita novas implementaes (BASSI FILHO, 2008). 3.4 Quando no Utilizar a Extreme Programming A metodologia XP recomenda formas simplificadas e eficazes de desenvolvimento de software, aplic-las em equipes que no fazem uso de processos geis no fcil, e muitas vezes impossvel. As dificuldades no so de ordem tcnica e sim culturais (BECK, 2004).
Naturalmente, h alguns tipos de sistemas nos quais o desenvolvimento e a entrega incrementais no so a melhor abordagem. Esses so sistemas muito grandes, nos quais o desenvolvimento pode envolver equipes que trabalham em locais diferentes; alguns sistemas embutidos; nos quais o software depende de desenvolvimento de hardware e alguns sistemas crticos, nos quais todos os requisitos devem ser analisados quanto a interaes que possam comprometer a segurana do sistema. (SOMMERVILLE, 2007, p. 261)

Quem pode e deve decidir se um projeto pode utilizar XP voc, no entanto existem alguns fatores que provavelmente faro XP no funcionar. 1. 2. 3. 4. 5. 6. 7. 8. 9. Exigncia de especificao/anlise/projeto completo antes de comear; Projetos com escopo fechado; Necessidade de fazer horas extras constantemente; Dificuldade de comunicao entre a equipe/cliente ( feedback); Equipes grandes ou distantes; Equipes alheias a mudanas; Desenvolvedores de baixa qualidade; Poltica de premiaes individuais; Ambiente fsico inadequado;

25

Os limites exatos da XP ainda no esto claros. Porm, existem alguns estraga prazeres que fazem a XP no funcionar; grandes times, clientes desconfiados, tecnologias que no suportam elegantemente as modificaes. (BECK, 2004, p. 151)

26

4. Exemplo de Aplicao da Extreme Programming

As informaes e dados desta seo foram coletadas pelo prprio autor, um dos desenvolvedores e responsvel pelo projeto dentro da empresa. 4.1 Empresa UNIBRASPE Em 2000 foi fundada a Unibraspe Brasileira de Petrleo S/A, suas operaes comearam em janeiro de 2003, a mesma fica estrategicamente localizada ao lado da Refinaria Presidente Getlio Vargas (REPAR) em Araucria - Pr. Sua principal atividade o armazenamento de derivados de petrleo e biocombustveis, sendo considerada uma base primria onde seus clientes (distribuidoras) retiram os produtos que podem ser encaminhados para outras bases (secundrias) ou diretamente para os postos de abastecimento. 4.2 Projeto A empresa no incio de 2010 implantou um sistema integrado de gesto empresarial (ERP) da TOTVS chamado Microsiga Protheus em sua verso 10. O sistema contemplava todos os departamentos da empresa, porm o controle de estoque de terceiros e faturamento, atividade que demandava grande esforo e considerada estratgica, no atendia as necessidades da empresa e precisava ser desenvolvido em separado. A empresa contratou a prpria TOTVS, proprietria do ERP para desenvolver e adaptar o sistema, porm o projeto no obteve xito. Em outubro de 2011 a empresa optou por deixar o seu prprio departamento de informtica responsvel pelo projeto. O departamento era recm-formado, no demandava de muitos profissionais e tinha muito pouco conhecimento sobre os requisitos do projeto. Aps um levantamento de requisitos, atravs de entrevistas com os responsveis do setor, foram definidas as primeiras diretrizes do projeto, entre elas que o mesmo seria feito usando a metodologia XP. A primeira ao efetiva foi transferir os desenvolvedores para o setor, ficando na mesma sala que os responsveis pela superviso, administrao e faturamento.

27

Detalhes tcnicos e qual seria o papel do cliente na metodologia no foram detalhados ao cliente, isso poderia causar algum tipo de resistncia ou mudar o seu foco de trabalho. A princpio o sistema que seria desenvolvido parecia ser muito simples, o principal negcio da UNIBRASPE armazenar e devolver combustveis. A armazenagem ocorre de duas formas, a principal o recebimento dutovirio, os clientes (distribuidoras) da UNIBRASPE compram gasolina e diesel da REPAR. Diariamente a REPAR bombeia os produtos comprados que so armazenados nos tanques da UNIBRASPE. A segunda forma de armazenagem rodoviria, as distribuidoras compram biocombustveis (biodiesel e etanol) de usinas e transportam at a UNIBRASPE onde so armazenados. Para armazenar os produtos a distribuidora precisa emitir uma nota fiscal de armazenagem. Para retirar o combustvel a distribuidora emite uma ordem de carregamento (OC), nesta ordem constam o nome do motorista, dados do veculo e quais produtos sero carregados. Esta OC precisa ser lanada no sistema, que indica se a distribuidora possui estoque suficiente, autorizando assim o procedimento de carregamento. Na sada do veculo, o sistema deve emitir uma nota fiscal de devoluo de armazenagem, encerrando assim o processo. Com a equipe formada, decises tcnicas foram tomadas, entre elas a escolha da linguagem de programao e sistema de gerenciamento de banco de dados (SGBD). Optou-se por utilizar Java (http://www.oracle.com/technetwork/java/index.html) como linguagem de programao e MySQL (http://www.mysql.com/) como SGBD, devido a flexibilidade de ambos e por ser de conhecimento tcnico dos desenvolvedores. Foi definido tambm que o sistema seria desenvolvido utilizando a arquitetura Model View Controller (MVC), devido a possibilidade de desenvolver, editar e testar cada parte separadamente. O sistema precisava de duas vises, uma viso desktop utilizada internamente pela UNIBRASPE e uma viso web, para que os clientes da UNIBRASPE tivessem acesso a alguns relatrios e funes do sistema. J ambientados no novo setor e com as definies tcnicas estabelecidas, iniciou-se a primeira reunio, para saber quais eram as prioridades e iniciar o desen-

28

volvimento. De forma natural e descontrada o cliente elegia os pontos fundamentais do projeto, priorizando aquilo que era mais importante e necessrio no momento. Ficou evidenciado logo no incio que o setor tinha muita dificuldade com a emisso de notas fiscais e o controle de estoque de terceiros, porm, para chegar ao ponto de emitir uma nota fiscal, muitas outras rotinas precisavam ser desenvolvidas, entre elas alguns cadastros essenciais. 1. 2. 3. 4. Cadastro de clientes; Cadastro de motoristas; Cadastro de veculos; Cadastro de produtos;

Aps a definio de um layout extremamente simples para as telas de cadastro, foram executados testes funcionais e o incio do desenvolvimento. Todos os cadastros teriam no mnimo duas telas, uma tela inicial para efetuar buscas (Figura 3) e outra tela para inserir ou alterar registros (Figura 4).

Figura 3 - Tela padro para buscas

29

Figura 4 - Tela padro para inseres/alteraes Aps o desenvolvimento dos principais cadastros, foi entregue a primeira verso do sistema, esta verso consumiu uma semana de trabalho, neste momento a metodologia XP mostrou sua fora atravs do feedback dos usurios, os mesmos iniciaram imediatamente o uso do sistema e com o incio dos cadastros, logo apontaram melhorias e solicitaram novos recursos. No incio, a entrega de verses era constante, as vezes ocorrendo vrias vezes no mesmo dia, com o passar do tempo as entregas se estabilizaram em torno de uma semana. A proximidade com o cliente s trazia benefcios, desde a convivncia no setor, acompanhamento dos processos e entendimento cada vez maior das necessidades e dificuldades enfrentadas diariamente, com isso surgia a proposta de solues e mudanas, novamente o feedback constante mostrava o seu valor. Porm, era preciso priorizar, era necessrio entregar software funcionando semanalmente, reunies de priorizao ocorriam de forma natural e expontnea, o cliente apontava sua necessidade e o incio do desenvolvimento era praticamente imediato. No dia 02 de janeiro de 2012 o sistema recm batizado de Sistema de Administrao e Controle de Combustveis (SACC) emitia sua primeira nota fiscal,

30

ou seja, em pouco mais de um ms a principal necessidade do cliente foi atendida. O sistema literalmente no tinha nenhum relatrio ou recurso desnecessrio, e convergia para uma nica ao, que era emitir a nota fiscal. O uso da metodologia evolua diariamente, se tornando uma rotina, da mesma forma que os desenvolvedores se sentiam parte integrante do setor, os colaboradores do setor, se sentiam parte do time de desenvolvimento. O ambiente de trabalho (Figura 5) foi decisivo na aplicao da metodologia, a facilidade de comunicao e a convivncia diria com o cliente, proporcionaram um entendimento melhor sobre as regras de negcio e uma grande unio da equipe, direcionando todos os esforos para implementar um software de qualidade.

Figura 5 - Ambiente de trabalho

31

4.3 Valores da XP na UNIBRASPE A tabela 2 ilustra os valores da metodologia XP, a adoo durante o projeto e a justificativa para sua adoo ou rejeio. Adota: SIM / NO / PARCIAL SIM

Valor

Justificativa

Comunicao

O sucesso do projeto e sua agilidade diretamente proporcional a interao da equipe e facilidade de comunicao da mesma. Todos os membros da equipe devem estar prximos, de preferncia na mesma sala e ter a liberdade de se comunicarem quando quiserem, isto permite que todos acompanhem o andamento do projeto e possam dar contribuies de forma natural e expontnea. Aquilo que o cliente quer geralmente muito mais simples e objetivo do que o desenvolvedor imagina, para atender o cliente rapidamente necessrio manter o projeto simples e codificar apenas o necessrio. Os comentrios sobre uma deciso tomada ou sobre os recursos de uma nova verso devem ser rpidos e de conhecimento de todos, a equipe deve ter conscincia do que est acontecendo. A alterao de cdigo em produo e o comprometimento com prazos, sem causar bugs, exige muita coragem e responsabilidade. Todos tm importncia dentro da equipe e agregam valor ao projeto, cada opinio ou ponto de vista era analisado e discutido, at que um entendimento fosse encontrado.

Simplicidade

SIM

Feedback

SIM

Coragem

SIM

Respeito

SIM

Tabela 2 - Valores da XP na UNIBRASPE

32

4.4 Prticas da XP na UNIBRASPE A tabela 3 ilustra as prticas da metodologia XP, a adoo durante o projeto e a justificativa para sua adoo ou rejeio. Adota: SIM / NO / PARCIAL SIM

Valor

Justificativa

Jogo de planejamento

O processo de priorizao precisava ser constante, o tempo todo o cliente identificava prioridades e os desenvolvedores estimavam e questionavam se aquilo realmente precisava ser feito naquele momento e daquela forma. A entrega constante de pequenas verses, trouxe segurana ao cliente, que j podia fazer testes e utilizar os recursos disponibilizados. Conversas francas sobre a realidade dos processos e como o desenvolvimento de software funcionava, de uma forma que o cliente entende-se e dentro da realidade do mesmo. O foco do projeto era atender o cliente no menor tempo possvel, desenvolver exatamente aquilo que ele precisava, da forma mais enxuta e rpida possvel. A equipe era multidisciplinar e engajada, era necessrio extrair o melhor de cada membro, direcionando os esforos para o bem do projeto. Aps cada entrega de verso era necessrio que o cliente efetua-se um conjunto de testes, aps sua aceitao, a nova verso entrava imediatamente em produo. O foco era um trabalho de qualidade, fazer um grande nmero de horas extras pode exaurir os membros da equipe, no incio o nmero de horas trabalhadas foi muito grande, com o tempo a equipe encontrou um ritmo saudvel e sustentvel. Nem todas as reunies eram em p, o ambiente de trabalho (Figura 5) propiciava a comunicao constante entre os membros da equipe, facilitando e incentivando o feedback. O cdigo era da equipe, qualquer um podia alterar o mesmo, isso facilitou o processo de refactoring, incluso de novos recursos e eliminao de bugs.

Pequenas verses

SIM

Metfora

SIM

Projeto simples

SIM

Time coeso

SIM

Testes de aceitao Ritmo sustentvel

SIM

PARCIAL

Reunies em p

PARCIAL

Posse coletiva

SIM

33

Valor

Adota: SIM / NO / PARCIAL PARCIAL

Justificativa

Programao em pares

A prtica s era usada em rotinas mais complexas, para elaborao de alguns testes automatizados e definio de layouts. Desde o incio os desenvolvedores definiram os padres de codificao, como o projeto foi feito em Java este processo foi facilitado, seguindo padres j definidos e comumente usados pelo mercado. Os desenvolvedores no se sentiam confortveis em aplicar esta prtica (TDD), os testes eram criados aps a codificao das rotinas. A refatorao era uma prtica constante e necessria para criar cdigo limpo e reaproveitvel. A integrao era praticamente instantnea, toda nova rotina tinha que ser integrada ao sistema, no menor tempo possvel e j participar dos testes para poder fazer parte da prxima verso.

Padres de codificao

SIM

Desenvolvi-mento orientado a testes Refatorao

NO

SIM

Integrao contnua

SIM

Tabela 3 - Prticas da XP na UNIBRASPE

34

4.5 Princpios da XP na UNIBRASPE A tabela 4 ilustra os princpios da metodologia XP, a adoo durante o projeto e a justificativa para sua adoo ou rejeio. Adota: SIM / NO / PARCIAL SIM

Valor

Justificativa

Feedback rpido

A troca de informaes entre os componentes da equipe foi fundamental para o sucesso do projeto, com a proximidade dos componentes esta troca era muito rpida, facilitando assim o direcionamento dos esforos e resoluo de problemas. Grande parte do trabalho era encontrar a maneira mais simples e rpida de fazer aquilo que o cliente realmente precisava. O projeto era incremental, a dificuldade era priorizar aquilo que o cliente necessitava e que agregaria maior valor ao negcio. Conforme o cliente comea a utilizar o software, ele acaba percebendo que determinadas funes poderiam ser feitas de outra forma ou que poderiam incluir ou excluir etapas/dados. Mudanas legais ou exigncias do mercado, tambm geram mudanas no sistema. Aceitar estas mudanas e efetuar as mesmas no menor tempo possvel, agrega valor ao software e torna o cliente mais competitivo. A equipe de desenvolvimento precisava ser experiente e ter domnio sobre as ferramentas que foram utilizadas.

Presumir simplicidade Mudanas incrementais Abraar mudanas

SIM

SIM

SIM

Trabalho de alta qualidade

SIM

Tabela 4 - Princpios da XP na UNIBRASPE

35

4.6 Princpios do Agile Manifesto na UNIBRASPE A tabela 5 ilustra os princpios do Agile Manifesto, se o mesmo contribuiu para o projeto e a viso da equipe sobre o mesmo. Contribuiu: SIM / NO / PARCIAL SIM

Valor

Viso da Equipe

Satisfao do cliente com entrega de software com valor agregado Aceitao a mudanas nos requisitos, mesmo que tardiamente

O cliente alm de ter o desejo de ver o software funcionando e poder us-lo, se sentia parte do time de desenvolvimento, provavelmente pela proximidade com os desenvolvedores e pelo foco dos mesmos em entregar o software com os recursos solicitados. Refazer rotinas e ver que tempo foi perdido, no agrada um desenvolvedor, porm isto era visto de forma positiva, surgia a oportunidade de melhorar uma rotina e agregar mais valor ao software, alm de tornar o cliente mais competitivo, adequando sua ferramenta em menos tempo que os concorrentes. Entregar software funcionando semanalmente, era o principal objetivo do time de desenvolvimento e trazia benefcios imediatos, desde a validao dos mesmos com testes funcionais, a comunicao dos usurios com elogios e crticas sobre os novos recursos. Esta foi a primeira ao dentro do projeto e com certeza a mais acertada, a proximidade entre desenvolvedores e cliente aproximou os mesmos, fazendo com que os desenvolvedores focassem seus esforos na automatizao e melhoria dos processos do setor e os clientes se sentissem confiantes, colaborando e incentivando o desenvolvimento do software. Desde o incio a motivao da equipe era enorme, o ambiente agradvel, com todo o suporte e recursos necessrios, contribuiu de forma decisiva para manter a equipe motivada e engajada no sucesso do projeto. A proximidade das equipes tornou o ambiente descontrado e colaborativo, quando surgia uma dvida sobre o projeto a mesma era discutida e sanada imediatamente, tanto os desenvolvedores como o cliente se sentiam confortveis em perguntar e argumentar sobre o projeto a qualquer momento.

SIM

Maior frequncia na entrega de software funcionando Pessoas de negcio e desenvolvedores devem trabalhar prximas

SIM

SIM

Motivao

SIM

Comunicao face a face

SIM

36

Valor

Contribuiu: SIM / NO / PARCIAL SIM

Viso da Equipe

Software executvel como mtrica primria de progresso

No princpio, a alta gerncia da empresa acompanhava de forma desconfiada o progresso do projeto, solicitava a criao de cronogramas, documentao e reunies de alinhamento, com o passar do tempo, eram comunicadas sobre a liberao de uma nova verso, participavam do processo de homologao e j se sentiam seguros que o software estava progredindo. Os primeiros dias no foram fceis, a empresa opera em dois turnos, ou seja, nosso cliente estava presente no setor em mdia durante dezesseis horas/dia. A participao de todos era essencial, chegou-se a trabalhar doze horas por dia, as vezes alternando os turnos, as vezes passando pelos dois turnos. A empresa trabalha com horrio flexvel, isso facilitou muito a adaptao, com o passar do tempo, o ritmo de trabalho se estabilizou de forma sustentvel. A equipe de desenvolvedores era muito experiente e focada na excelncia tcnica e bom design, isso colaborou muito para a agilidade e progresso do projeto. No existia tempo para desenvolver frescuras, cada linha de cdigo deveria ser til e estar disponvel para o cliente no menor tempo possvel. Eliminar do projeto aquilo que no era necessrio ou que poderia ser feito em outro momento era essencial. A cada novo desafio a prpria equipe se reunia e buscava a melhor soluo, o foco no projeto trouxe como resultados, solues coerentes, rpidas e eficientes. Constantemente todos os envolvidos do projeto conversavam sobre os processos, como os mesmos poderiam ser melhorados, isso tornava a equipe mais eficaz, com refinamentos e ajustes constantes.

Ritmo constante e sustentvel

PARCIAL

Excelncia tcnica

SIM

Simplicidade

SIM

Equipes auto organizveis geram melhores resultados Reflexo peridica

SIM

SIM

Tabela 5 - Princpios do Agile Manifesto na UNIBRASPE

37

5. Apresentao e Discusso dos Resultados

5.1 Aplicao dos Valores, Prticas e Princpios Na aplicao da metodologia XP na UNIBRASPE, a comunicao foi fundamental para o sucesso do projeto, facilitando e fortalecendo os outros valores. A facilidade de comunicao, proporcionada por um local de trabalho adequado, no mesmo ambiente do cliente, fez com que o feedback se torna-se constante e ocorre-se de forma rpida e natural. O rpido retorno por parte dos usurios , facilitou o entendimento das rotinas, tornando o trabalho de manter o projeto simples, mais fcil. A aplicao das prticas e princpios da metodologia, foi um aprendizado dirio, constantemente surgiam desafios, isso provocava mudanas na forma de aplicao ou adaptaes na metodologia. 5.2 Desafios Por no se tratar de uma empresa do ramo de desenvolvimento de software e no ter uma cultura interna nesta atividade, a ideia de implementar um projeto des ta natureza parecia muito distante. Muitas questes surgiram e se tornaram obstculos para o incio do projeto: a) b) c) d) e) f) Como seria o gerenciamento do projeto? Qual seria o tamanho da equipe e qualificao adequada? Qual seria o investimento necessrio em hardware/software? Quais tecnologias deveriam ser utilizadas? Como seria feita a integrao com os outros sistemas da empresa? Como seria o suporte aos usurios?

Alm da insegurana em relao as questes levantadas, existia tambm uma desconfiana dos usurios, se este projeto daria certo, uma vez que o projeto anterior tinha fracassado e eles j estavam sofrendo com a utilizao de sistemas deficientes, com necessidade de fazer controles paralelos e lanamentos em duplicidade.

38

A deciso em utilizar a metodologia XP foi baseada em um grande desafio: Formar uma equipe multidisciplinar, capaz de recuperar a confiana dos usurios, entregando software funcional, de forma constante e que atende-se as necessidades prioritrias do cliente. 5.3 Benefcios Dentre os benefcios alcanados com a aplicao da metodologia XP na UNIBRASPE, pode-se destacar: a) Satisfao dos usurios, que recebiam constantemente uma nova ver-

so do software, contendo as funcionalidades priorizadas pelos mesmos e que agregavam maior valor ao negcio. b) Tranquilidade por parte do cliente, sabendo que os desenvolvedores

aceitavam as constantes mudanas no projeto, isso tornava a empresa mais competitiva, uma vez que sua ferramenta se adaptava rapidamente as mudanas e requisitos do mercado. c) Agilidade da equipe de desenvolvimento em responder as solicitaes

dos usurios. 5.4 Adaptaes Um dos ensinamentos do criador da metodologia, Kent Beck, se XP no funciona, mude XP. A adaptabilidade uma caracterstica das metodologias geis, em alguns projetos, podem existir restries ou at mesmo a impossibilidade de aplicao de todos os fundamentos. Na UNIBRASPE algumas adaptaes foram necessrias: a) Ritmo sustentvel: Apesar da metodologia orientar o mximo de oito

horas por dia de trabalho e quarenta horas semanais, esta prtica no pde ser executada de forma literal, devido principalmente ao tamanho da equipe de desenvolvimento, em vrios momentos foi necessrio extrapolar estes horrios, para atingir os objetivos do projeto, porm, sempre respeitando os limites e necessidades individuais dos membros da equipe.

39

b)

Reunies em p: Como cliente e equipe de desenvolvimento estavam

no mesmo ambiente, muitas reunies foram evitadas, quando algo precisava ser discutido, nenhum membro da equipe precisava sair do lugar. c) Programao em pares: Esta prtica s era usada quando o nvel de

complexidade era muito elevado, principalmente na elaborao de layouts e testes automatizados. d) Desenvolvimento orientado a testes: Esta prtica no foi executada, a

equipe de desenvolvimento no tinha experincia em TDD e optou por fazer testes funcionais, alguns testes automatizados foram criados, principalmente para validao de rotinas crticas, anlise automtica de logs ou registros em bancos de dados.

40

6. Consideraes Finais
A aplicao da metodologia XP na UNIBRASPE reduziu de forma considervel os atrasos e retrabalhos, a entrega constante de pequenas verses deixou os usurios confiantes, eles recebiam software funcionando e que atendia suas necessidades. A eficincia causada pela metodologia, deixou a alta gerncia da empresa segura em relao ao retorno do investimento, eles podiam observar que o software evolua de forma constante e a cada dia atendia mais necessidades da empresa. Os desenvolvedores se sentiam confortveis ao desenvolver uma nova rotina, o rpido retorno por parte dos usurios evidenciava o sucesso ou fracasso, com isso, rapidamente surgiam as solicitaes de melhorias e pedidos de mudanas/ajustes.
O XP mais que um novo conjunto de tcnicas de programao. O XP uma forma nova de tratar o relacionamento entre clientes do desenvolvimento de software e os desenvolvedores. Clientes e desenvolvedores se envolvem em uma espcie de dana, ambos os lados trabalhando juntos para o bem de toda a equipe. (TELES, 2004, p. 297)

O uso da XP contraria alguns paradigmas do desenvolvimento tradicional de software, porm, se usada de forma correta, pode trazer timos resultados. Tradicionalmente a maior parte do tempo gasto no desenvolvimento de um software fica logo no incio, durante o planejamento. Na XP existe apenas um esboo geral, que vai ganhando detalhes diariamente, de forma a refletir a necessidade do cliente naquele momento. Antes de aplicar XP, deve-se analisar o ambiente de trabalho, o grau de maturidade da equipe de desenvolvimento e principalmente a proximidade com o cliente, ele fundamental para o sucesso.

41

Referncias Bibliogrficas
ASTELS, D.; MILLER G.; NOVAK, M. Extreme Programming - Guia prtico. Campos, 2002. BASSI FILHO, D. L. Experincias com desenvolvimento gil. 170 pg. Dissertao (Mestrado) - Universidade de So Paulo, So Paulo, 2008. BECK, K. Extreme Programming Explained: Embrace change . Addison-Wesley Professional, 1999. BECK, K.; BEEDLE, M.; VAN BENNEKUM, A.; COCKBURN, A.; CUNNINGHAM, W.; FOWLER, M.; GRENNING, J.; HIGHSMITH, J.; HUNT, A.; JEFFRIES, R.; KERN, J.; MARICK, B.; MARTIN, R. C.; MELLOR, S.; SCHWABER, K.; SUTHERLAND, J.; THOMAS, D. Manifesto for Agile Software Development, 2001. Disponvel em: <http://www.agilemanifesto.org>. Acesso em: 04 de novembro de 2012. BECK, K. Programao Extrema Explicada: Acolha as mudanas . Bookman, 2004. BECK, K. Smalltalk Best Practice Patterns. Prentice Hall, 1996. CARDOSO, C. H. R. Aplicando prticas de Extreme Programming (XP) em equipes SW-CMM nvel 2, VI Simpsio Internacional de Melhoria de Processos de Software, So Paulo, 2004. Disponvel em: <http://www.simpros.com.br/simpros2004/Apresentacoes_PDF/Artigos/Art_05_Simpr os2004.pdf>. Acesso em: 04 de novembro de 2012. CASADEI, C.; LODDI, S. A.; PEREIRA, S. R.; SOUZA, M. V. A. Metodologias geis: Um exemplo de aplicao da Extreme Programming (XP) . Fasci-Tech - Peridico Eletrnico da FATEC, So Caetano do Sul, v. 1, n. 3, pg. 163 a 177, 2010. FIGUEIREDO, A. L. G. ECO - Um ecossistema para o desenvolvimento gil de sistemas web. 137 pg. Dissertao (Mestrado) - Universidade de So Paulo, So Carlos, 2005. GONALVES JR., J. P. O uso da metodologia XP no desenvolvimento de software e os impactos na gesto de riscos. 49 pg. Monografia (Sistemas de Informao) - Centro Universitrio da Fundao Octvio Bastos, So Joo da Boa Vista, 2009. MACEDO, O. A. C. Diretrizes para desenvolvimento de linhas de produtos de software com base em Domain-Driven Design e mtodos geis. 153 pg. Dissertao (Mestrado) - Universidade de So Paulo, So Carlos, 2009. OLIVEIRA, R. M. Um estudo sobre o espao de trabalho informativo e o acompanhamento em equipes geis de desenvolvimento de software. 114 pg. Dissertao (Mestrado) - Universidade de So Paulo, So Paulo, 2012.

42

SOMMERVILLE, I. Engenharia de Software 8a. Edio. Pearson Addison-Wesley, 2007. TELES, V. M. Extreme Programming: Aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. Novatec, 2004.