Local Agile Game-based Process (LAGPRO)

O LAGPRO ´e um processo para ser utilizado por equipes locais para refor¸car a coor- dena¸c˜ao e motiva¸c˜ao em um contexto de desenvolvimento distribu´ıdo de software. ´E um processo iterativo, em que cada itera¸c˜ao ´e dividida em fases, as quais tˆem dura¸c˜ao de duas semanas.

A estrutura e os princ´ıpios gerais do LAGPRO s˜ao baseados no AUP, simplificando suas disciplinas e fases. A disciplina Model, foi esbo¸cada utilizando a constru¸c˜ao de modelos simplificados no in´ıcio de cada nova itera¸c˜ao e de modelos de revis˜oes ao final de cada itera¸c˜ao. A metodologia Test-Driven Development (TDD) foi utilizada na disciplina implementa¸c˜ao, onde os times de testes definiam os testes unit´arios automatizados e os times de desenvolvimento implementavam as regras de neg´ocio (Ribeiro et al., 2006).

O LAGPRO buscou introduzir motiva¸c˜ao em equipes utilizando elementos de jogos e competi¸c˜ao. Segundo Ribeiro et al. (2006), as tentativas de execu¸c˜ao do processo falharam devido `a rejei¸c˜ao por parte dos membros do time com rela¸c˜ao `a caracter´ıstica competitiva.

3.2

An´alise Comparativa dos Processos de Desenvolvi-

mento

Os processos RUP e XP foram escolhidos por serem amplamente utilizados, quer na academia como na ind´ustria, sendo uma metodologia tradicional e uma ´agil, respectiva-

mente. Em (Rocha et al., 2008) ´e apresentado um relato de experiˆencia sobre a adapta¸c˜ao do RUP para pequenas equipes de desenvolvimento distribu´ıdo. O AUP foi selecionado por ser uma simplifica¸c˜ao do RUP que utiliza conceitos de m´etodos ´ageis. E os demais, o Extended Workbench Model e o LAGPRO, por serem utilizados no contexto de DDS, conforme pode ser visto em (Ribeiro et al., 2006), (Paulish, 2007) e (Urdangarim, 2008). A seguir ser´a apresentada a compara¸c˜ao entre os processos de desenvolvimento de software mencionados acima. Para tanto, foi identificado um conjunto de crit´erios de compara¸c˜ao baseando-se nas caracter´ısticas de desenvolvimento distribu´ıdo de software identificadas em (Urdangarim, 2008) (crit´erios de A - G), nos elementos b´asicos de um processo de software (crit´erios de H - J) e no tipo de metodologia (crit´erio K e L). Os crit´erios a serem utilizados na compara¸c˜ao visando identificar qual dos processos melhor atende `as necessidades dos projetos DDS, s˜ao:

∙ (A) Diversidade: Identifica se o processo analisado oferece mecanismos para con- trole, coordena¸c˜ao e comunica¸c˜ao das diferen¸cas (cultural e idioma) entre as equipes envolvidas no projeto.

∙ (B) Requisitos: Caracteriza se o processo analisado trata a especifica¸c˜ao formal dos requisitos, que tem por objetivo amenizar os problemas de ambiguidades nos artefatos e com isso, minimizar a comunica¸c˜ao.

∙ (C) Centralizado: Identifica se o processo analisado apresenta uma centraliza¸c˜ao do controle das atividades do projeto.

∙ (D) Descentralizado: Identifica se o processo analisado ´e caracterizado pela descen- traliza¸c˜ao do controle das atividades do projeto.

∙ (E) Acompanhamento: Identifica se o processo caracteriza-se por acompanhar, periodicamente, a evolu¸c˜ao dos trabalhos dos times remotos.

∙ (F) Colabora¸c˜ao: Caracteriza se o processo permite o uso de ferramentas de cola- bora¸c˜ao entre os times como meio de compartilhamento de informa¸c˜oes.

∙ (G) Confian¸ca: Identifica se o processo ´e capaz de promover confian¸ca entre os membros dos diferentes times. A confian¸ca pode ser alcan¸cada oferecendo visibili- dade adequada do projeto, por meio da divulga¸c˜ao das informa¸c˜oes e por meio de mecanismos de percep¸c˜ao.

∙ (H) Pap´eis: Identifica se o processo possui uma organiza¸c˜ao r´ıgida na defini¸c˜ao dos pap´eis a serem desempenhados.

∙ (I) Artefatos: Identifica se o processo apresenta a defini¸c˜ao dos artefatos requeridos e gerados em cada fase.

∙ (J) Atividades: Identifica se o processo define as atividades que devem ser realizadas em cada fase.

∙ (K) Metodologia tradicional: Caracteriza se o processo apresenta o enfoque de uma metodologia tradicional de desenvolvimento de software.

∙ (L) Metodologia ´agil: Caracteriza se o processo apresenta o enfoque de metodologia ´

agil.

Segundo Urdangarim (2008), definir os crit´erios de an´alise ´e uma atividade que requer um consider´avel esfor¸co intelectual e que, geralmente, d´a margem para questionamentos que podem ir al´em do escopo do trabalho em quest˜ao. Desse modo, com os crit´erios expostos n˜ao se espera esgotar as perspectivas de compara¸c˜ao dos processos.

Na Tabela 3.1 os processos selecionados e descritos na Se¸c˜ao 3.1 s˜ao comparados em rela¸c˜ao aos crit´erios mencionados acima, cuja an´alise encontra-se na sequˆencia.

Tabela 3.1: An´alise Comparativa dos Processos

Processo/Crit´erios A B C D E F G H I J K L RUP x x x x x XP x x x x x x x x AUP x x x x x Extended Workbench Model x x x x x x x LAGPRO x x x x x x x x x

Analisando a Tabela 3.1 acima, ´e poss´ıvel observar que nenhum dos processos atende todas as necessidades dos projetos desenvolvidos com equipes geograficamente distribu´ıdas.

N˜ao h´a um processo que contemple os crit´erios relacionados ao DDS (crit´erios de A - G) e apresente os elementos b´asicos (pap´eis, artefato e atividades). Desse modo, percebe-se a inexistˆencia de um processo sistem´atico que contemple as caracter´ısticas dessa nova configura¸c˜ao de desenvolvimento. Para tanto, devem ser definidos as ativi- dades, os artefatos e os pap´eis necess´arios em cada etapa do desenvolvimento utilizando a abordagem distribu´ıda.

O RUP, o XP e o AUP definem o conjunto m´ınimo de elementos que comp˜oem um processo. Entretanto, n˜ao apresentam procedimentos para tratar as quest˜oes relacionadas aos problemas de DDS, que s˜ao representadas pelos crit´erios de A a G.

O Extended Workbench e o LAGPRO, embora tenham sido definidos para serem uti- lizados por projetos que s˜ao desenvolvidos de modo distribu´ıdo, n˜ao possuem mecanismos

para explicitar a diversidade, tratam apenas a especifica¸c˜ao formal dos requisitos. No Extended Wokbench, tamb´em, n˜ao s˜ao contemplados os fatores relacionados `a colabora¸c˜ao e confian¸ca. Al´em disso, n˜ao foram encontrados relatos sobre os artefatos gerados. E, no caso do LAGPRO, tamb´em, n˜ao foram identificadas as atividades.

