Desenvolvimento Ágil de Software: uma abordagem com SCRUM e XP

72
CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA DE MOCOCA CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA – ÊNFASE EM GESTÃO DE NEGÓCIOS Tiago Lucas Lopes de Oliveira DESENVOLVIMENTO ÁGIL DE SOFTWARE: UMA ABORDAGEM COM SCRUM E XP Mococa, SP 2º Semestre/2009

description

Este trabalho estuda duas metodologias ágeis para desenvolvimento de software com o intuito de explorar os benefícios decorrentes da combinação entre elas. As metodologias estudadas, Extreme Programming e Scrum, são caracterizadas pelo desenvolvimento de diversas iterações. Cada iteração resulta em um software, que é aprimorado na iteração subseqüente. Além disso, possuem propriedades complementares: Extreme Programming atenta principalmente para o processo de desenvolvimento do software, enquanto Scrum volta-se para o gerenciamento da equipe que o desenvolve. Com o intuito de demonstrar os benefícios da combinação dessas metodologias, este trabalho: estuda os processos para desenvolvimento de softwares, focalizando o desenvolvimento ágil, apresenta o Extreme Programming e o Scrum, discutindo seus métodos e investiga métodos de combinação entre as duas metodologias.

Transcript of Desenvolvimento Ágil de Software: uma abordagem com SCRUM e XP

CENTRO PAULA SOUZA

FACULDADE DE TECNOLOGIA DE MOCOCA

CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA – ÊNFASE

EM GESTÃO DE NEGÓCIOS

Tiago Lucas Lopes de Oliveira

DESENVOLVIMENTO ÁGIL DE SOFTWARE: UMA ABORDAGEM COM SCRUM E XP

Mococa, SP 2º Semestre/2009

TIAGO LUCAS LOPES DE OLIVEIRA

DESENVOLVIMENTO ÁGIL DE SOFTWARE: UMA ABORDAGEM COM SCRUM E XP

Monografia apresentada à Faculdade de Tecnologia de Mococa,

como parte dos requisitos para a obtenção do título de Tecnólogo em

Informática – Ênfase em Gestão de Negócios.

Orientadora: Sandra Cristina Costa

Co-orientador: Orlando Clínio Patriarcha

Mococa, SP 2º Semestre/2009

TIAGO LUCAS LOPES DE OLIVEIRA

DESENVOLVIMENTO ÁGIL DE SOFTWARE: UMA ABORDAGEM COM SCRUM

E XP

Monografia apresentada à Faculdade de Tecnologia de Mococa, como parte dos requisitos para a obtenção do título de Tecnólogo em Informática – Ênfase em Gestão de Negócios. Orientadora: Profª Drª Sandra Cristina Costa Co-orientador: Orlando Clínio Patriarcha ASS. ______________________________________________________ 1º Examinador: Sandra Cristina Costa Instituição: Faculdade de Tecnologia de Mococa ASS. ______________________________________________________ 2º Examinador: Orlando Clínio Patriarcha Instituição: ASS. ______________________________________________________ 3º Examinador: Geraldo Instituição: Faculdade de Tecnologia de Mococa Nota:

Mococa, dia 18 de Dezembro de 2009

Dedico este trabalho a todos aqueles que tornaram suas vidas inspiração para meus ideais, deixaram um pouco de poesia e revolução não ao mundo, mas a todos que tem o desejo de sonhar.

AGRADECIMENTOS

Após finalizar este trabalho, não pude deixar de aproveitar este espaço e agradecer

aqueles que tornam minha vida uma batalha agradável a travar.

ü Agradeço primeiramente a Deus, que por intercessão de sua mãe sempre me atendeu

mesmo que não soubesse. Tenho tudo, todo o necessário e a certeza de que essa é a

graça.

ü A professora Sandra, que teve paciência e tranqüilidade em acreditar nesse trabalho.

Agradeço pela boa vontade e tempo dedicado.

ü Ao meu amigo e co-orientador Orlando, seu apoio foi determinante para a realização

deste trabalho, agradeço também pela inspiração e indicações durante todo o

desenvolvimento nessa etapa.

ü A meus pais, Silvio e Elenita. Aprecio o quanto são determinados para criar e viver

uma família. Sem eles nada seria possível. Esse amor é essencial em toda a minha

formação.

ü A minhas irmãs, Daniele, Caroline e Gabriela, acredito que elas merecem ser

lembradas nesse momento, que possam ser inspiradas e assim lutar por todos os seus

objetivos.

ü A meus avós, Zezinho e Genésia, me orgulho muito em ser neto deles, todos os dias

agradeço a Deus pela família que tenho, sinto falta, amo e torço por todos.

ü A minha namorada, Ana Flávia, são mais de dois anos juntos, assim lutamos por

nossos ideais e estamos conquistando mais um objetivo, obrigado por tudo. Todas as

horas de trabalhos e estudos valem a pena quando se tem ao lado pessoas tão

preciosas.

ü A meus amigos, padre Ilsinho, padre Elviro, Luciana, João Paulo, Bruno e Graziela só

tenho a agradecer por todo apoio e parceria durante muitos dos bons e maus momentos

de minha vida.

Não são as espécies mais fortes que

sobrevivem, nem as mais inteligentes, mas

aquelas mais sensíveis à mudanças.

(DARWIN, apud KOSCIANSKI, 2007)

RESUMO

Este trabalho estuda duas metodologias ágeis para desenvolvimento de software com o intuito de explorar os benefícios decorrentes da combinação entre elas. As metodologias estudadas, Extreme Programming e Scrum, são caracterizadas pelo desenvolvimento de diversas iterações. Cada iteração resulta em um software, que é aprimorado na iteração subseqüente. Além disso, possuem propriedades complementares: Extreme Programming atenta principalmente para o processo de desenvolvimento do software, enquanto Scrum volta-se para o gerenciamento da equipe que o desenvolve. Com o intuito de demonstrar os benefícios da combinação dessas metodologias, este trabalho: estuda os processos para desenvolvimento de softwares, focalizando o desenvolvimento ágil, apresenta o Extreme Programming e o Scrum, discutindo seus métodos e investiga métodos de combinação entre as duas metodologias. Palavras-chave: Software; Ágil; Metodologias; Desenvolvimento; Iteração.

ABSTRACT

This paper studies two agile methodologies to software development to explore the benefits of combining them. The methodologies studied, Extreme Programming and Scrum, are characterized by the development of iterations, each resulting in a software program, which is tuned in the subsequent iteration. Besides, both methodologies have complementary features: Extreme Programming turns mainly to software development process, while Scrum focuses on management of the team developing the software. In order to explore the combination of these two methodologies, this paper studies software development processes, focusing on agile development, then it presents Extreme Programming and Scrum, discussing their methods and, finally, it investigates methods of combinations between them. Keywords: Methodologies. Development. Iterations. Process. Agile.

LISTA DE FIGURAS

Figura 1 – Modelo em Cascata – Ciclo de Vida ............................................................... 17

Figura 2 – Sistema de Incremento ..................................................................................... 19

Figura 3 - Prototipação ...................................................................................................... 20

Figura 4 – Modelo em Espiral .......................................................................................... 21

Figura 5 – A realimentação e a adaptação iterativa levam ao sistema desejado.

A instabilidade dos requisitos diminuem com o tempo ...................................................... 23

Figura 6 – Termos relativos ao cronograma em PU .......................................................... 24

Figura 7 – Disciplinas em PU ............................................................................................ 25

Figura 8 – Tipos de conclusão de projetos ........................................................................ 27

Figura 9 – Ciclo de vida do XP ......................................................................................... 44

Figura 10 – Variáveis do Sprint ......................................................................................... 49

Figura 11 – Modelo Sprint Backlog .................................................................................. 50

Figura 12 – Exemplo Sprint Backlog ................................................................................ 51

Figura 13 – Modelo de Sala de Equipe .............................................................................. 52

LISTA DE SIGLAS

AOO – Análise Orientada a Objetos

POO – Programação Orientada a Objetos

PU – Processo Unificado (Unified Process)

RUP – Rational Unified Process

UML – Unified Modeling Language

XP – Extreme Programming

PDCA – Plan, Do, Check and Act.

SUMÁRIO

1. INTRODUÇÃO ............................................................................................................. 12

2. PROCESSOS DE SOFTWARE E DESENVOLVIMENTO ÁGIL ......................... 14

2.1 PROCESSOS DE SOFTWARE ................................................................................... 14 2.1.1 Modelo em Cascata .................................................................................................. 16 2.1.2 Modelo Incremental ................................................................................................. 17 2.1.3 Prototipação ............................................................................................................. 18 2.1.4 Modelo em Espiral ................................................................................................... 20 2.2 PROCESSO UNIFICADO ........................................................................................... 21 2.2.1 RUP ........................................................................................................................... 25 2.3 DESENVOLVIMENTO ÁGIL .................................................................................... 25

3. EXTREME PROGRAMMING ................................................................................... 30

3.1 CLIENTE PRESENTE ................................................................................................. 30 3.2 JOGO DO PLANEJAMENTO ..................................................................................... 33 3.2.1 Responsabilidades .................................................................................................... 33 3.2.2 Estimativas de Estórias ........................................................................................... 34 3.2.3 Releases ..................................................................................................................... 35 3.2.4 Iterações .................................................................................................................... 36 3.3 STAND UP MEETING ................................................................................................ 37 3.4 PROGRAMAÇÃO EM PAR ........................................................................................ 38 3.5 REFACTORING .......................................................................................................... 39 3.6 DESENVOLVIMENTO GUIADO POR TESTES ...................................................... 39 3.7 CÓDIGO COLETIVO .................................................................................................. 40 3.8 CÓDIGO PADRONIZADO ......................................................................................... 40 3.9 DESIGN SIMPLES ...................................................................................................... 41 3.10 METÁFORA .............................................................................................................. 42 3.11 RITMOS SUSTENTÁVEL ........................................................................................ 42 3.12 INTEGRAÇÃO CONTINUA ..................................................................................... 43 3.13 CICLO DE VIDA DO XP .......................................................................................... 43

4. SCRUM .......................................................................................................................... 45

4.1 PRODUCT BACKLOG, PRODUCT OWNER E PRIORIZAÇÃO DE ESTÓRIAS . 45 4.2 PLANEJAMENTO DO SPRINT ................................................................................. 47 4.3 SPRINT BACKLOGS .................................................................................................. 49 4.4 SALA DA EQUIPE ...................................................................................................... 51 4.5 REUNIÕES DIÁRIAS ................................................................................................. 52 4.6 APRESENTAÇÃO DE SPRINTS ................................................................................ 52

4.7 RETROSPECTIVA DE SPRINTS ............................................................................... 52 4.8 COMBINAÇÃO ENTRE EXTREME PROGRAMMING E SCRUM ....................... 53

4.8.1 Programação em Par ............................................................................................... 53 4.8.2 Desenvolvimento Orientado a Testes (TDD) ......................................................... 54 4.8.3 Design Incremental .................................................................................................. 55 4.8.4 Integração Contínua ................................................................................................ 55 4.8.5 Propriedade Coletiva do Código ............................................................................ 56 4.8.6 Ambiente de Trabalho Informativo ....................................................................... 56 4.8.7 Padrão de Codificação ............................................................................................. 56 4.8.8 Ritmo Sustentável e Trabalho Energizado ............................................................ 57

5. ESTUDO DE CASO ..................................................................................................... 58

5.1 O PROJETO ANCAR2GO ........................................................................................... 58 5.2 ASPECTOS POSITIVOS DO PROJETO .................................................................... 59 5.2.1 Integração Contínua ................................................................................................ 59 5.2.2 Deployment Automatizado ...................................................................................... 60 5.2.3 Testes ......................................................................................................................... 60 5.2.4 Programação em Par ............................................................................................... 61 5.3 DESAFIOS TÉCNICOS ............................................................................................... 62 5.4 PREVAYLER ............................................................................................................... 64 5.5 RELACIONAMENTO DE TI COM A ORGANIZAÇÃO .......................................... 65 5.6 PRECISA MELHORAR ............................................................................................... 66 5.7 RELACIONAMENTO COM OS SHOPPINGS .......................................................... 66 5.8 EXTREME PROGRAMMING E SCRUM NO SGSC ................................................ 67

6. CONSIDERAÇÕES FINAIS ....................................................................................... 68

REFERÊNCIAS ................................................................................................................ 70

12

1 INTRODUÇÃO

A Engenharia de Software traz consigo diversos modelos para o processo de

desenvolvimento de software, muitos deles foram criados com um pensamento que não cabe a

essa forma de trabalho. Alguns modelos como, por exemplo, o modelo em cascata, são

baseados em modelos da fabricação industrial, os quais não parecem adequados ao

desenvolvimento de software que, sendo um trabalho do conhecimento, não poderia seguir

esse esquema. Por esse e outros motivos, a maioria dos softwares desenvolvidos não chegam

nem a ser entregues, e quando atingem a conclusão tem grande probabilidade de falhar.

Uma alternativa para o modelo em cascata é o desenvolvimento ágil de software, o

qual trabalha baseado em equipes e iterações curtas. Ao fim de cada iteração é entregue ao

cliente um software pronto, funcionando, porém, apenas com uma parte de suas

funcionalidades implementadas. A equipe busca desenvolver segundo as prioridades do

cliente, agregando valor ao produto entregue. Uma das vantagens desse método é sua

facilidade em se adaptar a mudanças e a facilidade quanto a manutenção. Os métodos de

desenvolvimento ágil têm características próprias que contribuem de forma eficaz para que o

desenvolvimento seja ágil, com qualidade.

Um dos métodos ágeis, o Extreme Programming, acontece com equipes pequenas e

médias, trabalha com poucos requisitos e torna imprescindível a presença do cliente durante

todo o desenvolvimento. A programação é feita em pares e seu maior foco é a qualidade do

produto e do seu código de forma que ao final sua facilidade de ser adaptado a mudanças será

satisfatória.

O Scrum, não está direcionado à criação o software propriamente, mas a gerenciar o

