RT Agile Methods

RELATRIO TCNICO
RT ES XXX / 2007
Reviso quasi-Sistemtica da Literatura: Caracterizao de Mtodos geis de Desenvolvimento de Software
Jos Fortuna Abrantes Guilherme Horta Travassos

Universidade Federal do Rio de Janeiro COPPE/Sistemas Caixa Postal 68.511 CEP 21.941-972 Rio de Janeiro RJ Brasil {jfa, ght}@cos.ufrj.br
PESC Programa de Engenharia de Sistemas e Computao COPPE / UFRJ
Rio de Janeiro, dezembro de 2007
Caracterizao de Mtodos geis de Desenvolvimento de Software Relatrio Tcnico ES xxx / 2007 ---------------------------------------------------------------------------------------------------------------------------------------------------------------
Reviso quasi-Sistemtica da Literatura: Caracterizao de Mtodos geis de Desenvolvimento de Software

Jos Fortuna Abrantes Guilherme Horta Travassos
Universidade Federal do Rio de Janeiro COPPE/Sistemas Caixa Postal 68.511 CEP 21.941-972 Rio de Janeiro RJ Brasil {jfa, ght}@cos.ufrj.br
ABSTRACT
This technical report aims to describe an investigation concerned with the characteristics that could be used to characterize agile development scenarios. A research protocol was formalized and executed in order to conduct a quasisystematic review, which means that no comparison could be possible since it represents a characterization review. The searches were conducted in the period of November-December/2006. The data obtained from the technical literature were analyzed and have allowed observing the characteristics that could be used to characterize a software development method as agile.
RESUMO
Este relatrio tcnico tem por objetivo descrever uma pesquisa relacionada a identificao de caractersticas de agilidade no contexto ddo desenvolvimento de software. Um protocolo de pesquisa foi formalizado e executado para conduzir uma quasi-reviso sistemtica da literatura, o que significa que no pode ser possvel executar qualquer comparao desde que esta representa uma reviso de caracterizao. As buscas foram realizadas no perodo de novembro-dezembro de 2006. Os dados obtidos da literatura tcnica foram analisados e permitiram observar as caractersticas que poderiam ser utilizadas para caracterizar um mtodo de desenvolvimento de software como sendo gil.
COPPE/UFRJ/PESC
Abrantes, Travassos
1- Introduo
A reduo do ciclo de desenvolvimento foi considerada uma das principais metas de desenvolvimento de software, a partir da dcada de 1990. Neste cenrio, Aoyama (1998) definiu agilidade em processos de software como sendo a capacidade de adaptaes rpidas a mudanas, nos requisitos e no ambiente que envolve o software. Aoyama props um processo gil a partir de experincias com desenvolvimento concorrente e distribudo, de lies aprendidas em fbricas de software japonesas e de conceitos em processos de produo de hardware. Foi ento cunhada a idia de processo gil de software, que no significa simplesmente desenvolvimento rpido de aplicaes, mas principalmente capacidade de adaptao com rapidez e flexibilidade a mudanas nos processos, nos produtos e no ambiente. Nos ltimos anos, os mtodos geis tm se apresentado como uma alternativa para o desenvolvimento de software. Tambm pode ser observado o crescimento do interesse das organizaes desenvolvedoras de software por tais mtodos. Para Boehm e Turner (2003, 2004) as metodologias geis de desenvolvimento prometem alto grau de satisfao do cliente, menores taxas de defeitos, tempos de desenvolvimento mais rpidos e uma soluo para mudanas rpidas de requisitos. Os mtodos geis de desenvolvimento de software tm chamado a ateno de engenheiros de software e de pesquisadores em todo o mundo [Abrahamsson, et al. 2003]. Segundo Hazzan e Dubinsky (2006) desenvolvimento gil de software tem a ver com mudanas culturais nos ambientes de desenvolvimento de software. Para Abrahamsson, Salo, Ronkainen e Warsta (2002) o que os mtodos geis buscam no como conter as mudanas mais cedo em um projeto de software, mas a melhor maneira de tratar mudanas inevitveis ao longo de seu ciclo de vida. Para alcanar seu objetivo, os mtodos geis so projetados para (1) produzir a primeira entrega em semanas e alcanar realimentao (feedback) rpida e mais cedo; (2) criar solues mais simples de modo que se houver mudanas que haja mais facilidade e menor volume de alteraes a serem feitas; (3) melhorar continuamente a qualidade do projeto, fazendo com que a iterao seguinte tenha menor custo de implementao; (4) testar constantemente, para detectar defeitos mais cedo e remov-los com menor custo. O entendimento do significado de agilidade no contexto de mtodos geis importante para guiar a evoluo de idias e pesquisas relacionadas com prticas de teste de software compatveis com os mtodos geis. Tal entendimento poder apoiar tambm, trabalhos relacionados com a verificao do alinhamento de caractersticas de projetos de software e alternativas de mtodos geis para desenvolv-los. A crescente imprevisibilidade do futuro um dos aspectos mais desafiadores da nova economia. Turbulncias tanto nos negcios quanto na tecnologia causam mudanas, que podem ser vistas como ameaas das quais se defender, ou como oportunidades a serem abraadas. A abordagem gil, ao invs de resistir mudana, busca acomod-la o mais fcil e eficientemente possvel, mantendo conscincia de suas possveis consequncias. A maioria das pessoas concordam que realimentao (feedback) importante, mas esquecem que o resultado de sua aceitao a mudana [Fowler e Highsmith, 2001]. Segundo Sugden e Strens (1996), para minimizar o impacto negativo da mudana nos objetivos do projeto e maximizar seus benefcios, trs principais
COPPE/UFRJ/PESC Abrantes, Travassos
estratgias so reconhecidas: identificar a mudana mais cedo no ciclo de vida; facilitar a incorporao da mudana quando inevitvel e se possvel reduzir a incidncia de necessidades de mudana. Para Rajlich (2006) a tentativa de congelar os requisitos por toda a durao do projeto no funciona, porque a acumulao de mudanas, tanto internas quanto externas muito grande e resultaria em falhas no projeto. O extremo oposto (afogar os programadores com um fluxo constante de mudanas) tambm no funciona porque criaria o caos no projeto. Um compromisso razovel seria congelar o ambiente por um tempo limitado chamado iterao. No final de cada iterao os stakeholders avaliam o progresso, consideram as mudanas no ambiente e decidem os caminhos da prxima iterao. As iteraes fornecem realimentao (feedback) e reduzem os riscos de surpresas e falhas. Iteraes rpidas so recomendadas por processos geis. H exemplos no mundo real, de argumentaes a favor e contra os mtodos geis [Boehm, 2002]. De todo modo, torna-se relevante conhecer mais sobre atividades de processos de desenvolvimento de software dentro do contexto de mtodos geis de desenvolvimento. Do mesmo modo, identificar caractersticas de projetos de software que possam credenci-los como candidatos a aplicao de mtodos geis, bem como identificar caractersticas de mtodos geis que os credencie para aplicao em determinados projetos de software, uma tarefa importante. Abrahamsson et al. (2003) considera relevante entender as propriedades de cada mtodo gil em particular, para que se possa fazer um julgamento adequado quando for o caso. Para analisar cada mtodo gil podem-se adotar perspectivas. E para caracterizar desenvolvimento gil de software em geral, necessrio identificar atributos. Boehm e Turner (2004) entendem que a agilidade responde pela liberdade e criatividade em um projeto de software, aplicando memria e histria para se ajustar a novos ambientes, para reagir e se adaptar, tirando vantagens de oportunidades inesperadas e para atualizar uma base de experincias para o futuro. O Longman Dictionary of Contemporary English (1992) define gil como sendo a qualidade de ser capaz de se mover rpida e facilmente. O Dicionrio Lello Popular (1958) define gil como a qualidade do que est vivo e se move com facilidade e presteza. O Dicionrio Aurlio, Holanda (1977), define gil como hbil, o que se move com destreza, que tem presteza de movimentos, ligeiro. No h definio universalmente aceita para um mtodo gil no campo de desenvolvimento de sistemas de informao [Conboy e Fitzgerald, 2004]. Nesse contexto, interessante identificar e observar quais propriedades ou caractersticas devem estar associadas a um mtodo de desenvolvimento de software, para que ele possa ser considerado gil. Mtodos geis no so ad-hoc e requerem disciplina por parte das equipes que os utilizam [Taylor et al, 2006]. A questo bsica de pesquisa determinar o que caracteriza um mtodo de desenvolvimento de software como sendo um mtodo gil. Pretende-se chegar a um conjunto bsico de caractersticas que so necessrias para que um mtodo possa ser classificado como mtodo gil, investigando atravs de reviso sistemtica de literatura (estudo secundrio) [Biolchini et al., 2005], quais so as caractersticas de agilidade no contexto de mtodos geis. O que significa ser gil para um mtodo de desenvolvimento de software?
Ser adotada uma abordagem que estrutura a questo de pesquisa em 4 elementos bsicos: populao, interveno, comparao e resultado [Pai et al, 2004]. Tendo em vista ser o objetivo deste estudo realizar uma caracterizao da rea, no haver comparao e nem ser possvel aplicao de meta-anlise. Desta forma, podemos definir este tipo de estudo secundrio, apesar de sistemtico, como uma quasireviso sistemtica. A motivao desta pesquisa servir de apoio busca de entendimento e soluo a outras questes envolvendo atividades de processo com mtodos geis. Este trabalho se estrutura da seguinte forma: na seo 2 explicitado o objetivo do trabalho. Na seo 3 apresentado um protocolo elaborado especificamente para esta reviso sistemtica. Na seo 4 descreve-se a execuo do protocolo apresentado na seo 3. Na seo 5 so apresentados os resultados obtidos com a reviso sistemtica. Na seo 6 apresenta-se uma proposta de caracterizao bsica de mtodos geis de desenvolvimento de software. Na seo 7 so apresentadas as concluses deste trabalho e sugestes para seus possveis desdobramentos. Na seo 8 esto registradas as referncias bibliogrficas.
2- Objetivo do Trabalho
Pretende-se investigar, atravs de reviso sistemtica de literatura, quais so as propriedades ou caractersticas de agilidade no contexto de mtodos geis para desenvolvimento de software. O que significa ser gil para um mtodo de desenvolvimento de software? No se pretende investigar caractersticas de mtodos geis especficos, mas de uma maneira geral, identificar quais so as propriedades ou caractersticas desse grupo de mtodos para desenvolver software e assim obter um conjunto de caractersticas desejveis para um mtodo ser considerado gil.
3- Protocolo de Reviso Sistemtica de Literatura