Desse modo, ´e poss´ıvel evidenciar a necessidade de um processo que atenda essas novas demandas geradas pela abordagem distribu´ıda e apresente a defini¸c˜ao dos elementos que um processo deve contemplar.

O processo de desenvolvimento de software tem passado por intensas transforma¸c˜oes nos ´ultimos anos. E nesse contexto, novas abordagens de desenvolvimento tˆem surgido objetivando que muitos dos problemas encontrados nos projetos anteriores n˜ao sejam repetidos. Dentre os problemas mais comuns aos projetos de software podem ser desta- cados: altos custos para evolu¸c˜ao, inconsistˆencia entre documenta¸c˜ao e sistema final, pouca ou quase que total falta de portabilidade e baixa confiabilidade. ´E sabido que o sucesso de um projeto de desenvolvimento de software inicia-se no devido planejamento e na escolha de uma metodologia compat´ıvel com as caracter´ısticas do mesmo, o que refor¸ca a necessidade de um processo de desenvolvimento que contemple de forma efetiva as necessidades do DDS.

Audy e Prikladnicki (2008), destacam que em um ambiente de desenvolvimento dis- tribu´ıdo, ´e fundamental um processo de desenvolvimento comum `a equipe pois, uma metodologia auxilia diretamente na sincroniza¸c˜ao, fornecendo a todos os membros da equipe uma nomenclatura comum de tarefas e atividades, e um conjunto comum de expectativas aos elementos envolvidos no processo.

Segundo Rocha et al. (2008), quando o contexto ´e Desenvolvimento Distribu´ıdo, o cen´ario muda com rela¸c˜ao ao desenvolvimento de software tradicional, pois as vari´aveis e os riscos aumentam. Ent˜ao, se n˜ao houver uma metodologia adequada para o processo de desenvolvimento, o projeto ter´a boas chances de n˜ao corresponder ao planejamento inicial. Em sua primeira percep¸c˜ao sobre o uso e estudo de DDS, Rocha et al. (2008) ressaltam a necessidade de processos mais adequados, pois, com base nas pesquisas realizadas, n˜ao foi f´acil a identifica¸c˜ao de modelos de referˆencia de processos para o ambiente DDS.