Metodologias geis: Estudo comparativo entre SCRUM e FDD

Joelson Isidro, Jean Fidelis e Vitor Melo Cincia da Computao - Centro Universitrio de Joo Pessoa (Unip) BR 230 - Km , gua Fria - CEP 58053-000 - Joo Pessoa - Paraba Brasil
joelson.isidro@gmail.com, jean_fernandes1983@hotmail.com, vitor_linkinpark27@hotmail.com

Abstract. Has been a long time since the Software Engineers community is interested in agile methods, because this methods is seems as a alternative for system development process in a faster, efficiently way and attend the real necessities from clients. There are a lot of methods available on the market who uses a agile approach and presents many similar activities on your development process. This article describe the characteristics from agile methods and defines SCRUM and FDD methodologies, as well make a comparison between both. Resumo. Cada vez mais os mtodos geis tm despertado o interesse da comunidade de Engenharia de Software como uma alternativa para o processo de desenvolvimento de sistemas de uma maneira mais rpida, eficiente e que atenda as reais necessidades dos clientes. Existem no mercado vrios mtodos disponveis que utilizam a abordagem gil e que, por seguirem os princpios geis, apresentam uma srie de atividades semelhantes no seu processo de desenvolvimento. Este artigo descreve as caractersticas presentes em metodologias geis e em especial define as metodologias SCRUM e FDD, como tambm faz uma comparao entre as duas.

1.

Introduo

Este artigo apresenta caractersticas das metodologias geis e em especial as metodologias SCRUM e FDD. O objetivo do mesmo compor as notas do 3 estgio nas disciplinas de Anlise e Projeto de Sistemas I e Engenharia de Software consecutivamente. A indstria de desenvolvimento de software tem se tornado uma das mais importantes indstrias do nosso tempo. Empregando milhares de trabalhadores em todos os pases do mundo, essa indstria cria alguns dos produtos mais essenciais que ns utilizamos para manter o nosso estilo de vida Na intensa competitividade do ambiente de desenvolvimento de software, o que separar os melhores dos piores, os vencedores dos perdedores? Esta resposta simples: a sua habilidade de criar e entregar mais rapidamente os produtos de software com mais qualidade e que melhor reflitam as reais necessidades dos clientes. Os mtodos geis utilizados para desenvolvimento de software so um diferencial que promete aumentar a satisfao do cliente agregando maior valor ao produto final, produzindo softwares de alta qualidade e acelerando os prazos de desenvolvimento de projetos.

2.

Metodologias geis

Os mtodos geis so processos de software bastante utilizados atualmente. Eles surgiram no final dos anos 90, como uma alternativa aos mtodos tradicionais, e propem agilizar o processo de desenvolvimento de software. Esses mtodos possuem em comum o fato de serem aplicados em projetos de baixa complexidade, utilizando ciclos iterativos curtos, planejamento guiado por funcionalidades, retro alimentao constante, tolerncia a mudanas, proximidade da equipe, intimidade com o cliente e um foco no ambiente geral de trabalho da equipe [Machado 2005]. Os mtodos geis oferecem s organizaes uma grande variedade de prticas e enfoques para o desenvolvimento de software, propiciando que as organizaes escolham o mtodo que melhor supra suas necessidades. Apesar destes mtodos serem guiados por funcionalidades, onde um conjunto de funcionalidades desenvolvido a cada iterao, eles as especificam de diferentes maneiras.

3.

SCRUM