projeto e a equipe de forma que sejam rápidos e atinjam os seus objetivos.

Essas metodologias de desenvolvimento podem dar crédito às equipes que trabalham

na criação de softwares, e apoiá-las para que atinjam as expectativas do cliente, possibilitando

que ele saiba o valor do desenvolvimento e tenha consciência de todas as funcionalidades

desenvolvidas.

O objetivo dessa monografia é apresentar uma combinação entre as principais práticas

desses dois modelos. Para isto, está organizada da seguinte maneira:

Capítulo 2: Consiste em apresentar os principais modelos de processos de software da

Engenharia de Software. Depois dessa apresentação, introduz o conceito de desenvolvimento

13

ágil, tal como descreve suas diferenças em relação às formas tradicionais de desenvolvimento,

seus valores e importância para os negócios atualmente.

• Capítulo 3: Apresenta o Extremming Programming, descrevendo todas as suas etapas,

especificando suas funções de forma detalhada e como são desenvolvidas.

• Capítulo 4: Como no capítulo anterior, porém, com o Scrum é apresentado todas as

fases em como esse método funciona e detalhes que o compõe e o torna uma das

metodologias mais usadas no mundo atual. Estuda uma seleção das fases mais

importantes para unir o XP e o Scrum, tornando-se assim, uma maneira ainda melhor

para o desenvolvimento de softwares.

• Capítulo 5: Faz análise de um estudo de caso que demonstra as vantagens,

desvantagens do uso de Scrum e XP na prática do dia-a-dia de uma empresa.

Dessa forma, essas metodologias de desenvolvimento poderão dar crédito às equipes

que trabalham na criação de softwares, atingindo todas as expectativas esperadas pelo cliente,

possibilitando que ele saiba o valor do desenvolvimento, tenha consciência de todas as

funcionalidades desenvolvidas, com qualidade e de forma ágil.

14

2 PROCESSOS DE SOFTWARE E DESENVOLVIMENTO ÁGIL

Este capítulo apresenta o software, tal como seus processos e métodos de

desenvolvimento, a fim de apresentar o desenvolvimento ágil e seus métodos como

contribuintes de melhorias no desenvolvimento com o objetivo de alcançar um

aprimoramento contínuo na criação de softwares.

A Engenharia de Software visa sistematizar a produção, a manutenção, a evolução e a recuperação de produtos intensivos de software, de modo que ocorra dentro de prazos e custos estimados, com progresso controlado e utilizando princípios, métodos, tecnologia e processos em contínuo aprimoramento. (FIORINI, 1998 apud, REZENDE, 2005).

A principal preocupação nessa atividade é desenvolver atingindo todos os objetivos

citados por Rezende, a realizar a produção de um software que cumpra todo o esperado pelo

cliente com qualidade de forma que seja adaptável a mudanças.

2.1 PROCESSOS DE SOFTWARE

Tonsig declara que a Engenharia de Software utiliza a Ciência da Computação e

Matemática para atingir seus objetivos quanto às práticas de desenvolver software. É preciso

saber sobre a necessidade do software para os negócios e a necessidade de sua flexibilidade a

mudanças contando com todas as mutações do mundo dos negócios.

O software não é uma entidade corpórea, trata-se de uma entidade lógica e não física; portanto, não se desgasta, ou seja, pelo uso ou tempo não sofre nenhum tipo de corrosão decorrente de sua própria atividade. O usuário não vê um software em execução (tal qual não vê o movimento dos elétrons), mas poderá verificar ou sentir os efeitos da sua existência, além de poder enxergar e interagir com sua interface caso exista. (TONSIG, 2003, p. 54).

Dessa forma, o software, resultado da engenharia, é o grande objetivo, com qualidade,

eficiência e viabilidade. Segundo Tonsig (2003), “o software como um conjunto de

componentes abstratos encapsulados na forma de procedimentos, funções, módulos, objetos

15

ou agentes.” A partir disso, a principal função da engenharia é propor modelos e processos

quais apresentem os melhores métodos e ferramentas para o planejamento e gerenciamento

dos projetos de desenvolvimento de software.

Segundo Pressman o processo é uma das camadas que formam a engenharia de

software e é tido como apoio, alicerce. É o responsável pela união de todas as camadas da

tecnologia e favorece a criação eficiente e oportuna de softwares.

Os processos de software formam a base para o controle gerencial de projetos de software e estabelecem o contexto no qual os métodos técnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios, formulários etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas. (PRESSMAN, 2006, p. 17).

Assim, a Engenharia de software fornece métodos e ferramentas que auxiliam na

produção de softwares. Os métodos são definidos como técnicas para o desenvolvimento e as

ferramentas que definem a base de qualquer projeto de software. Um framework1 de processo

é o esqueleto, o alicerce do projeto, onde é aplicada uma série de trabalhos co-relacionados

que tem como resultado um produto da engenharia de software. Nele existem algumas

atividades que podem ser usadas na maioria dos projetos de softwares, são elas:

- Comunicação: levantamento dos requisitos através de boa comunicação e cooperação

com os clientes.

- Planejamento: Descrição das tarefas técnicas, cronograma de trabalho, riscos,

recursos, e produtos finais.

- Modelagem: Modelos que permitem ao cliente ter uma noção de como será o

software, através disso os requisitos são reavaliados e são feitas as últimas alterações antes de

implementação (construção).

- Construção: Manipulação dos códigos e revisão de erros.

- Implantação: Entrega do produto, seja inteiro ou em partes (incremento), onde o

cliente avalia e faz o feedback2 para que possa ser alterado e melhorado.

