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

CENTRO PAULA SOUZA
FACULDADE DE TECNOLOGIA DE MOCOCA
CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA – ÊNFASE
EM GESTÃO DE NEGÓCIOS

Tiago Lucas Lopes de Oliveira

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

Mococa, SP
2º Semestre/2009

TIAGO LUCAS LOPES DE OLIVEIRA

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

Monografia apresentada à Faculdade de Tecnologia de Mococa,
como parte dos requisitos para a obtenção do título de Tecnólogo em
Informática – Ênfase em Gestão de Negócios.

Orientadora: Sandra Cristina Costa
Co-orientador: Orlando Clínio Patriarcha

Mococa, SP
2º Semestre/2009

TIAGO LUCAS LOPES DE OLIVEIRA

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

Monografia apresentada à Faculdade de Tecnologia de Mococa, como
parte dos requisitos para a obtenção do título de Tecnólogo em
Informática – Ênfase em Gestão de Negócios.

Orientadora: Profª Drª Sandra Cristina Costa
Co-orientador: Orlando Clínio Patriarcha

ASS.
______________________________________________________
1º Examinador: Sandra Cristina Costa
Instituição: Faculdade de Tecnologia de Mococa

ASS.
______________________________________________________
2º Examinador: Orlando Clínio Patriarcha
Instituição:

ASS.
______________________________________________________
3º Examinador: Geraldo
Instituição: Faculdade de Tecnologia de Mococa

Nota:

Mococa, dia 18 de Dezembro de 2009

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

AGRADECIMENTOS

Após finalizar este trabalho, não pude deixar de aproveitar este espaço e agradecer
aqueles que tornam minha vida uma batalha agradável a travar.
Agradeço primeiramente a Deus, que por intercessão de sua mãe sempre me atendeu
mesmo que não soubesse. Tenho tudo, todo o necessário e a certeza de que essa é a
graça.
A professora Sandra, que teve paciência e tranqüilidade em acreditar nesse trabalho.
Agradeço pela boa vontade e tempo dedicado.
Ao meu amigo e co-orientador Orlando, seu apoio foi determinante para a realização
deste trabalho, agradeço também pela inspiração e indicações durante todo o
desenvolvimento nessa etapa.
A meus pais, Silvio e Elenita. Aprecio o quanto são determinados para criar e viver
uma família. Sem eles nada seria possível. Esse amor é essencial em toda a minha
formação.
A minhas irmãs, Daniele, Caroline e Gabriela, acredito que elas merecem ser
lembradas nesse momento, que possam ser inspiradas e assim lutar por todos os seus
objetivos.
A meus avós, Zezinho e Genésia, me orgulho muito em ser neto deles, todos os dias
agradeço a Deus pela família que tenho, sinto falta, amo e torço por todos.
A minha namorada, Ana Flávia, são mais de dois anos juntos, assim lutamos por
nossos ideais e estamos conquistando mais um objetivo, obrigado por tudo. Todas as
horas de trabalhos e estudos valem a pena quando se tem ao lado pessoas tão
preciosas.
A meus amigos, padre Ilsinho, padre Elviro, Luciana, João Paulo, Bruno e Graziela só
tenho a agradecer por todo apoio e parceria durante muitos dos bons e maus momentos
de minha vida.

Não são as espécies mais fortes que
sobrevivem, nem as mais inteligentes, mas
aquelas mais sensíveis à mudanças.
(DARWIN, apud KOSCIANSKI, 2007)

RESUMO

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

Palavras-chave: Software; Ágil; Metodologias; Desenvolvimento; Iteração.

ABSTRACT

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

Keywords: Methodologies. Development. Iterations. Process. Agile.

LISTA DE FIGURAS

Figura 1 – Modelo em Cascata – Ciclo de Vida ............................................................... 17
Figura 2 – Sistema de Incremento ..................................................................................... 19
Figura 3 - Prototipação ...................................................................................................... 20
Figura 4 – Modelo em Espiral .......................................................................................... 21
Figura 5 – A realimentação e a adaptação iterativa levam ao sistema desejado.
A instabilidade dos requisitos diminuem com o tempo ...................................................... 23
Figura 6 – Termos relativos ao cronograma em PU .......................................................... 24
Figura 7 – Disciplinas em PU ............................................................................................ 25
Figura 8 – Tipos de conclusão de projetos ........................................................................ 27
Figura 9 – Ciclo de vida do XP ......................................................................................... 44
Figura 10 – Variáveis do Sprint ......................................................................................... 49
Figura 11 – Modelo Sprint Backlog .................................................................................. 50
Figura 12 – Exemplo Sprint Backlog ................................................................................ 51
Figura 13 – Modelo de Sala de Equipe .............................................................................. 52

LISTA DE SIGLAS

AOO – Análise Orientada a Objetos
POO – Programação Orientada a Objetos
PU – Processo Unificado (Unified Process)
RUP – Rational Unified Process
UML – Unified Modeling Language
XP – Extreme Programming
PDCA – Plan, Do, Check and Act.