Scrum, cuja definio foi formalizada por Ken Schwaber nos anos 90, um mtodo gil direcionado para a gerncia de projetos. O objetivo desse mtodo definir um processo de desenvolvimento interativo e incremental podendo ser aplicado no gerenciamento de atividades complexas, ele visa entregar um software de qualidade que seja til para o cliente. Aplica-se a projetos tanto pequenos como grandes. Pois, se uma empresa no possui processos bem definidos, o Scrum uma das melhores opes, pois ele mais simples de entender e de implantar que outros processos. Fazendo com que as chances de sucesso sejam maiores. A grande vantagem que ele por ser centrado no trabalho em equipe, traz uma caixa de ferramentas de boas prticas de trabalho, melhorando a comunicao e a cooperao, permitindo que cada um faa o seu melhor, se sentindo motivado profissionalmente, proporcionando um aumento de produtividade. A Scrum Alliance, organizao fundada pelos criadores da metodologia Scrum, para promover, apoiar e gerar recursos aos usurios da metodologia oferece cinco certificaes: ScrumMaster (CSM), Scrum Product Owner (CSPO), Scrum Practitioner (CSP), Scrum Coach (CSC) e Scrum Trainer (CST). Para os profissionais especializados, essas certificaes representam mais uma oportunidade de trabalho, pois a procura por esses contedos est cada vez maior. Mas, para os que visam capacitao em processos geis, de extrema importncia buscar referncias sobre o contedo e os responsveis por ele, porque nem todos os cursos tm boa qualidade.

Figura 1. Modelo do SCRUM

3.1

Papis

Product Owner (PO): Proprietrio do produto. ScrumMaster (SM): Membro da equipe responsvel pela gesto do projeto. So normalmente engenheiros de software ou da rea de sistemas. Apesar de ser gestor no tem propriamente autoridade sobre os demais membros da equipe. Equipe Scrum: responsvel por fazer estimativas; Definir as tarefas; Desenvolver o produto; Garantir a qualidade do produto; Apresentar o produto ao cliente.

3.2

Cerimnias

Planejamento da Sprint: a primeira reunio. Ela dividida em duas partes. Na primeira parte, o Product Owner define as prioridades, seleciona os itens do backlog e meta da Sprint. Na segunda parte a equipe define a Sprint Backlog. Reunio Diria: Somente membros da equipe devem participar. A durao dela de 15 minutos. Onde o objetivo desta reunio fazer que sejam respondidas trs questes:- O que eu fiz ontem? -O que vou fazer hoje? -Encontrei algum impedimento? Reviso da Sprint: Acontece no final da Sprint. Outras pessoas podem ser convidadas se necessrio. O objetivo da reunio apresentar o que foi realizado pela equipe durante a Sprint e fazer a entrega do produto (software funcionando) para o PO. (Normalmente apresentada uma pequena demonstrao do software). Retrospectiva da Sprint: Acontece logo aps a Reviso da Sprint. O objetivo avaliar o que deu certo e o que deu errado durante a Sprint, e tambm, fazer as devidas modificaes para a prxima Sprint, ou seja, o ciclo de melhoria contnua.

3.3

Artefatos

Product Backlog: uma lista contendo todas as funcionalidades desejadas para um produto. PB (Product Backlog) poder ser criado de diversas maneiras: Com Estrias de Usurio, Com Casos de Uso ou Com Features (funcionalidades de produto). Sprint Backlog: Trabalho a ser desenvolvido num Sprint de modo a criar um produto a apresentar ao cliente. Burndown (grfico): O grfico de Burndown uma forma visual e rpida de enxergar o status atual do projeto.

4.

FDD

