Você está na página 1de 7

4

1 INTRODUÇÃO

Diante da constante evolução dos softwares tornou-se indispensável inovar


também no desenvolvimento dos mesmos, a globalização aumentou a
competitividade e cada empresa tem obrigação de buscar, apresentar e aprimorar o
seu diferencial competitivo.
Segundo o relatório “CHAOS” (Standish Group, 2009), 32% dos projetos
obtiveram sucesso (foram entregues no prazo, dentro do orçamento e com escopo
completo), 44% mudaram (atrasaram, estourou o orçamento, e/ou reduziram
escopo) e 24% falharam (cancelados ou nunca usados), isto prova a dificuldade que
existe em compreender os fatores relevantes para as mudanças no curso do
processo.
As metodologias tradicionais têm como principal característica serem
divididas por etapas bem definidas Análise, Modelagem, Desenvolvimento e Testes,
cada etapa seguinte só é inicializada após o termino da anterior, sendo uma
dependente da outra e ainda, gerando documentos, diagramas UML 1 ou protótipo de
software.
Muitas dessas metodologias utilizam o modelo em cascata, que prevê uma
abordagem seqüencial, começando pela coleta de requisitos, passando pelo
planejamento, modelagem, construção e implantação. O foco destas é a
previsibilidade dos requisitos do sistema, dificultam o controle do projeto, pois
quando existem incertezas e há, por exemplo, uma alteração de requisitos, será
necessário voltar ao inicio para alterar a documentação gerada após a coleta dos
mesmos.
De acordo com Pressman (2006), projetos reais raramente seguem o fluxo
seqüencial que esse modelo propõe. Por se tratar de um modelo linear, uma
modificação no decorrer do processo pode causar confusão e ressaltando ainda,
que para o cliente é difícil estabelecer todos os requisitos explicitamente no início do
projeto, o que praticamente impossibilita a acomodação natural das incertezas que
existem no inicio de muitos.

_______________________________
1
Representação gráfica do produto em desenvolvimento, gerada em UML (Unified
Modeling Language), linguagem de modelagem que usa o conceito de orientação a objetos.
5

Foi visando superar esses e outros obstáculos que em 2001 foi assinado o
“Manifesto para o Desenvolvimento Ágil de Software”, nele notáveis
desenvolvedores declararam estar descobrindo melhores modos de
desenvolvimento de software, por meio deste passaram a valorizar os indivíduos e a
iteração entre eles, a colaboração do cliente e a resposta às modificações
existentes, além de não se prenderem a uma documentação abrangente.
Surgem então as metodologias ágeis, com desenvolvimento interativo,
colaborativo, é uma resposta às limitações das metodologias focadas na
documentação. Neste processo ágil a equipe deve estudar antecipadamente os
requisitos de software e prever quais poderão sofrer modificações e quais serão
mantidos no escopo inicial, é uma tarefa difícil, visto que é complicado definir quais
prioridades do cliente poderão sofrer alterações no decorrer do projeto.
O foco de tais metodologias é centrado nas relações humanas inerentes ao
desenvolvimento de sistemas e não somente na documentação e burocratização de
processos promovida pelos modelos tradicionais. Pregar o trabalho em equipe é
prioridade, pois um grande projeto de software com milhares de linhas de código não
pode ser escrito por uma única pessoa.
Trabalhar em equipe significa envolver diferentes emoções e opiniões, dividir
tarefas e compartilhar conhecimento, e neste processo as pessoas darão o melhor
de si se tiverem motivação e expectativas adequadas. Essa forma de trabalho que
exige ferramentas específicas, dentre essas o SCRUM foi o escolhido para esta
pesquisa por ser um ótimo exemplo de modelo de integração de indivíduos, que
contém fases bem definidas e reuniões para discussão que podem prevêem o
surgimento de fracassos para poder contorná-los sem grandes prejuízos para o
cronograma realizado.
Contendo princípios consistentes com o Manifesto Ágil, o SCRUM foi
desenvolvido por Jeff Sutherland e sua equipe no início da década de 90, recebendo
métodos adicionais de Scwaber e Beedle. É um modelo incremental e ideal para ser
utilizado em ambientes onde os requisitos não são muito claros ou mudam com
freqüência.
É indicado para gerenciar qualquer atividade complexa, aperfeiçoa o
entrosamento entre as equipes de desenvolvimento, com isso o rendimento
aumenta, os requisitos e as solicitações de alteração passam a ser entendidos com
maior facilidade.
6

2 DESENVOLVIMENTO ÁGIL

2.1 Características do Desenvolvimento Ágil

Segundo Pressman (2006, p.58), “a engenharia de software ágil


combina uma filosofia e um conjunto de diretrizes de desenvolvimento.
A filosofia encoraja a satisfação do cliente e a entrega incremental do
software logo de início; equipes de projeto pequenas, altamente
motivadas, métodos informais, produtos de trabalho de engenharia de
software mínimos e simplicidade global de desenvolvimento. As
diretrizes de desenvolvimento enfatizam a entrega em contraposição à
análise e ao projeto (apesar dessas atividades não serem
desencorajadas) e a comunicação ativa entre desenvolvedores e
clientes”.
Os princípios do desenvolvimento ágil visam minimizar as falhas
desenvolvendo o projeto de forma incremental, em curtos períodos, chamados de
iteração, sendo esses “mini-projetos” de software que incluirão as tarefas
necessárias para alcançar a funcionalidade do produto: planejamento, análise de
requisitos, projeto, codificação, teste e documentação.
Esse processo prioriza pessoas e iterações à processos e ferramentas,
software executável, ao contrário de documentação extensa e confusa,e
principalmente a colaboração do cliente e resposta rápidas às mudanças no escopo
durante o andamento do projeto.
A motivação é um dos focos de tais modelos, as equipes de negócio e
desenvolvimento trabalham juntas diariamente, deve ser dado o ambiente e o apoio
necessário aos indivíduos para que eles confiem na realização do trabalho.
Ter o software funcionando é a principal medida de progresso, para isso
maximizar a quantidade de trabalho não-realizado é essencial. A equipe deve
receber bem as mudanças de requisitos, mesmo estando em fase avançada de
desenvolvimento, pois o direcionamento dessas mudanças constitui em um
diferencial competitivo para o cliente.
7

