Upload
buitu
View
222
Download
3
Embed Size (px)
Citation preview
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 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
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-
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)
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.
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.
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
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.
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.
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
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
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)
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
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.
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
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;
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, é 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
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).
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.
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
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
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).
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;
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)
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.
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-
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
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,
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.
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
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.
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
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
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.
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
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.
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.
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.
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.
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.
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.