1 FRAMEWORK: um framework ou arcabouço é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. Um framework pode atingir uma funcionalidade específica, por configuração, durante a programação de uma aplicação. Ao contrário das bibliotecas, é o framework quem dita o fluxo de controle da aplicação, chamado de Inversão de Controle. 2 FEEDBACK: é o procedimento que consiste no provimento de informação à uma pessoa sobre o desempenho, conduta ou eventualidade executada por ela e objetiva reprimir, reorientar e/ou estimular uma ou mais ações determinadas, executadas anteriormente [

16

Esses cinco tópicos são usados como base em qualquer projeto de software, visto de

forma global têm-se a impressão de que a receita será a mesma, porém isso não acontece pois

cada projeto tem características e detalhes próprios.

A aplicação de modelos de processo tem como objetivo melhorar o gerenciamento e a

qualidade dos projetos, isso é, estabelecer medidas como datas de entregas e previsão de

custos de forma que não corra riscos e os custos da produção não sejam afetados.

Segundo Pressman os modelos ágeis priorizam a gestão do desenvolvimento, se

adéquam facilmente a vários tipos de projeto e são extremamente úteis à aplicações Web.

Assim, esses projetos, seguindo seus princípios acontecem com uma abordagem mais

informal, porém, efetiva e busca obter maior agilidade em seus processos de forma a levar

qualidade e satisfação ao cliente.

2.1.1 Modelo Cascata

Nesse modelo de desenvolvimento, a partir da análise de viabilidade do projeto a

evolução se dá de forma seqüencial, ou seja, uma etapa por vez, em cascata. Esse modelo é

inspirado nos modelos de produção industrial que é marcado por três princípios:

determinismo, especialização e foco na execução.

A Figura 1 mostra as sete etapas que formam o modelo em cascata: análise de

viabilidade, análise de requisitos, projeto, implementação, testes, implantação e manutenção.

Fonte: Livro Engenharia de Software. PRESSMAN, 1995.

Figura 1 - Modelo Cascata - Ciclo de vida Clássico.

Engenharia de Sistemas

Análise

Projeto

Codificação

Teste

Manutenção

17

Na avaliação de viabilidade de desenvolvimento parte-se de três pontos distintos para

ter garantia de que haverá recursos para o projeto. O primeiro avalia as condições de

desenvolvimento em hardware, software, licenças, banco de dados, entre outros. O segundo é

verificar a viabilidade econômica através de uma análise e uma previsão de todos os custos do

projeto, de forma que em sua aprovação, seja possível cobrir todos os recursos do

desenvolvimento. Por fim, o terceiro é verificar a viabilidade operacional, onde é feita a

previsão de todas as alterações e adaptações necessárias ao projeto, como mudança em

procedimentos e choques à normalidade da empresa.

A partir do momento em que o projeto é aprovado por sua viabilidade, é feita a análise

de requisitos, que é uma avaliação que determina quais serão as necessidades dos processos e

informações, de forma que sejam determinados quais serão as funções do software. Essa fase

é feita em conjunto do cliente, pois o projeto deve atender todas as suas especificações.

Inicia-se então a fase de projeto, na qual é desenvolvida a documentação do software,

interfaces para os usuários, banco de dados, etc. Na fase seguinte, a implementação vai seguir

toda a documentação criada na fase anterior e codificar, realizando-se testes para verificar se o

projeto se comporta como o especificado. Esses testes são realizados individualmente e em

conjunto, pois os erros podem ser revelados de diversas formas.

A fase de implantação é a fase na qual o software está concluído e livre para

utilização. Inicia-se com o treinamento dos usuários para que haja eficiência no seu uso, e

todas as ferramentas implementadas estão à disposição. Enfim, a fase da manutenção, ocorre

em todos os projetos de software, o usuário verifica erros ao longo do tempo, necessita de

novas funcionalidades, ajustes requeridos pelos usuários, entre outros.

2.1.2 Modelo Incremental

É uma modificação do modelo em cascata dividindo-se a fase de projeto lógico e

físico. A partir da divisão, esses projetos podem ser decompostos e executados paralelamente.

18

Fonte: Livro Engenharia de Software. PRESSMAN, 2000.

Figura 2 – Sistema Incremental.

“O modelo incremental combina o modelo em cascata com um aplicação iterativa,

porém, e oferece um produto operacional a cada incremento realizado. Tem como objetivo

diminuir o trabalho no desenvolvimento e entregar um produto finalizado a cada incremento”

(PFLEEGER, 2004).

Na figura 2, o cliente resume suas especificações e demonstra sua prioridade ou parte

dos requisitos necessários. Dessa forma, a implementação é feita em iterações, cada iteração é

entregue de forma que o cliente possa perceber novos requisitos ou alterar os existentes e

estes possam ser implementados em novas iterações. O diferencial desse modelo de

desenvolvimento é que essas iterações devem ser feitas de forma que em cada entrega o

cliente receba um aplicativo executável e livre para integração com outras iterações. Assim,

enquanto o software é desenvolvido, o cliente tem a possibilidade de usar algumas

funcionalidades do sistema.

2.1.3 Prototipação

Este modelo faz com que o usuário tenha melhor compreensão do software e

possibilite melhorias no tempo do desenvolvimento. O usuário pode ver como serão os

Definir esboço dos

requisitos

Atribuir requisitos

aos incremento

s

Projetar arquitetura do sistema

Desenvolver incrementos do sistema

Validar incremento

Integrar incremento

Validar Sistema

Sistema Final

19

aspectos visuais do software e suas saídas devidas à interação e assim pode colaborar com o

desenvolvimento conforme seu crescimento. Com isso, ele torna-se parte da equipe de

desenvolvimento, um colaborador e também um dos responsáveis do êxito do software.

Para Tonsig (2003, p. 62), a prototipação é como um desenvolvimento de software

que inicialmente cuida apenas das características de interface com o usuário, resguardando

para uma segunda etapa os demais procedimentos internos de checagem e manipulação dos

dados.

Isso acontece porque o usuário tem uma premissa das respostas de um software ainda

que inacabado, é como um rascunho do que é esperado para o produto final, porém está

sujeito a correções e modificações.

Fonte: Livro Engenharia de Software. PRESSMAN, 1995.

Figura 3 – Prototipação.

Como pode-se observar na Figura 3, Pressman coloca que a Prototipação tem como

opção fazer parte do Modelo em Cascata, como uma forma de auxiliar a ligação entre cliente

e equipe de projeto em definições de requisitos.

O desenvolvimento tem início com a coleta de dados que é usado como apoio na

definição dos requisitos. Os primeiros objetivos a serem definidos são os objetivos globais, os

quais levam em conta tudo que é indispensável para o projeto. A equipe desenvolve o

primeiro protótipo, o qual dará a oportunidade de ver como seria a interface do software, sem

qualidade, e que tenha como foco o objetivo global definido entre equipe e cliente. Após a

avaliação de todos, deve-se determinar com maior sutileza os requisitos de forma que

obtenham maior detalhamento.

Requisitos Projeto Codificação Teste

PROJETO CODIFICAÇÃO TESTE MANUTENÇÃO

Protótipo

Análise de requisitos.

Produto (manutenibilidade,

qualidade)

20

2.1.4 Modelo Espiral

O modelo em Espiral foi desenvolvido por Berry Boehm, com o objetivo de atingir

melhorias quanto aos modelos anteriores. Trata-se de uma espiral, onde os trabalhos

principais partem do centro, e conforme é executado o projeto percorre para o sentido de fora

da espiral.

Fonte: Livro Engenharia de Software, PRESSMAN, 1995.

Figura 4 – Modelo Espiral.

Pressman (1995) divide o modelo em Espiral em quatro partes:

- Planejamento: é a busca das definições de riscos, objetivos e restrições;

- Análise de Riscos: busca-se como resolver os problemas e os melhores caminhos

para alcançar os objetivos do software;

- Engenharia é a parte de desenvolvimento do produto;

- Avaliação pelo Usuário: é o resultado para o cliente, a avaliação do trabalho.

21

2.2 PROCESSO UNIFICADO

Através dos modelos de software convencionais o Processo Unificado seleciona suas

melhores ferramentas e modelos, de forma que possa implementar o desenvolvimento ágil de

softwares.

Entre as décadas de 1980 e 1990, as metodologias e linguagens orientadas a objetos

ganharam impulso na engenharia de software. Em todas as inovações que chegaram junto

com a Engenharia de Software tanto em relação à AOO quanto POO, não houve concórdia

quanto aos métodos a serem utilizados. No início da década de 1990 James Rumbaugh, Grady

Booch e Ivar Jacobson desenvolveram um “método unificado” (PRESSMAN, 2006, p. 52) o

resultado desse trabalho foi a UML. Segundo Larman (2004, p. 34) “UML é uma linguagem

para especificar, visualizar, construir e documentar os artefatos de sistemas de software, bem

como para modelar negócios e outros sistemas que não sejam de software.”

Para Neto (2008) “a UML foi projetada para auxiliar aqueles que participam da

atividade de desenvolvimento de software a construir modelos que permitam visualizar o

sistema, especificar a estrutura, especificar o comportamento, construir o software e

documentar as decisões tomadas”.

Através da UML pode-se ter acesso a diversas ferramentas no apoio à engenharia de

software em OO, porém não tem o mesmo apoio quanto a equipes de aplicação da tecnologia.

A partir disso Jacobson, Booch e Rumbaugh criaram o Processo Unificado (PU), passou a ser

o esqueleto, a armação por trás da engenharia de software orientada a objetos e que usa a

UML.

Larman (2004, p. 38) define o PU como “uma combinação das melhores práticas, tais

como um ciclo de vida iterativo e o desenvolvimento orientado pelos riscos, em uma única e

bem documentada descrição”.

Neto (2008) explica que o PU encaixa-se na definição de processo: um conjunto de

atividades executadas para transformar um conjunto de requisitos do cliente em um sistema de

software.

Para ele o PU também é uma estrutura genérica de processo que pode ser customizado

adicionando-se ou removendo-se atividades com base nas necessidades específicas e nos

recursos disponíveis para o projeto.

22

A maior característica do PU é o desenvolvimento iterativo, que é marcado por aceitar

mudanças e também por sua adaptabilidade. Nesse modelo deve-se dividir o projeto em vários

miniprojetos, os quais terão seu tempo de duração determinado e serão consideradas iterações,

cada uma delas torna-se um projeto independente no qual há análise de requisitos, projeto,

implementação e teste. Toda iteração resulta em um sistema finalizado, testado, integrado e

executável.

As iterações são rápidas, pois exigem apenas uma pequena quantidade de requisitos.

No início as escolhas dos requisitos podem não parecer ao certo o esperado do processo,

porém no PU, os projetos necessitam de um reabastecimento que é adquirido a partir dos

usuários, desenvolvedores e testes. Portanto a idéia principal desse tipo de abordagem é a

progressão, mas não de forma que force o projeto a tomar novas direções e sim de forma que

seja conseqüência do amadurecimento dos requisitos.

Fonte: LARMAN, Craig; 2004.

Figura 5- A realimentação e a adaptação iterativas levam ao sistema desejado. A instabilidade dos

requisitos e do projeto diminuem com o tempo.

O PU é dividido em quatro fases técnicas:

- Concepção: geralmente o modelo de casos de uso é usado como ferramenta, é como

simulações do sistema por usuários que não tiveram contato algum com o software. Os

resultados obtidos e a partir disso é definida uma série de condições e ações do software. Esta

fase tem como objetivo obter uma visão geral do projeto, definições sobre os riscos do

negócio e do projeto e uma melhor definição dos requisitos.

23

- Elaboração: nessa fase é desenvolvido o modelo de análise do PU. Funciona como

um aperfeiçoamento da AOO, uma análise de projeto. Ambas melhoram a evolução do

projeto de arquitetura do software, revisam os riscos e os requisitos do projeto de forma que

tragam garantias à sua elaboração. A conseqüência desta fase é uma elaboração refinada dos

requisitos práticos e os que não foram compreendidos no modelo de casos de casos de uso.

- Construção: são necessárias três ferramentas para a execução dessa fase. Através de

um modelo de implementação é adquirida a manifestação das classes do projeto que passam a

ser transformada para finalizar o sistema. O modelo de implantação organiza todos os

componentes para o ambiente físico de computação. O modelo de teste transmite os

resultados dos testes e garantem sua eficácia no projeto criado.

- Transição: é a finalização de um incremento, ou seja, como o PU divide um projeto e

diversas partes, e cada uma é integrada a um sistema final, é realizado o feedback para

alterações e melhorias na qualidade do projeto.

Fonte: LARMAN, Craig, 2004.

Figura 6- Termos relativos ao cronograma em PU.

As descrições de cada ocupação no PU são conhecidas como disciplinas, elas

demonstram como elaborar ou executar uma determinada atividade de forma que esta esteja

organizada, até que alcance ao longo das iterações o seu ideal. O enfoque passa a ser diferente

com o tempo, a princípio é maior, até que o projeto esteja estável por conseqüência da

realimentação e os requisitos melhor atendidos.

24

As ações e ferramentas no PU são opcionais, devem ser vistos como um tipo de

complemento, aos quais de acordo com a necessidade do projeto são usados como solução.

Porém, algumas práticas e regras são constantes, pode-se citar o desenvolvimento iterativo e

orientado ao controle de riscos e a variação contínua da qualidade.

Entre alguns conflitos surge o PU ágil, tratam-se também alguns métodos ágeis como

os processos pesados e preditivos. O primeiro trata quando um projeto engloba muitos

detalhes no planejamento, preparação e necessita de longo prazo, sem flexibilidade e

controlável e que não aceite mudanças, seja definitivo. Os processos preditivos projetam e

supõem como será o projeto e como serão usados os recursos com antecedência. Tem um

ciclo de vida em cascata ou seqüencial, definem-se todos os requisitos, um projeto minucioso

e por fim faz-se a implementação. Quando o PU foi criado não houve intenção alguma de usar

processos como os pesados e preditivos, ele foi feito para ser usado em um processo ágil que

tem como objetivo ser leve e adaptável, fácil de estabelecer mudanças, e obter resultados.

Fonte: Larman, Craig, 2004.

Figura 7 – Disciplinas do PU.

25

2.2.1 Rational Unified Process

O RUP (Rational Unified Process), é uma estrutura condensada para os processos de

criação de software. Como o PU tem fortes características do desenvolvimento em espiral,

pelo seu processo iterativo e utiliza a UML (Unified Modeling Language), para o projeto e

documentação.

Tem como objetivo inicial demonstrar a estrutura do sistema, com sua arquitetura e

funcionalidade, de forma que essa união resulta no sucesso na entrega do produto. É dividido

em trinta e nove papéis que ajudam na personalização do software, cada membro da equipe

incorpora vários papéis, não é obrigatória a utilização de todos. Aquele que assume um papel

é responsável pelo seu cumprimento.

Como na figura 7, seu ciclo é muito parecido com o formato do PU, é formado por

quatro fases essenciais:

- Iniciação;

- Elaboração;

- Construção;

- Transição.

Algumas de suas principais características são marcadas pelo desenvolvimento

iterativo, pela sua forma de administrar os requisitos, modelagem visual, qualidade e

facilidade a modificações.

2.3 DESENVOLVIMENTO ÁGIL

Qual a importância em ser ágil ao fabricar softwares para o mercado e empresas de

desenvolvimento? Segundo Bueno (2008) ágil é o mesmo que ligeiro, leve, rápido. Sabe-se

que o mercado está em constante mudança, e é necessário tomar determinadas medidas para

acompanhar e suprir todas as suas necessidades.

Em meio ao desenvolvimento atual de software a palavra ágil tem sido sinônimo de

modificações, essas que estão presentes nos requisitos para o desenvolvimento, produção de

26

software, equipes de desenvolvimento, adaptações às novas tecnologias e orientações do

mercado, etc. Pressman (2006) ainda acrescenta à agilidade significados que levam à melhor

comunicação entre todos que interagem na produção e clientes que são inseridos na equipe de

desenvolvimento e que retornam o feedback de forma instantânea aos desenvolvedores,

enfim, à entrega mais rápida do software.

Teles (2006) atribui o termo “Desenvolvimento Tradicional” aos modelos de

desenvolvimento em cascata que ainda são os mais usados atualmente. Como foi citado no

capítulo anterior, esse modelo é a produção de softwares de forma seqüencial, ou seja, seu

desenvolvimento se dá de forma que suas etapas acontecem sucessivamente, onde uma utiliza

o resultado da anterior. Critica ainda esse modelo por ser extremamente falho e ter um alto

índice de fracassos e produtos que não atendem o especificado na análise de requisitos, como

mostra o gráfico:

Tipo 116%

Tipo 253%

Tipo 331%

Tipo 1

Tipo 2

Tipo 3

Fonte: TELES, 2006.

Figura 8 – Tipos de Conclusão de Projetos. Pesquisa do Standish Group sobre a conclusão de projetos de

software (1994).

- Tipo 1 ou Projeto bem sucedido: aquele que atende todas as expectativas, como

tempo, custo e todas as funcionalidades especificadas funcionando.

- Tipo 2 ou Projeto desafiado: onde há entrega do software, porém, não como

combinado anteriormente, ultrapassa o prazo e orçamento, além de não cumprir com todas as

funcionalidades especificadas no início do projeto.

- Tipo 3 ou Projeto fracassado: quando o projeto é cancelado durante o

desenvolvimento.

Teles (2006) aponta que em um novo estudo com dados do ano de 2002, o Standish

Group apontou avanços quanto à conclusão de projetos. A taxa de sucesso passou de 16,2%

27

para 24%, os fracassados de 31,1% para 15% e os desafiados praticamente mantiveram seu

índice por volta dos 51%. Sendo que a maioria dos projetos pesquisados são do

desenvolvimento tradicional que confirma numericamente sobre as falhas do modelo em

cascata.

Toda a evolução do desenvolvimento tradicional junto ao modelo em cascata

comprova a sua ineficácia. Teles utiliza das teorias de Drucker para explicar as duas

categorias de trabalho: trabalho manual e trabalho do conhecimento e coloca o

desenvolvimento de software na segunda categoria, como especifica nesse trecho:

O desenvolvimento de software é um trabalho executado basicamente por trabalhadores do conhecimento. Entretanto, as premissas em que se baseiam o desenvolvimento tradicional somente são válidas para o trabalho manual. Logo existe um problema: o desenvolvimento tradicional se baseia em premissas que não são válidas para o tipo de trabalho que ele envolve. (TELES, 2006, p. 38).

Teles (2006), ainda coloca em foco que o desenvolvimento tradicional tem três

características que segundo Taylor regem a fábrica: determinismo, especialização e foco na

execução. Ele parte do princípio de que esse tipo de desenvolvimento é seqüencial, ou seja,

segue todas etapas de forma linear. Assim, o determinismo trata as transformações das

matérias-primas, a especialização é a divisão do processo de fabricação e por fim agrupando

as duas anteriores têm-se o foco na execução. Não existe criatividade nesse processo de

fabricação, ele existe e o trabalhador a executa, como em uma máquina onde ele é apenas uma

peça.

O determinismo é importante no desenvolvimento tradicional de forma que diminui as

falhas e excesso de tempo, a especialização realiza a divisão de papéis à equipe e, portanto,

com os dois anteriores, possibilita exclusivamente o foco na execução das tarefas pelos

desenvolvedores.

O Desenvolvimento Ágil é uma alusão ao processo em espiral, uma forma de

desenvolvimento iterativo, onde cada fase é executada diversas vezes. Cada iteração tem

como objetivo um software concluído, pronto para o uso, porém, com menos funcionalidades,

dado que no desenvolvimento ágil o projeto é dividido em várias iterações, onde são

especificadas algumas funções a ser desenvolvidas e ao final de todas as iterações tem-se um

software completo que atenda ao máximo possível as exigências do cliente sem que tenha

passado os limites de tempo e orçamento.

Ser incremental é uma das maiores características desse modo de desenvolvimento, de

forma que toda a equipe é integrada à criação do projeto e fases do desenvolvimento que

28

acontecem ao mesmo tempo. O cliente participa da criação do sistema e aprende com ele,

descobre todos os procedimentos técnicos, dá soluções de determinados problemas à equipe,

requisita alterações ao longo do projeto e também recebe idéias de funcionalidades para

solucionar seus problemas pela equipe.

O desenvolvimento ágil foi criado com a expectativa de eliminar os problemas da

Engenharia de Software tradicional, ele fornece diversos benefícios e tem como objetivo o

produto final em um período abaixo do estimado no desenvolvimento tradicional e qualidade

de forma que atenda aos requisitos esperados pela empresa.

Em 2001, Kent Benck junto a uma equipe onde outros 16 desenvolvedores, produtores

e consultores de software assinaram o Manifesto Ágil que leva a, seguinte declaração:

Estamos descobrindo melhores maneiras de desenvolvimento de software fazendo-o e ajudando outros a fazê-lo. Por meio desse trabalho passamos a valorizar: - Indivíduos e iterações em vez de processos e ferramentas. - Software funcionando em vez de documentação abrangente. - Colaboração do cliente em vez de negociação dos contratos. - Resposta a modificações em vez de seguir plano. Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda. (Beck et al, 2009).

No desenvolvimento ágil, o processo de software deve ter quatro valores fundamentais

que determina e contribui de forma eficiente ao sucesso na conclusão de um projeto.

A primeira é o feedback, ao tratar esse elemento deve-se usar o termo realimentação,

essa palavra é pela resposta do cliente ao desenvolvimento fazendo com que a equipe melhore

sempre a cada iteração e o contrário também deve acontecer quando a equipe dá novas opções

em funcionalidades no software de forma que dê melhorias aos processos de controle da

empresa.

A segunda é a comunicação, a responsável por gerar o feedback, o processo ágil tem a

participação contínua do cliente junto à equipe, isso nem sempre acontece pelos clientes não

conseguirem dispor de tempo para participar do desenvolvimento, porém, caso isso aconteça

deve-se negociar ao menos um período diário ou mesmo que a equipe se desloque até o

cliente. É importante que dividam o mesmo espaço, assim, acontece a troca de informações

em tirar a dúvida de ambos quanto ao projeto e funcionalidades, além da comunicação

indireta como conversas paralelas que também podem auxiliar em obter novas idéias e

melhorias no desenvolvimento.

A terceira é ser simples, é necessário apenas que a equipe desenvolva o que o cliente

necessita, não é preciso que o desenvolvimento seja embasado por teorias futuras de

29

funcionalidades que não estão inclusas no projeto, ou seja, a equipe não deve assumir

possibilidades incertas, e todas as dúvidas devem acabar através do cliente. Caso isso não seja

possível, ele assume a forma mais razoável para implementar o software. Teles especifica que

a idéia da simplicidade é evitar o trabalho dispensável, de forma que possa enxugar o tempo

de desenvolvimento e o custo do produto com teorias incertas, assim pode-se dizer que no

desenvolvimento pode-se exercer trabalhos incorretos e incabíveis de forma que trás a solução

em simplificar e eliminar tarefas desnecessárias à produção ágil.

A quarta e última característica necessária a esse tipo de desenvolvimento, ou

produção de software é a coragem, a diferença entre os processos tradicional e ágil são bem

consideráveis, portanto, é necessária que haja coragem para promover o desenvolvimento ágil

no ambiente de produção de software.

30

3 EXTREME PROGRAMMING (XP)

Segundo Teles (2006), o XP é um método de desenvolvimento de software que é

focado em mudanças constantes em projetos com poucos requisitos especificados, orientação

a objeto, equipes de até doze integrantes e por fim, o desenvolvimento iterativo.

O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de um conjunto de valores e práticas que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software. (TELES, 2006, p. 21).

Como citado no capítulo anterior o XP é embasado nos quatro valores do

desenvolvimento ágil de software, feedback, comunicação, simplicidade e coragem. O

feedback é a realimentação tanto da equipe que o desenvolve, quanto o cliente que amplia

seus conceitos quanto às funcionalidades necessárias e participa na melhoria do projeto.

Comunicação tem sua essência nessa forma de desenvolver a fim de atender o software com

exclusividade, assim pode resolver seus problemas e propor melhorias de forma ágil. Ser

simples é seguir somente a direção especificada no projeto. E por fim a coragem, que é

enfrentar todos os desafios para implementar as etapas do desenvolvimento ágil, de forma que

seja segura em garantir sua qualidade com segurança e agilidade.

3.1 CLIENTE PRESENTE

No desenvolvimento em cascata o cliente participa da análise de requisitos de forma

que especifica todas as funcionalidades necessárias ao software, na maioria das vezes não é

eficaz e muito menos eficiente, pois, ele não compreende toda extensão das funcionalidades.

É preciso que o cliente participe do projeto contribuindo pela realização dos valores do XP,

como a simplicidade, de forma que o andamento do projeto seja marcado com pequenos

ajustes para sua melhoria e evitar grandes mudanças ao longo do desenvolvimento, assim, ele

pode contribuir de forma eficaz para o sucesso do projeto.

31

Essa fase é de suma importância, a partir de sua excelência pode-se atingir o seu

sucesso. A comunicação direta e indireta no ambiente de desenvolvimento entre equipe e

cliente, pode levar a ajustes, adaptações e inovações que são fundamentais em um processo

ágil.

O projeto é dividido em diversas estórias3, elas são características breves de

funcionalidades do projeto descritas em cartões. A partir disso, a comunicação passa a ser

essencial, cliente e desenvolvedor destacam os detalhes da estória de forma que possam ter

pontos de vista abrangentes e assim determinar as melhores formas de desenvolvimento.

Existem diversas formas para que o cliente possa contribuir para que o projeto seja

mais ágil, a primeira ao esclarecer a estória a ser implementada, a segunda se dá com o

surgimento de dúvidas durante a implementação da funcionalidade e a terceira ao contribuir

que o desenvolvedor não inclua premissas em seu trabalho, de forma que possa levar o projeto

a mudar seu foco e perder tempo. Existem outros motivos para a participação do cliente, como

o surgimento de idéias e dúvidas em uma comunicação paralela e também ao finalizar o

desenvolvimento de uma funcionalidade o cliente poderá ver se é a forma esperada ou se há

necessidade de mudanças.

Com a presença do cliente no desenvolvimento do sistema há o favorecimento da

realimentação, ou seja, o feedback é executado de forma que a equipe terá todas as

informações necessárias sobre as principais iterações e o esperado pelo cliente, poderá

mostrar ao cliente soluções e problemas não especificados anteriormente, e por outro lado ele

também saberá o quanto estará pagando por cada parte do sistema a ser implementada, pois o

software não pode ser manipulado, de forma que é mais difícil saber seu valor real. Através da

confiança entre as duas partes na participação contínua do cliente no desenvolvimento, ele

terá a percepção do custo e tempo de desenvolvimento, de forma que entenderá o valor a ser

pago pelo produto, ou seja, pelo tempo gasto no desenvolvimento, por conhecimento

acrescido ao sistema e pelo trabalho da equipe.

Nessa fase Teles (2006), aponta como maior dificuldade um cliente realmente

disponível para participar do projeto, porém ele pode ser muito atarefado de forma que não

possa estar integrado ao desenvolvimento. Para resolver isso ele coloca duas situações: o

cliente presente e o cliente totalmente afastado, mas o segundo não garante em nada o projeto

de forma que no mínimo se possa obter um cliente que saiba dividir suas tarefas com a sua

presença no projeto, e caso isso não possa acontecer, a equipe também pode se deslocar até o

3 ESTÓRIA: são cartões contendo as descrições das funcionalidades a ser implementadas no projeto.

32

local de trabalho do cliente, de forma que possam dividir o mesmo ambiente e assim, garantir

a qualidade e agilidade do processo. No desenvolvimento do sistema o cliente poderá concluir

seus afazeres, a diferença é que vão dividir a mesma sala, e assim, podem trocar todas as

informações necessárias, isso pode ser considerado como um detector de erros, onde o cliente

irá informar a equipe o caminho certo em todas as dúvidas, e ambos terão conversas informais

de forma que terão a chance de criar novas idéias e terem um melhor ponto de vista em

relação ao sistema como um todo, ou mesmo de uma determinada funcionalidade, a esta sala

onde cliente e equipe de desenvolvedores dividem o mesmo espaço dá-se o nome de sala de

guerra.

Quando não se pode ter a presença contínua do cliente no projeto o ideal é criar uma

agenda, onde cliente e equipe devem se encontrar algumas vezes ao longo do dia, dessa forma

eles não irão dividir o mesmo espaço perdendo a comunicação informal e a resolução das

dúvidas de forma mais rápida, porém ainda existe um bom nível de confiança, comunicação,

feedback e o cliente pode continuar suas obrigações normalmente. Outra situação é quando o

cliente não pode acolher a equipe por falta de espaço, a solução é que a equipe se instale em

um lugar próximo ao cliente para que possam se encontrar algumas vezes no dia. Caso a

empresa possa acolher a equipe o cliente ou seu representante deve ser deslocado para a sala

em que a equipe irá trabalhar.

Sem a presença do cliente perde-se a confiança no projeto e o feedback e a

realimentação também são extintos, pode-se saber a principal causa através de DeMarco:

Trata-se de um problema central: o afastamento entre cliente e equipe é uma das causas essenciais dos fracassos nas iniciativas de software. Os grandes problemas desta indústria são sobretudo sociais e pouco tem a ver com a tecnologia (DeMarco, 1987, p.4). Não são questões técnicas, mas sim reflexos das estruturas e dos relacionamentos humanos envolvidos no projeto. (DEMARCO, 1987 apud TELES, 2006).

É necessário criar uma reorganização dos processos e incluir o cliente de forma que o

objetivo seja alcançado de forma eficaz. Ao desenvolver o XP, o primeiro desafio requerido é

a inclusão do cliente no ambiente de desenvolvimento, esta ferramenta deve ser muito bem

usada, de forma corajosa, para que o projeto obtenha sucesso. É preciso também mudar a

divisão de responsabilidades, onde o cliente paga e os fins alcançados em um sistema são

inteiramente responsabilidade da equipe de desenvolvimento. A participação do cliente em

um sistema é de suma importância, pois, por ele não ter todo o conhecimento técnico em

33

relação ao desenvolvimento de software não poderá especificar todas as funcionalidades

esperadas em uma análise de requisitos.

3.2 JOGO DO PLANEJAMENTO

3.2.1 Responsabilidades

A fase do jogo do planejamento, segundo Teles, é usado no XP de forma que os

desenvolvedores estejam sempre implementando as prioridades dos clientes, ela acontece ao

longo de todo o projeto, de forma que qualquer alteração no percurso esteja dentro do

planejamento feito pela equipe.

A divisão das responsabilidades se dá na divisão dos papéis, onde negócios são

dirigidos ao cliente e a questão técnica é incorporada pela equipe. Com base nessa divisão

têm-se o direito de cada parte. São direitos do cliente:

- Ter um plano geral com informações sobre possibilidades, tempo e preço;

- Receber todo o valor do trabalho semanal da equipe;

- Acompanhar o desenvolvimento do projeto com um sistema executável, pronto para

o uso, que passe nos testes especificados pelo cliente;

- Mudar os requisitos e funcionalidades, sem ter que pagar um preço muito alto;

- Se informados sobre mudanças no projeto de forma que possa decidir manter o

escopo ou alterá-lo para cumprir o tempo determinado. Cancelar o projeto e ficar com o

sistema desenvolvido e investido até a data do cancelamento.

E direitos da equipe:

- Saber as necessidades e prioridades do cliente quanto ao sistema;

- Trabalhar de forma que o resultado seja de qualidade permanente;

- Pedir ajuda a colegas e cliente;

- Criar e atualizar as expectativas;

- Escolher a estória a ser desenvolvida sem imposição.

34

A estória é um pequeno cartão, funciona na verdade como um convite a uma conversa

onde cliente e desenvolvedor poderão entrar num consenso sobre a funcionalidade a ser

desenvolvida, ela deve ser escrita pelo cliente em poucas palavras de maneira que especifique

a funcionalidade da forma mais simples possível, transmitindo apenas o que é esperado.

Assim ele terá de raciocinar sobre o que estará escrevendo e terá uma melhor amplitude do

que deseja.

Para Teles (2006), existe um vínculo psicológico entre o cliente e a estória por vários

fatores como o fato de que o cliente é responsável pelo que é requisitado no cartão, para que o

cliente possa entender o valor de cada especificação feita, fazendo assim que ele possa

demonstrar suas prioridades de acordo com o custo de cada funcionalidade solicitada. Este é

mais um fator que reforça o item anterior, cliente presente, por ele ter consciência do custo de

um projeto de software.

Geralmente o desenvolvedor escolhe a estória que deseja implementar, estas

geralmente tem a duração de um dia. De acordo com o tamanho do projeto, essas estórias

podem ser transformadas em tarefas, em outros cartões para ser desenvolvidos por todos os

desenvolvedores como estórias e a duração podem variar em um tempo maior.

3.2.2 Estimativas de Estórias

“O XP utiliza o conceito de dia ideal de desenvolvimento, que representa um dia no

qual o desenvolvedor só trabalha na implementação de funcionalidades, sem ter que se

preocupar com nenhuma atividade extra.” (TELES, 2006, p. 73).

O valor do projeto depende das estimativas feitas em cada estória, elas são medidas

através do tempo que cada desenvolvedor irá consumir em sua produção. Assim pode-se dizer

que no XP todas as estimativas são feitas com base do dia ideal, cabe ao desenvolvedor saber

quanto tempo irá usar para implementar uma funcionalidade sem ser interrompido por

telefone, reuniões, etc.

Cada dia ideal de desenvolvimento para dois programadores é considerado um ponto,

pode-se usar outro significado a ele de acordo com o projeto, mas no XP o usual é esse. Será

demonstrado nas próximas etapas que nessa forma de desenvolvimento costuma-se usar a

35

programação em par. Esses pontos são registrados na estória de forma que possa fazer com

que o cliente saiba o quanto estará pagando por cada funcionalidade.

As estimativas devem ser feitas por comparação, em equipe e cliente reunidos, usando

estimativas realizadas no passado e que sejam parecidas de forma que possam chegar o mais

próximo possível da quantidade de pontos realmente usada no desenvolvimento e com a

presença do cliente de forma que seja feita com todo o esclarecimento possível e cuidando

para que ele não force diminuir o tempo estimado (cliente), o mínimo de sentimentos possível

e o máximo de conhecimento técnico possível (equipe).

3.2.3 Releases

Como visto anteriormente, o desenvolvimento ágil acontece de forma incremental,

sendo que cada incremento é entregue um sistema pronto, executável, porém com menos

funcionalidades. No XP um release é um grupo de funcionalidades que tem um valor

determinado para o cliente, geralmente são pequenos de forma que o cliente tenha acesso às

suas funcionalidades o mais rápido possível.

Segundo Teles (2006), no início de um projeto em XP, cliente e equipe devem dividir

o projeto em releases, pequenos e parecidos, devem priorizar quais levam mais valor ao

cliente e após essa divisão, as estórias são distribuídas entre eles.

As estórias são desenvolvidas ao longo do projeto, após utilizar o sistema criado no

primeiro release, o cliente terá uma noção melhor em como o sistema e seu desenvolvimento

acontece e poderá melhorar as futuras estórias. Porém, é indicado ao cliente que se preocupe

apenas com a estória que está sendo usada e conforme o avanço do projeto ele irá identificar

novas estórias necessárias ao seu sistema.

Durante todo o projeto ele poderá criar novas estórias conforme identifique novas

prioridades e também remover aquelas que não serão mais necessárias. Isso se dá pelo seu

aprendizado com o avanço do projeto, assim, poderá identificar melhor suas necessidades e

também receber indicações por parte da equipe para melhorias do sistema.

O fim de um release acontece com a conclusão de todas as iterações determinadas a

ela, seguido da implantação do sistema desenvolvido para o cliente, e por fim, há o feedback,

36

de forma que haverá realimentação de informações para a equipe e assim, nos releases

seguintes haverá maior possibilidade de que a equipe possa suprir as necessidades do cliente.

3.2.4 Iterações

“Um release, mesmo que seja pequeno, representa um tempo muito longo para o

desenvolvimento em XP. Por essa razão, cada release é dividido em unidades de tempo

menores, conhecidas como iteração.” (TELES, 2006, p. 79).

Para ele, a iteração é uma parte de um release, um pequeno prazo dedicado ao

desenvolvimento de um grupo de estórias. O prazo médio de um release são duas semanas de

forma que contribua com o feedback e obtenha aprendizagem necessária.

A reunião de planejamento de iteração faz uma estimativa de tempo através dos pontos

das estórias conhecida como velocidade da iteração, determinar a quantidade de pontos que

serão desenvolvidos pela equipe.

O cálculo feito para saber quantos pontos serão implementados em uma iteração por

uma determinada equipe é o seguinte forma, faz-se o cálculo do número de dias úteis, subtrai-

se dois dias para reuniões de planejamento e encerramento da iteração, multiplica-se pelo

número de desenvolvedores e por fim divide-se por dois, pois o XP é marcado pelo

desenvolvimento em par, assim, é obtido o número de pontos necessários para criar uma

iteração.

“Em inglês, costuma-se usar o termo yesterday’s weather (o tempo do dia anterior)

para nomear a estratégia usada pelo XP.” (TELES, 2006, p. 82). Sua função é prever a

quantidade de pontos que a equipe suporta implementar, a partir disso esses pontos são

oferecidos ao cliente para que ele selecione de acordo com sua prioridade quais iterações

serão desenvolvidas. Essa previsão é feita com base no que foi implementado na última

iteração, assim, os pontos são somados e dispostos ao cliente, quando a equipe ultrapassa os

pontos no desenvolvimento ou não consegue cumpri-los a previsão é atualizada sempre com

base na última iteração. Todavia não é aconselhável abrir exceções ao cliente, de maneira que

ele possa tentar levar os desenvolvedores a sempre aumentar os pontos para o

desenvolvimento, isso pode gerar conflitos entre equipe e cliente por muitas vezes não

37

conseguir cumprir esses pontos no desenvolvimento, assim a preferência é que a equipe

entregue sempre os pontos que suporta desenvolver.

O indicado no XP é que a equipe siga a ordem de desenvolvimento desejada pelo

cliente, dessa maneira ele ficará satisfeito gerando mais valor ao desenvolvimento. Para isso a

equipe precisa contar com sua criatividade e empenho para solucionar os problemas e atender

as prioridades do cliente. Quando não há sucesso em resolvê-los, a equipe precisa tornar

explícito ao cliente os motivos e criar uma nova ordem para seguir o desenvolvimento.

Uma das maiores vantagens do XP é que o cliente pode estar sempre realizando

mudanças nos releases, estórias, prioridades, ao pedir novas ou excluir funcionalidades, etc.

Entretanto, não poderá pedir alterações em uma iteração, deverá esperar o fim de forma que

não atrapalhe o trabalho da equipe e o desenvolvimento deixa de ser ágil.

O fim de uma iteração é marcado por uma reunião onde as funcionalidades são

testadas no sistema e também de testes para verificar se o desenvolvimento cumpriu com da

estória onde é verificado se foi realizado todo o trabalho corretamente.

3.3 STAND UP MEETING

Reunião em pé é uma das características do XP, onde, todos os dias, toda a equipe faz

um reunião de aproximadamente dez minutos e relata todo o desenvolvimento do dia anterior,

é destacado todos os desafios e como foram resolvidos, assim, pode-se ajudar aqueles que

tenham problemas semelhantes, fazem avaliação e faz com que a equipe esteja ciente do

andamento do trabalho. Também é definido nessa reunião como será o andamento do dia

corrente, onde a equipe prioriza os cartões a ser desenvolvidos, de forma que evite os erros

analisados do dia anterior e garanta o resultado com qualidade e agilidade. Todos devem

participar de forma ativa da reunião, mesmo que tenha pouco tempo para expor seu trabalho,

idéias e problemas. Desta forma o que seria dúvida de uma parte do sistema, ou um

desenvolvedor, torna-se solução para o todo, ou seja, a equipe.

38

3.4 PROGRAMAÇÃO EM PAR

A programação em par, ou em inglês, pair programming, trás consigo várias soluções

para tornar o desenvolvimento realmente ágil, pois reúne ao trabalho dos desenvolvedores o

acúmulo de experiências de forma que eles encontrem soluções rápidas, criativas e simples e

também podem corrigir os pequenos erros de programação quase que instantaneamente.

A programação em par pressupõe uma comunicação contínua entre os desenvolvedores que formam o par. Através da conversa, eles discutem as melhores alternativas, corrigem erros, analisam cenários, enfim, discutem as melhores idéias para a resolução de cada problema. Portanto, é absolutamente incorreto acreditar que um trabalha enquanto o outro fica parado. Ambos estão trabalhando o tempo todo. (TELES, 2006, p. 91)

Portanto, dois programadores desenvolvem suas atividades em conjunto e em uma

máquina, geralmente um trabalha com o teclado, segundo Teles este é conhecido como

“condutor” e o outro é o “navegador”, é como um estrategista para melhorar o

desenvolvimento acompanhando o trabalho do condutor.

Teles (2006) ainda coloca que não existem muitos estudos dirigidos à produtividade

em equipes que desenvolvem em par e aquelas que o fazem individualmente, porém destaca

algumas vantagens que em um projeto maior podem ser claramente explícitas: o código

praticamente não apresenta problemas, pois durante sua elaboração é imediatamente revisado

e os problemas são resolvidos de forma mais simples, isso melhora sua manutebilidade.

Apesar de expor essas duas vantagens, em um ponto de vista mais amplo pode-se

perceber que a maior melhoria nesse procedimento é a agilidade. Pois, evita a perda de tempo

com revisões e simplicidade do código.

Durante a implementação muitos se deparam com diversas distrações, a programação

em par contribui em criar uma determinada pressão para que isso não ocorra, ela é chamada

no XP de pair pressure, ou pressão do par. Assim, um sempre irá cobrar o outro de forma que

o foco não seja perdido.

As trocas de par e de funções são de extrema importância no XP, a cada iteração

devem-se trocar os pares, para que não se torne um círculo vicioso podendo trazer danos ao

trabalho. Em relação às funções, os pares devem revezar durante o dia as funções de condutor

e navegador, mas essa troca deve ser natural, deve ser decidida pelo cansaço de digitar, ou

mesmo por não agüentar ficar sem fazer nada, entre outros motivos.

39

Existem alguns desafio quanto essa prática, o escritório deve ser adaptado a dois

usuários por computador, o gerenciamento da equipe deve deixar de lado as práticas

industriais, os desenvolvedores devem ser seguros e abertos ao aprendizado e não pode haver

competição entre a dupla, para que o ambiente possa ser de complementação de experiências

e conhecimentos técnicos e assim, atingir os objetivos esperados.

3.5 REFACTORING

O refactoring tem o objetivo de dar maior legibilidade ao código, assim faz com que a

sua leitura seja mais rápida, contribui caso haja necessidade de futuras modificações no

sistema e também melhor manutebilidade.

Teles (2006), destaca que é uma forma de modificar o código, sem mudar o que é

implementado. Faz o uso de testes para que sua manipulação não condene os seus resultados.

Como visto anteriormente, umas das principais vantagens do desenvolvimento ágil é a

facilidade de modificar, incluir ou excluir uma funcionalidade, o refactoring contribui também

com possíveis manutenções, de forma a garantir a compreensão do código diminuindo as suas

barreiras para a manutenção.

O refactoring torna possíveis os objetivos do desenvolvimento ágil, ele não pode

existir sem essa fase, possibilita as modificações e criação de novas funcionalidades. Leva

risco a falhas por alterações nos códigos, porém, tem como solução os testes, que torna essa

fase segura a garantir todas as expectativas da equipe e cliente.

3.6 DESENVOLVIMENTO GUIADO PELOS TESTES

A programação guiada por testes tem por principal objetivo diminuir o tempo de

depuração de um projeto. Relata as falhas de desenvolvimento à equipe, contribuindo de

forma ágil para a resolução dos problemas.

40

Os principais testes usados são determinados por Beck (2000), da seguinte maneira:

- Teste de unidade: analisa os resultados das funcionalidades para verificar se estão

corretos. São usados quando não houver clareza na interface, detectar situações incomuns,

detectar e isolar erros de código. Seu objetivo é contribuir com o refactoring e tornar o código

claro e sem erros.

- Teste de aceitação: torna seguro o funcionamento correto do sistema, analisa o

relacionamento das estórias. Acontece como um simulador do sistema e a partir do resultado

faz a comparação com o esperado. O teste desenvolvido pelo cliente, a partir disso, embora

seja grande a dificuldade, esses testes devem gradualmente ser automatizados no sistema.

3.7 CÓDIGO COLETIVO

O código coletivo é extremamente ligado ao refactoring e ao desenvolvimento guiado

pelos testes. Para executá-lo é necessário que o desenvolvedor tenha coragem quando

programa pois seu código poderá ser alterado por outros programadores e ao alterar um

código já desenvolvido de forma que deverá garantir a continuidade do funcionamento do

código.

Essa fase também garante a agilidade no desenvolvimento. No XP, não existe divisão

de trabalho, todos trabalham no código e todos podem alterá-lo sem problema algum. O maior

benefício atingido nessa fase é a revisão de código, ou seja, mais uma aplicação de

refactoring.

3.8 CÓDIGO PRADRONIZADO

O código é uma das melhores formas de comunicação em uma equipe de

desenvolvimento. Isso é alcançado através do código padronizado.

41

Cada programador tem uma forma diferente de desenvolver o código, através dessas

diferenças torna-se um tanto complicada essa forma de comunicação, pois o código pode ficar

ilegível. Assim, é indicado que a equipe tenha um padrão de codificação, esse padrão permite

que a equipe tenha mais facilidade ao ler o código sem preocupação em ter de decifrar o

código alheio.

Dessa forma, o indicado é que a equipe adote um padrão ao iniciar o projeto, pode

haver diversas dificuldades quanto a conseguir chegar a um padrão, porém, a equipe deve

chegar a um consenso.

3.9 DESIGN SIMPLES

No XP, é determinado que a equipe assuma o design mais simples possível e que faça

uma funcionalidade passar nos testes criados para a mesma.

No desenvolvimento tradicional, ao surgir problemas em um software desenvolvido, o

custo para manutenção e alterações cresce exponencialmente com o tempo. Assim, a equipe

busca criar soluções genéricas para não levar o software a ter problemas maiores com as

mudanças. Existe uma certa incapacidade ao lidar com mudanças nesse modo de

desenvolvimento.

No XP, o princípio do custo com alterações é um tanto diferente do desenvolvimento

tradicional. O custo cresce em menor proporção e ao longo do tempo chega a ser praticamente

linear ao custo do desenvolvimento do software

Ao longo das iterações, o design evolui, sempre com simplicidade de forma que a

equipe possa fazer alterações no software a qualquer momento, com facilidade. Por esta

razão, o refactoring tem um papel fundamental no design do XP.

42

3.10 METÁFORA

O XP utiliza a metáfora para demonstrar o que se passa no projeto. É uma forma de

entender os problemas de forma mais consciente, até mesmo quanto a seus resultados. Dessa

forma equipe e cliente terão maior ciência dos objetivos do sistema e poderão melhorar sua

comunicação.

Teles (2006), aponta a metáfora, como um relacionamento entre as coisas mais

absurdas ao seu projeto. Para criar uma metáfora é preciso ter uma idéia, ela é o resultado de

um complexo processamento no subconsciente, de suma importância para o desenvolvimento

de software. Para isso a mente deve estar oxigenada e descansada.

A metáfora é relacionada ao ritmo sustentável descrito a posteriormente. Assim os

desenvolvedores devem estar descansados todos os dias e independente da motivação

humanista, existe uma motivação econômica muito forte que pode ser notada. Com as pessoas

descansadas a produção é maior e com mais qualidade, eficácia em suas idéias, maior atenção

e agilidade no desenvolvimento.

3.11 RITMO SUSTENTÁVEL

O ritmo sustentável no XP é importante porque viabiliza à equipe cumprir o tempo

planejado para finalizar o projeto. Nesse método de desenvolvimento não se usa a hora extra

para que o ritmo não seja alterado e o desenvolvedor tenha todas as motivações descritas

anteriormente em relação a estar descansado.

Como em outras práticas do XP, adotar o ritmo sustentável é um desafio a ser travado.

No mundo todo, várias equipes têm adotado esta prática e colhem seus frutos. Seus projetos

são mais ágeis, as pessoas convivem de forma mais harmoniosa e, sobretudo, não precisam ter

sacrifícios fora do trabalho.

43

3.12 INTEGRAÇÃO CONTÍNUA

Existem duas ferramentas de suma importância para realizar a integração contínua: A

ferramenta de build, compila o sistema e executa outras atividades que sejam necessárias para

que o sistema seja executado, levando o desenvolvimento a ter agilidade gerando um sistema

e o Sistema de controle de versão, conhecido como repositório, sua função é armazenar os

códigos fonte do sistema e mantém a sua versão.

Ao integrar uma funcionalidade ao sistema ela afeta outras já incorporadas a ele,

assim, ao desenvolver a funcionalidade o par deve integrá-la ao sistema diversas vezes

durante o dia, e também deve ser testada, dessa forma atingirá sucesso ao integrá-la.

Com o código coletivo, a equipe avança com maior velocidade, porque, assim não é

necessário esperar por outra pessoa para que o problema seja resolvido. O código permanece

mais claro, pois é revisado por diversos programadores e eles não precisam contornar áreas

problemáticas do sistema.

3.13 CICLO DE VIDA DO XP

No XP, a equipe implementa as funcionalidades mais importantes de acordo com as

prioridades do cliente, assim, poderá gerar valor, alto e ágil.

As quatro fases principais do XP, são demonstradas na figura 9:

Fonte: Engenharia de Software, PRESSMAN, 2006.

Figura 9: Ciclo de Vida do XP

PLANEJAMENTO PROJETO CODIFICAÇÃO TESTE

44

A equipe no XP é composta pelo Gerente de Projeto que é o responsável pelos

assuntos administrativos do projeto, o Coach que cuida da questão técnica do projeto, o

Analista de Teste, é o responsável por ajudar o cliente a escrever os testes de aceitação, o

Redator Técnico, contribui para que a equipe de desenvolvimento documente o sistema e o

Desenvolvedor, que analisa, projeta e codifica o sistema.

As atividades do XP trazem resultados rapidamente na forma de um software testado,

que cumpre todos os requisitos e expectativas do cliente em relação a custo e qualidade. Ao

combinar as técnicas do XP e eliminar as atividades que tornam o desenvolvimento

redundante leva a equipe a cumprir seus prazos e trabalhar sem ultrapassar seus limites

humanos. Enfim, diminui os riscos dos projetos, desenvolve software de forma iterativa e

reavalia as prioridades dos clientes.

45

4 SCRUM

Ratuchenei (2008) especifica que Scrum não é um processo, mas uma metodologia

que funciona como gestor e estrategista em desenvolvimento de softwares.

Para Kniberg (2007) Scrum não é um método, e sim um framework, ou seja, uma

ferramenta no auxílio de projetos de software.

No Scrum existem três tipos de papéis, o primeiro é o Scrum máster, o responsável por

todo o projeto e pela concretização dos outros papéis. O segundo é o Product Owner, ele

define as finalidades do produto a ser criado, cria prioridades de forma que as primeiras

funcionalidades a ser implantadas não sejam as mais fáceis, e sim aquelas que podem gerar

mais valor ao cliente. E o terceiro é a equipe, que trabalha nos moldes definidos pelo Scrum

Master e Product Owner.

4.1 PRODUCT BACKLOG, PRODUCT OWNER E PRIORIZAÇÃO DE ESTÓRIAS

No Scrum o Product Backlog é um conjunto de itens, estórias que definem o que o

cliente espera em um sistema, assim a equipe irá determinar o desenvolvimento. O

responsável pelo Product Backlog é o Product Owner, sua principal função é definir as

estórias, priorizá-las na Sprint Planning Meetings, no entanto não precisa saber como

implementá-las, apenas a função de cada uma.

Através de sua formação, o product owner tem a possibilidade de criar estórias que o

auxiliem no desenvolvimento, de forma que o seu foco seja gerar valor para o cliente criando

as funcionalidades prioritárias a ele. Outros integrantes da equipe também podem acrescentar

estórias, porém a função de priorizá-las é estritamente do product owner.

Um pouco diferente do que foi visto no XP, uma estória em Scrum tem as seguintes

características:

- ID: Apenas uma forma de identificar a estória caso o nome seja alterado. Pode ser

formado por auto-incrementos.

- Nome: a estória necessita de um pequeno nome com sua descrição

46

- Importância: No Scrum, é usual uma pontuação para destacar a importância da

estória, quanto mais pontos maior sua importância.

- Estimativa inicial: Como no XP, são usados pontos para estimar (tempo x

desenvolvedor) o desenvolvimento fazendo comparações entre estórias com funcionalidades

semelhantes.

- Como demonstrar: Ao apresentar o sprint é demonstrado como acontece a estória, de

forma linear é destacado o que é feito e os resultados.

- Notas: Espaço reservado a observações extras. (fontes, informações, entre outros).

Fonte: KNIBERG, 2007.

Quadro 1 - Modelo Product Backlog (exemplo).

As estórias podem ser alteradas por qualquer desenvolvedor, geralmente o product

owner é o responsável por ela, porém, através de esclarecimentos e alterações, o documento

pode, e deve ser sempre atualizado.

Além dos itens descritos anteriormente em uma estória ainda pode-se acrescentar

novas informações para apoiar as decisões do product owner ao priorizar as estórias.

- Track: uma forma de dividir as estórias por categoria.

- Componentes: Usada para definir os componentes técnicos usados no

desenvolvimento da estória

47

- Solicitante: Para gerar feedback esse campo registra o solicitante da estória, seja o

cliente ou algum stakeholder.

- Id do bug: Para rastrear a estória com seus defeitos.

O product backlog só pode ser fechado para a criação de sprints após ter a certeza de

que as estórias foram priorizadas corretamente e bem distribuídas.

4.2 PLANEJAMENTO DO SPRINT

Sprints são o mesmo que iterações, porém elas seguem o ciclo PDCA4, e como no XP

seu resultado é um sistema com menos funcionalidades, pronto para ser utilizado pelo cliente.

O ciclo PDCA, faz parte da gestão da qualidade em Administração, e segue os

seguintes passos:

- Plan (Plano): Identifica o problema, analisa e então, elabora planejamentos para

resolve-lo.

- Do (Execução): Segue o plano definido.

- Check (Verificação): Monitora e avalia os resultados de forma periódica

confrontando com o plano inicial.

- Act (Ação): Age de acordo com os resultados obtidos. Determina meios de melhorias

do processo como forma de obter melhor qualidade.

Dessa forma, o sprint segue as mesmas fases do ciclo PDCA, começa por uma reunião

que planeja o sprint, sendo que essa fase não tolera erros, pode levar o sprint a ser mal feito.

O product owner deve confiar em sua equipe e deixar que realizem seu trabalho,

portanto nessa reunião discute-se as melhores formas de deixar que a equipe trabalhar por

algumas semanas sem distrações que a levem a atrasos.

De forma mais clara, essa reunião discute o objetivo do sprint, a equipe, um sprint

backlog, a data de apresentação e por fim local e horário das reuniões diárias.

Assim, são apresentadas na figura 10, três variáveis destacadas em um planejamento

de sprint, por essa razão equipe de desenvolvimento e product owner devem trabalhar em

conjunto pelo sucesso do projeto.

4 PDCA: É um ciclo de desenvolvimento que tem como foco a melhoria contínua.

48

Fonte:KNIBERG, 2007.

Figura 10 – Variáveis do Sprint.

Como já foi visto no XP, a comunicação é um dos valores do desenvolvimento ágil,

com o Scrum não é diferente, equipe e product owner definem da melhor forma possível as

variáveis do sprint.

O Escopo e a Importância são definidos pelo product owner, ele destaca a prioridade e

o fim esperado para cada estória.

A Estimativa é definida pela equipe, o tempo é estimado, de forma que deve ser feito

em ordem decrescente de acordo com a prioridade de cada uma. O resultado dessa estimativa

pode fazer com que o product owner mude de idéia e altere a prioridade das estórias.

Kniberg (2007) ainda exclui da figura 10 um quarto elemento, qualidade, essa variável

é dividida em dois âmbitos, são eles:

- Qualidade interna: Tem mais relação à questão técnica, questões das quais o cliente

não tem idéia em como resolver, e que pode levar benefícios futuros quanto à manutebilidade

e alterações do sistema.

- Qualidade externa: Questões ligadas diretamente ao usuário, como por exemplo uma

boa interface que o leve a ter fácil aprendizado para usar o sistema.

O tamanho do sprint é definido para permitir a agilidade do projeto, assim, são

definidas as vantagens de um sprint curto e longo:

- Sprints curtos: O feedback é mais freqüente, de forma que passará a entregá-los mais

rápido

- Sprints longos: Suas vantagens são maior facilidade para correção de erros de

desenvolvimento e mais tempo para a equipe alcançar um bom ritmo.

49

4.3 SPRINT BACKLOGS

Após a reunião de planejamento e antes da reunião diária, é função do Scrum Master

criar um sprint backlog. Existem muitos formatos a ele, como: Jira, Excel e um quadro na

parede, do qual segundo Kniberg, é o mais indicado a ser usado.

Esse quadro deve ser montado em uma parede livre de pelo menos 2 m², como é

demonstrado na figura 11.

Fonte: KNIBERG, 2007.

Figura 11 – Modelo de Sprint Backlog.

Esse quadro é descrito a seguir de acordo com cada etapa:

- Não iniciado: são os itens do backlog dos quais ninguém está trabalhando ainda.

- Iniciado: itens do backlog que estão sendo desenvolvidos no dia corrente.

- Pronto: itens dos quais não serão mais necessários para o trabalho.

- Depois: quando os itens são concluídos antes do fim do prazo para o sprint são

incluídos novos itens para o desenvolvimento.

50

- Gráfico de Burndown: Demonstra se a equipe está estimando corretamente e o mais

importante, se está cumprindo todos os pontos estimados. Dessa forma, quanto mais próximo

da linha pontilhada melhor está o desenvolvimento, quanto mais longe, maior o tempo usado

acima do estimado e o custo também é maior.

Fonte: KNIBERG, 2007.

Figura 12 – Exemplo de Sprint Backlog.

Na figura 12, é apresentado um exemplo de sprint backlog, uma forma simples

para a organização do que ocorre no desenvolvimento de cada sprint. As vezes pode chegar a

parecer uma bagunça, mas na verdade é através dele que o desenvolvimento dos sprints são

guiados e organizados.

51

4.4 SALA DA EQUIPE

Chamado por Kniberg por “Canto de Design” é uma sala onde a quipe fará as suas

reuniões diárias visando o quadro de tarefas, um computador público, cadeiras extras, espaço

para as reuniões em pé e a parede de design que é um quadro branco, onde a equipe pode

escrever suas observações de design e esboços de documentações.

O ideal é que a equipe esteja sempre junta para o desenvolvimento, isto significa que

devem ficar a uma distância onde não sejam incomodados por outras equipes, possam ter

plena visão do quadro de tarefas e entre os desenvolvedores e possam conversar sem precisar

gritar.

A presença do product owner é essencial para a equipe, mas não é necessária a sua

presença na sala da equipe, para que não haja intromissão no desenvolvimento, pois a equipe

deve deixar que o seu trabalho flua naturalmente.

Fonte: KNIBERG, 2007.

Figura 13 – Modelo de Sala da Equipe.

Na figura 13, é apresentado um exemplo de sala da equipe, ainda falta a inclusão da

disposição das mesas de forma que seja feita de acordo com as possibilidades de cada equipe,

desde que siga o conjunto de regras já especificadas anteriormente.

52

4.5 REUNIÕES DIÁRIAS

As reuniões diárias, conhecidas em inglês como daily scrum, devem ser diárias, sem

atrasos e no mesmo lugar de preferência diante do quadro de tarefas. A equipe deve estar em

pé, para que a reunião não perdure por muito tempo, geralmente o máximo de tempo é quinze

minutos. A equipe apresenta o que foi feito no dia anterior e aproveita para atualizar o quadro

de tarefas.

4.6 APRESENTAÇÕES DE SPRINTS

Existem diversos pontos positivos em uma apresentação de sprint, como motivação à

equipe pela conclusão do trabalho e reconhecimento externo, feedback de stakeholders,

interação entre equipes e a finalização real do sprint, pois, sem a apresentação há o risco de

ser entregue “quase” pronto. A apresentação força a equipe em querer melhorar o

desenvolvimento para não correr o risco de se constranger em sua apresentação.

4.7 RETROSPECTIVAS DE SPRINTS

As retrospectivas são muito importantes, e para Kniberg (2007), o segundo evento

mais importante do Scrum, o primeiro é a reunião de planejamento. É uma forma de perceber

erros e buscar melhorias nos próximos sprints.

Uma reunião de retrospectiva deve contar com a presença de toda a equipe, o product

owner e o Scrum máster. Escolhe-se um secretário, é feito um resumo do sprint backlog,

todos expõem suas opiniões quanto ao desenvolvimento do sprint, é feita uma comparação do

53

tempo estimado com o tempo empregado, busca-se os motivos caso haja uma diferença muito

grande e enfim, o Scrum master resume as sugestões para atribuí-los ao próximo sprint.

4.8 COMBINAÇÃO ENTRE EXTREME PROGRAMMING E SCRUM

Existem idéias que se confrontam quanto a uma possível combinação entre XP e

Scrum, portanto esse capítulo foca as melhores utilidades nesse meio, de forma que essa

junção leve o desenvolvimento a ser ágil e agregue valor ao cliente.

O Scrum lida diretamente com as formas de gerenciar e organizar a equipe, um

framework de gerenciamento, enquanto o XP é ligado às melhores formas de desenvolver,

dessa forma eles podem se complementar com sucesso

Segundo Chapiewski (2008) a maior diferença entre os dois é que o Scrum pode ser

usado para outras coisas que não sejam desenvolvimento de software. No entanto, o XP

complementa o Scrum, pois, algumas práticas determinantes para o sucesso do

desenvolvimento de software não fazem parte do Scrum, mas são garantidos no XP.

Ele ainda questiona se o ideal seria então abandonar o Scrum e partir para o uso

apenas do XP. Porém, garante que algumas diferenças interessantes no Scrum, como:

retrospectiva no processo, ênfase na gerência do product backlog, a forma de planejar e o

acompanhamento dos Sprints.

A seguir são destacadas as melhores práticas para essa metodologia XP/Scrum, de

forma que a maioria delas são tratadas diretamente pelo Scrum, caso não haja sucesso no

desenvolvimento.

4.8.1 Programação Em Par

A programação em par oferece diversas melhorias ao desenvolvimento, de forma que

poderá levar também a equipe a ter o mesmo padrão de conhecimento, por todos trabalharem

54

no mesmo código, troca de experiências, conhecimentos técnicos e qualidade no

desenvolvimento. Além disso, deve ser uma experiência da qual o programador tenha o desejo

de realizar, não é correto que o faça por pressão de forma que não terá uma boa experiência

dessa ferramenta de desenvolvimento.

Existe a necessidade de um computador à disposição do navegador, este será apenas

um apoio para pequenas atividades simultâneas ao desenvolvimento. Deve haver

revezamento entre os pares e não há necessidade de acontecer todos os dias.

Entre as maiores vantagens desse meio para o desenvolvimento está a revisão de

código, esta se dá por que enquanto o condutor digita, seus erros são revisados pelo

navegador, dessa forma o código passa a ser simples e o desenvolvimento ganhar maior

qualidade no seu código.

4.8.2 Desenvolvimento Orientado a Testes (TDD)

O desenvolvimento orientado a testes é uma das ferramentas mais difíceis do

desenvolvimento ágil, pois é necessário um tempo até que os programadores se adaptem a ele,

Kniberg indica que apesar dessa dificuldade a melhor maneira para que a equipe aprenda é

desenvolver em par sempre com um programador que tenha experiência, assim, na prática seu

aprendizado será facilitado.

Desenvolvimento orientado a testes significa que você escreve um teste

automatizado, então escreve apenas código suficiente para fazê-lo passar, então

você refatora o código primeiramente para melhorar a legibilidade e remover

duplicação. Enxague e repita. (KNIBERG, 2007, p. 85).

O TDD pode ser aplicado tanto em novos códigos quanto nos já existentes, a principal

diferença é que nos novos códigos essa aplicação pode levar um tempo maior do que o

esperado por necessitar de mais ferramentas e testes que o normal, enquanto que no código já

existente a dificuldade de aplicação é grande, pois existe uma equipe dedicada a realizar testes

de regressão e performance.

55

Os testes de regressão são manuais, portanto leva-se um tempo maior para sua

realização, o ideal seria encontrar uma forma de automatizá-los, como isso não é possível, a

melhor forma encontrada por Kniberg foi realizá-lo de forma linear, porém, deve-se começar

pelos testes mais aplicáveis às ferramentas. Portanto, não existe a necessidade de automatizá-

los, mas desenvolver de forma que a aplicação dos testes de regressão se torne mais fácil.

Ferramentas usadas para o TDD:

- JUnit / httpUnit / jWebUnit.

- HSQLDB como BD.

- Jetty como container web.

- Spring framework para ligar diferentes tipos de fixtures de teste.

4.8.3 Design Incremental

Como valor imprescindível no desenvolvimento ágil, a simplicidade marca o design

incremental de forma que desde o início do projeto ele tenha essa característica e com o

desenrolar do trabalho sua melhoria contínua. Esse efeito é considerado uma conseqüência do

TDD, e evita grandes estragos gerados pela perda de tempo na sua criação no início do

projeto.

4.8.4 Integração Contínua

Essa ferramenta resolve diversos problemas ao demonstrar como o sprint desenvolvido

funciona ao ser integrado no sistema e questões sobre a qualidade do mesmo, assim, diversos

problemas podem ser detectados, documentações são criadas para expor os problemas de

código para que com a manutenção o sprint funcione.

56

4.8.5 Propriedade Coletiva do Código

É muito rentável ao desenvolvimento o uso do código coletivo, apesar da programação

em par contribuir para que boa parte da equipe trabalhe no mesmo código, a propriedade

coletiva eleva o nível do código e também o torna independente de um programador, caso ele

fique impossibilitado de trabalhar.

4.8.6 Ambiente de Trabalho Informativo

Como foi apresentado no item 3.4 do capítulo anterior, o ambiente de trabalho deve

contar com todas as informações possíveis em relação ao projeto nas paredes e tem-se a

necessidade de um quadro branco para uso da equipe, dessa forma a equipe terá maior

facilidade para incorporar o espírito do projeto a ser desenvolvido. Também há a necessidade

de um faxineiro na equipe, este será o responsável para limpar todo o lixo do projeto anterior.

4.8.7 Padrão de Codificação

Como em outros meios de fazer desenvolvimento ágil, o padrão de codificação deve

existir e acontecer de forma que seu início seja simples e evolua com o código. Existem

muitas diferenças entre programadores, isso pode levar a dois resultados distintos, o sucesso

de forma que a equipe realizará apenas o que realmente for necessário ao sprint, ou problemas

de inconsistência e má legibilidade no código.

57

4.8.8 Ritmo Sustentável e Trabalho Energizado

No desenvolvimento ágil, não se usa as horas extras, pois, não são aceitas como sinal

de maior produção. Pode levar o software à ruína, má qualidade, erros desastrosos, falta de

segurança e extrema dificuldade nos testes.

O Scrum, pode ser feito de forma mais eficaz com uma equipe motivada e descansada,

que chegue ao trabalho preparada para pensar e preparada para resolver suas tarefas do dia.

58

5 ESTUDO DE CASO

A partir de todos os estudos realizados nos capítulos anteriores foi realizada uma

pesquisa em uma empresa que utiliza os métodos ágeis, de maneira mais específica em Scrum

e XP. Foram levantadas diversas questões com o intuito de ter garantia quanto aos benefícios

gerados pelo desenvolvimento ágil de software e também, para saber quais são os maiores

problemas na sua aplicação e reação da equipe de desenvolvimento e do mercado.

A empresa estudada é a “Ancar”, a equipe recebeu treinamento em Java, orientação a

objetos e Extreme Programming. Ele foi realizado online, algumas vezes por semana, de

modo que a equipe pudesse continuar a executar suas atividades diárias e ainda assim dedicar

algumas horas ao treinamento. A Ancar mudou-se para um novo escritório, com espaço de

trabalho aberto e começou o desenvolvimento de um novo software utilizando as práticas do

Extreme Programming e Scrum.

5.1 O PROJETO ANCAR2GO

O SGSC atende bem às necessidades operacionais do negócio, mas não fornece

informações de maneira apropriada para os níveis estratégicos da organização. Por essa razão,

a Ancar decidiu investir no desenvolvimento do Ancar2Go, um sistema que pudesse agregar

informações estratégicas de modo que fossem fáceis de ser acessadas pelos diretores, de

qualquer lugar, estando eles conectados à rede ou não. O sistema está sendo implementado

pela equipe interna da Ancar, composta de seis pessoas, utilizando Java, com interface

desktop e acesso através do Java Web Start. O projeto utiliza todas as práticas originais do

Extreme Programming desde o início. As iterações são semanais e no jogo do planejamento

um representante dos usuários escreve as histórias utilizando cartões em papel. Os

desenvolvedores estimam o esforço em pontos, onde cada ponto representa quatro horas de

trabalho ideais. Diariamente a equipe faz um stand up meeting no início da manhã, no qual,

além de revisar o trabalho do dia anterior, prioriza as atividades do dia que está começando e

atualiza as informações do quadro de acompanhamento diário.

59

Como a mesma equipe é responsável pela implementação do Ancar2Go e pela

manutenção do SGSC, os desenvolvedores dedicam as manhãs ao Ancar2Go e as tardes ao

SGSC. Ao final de cada iteração, a equipe realiza uma retrospectiva, onde avalia o que

funcionou durante a semana, o que precisa melhorar e que ações devem ser tomadas para a

iteração seguinte. A retrospectiva utiliza ferramentas simples, tais como quadro branco,

canetas e post its.

Durante o desenvolvimento, os programadores trabalham em pares, revezando-se com

freqüência. As tarefas não são atribuídas aos desenvolvedores individualmente. Ou seja, a

responsabilidade de cada atividade é sempre da equipe como um todo. A equipe trabalha

junta, em um mesmo ambiente, que também possui um quadro branco à disposição. A IDE

utilizada é o IntellIJ, que provê excelente suporte para refatoração, integração com Ant, JUnit

e inúmeras facilidades que ajudam os desenvolvedores a avançarem rapidamente. As

integrações, que são síncronas, são automatizadas (utilizando-se Ant) e realizadas com

freqüência. O repositório usado é o CVS.

A equipe procura desenvolver os testes unitários antes das funcionalidades, com o

suporte do JUnit e do EasyMock. Para obter feedback sobre o nível de cobertura dos testes,

utiliza-se o Emma.

5.2 ASPECTOS POSITIVOS DO PROJETO

5.2.1 Integração Contínua

Dentre as práticas da equipe, o processo de integração contínua merece destaque. Os

desenvolvedores vêm dedicando esforços significativos para automatizá-lo e mantê-lo

divertido. Como a integração deve ser serializada, eles adotaram um sinalizador: um boneco

de borracha do Bob Espoja. Para que um par possa integrar seu trabalho, ele deve tomar posse

do Bob Esponja e apertá-lo duas vezes, o que produz um som pitoresco, avisando aos demais

que uma integração será iniciada. Durante a integração o Bob Esponja é mantido sobre o

60

monitor do par e, ao final, os desenvolvedores o apertam uma única vez, sinalizando o

término do procedimento.

Com a mudança para o novo escritório, a equipe de desenvolvimento passou a

trabalhar em um grande espaço aberto que é compartilhado com outros departamentos. O Bob

Esponja, naturalmente, não passa despercebido. Praticamente toda a empresa escuta os sons

produzidos por ele. No começo, isso despertou a curiosidade de todos que, pouco a pouco,

foram tomando conhecimento do XP e de suas práticas irreverentes. O uso do Bob Esponja,

além de ser divertido, vem gerando visibilidade sobre o trabalho de desenvolvimento e tem

conquistado a simpatia das demais áreas.

5.2.2 Deployment Automatizado

Além do processo de integração contínua, a equipe também investiu na automação do

deployment que hoje é feito apertando-se um único botão. Isso permite colocar novas versões

em produção rapidamente.

5.2.3 Testes

A automação dos testes representa o maior desafio técnico para os desenvolvedores.

Como é bem conhecido, dificuldades em testar o código normalmente refletem um design

inapropriado. Portanto, a automação de testes demanda maior conhecimento de orientação a

objetos, padrões, boas práticas para elevar a coesão e reduzir o acoplamento, bem como a

compreensão de técnicas de testes como o uso de mock objects. Alem do JUnit, os

desenvolvedores também adotaram o EasyMock, que facilita a criação de mock objects. Um

dos efeitos colaterais de seu uso é a ênfase na utilização de interfaces dentro do código, o que

tem representado um benefício para a evolução e flexibilidade do mesmo.

61

A cultura de escrever testes antes das funcionalidades se torna mais forte a cada dia e

os desenvolvedores se revelam cada vez mais habilidosos no uso das técnicas. Entretanto,

ainda há muito o que melhorar. A análise de cobertura do Emma revela que 91% das classes

estão cobertas, bem como 74% dos métodos e 70% das linhas de código.

5.2.4 Programação em Par

A programação em par, que foi muito bem aceita desde o início, vem sendo usada

permanentemente desde então e é uma das práticas que têm trazido resultados mais

marcantes. Trabalhando em par, os desenvolvedores têm se mostrado bastante produtivos e o

nível de concentração é elevado. Além disso, há grande satisfação e confiança no código

produzido.

A programação em par costuma ser uma técnica polêmica, visto que muita gente

acredita, erroneamente, que ela irá dobrar os custos ou o tempo do projeto. Na Ancar isso não

aconteceu. O gerente da equipe, bem como o diretor do departamento, apoiaram o uso de

pares desde o início. Eles próprios costumam participar ativamente do processo de

pareamento, o que os faz perceber diretamente seus benefícios.

Esse comportamento da gerência é importante, já que costuma ser difícil adotar a

programação em par na ausência de um apoio explícito da direção da empresa. No caso da

Ancar, em particular, a programação em par parece alinhar-se muito bem com os valores da

organização. Toda empresa possui um conjunto de valores, sejam eles expressos formalmente

ou conhecidos apenas de forma tácita por seus colaboradores. No caso da Ancar, há um valor

conhecido de forma explícita e, ao mesmo tempo, profundamente enraizado na cultura

corporativa.

Na cultura da Ancar, os relacionamentos humanos são muito valorizados e nutridos de

forma harmônica. Todos se conhecem, há um grau elevado de respeito entre as pessoas e uma

real preocupação de que o ambiente de trabalho seja agradável para todos. Os diretores,

gerentes e demais colaboradores trabalham juntos em um grande espaço aberto, onde há um

raro equilíbrio entre informalidade e alta produtividade.

62

A programação em par tem se revelado uma extensão natural dessa cultura. Os

desenvolvedores se divertem ao longo do dia, se relacionam de maneira informal e

descontraída e produzem muito em pouco tempo. Um aspecto interessante da programação

em par é a disseminação de conhecimento, tanto técnico, quanto de negócio. Por exemplo, no

começo de 2005, pouco depois do início do treinamento em XP.

A programação em par e o revezamento de pares representa hoje um motivo de

tranqüilidade para a direção da empresa, na medida em que o conhecimento sobre os sistemas

está espalhado entre diversas pessoas. Isso evita a possibilidade de que a saída de um

desenvolvedor impeça a evolução de um ou mais sistemas.

5.3 DESAFIOS TÉCNICOS

O Ancar2Go continua em desenvolvimento e ainda não contém um conjunto

significativo de funcionalidades ao ponto de se tornar parte do dia-a-dia da empresa.

Entretanto, vem avançando rapidamente nessa direção, já tendo realizado algumas conquistas

significativas. O objetivo do sistema é servir como uma espécie de painel de controle,

contendo informações criticas sobre o negócio, online e de fácil utilização, de modo que os

usuários possam fazer análises sobre o desempenho da empresa de forma rápida e intuitiva.

Para que isso se tornasse realidade, a equipe priorizou a interface com os usuário e

particularmente o uso das plantas dos shoppings.

No dia-a-dia dos diretores e gerentes, as plantas são usadas permanentemente para

apoiar decisões sobre que unidades comerciais serão alugadas, que áreas de um shopping

necessitam de reformas etc. Portanto, colocar as plantas no software, como ponto de acesso

para todas as funcionalidades, pareceu o melhor caminho para aproximá-lo da realidade de

seus usuários. Isso criou alguns desafios técnicos que foram gradualmente solucionados pela

forma de trabalho integrada da equipe de desenvolvimento. O primeiro problema era desenhar

as plantas. Para isso, a equipe estudou e desenvolveu habilidades em Java2D, de modo a

conseguir capturar os polígonos e colori-los de acordo com os usos do sistema.

O desafio posterior foi obter os polígonos que formavam as plantas. Alguns shoppings

tinham essas informações em banco de dados, enquanto outros não. A equipe começou

63

implementando formas de acesso ao banco de dados existente, utilizando Hibernate.

Resolvida essa questão, surgiu o problema de como obter os vértices das plantas dos demais

shoppings. Cada shopping possui uma área de arquitetura que utiliza AutoCAD para manter

as plantas atualizadas. A equipe de desenvolvimento estudou inúmeras formas de trazer as

informações das plantas para o banco de dados.

A primeira idéia foi desenvolver um editor de plantas que servisse como um

AutoCAD simplificado, de modo que a área de arquitetura dos shoppings pudesse abrir o

editor, colocar nele uma imagem da planta e clicar sobre os vértices para que o editor

registrasse esses pontos e os armazenasse no banco de dados.

Embora pareça trabalhoso, esse conceito era usado no sistema em Clipper e

funcionava. Entretanto, antes que os desenvolvedores avançassem muito nessa direção, surgiu

a idéia de criar um mecanismo automatizado para importar os vértices do AutoCAD. O

AutoCAD é capaz de exportar uma planta em um arquivo de texto no formato DXF. A equipe

implementou um pequeno aplicativo, chamado Mapper, que faz o parsing do arquivo DXF,

associa cada polígono a uma unidade comercial (com a ajuda de um operador) e grava as

informações no banco de dados. Essa solução simplificou significativamente a

implementação, bem como a forma de atualização das plantas pelos shoppings. Ela foi

possível devido à forma integrada de trabalho, com uso de pares, que leva os desenvolvedores

a discutirem inúmeras idéias.

Resolvido o problema técnico, chegou a hora de resolver o problema sistêmico. A

Ancar descobriu que o processo de manutenção das plantas nos shoppings não era

padronizado, nem funcionava de maneira harmônica. Assim, o desenvolvimento do Ancar2Go

levou à padronização do processo de atualização das plantas, que depois de algum tempo, foi

bem sucedido, permitindo que todas as plantas passassem a aparecer corretamente no sistema.

Para plotar uma planta, é necessário ler e processar uma grande quantidade de polígonos do

banco de dados. O uso do Hibernate não se mostrou eficiente para essa atividade, apesar dos

esforços de otimização por parte da equipe. Algumas soluções foram estudadas até que os

desenvolvedores decidiram experimentar o Prevayler.

64

5.4 PREVAYLER

Prevayler é um projeto open-source, que implementa uma camada de prevalência para

Java. Ele mantém todos os dados da aplicação em memória, porém sincronizados com o

disco, utilizando serialização. Dessa forma, é possível trabalhar apenas com objetos e evitar o

uso de banco de dados, desde que haja memória suficiente para os dados da aplicação. Por

trabalhar diretamente em memória, as consultas no Prevayler são extremamente rápidas. São

três ordens de grandeza mais rápidas que consultas a bancos de dados.

O Prevayler, que foi desenvolvido originalmente no Brasil e é mantido atualmente por

desenvolvedores no mundo inteiro, é bastante simples. Seu código é pequeno e o uso é fácil.

Spikes demonstraram que ele funcionaria e traria ganhos de desempenho significativos para o

Ancar2Go. Então a equipe fez um grande refactoring, criando um módulo extrator para ler

todas as informações do banco dedados, e transferi-las para o Prevayler, de modo que o

Ancar2Go não tivesse mais que acessar a base de dados para plotar os polígonos. É

importante notar que esse sistema não é usado para fazer atualizações. Os usuários apenas

consultam informações sobre o negócio, as quais são atualizadas apenas duas vezes ao mês,

quando então o extrator é executado e a base do Prevayler é reconstruída do zero.

O uso do Prevayler simplificou a aplicação, permitindo apagar muitas linhas de código

que antes eram usadas para lidar com acessos ao banco de dados. Inúmeras bibliotecas

deixaram de ser necessárias, tornado o sistema mais leve e fácil de ser compreendido.

O Prevayler também ajudou a viabilizar a portabilidade do sistema. O deployment do

Ancar2Go é feito em um servidor web, acessível por todos os funcionários da Ancar, em

todos os shoppings. A partir desse servidor, os usuários têm acesso ao Jar mais atualizado,

contendo a aplicação e todos os seus dados. Uma vez executada, a aplicação permanece na

máquina do usuário e não é necessário estar conectado à rede para utilizá-la. A conexão com a

rede só é necessária para atualizar a aplicação de tempos em tempos. Esses modelo permite

que os diretores possam levar a aplicação em seus notebooks, sem a necessidade de instalar e

operar um banco de dados nos mesmos.

65

5.5 RELACIONAMENTO DE TI COM A ORGANIZAÇÃO

O desenvolvimento do Ancar2Go, utilizando o Extreme Programming, vem gerando

maior visibilidade do trabalho de TI para o restante da organização. Parte disso se deve ao

empenho constantes dos desenvolvedores no sentido de envolver os usuários e as mais

diversas áreas da empresa no processo priorização e definição das funcionalidades.

No início do projeto, as funcionalidades foram especificadas e priorizadas apenas pelo

diretor de TI, Ricardo Carvalho. Como ele havia desenvolvido sozinho o sistema em Clipper,

utilizado por toda a empresa durante a década de 80 e 90, ele tinha profundo conhecimento

sobre as principais necessidades da organização e compreendia a importância de garantir que

a interface fosse baseada fortemente no uso de plantas.

Uma vez resolvidos os desafios relacionados às plantas e com algumas

funcionalidades prontas, a equipe decidiu apresentar o sistema para o restante da empresa e

começar a receber feedback de outras áreas. Era hora também de permitir que outros

departamentos participassem do processo de definição e priorização das funcionalidades.

Um dia, sem aviso prévio, os desenvolvedores foram para uma grande sala de reunião,

prepararam uma breve apresentação do sistema e saíram pela empresa, de mesa em mesa,

convidando todos para conhecer o Ancar2Go. Inúmeras pessoas deixaram de lado o que

estavam fazendo e foram participar. Todos ficaram bem impressionados ao ver as plantas no

computador e o que era possível fazer com elas. A equipe aproveitou a oportunidade para

distribuir post its e pedir que os participantes sugerissem as próximas funcionalidades. O

feedback foi enorme. Ainda nessa reunião, com os post its no quadro, os participantes fizeram

uma rápida priorização, na qual cada pessoa votou nas funcionalidades que considerava mais

importante. A partir daí o sistema realmente começou a ser conduzido pela comunidade de

usuários de toda a organização, ajudando a aprimorar os relacionamentos com TI e a

visibilidade do seu trabalho.

Nas semanas seguintes, as funcionalidades sugeridas começaram a ser desenvolvidas e

os usuários começaram a participar mais cedo do processo. Eles começaram a participar das

reuniões de planejamento, onde a equipe passou a produzir protótipos rapidamente, enquanto

o usuário descrevia novas histórias. O processo vem funcionando bem desde então.

66

5.6 PRECISA MELHORAR

O Extreme Programming vem gerando benefícios para a Ancar, mas é possível

melhorar em diversos aspectos. A cobertura de testes atual é boa, mas os desenvolvedores

desejam alcançar 100% nas medições do Emma. Com isso, eles esperam implantar o conceito

de “Broken Window”, sugerido por Thomas e Hunt. A idéia é que, uma vez alcançado 100%

de cobertura de testes, nenhum par irá desejar integrar um código que faça o grau de cobertura

baixar. Portanto, 100% de cobertura representa uma pressão positiva no sentido de manter o

sistema sempre em bom estado.

Para atingir esse objetivo, a equipe precisa se tornar cada vez mais disciplinada e

evitar os eventuais momentos nos quais é tomada pelo que ficou conhecido como IVSP: a

Incrível Vontade de Sair Programando. São as ocasiões em que um par deixa de fazer o teste,

pula diretamente para a implementação da funcionalidade e, às vezes, se esquece de voltar e

testar o que produziu.

5.7 RELACIONAMENTO COM OS SHOPPINGS

Além dos testes, é preciso haver maior integração com os usuários nos shoppings. Eles

têm uma responsabilidade importante: atualizar as plantas. Além disso, seus gestores também

precisam conhecer e se familiarizar com o sistema. A distância física de alguns shoppings têm

tornado as visitas pouco freqüentes, o que naturalmente não é bom para o avanço na utilização

do sistema.

67

5.8 EXTREME PROGRAMMING E SCRUM NO SGSC

Originalmente, o objetivo da Ancar era utilizar o Extreme Programming e Scrum no

desenvolvimento do Ancar2Go. Entretanto, esse modelo de trabalho vem influenciando a

manutenção do SGSC, o sistema legado de administração dos shoppings.

A equipe começou a utilizar o modelo de planejamento do XP no SGSC, trabalhando

com iterações semanais. Além disso, tem usado o quadro de acompanhamento diário para

monitorar as atividades de manutenção. A influência do XP também levou a criação de

inúmeros scripts para automatizar processos repetitivos no SGSC.

E o Scrum foi incluso em meio ao ambiente de trabalho de forma a melhorar a

comunicação e o gerenciamento da equipe. A viabilizar que os desenvolvedores pudessem

trabalhar sem interrupções com todas as ferramentas necessárias à conclusão do trabalho.

O próximo passo é criar mecanismos de testes automatizados no SGSC, de modo que

a equipe possa colher os mesmos benefícios de segurança e qualidade observados até o

momento no Ancar2Go. Nessa área ainda há muito o que fazer e a aprender, visto que os

desafios são diferentes e o sistema não foi estruturado originalmente da forma mais adequada

possível para ser testado de forma unitária, por exemplo.

68

6 CONSIDERAÇÕES FINAIS

O desenvolvimento ágil de software necessita da colaboração das pessoas que devem

ter total comprometimento seguindo à risca os quatro princípios explícitos no início do

trabalho: comunicação, feedback, coragem e simplicidade. É necessário que todos deixem de

lado os vícios do desenvolvimento tradicional e se adaptem aos métodos ágeis, dessa forma, a

equipe deve ser composta por uma seleção de integrantes que estejam dispostos a se adaptar.

As técnicas ágeis são usadas para ter maior controle do projeto, diminuir os riscos, aumentar o

retorno de investimento e ter sucesso no desenvolvimento de forma que cliente e equipe saiam

satisfeitos com o sistema produzido.

Muitas empresas não conseguem implantar o desenvolvimento ágil, porque nele os

gerentes, ou aqueles que estão acima em uma hierarquia do projeto, podem se sentir pouco a

vontade em dar total liberdade à equipe. Os líderes da equipe devem dominar totalmente os

princípios ágeis, suas regras e aplicação, para que saibam argumentar em todas as

necessidades da equipe e não deturpar o desenvolvimento ágil.

Após expor os processos de software e dois dos principais métodos ágeis, este trabalho

estuda uma combinação entre Extreme Programming e Scrum, de forma que foi obtido um

terceiro método (XP/Scrum). Esse método pode obter maior sucesso que os dois separados,

pois, enquanto o Scrum é mais focado no gerenciamento das equipes, o XP define as melhores

maneiras de desenvolver o software. Assim, pode-se suprir as falhas de ambos e como um

complemento atingir melhores resultados como: agilidade no processo, menores custos,

qualidade no código e fácil adaptabilidade a mudanças.

O desenvolvimento ágil é proposto ao desenvolvimento em equipes que tenham

dificuldades em exercer os compromissos criados com o cliente excedendo tempo, custo e

desenvolvem softwares com dificuldades a alterações. Seu papel é melhorar seu

relacionamento com os clientes aumentando sua credibilidade, demonstrar o valor de cada

funcionalidade de forma que o cliente entenda o investimento, o código do projeto terá maior

legibilidade aumentando sua qualidade e possibilitando alterações, entre outros. Nessa forma

de desenvolvimento a formação humana é privilegiada, pois, as idéias dos integrantes da

equipe são inseridas no desenvolvimento e ele deixa de ser apenas uma peça de uma máquina

e torna-se um produtor de idéias. O ensino do desenvolvimento ágil deve ser incluído no

69

sistema de ensino dos cursos de informática no Brasil de forma que ele coexista com o

desenvolvimento tradicional, pois cada um tem o seu papel no desenvolvimento de softwares.

70

REFERÊNCIAS BIBLIOGRÁFICAS

BECK, Kent. Manifesto Ágil disponível em http://www.manifestoagil.com.br/ acessado em

15/10/2009.

BUENO, Francisco da Silveira. Minidicionário da Lingua Portuguesa. São Paulo: FTD,

2008.

CHAPIEWSKI, Guilherme. XP complementa o Scrum. Disponível em

http://gc.blog.br/2008/03/31/xp-complementa-o-scrum/ acesso em 15/11/2009.

KNIBERG, Henrik. Scrum e XP direto das trincheiras: como nós fazemos Scrum. EUA:

InfoQ.com, 2007.

KOSCIANSKI, André. Qualidade de Software: aprenda as metodologias e técnicas mais

modernas para o desenvolvimento de software. São Paulo: Novatec Editora, 2007.

LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto

orientados a objetos e ao Processo Unificado. Porto Alegre: Bookman, 2004.

NETO, Plácido Antônio de Souza. Processo Unificado – Visão Geral. Disponívem em

http://www.cefetrn.br/~placido/ensino/mossoro/aoo/material/UP.pdf acesso em 15/10/2009.

PFLEEGER, S. L. Engenharia de Software: Teoria e Prática. São Paulo: Prentice Hall,

2004.

PRESSMAN, Roger S. Engenharia de Software. São Paulo: McGraw-Hill, 2006.

RATUCHENEI, Victor Ávila. Uma abordagem baseada nos princípios ágeis para o

desenvolvimento de sistemas Web. Disponível em

http://www.ufpel.edu.br/cic/2008/cd/pages/pdf/CE/CE_01960.pdf acesso em 15/11/2009.

71

REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informação. Rio de

Janeiro: Brasport, 2005.

SABINO, Fernanda Oliveira. Extreme Programming. Monografia, Mococa-SP: Fatec, 2009.

SCOTT, Kendall. Processo Unificado Explicado. Bookman, 1999.

TELES, Vinícius Manhães. Extreme Programming: aprenda como encantar seus usuários

desenvolvendo software com agilidade e alta qualidade. São Paulo: Novatec Editora, 2006.

TELES, Vinícius Manhães. Improve IT. Disponível em

http://improveit.com.br/xp/case_ancar acesso em 10/11/2009.

TONSIG, Sérgio Luiz. Engenharia de Software. São Paulo: Futura, 2003.