Universidade Estadual de Maringá Centro de Tecnologia - Departamento de Informática Especialização em Desenvolvimento de Sistemas para Web - Turma 8
EVERTON ANTONIO RAMOS
METODOLOGIAS ÁGEIS: EXTREME PROGRAMMING (XP) Um exemplo de aplicação em uma empresa do setor de óleo e gás
MONOGRAFIA DE ESPECIALIZAÇÃO
MARINGÁ - PR 2013
EVERTON ANTONIO RAMOS
METODOLOGIAS ÁGEIS: EXTREME PROGRAMMING (XP) Um exemplo de aplicação em uma empresa do setor de óleo e gás
Trabalho submetido à Universidade Estadual de Maringá como requisito parcial para obtenção do título de Especialista em Desenvolvimento de Sistemas para Web. Orientador: Prof. MSc. Gécen Dacome de Marchi
MARINGÁ - PR 2013
TERMO DE APROVAÇÃO
METODOLOGIAS ÁGEIS: EXTREME PROGRAMMING (XP) Um exemplo de aplicação em uma empresa do setor de óleo e gás
por
Everton Antonio Ramos
Esta monografia foi apresentada às 14:00 do dia 18 de janeiro de 2013, como requisito parcial para a obtenção do título de Especialista em Desenvolvimento de Sistemas para Web pelo Departamento de Informática da Universidade Estadual de Maringá. O candidato apresentou o trabalho para a Banca Examinadora composta pe-
los professores abaixo assinados. Após a deliberação, a Banca Examinadora considerou o trabalho ________________________.
Prof. MSc. Gécen Dacome de Marchi (Orientador) (UEM)
Prof. MSc. Munif Gebara Junior (UEM)
Prof. MSc. Flávio Rogério Uber (UEM)
DEDICATÓRIA A meus filhos Heitor e Mariana, que tenham a opção e a escolha das próprias forma ções. Aos amigos que fiz durante esta especialização e que ajudaram a vencer os desafios para alcançar mais esta conquista.
AGRADECIMENTOS Agradeço enormemente minha mãe, Prof. Maria José Pereira Ramos, por nunca ter deixado de lutar para que seus filhos recebessem a melhor educação e tivessem as melhores oportunidades. Agradeço a UNIBRASPE por confiar, acreditar e viabilizar todos os recursos necessários para que o projeto fosse bem sucedido. Agradeço a todos os envolvidos, em especial ao Josiel, que desde o início acreditou no projeto e que sempre esteve presente e disposto para tirar dúvidas e orientar sobre os procedimentos.
EPÍGRAFE ”Não é necessário pintar um grande quadro ou fazer uma grande descoberta para ser criativo, porquanto criativos são todo pensamento e toda ação 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 gás. Uma pesquisa exploratória e qualitativa buscou analisar a aplicação dos valores, práticas e princípios da metodologia na implementação de um projeto na empresa. Foram analisados os desafios, benefícios e adaptações que foram necessárias para sua aplicação e os resultados alcançados. Palavras-chave: Engenharia de software, Metodologias ágeis, Programação extrema, XP, Valores, Práticas, Princípios.
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 ILUSTRAÇÕES Figura 1 Figura 2 Figura 3 Figura 4 Figura 5
Ciclos de planejamento e feedback Práticas da Extreme Programming Tela padrão para buscas Tela padrão para inserções/alterações Ambiente de trabalho
Página 18 20 27 28 29
LISTA DE TABELAS Tabela 1 Tabela 2
Principais papeis na XP
Página 17 30
Valores da XP na UNIBRASPE Tabela 3
31 Práticas da XP na UNIBRASPE
Tabela 4 Tabela 5
Princípios da XP na UNIBRASPE Princípios do Agile Manifesto na UNIBRASPE
33 34
LISTA DE ABREVIATURAS E SIGLAS ERP
Enterprise Resource Planning (Sistema Integrado de Gestão Empresarial)
FDD
Feature Driven Development (Desenvolvimento Guiado por Funcionalidades)
MVC
Model View Controller (Modelo Visão Controle)
OC
Ordem de Carregamento
OOP
Object-Oriented Programming (Programação Orientada a Objetos)
REPAR
Refinaria Presidente Getúlio Vargas
SACC
Sistema de Administração e Controle de Combustíveis
SGBD
Sistema de Gerenciamento de Banco de Dados
TDD
Test Driven Development (Desenvolvimento Orientado a Testes)
XP
Extreme Programming (Programação Extrema)
SUMÁRIO 1. Introdução
Página 13
2. Fundamentação Teórica 2.1 Engenharia de Software 2.2 Surgimento dos Métodos Ágeis de Desenvolvimento de Software 2.3 Surgimento da Extreme Programming 2.4 Agile Alliance 2.5 Agile Manifesto
14 14 14 14 15 15
3. Extreme Programming 3.1 Valores da Extreme Programming 3.2 Práticas da Extreme Programming 3.3 Princípios da Extreme Programming 3.4 Quando não Utilizar a Extreme Programming
17 18 19 22 23
4. Exemplo de Aplicação da Extreme Programming 4.1 Empresa UNIBRASPE 4.2 Projeto 4.3 Valores da XP na UNIBRASPE 4.4 Práticas da XP na UNIBRASPE 4.5 Princípios da XP na UNIBRASPE 4.6 Princípios do Agile Manifesto na UNIBRASPE
25 25 25 30 31 33 34
5. Apresentação e Discussão dos Resultados 5.1 Aplicação dos Valores, Práticas e Princípios 5.2 Desafios 5.3 Benefícios 5.4 Adaptações
37 37 37 38 38
6. Considerações Finais
40
Referências Bibliográficas
41
14
1. Introdução Desde a criação da linha de pesquisa engenharia de software na década de 1960 a indústria de software busca técnicas para reduzir os riscos e aumentar a produtividade. O desenvolvimento de software em cascata ou ciclo de vida do software foi o primeiro grande avanço, este modelo é focado no planejamento e documentação, seguindo passos rigorosos desde o levantamento de requisitos, análise, projeto, codificação, testes e manutenção (SOMMERVILLE, 2007). No modelo ágil, se enfatiza a obtenção de funcionalidades executáveis que possam ser agregadas e disponibilizadas aos usuários no menor tempo possível, porém não significa negligenciar as atividades da engenharia de software, apenas praticá-las de forma não convencional. Em 1996, Kent Beck e Ward Cunningham criaram a metodologia Extreme Programming (XP) (FIGUEIREDO, 2005), baseada numa série de princípios e boas práticas, esta técnica permite o desenvolvimento de forma ágil, o “Extreme” se deve ao fato dela empregar ao extremo boas práticas da engenharia de software (BECK, 1999), sem esquecer-se do custo e qualidade. Este trabalho pretende mostrar de forma teórica os valores, práticas e princípios da metodologia XP. A metodologia adotada foi um levantamento bibliográfico em livros, artigos, trabalhos acadêmicos e materiais encontrados na Internet. Para subsidiar a teoria, foi efetuada uma pesquisa exploratória e qualitativa, dentro de uma empresa brasileira do setor de óleo e gás, onde a metodologia XP foi aplicada.
15
2. Fundamentação Teórica 2.1 Engenharia de Software Engenharia de software é a área de conhecimento dentro da ciência da computação que estuda formas de se especificar, construir e manter software. Desde meados da década de 1960 técnicas de engenharia começaram a ser usadas no de senvolvimento de software, buscando criar processos capazes de ser documentados e depois replicados. Essas técnicas tornaram-se parte da engenharia de software e são amplamente usadas hoje em dia. No entanto, assim como aumentou a habilidade de produzir software, cresceu também a necessidade por sistemas de software mais complexos. Novas tecnologias resultantes da convergência de computadores e sistemas de comunicação, e as complexas interfaces com o usuário, impuseram novos desafios aos engenheiros de software. Como muitas empresas ainda não aplicam as técnicas de engenharia de software de forma efetiva, muitos projetos produzem software de baixa confiabilidade, com atraso e com custo além do orçamento. (SOMMERVILLE, 2007, p. 4)
2.2 Surgimento dos Métodos Ágeis de Desenvolvimento de Software O surgimento dos métodos ágeis de desenvolvimento de software ocorreu quando dezessete especialistas, criadores de métodos como Extreme Programming (XP), Scrum e Feature Driven Development (FDD), delinearam princípios comuns compartilhados por todos. O resultado foi a formação da Agile Alliance e o estabelecimento do Agile Manifesto, no ano de 2001 (BECK et al., 2001). Apesar das metodologias ágeis terem práticas 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 técnicas de programação (BECK, 1996). Foi convidado no mesmo ano para liderar um projeto na Chrysler (fabricante de veículos). O projeto já havia ultrapassado os prazos e custos sem alcançar os resultados esperados. Com o auxílio de sua equipe, Beck conse guiu entregar um sistema de qualidade, começando do zero e terminando em menos tempo que nas tentativas anteriores. Beck agrupou técnicas que de forma isolada já haviam demonstrado sua eficiência, multiplicando assim os resultados, surgia aí a Extreme Programming. Seu objetivo era maximizar a utilização destas técnicas ao
16
extremo, com revisão constante do código, através da programação 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 organização sem fins lucrativos, com o compromisso de promover princípios e práticas de desenvolvimento ágil de software. Eles apoiam quem explora e aplica estes princípios, tornando a indústria de software mais produtiva, humana e sustentável. 2.5 Agile Manifesto Na formação da Agile Alliance foi publicado o Agile Manifesto (BECK et al., 2001). Os autores, mesmo reconhecendo valor em técnicas e princípios já consagrados na engenharia de software, declararam: Indivíduos e interações mais que processos e ferramentas; Software funcionando mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder as mudanças mais que seguir um plano. Este manifesto não se limitou a estas declarações, foram definidos doze princípios: 1.
Satisfação do cliente com entrega de software com valor agregado;
2.
Aceitação a mudanças nos requisitos, mesmo que tardiamente;
3.
Maior frequência na entrega de software funcionando;
4.
Pessoas de negócio e desenvolvedores devem trabalhar próximas;
5.
Motivação;
6.
Comunicação face a face;
7.
Software executável como métrica primária de progresso;
8.
Ritmo constante e sustentável;
9.
Excelência técnica;
17
10.
Simplicidade;
11.
Equipes auto-organizáveis geram melhores resultados;
12.
Reflexão periódica.
18
3. Extreme Programming XP é uma metodologia ágil para desenvolvimento de software, é recomendada sua utilização em projetos com requisitos incertos e que mudam com frequência, que possuam equipes pequenas (máximo de doze desenvolvedores), onde o sistema possa ser desenvolvido de forma incremental (ou iterativa) e que a programação seja feita usando o paradigma da orientação a objetos (OOP). O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de um conjunto de valores e práticas que atuam de forma harmônica 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 negócio do cliente, para isso a equipe deve reunir todas as habilidades técnicas e de negócios para produzir o software (BASSI FILHO, 2008). Em XP existem quatro papeis principais conforme a tabela abaixo (Tabela 1): Papel
Função
Programador
O programador é um papel chave em XP (FIGUEIREDO, 2005), a ideia é que não exista hierarquia, o mesmo tem como função codificar o sistema, na metodologia XP os programadores precisam ser experientes e qualificados.
Coach (Treinador)
O mais experiente do time de desenvolvimento recebe o papel de coach, ele deve orientar a equipe sobre as práticas da XP, o coach não é necessariamente o melhor programador e sim quem mais entende da metodologia XP.
Tracker (Acompanhador)
Responsável por manter a equipe consciente do andamento do projeto, ele deve trazer informações que ajudem a equipe a tomar decisões sobre a arquitetura, design e implementação, muitas vezes o próprio coach exerce este papel.
Cliente
Em XP o cliente faz parte da equipe, ele deve estar sempre presente e disposto a tirar dúvidas e esclarecer procedimentos. Tabela 1 - Principais papeis na XP
Na XP o ciclo de planejamento e feedback (Figura 1) devem ser diários, a equipe deve se reunir e discutir sobre os resultados e dificuldades encontradas até o
19
momento, priorizar aquilo que é mais importante para o cliente e focar seus esforços 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 iteração (CARDOSO, 2004), através dele os desenvolvedores conseguem avaliar o nível de sucesso de uma nova versão e se as funcionalidades apresentadas atenderam as expectativas dos usuários. A troca de informações deve ser constante, isso gera uma união e reciprocidade entre todos os membros da equipe. Comunicação (Communication): Para que exista feedback a comunicação precisa ser constante e intensa. A melhor forma de comunicação entre duas pessoas é uma conversa face a face, conversas pelo telefone ou através de mensagens instantâneas acabam não tendo a mesma eficiência. A forma como nos comunicamos tem influência direta na compreensão da mensagem, uma conversa face a face agrega valores como gestos, expressões faciais, tom de voz, entre outros, isso acaba facilitando a transmissão da mensagem e sua compreensão (TELES, 2004).
20
Simplicidade (Simplicity): Em projetos onde os requisitos podem mudar a qualquer momento, criar funcionalidades desnecessárias só tornam o software complexo e de difícil manutenção (BECK, 1999). Todo o código escrito deve ser focado em criar funcionalidades priorizadas pelo cliente e que terão seu uso de forma imediata. Fazer exatamente aquilo que o cliente precisa, da forma mais simples possível, garante velocidade no desenvolvimento e facilidade na manutenção. Respeito (Respect): O respeito é o valor que sustenta os demais, sem respeito os outros valores perdem o sentido e a aplicação da metodologia se torna in viável. Respeitar opiniões diversas, necessidades individuais, saber ouvir e ter compreensão entre todos os membros da equipe é fundamental. Coragem (Courage): Por ser uma metodologia relativamente nova e ser contrária a vários processos tradicionais de desenvolvimento de software, a adoção e aplicação exigem coragem da equipe (TELES, 2004). É preciso coragem para manter o projeto simples, permitindo que o cliente priorize as funcionalidades que deverão ser implementadas, aceitando mudanças constantes nos requisitos e permitindo que todos tenham acesso aos códigos e possam modificar os mesmos a qualquer momento. 3.2 Práticas da Extreme Programming Práticas em XP são derivadas de seus valores (CARDOSO, 2004) e representam aquilo que a equipe executa diariamente (Figura 2), sua utilização depende do contexto, conforme o contexto muda a aplicação da prática também deve mudar.
21
Figura 2 - Práticas da Extreme Programming Fonte: www.xprogramming.com Cliente presente (Whole Team): Na XP a presença do cliente é fundamental, as informações que o mesmo fornece de forma rápida, permitem a obtenção do máximo 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 necessário para desenvolver cada nova funcionalidade, esta prática assegura que o trabalho seja direcionado para aquilo que é mais importante para o cliente (ASTELS; MILLER; NOVAK, 2002). Pequenas versões (Small Releases): A entrega constante de pequenas versões, com novas funcionalidades, faz com que o cliente sinta confiança no projeto. O mesmo ao iniciar o uso de uma nova versão, com as funcionalidades que ele elegeu como prioritárias e que agregam valor ao negócio, produz um ambiente de colaboração, motivando toda a equipe. Metáfora (Metaphor): Numa equipe multidisciplinar onde os níveis de conhecimento tendem a ser desproporcionais, ou seja, o desenvolvedor entende muito de programação e o cliente entende muito das regras de negócio, a comunicação pode se tornar complicada. O uso de metáforas possibilita a transmissão de ideias de uma
22
forma mais clara e simples. Esta prática facilita a comunicação entre o desenvolvedor e o cliente, estabelecendo um vocabulário comum (BECK, 2004). Projeto simples (Simple Design): Quanto mais simples for o sistema, mais rapidamente o mesmo poderá ser adaptado à mudanças. A redução do tempo e custo das mudanças depende de um projeto simples, ser simples não significa que o mesmo não dispõe dos recursos necessários para atender o cliente, significa que o projeto tem exatamente aquilo que o cliente precisa, no nível de complexidade e flexibilidade necessários naquele momento (BASSI FILHO, 2008). Ritmo sustentável (Sustainable Pace): Pessoas cansadas não conseguem aplicar a metodologia XP, o respeito pelos limites físicos e necessidades individuais é essencial para a produção de um bom trabalho. A XP recomenda que a carga ho rária de trabalho não ultrapasse oito horas diárias e quarenta horas semanais (GONÇALVES JR., 2009). Posse coletiva (Collective Ownership): Todos os desenvolvedores devem ter acesso a todas as partes do código, podendo efetuar alterações naquilo que for necessário. Esta prática é essencial para agilizar eventuais correções ou revisões. Programação em pares (Pair Programming): Dois programadores, de forma coletiva, utilizam o mesmo computador para implementar determinadas funcionalidades. Esta prática traz vários benefícios: revisão constante do código; redução de erros; replicação de conhecimentos. As duplas devem ser trocadas frequentemente, aumentando a união e disseminação das experiências. Padrões de codificação (Coding Standard): O padrão de codificação é essencial para garantir uma manutenção rápida do software, o mesmo só pode ser de posse coletiva se todos da equipe entenderem o código. Seguir um padrão torna o código homogêneo, permitindo manutenções rápidas e seguras (TELES, 2004). Desenvolvimento orientado a testes (Test Driven Development): Testes são escritos para cada funcionalidade, antes de codificá-las, isto obriga um planejamento das interfaces, classes e métodos, esta prática gera uma massa de testes que pode ser usada a qualquer momento para validar todo o sistema (TELES, 2004). Refatoração (Refactoring): Consiste em organizar o código fonte de um software, melhorando sua qualidade e facilitando o processo de manutenção. Isso
23
é fundamental para tornar o código mais legível e detectar possíveis erros (GONÇALVES JR., 2009). Integração contínua (Continuous Integration): Logo após terminar determinada rotina, o programador deve integrá-la ao projeto principal. Isso deve ser feito várias vezes ao dia, visando a sincronização das atividades individuais (BECK, 2004). Depois de algum tempo, adeptos de XP perceberam que simplesmente aplicar todas as práticas, sem considerar os princípios e valores por trás delas não era uma abordagem efetiva. O que faz sentido, de acordo com a própria filosofia que XP segue: métodos ágeis devem ser adaptativos e não-prescritivos. Esta observação levou à criação de uma nova prática, chamada “Conserte XP quando ela não funciona”, que sugere que quando não for possível aplicar XP em sua totalidade, as práticas devem ser adaptadas de acordo com o ambiente. Desta forma, as práticas de XP não devem ser vistas como dogmas, mas como orientações para organizar o comportamento da equipe e como base para reflexão contínua. (BASSI FILHO, 2008, p. 57)
3.3 Princípios da Extreme Programming Uma característica dos métodos ágeis de desenvolvimento de software é que sua aplicação varia conforme o contexto encontrado. Mesmo assim, estas variações são direcionadas através de uma série de princípios (OLIVEIRA, 2012). Feedback rápido (Fast feedback): O tempo decorrido após a implantação de uma nova funcionalidade e o feedback do usuário é fundamental para a aprendizagem (CASADEI; LODDI; PEREIRA; SOUZA, 2010), facilitando a correção de problemas e ajustes necessários para melhorar o uso do software. Presumir simplicidade (Assuming simplicity): Um sistema grande e complexo é formado por partes pequenas e simples, desenvolvedores tradicionalmente são orientados a planejar para o futuro visando o reuso, a XP orienta que o esforço de desenvolvimento seja direcionado para resolver o problema atual, da forma mais rápida e simples possível (BECK, 2004). Mudanças incrementais (Incremental changes): A busca pela solução mais simples força a equipe a estar preparada para mudanças constantes. A evolução do projeto e entendimento do problema acabam gerando alterações nos requisitos e escopo, a equipe deve estar preparada para estas mudanças, executando as mesmas no menor tempo e custo possível (MACEDO, 2009).
24
Abraçar mudanças (Embracing changes): Desenvolvedores geralmente não lidam bem com mudanças de requisitos ou escopo, porém estas mudanças 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 não é um fator negociável, ela deve ser uma meta, o aumento da qualidade traz mais motivação para os membros da equipe, satisfaz o cliente e facilita novas implementações (BASSI FILHO, 2008). 3.4 Quando não Utilizar a Extreme Programming A metodologia XP recomenda formas simplificadas e eficazes de desenvolvimento de software, aplicá-las em equipes que não fazem uso de processos ágeis não é fácil, e muitas vezes impossível. As dificuldades não são de ordem técnica e sim culturais (BECK, 2004). Naturalmente, há alguns tipos de sistemas nos quais o desenvolvimento e a entrega incrementais não são a melhor abordagem. Esses são 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 críticos, nos quais todos os requisitos devem ser analisados quanto a interações que possam comprometer a segurança 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 farão XP não funcionar. 1.
Exigência de especificação/análise/projeto completo antes de começar;
2.
Projetos com escopo fechado;
3.
Necessidade de fazer horas extras constantemente;
4.
Dificuldade de comunicação entre a equipe/cliente (feedback);
5.
Equipes grandes ou distantes;
6.
Equipes alheias a mudanças;
7.
Desenvolvedores de baixa qualidade;
8.
Política de premiações individuais;
9.
Ambiente físico inadequado;
25
Os limites exatos da XP ainda não estão claros. Porém, existem alguns estraga prazeres que fazem a XP não funcionar; grandes times, clientes desconfiados, tecnologias que não suportam elegantemente as modificações. (BECK, 2004, p. 151)
26
4. Exemplo de Aplicação da Extreme Programming As informações e dados desta seção foram coletadas pelo próprio autor, um dos desenvolvedores e responsável pelo projeto dentro da empresa. 4.1 Empresa UNIBRASPE Em 2000 foi fundada a Unibraspe Brasileira de Petróleo S/A, suas operações começaram em janeiro de 2003, a mesma fica estrategicamente localizada ao lado da Refinaria Presidente Getúlio Vargas (REPAR) em Araucária - Pr. Sua principal atividade é o armazenamento de derivados de petróleo e biocombustíveis, sendo considerada uma base primária onde seus clientes (distribuidoras) retiram os produtos que podem ser encaminhados para outras bases (secundárias) ou diretamente para os postos de abastecimento. 4.2 Projeto A empresa no início de 2010 implantou um sistema integrado de gestão empresarial (ERP) da TOTVS chamado Microsiga Protheus em sua versão 10. O sistema contemplava todos os departamentos da empresa, porém o controle de estoque de terceiros e faturamento, atividade que demandava grande esforço e considerada estratégica, não atendia as necessidades da empresa e precisava ser desenvolvido em separado. A empresa contratou a própria TOTVS, proprietária do ERP para desenvolver e adaptar o sistema, porém o projeto não obteve êxito. Em outubro de 2011 a empresa optou por deixar o seu próprio departamento de informática responsável pelo projeto. O departamento era recém-formado, não demandava de muitos profissionais e tinha muito pouco conhecimento sobre os requisitos do projeto. Após um levantamento de requisitos, através de entrevistas com os responsáveis do setor, foram definidas as primeiras diretrizes do projeto, entre elas que o mesmo seria feito usando a metodologia XP. A primeira ação efetiva foi transferir os desenvolvedores para o setor, ficando na mesma sala que os responsáveis pela supervisão, administração e faturamento.
27
Detalhes técnicos e qual seria o papel do cliente na metodologia não foram detalhados ao cliente, isso poderia causar algum tipo de resistência ou mudar o seu foco de trabalho. A princípio o sistema que seria desenvolvido parecia ser muito simples, o principal negócio da UNIBRASPE é armazenar e devolver combustíveis. A armazenagem ocorre de duas formas, a principal é o recebimento dutoviário, os clientes (distribuidoras) da UNIBRASPE compram gasolina e diesel da REPAR. Diariamente a REPAR bombeia os produtos comprados que são armazenados nos tanques da UNIBRASPE. A segunda forma de armazenagem é rodoviária, as distribuidoras compram biocombustíveis (biodiesel e etanol) de usinas e transportam até a UNIBRASPE onde são armazenados. Para armazenar os produtos a distribuidora precisa emitir uma nota fiscal de armazenagem. Para retirar o combustível a distribuidora emite uma ordem de carregamento (OC), nesta ordem constam o nome do motorista, dados do veículo e quais produtos serão carregados. Esta OC precisa ser lançada no sistema, que indica se a distribuidora possui estoque suficiente, autorizando assim o procedimento de carregamento. Na saída do veículo, o sistema deve emitir uma nota fiscal de devolução de armazenagem, encerrando assim o processo. Com a equipe formada, decisões técnicas foram tomadas, entre elas a escolha da linguagem de programação 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 programação e MySQL (http://www.mysql.com/) como SGBD, devido a flexibilidade de ambos e por ser de conhecimento técnico dos desenvolvedores. Foi definido também 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 visões, uma visão desktop utilizada internamente pela UNIBRASPE e uma visão web, para que os clientes da UNIBRASPE tivessem acesso a alguns relatórios e funções do sistema. Já ambientados no novo setor e com as definições técnicas estabelecidas, iniciou-se a primeira “reunião”, para saber quais eram as prioridades e iniciar o desen-
28
volvimento. De forma natural e descontraída o cliente elegia os pontos fundamentais do projeto, priorizando aquilo que era mais importante e necessário no momento. Ficou evidenciado logo no início que o setor tinha muita dificuldade com a emissão de notas fiscais e o controle de estoque de terceiros, porém, para chegar ao ponto de emitir uma nota fiscal, muitas outras rotinas precisavam ser desenvolvidas, entre elas alguns cadastros essenciais. 1.
Cadastro de clientes;
2.
Cadastro de motoristas;
3.
Cadastro de veículos;
4.
Cadastro de produtos;
Após a definição de um layout extremamente simples para as telas de cadastro, foram executados testes funcionais e o início do desenvolvimento. Todos os cadastros teriam no mínimo duas telas, uma tela inicial para efetuar buscas (Figura 3) e outra tela para inserir ou alterar registros (Figura 4).
Figura 3 - Tela padrão para buscas
29
Figura 4 - Tela padrão para inserções/alterações Após o desenvolvimento dos principais cadastros, foi entregue a primeira versão do sistema, esta versão consumiu uma semana de trabalho, neste momento a metodologia XP mostrou sua força através do feedback dos usuários, os mesmos iniciaram imediatamente o uso do sistema e com o início dos cadastros, logo apontaram melhorias e solicitaram novos recursos. No início, a entrega de versões era constante, as vezes ocorrendo várias 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 benefícios, desde a convivência no setor, acompanhamento dos processos e entendimento cada vez maior das necessidades e dificuldades enfrentadas diariamente, com isso surgia a proposta de soluções e mudanças, novamente o feedback constante mostrava o seu valor. Porém, era preciso priorizar, era necessário entregar software funcionando semanalmente, “reuniões” de priorização ocorriam de forma natural e expontânea, o cliente apontava sua necessidade e o início do desenvolvimento era praticamente imediato. No dia 02 de janeiro de 2012 o sistema recém batizado de Sistema de Administração e Controle de Combustíveis (SACC) emitia sua primeira nota fiscal,
30
ou seja, em pouco mais de um mês a principal necessidade do cliente foi atendida. O sistema literalmente não tinha nenhum relatório ou recurso desnecessário, e convergia para uma única ação, que era emitir a nota fiscal. O uso da metodologia evoluía 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 aplicação da metodologia, a facilidade de comunicação e a convivência diária com o cliente, proporcionaram um entendimento melhor sobre as regras de negócio e uma grande união da equipe, direcionando todos os esforços 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 adoção durante o projeto e a justificativa para sua adoção ou rejeição.
Valor
Adota: SIM / NÃO / PARCIAL
Justificativa
Comunicação
SIM
O sucesso do projeto e sua agilidade é diretamente proporcional a interação da equipe e facilidade de comunicação da mesma. Todos os membros da equipe devem estar próximos, de preferência na mesma sala e ter a liberdade de se comunicarem quando quiserem, isto permite que todos acompanhem o andamento do projeto e possam dar contribuições de forma natural e expontânea.
Simplicidade
SIM
Aquilo que o cliente quer geralmente é muito mais simples e objetivo do que o desenvolvedor imagina, para atender o cliente rapidamente é necessário manter o projeto simples e codificar apenas o necessário.
Feedback
SIM
Os comentários sobre uma decisão tomada ou sobre os recursos de uma nova versão devem ser rápidos e de conhecimento de todos, a equipe deve ter consciência do que está acontecendo.
Coragem
SIM
A alteração de código em produção e o comprometimento com prazos, sem causar bugs, exige muita coragem e responsabilidade.
Respeito
SIM
Todos têm importância dentro da equipe e agregam valor ao projeto, cada opinião ou ponto de vista era analisado e discutido, até que um entendimento fosse encontrado.
Tabela 2 - Valores da XP na UNIBRASPE
32
4.4 Práticas da XP na UNIBRASPE A tabela 3 ilustra as práticas da metodologia XP, a adoção durante o projeto e a justificativa para sua adoção ou rejeição.
Valor
Adota: SIM / NÃO / PARCIAL
Justificativa
Jogo de planejamento
SIM
O processo de priorização 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.
Pequenas versões
SIM
A entrega constante de pequenas versões, trouxe segurança ao cliente, que já podia fazer testes e utilizar os recursos disponibilizados.
Metáfora
SIM
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.
Projeto simples
SIM
O foco do projeto era atender o cliente no menor tempo possível, desenvolver exatamente aquilo que ele precisava, da forma mais “enxuta” e rápida possível.
Time coeso
SIM
A equipe era multidisciplinar e engajada, era necessário extrair o melhor de cada membro, direcionando os esforços para o bem do projeto.
Testes de aceitação
SIM
Após cada entrega de versão era necessário que o cliente efetua-se um conjunto de testes, após sua aceitação, a nova versão entrava imediatamente em produção.
Ritmo sustentável
PARCIAL
O foco era um trabalho de qualidade, fazer um grande número de horas extras pode exaurir os membros da equipe, no início o número de horas trabalhadas foi muito grande, com o tempo a equipe encontrou um ritmo saudável e sustentável.
Reuniões em pé
PARCIAL
Nem todas as “reuniões” eram em pé, o ambiente de trabalho (Figura 5) propiciava a comunicação constante entre os membros da equipe, facilitando e incentivando o feedback.
SIM
O código era da equipe, qualquer um podia alterar o mesmo, isso facilitou o processo de refactoring, inclusão de novos recursos e eliminação de bugs.
Posse coletiva
33
Valor
Adota: SIM / NÃO / PARCIAL
Justificativa
Programação em pares
PARCIAL
A prática só era usada em rotinas mais complexas, para elaboração de alguns testes automatizados e definição de layouts.
Padrões de codificação
SIM
Desde o início os desenvolvedores definiram os padrões de codificação, como o projeto foi feito em Java este processo foi facilitado, seguindo padrões já definidos e comumente usados pelo mercado.
Desenvolvi-mento orientado a testes
NÃO
Os desenvolvedores não se sentiam confortáveis em aplicar esta prática (TDD), os testes eram criados após a codificação das rotinas.
Refatoração
SIM
A refatoração era uma prática constante e necessária para criar código “limpo” e reaproveitável.
Integração contínua
SIM
A integração era praticamente instantânea, toda nova rotina tinha que ser integrada ao sistema, no menor tempo possível e já participar dos testes para poder fazer parte da próxima versão.
Tabela 3 - Práticas da XP na UNIBRASPE
34
4.5 Princípios da XP na UNIBRASPE A tabela 4 ilustra os princípios da metodologia XP, a adoção durante o projeto e a justificativa para sua adoção ou rejeição.
Valor
Adota: SIM / NÃO / PARCIAL
Feedback rápido
SIM
A troca de informações entre os componentes da equipe foi fundamental para o sucesso do projeto, com a proximidade dos componentes esta troca era muito rápida, facilitando assim o direcionamento dos esforços e resolução de problemas.
Presumir simplicidade
SIM
Grande parte do trabalho era encontrar a maneira mais simples e rápida de fazer aquilo que o cliente realmente precisava.
Mudanças incrementais
SIM
O projeto era incremental, a dificuldade era priorizar aquilo que o cliente necessitava e que agregaria maior valor ao negócio.
Abraçar mudanças
SIM
Conforme o cliente começa a utilizar o software, ele acaba percebendo que determinadas funções poderiam ser feitas de outra forma ou que poderiam incluir ou excluir etapas/dados. Mudanças legais ou exigências do mercado, também geram mudanças no sistema. Aceitar estas mudanças e efetuar as mesmas no menor tempo possível, agrega valor ao software e torna o cliente mais competitivo.
Trabalho de alta qualidade
SIM
A equipe de desenvolvimento precisava ser experiente e ter domínio sobre as ferramentas que foram utilizadas.
Justificativa
Tabela 4 - Princípios da XP na UNIBRASPE
35
4.6 Princípios do Agile Manifesto na UNIBRASPE A tabela 5 ilustra os princípios do Agile Manifesto, se o mesmo contribuiu para o projeto e a visão da equipe sobre o mesmo.
Valor
Contribuiu: SIM / NÃO / PARCIAL
Visão da Equipe
Satisfação do cliente com entrega de software com valor agregado
SIM
O cliente além 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.
Aceitação a mudanças nos requisitos, mesmo que tardiamente
SIM
Refazer rotinas e ver que tempo foi perdido, não agrada um desenvolvedor, porém isto era visto de forma positiva, surgia a oportunidade de melhorar uma rotina e agregar mais valor ao software, além de tornar o cliente mais competitivo, adequando sua ferramenta em menos tempo que os concorrentes.
Maior frequência na entrega de software funcionando
SIM
Entregar software funcionando semanalmente, era o principal objetivo do time de desenvolvimento e trazia benefícios imediatos, desde a validação dos mesmos com testes funcionais, a comunicação dos usuários com elogios e críticas sobre os novos recursos.
Pessoas de negócio e desenvolvedores devem trabalhar próximas
SIM
Esta foi a primeira ação 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 esforços na automatização e melhoria dos processos do setor e os clientes se sentissem confiantes, colaborando e incentivando o desenvolvimento do software.
Motivação
SIM
Desde o início a motivação da equipe era enorme, o ambiente agradável, com todo o suporte e recursos necessários, contribuiu de forma decisiva para manter a equipe motivada e engajada no sucesso do projeto.
Comunicação face a face
SIM
A proximidade das equipes tornou o ambiente descontraído e colaborativo, quando surgia uma dúvida sobre o projeto a mesma era discutida e sanada imediatamente, tanto os desenvolvedores como o cliente se sentiam confortáveis em perguntar e argumentar sobre o projeto a qualquer momento.
36
Contribuiu: SIM / NÃO / PARCIAL
Valor
Visão da Equipe
Software executável como métrica primária de progresso
SIM
No princípio, a alta gerência da empresa acompanhava de forma desconfiada o progresso do projeto, solicitava a criação de cronogramas, documentação e reuniões de alinhamento, com o passar do tempo, eram comunicadas sobre a liberação de uma nova versão, participavam do processo de homologação e já se sentiam seguros que o software estava progredindo.
Ritmo constante e sustentável
PARCIAL
Os primeiros dias não foram fáceis, a empresa opera em dois turnos, ou seja, nosso cliente estava presente no setor em média durante dezesseis horas/dia. A participação 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 horário flexível, isso facilitou muito a adaptação, com o passar do tempo, o ritmo de trabalho se estabilizou de forma sustentável.
Excelência técnica
SIM
A equipe de desenvolvedores era muito experiente e focada na excelência técnica e bom design, isso colaborou muito para a agilidade e progresso do projeto.
Simplicidade
SIM
Não existia tempo para desenvolver “frescuras”, cada linha de código deveria ser útil e estar disponível para o cliente no menor tempo possível. Eliminar do projeto aquilo que não era necessário ou que poderia ser feito em outro momento era essencial.
Equipes auto organizáveis geram melhores resultados
SIM
A cada novo desafio a própria equipe se reunia e buscava a melhor solução, o foco no projeto trouxe como resultados, soluções coerentes, rápidas e eficientes.
Reflexão periódica
SIM
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.
Tabela 5 - Princípios do Agile Manifesto na UNIBRASPE
37
5. Apresentação e Discussão dos Resultados 5.1 Aplicação dos Valores, Práticas e Princípios Na aplicação da metodologia XP na UNIBRASPE, a comunicação foi fundamental para o sucesso do projeto, facilitando e fortalecendo os outros valores. A facilidade de comunicação, 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 rápida e natural. O rápido retorno por parte dos usuários, facilitou o entendimento das rotinas, tornando o trabalho de manter o projeto simples, mais fácil. A aplicação das práticas e princípios da metodologia, foi um aprendizado diário, constantemente surgiam desafios, isso provocava mudanças na forma de aplicação ou adaptações na metodologia. 5.2 Desafios Por não se tratar de uma empresa do ramo de desenvolvimento de software e não ter uma cultura interna nesta atividade, a ideia de implementar um projeto des ta natureza parecia muito distante. Muitas questões surgiram e se tornaram obstáculos para o início do projeto: a)
Como seria o gerenciamento do projeto?
b)
Qual seria o tamanho da equipe e qualificação adequada?
c)
Qual seria o investimento necessário em hardware/software?
d)
Quais tecnologias deveriam ser utilizadas?
e)
Como seria feita a integração com os outros sistemas da empresa?
f)
Como seria o suporte aos usuários?
Além da insegurança em relação as questões levantadas, existia também uma desconfiança dos usuários, se este projeto daria certo, uma vez que o projeto anterior tinha fracassado e eles já estavam sofrendo com a utilização de sistemas deficientes, com necessidade de fazer controles paralelos e lançamentos em duplicidade.
38
A decisão em utilizar a metodologia XP foi baseada em um grande desafio: Formar uma equipe multidisciplinar, capaz de recuperar a confiança dos usuários, entregando software funcional, de forma constante e que atende-se as necessidades prioritárias do cliente. 5.3 Benefícios Dentre os benefícios alcançados com a aplicação da metodologia XP na UNIBRASPE, pode-se destacar: a)
Satisfação dos usuários, que recebiam constantemente uma nova ver-
são do software, contendo as funcionalidades priorizadas pelos mesmos e que agregavam maior valor ao negócio. b)
Tranquilidade por parte do cliente, sabendo que os desenvolvedores
aceitavam as constantes mudanças no projeto, isso tornava a empresa mais competitiva, uma vez que sua ferramenta se adaptava rapidamente as mudanças e requisitos do mercado. c)
Agilidade da equipe de desenvolvimento em responder as solicitações
dos usuários. 5.4 Adaptações Um dos ensinamentos do criador da metodologia, Kent Beck, se XP não funciona, mude XP. A adaptabilidade é uma característica das metodologias ágeis, em alguns projetos, podem existir restrições ou até mesmo a impossibilidade de aplicação de todos os fundamentos. Na UNIBRASPE algumas adaptações foram necessárias: a)
Ritmo sustentável: Apesar da metodologia orientar o máximo de oito
horas por dia de trabalho e quarenta horas semanais, esta prática não pôde ser executada de forma literal, devido principalmente ao tamanho da equipe de desenvolvimento, em vários momentos foi necessário extrapolar estes horários, para atingir os objetivos do projeto, porém, sempre respeitando os limites e necessidades individuais dos membros da equipe.
39
b)
Reuniões em pé: Como cliente e equipe de desenvolvimento estavam
no mesmo ambiente, muitas reuniões foram evitadas, quando algo precisava ser discutido, nenhum membro da equipe precisava sair do lugar. c)
Programação em pares: Esta prática só era usada quando o nível de
complexidade era muito elevado, principalmente na elaboração de layouts e testes automatizados. d)
Desenvolvimento orientado a testes: Esta prática não foi executada, a
equipe de desenvolvimento não tinha experiência em TDD e optou por fazer testes funcionais, alguns testes automatizados foram criados, principalmente para validação de rotinas críticas, análise automática de logs ou registros em bancos de dados.
40
6. Considerações Finais A aplicação da metodologia XP na UNIBRASPE reduziu de forma considerável os atrasos e retrabalhos, a entrega constante de pequenas versões deixou os usuários confiantes, eles recebiam software funcionando e que atendia suas necessidades. A eficiência causada pela metodologia, deixou a alta gerência da empresa segura em relação ao retorno do investimento, eles podiam observar que o software evoluía de forma constante e a cada dia atendia mais necessidades da empresa. Os desenvolvedores se sentiam confortáveis ao desenvolver uma nova rotina, o rápido retorno por parte dos usuários evidenciava o sucesso ou fracasso, com isso,
rapidamente
surgiam
as
solicitações
de
melhorias
e
pedidos
de
mudanças/ajustes. O XP é mais que um novo conjunto de técnicas de programação. 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 espécie de dança, 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, porém, se usada de forma correta, pode trazer ótimos resultados. Tradicionalmente a maior parte do tempo gasto no desenvolvimento de um software fica logo no início, durante o planejamento. Na XP existe apenas um esboço 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
Referências Bibliográficas ASTELS, D.; MILLER G.; NOVAK, M. Extreme Programming - Guia prático. Campos, 2002. BASSI FILHO, D. L. Experiências com desenvolvimento ágil. 170 pág. Dissertação (Mestrado) - Universidade de São Paulo, São 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. Disponível em: . Acesso em: 04 de novembro de 2012. BECK, K. Programação Extrema Explicada: Acolha as mudanças. Bookman, 2004. BECK, K. Smalltalk Best Practice Patterns. Prentice Hall, 1996. CARDOSO, C. H. R. Aplicando práticas de Extreme Programming (XP) em equipes SW-CMM nível 2, VI Simpósio Internacional de Melhoria de Processos de Software, São Paulo, 2004. Disponível em: . Acesso em: 04 de novembro de 2012. CASADEI, C.; LODDI, S. A.; PEREIRA, S. R.; SOUZA, M. V. A. Metodologias Ágeis: Um exemplo de aplicação da Extreme Programming (XP). Fasci-Tech - Periódico Eletrônico da FATEC, São Caetano do Sul, v. 1, n. 3, pág. 163 a 177, 2010. FIGUEIREDO, A. L. G. ECO - Um ecossistema para o desenvolvimento ágil de sistemas web. 137 pág. Dissertação (Mestrado) - Universidade de São Paulo, São Carlos, 2005. GONÇALVES JR., J. P. O uso da metodologia XP no desenvolvimento de software e os impactos na gestão de riscos. 49 pág. Monografia (Sistemas de Informação) - Centro Universitário da Fundação Octávio Bastos, São João da Boa Vista, 2009. MACEDO, O. A. C. Diretrizes para desenvolvimento de linhas de produtos de software com base em Domain-Driven Design e métodos ágeis. 153 pág. Dissertação (Mestrado) - Universidade de São Paulo, São Carlos, 2009. OLIVEIRA, R. M. Um estudo sobre o espaço de trabalho informativo e o acompanhamento em equipes ágeis de desenvolvimento de software. 114 pág. Dissertação (Mestrado) - Universidade de São Paulo, São Paulo, 2012.
42
SOMMERVILLE, I. Engenharia de Software 8a. Edição. Pearson Addison-Wesley, 2007. TELES, V. M. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. Novatec, 2004.