SUMÁRIO

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

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

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

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

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

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

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

4.7 RETROSPECTIVA DE SPRINTS ............................................................................... 52
4.8 COMBINAÇÃO ENTRE EXTREME PROGRAMMING E SCRUM ....................... 53
4.8.1 Programação em Par ............................................................................................... 53
4.8.2 Desenvolvimento Orientado a Testes (TDD) ......................................................... 54
4.8.3 Design Incremental .................................................................................................. 55
4.8.4 Integração Contínua ................................................................................................ 55
4.8.5 Propriedade Coletiva do Código ............................................................................ 56
4.8.6 Ambiente de Trabalho Informativo ....................................................................... 56
4.8.7 Padrão de Codificação ............................................................................................. 56
4.8.8 Ritmo Sustentável e Trabalho Energizado ............................................................ 57

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

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

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

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

12

1 INTRODUÇÃO

A Engenharia de Software traz consigo diversos modelos para o processo de
desenvolvimento de software, muitos deles foram criados com um pensamento que não cabe a
essa forma de trabalho. Alguns modelos como, por exemplo, o modelo em cascata, são
baseados em modelos da fabricação industrial, os quais não parecem adequados ao
desenvolvimento de software que, sendo um trabalho do conhecimento, não poderia seguir
esse esquema. Por esse e outros motivos, a maioria dos softwares desenvolvidos não chegam
nem a ser entregues, e quando atingem a conclusão tem grande probabilidade de falhar.
Uma alternativa para o modelo em cascata é o desenvolvimento ágil de software, o
qual trabalha baseado em equipes e iterações curtas. Ao fim de cada iteração é entregue ao
cliente um software pronto, funcionando, porém, apenas com uma parte de suas
funcionalidades implementadas. A equipe busca desenvolver segundo as prioridades do
cliente, agregando valor ao produto entregue. Uma das vantagens desse método é sua
facilidade em se adaptar a mudanças e a facilidade quanto a manutenção. Os métodos de
desenvolvimento ágil têm características próprias que contribuem de forma eficaz para que o
desenvolvimento seja ágil, com qualidade.
Um dos métodos ágeis, o Extreme Programming, acontece com equipes pequenas e
médias, trabalha com poucos requisitos e torna imprescindível a presença do cliente durante
todo o desenvolvimento. A programação é feita em pares e seu maior foco é a qualidade do
produto e do seu código de forma que ao final sua facilidade de ser adaptado a mudanças será
satisfatória.
O Scrum, não está direcionado à criação o software propriamente, mas a gerenciar o
projeto e a equipe de forma que sejam rápidos e atinjam os seus objetivos.
Essas metodologias de desenvolvimento podem dar crédito às equipes que trabalham
na criação de softwares, e apoiá-las para que atinjam as expectativas do cliente, possibilitando
que ele saiba o valor do desenvolvimento e tenha consciência de todas as funcionalidades
desenvolvidas.

O objetivo dessa monografia é apresentar uma combinação entre as principais práticas
desses dois modelos. Para isto, está organizada da seguinte maneira:
Capítulo 2: Consiste em apresentar os principais modelos de processos de software da
Engenharia de Software. Depois dessa apresentação, introduz o conceito de desenvolvimento

13

ágil, tal como descreve suas diferenças em relação às formas tradicionais de desenvolvimento,
seus valores e importância para os negócios atualmente.
• Capítulo 3: Apresenta o Extremming Programming, descrevendo todas as suas etapas,
especificando suas funções de forma detalhada e como são desenvolvidas.
• Capítulo 4: Como no capítulo anterior, porém, com o Scrum é apresentado todas as
fases em como esse método funciona e detalhes que o compõe e o torna uma das
metodologias mais usadas no mundo atual. Estuda uma seleção das fases mais
importantes para unir o XP e o Scrum, tornando-se assim, uma maneira ainda melhor
para o desenvolvimento de softwares.
• Capítulo 5: Faz análise de um estudo de caso que demonstra as vantagens,
desvantagens do uso de Scrum e XP na prática do dia-a-dia de uma empresa.
Dessa forma, essas metodologias de desenvolvimento poderão dar crédito às equipes
que trabalham na criação de softwares, atingindo todas as expectativas esperadas pelo cliente,
possibilitando que ele saiba o valor do desenvolvimento, tenha consciência de todas as
funcionalidades desenvolvidas, com qualidade e de forma ágil.

14

2 PROCESSOS DE SOFTWARE E DESENVOLVIMENTO ÁGIL

Este capítulo apresenta o software, tal como seus processos e métodos de
desenvolvimento, a fim de apresentar o desenvolvimento ágil e seus métodos como
contribuintes de melhorias no desenvolvimento com o objetivo de alcançar um
aprimoramento contínuo na criação de softwares.

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