O FDD (Feature Driven Development) um mtodo gil para gerenciamento o desenvolvimento de software, criado em 1997 por Peter Coad e Jeff De Luca, num grande projeto em Java para o United Overseas Bank, em Singapura. Ele combina as melhores prticas do gerenciamento gil de projetos com uma abordagem completa para Engenharia de Software orientada por objetos, conquistando os trs principais pblicos de um projeto de software: clientes, gerentes e desenvolvedores. [Heptagon] O processo FDD dividido em 5 etapas: 1 DMA (Desenvolver um Modelo Abrangente) Pode envolver desenvolvimento de requisitos, anlise orientada por objetos, modelagem lgica de dados e outras tcnicas para entendimento do domnio de negcio em questo. O resultado um modelo de objetos (e/ou de dados) de alto nvel, que guiar a equipe durante os ciclos de construo. 2 CLF (Construir a Lista de Funcionalidades) Decomposio funcional do modelo do domnio, em trs camadas tpicas: reas de negcio, atividades de negcio e passos automatizados da atividade (funcionalidades). O resultado uma hierarquia de funcionalidades que representa o produto a ser construdo (tambm chamado de product backlog, ou lista de espera do produto). 3 PPF (Planejar por Funcionalidade) Abrange a estimativa de complexidade e dependncia das funcionalidades, tambm levando em considerao a prioridade e valor para o negcio/cliente. O resultado um plano de desenvolvimento, com os pacotes de trabalho na seqncia apropriada para a construo. 4 DPF (Detalhar por Funcionalidade) J dentro de uma iterao de construo, a equipe detalha os requisitos e outros artefatos para a codificao de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades inspecionado. O resultado o modelo de domnio mais detalhado e os esqueletos de cdigo prontos para serem preenchidos.

5 CPF (Construir por Funcionalidade) Cada esqueleto de cdigo preenchido, testado e inspecionado. O resultado um incremento do produto integrado ao repositrio principal de cdigo, com qualidade e potencial para ser usado pelo cliente/usurio. Dessas etapas as trs primeiras pertencem parte de planejamento do processo e as duas ltimas parte iterativa.

Figura 2. Modelo do FDD

5.

SCRUM x FDD

Sommerville (2003) afirma que os mtodos geis so fundamentados no Desenvolvimento Incremental. E conforme puderam ser observados, as atividades sugeridas durante o seu processo de desenvolvimento so bastante semelhantes aos Princpios geis. No Desenvolvimento Incremental os clientes inicialmente identificam, em um esboo, os requisitos do sistema e selecionam quais so os mais e os menos importantes. Em seguida definida uma srie de iteraes de entrega, onde em cada uma fornecida um subconjunto de funcionalidades executveis, dependendo das suas prioridades.

Figura 3. Modelo de Desenvolvimento Incremental Aps a identificao dos incrementos, as funcionalidades a serem entregues na primeira iterao so detalhadas e desenvolvidas. Paralelamente a este desenvolvimento, outras funcionalidades podem ser analisadas para fazerem parte dos outros incrementos. Uma vez que cada incremento concludo e entregue, os clientes podem coloc-lo em operao. O fato dos clientes poderem experimentar o sistema gradualmente facilita o esclarecimento das funcionalidades para os incrementos

subseqentes e medida que novos incrementos so concludos, eles so integrados s iteraes existentes, de modo que o sistema melhora a cada novo incremento entregue (SOMMERVILLE, 2003). Abaixo so apresentadas as caractersticas presentes nas metodologias em estudo para cada etapa de um modelo no Desenvolvimento Incremental.

5.1

Definio do Esboo dos Requisitos

No Scrum, de acordo com Schwaber e Beedle (2002), os requisitos conhecidos at o momento so listados dando origem ao Product Backlog. Estes requisitos so agrupados de acordo com as suas prioridades, apresentando as seguintes informaes: descrio do requisito, tempo estimado para o desenvolvimento e responsvel pelo desenvolvimento. No FDD, os requisitos j conhecidos so listados, definidos e documentados atravs de casos de uso ou users stories - descries textuais sucintas a respeito das funcionalidades do sistema (BECK, 2000). Sugere-se tambm que sejam construdos um diagrama de classes UML e diagrama(s) de seqncia UML com o objetivo de auxiliar na compreenso do projeto (HIGHSMITH 2002). Mtodo SCRUM FDD Especificao da Atividade Definio do Product Backlog Gerao de artefatos para a documentao dos requisitos Tabela 1 - Atividade - Definio do Esboo dos Requisitos

5.2