Ser adotada uma abordagem que estrutura a questo de pesquisa em quatro elementos bsicos: populao, interveno, comparao e resultado [Pai et al, 2004]. 3.1. Objetivo Identificar as propriedades ou caractersticas dos mtodos geis de desenvolvimento de software, de uma maneira geral. 3.2. Formulao da Pergunta Quais so as propriedades ou caractersticas dos mtodos geis de desenvolvimento de software? Problema: Encontrar propriedades ou caractersticas de mtodos geis de desenvolvimento de software. Aplicao: Servir de base ou apoiar pesquisas envolvendo (1) atividades de processo em mtodos geis de desenvolvimento de software e envolvendo (2) critrios para seleo de mtodos geis a serem aplicados em projetos de desenvolvimento de software.
Populao: Projetos de desenvolvimento de software. Interveno: Mtodos geis de desenvolvimento de software. Comparao: No h. Resultado: Lista de propriedades ou caractersticas de agilidade de mtodos de desenvolvimento de software. Controle: Miller, G. G. The characteristics of agile software processes, The 39th International Conference of Object-Oriented Languages and Systems (TOOLS 39), Santa Barbara, CA, 2001. Abrahamsson, P. Salo, O. Ronkainen, J. Warsta, J. Agile Software Development Methods. Review and Analysis. Espoo. VTT Publications 478, 2002. Lindvall, M. Basili, V. et al. Empirical Findings in Agile Methods, In: Proceedings of Extreme Programming and Agile Methods SP/Agile Universe, pp. 197-207, 2002. 3.3. Seleo de Fontes As fontes sero bases de dados eletrnicas, disponveis no portal CAPES, incluindo conferncias, journals e relatrios tcnicos indexados por: Compendex EI IeeeXplore Inspec Web of Science ACM digital library Estas fontes foram escolhidas porque so as que se tem acesso para recuperao de referncias, bem como maior facilidade para recuperao do texto completo do artigo quando fosse o caso. Alm disso, estas fontes foram consideradas significativas no sentido de oferecerem publicaes pertinentes e que podem contribuir significativamente para o resultado da pesquisa. Idioma: Ingls, por ser maioria nas bases de dados pesquisadas. Em uma busca preliminar, no foram encontrados artigos escritos em portugus que trouxessem contribuio para o tema da pesquisa. Alm disso, textos em portugus, embora se reconhea a sua importncia, muitas vezes no se encontram indexados, o que aumenta o esforo ou impede sua busca. Tipos de documentos: Qualquer tipo de trabalho ou artigo que faa abordagem sobre propriedades ou caractersticas de agilidade em mtodos de desenvolvimento de software.
COPPE/UFRJ/PESC
Abrantes, Travassos
3.4. Palavras-chave Populao: software, development, implementation project, system, application, engineering, building,
Interveno: agile, method, adaptive, rapid, approach, technique, environment, process, practice, methodology Resultado: characteristic, attribute, property, feature, characterization, aspect, idea, factor, dimension, driver, perspective, requirement 3.5. Critrios de Incluso e Excluso Os documentos devem estar disponveis na web; Os documentos devem contemplar propriedades ou caractersticas de agilidade em mtodos geis de desenvolvimento de software; Os documentos devem relatar algum exemplo ou caso de utilizao de algum mtodo gil de desenvolvimento de software. 3.6. Processo de Seleo dos Estudos O pesquisador aplicar a estratgia de busca para a identificao de potenciais documentos. Os documentos identificados sero selecionados pelo mesmo pesquisador atravs da leitura e verificao dos critrios de incluso e excluso estabelecidos. Posteriormente a lista de documentos excludos ser avaliada por um segundo pesquisador. Em caso de conflito o documento ser includo. Ao final, os documentos sero lidos pelos pesquisadores para extrao de informaes sobre propriedades ou caractersticas dos mtodos geis de desenvolvimento de software. 3.7. Avaliao da Qualidade dos Estudos No ser feita por tratar-se de uma pesquisa para fins de caracterizao de objeto de estudo (os mtodos geis). Ser considerado que as fontes dos documentos so confiveis, e que os textos tenham passado por revises externas que serviram de filtragem para que tenham qualidade suficiente para contribuir com a reviso sistemtica. 3.8. Estratgia de Extrao de Informaes Para cada estudo selecionado aps a execuo do processo de seleo, sero extraidas as seguintes informaes: Ttulo do documento Autor(es) Fonte Ano de publicao Propriedades ou caractersticas de agilidade
Abrantes, Travassos
COPPE/UFRJ/PESC
3.9. Sumarizao de Resultados Os resultados sero tabulados. Sero realizadas anlises para identificar similaridades e as propriedades ou caractersticas mais relevantes para os mtodos geis de desenvolvimento de software. Ser considerada a freqncia com que uma propriedade ou caracterstica tenha sido apontada por autores diferentes. 3.10. String de Busca Na medida do possvel, a string de busca ser a mesma para todas as mquinas de busca. Contudo, poder haver adaptaes para se adequar a restries de mquinas de busca especficas, observando-se as seguintes diretrizes: 1. a string derivada dever ser logicamente equivalente string original, ou 2. na impossibilidade de se manter equivalncia exata, dever a string derivada ser mais abrangente para evitar perda de documentos potencialmente relevantes. De acordo com Pai et al (2004) os 4 elementos bsicos que estruturam a questo de pesquisa podem ser relacionados com o operador lgico AND. Isto foi feito para cada conjunto de palavras-chave escolhidas para representar cada um dos elementos populao, interveno e resultado. Para cada um destes trs elementos da estrutura, as respectivas palavras-chave foram combinadas com o operador lgico OR. Foi tambm utilizado o operador binrio NEAR, que um recurso oferecido pelas mquinas de busca para estabelecer que uma palavra-chave deva ocorrer prxima outra palavra-chave. Este operador pode ser parametrizado para estabelecer a proximidade ou distncia em quantidade de palavras, entre as duas palavras-chave, em cada ocorrncia. Se utilizado o parmetro zero, as duas palavras-chave devem ocorrer juntas para satisfazer a condio. Segue-se a string de base: (software NEAR0 development OR software NEAR1 engineering OR software NEAR0 building OR software NEAR0 implementation OR software NEAR0 projects OR software NEAR0 systems OR software NEAR0 application OR system NEAR0 development OR system NEAR0 engineering OR system NEAR0 building OR system NEAR0 implementation OR system NEAR0 project OR application NEAR0 development OR application NEAR0 engineering OR application NEAR0 building OR application NEAR0 implementation OR application NEAR0 project) AND ((agile OR adaptive OR rapid) AND (method OR process OR practice OR methodology OR approach OR technique OR environment)) AND ((agile) AND (characteristic OR attribute OR property OR feature OR characterization OR aspect OR idea OR factor OR dimension OR driver OR perspective OR requirement))
4- Execuo de Buscas
As buscas foram realizadas utilizando mquinas de busca de editoras ou bibliotecas digitais disponveis no portal CAPES.
COPPE/UFRJ/PESC
Abrantes, Travassos
4.1. Avaliao das Strings de Busca A busca, em todas as mquinas, com exceo da ACM digital library, foram efetuadas com a opo autostemming ligada e com utilizao do operador NEAR parametrizado. Os resultados obtidos com a string bsica foram comparados com os resultados obtidos em uma busca feita anteriormente, utilizando uma string menos abrangente. Observou-se que algumas mquinas de busca (Inspec, Web of Science), apesar de terem submetidas a si, uma string mais abrangente, deixaram de recuperar documentos relevantes, recuperados anteriormente. Por este motivo, foram feitos ajustes nas strings, at produzir resultado satisfatrio, recuperando quantidade de documentos pelo menos igual busca menos abrangente feita antes e no perdendo os documentos relevantes tambm recuperados anteriormente. As alteraes realizadas para cada mquina de busca sero apresentadas a seguir: Compendex EI: a busca no apresentou problemas, a string foi processada integralmente e, pelos resultados obtidos, no precisou ser ajustada. (software NEAR/0 development OR software NEAR/1 engineering OR software NEAR/0 building OR software NEAR/0 implementation OR software NEAR/0 projects OR software NEAR/0 systems OR software NEAR/0 application OR system NEAR/0 development OR system NEAR/0 engineering OR system NEAR/0 building OR system NEAR/0 implementation OR system NEAR/0 project OR application NEAR/0 development OR application NEAR/0 engineering OR application NEAR/0 building OR application NEAR/0 implementation OR application NEAR/0 project) AND ((agile OR adaptive OR rapid) AND (method OR process OR practice OR methodology OR approach OR technique OR environment)) AND ((agile) AND (characteristic OR attribute OR property OR feature OR characterization OR aspect OR idea OR factor OR dimension OR driver OR perspective OR requirement)) IeeeXplore: a busca apresentou problemas. A string no foi processada integralmente e teve que ser feita por partes, sucessivamente em cima dos resultados parciais. Observou-se que na ltima etapa a mquina no conseguiu processar a consulta, mesmo sendo sobre os resultados parciais alcanados. Seguindo as diretrizes estabelecidas no protocolo, a string foi reformulada e teve que ficar mais abrangente. Foram ento consideradas para busca apenas a interveno e o resultado, desconsiderando-se a populao e absorvendo-se o nus de selecionar documentos manualmente. A string original (no processada pela mquina) a que se segue: (software NEAR/0 development OR software NEAR/1 engineering OR software NEAR/0 building OR software NEAR/0 implementation OR software NEAR/0 projects OR software NEAR/0 systems OR software NEAR/0 application OR system NEAR/0 development OR system NEAR/0 engineering OR system NEAR/0 building OR system NEAR/0 implementation OR system NEAR/0 project OR application NEAR/0 development OR application NEAR/0 engineering OR application NEAR/0 building
OR application NEAR/0 implementation OR application NEAR/0 project) AND ((agile OR adaptive OR rapid) AND (method OR process OR practice OR methodology OR approach OR technique OR environment)) AND ((agile) AND (characteristic OR attribute OR property OR feature OR characterization OR aspect OR idea OR factor OR dimension OR driver OR perspective OR requirement)) Tendo em vista a impossibilidade de se processar a string completa, foi feito um desmembramento da mesma, tomando-se o cuidado de tentar um esquema que minimizasse a quantidade de consultas intermedirias. Para isso buscou-se determinar a extenso mxima da string que poderia ser processada pela mquina de busca da IeeeXplore, e a partir da foram montadas as strings complementares. A partir de uma string base foram montadas 11 strings diferentes cujos resultados foram agrupados. As repeties foram determinadas e eliminadas. O processamento do resultado seguiu o mesmo padro adotado para todas as mquinas das demais editoras ou bibliotecas digitais. A string de base utilizada foi a que se segue: (software <NEAR/0> develop OR software <NEAR/1> engineering OR software <NEAR/0> building OR software <NEAR/0> implement OR software <NEAR/0> projects OR software <NEAR/0> systems OR software <NEAR/0> application OR system <NEAR/0> develop OR system <NEAR/0> engineering OR system <NEAR/0> building OR system <NEAR/0> implement OR system <NEAR/0> project OR application <NEAR/0> develop OR application <NEAR/0> engineering OR application <NEAR/0> building OR application <NEAR/0> implement OR application <NEAR/0> project) AND (agile OR adaptive OR rapid) AND (method OR process OR practice OR methodology OR approach OR technique OR environment) AND agile Em seguida, foram formadas 11 strings, acrescentando-se string base o operador AND e cada um do seguintes termos: charact*, attribute, propert*, feature, aspect, idea, factor, dimension, driver, perspective e requirement. Foram efetuadas portanto, 11 buscas na mquina da IeeeXplore. Inspec: A mquina de busca conseguiu processar a string completa. Contudo, recuperou menor quantidade de documentos do que a busca com a string menos abrangente efetuada anteriormente, e, alm disso, deixou de recuperar um controle anteriormente recuperado. Por este motivo a string teve que ser reformulada. Observou-se atravs de testes que o problema no estava no operador NEAR, mas sim no termo characteristic que teve que ser passado para o plural, fazendo com que o controle fosse recuperado. Tendo em vista este resultado, todos os nomes na string base foram passados para o plural e a mquina de busca passou a recuperar o controle, os documentos relevantes da busca com a string menos abrangente feita anteriormente e passou a recuperar 250 documentos ao invs de apenas 77. A string final para a mquina da Inspec ficou assim:
COPPE/UFRJ/PESC
Abrantes, Travassos
(software NEAR0 development OR software NEAR1 engineering OR software NEAR0 building OR software NEAR0 implementation OR software NEAR0 projects OR software NEAR0 systems OR software NEAR0 applications OR systems NEAR0 development OR systems NEAR0 engineering OR systems NEAR0 building OR systems NEAR0 implementation OR systems NEAR0 projects OR applications NEAR0 development OR applications NEAR0 engineering OR applications NEAR0 building OR applications NEAR0 implementation OR applications NEAR0 projects) AND ((agile OR adaptive OR rapid) AND (methods OR processes OR practices OR methodologies OR approaches OR techniques OR environments)) AND ((agile) AND (characteristics OR attributes OR properties OR features OR characterization OR aspects OR ideas OR factors OR dimensions OR drivers OR perspectives OR requirements)) Na mquina da Inspec, a sintaxe do operador NEAR diferente da sintaxe do mesmo operador nas mquinas Compendex EI e IeeeXplore. Alm disso, na mquina da Inspec, a string completa s pode ser processada corretamente na opo Normal Search. Web of Science: Na mquina da Web of Science o operador equivalente ao NEAR das mquinas anteriores o SAME que no pode ser parametrizado. A mquina de busca no conseguiu processar a string completa. Por limitaes de implementao ficou restrita a 50 termos de busca e 49 operadores. Sendo assim, foram suprimidos da string bsica, 7 termos de busca, a saber: (idea, software building, system building, application building). Estes termos foram escolhidos porque so sinnimos menos especficos e mais abrangentes, includos no conjunto com o intuito de aumentar o recall. A mquina recuperou 23 documentos, acima dos 11 recuperados em busca anterior com string menos abrangente. Contudo, continuou deixando de recuperar documentos recuperados com a string menos abrangente em busca anterior. Sendo assim, foi feita a passagem para o plural, de todos os nomes usados na string, como j havia sido feito para a Inspec. O resultado foi bom, sendo recuperados os documentos relevantes anteriores e a quantidade total de itens recuperados pela mquina passou a ser de 45 documentos. A opo de busca utilizada na Web of Science teve que ser a General Search. A string final utilizada para a Web of Science ficou assim: (software SAME development OR software SAME engineering OR software SAME implementation OR software SAME projects OR software SAME systems OR software SAME application OR systems SAME development OR systems SAME engineering OR systems SAME implementation OR systems SAME projects OR applications SAME development OR applications SAME engineering OR applications SAME implementation OR applications SAME projects) AND ((agile OR adaptive OR rapid) AND (methods OR processes OR practices OR methodologies OR approaches OR techniques OR environments)) AND ((agile) AND (characteristics OR attributes OR properties OR features OR characterization OR aspects OR factors OR dimensions OR drivers OR perspectives OR requirements))
COPPE/UFRJ/PESC
Abrantes, Travassos
ACM digital library: Por ter uma mquina de busca mais restrita, que no permite o uso de operadores booleanos, a string bsica teve que ser reformulada para se adaptar aos operadores da ACM, observando-se, contudo, as diretrizes estabelecidas no protocolo. A opo de busca utilizada na ACM digital library foi a Advanced Search, com a digital library marcada. A string final utilizada para a ACM digital library ficou assim: +agile +software +development +method* +process* +characteristic* +attribute* propert* feature* characterization aspect* idea* factor* dimension* driver* perspective* requirement* adaptive rapid characterization engineering building implementation project* system* application* practice* approache* technique* environment* 4.2. Execuo das Buscas nas Bibliotecas Digitais Resultados: A quantidade de referncias recuperadas foi:
Quantidade Biblioteca Compendex EI IeeeXplore Inspec Web of Science ACM digital library TOTAL Recuperada 303 299 250 45 119 1016
4.3. Anlise dos Documentos Recuperados Todas as referncias recuperadas foram importadas para o JabRef [JabRef version 2.0.1 (c) 2006] que foi o gerenciador de referncias utilizado para manipular as referncias recuperadas pelas mquinas de busca. A ferramenta JabRef foi muito til para identificar repeties, categorizar referncias, priorizar leituras, tabular referncias, exportar listas para recuperao de documento completo, etc. Foram criados campos customizados na ferramenta JabRef, bem como a elaborao de layouts especficos de exportao, de modo a facilitar o trabalho de manipulao das referncias, inclusive
COPPE/UFRJ/PESC
Abrantes, Travassos
10
para priorizar a leitura dos documentos includos e selecionados para a reviso sistemtica. Nem todas as editoras / bibliotecas digitais permitem as mesmas facilidades para exportao do material recuperado em formato que possa ser importado por um gerenciador de referncias. A Compendex EI, a Inspec, e a Web of Science exportam de uma nica vez todos os itens recuperados pelas respectivas mquinas. A Inspec e Web of Science exportaram referncias com muitos campos faltantes (no preenchidos). A IeeeXplore s permite exportao por pgina de resultado. Quando se tentou reduzir a quantidade de exportaes aumentando a quantidade de itens por pgina, a exportao no funcionou, s podendo ser feita para uma das quatro opes de quantidade por pgina de exibio oferecida pela editora, que exatamente a mnima, com 25 itens recuperados, embora a mquina oferea opo para exibir at 100 itens por pgina. A ACM digital library s permite exportao item a item o que dificulta bastante o tratamento dos itens recuperados. As repeties foram eliminadas, mantendo-se o artigo remanescente contabilizado para a biblioteca digital com maior quantidade de itens recuperados. Todos os controles foram recuperados (a Compendex EI recuperou dois deles e a Inspec recuperou o outro). A nova situao quantitativa, aps eliminao de repetiess, ficou assim: Quantidade Artigos Artigos Inicial Repetidos Mantidos 303 2 301 299 86 213 250 126 124 45 28 17 119 2 117 1016 244 772
Biblioteca Compendex EI IeeeXplore Inspec Web of Science ACM digital library TOTAL
Em seguida, em uma primeira avaliao superficial (ttulo e abstract) foram excludas as referncias que nitidamente tratavam de outros assuntos no pertinentes pesquisa. Aps eliminao tambm de tais itens, a nova situao quantitativa ficou assim: A serem Biblioteca Compendex EI IeeeXplore Inspec Web of Science ACM digital library TOTAL
COPPE/UFRJ/PESC
Selecionados Excludos 301 213 124 17 117 772 53 12 6 8 102 181 Inicialmente 248 201 118 9 15 591
Abrantes, Travassos
Avaliados
11
Posteriormente, em uma avaliao mais apurada e detalhada, foram selecionados os documentos candidatos a fazer parte da reviso sistemtica. Para aproveitar as recuperaes j efetuadas, e enriquecer a reviso, foram separados documentos relevantes que tratam de agilidade de processos em outras reas de conhecimento (manufatura/negcios e eletrnica) com o objetivo de apurar se alguma idia foi ou pode ser aproveitada para o processo de desenvolvimento de software. Aps a ltima seleo os quantitativos ficaram assim:
Selecionados
Artigos Incluidos
TOT Software Neg/Manuf Eletrnica
Artigos Excluidos
TOT Software Neg/Manuf Eletrnica
Biblioteca
Compendex EI IeeeXplore Inspec Web of Science
Inicialmente
248 201 118 9 15 591
86 113 42 4 7 252
70 85 39 3 7 204
15 23 3 1
1 162 5 88 76 5 8 6 339
133 34 70 3 8 248
25 32 6 2
4 22
ACM digital library TOTAL
42
65
26
Do total de documentos recuperados, 23,9% eram repeties, em sua grande maioria causadas por superposio de recuperaes efetuadas nas diferentes bibliotecas digitais. Eliminadas as repeties, 23,3% deste subtotal de documentos (181 em 772) no foram considerados relevantes. Aps o exame minucioso dos documentos a partir de ttulo e resumo, mantida a mesma base (772 documentos) 32,8% dos documentos recuperados (252 documentos) foram incluidos e selecionados para leitura. Dentre os documentos excludos, a grande maioria (73,1%) trata de mtodos geis, sem, contudo, abordar suas propriedades ou caractersticas. Os 204 documentos incluidos e pertinentes rea de software foram classificados em uma escala de prioridades, p0, p1 e p2, com base na leitura minuciosa de ttulo e resumo. Isto foi feito para permitir um critrio no seqenciamento das leituras. Em p0 foram classificados os documentos identificados como tendo alta probabilidade de relevncia para a pesquisa. Em p2 foram classificados os documentos com pouca probabilidade de serem relevantes para a pesquisa. Em p1 foram classificados os documentos que geravam dvidas quanto sua melhor classificao considerando-se apenas p0 e p2. Essa categorizao resultou na seguinte tabela quantitativa: p0 p1 p2 58 documentos 72 documentos 74 documentos
COPPE/UFRJ/PESC
Abrantes, Travassos
12
Dos 252 documentos a serem lidos, poderiam ser identificados como prioritrios, 106 documentos, com a seguinte distribuio: Eletrnica Negcios/Manufatura Mtodos geis de Desenvolvimento de Software TOTAL 4.4. Extrao de Informaes Das 58 referncias da rea de software, 39 tiveram o texto completo recuperado. Estes documentos foram lidos e analisados para a reviso sistemtica. No foi possvel Ter acesso ao texto completo de 19 destas referncias. Das 42 referncias das reas de negcios/manufatura, 29 tiveram o texto completo recuperado. Estes textos foram lidos e analisados para verificar se havia alguma contribuio que pudesse ser aproveitada na reviso sistemtica. No foi possvel ter acesso ao texto completo de 13 destas referncias. A grande maioria dos documentos lidos no trazia uma contribuio direta para caracterizar mtodos geis de desenvolvimento de software. Muitos deles mencionavam alguma caracterstica, mas no traziam a semntica ou pelo menos a idia principal para as caractersticas citadas nos textos. Contriburam para a reviso sistemtica e tiveram as caracterizaes aproveitadas, os textos de 11 documentos apenas. Dentre eles, considerou-se 2 clusters de documentos, sendo cada cluster computado uma nica vez na incidncia das caractersticas nos artigos, para evitar a repetio de contagem de caractersticas similares. Na formao dos clusters para fins de contagem, foram utilizados os seguintes critrios: no contar repeties em artigos diferentes do mesmo autor. Tambm no contar repeties, quando o artigo foi escrito por mais de um autor, e as mesmas caractersticas foram abordadas por algum dos co-autores em outro artigo. Do mesmo modo, no contar repeties, quando caractersticas foram abordadas em um artigo, referenciando outro artigo no qual elas tambm j foram consideradas. As propriedades ou caractersticas de mtodos geis de desenvolvimento de software capturadas nos documentos includos foram tabeladas conforme se segue: 6 42 58 106
Tabela 1 Documentos descrevendo caractersticas de mtodos geis
Ord 1 Autor, Ano de publicao Titulo Fonte Propriedades ou Abrahamsson, P.; Warsta, J.; Siponen, M.T. & Ronkainen, J. 2003 New directions on agile methods: a comparative analysis. IEEE Computer Society Incrementalidade: pequenas releases de software, com ciclos rpidos de desenvolvimento;
Abrantes, Travassos
COPPE/UFRJ/PESC
13
Caractersticas Transparncia ou Clareza: o mtodo fcil de aprender e modificar e suficientemente documentado. Adaptabilidade: habilidade de atender e reagir a mudanas de ltima hora. Cooperatividade: interao de perto entre desenvolvedor e cliente. Autor, Ano de Boehm, B. & Turner, R. 2004a publicao New directions on agile methods: a comparative analysis. Titulo IEEE Computer Society Fonte Propriedades Incrementalidade: pequenas releases de software, com ciclos rpidos de desenvolvimento; ou Caractersticas Transparncia ou Clareza: o mtodo fcil de aprender e modificar e suficientemente documentado. Adaptabilidade: habilidade de atender e reagir a mudanas de ltima hora. Cooperatividade: interao de perto entre desenvolvedor e cliente. Autor, Ano de Meso, Peter. Jain, Radhika. summer 2006. publicao Contemporary practices in systems development. Agile Software Titulo Development: adaptive systems principles and best practices. Information Systems Management Fonte Propriedades Princpio dos sistemas abertos: interao aberta entre os vrios stakeholders (gerentes, desenvolvedores e clientes); ou Caractersticas Princpio de estrutura enxuta ou leve (lean): equipes capazes de procurar e receber continuamente, realimentao (feedback) de modo mais freqente e com mais rapidez. (teoria dos sistemas adaptativos complexos) Autor, Ano de Holmstrom, Helena. Fitzgerald, Brian. et al. summer 2006. publicao Contemporary practices in systems development. Agile Practices Titulo Reduce Distance in Global Software Development. Information Systems Management Fonte Propriedades Ciclos de desenvolvimento iterativos, curtos, dirigidos por caractersticas do produto; ou Caractersticas Perodos de reflexo e introspeco; Tomada de deciso colaborativa; Incorporao de realimentao (feedback) rpida; Integrao contnua de mudanas de cdigo ao sistema em desenvolvimento. Autor, Ano de Miller, Granville G. 2001. publicao The Characteristics of Agile Software Processes. Titulo Proceedings of the 39th Intl Conf. and Exhibition on Technology of Fonte Object-Oriented Languages and Systems (TOOLS01) Propriedades Modularidade: caracterstica que permite que um processo seja quebrado em componentes chamados de atividades; ou Caractersticas Iteratividade: foco em ciclos curtos, nos quais certo conjunto de atividades completado em poucas semanas; estes ciclos no sero
Abrantes, Travassos
COPPE/UFRJ/PESC
14
suficientes para obter os elementos 100% prontos, por isso so repetidos muitas vezes para refinar as entregas. Limitao de tempo: pode-se estabelecer limite de tempo para cada iterao ( a unidade para planejamento do projeto de desenvolvimento de software) programando-as; provavelmente no ser possvel programar todas as atividades do processo numa iterao, mas apenas aquelas para alcanar os objetivos estabelecidos no incio da iterao; funcionalidades podem ser reduzidas e atividades reprogramadas se no puderem ser completadas no espao de tempo alocado para aquela iterao. Parcimnia: (enxutez ou leveza - leanness) caracterstica que o processo gil tem de requerer o mnimo necessrio de atividades para mitigar riscos e alcanar metas; a reduo de atividades permitiria aos desenvolvedores entregar sistemas com cronogramas agressivos. Adaptabilidade: adaptao do processo para atender situaes ou riscos no previstos inicialmente; se no puderem ser atendidas com as atividades planejadas para a iterao, novas atividades so adicionadas iterao para alcanar as metas, ou atividades so descartadas da iterao se riscos inicialmente previstos se tornam sem base ou fundamento. Incrementalidade: no tentar construir o sistema todo de uma s vez; o sistema partido em incrementos que podem ser desenvolvidos em paralelo em tempos diferentes, fazendo teste de unidade para cada incremento; quando o incremento completado e testado, ele integrado ao sistema. Convergncia: estabelece que se esteja ativamente atacando todos os riscos que devem ser considerados; como resultado o sistema se torna mais prximo da realidade buscada a cada iterao; na medida em que os riscos so atacados de forma pr-ativa o sistema est sendo entregue em incrementos; faz-se o possvel para garantir o sucesso do modo mais rpido possvel. Orientao a pessoas: favorecer (valorizar) pessoas sobre processos e tecnologias; processos geis evoluem atravs de adaptao, de maneira orgnica; desenvolvedores so encorajados a aumentar sua produtividade, qualidade e desempenho; Colaboratividade: processos geis apiam comunicao entre membros da equipe, como parte vital de qualquer projeto de desenvolvimento de software; quando um projeto dividido em partes, entender como as partes se acomodam vital na criao do produto; h mais integrao do que simples comunicao; colaboratividade o ingrediente fundamental para integrar rapidamente um grande projeto medida em que os incrementos so desenvolvidos em paralelo; Autor, Ano de Aoyama, Mikio. 1998 publicao Agile Software Process and Its Experience. Titulo Proceedings of the 1998 International Conference on Software Fonte Engineering, p. 3-12 Propriedades Incrementalidade e Evolutividade: produtos so entregues
Abrantes, Travassos
COPPE/UFRJ/PESC
15
incrementalmente ao longo do tempo; ou Caractersticas Agilidade: adaptaes rpidas a mudanas nos requisitos e no ambiente; Modularidade e Enxutez ou Leveza (Leanness): mais modular e mais leve que modelos de processo convencionais. Baseado no Tempo: operado com um ciclo de tempo (prazo) fixo; grandes volumes de desenvolvimento so quebrados em mltiplas entregas que possam ser desenvolvidas incremental e concorrentemente de modo previsvel. Autor, Ano de Coram, Michael. Bohner, Shawn. 2005 publicao The Impact of Agile Methods on Software Project Management Titulo Proceedings of the 12th IEEE International Conference and Workshops Fonte on the Engineering of Computer-Based Systems (ECBS05) Propriedades Colaboratividade: ambiente altamente colaborativo, viabilizando a comunicao informal entre membros da equipe para disseminar ou Caractersticas informao. Revises de Cdigo: como forma de permitir disseminao de informaes chave (ex. atravs de programao por pares). Equipes pequenas: e pequeno nmero de equipes por projeto, necessrio para promover o ambiente colaborativo e por requerer menos planejamento para coordenar as atividades dos membros das equipes. Cronogramas curtos para entregas: de 2 semanas a no mximo 6 meses; no fim do prazo um produto funcional entregue ao cliente para avaliao, com mudanas a serem consideradas na escala de prioridades para as entregas subsequentes. Delimitao do tempo: o tamanho das entregas fixado, mas as funcionalidades no, mantendo o foco no cliente e evitando desperdcios e desvios de escopo. Testes constantes: para prevenir a degradao da qualidade, devido entregas muito curtas, d-se alta nfase a testes do produto ao longo do ciclo de vida. Visa prevenir tambm contra a idia de apenas escrever cdigo. Mtodos geis requerem testes de integrao ao longo do processo de desenvolvimento. Automao dos testes importante para que as builds dirias passem por testes de regresso garantindo que todas as funcionalidades estejam operando corretamente. Algumas metodologias geis recomendam at mesmo testes de aceitao a cada entrega, ou mesmo em desenvolvimento concorrente. Autor, Ano de publicao Titulo Fonte Propriedades ou Caractersticas Hansson, C. Dittrich, Y. Gustafsson, B. Zarnak, S. 2006 How agile are industrial software development practices? The Journal of Systems and Software 79, 12951311 Valorizar mais Indivduos e Interaes do que Processos e Ferramentas: a comunicao e a cooperao dentro das equipes de desenvolvimento so consideradas fundamentais e necessrias; um dos argumentos bsicos a favor de mtodos geis o aumento da eficincia das pessoas que trabalham juntas; interaes freqentes entre indivduos
Abrantes, Travassos
COPPE/UFRJ/PESC
16
compensam a documentao mais reduzida; um bom processo no conserta uma equipe ruim, mas uma equipe unida e coesa pode trabalhar com um processo ruim; a organizao e a nfase dada comunicao podem ser usadas como indicadores da agilidade das prticas de desenvolvimento de software. Valorizar mais Software Funcionando do que Documentao Abrangente: de acordo com a idia de desenvolvimento gil, o sistema funcionando o melhor meio para avaliar o desempenho da equipe; se a documentao estiver desatualizada, ela pouco til, assim, a recomendao gil no produzir documentao a no ser que a necessidade delas seja imediata e significativa; a atitude das organizaes para com a documentao, e o seu propsito, so indicadores da agilidade das prticas de desenvolvimento de software. Valorizar mais a Colaborao do Cliente do que Negociao de Contratos: o manifesto gil enfatiza que o software no pode ser desenvolvido com sucesso sem o envolvimento dos clientes e/ou usurios; o cliente, ou mais provavelmente, o usurio, conhece as necessidades e os requisitos para o novo software e deve portanto, tomar parte ativa no processo de desenvolvimento; a realimentao (feedback) do cliente/usurio deve acontecer de forma regular e freqente; contratos devem descrever e estipular como a equipe de desenvolvimento e o cliente/usurio trabalharo juntos; uma contrato que especifica apenas requisitos tcnicos, prazos e custos, seria falho; um amplo escopo de atividades que normalmente no so consideradas parte do desenvolvimento de software, como a funo de apoio ou suporte, esto relacionadas com o envolvimento do usurio e so indicadores da agilidade das prticas de desenvolvimento de software. Valorizar mais a Resposta a Mudanas do que Seguir um Plano: de acordo com o movimento gil, os planos devem ser flexveis, permitindo respostas a mudanas nos negcios e na tecnologia; a construo de planos detalhados para um horizonte de poucas semanas til; elaborar planos de mais alto nvel de abstrao para os prximos poucos meses e apenas algumas idias para o futuro considerada uma boa estratgia; provavelmente, o cliente/usurio ir alterar os requisitos quando ele testar o sistema; novos requisitos sero descobertos ou requisitos j elicitados sero considerados desnecessrios durante o processo de desenvolvimento, devendo o plano ser revisto e as prioridades reconsideradas; a grande questo como lidar com mudanas inevitveis ao longo do ciclo de vida dos projetos e responder a mudanas no ambiente? O modo pelo qual as organizaes reagem a mudanas tambm um indicador da agilidade das prticas de desenvolvimento de software. Autor, Ano de Cockburn, A. 2002 publicao Agile Software Development Joins the Would-Be Crowd Titulo Cutter IT Journal v. 15 n. 2 Fonte Propriedades Utilizao de subprojetos curtos: subprojetos de perodos mais longos tornam a equipe menos gil; a escolha tem que ser equilibrada porque ou
Abrantes, Travassos
COPPE/UFRJ/PESC
17
10
11
Caractersticas h trabalho de planejamento no incio e de integrao, teste e entrega no fim de cada subprojeto ou incremento. Reflexo sobre as prticas empregadas: reunies no fim de cada subprojeto ou iterao para os membros da equipe discutirem o que eles esto fazendo bem e o que precisa ser mudado. Trabalho em locais prximos: para algumas metodologias significa trabalhar na mesma sala ou em salas adjacentes, o que s funciona para equipes de 8 a no mximo 14 pessoas Todas as metodologias so sensveis localizao da equipe, pois esto fortemente fundamentadas em canais de comunicao rpidos e ricos, que permitem reduzir a documentao externa a ser construida e mantida. A agilidade pode variar variando-se a qualidade dos canais de comunicao e o balano entre conhecimento externo e tcito. No significa que a equipe para ser gil no possa produzir documentos; executar um projeto entre paises diferentes e fusos horrios diferentes realmente um obstculo para as equipes serem geis. Ateno s Equipes: as reunies dirias em p e os workshops de reflexo do s pessoas a chance de manifestar suas preocupaes com relao ao grupo; os membros da equipe devem ter meios de expressar seus medos e desejos para a comunidade. Autor, Ano de Abrahamsson, P. Salo, O. Ronkainen, J. Warsta, J. 2002 publicao Agile Software Development Methods. Titulo Review and Analysis. Espoo. VTT Publications 478 Fonte Propriedades Modularidade: no nvel de processo de desenvolvimento; Iteratividade: ciclos curtos que permitam verificaes e correes ou Caractersticas rpidas; Limitao de Tempo: ciclos de iterao de uma a seis semanas; Parcimnia: remoo de todas as atividades desnecessrias no processo de desenvolvimento; Adaptabilidade: para com possveis novos riscos emergentes; Incrementalidade: abordagem de processo que permite a construo de funcionalidades da aplicao em pequenos passos; releases pequenas com ciclos rpidos. Convergncia: abordagem para minimizar os riscos; Orientao a pessoas: favorecimento das pessoas sobre processos e tecnologia; Colaboratividade: estilo de trabalho comunicativo. Cooperatividade: cliente e desenvolvedores trabalhando constantemente juntos e comunicando-se de perto. Transparncia ou Clareza: o mtodo fcil de aprender e modificar e bem documentado. Autor, Ano de Lindvall, M. Basili, V. et al. 2002 publicao Empirical Findings in Agile Methods, Titulo In: Proceedings of Extreme Programming and Agile Methods Fonte SP/Agile Universe, pp. 197-207.
Abrantes, Travassos
COPPE/UFRJ/PESC
18
Propriedades Iteratividade: entrega um sistema completo logo no incio e ento muda a funcionalidade de cada subsistema com cada nova release. ou Caractersticas Incrementalidade: o sistema como especificado nos requisitos particionado em pequenos subsistemas por funcionalidade; nova funcionalidade adicionada a cada nova release. Auto-organizao: a equipe tem autonomia para se organizar da melhor forma para completar os itens de trabalho. Emergncia: permite-se que tecnologia e requisitos aflorem ao longo do ciclo de vida do produto. 5- Anlise dos Resultados Obtidos Foi montada uma tabela de caractersticas de mtodos geis encontradas nos artigos. Esta tabela foi construida a partir de cada caracterstica distinta identificada no conjunto de artigos. Foram contadas as quantidades de artigos em que a caracterstica foi abordada, sendo que nesta contagem cada cluster foi computado uma nica vez. Cada cluster ficou com 2 documentos, sendo a formao de cada um deles conforme se segue:
Tabela 2 Formao dos clusters de documentos incluidos na reviso sistemtica
Cluster
Documento Includo 1- Abrahamsson, P.; Warsta, J.; Siponen, M.T. & Ronkainen, J. New directions on agile methods: a comparative analysis. IEEE Computer Society, 2003, 244254 10- Abrahamsson, P. Salo, O. Ronkainen, J. Warsta, J. Agile Software Development Methods. Review and Analysis. Espoo. VTT Publications 478, 2002 2- Boehm, B. & Turner, R. Balancing agility and discipline: A Guide for the Perplexed. Pearson Education Inc, Boston, MA. 2004a 11- Lindvall, M. Basili, V. et al. Empirical Findings in Agile Methods, In: Proceedings of Extreme Programming and Agile Methods SP/Agile Universe, pp. 197-207, 2002.
Documento Representativo do Cluster (ord. na tab. 1)
Segue a tabela com a incidncia das caractersticas de mtodos geis nos artigos:
Tabela 3 Incidncia das caractersticas de mtodos geis nos artigos
Caracterstica Incrementalidade:
Descrio Pequenas releases de software, com ciclos rpidos de desenvolvimento; no entregar o produto todo de uma s vez;
Quant. Artigos 5
Ordem na Tab. 1 1,2, 5, 6, 9
COPPE/UFRJ/PESC
Abrantes, Travassos
19
no tentar construir o sistema todo de uma s vez; o sistema partido em incrementos que podem ser desenvolvidos em paralelo em tempos diferentes, fazendo teste de unidade para cada incremento; quando o incremento completado e testado, ele integrado ao sistema; o sistema como especificado nos requisitos particionado em pequenos subsistemas por funcionalidade; nova funcionalidade adicionada a cada nova release. Subprojetos de perodos mais longos tornam a equipe menos gil. Interao com proximidade entre Cooperatividade: desenvolvedor e cliente; interao aberta entre os vrios stakeholders (gerentes, desenvolvedores e clientes); o manifesto gil enfatiza que o software no pode ser desenvolvido com sucesso sem o envolvimento dos clientes e/ou usurios; o cliente, ou mais provavelmente, o usurio, conhece as necessidades e os requisitos para o novo software e deve, portanto, tomar parte ativa no processo de desenvolvimento; a realimentao (feedback) do cliente/usurio deve acontecer de forma regular e freqente; um amplo escopo de atividades que normalmente no so consideradas parte do desenvolvimento de software, como a funo de apoio ou suporte, esto relacionadas com o envolvimento do usurio e so indicadores da agilidade das prticas de desenvolvimento de software. Transparncia ou O mtodo fcil de aprender e Clareza: modificar e suficientemente documentado. Habilidade de atender e reagir a Adaptabilidade: mudanas de ltima hora; adaptao do processo para atender situaes ou riscos no previstos inicialmente; capacidade de adaptaes rpidas a mudanas nos requisitos e no ambiente; de acordo com o movimento gil, os
COPPE/UFRJ/PESC
1, 3, 8
1 5
1 1, 4, 5, 6, 8
Abrantes, Travassos
20
planos devem ser flexveis, permitindo respostas a mudanas nos negcios e na tecnologia; provavelmente, o cliente/usurio ir alterar os requisitos quando ele testar o sistema; novos requisitos sero descobertos ou requisitos j elicitados sero considerados desnecessrios durante o processo de desenvolvimento, devendo o plano ser revisto e as prioridades reconsideradas. O modo pelo qual as organizaes reagem a mudanas tambm um indicador da agilidade das prticas de desenvolvimento de software. Iteratividade: Envolvendo vrios ciclos curtos, dirigidos por caractersticas do produto, nos quais um certo conjunto de atividades completado em poucas semanas; estes ciclos no sero suficientes para obter os elementos 100% prontos, por isso so repetidos muitas vezes para refinar as entregas. Auto-organizao: As equipes determinam o melhor modo de trabalhar; a equipe tem autonomia para se organizar da melhor forma para completar os itens de trabalho. Emergncia: Os processos, princpios, estruturas de trabalho so reconhecidos durante o projeto ao invs de serem prdeterminados; permite-se que tecnologia e requisitos emerjam ao longo do ciclo de vida do produto; Perodos de reflexo e Reunies no fim de cada subprojeto ou introspeco; iterao para os membros da equipe discutirem o que eles esto fazendo bem e o que precisa ser mudado. Incorporao de Equipes capazes de procurar e receber realimentao (feedback) continuamente, realimentao rpida; (feedback) de modo mais freqente e com mais rapidez. (teoria dos sistemas adaptativos complexos) Modularidade: Caracterstica que permite que um processo seja quebrado em componentes chamados de atividades; modularidade permite que atividades sejam adicionadas ou removidas de um
COPPE/UFRJ/PESC
2, 4, 5, 7
4, 9
3, 4
5, 6
Abrantes, Travassos
21
processo quando necessrio. Estabelecimento de limite de tempo para cada iterao programada; provavelmente no ser possvel programar todas as atividades do processo numa iterao, mas apenas aquelas para alcanar os objetivos estabelecidos no incio da iterao; funcionalidades podem ser reduzidas e atividades reprogramadas se no puderem ser completadas no espao de tempo alocado para aquela iterao. Opera-se com um ciclo de tempo (prazo) fixo; grandes volumes de desenvolvimento so quebrados em mltiplas entregas que possam ser desenvolvidas incremental e concorrentemente de modo previsvel. Tamanho das entregas fixado, mas as funcionalidades no, mantendo o foco no cliente e evitando desperdcios e desvios de escopo. Parcimnia (Enxutez Caracterstica que o processo gil tem ou Leveza(Leanness): de requerer o mnimo necessrio de atividades para mitigar riscos e alcanar metas; a reduo de atividades permitiria aos desenvolvedores entregar sistemas com cronogramas agressivos; de acordo com a idia de desenvolvimento gil, o sistema funcionando o melhor meio para avaliar o desempenho da equipe; se a documentao estiver desatualizada, ela pouco til, assim, a recomendao gil no produzir documentao a no ser que a necessidade delas seja imediata e significativa; a atitude das organizaes para com a documentao, e o seu propsito, so indicadores da agilidade das prticas de desenvolvimento de software; remoo de todas as atividades desnecessrias no processo de desenvolvimento; Convergncia: Ataque efetivo a todos os riscos que devem ser considerados; como resultado o sistema se torna mais prximo da realidade buscada a cada iterao; medida que os riscos so Restrio de Prazo:
COPPE/UFRJ/PESC
5, 6, 7
5, 6, 8
Abrantes, Travassos
22
Orientao a pessoas:
Colaboratividade:
Equipes pequenas:
atacados de forma pr-ativa, o sistema est sendo entregue em incrementos; faz-se o possvel para garantir o sucesso do modo mais rpido possvel. Favorecer (valorizar) pessoas sobre processos e tecnologias; processos geis evoluem atravs de adaptao, de maneira orgnica; desenvolvedores so encorajados a aumentar sua produtividade, qualidade e desempenho; a comunicao e a cooperao dentro das equipes de desenvolvimento so consideradas fundamentais e necessrias; um dos argumentos bsicos a favor de mtodos geis o aumento da eficincia das pessoas que trabalham juntas; a organizao e a nfase dada comunicao podem ser usadas como indicadores da agilidade das prticas de desenvolvimento de software. As reunies dirias em p e os workshops de reflexo do s pessoas a chance de manifestar suas preocupaes com relao ao grupo; os membros da equipe devem ter meios de expressar seus medos e desejos para a comunidade. Processos geis apoiam comunicao entre membros da equipe, como parte vital de qualquer projeto de desenvolvimento de software; quando um projeto dividido em partes, entender como as partes se acomodam vital na criao do produto; h mais integrao do que simples comunicao; colaborao o ingrediente fundamental para integrar rapidamente um grande projeto medida em que os incrementos so desenvolvidos em paralelo; ambiente altamente colaborativo, viabilizando a comunicao informal entre membros da equipe para disseminar informao. Pequeno nmero de equipes por projeto, necessrio para promover o ambiente colaborativo e por requerer menos planejamento para coordenar as
5, 8, 9
4, 5, 7
COPPE/UFRJ/PESC
Abrantes, Travassos
23
Testes constantes:
Equipes Locais:
atividades dos membros das equipes. Para prevenir a degradao da qualidade devido a entregas muito curtas, d-se alta nfase a testes do produto ao longo do ciclo de vida. Visa prevenir tambm contra a idia de apenas escrever cdigo. Mtodos geis requerem testes de integrao ao longo do processo de desenvolvimento. Automao dos testes importante para que as builds dirias passem por testes de regresso garantindo que todas as funcionalidades estejam operando corretamente. Algumas metodologias geis recomendam at mesmo testes de aceitao a cada entrega, ou mesmo em desenvolvimento concorrente. Para algumas metodologias significa trabalhar na mesma sala ou em salas adjacentes, o que s funciona para equipes de 8 a no mximo 14 pessoas Todas as metodologias so sensveis localizao da equipe, pois esto fortemente fundamentadas em canais de comunicao rpidos e ricos, que permitem reduzir a documentao externa a ser construida e mantida. A agilidade pode variar variando-se a qualidade dos canais de comunicao e o balano entre conhecimento externo e tcito. No significa que a equipe para ser gil no possa produzir documentos; executar um projeto entre paises diferentes e fusos horrios diferentes realmente um obstculo para as equipes serem geis.
Dentre os artigos ou documentos analisados, 11 apresentaram caracterizaes de agilidade para mtodos de desenvolvimento de software. Nestes artigos foram encontradas diversas caractersticas com significados similares, apesar de denominaes diferentes. Conforme a tabela 1, os 11 artigos so: 1- Abrahamsson, P.; Warsta, J.; Siponen, M.T. & Ronkainen, J. New directions on agile methods: a comparative analysis. IEEE Computer Society, 2003, 244-254
COPPE/UFRJ/PESC
Abrantes, Travassos
24
2- Boehm, B. & Turner, R. Balancing agility and discipline: A Guide for the Perplexed. Pearson Education Inc, Boston, MA. 2004a. 3- Meso, Peter. Jain, Radhika. Contemporary practices in systems development. Agile Software Development: adaptive systems principles and best practices. Information Systems Management, summer 2006. 4- Holmstrom, Helena. Fitzgerald, Brian. et al. Contemporary practices in systems development. Agile Practices Reduce Distance in Global Software Development. Information Systems Management, summer 2006. 5- Miller, Granville G. The Characteristics of Agile Software Processes. Proceedings of the 39th Intl Conf. and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS01), 2001. 6- Aoyama, Mikio. Agile Software Process and Its Experience. Proceedings of the 1998 International Conference on Software Engineering, p. 3-12, 1998 7- Coram, Michael. Bohner, Shawn. The Impact of Agile Methods on Software Project Management. Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS05), 2005 8- Hansson, C. Dittrich, Y. Gustafsson, B. Zarnak, S. How agile are industrial software development practices? The Journal of Systems and Software 79, 12951311, 2006 9- Cockburn, A. Agile Software Development Joins the Would be Crowd. Cutter IT Journal, v.15, n.2, 2002. 10- Abrahamsson, P. Salo, O. Ronkainen, J. Warsta, J. Agile Software Development Methods. Review and Analysis. Espoo. VTT Publications 478, 2002 11- Lindvall, M. Basili, V. et al. Empirical Findings in Agile Methods, In: Proceedings of Extreme Programming and Agile Methods SP/Agile Universe, pp. 197-207, 2002. Aps interpretao do significado descrito para cada ocorrncia de caracterstica, foram identificadas as similaridades e contadas s respectivas presenas nos documentos ou artigos includos na reviso sistemtica. As revises de cdigo consideradas por Coram e Bohner (2005) foram interpretadas mais como prtica do que caracterstica, razo pela qual foi excluida. A tabela 3 mostra a distribuio das 18 caractersticas encontradas, de acordo com a incidncia de presena em 9 artigos aps a excluso das similaridades e considerao dos clusters.
Tabela 3 Percentuais de incidncia das caractersticas nos artigos
Ord 1 2
COPPE/UFRJ/PESC
Caracterstica Adaptabilidade Incrementalidade
Quantidade de Artigos 5 5
Percentual 55,56% 55,56%