A principal preocupação nessa atividade é desenvolver atingindo todos os objetivos
citados por Rezende, a realizar a produção de um software que cumpra todo o esperado pelo
cliente com qualidade de forma que seja adaptável a mudanças.

2.1 PROCESSOS DE SOFTWARE

Tonsig declara que a Engenharia de Software utiliza a Ciência da Computação e
Matemática para atingir seus objetivos quanto às práticas de desenvolver software. É preciso
saber sobre a necessidade do software para os negócios e a necessidade de sua flexibilidade a
mudanças contando com todas as mutações do mundo dos negócios.

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

Dessa forma, o software, resultado da engenharia, é o grande objetivo, com qualidade,
eficiência e viabilidade. Segundo Tonsig (2003), “o software como um conjunto de
componentes abstratos encapsulados na forma de procedimentos, funções, módulos, objetos

15

ou agentes.” A partir disso, a principal função da engenharia é propor modelos e processos
quais apresentem os melhores métodos e ferramentas para o planejamento e gerenciamento
dos projetos de desenvolvimento de software.
Segundo Pressman o processo é uma das camadas que formam a engenharia de
software e é tido como apoio, alicerce. É o responsável pela união de todas as camadas da
tecnologia e favorece a criação eficiente e oportuna de softwares.

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

Assim, a Engenharia de software fornece métodos e ferramentas que auxiliam na
produção de softwares. Os métodos são definidos como técnicas para o desenvolvimento e as
ferramentas que definem a base de qualquer projeto de software. Um framework1 de processo
é o esqueleto, o alicerce do projeto, onde é aplicada uma série de trabalhos co-relacionados
que tem como resultado um produto da engenharia de software. Nele existem algumas
atividades que podem ser usadas na maioria dos projetos de softwares, são elas:
- Comunicação: levantamento dos requisitos através de boa comunicação e cooperação
com os clientes.
- Planejamento: Descrição das tarefas técnicas, cronograma de trabalho, riscos,
recursos, e produtos finais.
- Modelagem: Modelos que permitem ao cliente ter uma noção de como será o
software, através disso os requisitos são reavaliados e são feitas as últimas alterações antes de
implementação (construção).
- Construção: Manipulação dos códigos e revisão de erros.
- Implantação: Entrega do produto, seja inteiro ou em partes (incremento), onde o
cliente avalia e faz o feedback2 para que possa ser alterado e melhorado.

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

16

Esses cinco tópicos são usados como base em qualquer projeto de software, visto de
forma global têm-se a impressão de que a receita será a mesma, porém isso não acontece pois
cada projeto tem características e detalhes próprios.
A aplicação de modelos de processo tem como objetivo melhorar o gerenciamento e a
qualidade dos projetos, isso é, estabelecer medidas como datas de entregas e previsão de
custos de forma que não corra riscos e os custos da produção não sejam afetados.
Segundo Pressman os modelos ágeis priorizam a gestão do desenvolvimento, se
adéquam facilmente a vários tipos de projeto e são extremamente úteis à aplicações Web.
Assim, esses projetos, seguindo seus princípios acontecem com uma abordagem mais
informal, porém, efetiva e busca obter maior agilidade em seus processos de forma a levar
qualidade e satisfação ao cliente.

2.1.1 Modelo Cascata

Nesse modelo de desenvolvimento, a partir da análise de viabilidade do projeto a
evolução se dá de forma seqüencial, ou seja, uma etapa por vez, em cascata. Esse modelo é
inspirado nos modelos de produção industrial que é marcado por três princípios:
determinismo, especialização e foco na execução.
A Figura 1 mostra as sete etapas que formam o modelo em cascata: análise de
viabilidade, análise de requisitos, projeto, implementação, testes, implantação e manutenção.

Engenharia
de Sistemas
Análise

Projeto
Codificação

Teste

Manutenção

Fonte: Livro Engenharia de Software. PRESSMAN, 1995.
Figura 1 - Modelo Cascata - Ciclo de vida Clássico.

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

Definir Atribuir Projetar
esboço requisitos arquitetura
dos aos do sistema
requisitos incremento
s

Desenvolver Validar Integrar Validar
incrementos incremento incremento Sistema
do sistema Sistema
Final

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

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.

Requisitos
Projeto PROJETO CODIFICAÇÃO TESTE MANUTENÇÃO
Codificação
Teste

Protótipo Produto
(manutenibilidade,
qualidade)
Análise de
requisitos.

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.

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 1
Tipo 3 16%
31%
Tipo 1
Tipo 2
Tipo 3

Tipo 2
53%

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:

PLANEJAMENTO PROJETO CODIFICAÇÃO TESTE

Fonte: Engenharia de Software, PRESSMAN, 2006.
Figura 9: Ciclo de Vida do XP

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.


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.


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.


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

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (10)

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

Ähnlich wie Desenvolvimento Ágil de Software: uma abordagem com SCRUM e XP (20)

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