Atribuio dos Requisitos s Iteraes

No Scrum os requisitos que sero desenvolvidos em cada Sprint so definidos a partir da lista de requisitos contida no Product Backlog. Durante a Reunio de Planejamento da Sprint acontece a alocao dos requisitos s Sprints, de acordo com a sua prioridade, dando origem ao Sprint Backlog (BEEDLE et al, 1998). No FDD, as caractersticas (requisitos) so agrupadas e priorizadas de acordo com a sua importncia e dependncia dando origem aos conjuntos de caractersticas que sero desenvolvidos durante as vrias iteraes (HIGHSMITH 2002). Mtodo SCRUM FDD Especificao da Atividade Definio do Sprint Backlog. As Sprints (iteraes) duram no mximo 30 dias. As caractersticas so agrupadas, priorizadas e distribudas aos responsveis pelo seu desenvolvimento. As iteraes duram no mximo 2 semanas. Tabela 2 - Atividade - Atribuio dos Requisitos as Iteraes

5.3

Projeto da Arquitetura do Sistema

O Scrum sugere que seja feito um projeto geral do sistema baseado nos itens do Product Backlog (SCHWABER E BEEDLE, 2002). E tambm no sugere nenhuma tcnica associada a esta atividade. De acordo com Highsmith (2002a), De Luca (2002) e Abrahamsson (2002), o FDD sugere que seja construdo um diagrama de classes da UML para representar a

arquitetura do sistema. Para complementar o diagrama de classes tambm podero ser gerados diagramas de seqncia da UML.

5.4

Desenvolver Incremento do Sistema

No Scrum, esta atividade acontece durante a Sprint, onde so implementados os requisitos contemplados no Sprint Backlog. Schwaber (1995) ressalta que o desenvolvimento dos itens dentro de uma Sprint no segue nenhum processo prdefinido. Durante cada uma das Sprints acontecem as Reunies Dirias do Scrum que devem durar de 15 a 30 minutos e tm como objetivo que todos os envolvidos se mantenham informados sobre o progresso e as dificuldades encontradas. No FDD a implementao das classes e mtodos correspondentes s caractersticas que sero desenvolvidas durante as iteraes antecedida pelas atividades de anlise da documentao existente, gerao de diagramas de seqncia para o conjunto de caractersticas, refinamento do modelo gerado durante as atividades de definio dos requisitos e do projeto da arquitetura do sistema (HIGHSMITH 2002). Mtodo Especificao da Atividade SCRUM Implementao dos requisitos contemplados no Sprint Backlog para a Sprint corrente. Anlise da documentao existente, gerao de Diag. de Seqncia da UML, refinamento do modelo gerado nas atividades anteriores e implementao das FDD caractersticas que sero desenvolvidas durante a iterao corrente. Tabela 3 - Atividade - Desenvolver Incremento do Sistema

5.5

Validar Incremento

O Scrum sugere que a atividade de validao dos itens do Sprint Backlog implementados seja realizada no final da Sprint (SCHWABER E BEEDLE 2002). Segundo Abrahamsson (2002), no FDD os testes acontecem ao final de cada iterao, onde o conjunto de caractersticas implementadas durante a mesma testado atravs de testes de unidade pelos proprietrios de classe os programadores.

Mtodo Especificao da Atividade SCRUM No adota nenhum processo de validao pr-definindo Os testes e inspees so executados pelos prprios programadores aps a FDD implementao Tabela 4 - Validar Incremento

5.6

Integrar Incremento

No Scrum, a integrao dos resultados das vrias Sprints acontece ao final de cada uma delas (SCHWABER E BEEDLE 2002). O Scrum no sugere como esta atividade deve ser realizada. No FDD, a integrao do conjunto de caractersticas implementadas durante a iterao corrente com os outros conjuntos acontece ao final de cada iterao, aps os testes e inspees (HIGHSMITH 2002).

Mtodo SCRUM FDD

