42
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 - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

  • Upload
    buitu

  • View
    222

  • Download
    3

Embed Size (px)

Citation preview

Page 1: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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

Page 2: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 Marin-gá 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

Page 3: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 requi-

sito parcial para a obtenção do título de Especialista em Desenvolvimento de Siste-

mas para Web pelo Departamento de Informática da Universidade Estadual de Ma-

ringá. O candidato apresentou o trabalho para a Banca Examinadora composta pe-

Page 4: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

los professores abaixo assinados. Após a deliberação, a Banca Examinadora consi-

derou 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)

Page 5: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 desafi-os para alcançar mais esta conquista.

Page 6: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 neces-sá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 so-bre os procedimentos.

Page 7: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

EPÍGRAFE

”Não é necessário pintar um grande quadro ou fazer uma grande desco-berta para ser criativo, porquanto criativos são todo pensamento e toda ação que nos sublimam, afastando-nos dos instintos arcaicos e tornando-nos mais humanos.”

GIACOMO DAQUINO

Page 8: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

RESUMO

Este trabalho aborda o uso da metodologia de desenvolvimento ágil XP em uma em-presa brasileira do setor de óleo e gás. Uma pesquisa exploratória e qualitativa bus-cou analisar a aplicação dos valores, práticas e princípios da metodologia na imple-mentaçã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 extre-ma, XP, Valores, Práticas, Princípios.

Page 9: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 ne-cessary for its implementation and the results achieved.

Keywords: Software engineering, Agile methodologies, Extreme programming, XP, Values, Practices, Principles.

Page 10: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

LISTA DE ILUSTRAÇÕES

Página

Figura 1 Ciclos de planejamento e feedback 18

Figura 2 Práticas da Extreme Programming 20

Figura 3 Tela padrão para buscas 27

Figura 4 Tela padrão para inserções/alterações 28

Figura 5 Ambiente de trabalho 29

Page 11: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

LISTA DE TABELAS

Página

Tabela 1 Principais papeis na XP 17

Tabela 2

Valores da XP na UNIBRASPE

30

Tabela 3

Práticas da XP na UNIBRASPE

31

Tabela 4 Princípios da XP na UNIBRASPE 33

Tabela 5 Princípios do Agile Manifesto na UNIBRASPE 34

Page 12: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

LISTA DE ABREVIATURAS E SIGLAS

ERP Enterprise Resource Planning (Sistema Integrado de Gestão Empresarial)

FDD Feature Driven Development (Desenvolvimento Guiado por Funcio-nalidades)

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)

Page 13: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

SUMÁRIO

Página

1. Introdução 13

2. Fundamentação Teórica 14

2.1 Engenharia de Software 14

2.2 Surgimento dos Métodos Ágeis de Desenvolvimento de Software 14

2.3 Surgimento da Extreme Programming 14

2.4 Agile Alliance 15

2.5 Agile Manifesto 15

3. Extreme Programming 17

3.1 Valores da Extreme Programming 18

3.2 Práticas da Extreme Programming 19

3.3 Princípios da Extreme Programming 22

3.4 Quando não Utilizar a Extreme Programming 23

4. Exemplo de Aplicação da Extreme Programming 25

4.1 Empresa UNIBRASPE 25

4.2 Projeto 25

4.3 Valores da XP na UNIBRASPE 30

4.4 Práticas da XP na UNIBRASPE 31

4.5 Princípios da XP na UNIBRASPE 33

4.6 Princípios do Agile Manifesto na UNIBRASPE 34

5. Apresentação e Discussão dos Resultados 37

5.1 Aplicação dos Valores, Práticas e Princípios 37

5.2 Desafios 37

5.3 Benefícios 38

5.4 Adaptações 38

6. Considerações Finais 40

Referências Bibliográficas 41

Page 14: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 do-

cumentação, seguindo passos rigorosos desde o levantamento de requisitos, análi-

se, projeto, codificação, testes e manutenção (SOMMERVILLE, 2007). No modelo

ágil, se enfatiza a obtenção de funcionalidades executáveis que possam ser agrega-

das 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 sub-

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

Page 15: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

15

2. Fundamentação Teórica

2.1 Engenharia de Software

Engenharia de software é a área de conhecimento dentro da ciência da com-

putaçã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 documenta-

dos 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 resul-tantes da convergência de computadores e sistemas de comunica-ção, e as complexas interfaces com o usuário, impuseram novos de-safios aos engenheiros de software. Como muitas empresas ainda não aplicam as técnicas de engenharia de software de forma efeti-va, 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 Program-

