Upload
tiago-oliveira
View
9.032
Download
2
Embed Size (px)
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.
Citation preview
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.