Especificao da Atividade Atividade realizada ao final de cada Sprint Atividade realizada aps os testes no incremento Tabela 5 - Atividade - Integrar Incremento

5.7

Validar Sistema

Conforme Schwaber e Beedle (2002), o Scrum valida a integrao dos incrementos no ltimo dia de cada Sprint atravs de uma reunio chamada Reviso da Sprint. Os participantes avaliam o incremento e decidem sobre as atividades seguintes. Aps a entrega do incremento ao cliente, o Scrum sugere que seja realizado algum tipo de acompanhamento em relao utilizao do mesmo, onde so executados mais testes com o objetivo de garantir a qualidade do mesmo. Aps a integrao dos conjuntos de caractersticas, o FDD valida todos os incrementos gerados atravs das inspees e dos testes de integrao (DE LUCA 2002). Mtodo SCRUM FDD Especificao da Atividade O cliente valida o sistema integrado em uma reunio no ltimo dia da Sprint Esta atividade ocorre atravs das inspees e dos testes de integrao Tabela 6 - Atividade - Validar Sistema

5.8

Entrega Final

No Scrum, o sistema entregue quando no existirem mais itens no Product Backlog a serem desenvolvidos (SCHWABER E BEEDLE 2002). O FDD sugere que todos os conjuntos de caractersticas devem passar pelas etapas de projeto e construo at que o sistema esteja pronto para ser entregue (HIGHSMITH 2002, ABRAHAMSSON 2002). Mtodo Especificao da Atividade SCRUM Todos os itens no Product Backlog desenvolvidos FDD O sistema entregue aps todos os conjuntos de caractersticas implementados Tabela 7 Atividade de Entrega Final

6.

SCRUM e FDD

O SCRUM e FDD juntos podem facilitar e potencializar o entendimento dos requisitos de software. O SCRUM excelente para o Gerenciamento de Projetos, contudo existe uma lacuna entre a Gesto de Projetos baseada em SCRUM e as prticas de engenharia de software. Ao utilizarmos o FDD conseguimos reduzir esta lacuna e nos aproximarmos da Engenharia de Software gil.

Devemos combinar, juntar as melhores prticas de cada mtodo para termos um processo completo de Gesto de Projetos e de Engenharia de software gil

Figura 4. Integrao das metodologias: SCRUM e FDD

6.

Consideraes Finais

A intensiva competitividade na rea de desenvolvimento de software faz com que as empresas busquem sempre o aperfeioamento de seus servios para poder vencer a concorrncia. Prazo e qualidade, alm claro de melhor aceitao e adaptao a mudanas so importantes diferenciais que podem ser atingidos utilizando-se metodologias geis de desenvolvimento. Embora no seja a soluo para todos os problemas, a metodologia gil mostra uma maneira de trabalhar bastante organizada e iterativa, podendo inclusive contribuir para um ambiente de trabalho mais amigvel. Portanto uma boa opo para se obter os diferencias desejados.

7.

Referncias
Guiffra, Ceclia E., Vilain (2010), Patrcia.Modelagem da Interao do Usurio no Desenvolvimento gil. Disponvel em: http://periodicos.unesc.net/index.php/sulcomp/article/viewFile/245/250. Acesso em: 07/05/2011. Conalves, Eduardo, Boeira, Heitor (2008). Projeto e implementao de uma ferramenta para gerncia de requisitos em metodologias geis. Disponvel em: http://www.seminfo.com.br/anais/2008/pdfs/seminfo/8-50723.pdf. Acesso em: 07/05/2011. Fagundes, Priscila et. al. (2008). Comparao entre os processos dos Mtodos geis: XP, SCRUM, FDD E ASD em relao ao desenvolvimento iterativo incremental.Disponvel em: http://revista.ctai.senai.br/index.php/edicao01/article/viewDownloadInterstitial/2 1/18. Acesso em: 07/05/2011.