ming (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 pre-

gam 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 progra-

maçã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

Page 16: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

16

extremo, com revisão constante do código, através da programação em pares, tes-

tes 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 compro-

misso 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á consagra-

dos 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 prin-

cí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;

Page 17: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

17

10. Simplicidade;

11. Equipes auto-organizáveis geram melhores resultados;

12. Reflexão periódica.

Page 18: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

18

3. Extreme Programming

XP é uma metodologia ágil para desenvolvimento de software, é recomenda-

da 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 siste-

ma 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 equi-pe 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 investi-mento 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 reu-

nir 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 co-dificar 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 pre-sente 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

Page 19: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 feed-back

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 ins-

tantâ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 aca-

ba facilitando a transmissão da mensagem e sua compreensão (TELES, 2004).

Page 20: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 fo-

cado 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 pos-

sível, garante velocidade no desenvolvimento e facilidade na manutenção.

Respeito (Respect): O respeito é o valor que sustenta os demais, sem res-

peito 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 com-

preensão entre todos os membros da equipe é fundamental.

Coragem (Courage): Por ser uma metodologia relativamente nova e ser con-

trá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 man-

ter o projeto simples, permitindo que o cliente priorize as funcionalidades que deve-

rã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 represen-

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

Page 21: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

21

Figura 2 - Práticas da Extreme ProgrammingFonte: 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 ver-

sõ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 conhe-

cimento 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

Page 22: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

22

forma mais clara e simples. Esta prática facilita a comunicação entre o desenvolve-

dor 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 cus-

to 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 fle-

xibilidade 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 funcionalida-

des. Esta prática traz vários benefícios: revisão constante do código; redução de er-

ros; 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 é es-

sencial 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 planeja-

mento 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

Page 23: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 determi-

nada 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 simples-mente aplicar todas as práticas, sem considerar os princípios e valo-res por trás delas não era uma abordagem efetiva. O que faz senti-do, 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 comporta-mento 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 aprendi-

zagem (CASADEI; LODDI; PEREIRA; SOUZA, 2010), facilitando a correção de pro-

blemas e ajustes necessários para melhorar o uso do software.

Presumir simplicidade (Assuming simplicity): Um sistema grande e comple-

xo é 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 es-

copo, a equipe deve estar preparada para estas mudanças, executando as mesmas

no menor tempo e custo possível (MACEDO, 2009).

Page 24: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 de-

vem ser encaradas como a oportunidade de tornar o cliente mais competitivo, entre-

gando 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 desenvolvi-

mento 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 desenvolvi-mento e a entrega incrementais não são a melhor abordagem. Es-ses são sistemas muito grandes, nos quais o desenvolvimento pode envolver equipes que trabalham em locais diferentes; alguns siste-mas embutidos; nos quais o software depende de desenvolvimento de hardware e alguns sistemas críticos, nos quais todos os requisi-tos devem ser analisados quanto a interações que possam compro-meter 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;

Page 25: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

25

Os limites exatos da XP ainda não estão claros. Porém, existem al-guns estraga prazeres que fazem a XP não funcionar; grandes ti-mes, clientes desconfiados, tecnologias que não suportam elegante-mente as modificações. (BECK, 2004, p. 151)

Page 26: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 bio-

combustíveis, sendo considerada uma base primária onde seus clientes (distribuido-

ras) 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 em-

presarial (ERP) da TOTVS chamado Microsiga Protheus em sua versão 10. O siste-

ma 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 empre-

sa optou por deixar o seu próprio departamento de informática responsável pelo pro-

jeto. 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 su-

pervisão, administração e faturamento.

Page 27: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 prin-

cipal negócio da UNIBRASPE é armazenar e devolver combustíveis. A armazena-

gem ocorre de duas formas, a principal é o recebimento dutoviário, os clientes (distri-

buidoras) da UNIBRASPE compram gasolina e diesel da REPAR. Diariamente a RE-

PAR bombeia os produtos comprados que são armazenados nos tanques da UNI-

BRASPE. A segunda forma de armazenagem é rodoviária, as distribuidoras com-

pram biocombustíveis (biodiesel e etanol) de usinas e transportam até a UNIBRAS-

PE 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 carre-

gamento (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 carre-

gamento. 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 esco-

lha 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 tes-

tar 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 cli-

entes 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, ini-

ciou-se a primeira “reunião”, para saber quais eram as prioridades e iniciar o desen-

Page 28: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 desenvolvi-

das, 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 ca-

dastro, 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

Page 29: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

29

Figura 4 - Tela padrão para inserções/alterações

Após o desenvolvimento dos principais cadastros, foi entregue a primeira ver-

sã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 aponta-

ram 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,

Page 30: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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

Page 31: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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.

ValorAdota:

SIM / NÃO / PARCIAL

Justificativa

Comunicação SIM O sucesso do projeto e sua agilidade é diretamente proporcio-nal 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 comuni-carem 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 cli-ente rapidamente é necessário manter o projeto simples e co-dificar apenas o necessário.

Feedback SIM Os comentários sobre uma decisão tomada ou sobre os re-cursos de uma nova versão devem ser rápidos e de conheci-mento 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 res-ponsabilidade.

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 discu-tido, até que um entendimento fosse encontrado.

Tabela 2 - Valores da XP na UNIBRASPE

Page 32: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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.

ValorAdota:

SIM / NÃO / PARCIAL

Justificativa

Jogo de planeja-mento

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 dis-ponibilizados.

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 for-ma mais “enxuta” e rápida possível.

Time coeso SIM A equipe era multidisciplinar e engajada, era necessário ex-trair 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úme-ro 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 mem-bros da equipe, facilitando e incentivando o feedback.

Posse coletiva 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.

Page 33: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

33

ValorAdota:

SIM / NÃO / PARCIAL

Justificativa

Programação em pares

PARCIAL A prática só era usada em rotinas mais complexas, para ela-boração de alguns testes automatizados e definição de layouts.

Padrões de codifi-caçã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

Page 34: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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.

ValorAdota:

SIM / NÃO / PARCIAL

Justificativa

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 as-sim o direcionamento dos esforços e resolução de problemas.

Presumir simplici-dade

SIM Grande parte do trabalho era encontrar a maneira mais sim-ples e rápida de fazer aquilo que o cliente realmente precisa-va.

Mudanças incre-mentais

SIM O projeto era incremental, a dificuldade era priorizar aquilo que o cliente necessitava e que agregaria maior valor ao ne-gó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 softwa-re 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.

Tabela 4 - Princípios da XP na UNIBRASPE

Page 35: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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.

ValorContribuiu: SIM / NÃO / PARCIAL

Visão da Equipe

Satisfação do clien-te com entrega de software com va-lor agregado

SIM O cliente além de ter o desejo de ver o software funcionan-do e poder usá-lo, se sentia parte do time de desenvolvimen-to, provavelmente pela proximidade com os desenvolvedores e pelo foco dos mesmos em entregar o software com os re-cursos solicitados.

Aceitação a mu-danças nos requisi-tos, 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, ade-quando sua ferramenta em menos tempo que os concorren-tes.

Maior frequência na entrega de software funcio-nando

SIM Entregar software funcionando semanalmente, era o princi-pal objetivo do time de desenvolvimento e trazia benefícios imediatos, desde a validação dos mesmos com testes funcio-nais, a comunicação dos usuários com elogios e críticas so-bre os novos recursos.

Pessoas de negó-cio e desenvolve-dores devem traba-lhar 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, co-laborando 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, contri-buiu de forma decisiva para manter a equipe motivada e en-gajada 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 de-senvolvedores como o cliente se sentiam confortáveis em perguntar e argumentar sobre o projeto a qualquer momento.

Page 36: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

36

ValorContribuiu: SIM / NÃO / PARCIAL

Visão da Equipe

Software execu-tável como métrica primária de pro-gresso

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 progre-dindo.

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 traba-lho 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 me-nor 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 orga-nizáveis geram me-lhores 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, so-luçõ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 melhora-dos, isso tornava a equipe mais eficaz, com refinamentos e ajustes constantes.

Tabela 5 - Princípios do Agile Manifesto na UNIBRASPE

Page 37: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 funda-

mental para o sucesso do projeto, facilitando e fortalecendo os outros valores.

A facilidade de comunicação, proporcionada por um local de trabalho adequa-

do, 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ácu-

los 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 duplici-

dade.

Page 38: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 necessida-

des prioritárias do cliente.

5.3 Benefícios

Dentre os benefícios alcançados com a aplicação da metodologia XP na UNI-

BRASPE, 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 com-

petitiva, uma vez que sua ferramenta se adaptava rapidamente as mudanças e re-

quisitos 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 funci-

ona, mude XP. A adaptabilidade é uma característica das metodologias ágeis, em al-

guns 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 de-

senvolvimento, em vários momentos foi necessário extrapolar estes horários, para

atingir os objetivos do projeto, porém, sempre respeitando os limites e necessida-

des individuais dos membros da equipe.

Page 39: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 tes-

tes 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 tes-

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

Page 40: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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 neces-

sidades.

A eficiência causada pela metodologia, deixou a alta gerência da empresa se-

gura 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 de-senvolvedores 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 matu-

ridade da equipe de desenvolvimento e principalmente a proximidade com o cliente,

ele é fundamental para o sucesso.

Page 41: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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: <http://www.agilemanifesto.org>. 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: <http://www.simpros.com.br/simpros2004/Apresentacoes_PDF/Artigos/Art_05_Simpros2004.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 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.

Page 42: EVERTON ANTONIO RAMOS - espweb.uem.br Antonio Ramos... · Um exemplo de aplicação em uma empresa do setor de óleo e gás MONOGRAFIA DE ESPECIALIZAÇÃO ... Scrum e Feature Driven

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.