2.2 Objetivos do Desenvolvimento Ágil

De acordo com Martins (2007), são cinco os principais objetivos do Agile


Project Management (APM), sendo eles: Inovação contínua, adaptabilidade do
produto, entregas com cronograma reduzido, adaptabilidade do processo e das
pessoas, resultados confiáveis.
A inovação contínua busca suprir às necessidades atuais do cliente, mesmo
que estas sofram mudanças no decorrer do projeto.
O desenvolvimento deve ter foco na redução do custo de adaptação, visto
que o produto deve ser adaptado a possíveis alterações de escopo.
Há duas razões pelas quais o retorno rápido é importante: cometemos a
maior parte dos nossos erros nos primeiros aspectos do desenvolvimento e o custo
de consertar esses defeitos aumenta exponencialmente conforma a demora de
serem descobertos (AMBLER, 2002).
Para isso, as metodologias ágeis programam entregas com cronograma
reduzido, assim podem identificar mais cedo requisitos mal-compreendidos, falhas
na modelagem, na codificação, entre outros.
Logo abaixo, os gráficos demonstrando a curva de probabilidade de
surgimento de defeitos, e, em seguida, a curva representando o custo do conserto
dos mesmos.

Figura 1: Probabilidade decrescente do surgimento de defeitos em cada fase


de desenvolvimento.
8

Figura 2: Custos crescentes para identificar e consertar os defeitos em cada


fase de desenvolvimento.

Em uma indústria onde a mudança é regra, cada oportunidade de aprender


novos métodos deve ser explorada, para isso, a formação de uma equipe integrada
e multidisciplinar é importante. Segundo AMBLER (2002), os modeladores ágeis
reconhecem que nunca sabem tudo sobre algo; há sempre a oportunidade de
aprender mais e estender seus conhecimentos.
Aliando esses objetivos a uma boa gerência, pode-se entregar um resultado
confiável ao cliente, que possa superar as incertezas dos requisitos e o surgimento
de novas tecnologias, que seriam fatores complicadores em um processo tradicional.

2.3 Quando deve ser utilizado o desenvolvimento ágil?

É indicado o uso de métodos ágeis principalmente em situações onde os


requisitos são imprevisíveis ou mudam rapidamente, quando há colaboração do
cliente no sentido de avaliar as versões lançadas e traçar seus objetivos e
prioridades, dessa forma o projeto pode evoluir de acordo com a elevação das
necessidades do mesmo.
Vale salientar que os processos de softwares básicos não devem ser
deixados de lado, o foco do Ágile está na modelagem e documentação eficazes,
para outras necessidades como as rotinas de teste, gerenciamento de projeto e
suporte ao sistema deve-se aliar a outros modelos para obter o resultado ideal.
9

3 SCRUM

3.1 Definição

O nome “Scrum” é derivado de uma jogada do rugby, em uma alusão à


formação de equipe, com divisão de papéis em busca de um objetivo comum.
É um modelo iterativo e incremental que pode ser utilizado para o
gerenciamento de qualquer atividade complexa, proporcionando bom entrosamento
entre os membros do time de desenvolvedores, participação ativa do cliente e
aumento no rendimento das atividades.
Scrum não é um processo ou uma técnica para o desenvolvimento de
produtos. Ao invés disso, é um framework dentro do qual você pode empregar
diversos processos e técnicas. O papel do Scrum é fazer transparecer a eficácia
relativa das suas práticas de desenvolvimento para que você possa melhorá-las,
enquanto provê um framework dentro do qual, produtos complexos podem ser
desenvolvidos (SCHWABER. SUTHERLAND, 2010)
10

REFERÊNCIAS BIBLIOGRÁFICAS

AFONSO, INACIO ORTH; RAFAEL, PRIKLADINICKI. Planejamento e gerência de


projetos. EDIPUCRS, 2009.

HELDMAN, KIM. Gerência de Projetos: Guia para o exame oficial do PMI. 2ª


reimpressão. Editora Elsevier, 2005.

MARTINS, JOSÉ CARLOS CORDEIRO. Técnicas para gerenciamento de


projetos de software. BRASPORT LIVROS E MULTIMIDIA LTDA, 2007.

ROGER, S. PRESSMAN. Engenharia de Software. 6 ed. McGraw-Hill, 2006.

SCHWABER, KEN; SUTHERLAN, JEFF. The Scrum Guide. Scrum.org, 2010.

SCOTT, W. AMBLER. Modelagem Ágil – Práticas eficazes para a programação


extrema e o processo unificado. Artmed Editora S/A, 2002.

STANDISH GROUP. Chaos Report 2009. Disponível em:


<http://www1.standishgroup.com/newsroom/chaos_2009.php>. Acesso em 25 Mar
2011.