UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E
SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE
APLICAÇÕES
Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹
¹Universidade Paranaense (Unipar)
Paranavaí – PR – Brasil
[email protected], [email protected]
Resumo. Este artigo constitui uma descrição de um estudo da utilização das
metodologias ágeis XP e Scrum para o desenvolvimento rápido de aplicações,
visando apresentar individualmente as características de cada metodologia,
de modo a auxiliar na escolha de um modelo que seja o mais adequado
possível para o tipo de aplicação que será desenvolvida e apresentando a
interação que é possível ter entre os dois frameworks.
1. Introdução
Nos anos 70, devido à chamada Crise do Software, muitos projetos enfrentavam
dificuldades para serem entregues devido ao grande crescimento pela demanda do
produto. Alguns destes problemas deviam-se ao fato de não existir uma metodologia
definida para a criação do software [Sommerville 2007].
As metodologias ágeis surgiram como uma alternativa as metodologias
tradicionais, visando a agilidade no desenvolvimento de softwares, onde é possível fazer
a incorporação de modificações que venham a ocorrer no decorrer do projeto. As
metodologias ágeis mais usadas atualmente são a SCRUM e o XP (Extreme
Programming).
Em 2001 um grupo de 17 desenvolvedores, produtores e consultores de software
assinaram o chamado “Manifesto para o Desenvolvimento Ágil de Software”, onde
declaravam que estavam descobrindo maneiras melhores para se desenvolver software, e
passaram a valorizar os seguintes conceitos: Indivíduos e interações mais que processos
e ferramentas; Software em funcionamento mais que documentação abrangente;
Colaboração com o cliente mais que negociação de contratos; Responder a mudanças
mais que seguir um plano [Beck et al 2001].
A seguir constam alguns modelos de processo de softwares ágeis que serão
abordados no artigo:
•
XP
•
Scrum
Existem outros modelos de processo, porém, não haverá uma investigação
profunda sobre eles.
Este artigo tem como objetivo fazer uma análise das características das
metodologias ágeis XP e Scrum, de forma a auxiliar na escolha de um modelo que seja
adequado ao tipo de aplicação que será desenvolvida, onde serão abordadas suas
características.
2. Extreme Programming (XP)
O trabalho inicial foi realizado por Kent Beck, que diante de uma crise, no ano de 2002,
foi constatado através de pesquisas que 45% das funcionalidades do software nunca são
utilizadas, 19% são usadas raramente, 16% às vezes, 13% frequentemente e apenas 7%
são utilizadas sempre. Perante a isso, Beck desenvolveu a metodologia chamada de
Extreme Programming, ou técnica de XP [Teles 2005].
O XP tem foco em sistemas que são voltados para as seguintes características
[Teles 2005]:
•
Projetos cujos requisitos são vagos e mudam com frequência;
•
Desenvolvimento de sistemas orientado a objeto;
•
Equipes pequenas, preferencialmente até 12 desenvolvedores;
•
Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser
implementado logo no início do projeto e vai ganhando novas funcionalidades
ao longo do tempo.
Uma das características do XP é assegurar que o cliente receba o máximo de
valor de cada dia de trabalho da equipe de desenvolvimento. O XP é 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 investimento em software [Teles 2005].
O processo de desenvolvimento XP é baseado em quatro valores fundamentais
que servem como parâmetro para o sucesso no desenvolvimento do software e para
garantir a satisfação do cliente. Estes valores podem ser observados na Figura 1 [Teles
2005].
Figura 1. Valores do XP [Junior 2012]
Feedback: A equipe de desenvolvimento é alimentada com o retorno que o cliente
necessita. O cliente reavalia suas necessidades e passa para a equipe analisar o que
precisa ser implementado, ou fazer alterações naquilo que já faz parte do software. É
com o feedback que o cliente conduz o desenvolvimento diário do projeto e garante que
a equipe direcione suas atenções para aquilo que realmente irá gerar mais valor [Teles
2005].
O feedback é imprescindível, seja na etapa de codificação, onde o programador
irá efetuar testes em cada trecho do código, seja na comunicação com o cliente, onde irá
ser verificado se os requisitos que o cliente necessita foram atendidos de forma simples
e eficaz [Beck 2004 apud Toniazzo 2007].
Coragem: Pelo fato do XP ser uma metodologia diferenciada das metodologias
tradicionais, ela acaba desafiando as metodologias clássicas em certos pontos, ela
aborda o desenvolvimento sobre um outro aspecto, ter coragem no desenvolvimento do
projeto é essencial, pois por várias vezes é preciso tomar decisões que em primeira
impressão podem parecer errados, porém acabam se mostrando decisões valiosas. Um
exemplo disso é analisar um determinado código e decidir se é valido continuar a
escrevê-lo ou se será necessário refazê-lo novamente de uma forma mais simples e
eficaz [Toniazzo 2007].
Comunicação: A comunicação é ponto fundamental para qual for a atividade que seja
desenvolvida em equipe, seja em qual área for, e no processo de desenvolvimento de
software não é diferente, é por meio de uma comunicação ágil que todo o processo é
baseado [Toniazzo 2007].
A metodologia XP da ênfase na comunicação, e da grande importância em fazêla de diversas formas, pois os processos tradicionais de desenvolvimento, essa
comunicação é feita basicamente com a escrita, os analistas descrevem e documentam o
que precisará ser feito e os programadores executam. Porém, os programadores têm
dificuldade em documentar seu trabalho [Toniazzo 2007].
Simplicidade: Durante a análise de uma dos requisitos de um projeto, o seu treinador
precisa se perguntar qual é a forma mais simples possível de se realizar esta tarefa.
Desta forma o XP mostra que a simplicidade é fundamental para se obter sucesso no
projeto [Beck 2004 apud Toniazzo 2007].
Muitos desenvolvedores têm dificuldade em encontrar está resposta, pois
desenvolver de forma simples não é fácil. Um requisito normalmente é ser
complementado futuramente com determinadas funcionalidades que o cliente ainda não
solicitou, tal funcionalidade será importante no futuro. O treinador da equipe tem como
responsabilidade lembrar os integrantes da importância de se pensar de maneira simples
[Toniazzo 2007].
3. SCRUM
Schwaber [2002] define o Scrum como “um processo Ágil ou ainda um framework para
gerenciamento de projetos Ágeis. É um processo de gerência de projetos, certamente
não é uma metodologia, pois isto seria pesado demais”.
O framework Scrum é um framework onde se pode tratar e resolver problemas
complexos e adaptativos, ao mesmo tempo em que se desenvolvem produtos que sejam
produtivos e criativos e que tenham o maior valor possível agregado. Umas das
características do Scrum é ser [Schwaber e Sutherland 2011]:
•Leve
•Simples de entender
•Extremamente difícil de dominar
O framework Scrum é constituído da seguinte forma: inicialmente é feito o
desenvolvimento do product backlog através das denominadas user stories, em seguida
é definido o product backlog, que é uma lista de requisitos necessários para o
desenvolvimento do produto. Ele é definido em tarefas e transformado em sprint
backlog, essas serão as tarefas que serão desenvolvidas durante a sprint. A duração de
cada sprint pode ser de certa de 2 a 4 semanas, e cada item da sprint backlog
corresponde a um dia de trabalho, em seguida, a cada sprint é obtido o product
increment [Junior 2012].
O Scrum possui alguns papéis, estes estão representados na figura 2. Estes papéis
serão estudados a seguir.
Figura 2. Papéis do Scrum
O Product Owner (PO) é a pessoa ou o representante do cliente que irá definir o
projeto, ele irá demonstrar a equipe a visão do produto e criar as fronteiras para limitar e
proteger a equipe e questões de padrões, tempo e preços [Silveira 2008 apud Junior
2012].
O PO é quem possui os conhecimentos do negócio e da necessidade do cliente,
ele é responsável em reunir as informações e conhecimentos necessários para a equipe
de desenvolvimento entender o que será preciso para desenvolver o produto [Rossi
2012]. O Scrum Master possuiu a responsabilidade de fazer o processo Srum funcionar
em sua totalidade sem nenhum impedimento fazendo com que a equipe trabalhe em suas
tarefas rapidamente [Carvalho 2009 apud Junior 2012].
O Scrum Master é responsável por fazer o time aderir as teorias, práticas e regras
do Scrum. O Scrum Master auxilia para os que estão fora do time Scrum a entender
quais as suas interações com o Time Scrum são úteis e quais não são. O Scrum Master
maximiza o valor criado pelo Time Scrum, ajudando todos a mudarem as interações
[Schwaber e Sutherland 2011].
O time Scrum (equipe) se organiza automaticamente e é multifuncional, o
próprio time escolhe qual a melhor forma de se executar determinada tarefa, não tendo a
necessidade de se ter um gestor para determinar as atividades dos desenvolvedores e o
que será desenvolvido, pois o time possui autonomia suficiente para fazer a execução do
trabalho [Schwaber e Sutherland 2011].
4. Metodologia
Para a realização deste artigo foram feitas pesquisas em artigos e sites da Internet. Após
as pesquisas foram feitas a identificação dos capítulos e suas respectivas descrições.
Desta forma, compondo o projeto final.
5. Conclusão
Na Engenharia de Software, ao se desenvolver um sistema, na maioria das vezes não se
utiliza apenas conceitos de um tipo de modelo de processo, sempre irão ser utilizados
idéias e métodos de outros modelos, da mesma forma em que não existe um modelo que
seja certo ou errado, existe o modelo que de adéque ao tipo de aplicação, ambiente e
objetivo.
Cada modelo de processo possui seus pontos fortes e suas fragilidades, porém
possui uma série de fases genéricas em comum. Caso o processo de software não for o
adequado, o produto final irá sofrer, mas uma ênfase somente no processo também é
pode ser perigosa. O produto e o processo devem ser tratados como algo que se
complementam.
Os objetivos deste artigo foram analisar os modelos de processo ágeis que são
utilizados na Engenharia de Software, exibindo suas características tornando mais claro
possível o entendimento de cada modelo para a escolha de um que seja adequado ao tipo
de aplicação que será desenvolvida.
Referências
Beck, Kent et al. Manifesto para Desenvolvimento Ágil de Software. 2001. Disponível
em: <http://agilemanifesto.org/iso/ptbr/> Acessado em 29/07/2013.
Junior, Julio Cesar Germano. Utilização da Metodologia Extreme Programming Como
Complemento do Framework Scrum. 2012.
Schwaber e Sutherland, Ken; Jeff. Um guia definitivo para o Scrum: as regras do jogo.
2011.
Disponível
em:
<http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum%20Guide%2
0-%20Portuguese%20BR.pdf> Acessado em 28/07/2013.
Schwaber, Ken; Beedle, Mike. Agile Software Development withScrum.New Jersey:
Prentice Hall, 2002.
Sommerville, I. (2007) “Engenharia de Software” 8ª Edição, Editora Pearson.
Teles, Vinícius Manhães. Extreme Programming: aprenda como encantar seus usuários
desenvolvendo software com agilidade e alta qualidade. 1. ed. São Paulo: Novatec,
2004. 316 p.
Toniazzo, José Carlos. Extreme Programming: Uma Abordagem em Testes de Software
Utilizando XUnit. 90 f. Projeto apresentado à Universidade Comunitária Regional de
Chapecó para obter grau em especialista em Engenharia e Qualidade de Software,
2007.
Disponível
em:
<http://zetoniazzo.files.wordpress.com/2007/08/monografia_jose_toniazzo.pdf>
Acesso em 24/07/2013.