Abrantes, Travassos
25
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Iteratividade Colaboratividade Cooperatividade Orientao a Pessoas Parcimnia (Leanness) Restrio de Prazo Incorporao de Realimentao Modularidade Reflexo/Introspeco Auto-organizao Convergncia Emergncia Equipes Locais Equipes Pequenas Testes Constantes Transparncia
4 3 3 3 3 3 2 2 2 1 1 1 1 1 1 1
44,44% 33,33% 33,33% 33,33% 33,33% 33,33% 22,22% 22,22% 22,22% 11,11% 11,11% 11,11% 11,11% 11,11% 11,11% 11,11%
Para facilitar a visualizao, foi elaborado o grfico que se segue, a partir da tabela 3:
Grfico 1 Percentuais de incidncia das caractersticas nos artigos
Incidncia das Caractersticas nos Artigos
Percentuais de Incidncia
60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00%

Ad ap ta In bi cr em lida de en ta li Ite dad e ra Co t iv i la bo dad r e Co ativ O id op rie ad e nt e a r ati Pa vi o da rc d im n Pes e In ia so co as (L Re rp e or a stri ann es o o s) de de Re Pr az al im o en Re ta M o fle o x du l ar o/ id In ad t e Au ros pe to c -o o rg an iz Co a o nv er g Em nc ia er Eq g ui nc pe Eq ia s ui Lo pe ca Te s P e q is st ue es na Co s ns ta Tr nt an es sp ar n cia
Caractersticas
Como se pode observar, as caractersticas mais freqentes foram Adaptabilidade, Incrementalidade e Iteratividade, com 55,56 % de incidncia nos artigos para as duas primeiras e 44,44 % para a Iteratividade. Dentre estas, a adaptabilidade parece estar mais diretamente alinhada com um dos valores do Agile Manifesto (2001): Valorizar mais a resposta a mudanas do que seguir um plano.
26
As caractersticas com uma frequncia mdia de presena nos artigos foram Colaboratividade, Cooperatividade, Orientao Pessoas, Parcimnia e Restrio de Prazo. Dentre estas, parecem estar mais alinhadas com valores especificados no Agile Manifesto (2001): Cooperatividade associada com Valorizar mais a ao do cliente do que negociao de contratos. Orientao Pessoas associada com Valorizar mais indivduos e interaes do que processos e ferramentas. Parcimnia associada com Valorizar mais software funcionando do que documentao abrangente. A parcimnia foi um termo encontrado na literatura [Miller, 2001] e adotado nesta reviso para leanness. Segundo Conboy e Fitzgerald (2004) a idia de leanness a eliminao de perdas ou a habilidade de fazer mais com menos. As caractersticas menos frequentes nos artigos foram Incorporao de Realimentao (feedback), Modularidade, Reflexo/Introspeco, Auto-organizao, Convergncia, Emergncia, Equipes Locais, Equipes Pequenas, Testes Constantes e Transparncia. Dentre as 18 caractersticas identificadas, trs foram contempladas por 2 clusters ((incrementalidade, adaptabilidade e iteratividade), dez foram contempladas por apenas 1 cluster (cooperatividade, transparncia, auto-organizao, emergncia, modularidade, restrio de prazo, parcimnia, convergncia, orientao a pessoas e colaboratividade) e 5 no tm participao em qualquer cluster (reflexo e introspeco, realimentao (feedback) rpida, equipes pequenas e equipes locais). A tabela a seguir mostra a distribuio das caractersticas identificadas nos artigos, de acordo com os clusters a elas associados.
Tabela 4 - Distribuio das caractersticas identificadas nos artigos, por quantidade de clusters
Ord 1 2 3 4 5 6 7 8 9 10 11 12
Caracterstica Incrementalidade Adaptabilidade Iteratividade Colaboratividade Cooperatividade Orientao Pessoas Parcimnia (Leanness) Restrio de Prazo Modularidade Auto-organizao Convergncia Emergncia
Quantidade de Clusters 2 2 2 1 1 1 1 1 1 1 1 1
Quantidade de Artigos 5 5 4 3 3 3 3 3 2 1 1 1
Abrantes, Travassos
COPPE/UFRJ/PESC
27
13 14 15 16 17 18
Transparncia Incorporao de Realimentao Reflexo/Introspeco Equipes Locais Equipes Pequenas Testes Constantes
1 0 0 0 0 0
1 2 2 1 1 1
Para facilitar a visualizao, foi elaborado o grfico que se segue, a partir da tabela 4:
Grfico 2 Percentuais de incidncia das caractersticas nos clusters
Distribuio das Caractersticas por Quantidade de Clusters
Quantidade de Clusters
2,5 2 1,5 1 0,5 0

en ta lid ad e ab ilid ad Ite e ra t iv Co id ad la bo e ra tiv Co id ad op O e rie er at nt ivi a da o Pa de rc Pe im n ss oa ia (L s Re ea nn st ri es o s) de Pr az M o od ul ar Au id ad to -o e rg an iz Co o nv er g nc Em In ia co er rp g or Tr nc a an ia o sp de ar n Re cia Re al im fle en x ta o/ In o tro sp ec Eq ui o pe Eq s Lo ui pe ca is s Pe Te qu st en es as Co ns ta nt es Ad ap t
In cr em
Caractersticas
Observa-se que as caractersticas de Incrementalidade, Adaptabilidade e Iteratividade permanecem com maior destaque tambm quando se considera a quantidade de clusters associados s caractersticas identificadas nos artigos. J as caractersticas de Auto-organizao, Convergncia, Emergncia e Transparncia que estavam na faixa de baixa incidncia nos artigos, tiveram um cluster associado a cada uma delas. A tabela 5 abaixo d uma idia da distribuio das caractersticas abordadas nos artigos por faixa de ano de publicao.
COPPE/UFRJ/PESC
Abrantes, Travassos
28
Tabela 5 - Distribuio das caractersticas por faixa de ano de publicao dos artigos Ord 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Caracterstica Adaptabilidade Parcimnia (Leanness) Restrio de Prazo Incrementalidade Iteratividade Orientao Pessoas Colaboratividade Reflexo/Introspeco Cooperatividade Modularidade Incorporao de Realimentao Testes Constantes Equipes Pequenas Emergncia Auto-organizao Transparncia Equipes Locais Convergncia Faixa De 1998 1998 1998 1998 2001 2001 2001 2002 2003 1998 2006 2005 2005 2004 2004 2003 2002 2001 At 2006 2006 2005 2004 2006 2006 2006 2006 2006 2001 2006 2005 2005 2004 2004 2003 2002 2001 Amplitude 9 9 8 7 6 6 6 5 4 4 1 1 1 1 1 1 1 1 Quant. Artigos 5 3 3 5 4 3 3 2 3 2 2 1 1 1 1 1 1 1 Quant. por ano 0,56 0,33 0,38 0,71 0,67 0,50 0,50 0,40 0,75 0,50 2,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 2 em 2006 2 em 2006 Obs. 2 em 2006
Na tabela 5 pode-se observar que dentre as caractersticas abordadas com maior amplitude de tempo e com ndice de publicaes por ano acima de 0,50 artigos esto a adaptabilidade, a incrementalidade, a iteratividade e a cooperatividade. Tambm se podem observar na tabela, que algumas caractersticas foram preocupaes apenas pontuais por parte dos especialistas. O grfico que se segue foi elaborado a partir da tabela 5, oferecendo uma visualizao das caractersticas por amplitude de tempo de publicaes:
COPPE/UFRJ/PESC
Abrantes, Travassos
29
Grfico 3 Distribuio das Caractersticas por Amplitude de Tempo de Publicaes

Distribuio das Caractersticas por Amplitude de Tempo de Publicaes
Faixa de Tempo em Anos
10 9 8 7 6 5 4 3 2 1 0
Ad Pa ap rc ta im bi n lid ia ad (L e Re ea st nn ri es o s) de In Pr cr az em o en ta lid O ad Ite rie e ra nt t iv a id o ad e Pe Co ss la oa Re bo s fle ra x tiv o/ id In ad tro e sp Co ec op In co o er rp at or ivi a da M o de od ul de ar Re id ad al e im Te en st es ta Co o Eq ns ui ta pe nt s es Pe qu en Em as er Au g to nc -o ia rg an iz Tr a an o sp ar Eq n ui cia pe s Lo ca Co is nv er g nc ia
Caractersticas
Observa-se tambm, que com exceo do artigo publicado por Aoyama (1998) todos os demais foram publicados a partir da declarao do Agile Manifesto (2001).
6- Proposta de Caracterizao Bsica para Mtodos geis

Os mtodos geis tm como marco principal a publicao do Agile Manifesto (2001) e procuram colocar mais nfase nas pessoas e interaes, software funcionando, colaborao do cliente e acomodao das mudanas, ao invs de focar mais nos processos, ferramentas, contratos e planos. Todas as caractersticas de mtodos geis elencadas nesta reviso podem ser desejveis em ambientes especficos de desenvolvimento de software, no sentido de que podem trazer benefcios quanto ao melhor desempenho do processo. No seria adequado afirmar que um determinado mtodo para ser considerado gil tenha, necessariamente, que conter integralmente todas as caractersticas apresentadas. Algumas das caractersticas levantadas podem estar presentes em determinado mtodo com grau de intensidade maior ou menor, ou at mesmo algumas delas no estarem presentes, dependendo de fatores circunstanciais, sem comprometer a agilidade. O foco para avaliao tem que ser o resultado final alcanado, no sentido de satisfazer necessidades do cliente, dentro do oramento, dentro dos prazos e com a qualidade esperada. Alm disso, no necessariamente as diversas instncias possveis de mtodos geis tm o mesmo grau de agilidade. Uma idia alternativa para configurar o mtodo com o nvel ou grau de agilidade desejado, a adoo de prticas. As prticas adotadas podem ser ajustadas de modo a alcanar a intensidade desejada e adequada para cada caracterstica que deve estar presente no mtodo gil. Desse modo, poder-se-ia tentar embutir nele, com alguma intensidade, algumas ou todas as caractersticas dos mtodos geis. Mtodos tradicionais ou orientados a plano podem ser customizados com uma dosagem de algumas prticas para alcanar o nvel de agilidade necessrio. Segundo Patel et al (2006) a tendncia de adaptao/customizao dos processos de desenvolvimento de software por parte das organizaes desenvolvedoras est em crescimento, enquanto
30
decresce a quantidade de organizaes que seguem um processo comercial de modo prescritivo. Os fatores que podem influenciar a escolha das prticas e seus respectivos ajustes, para serem inseridas no processo de software e alcanar a agilidade necessria para o mtodo de desenvolvimento devem contemplar aspectos como natureza do projeto, ambiente de desenvolvimento, cultura da organizao. Para se alcanar a agilidade de mtodos de desenvolvimento de software, algumas caractersticas podem ser consideradas fundamentais. Dentro do contexto apresentado, a caracterstica fundamental e mais aderente aos valores do Manifesto gil parece ser a adaptabilidade. Em seguida, e considerando um aspecto mais pragmtico, seguem as caractersticas de incrementalidade e iteratividade que devem caminhar juntas. A essas caractersticas devem se somar outras trs que esto diretamente associadas uma idia central dos mtodos geis que o foco nas pessoas que conduzem as atividades dos processos. So elas: colaboratividade, cooperatividade (estas duas caractersticas s vezes so confundidas uma com a outra na literatura) e orientao a pessoas. Deve-se acrescentar ainda, duas caractersticas que alm de necessrias para o sucesso de um mtodo gil, so fundamentais em qualquer processo produtivo inserido em uma economia global e um mercado cada vez mais competitivo. So elas: parcimnia (leanness) e restrio de prazo. Convm observar que as entregas devem ser feitas com rapidez, mas tm que agregar valor para o cliente, atravs de resultados prticos ou efetivos, no devendo ser confundidas com a prtica de prototipao. As caractersticas de colaboratividade e cooperatividade s vezes so confundidas uma com a outra na literatura, dependendo da interpretao que se faa para o seu significado. Contudo, nesta quasi-reviso sistemtica no foi feita a mescla destas duas caractersticas, tentando respeitar as idias dos autores, alm de no se ter encontrado indicativos que permitissem fazer tal mescla de forma segura. A diferena entre as duas sutil e no est destacada nos textos dos artigos recuperados. A idia da cooperao parece ter ligao mais direta com a interao do cliente com o grupo desenvolvedor e est associada ao papel da realimentao (feedback) constante [Abrahamsson et al, 2003; Meso e Radhika, 2006; Hansson et al, 2006]. J a idia de colaboratividade parece estar associada com a interao entre os membros do grupo desenvolvedor e relacionada com a integrao contnua de novos incrementos de software, com funcionalidades modificadas ou novas [Holmstrom et al, 2006; Miller, 2001; Coram e Bohner, 2005; Miller, 2003]. As demais caractersticas elencadas nesta quasi-reviso sistemtica so tambm importantes para o sucesso de um mtodo gil. Contudo, pode-se consider-las como decorrentes ou subsidirias daquelas acima citadas como fundamentais. Abrahamsson, Salo, Ronkainen e Warsta (2002) consideram que um mtodo agil se ele apresenta 4 caractersticas: incrementalidade, cooperatividade, transparncia ou clareza e adaptabilidade. Para eles, o pensamento gil uma viso centrada nas pessoas para desenvolver software. Para Highsmith (2002) as pessoas, com seus conhecimentos, habilidades, experincias, peculiaridades e personalidades so o principal fator ou impacto de primeira grandeza no sucesso de um projeto de software.
COPPE/UFRJ/PESC
Abrantes, Travassos
31
Nossa proposta para qualificar um mtodo ou processo de desenvolvimento de software como sendo gil, apresentada assim: um mtodo para ser dito gil, deve apresentar, em um grau adequado ao contexto de desenvolvimento em que ele se insere, no mnimo as seguintes caractersticas: adaptabilidade, incrementalidade, iteratividade, colaboratividade, cooperatividade, orientao a pessoas, parcimnia (leanness) e restrio de prazo. Uma grande questo que fica : como medir a intensidade ou grau de adequao destas caractersticas a um determinado contexto de desenvolvimento de software?
7- Concluses
A caracterizao de agilidade em mtodos geis, de maneira geral, e no em um ou mais mtodos especficos, importante para o melhor entendimento de outras questes ligadas ao desenvolvimento gil. A avaliao do grau em que os mtodos geis existentes atendem aos princpios declarados no manifesto gil pode ajudar a entender os resultados da aplicao de certos mtodos em projetos de desenvolvimento de software. Para Favaro (2002) a iteratividade considerada o denominador comum dos mtodos geis. Glass (2004) destaca a necessidade de pesquisas que proponham uma taxonomia para as metodologias geis disponveis, baseada em seus pontos fortes e em seus pontos fracos; uma segunda taxonomia, para o espectro de domnios de problemas, baseada em suas necessidades; e um mapeamento entre as duas taxonomias baseado no entendimento do que as metodologias oferecem e do que os domnios necessitam. A anlise do significado ou definio de agilidade a partir do seu relacionamento com flexibilidade e leanness (parcimnia) pode apoiar o entendimento dos mtodos geis. Explorar a natureza e evoluo destes conceitos em outras reas (manufatura, finanas, gerncia, trabalho, marketing, eletrnica) pode ajudar no esclarecimento do significado de agilidade dos mtodos de desenvolvimento de software. Para Lou et al (2004) agilidade tem dois significados na indstria manufatureira moderna: flexibilidade e reconfigurabilidade. Flexibilidade seria a habilidade da organizao para fazer ajustes de acordo com a necessidade dos clientes; reconfigurabilidade seria a habilidade da organizao para atender demandas por mudanas. A habilidade para responder a mudanas de mercado tem sido reconhecida com um elemento chave para o sucesso e a sobrevivncia das organizaes. Conboy e Fitzgerald (2004), aps analisar os conceitos de flexibilidade e parcimnia (leanness) associados agilidade, propem o seguinte conceito: agilidade a contnua prontido de um mtodo ou processo gil, para rapidamente ou inerentemente, proativamente ou reativamente, abraar a mudana, atravs de componentes econmicos, simples e de alta qualidade e atravs de relacionamentos com seu ambiente. Segundo os mesmos autores, a parcimnia (leanness) pressupe a eliminao de todas as perdas em um processo, enquanto que a agilidade requer sim a eliminao de perdas, mas s at o limite que no comprometa a habilidade de pronta resposta a mudanas. O alinhamento da filosofia dos mtodos geis com os objetivos do desenvolvimento de software global (GSD Global Software Development), para
32
resolver questes incidentes nesse ambiente de desenvolvimento pode ser pesquisado, como sugere Holmstrom et al (2006), sendo esta uma idia interessante. Esse alinhamento pode ter uma associao direta com as caractersticas de Equipes Locais e Equipes Pequenas. A busca de um caminho para descobrir associaes entre caractersticas de mtodos geis de desenvolvimento de software e caractersticas de projetos de desenvolvimento de software, para determinar se mtodos geis so indicados para os projetos, ainda permanece sem uma resposta satisfatria. A customizao de mtodos de desenvolvimento de software, identificando e selecionando as prticas mais adequadas para um dado ambiente ou projeto de desenvolvimento, obtendo uma mescla equilibrada de prticas dos mtodos dirigidos a planos, com prticas dos mtodos geis, parece ainda carecer de mais trabalhos de pesquisa. Segundo Chau et al (2002) a criao e compartilhamento de conhecimento so partes essenciais de processos de software, quer sejam tradicionais ou geis Vinekar, Slinkman e Nerur (2006) declaram que h evidncias que parecem indicar que as organizaes de desenvolvimento de software esto tentando utilizar ambas as abordagens de desenvolvimento de software, a tradicional e a gil. Para Nawrocki et al (2006) a maioria dos projetos de software contemporneos requerem um equilbrio de agilidade e disciplina. Como chegar a esse equilbrio uma questo que ainda precisa de mais pesquisas, apesar das propostas j existentes feitas por alguns especialistas, dentre eles Boehm e Turner (2004a). H ainda que se considerar que os trabalhos de pesquisa podem tomar outros rumos, no necessariamente em alto nvel de abstrao, podendo se voltar a aspectos mais especficos ligados s atividades dos processos geis, como testes geis em projetos de software. Recentemente, as equipes de desenvolvimento de software que utilizam processos geis comearam a adotar largamente o desenvolvimento dirigido a testes Test-Driven Development [Crispin, 2006]. As caractersticas relacionadas com testes no tiveram muita incidncia nas abordagens feitas nos diversos artigos. Contudo, conforme Lindvall et al (2002) enfatizam, os testes so uma questo fundamental em mtodos geis, fortalecendo a idia da necessidade de pesquisas nesta direo. Segundo Barnett (2004) o desenvolvimento Open Source adota prticas de planejamento e de engenharia que j provaram ser escalveis, e que tais prticas so tambm adotadas pelo desenvolvimento gil: releases freqentes e mais cedo; representao do cliente no projeto; implementao de TDD Test Driven Development. Este assunto tambm merecedor de um pouco mais de pesquisa. Alguns trabalhos futuros podem se tornar interessantes dentro do contexto de mtodos geis. Dentre eles: 1- Buscar o entendimento das caractersticas de cada mtodo gil em particular, para identificar o quanto aderente cada um est em relao s caractersticas elencadas nesta quasi-reviso sistemtica. 2- Qual ou quais caractersticas esto mais presentes nas metodologias geis propostas na literatura e com que intensidade.
COPPE/UFRJ/PESC
Abrantes, Travassos
33
3- Qual o significado ou a importncia da prtica de TDD (Test-Driven Developement) na agilidade das metodologias? Para que caractersticas dos mtodos geis TDD contribui, no sentido de tornar o mtodo mais gil? 4- Procurar mtricas para apoiar o estabelecimento e a avaliao do grau de intensidade da agilidade? (possivelmente presena de prticas associadas s diversas caractersticas, aplicadas em nveis de intensidade diferentes) 5- Ampliar conhecimento sobre questes como ambientes de desenvolvimento com equipes grandes ou GSD Global Software Development. Estariam tais ambientes impedidos de serem geis devido suas maiores dificuldades em atender as caractersticas Equipes Pequenas e Equipes Locais?
8- Referncias Bibliogrficas
Abrahamsson, P. Salo, O. Ronkainen, J. Warsta, J. (2002) Agile Software Development Methods. Review and Analysis, Espoo. VTT Publications 478. Abrahamsson, P.; Warsta, J.; Siponen, M.T. & Ronkainen, J. (2003) New directions on agile methods: a comparative analysis, IEEE Computer Society, 244-254 Agile Manifesto. (2001) Disponvel em http://agilemanifesto.org. Acessado em 23 de Agosto de 2006. Aoyama, Mikio. (1998) Agile Software Process and Its Experience, Proceedings of the 1998 International Conference on Software Engineering, p. 3-12. Barnett, L. (2004) Applying Open Source Processes In Corportate Development Organizations, Forrester Best Practices, may 20. Boehm, B. (2002) Get ready for agile methods, with care, Computer, Institute of Electrical and Electronics Engineers Computer Society, 35, 64-69. Boehm, B. & Turner. R. (2003) Observations on balancing discipline and agility, Proceedings of the Agile Development Conference. Boehm, B. & Turner, R. (2004) Balancing agility and discipline: Evaluating and integrating agile and plan-driven methods, Institute of Electrical and Electronics Engineers Computer Society, Piscataway, NJ 08855-1331, United States, 26, 718719. Boehm, B. & Turner, R. (2004a) Balancing agility and discipline: A Guide for the Perplexed, Pearson Education Inc, Boston, MA. Chau, T. Maurer, F. Melnik, G. (2002) Knowledge Sharing: Agile Methods vs. Tayloristic Methods, Department of Computer Science, University of Calgary Calgary, Canada. Cockburn, A. (2002) Agile Software Development Joins the Would be Crowd, Cutter IT Journal, v.15, n.2. Conboy, K. & Fitzgerald, B. (2004) Toward a conceptual framework of agile methods: A study of agility in different disciplines, Association for Computing Machinery, New York, NY 10036-5701, United States, 37-44. Coram, Michael. Bohner, Shawn. (2005) The Impact of Agile Methods on Software Project Management, Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS05).
34
Crispin, L. (2006) Driving Software Quality: How Test-Driven Development Impacts Software Quality, Ieee Software. Favaro, J. Managing Requirements for Business Value. IEEE Software, v19, 15-17, 2002. Fowler, M. Highsmith, J. (2001) The Agile Manifesto, Software Development, v.9 n.8, aug. Glass, R.L. (2004) Matching methodology to problem domain, Communications of the ACM, Association for Computing Machinery, New York, United States, 47, 1921. Hansson, C. Dittrich, Y. Gustafsson, B. Zarnak, S. (2006) How agile are industrial software development practices?, The Journal of Systems and Software 79, 1295 1311. Hazzan, O. Dubinsky, Y. (2006) Can Diversity in Global Software Development be Enhanced by Agile Software Development?, ACM Digital Library. Holanda, A. B. (1977) Dicionrio Aurlio da Lngua Portuguesa, Editora Nova Fronteira. Highsmith, J. (2002) Agile Software Development Ecosystems, Addison Wesley. Holmstrom, Helena. Fitzgerald, Brian. et al. (2006) Contemporary practices in systems development. Agile Practices Reduce Distance in Global Software Development, Information Systems Management, summer. Lello Popular. (1958) Novo Dicionrio Ilustrado da Lngua Portuguesa, Lello e Irmo Ed. Porto, Portugal. Lindvall, M. Basili, V. et al. (2002) Empirical Findings in Agile Methods, In: Proceedings of Extreme Programming and Agile Methods SP/Agile Universe, pp. 197-207. Longman Group. (1992) Dictionary of Contemporary English New Edition, Longman House, Burnt Mill, Harlow, UK. Lou, Ping. Zhou, Zu-de. et al. (2004) Study on multi-agent-based agile supply chain management, International Journal Adv Manufacturing Tachnology, v.23:197-203. Meso, Peter. Jain, Radhika. (2006) Contemporary practices in systems development. Agile Software Development: adaptive systems principles and best practices, Information Systems Management, summer. Miller, Granville G. (2001) The Characteristics of Agile Software Processes, Proceedings of the 39th Intl Conf. and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS01). Nawrocki, J.; Olek, L.; Jasinski, M.; Paliswiat, B.; Walter, B.; Pietrzak, B. & Godek, P. (2006) Balancing agility and discipline with Xprince, Springer Verlag, Heidelberg, D-69121, Germany, 3943 NCS, 266-277. Pai, M. McCulloch, M. Gorman, J.D. et al. (2004) Systematic Reviews and metaanalyses: An illustrated, step-by-step guide, The National Medical Journal of India, vol. 17, n.2.
35
Patel, C. Lycett, M. et al. (2006) Perceptions of Agility and Collaboration in Software Development Practice, Proceedings of the 39th Hawaii International Conference on System Sciences. Rajlich, V. (2006) Changing the Paradigm of Software Engineering, Communications of the ACM, v.49, n.8, aug. Sugden, R.C. Strens, M.R. (1996) Strategies, tatics and methods for handling change, Engineering of Computer-Based Systems Proceedings of IEEE Symposium and Workshop, mar. Taylor, P.S. Greer, D. Sage, P. et all. (2006) Do Agile GSD Experience Reports Help the Practitioner?, ACM Digital Library. Vinekar, V. Slinkman, C.W. Nerur, S. (2006) Contemporary practices in systems development. Can Agile and Traditional Systems Development Approaches Coexist? An Ambidextrous View, Information Systems Management, summer.
COPPE/UFRJ/PESC
Abrantes, Travassos
36

RT Agile Methods

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

RT Agile Methods

Enviado por

Direitos autorais:

Formatos disponíveis

RELATRIO TCNICO

Reviso quasi-Sistemtica da Literatura: Caracterizao de Mtodos geis de Desenvolvimento de Software

Jos Fortuna Abrantes Guilherme Horta Travassos

PESC Programa de Engenharia de Sistemas e Computao COPPE / UFRJ

Rio de Janeiro, dezembro de 2007

Reviso quasi-Sistemtica da Literatura: Caracterizao de Mtodos geis de Desenvolvimento de Software

3- Protocolo de Reviso Sistemtica de Literatura

248 201 118 9 15 591

ACM digital library TOTAL

Tabela 1 Documentos descrevendo caractersticas de mtodos geis

Documento Representativo do Cluster (ord. na tab. 1)

Ordem na Tab. 1 1,2, 5, 6, 9

Caracterstica Adaptabilidade Incrementalidade

Percentual 55,56% 55,56%

60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00%

2,5 2 1,5 1 0,5 0

Grfico 3 Distribuio das Caractersticas por Amplitude de Tempo de Publicaes

Faixa de Tempo em Anos

6- Proposta de Caracterizao Bsica para Mtodos geis

Você também pode gostar