Avaliação de Características de Agilidade e Práticas Ágeis para Processos de Software

José Fortuna Abrantes, Guilherme Horta Travassos

COPPE/SistemasUniversidade Federal do Rio de Janeiro

Rio de Janeiro, Brasil{jfa, ght}@cos.ufrj.br

Abstract. Context: It is believed that agility in software process can bring bene-fits to software development and lead to economy of efforts when accommodate changes is needed. Objective: Assess pertinence and relevance of agility charac-teristics and agile practices for software processes. Method: From 18 agility characteristics and 17 agile practices applicable to software processes revealed through systematic literature reviews performed in 2010, a survey was con-ducted to assess their pertinence and relevance. Results: 16 agility characteris-tics and 15 agile practices were considered pertinent to insert agility in software processes. Conclusion: Results should be used sparingly. It would be interesting to replicate the study in other contexts, with different subjects, and compare them, to increase the generalization of their results.

Keywords: Agility in software processes, characteristics of agility, survey, evi-dence based software engineering, agile practices, agile software development, agile methods.

1 Introdução

Pode-se observar nas últimas décadas a necessidade de que processos de software sejam passíveis de adaptação a modificações de última hora ou a modificações não previstas, especialmente nos requisitos, para atender necessidades específicas dos negócios em um mercado cada dia mais dinâmico, competitivo e se abrindo a novas possibilidades. O mais significativo desafio para as organizações do século XXI será sua habilidade de adaptação a mudanças rápidas e imprevisíveis, de modo mais apro-priado e mais rápido do que seus competidores [1]. A morosidade para acomodar incertezas e mudanças rápidas leva inevitavelmente à obsolescência do software e à insatisfação do cliente [2]. Mudanças constantes, especialmente nos requisitos e no ambiente dos negócios, se transformam em dificuldades quando processos de softwa-re mais rígidos são aplicados.

Algumas atividades de processos de software (p.ex. atividades de teste) estão entre as mais onerosas do conjunto de atividades que fazem parte do desenvolvimento de software [3]. Mudanças em requisitos podem tornar obsoletos ou desatualizados arte-fatos planejados, projetados e já especificados ou até mesmo já executados e com seus

resultados analisados. É desejável que os processos de software apresentem agilidade suficiente para acomodar mudanças inevitáveis e não previstas. Ao mesmo tempo, espera-se que estes processos possam ser descritos, monitorados e melhorados [4].

Uma das mais importantes inovações nas abordagens de desenvolvimento de soft-ware dos últimos anos tem sido a introdução dos princípios ágeis [5]. Contudo, apesar de uma série de métodos ágeis terem sido propostos, pouco se sabe sobre a forma como estes métodos são utilizados na prática e quais são seus efeitos sobre os proces-sos de software [6]. Assim, algumas preocupações vêm à tona quando se pensa em definir processos de software suscetíveis a mudanças: como embutir agilidade em um processo de software? Quais são as características desejáveis em um processo de software para que ele possa ser considerado ágil? Estas questões, embora aparente-mente simples e até onde vai nosso conhecimento, ainda não possuem respostas ade-quadas descritas na literatura técnica.

Segundo [7], as abordagens de desenvolvimento ágil envolvem a adoção de um conjunto de práticas que se apóiam mutuamente. Uma alternativa de solução para se embutir características de agilidade em processos de software pode se apoiar, portan-to, na adoção de práticas ágeis. Assim, explorar esta alternativa implica em responder as questões seguintes: (1) quais características de agilidade são pertinentes e devem ou podem ser candidatas a serem inseridas em um processo de software com a finali-dade de torná-lo ágil? (2) quais práticas ágeis de software são pertinentes e podem ser consideradas para serem adotadas em processos de software com o objetivo de se tentar embutir características de agilidade no processo? Apesar do entendimento de que uma prática isoladamente talvez não possa trazer um grau de agilidade adequado para um processo de software, faz-se necessário considerar a pertinência de cada uma delas isoladamente, para apoiar a formação de um conjunto adequado de práticas ágeis que possam fazer com que um processo de software tenha o grau de agilidade desejado para um projeto de software específico.

Buscando responder a estas questões, foram executadas revisões sistemáticas de li-teratura [8,9] que identificaram características de agilidade (Adaptabilidade, Auto-organização, Convergência, Emergência, Equipes Locais, Equipes Pequenas, Incorpo-ração de Realimentação (feedback), Leanness (parcimônia), Modularidade, Orienta-ção a Pessoas, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Ser In-cremental, Ser Iterativo, Testes Constantes, Time-Boxing e Transparência) a serem esperadas em processos de software, bem como práticas ágeis (Backlog de produto, Cliente presente, Desenvolvimento orientado a testes, Design simples, Equipe com-pleta, Espaço de trabalho aberto, Integração contínua, Jogo de planejamento, Metáfo-ra, Padrões de código, Programação em par, Propriedade coletiva do código, Refato-ração, Releases curtas, Reuniões diárias, Ritmo sustentável, Visibilidade de projeto)que poderiam ser adotadas nos processos para embutir as características de agilidadedesejadas. Entretanto, as indicações resultantes destes estudos secundários não ofere-ciam nível de confiança aceitável, já que representavam a síntese realizada pelos pes-quisadores. Visando aumentar a confiança nestes resultados, estas características de agilidade e práticas ágeis tornaram-se objeto de estudo em uma pesquisa de opinião para avaliar a pertinência e o nível de relevância de cada uma delas no contexto de agilidade em processos de software. O principal objetivo deste artigo é descrever os

resultados desta pesquisa de opinião, estando estruturado da seguinte forma: na seção 2 é apresentada a metodologia e o planejamento da pesquisa de opinião. Na seção 3são apresentados e discutidos os resultados alcançados com a execução do estudo. Na seção 4 as ameaças à validade do estudo são apresentadas. Na seção 5 são feitas as considerações finais e comentadas as possibilidades para trabalhos futuros.

2 Planejamento do Estudo

O objeto de estudo inclui os dois conjuntos iniciais, um de características de agilidade identificadas em uma revisão sistemática de literatura [8] para apoiar a inserção de agilidade em processos de software, e outro, de práticas ágeis de software identifica-das em outra revisão sistemática de literatura [9], ambas realizadas em 2010.

Utilizando a abordagem GQM [12], o objetivo do estudo é Analisar o conjunto de características de agilidade, Com o propósito de caracterizar, Com respeito a sua per-tinência e relevância para caracterizar um processo de software como sendo ágil, bem como sua correspondente relevância em relação àquela caracterização, Do ponto de vista de pesquisadores em processos ágeis de software, No contexto de projetos de software que adotam abordagens ágeis de desenvolvimento. E também Analisar o conjunto de práticas ágeis de software, Com o propósito de caracterizar, Com respeito a sua pertinência e relevância relacionada com a obtenção de agilidade em processosde software, Do ponto de vista de pesquisadores em processos ágeis de software, No contexto de projetos de software adotando abordagens ágeis de desenvolvimento.

As questões de pesquisa e respectivas métricas consideradas são: Q1: as caracterís-ticas de agilidade extraídas da literatura técnica são pertinentes para caracterizar um processo de software como sendo ágil? M1: o número de características de agilidade classificadas como pertinentes para caracterizar um processo ágil de software, de acor-do com a opinião dos participantes do estudo. Q2: Existe alguma característica de agi-lidade adicional que seja pertinente para caracterizar um processo ágil de software que não está presente no conjunto inicial? M2: o número de características de agilidade adicionais para serem incluídas no conjunto inicial, de acordo com a opinião dos parti-cipantes do estudo. Q3: Existe alguma característica de agilidade presente no conjunto inicial que não é pertinente para caracterizar um processo ágil de software? M3: núme-ro de características de agilidade a serem removidas do conjunto inicial, de acordo com a opinião dos participantes do estudo. Q4: Qual é a ordem de relevância das caracterís-ticas de agilidade no conjunto final de características de agilidade quando se considera uma abordagem ágil para processos de software a serem aplicados em um projeto de software? M4: a ordem em um conjunto de características de agilidade ordenado por nível de relevância. Q5: Serão as práticas ágeis de software extraídas da literatura téc-nica, pertinentes com relação às abordagens ágeis para processos de software? M5: número de práticas ágeis de software classificadas como pertinentes com relação a abordagens ágeis para processos de software, de acordo com a opinião dos participan-tes do estudo. Q6: Existe alguma prática ágil de software adicional que seja pertinente com relação às abordagens ágeis de software que não está presente no conjunto inicial? M6: número de práticas ágeis de software adicionais a serem incluídas no conjunto inicial, de acordo com a opinião dos participantes do estudo. Q7: Existe alguma prática ágil de software presente no conjunto inicial de práticas ágeis de software que não é pertinente com relação às abordagens ágeis para processos de software? M7: número

de práticas ágeis de software a serem removidas do conjunto inicial de acordo com a opinião dos participantes do estudo. Q8: Qual é a ordem de relevância das práticas ágeis de software no conjunto final de práticas quando se considera sua adoção em um processo ágil de software? M8: a ordem de cada prática no conjunto de práticas ágeis ordenado por nível de relevância.

No planejamento do estudo foram consideradas algumas hipóteses: Hipótese Nula 1 (H0 1): o conjunto inicial de características de agilidade está com-

pleto, isto é, todas as características de agilidade presentes no conjunto inicial são per-tinentes para a caracterização de agilidade em processos de software, e nenhuma carac-terística deve ser incluída nem removida. Sendo Cr – características classificadas como não pertinentes e que precisam ser removidas do conjunto inicial; Ci – características não presentes no conjunto inicial e classificadas como pertinentes, que precisam ser incluídas no conjunto inicial de características de agilidade; (H0 1: |Cr| = |Ci| = 0).Hipótese Alternativa (H1): existem características no conjunto inicial de características de agilidade que foram classificadas como não pertinentes para a caracterização de agilidade em processos de software. Portanto, elas precisam ser removidas do conjunto inicial de características de agilidade (H1: |Cr| ≠ 0). Hipótese Alternativa (H2): existemcaracterísticas não presentes no conjunto inicial de características de agilidade que foram classificadas como pertinentes para a caracterização de agilidade em processos de software. Portanto, elas precisam ser incluídas do conjunto inicial de características de agilidade (H2: |Ci| ≠ 0).

Hipótese Nula 2 (H0 2): todas as características de agilidade têm o mesmo nível de relevância para apoiar a inserção de agilidade em processos de software. Sendo CRLi –nível de relevância relacionado com a caracterização de agilidade em processos de software para a característica “i”, onde i é um número entre 1 e n, e sendo n o total de características de agilidade que foi considerado pertinente (H0 2: CRL1 = CRL2 = … = CRLn). Hipótese Alternativa (H3): existe pelo menos uma característica de agilidade com nível de relevância diferente das demais características de agilidade relacionadas com a caracterização de agilidade em processos de software (H3: i,j | CRLi ≠ CRLj, onde “i” and “j” são números entre 1 e n, e “i ≠ j”).

Hipótese Nula 3 (H0 3): o conjunto inicial de práticas ágeis de software está com-pleto, isto é, todas as práticas presentes no conjunto inicial são pertinentes com relação a abordagens ágeis para processos de software, e nenhuma prática deve ser incluída nem excluída. Sendo Pc – conjunto inicial de práticas ágeis de software; Pr – práticas classificadas como não pertinentes que precisam ser removidas do conjunto inicial; Pi – práticas não presentes no conjunto inicial, classificadas como pertinentes e que preci-sam ser incluídas no conjunto inicial de práticas ágeis de software (H0 3: |Pr| = |Pi| = 0). Hipótese Alternativa (H4): existem práticas no conjunto inicial de práticas ágeis de software que foram classificadas como não pertinentes com relação às abordagens ágeis para processos de software. Portanto, elas precisam ser removidas do conjunto inicial de práticas ágeis (H4: |Pr| ≠ 0). Hipótese Alternativa (H5): existem práticas não presentes no conjunto inicial de práticas ágeis de software que foram classificadas como pertinentes com relação às abordagens ágeis para processos de software. Portan-to, elas precisam ser incluídas do conjunto inicial de práticas ágeis (H5: |Pi| ≠ 0).

Hipótese Nula 4 (H0 4): todas as práticas ágeis de software têm o mesmo nível de relevância com relação às abordagens ágeis para processos de software. Sendo PRLi –nível de relevância relacionado com as abordagens ágeis para processos de software para a prática “i”, onde i é um número entre 1 e m e sendo m o total de práticas ágeis que foi considerado pertinente (H0 4: PRL1 = PRL2 = … = PRLm). Hipótese Alterna-tiva (H6): há pelo menos uma prática ágil de software com nível de relevância diferen-

te das demais práticas ágeis relacionadas com abordagens ágeis para processos de software (H6: i,j | PRLi ≠ PRLj, onde “i” and “j” são números entre 1 e m, e “i ≠ j”).

Os questionários da pesquisa de opinião foram preenchidos por pesquisadores queindicaram quatro opiniões:

primeiro, se as características apresentadas podem ser consideradas pertinentes ou não para caracterizar um processo de software como sendo ágil, e se é necessário incluir novas características de agilidade juntamente com seu significado, ou excluir alguma característica do conjunto inicial.

Segundo, depois da definição do conjunto final de características de agilidade per-tinentes, deseja-se definir o nível de relevância de cada característica para apoiar a caracterização de um processo de software como sendo ágil, de acordo com a opinião dos participantes. Quatro níveis de relevância foram definidos: (0) Não relevante (sem relevância). É o mais baixo grau de relevância - a característica não tem qualquer influência na caracterização de um processo de software como sendo ágil. A agilidade não seria afetada se a referida característica estiver ausente do processo de software, independentemente de cenários particulares ou de ambientes de desenvolvimento. (1) Pouco relevante (insignificante) - a característica não afeta significativamente ou tem uma pequena influência na caracterização de um processo de software como sendo ágil. A ausência da característica não compromete seriamente a agilidade de um pro-cesso de software em todos ou na maioria dos cenários ou ambientes de desenvolvi-mento. (2) Altamente relevante (muito relevante) - a característica tem forte ou consi-derável influência na caracterização de um processo de software como sendo ágil. A ausência da característica compromete a agilidade de um processo de software em todos ou na maioria dos cenários ou ambientes de desenvolvimento. (3) Absolutamen-te relevante - a característica é vital ou imperativa na caracterização de um processo de software com sendo ágil. A ausência da característica impede a caracterização de um processo de software como um processo ágil.

Terceiro, se as práticas ágeis apresentadas podem ser consideradas pertinentes ou não em abordagens ágeis para processos de software, e se é necessário incluir ou ex-cluir alguma prática do conjunto inicial de práticas ágeis de software.

Quarto, depois da definição do conjunto final de práticas ágeis pertinentes, é dese-jado definir o nível de relevância de cada prática na adoção de abordagens ágeis para processos de software, de acordo com a opinião pessoal dos participantes do estudo. Para isso, quatro níveis de relevância foram definidos: (0) Não relevante (sem rele-vância). É o mais baixo grau de relevância e significa que a prática não tem qualquer influência na adoção de uma abordagem ágil. A abordagem ágil de um processo de software não é afetada se a referida prática estiver ausente do processo de software, independentemente de cenários particulares ou de ambientes de desenvolvimento. (1) Pouco relevante (insignificante) - a prática não afeta significativamente ou tem uma pequena influência na adoção de uma abordagem ágil para um processo de software. A ausência da prática não irá comprometer seriamente a abordagem ágil para um processo de software em todos ou na maioria dos cenários ou ambientes de desenvol-vimento. (2) Altamente relevante (muito relevante) - a prática tem forte ou considerá-vel influência na adoção de uma abordagem ágil. A ausência da prática compromete a abordagem ágil para um processo de software em todos ou na maioria dos cenários ou

ambientes de desenvolvimento. (3) Absolutamente relevante - a prática é vital ou imperativa para a adoção de uma abordagem ágil. A ausência da prática impede a adoção da abordagem ágil para um processo de software.

O questionário foi disponibilizado na internet, dividido em cinco partes: caracteri-zação do participante; identificação das características de agilidade; definição do nível de relevância das características de agilidade; identificação das práticas ágeis pertinen-tes para abordagem ágil de processo de software; definição do nível de relevância das práticas ágeis de software. Para diferenciar as respostas dos participantes, foi atribuído um peso para cada participante de acordo com quatro perspectivas: formação acadêmi-ca, número de artigos publicados sobre processos ágeis, nível de experiência com o uso de abordagens ágeis em projetos de software, número total de projetos de software utilizando processos ágeis nos quais participou. A fórmula utilizada para definir o peso do participante foi adaptada de [10]:

MedianaTP

itieipifiS

)()()()()(

S(i) é o peso atribuído ao participante i f(i) é a formação acadêmica. As opções para esta variável são: 0, para graduação;

1, para especialização; 2, para mestrado; 3, para doutorado; p(i) é o indicador sobre o número de artigos relacionados com processos ágeis ou

com métodos ágeis publicados pelo participante. As opções para esta variável são:0, entre 1 e 2 artigos; 1, entre 3 e 4 artigos; 2, entre 5 e 6 artigos; 3, mais do que 6artigos;

e(i) é o nível de experiência do participante com relação ou uso de abordagens ágeis em projetos de software. As opções para esta variável são: 0, nível de experi-ência baixo; 1, nível de experiência médio; 2, nível de experiência alto; 3 nível de experiência muito alto;

t(i) é o número estimado de projetos de software utilizando abordagens ágeis dos quais ele/ela participou.

Mediana TP é a mediana do número total de projetos de software utilizando abor-dagens ágeis, considerando as respostas de todos os participantes.

A faixa de valores para o indicador p(i) foi definida após a análise de uma amostra de autores extraídos dos artigos que contribuíram com pelo menos uma característica de agilidade na primeira execução do protocolo da revisão sistemática [8]. Foi utiliza-da uma população de artigos cujas referências estavam registradas no gerenciador de referências, totalizando 897 referências (não incluídas as referências recuperadas pela máquina de busca da ACM Digital Library). Dentre tais referências, foram recupera-dos todos os artigos sobre abordagens ágeis publicados por cada autor da amostra considerada. Estes dados conduziram às seguintes medidas: mediana = 2; média = 2,18; moda = 1; desvio padrão = 1,62; valor máximo = 7.

Uma vez que o conjunto de participantes para avaliar as características de agilidade e as práticas ágeis é o mesmo, os cálculos para definir quais são as característi-cas/práticas pertinentes também são os mesmos, dependendo apenas das diferentes respostas dos participantes para os dois conjuntos de características e práticas.

Para definir quais características de agilidade/práticas ágeis são pertinentes no con-texto das abordagens ágeis de software, é necessário computar as respostas de cada

onde:

participante e considerar seu respectivo peso, tanto para as características quanto para as práticas. As respostas, com os respectivos pesos, foram computadas através das fórmulas a seguir apresentadas, adaptadas do trabalho de [10]:

m

iiSjispostaRejaPertinênci

1))(*),(()( onde:

Pertinência(j) é o valor total das respostas de todos os participantes (multiplicadas por seus respectivos pesos) sobre a pertinência da característica/prática j para ca-racterizar um processo ágil de software.

Resposta(i, j) é o indicador de pertinência (1) ou não pertinência (0) definido pelo participante i para a característica/prática j.

S(i) é o peso atribuído ao participante i; m é o total de participantes que responderam à pesquisa de opinião.

A definição se uma característica de agilidade/prática ágil é pertinente ou não per-tinente deve estar baseada em um ponto de corte, isto é, um patamar indicando se a característica/prática está incluída no conjunto final (valor maior ou igual ao patamar).O patamar adotado para este estudo é 50% do valor máximo que poderia ser obtido para a característica/prática j na variável Pertinência(j) se todos os participantes res-pondessem sim com relação à sua pertinência no contexto das abordagens ágeis.

m

iiSPatamar

1)(*5,0

S(i) é o peso atribuído ao participante i m é o total de participantes que responderam à pesquisa

Portanto o critério fica assim: se Pertinência(j) < Patamar então a característi-ca/prática j é classificada como não pertinente e deve ser removida do conjunto inici-al; se Pertinência (j) ≥ Patamar então a característica/prática j é classificada como pertinente e deve ser mantida no conjunto inicial.

Ao conjunto obtido a partir do conjunto inicial de características de agilida-de/práticas ágeis, de acordo com o patamar estabelecido, devem ser adicionadas as características/práticas indicadas pelos participantes para completar o conjunto inicial, desde que as características/práticas indicadas tenham sido descritas quanto ao seu significado. As características/práticas incluídas pelos participantes foram considera-das como pertinentes.

Para definir o nível de relevância de uma característica de agilidade/prática ágil classificada previamente como pertinente, é necessário primeiramente somar as res-postas de cada participante (multiplicadas por seus respectivos pesos).

m

iiSjiEscalajRNível

1))(*),(()(

RNível(j) é o valor total de respostas de todos os participantes (multiplicadas por seus pesos) para a característica/prática j

m é o total de participantes que responderam à pesquisa Escala(i, j) é a escala de nível de relevância (0-3) definida pelo participante i para a

característica/prática j S(i) é o peso atribuído ao participante i

onde:

onde:

Após este passo, as características de agilidade/práticas ágeis foram ordenadas por seus respectivos RNível(j), sendo a mais relevante foi aquela com o maior valor de RNível(j).

Cada participante teve que: preencher as informações relacionadas com sua carac-terização; indicar a pertinência de um conjunto de características de agilidade (apre-sentado em ordem alfabética); definir o nível de relevância destas características; indicar a pertinência de um conjunto de práticas ágeis de software (apresentadas em ordem alfabética); e finalmente, definir o nível de relevância destas práticas ágeis.

A população para esta pesquisa de opinião é formada por autores de artigos cientí-ficos publicados a partir de 2008, relacionados com abordagens ágeis e identificados e referenciados nas revisões sistemáticas de literatura sobre características de agilidade e práticas ágeis descritas em [8, 9]. Os participantes foram contatados por email e acessaram um website onde o questionário estava disponível, utilizando um código para login e uma senha enviada no corpo do email de contato.

As variáveis independentes do estudo são o conjunto inicial de características de agilidade e o conjunto inicial de práticas ágeis de software. As variáveis dependentes são o conjunto final de características de agilidade, o nível de relevância para cada característica de agilidade incluída no conjunto final relacionado com suas respectivas relevâncias para caracterizar um processo de software como sendo ágil, o conjunto final de práticas ágeis de software e o nível de relevância para cada prática ágil de software incluída no conjunto final relacionado com suas respectivas relevâncias para a adoção de uma abordagem ágil em um processo de software.

Quanto à validade de conclusão, numa tentativa de se evitar influências, não foram convidados a participar do estudo, autores de artigos dos quais foram extraídas carac-terísticas de agilidade ou práticas ágeis identificadas nas revisões sistemáticas de lite-ratura. Supõe-se que esta população formada pelos demais autores é representativa no contexto dos pesquisadores em abordagens ágeis, sendo que eles responderam ao questionário utilizando seu conhecimento e experiência neste campo de pesquisa. Após executar o estudo com essa população, foi avaliado o nível de confiança dos dados obtidos, utilizando-se uma fórmula adaptada de [11] apresentada a seguir:

)*/()(0 nNnNE

E0 = Nível de Confiança (ex. 0,05 ≡ 95%) N = Tamanho da população n = Tamanho da amostra

A verificação da H0 1 foi feita pela simples demonstração da presença ou não de características de agilidade no conjunto de características a serem incluídas e no con-junto de características a serem removidas do conjunto inicial. O conjunto final de características de agilidade foi definido adicionando-se ao conjunto inicial as caracte-rísticas presentes no conjunto de características a serem incluídas e também removen-do-se do conjunto inicial as características presentes no conjunto de características a serem excluídas. O resultado destas duas operações produziu o conjunto final de ca-racterísticas de agilidade. O critério utilizado para definir os itens de cada conjunto mencionado (características a serem incluídas e características a serem removidas)

onde:

foi: 1. Para o conjunto de características a serem removidas, a pertinência associada com a característica deve ser menor do que o patamar estabelecido e já descrito nesta seção; 2. Para ser inserida no conjunto de características a serem incluídas, uma carac-terística, com a respectiva descrição de seu significado, deve ser indicada por pelo menos dois participantes. A verificação da H0 2 foi feita pela simples demonstração da presença ou não de práticas ágeis no conjunto de práticas a serem incluídas e no conjunto de práticas a serem removidas do conjunto inicial. O conjunto final de práti-cas ágeis foi definido adicionando-se ao conjunto inicial as práticas presentes no con-junto de práticas a serem incluídas, e também removendo do conjunto inicial as práti-cas presentes no conjunto de práticas a serem excluídas. O resultado destas duas ope-rações produziu o conjunto final de práticas ágeis. O critério utilizado para definir os itens dos conjuntos de práticas a serem incluídas e de práticas a serem removidas foi: 1. Para o conjunto de práticas a serem removidas, a pertinência associada com a práti-ca deve ser menor do que o patamar estabelecido e já descrito nesta seção; 2. Para ser inserida no conjunto de práticas a serem incluídas, uma prática com a respectiva des-crição de seu significado deve ser indicada por pelo menos dois participantes.

3 Resultados e Discussão

O instrumento esteve disponível de 06 de janeiro de 2011 até 06 de março de 2011 (data de fechamento para análise dos resultados do estudo), no endereço http://lens-ese.cos.ufrj.br/surveyagile/. Por email, foram convidados 117 participantes. Até o final do mês de janeiro de 2011 houve 31 acessos, sendo que 21 participantes registra-ram suas respostas. Dentre os respondentes havia participantes da Áustria, Estados Unidos, Canadá, Jordânia, Dinamarca, Finlândia e Itália, dentre outros. Infelizmente não há mecanismos adequados para se verificar se todas as mensagens enviadas por e-mail chegaram aos seus destinatários. Alguns podem não estar mais sendo utilizados.

Para cada participante foram tabulados seus atributos de caracterização e computa-do um peso individual conforme descrito na seção 2. As respostas de cada pesquisa-dor foram ponderadas com um peso diferenciado de acordo com seu nível de experi-ência e/ou habilidade.

Como foram enviados 117 emails com endereços supostamente válidos, e houve resposta de 21 participantes, o nível de confiança fica em torno de 80,23 % dos dados coletados, obtido com a aplicação da fórmula para cálculo do nível de confiança de uma amostra, fórmula esta apresentada na seção 2 deste documento, adaptada de [11].

Uma vez obtidos os pesos dos participantes, pode-se passar para a análise dos re-sultados sobre a avaliação da pertinência das características de agilidade. Aplicando-se os critérios e procedimentos descritos no planejamento da pesquisa de opinião que se encontra na seção 2 deste documento, após os cálculos para cada característica de agi-lidade avaliada foi elaborado o gráfico da Fig. 1, mostrando os níveis de pertinência das características. Detalhes e passos intermediários para análise dos dados obtidos estão descritos na seção 2.

Fig. 1. Pertinência das Características de Agilidade

Como o limite inferior adotado no planejamento da pesquisa de opinião para uma característica ser considerada pertinente foi de 50%, temos então que as características Convergência e Equipes Locais (níveis de pertinência 45,0% e 30,9% respectivamente)não serão consideradas pertinentes e não farão parte do corpo de conhecimento inicial a ser adotado para prosseguimento dos estudos em um contexto mais amplo de pesqui-sa. Observa-se que os participantes não sugeriram qualquer característica nova com suas respectivas descrições, diferentes daquelas do conjunto inicial enviado para a pesquisa de opinião. A H0 1 apresentada no planejamento da pesquisa de opinião (se-ção 2) não foi observada. Contudo há um risco associado, visto que o nível de confian-ça apurado foi de 80,23%.

Do mesmo modo como foi feito para as características, e aplicando-se os mesmos critérios e procedimentos, foram feitos os cálculos também para as práticas ágeis. Ográfico da Fig. 2, mostra o nível de pertinência para cada prática. Detalhes e passos intermediários para análise dos dados estão descritos na seção 2.

Fig. 2. Pertinência das práticas ágeis

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0%

100,0%

Nív

el d

e Per

tinên

cia

Características

Pertinência das Características de Agilidade

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0%

100,0%

Nív

el d

e Per

tinênci

a

Práticas

Pertinência das Práticas Ágeis

Como o limite inferior adotado no planejamento da pesquisa de opinião para uma prática ser considerada pertinente foi de 50%, temos então que as práticas Espaço de trabalho aberto e Programação em par não serão consideradas pertinentes e não farão parte do corpo de conhecimento inicial a ser adotado para prosseguimento de estudos em um contexto mais amplo de pesquisa.

Não houve indicação de novas práticas ágeis por parte dos participantes. Contudo, a H0 2 descrita na seção 2 deste documento também não foi observada, já que 2 práti-cas ágeis foram removidas do conjunto original. Entretanto, as mesmas ressalvas já feitas com relação a riscos para o caso da não observação da H0 1, valem para a H0 2.

Uma vez identificada a pertinência para cada característica e para cada prática, po-de-se determinar seus respectivos níveis de relevância. Aplicando-se o procedimento de cálculo descrito na seção 2 foram determinados os níveis de relevância para as ca-racterísticas de agilidade e para as práticas ágeis. Os resultados deste procedimento de cálculo estão expressos na tabela 1.

Tabela 1. Relevância das Características de Agilidade e das Práticas Ágeis

CaracterísticaNível de

Relevância PráticaNível de

RelevânciaOrientação a pessoas 89,1% Integração contínua 92,1%Adaptabilidade 88,7% Backlog de produto 82,7%Ser iterativo 84,8% Releases curtas 82,4%Ser colaborativo 84,7% Refatoração 80,2%Testes constantes 84,1% Visibilidade de projeto 75,8%Incorporação de realimentação 84,1% Jogo de planejamento 70,7%Ser incremental 83,3% Design simples 62,9%Reflexão e Introspecção 80,8% Reuniões diárias 57,7%Ser cooperativo 79,3% Padrões de código 55,7%Time-Boxing 63,5% Propriedade coletiva do código 51,7%Transparência 62,8% Desenvolvimento orientado a testes 46,2%Emergência 57,7% Ritmo sustentável 42,3%Auto-organização 57,2% Cliente presente 37,3%Leanness 56,5% Equipe completa 34,9%Modularidade 54,0% Metáfora 34,6%Equipes pequenas 43,2%

Observa-se que a H0 3 descrita na seção 2 não foi observada, já que as característi-cas de agilidade não apresentaram todas o mesmo nível de relevância. As mesmas ressalvas já feitas com relação a riscos para o caso da não observação de H0 1 e H0 2 também valem para a H0 3.

Também no caso das práticas observa-se que a H0 4 descrita na seção 2 não foi ob-servada, já que as práticas ágeis não apresentaram, todas, o mesmo nível de relevância. Mas, ficam valendo as mesmas ressalvas já feitas para a não observação das 3 hipóte-ses nulas anteriores, decorrentes do nível de confiança alcançado.

Uma das características que atingiu mais que 90% de pertinência (ser iterativo) é apontada como um dos denominadores comuns dentre as principais metodologias ágeis propostas na literatura. Embora com uma relação de ordem diferente, as 10 caracterís-ticas/práticas com maiores níveis de pertinência também estão entre as 10 característi-cas/práticas que apresentaram os maiores níveis de relevância.

Assim, um corpo de conhecimento envolvendo 16 características de agilidade e 15 práticas ágeis com seus respectivos níveis de relevância foi definido.

4 Ameaças à Validade

Este estudo partiu de conjuntos iniciais de características de agilidade e de práticas ágeis identificadas com base no que foi encontrado na literatura técnica, na visão de pesquisadores. Isto se traduz em uma limitação do estudo. Não se pode ter a certeza de que os mesmos conjuntos iniciais seriam obtidos se fosse feita uma tentativa de identi-ficar as características e práticas ágeis em projetos de software reais que empregassem as idéias de agilidade em desenvolvimento de software. Isto poderia levar este estudo a diferentes resultados se uma visão mais “industrial” fosse utilizada para identificar os conjuntos iniciais de características e práticas. Também, as limitações ou ameaças à validade deste estudo estão associadas com os critérios que conduziram a formação das strings de busca utilizadas nas revisões sistemáticas de literatura que deram origem ao conjunto inicial de características de agilidade e de práticas ágeis incluídas no estudo [8, 9]. Naquelas oportunidades, houve uma tentativa de evitar perda de documentos relevantes para o estudo. Porém, devido à escolha dos termos de busca, e também de-vido algumas dificuldades encontradas com a máquina de busca da ACM digital li-brary, especialmente durante a revisão de características de agilidade, há o risco de que estudos relevantes tenham ficado de fora da revisão. No caso da revisão de característi-cas de agilidade [8], o critério estabelecido no protocolo (exclusão de documentos reportando características de um método ágil em particular), embora evitasse influên-cias (vieses), pode ter deixado fora do conjunto inicial alguma característica diferente daquelas identificadas com a execução do protocolo da revisão sistemática.

A experiência com projetos ágeis foi ponderada com os pesos associados a cada participante, para avaliar os resultados. Contudo, hoje em dia muitos projetos que são ditos e considerados como sendo ágeis, na verdade não o são, o que poderia distorcer os resultados. Não foi possível fazer uma avaliação do perfil dos respondentes para excluir do estudo aqueles que não teriam experiência prática suficiente para responder.

Também há que se considerar que o nível de confiança obtido para a amostra utili-zada no estudo ficou em torno de 80,23%, o que representa um risco, mesmo conside-rando-se que algumas mensagens podem não ter sido recebidas (devido, por exemplo,à possibilidade de haver emails que não estão mais sendo usados pelos pesquisadores convidados a participar do estudo). Assim, os resultados deste trabalho podem ser uti-lizados, mas com o devido cuidado ou parcimônia.

Quanto à validade de constructo, este estudo é caracterizado por uma suposta vali-dade de dois conjuntos iniciais de características de agilidade e práticas ágeis definidas através de revisões de literatura técnica. Um dos propósitos deste estudo é confirmar a validação do conjunto inicial de características de agilidade, além de permitir sua evo-lução, e ao mesmo tempo, obter um conjunto idôneo de práticas ágeis de software com relação à adoção de uma abordagem ágil para processos de software.

Quanto à validade externa deste estudo, os participantes são considerados represen-tativos para a população de pesquisadores em abordagens ágeis, uma vez que eles foram identificados através de revisões sistemáticas de literatura, incluindo estudos publicados desde 2008. Eventuais riscos ou ameaças à validade decorrentes dos crité-rios adotados nas revisões sistemáticas são reduzidos parcialmente pela exclusão de autores de artigos dos quais foram extraídas características e práticas nas revisões sistemáticas, pois seria possível alguma argumentação de que as opiniões de tais pes-quisadores eventualmente poderiam influenciar os resultados, pelo fato de eles pró-prios terem contribuído com características/práticas em seus artigos, dentro dos crité-

rios estabelecidos nos protocolos das revisões sistemáticas. Os objetos utilizados neste estudo (conjunto inicial de características de agilidade e de práticas ágeis de software) podem ser considerados reais e representativos para o problema sendo estudado, uma vez que tais objetos foram definidos utilizando-se diferentes trabalhos científicos publicados na literatura técnica sobre abordagens ágeis. Cada participante teve opor-tunidade de responder o questionário sem limitação de tempo, uma vez iniciado o preenchimento do instrumento de pesquisa.

A instrumentação utilizada neste estudo foi idealizada para ser tão simples quanto possível e demandar a mínima quantidade de tempo para os participantes responde-rem as questões. A língua utilizada no instrumento de pesquisa foi a língua inglesa, por ser a mais acessível e tendo em vista as mais variadas nacionalidades dos partici-pantes convidados para fazer parte do estudo.

5 Conclusão

A partir das respostas dos participantes, duas características de agilidade originárias de revisão sistemática de literatura [8] foram excluídas do corpo de conhecimento inicial: Convergência e Equipes Locais. O mesmo aconteceu com duas práticas ágeis originá-rias de revisão sistemática de literatura [9]: Espaço de trabalho aberto e Programação em par. Dezesseis características de agilidade e quinze práticas ágeis passam a fazer parte de um corpo de conhecimento inicial para apoiar o prosseguimento de estudosque busquem a agilidade para processos de software. Das dezesseis características de agilidade que passam a fazer parte do corpo de conhecimento, apenas uma (Equipes pequenas) apresenta nível de relevância abaixo de 50%.

Das quinze práticas ágeis que devem fazer parte do corpo de conhecimento, dez a-presentam nível de relevância acima de 50%. Dentre estas, Integração contínua é a prática com mais alto nível de relevância, da ordem de 92%. As práticas que apresen-tam os mais baixos níveis de relevância foram: Equipe completa e Metáfora.

A utilização do corpo de conhecimento inicial formado a partir dos resultados deste estudo apresenta um nível de confiança de 80,23%, alcançado a partir da amostra e calculado conforme o planejamento descrito na seção 2.

Com base nos resultados do estudo, devem inicialmente fazer parte do corpo de co-nhecimento avaliado, as características de agilidade e práticas ágeis que se seguem:

16 Características de Agilidade: Ser colaborativo, Ser cooperativo, Ser incremental, Adaptabilidade, Auto-organização, Ser iterativo, Testes constantes, Emergência, In-corporação de realimentação, Leanness, Modularidade, Orientação a pessoas, Reflexão e Introspecção, Equipes pequenas, Time-Boxing, Transparência.

15 Práticas Ágeis: Padrões de código, Propriedade coletiva do código, Integração contínua, Metáfora, Cliente presente, Jogo de planejamento, Backlog de produto, Visi-bilidade de projeto, Refatoração, Design simples, Releases curtas, Reuniões diárias, Ritmo sustentável.

As descrições destas características de agilidade e das práticas ágeis foram consoli-dadas nas respectivas revisões sistemáticas de literatura e estão registradas em [8, 9].

Trabalhos futuros no contexto de processos ágeis de software poderão incluir as-pectos como estimativa do grau de agilidade alcançado por métodos ou processos de software e a avaliação de tais métodos ou processos quanto à agilidade; projeto e exe-cução de estudos experimentais para detectar e/ou implantar práticas ágeis relacionadas

com atividades de processos de software e que possam promover agilidade para um processo específico em um determinado ambiente de desenvolvimento de software.Além disso, tendo em vista as limitações apresentadas na seção anterior, o ideal seria replicar o estudo em outros contextos, com outros participantes, e compará-los, visan-do aumentar o poder de generalização dos resultados.

Agradecimentos

Esta pesquisa foi desenvolvida no contexto do projeto Experimentação em Enge-nharia de Software e Ciência em Larga Escala, CNPq 304795/2010-0. O Prof. Travas-sos é bolsista de produtividade em pesquisa do CNPq.

Referências

1. Bohem, B.: Making a difference in the software century. IEEE Computer, March, 78-84, (2008)

2. Ktata, O., Lévesque, G.: Agile development: Issues and avenues requiring a substantial enhancement of the business perspective in large projects. In: 2nd Canadian Conference on Computer Science and Software Engineering, pp. 59-66. Montreal (2009)

3. Beizer, B.: Software Testing Techniques. International Thomson Computer Press, Boston(1990)

4. Hass, A. M. J.: Testing processes. In: IEEE International Conference on Software Testing Verification and Validation Workshop ICSTW, (2008)

5. Vlaanderen, K., Jansen, S., Brinkkemper, S., Jaspers, E.: The agile requirements refi-nery: Applying SCRUM principles to software product management. Information and Software Technology, 53, 58–70 (2011).

6. Dyba, T., Dingsoyr, T.: Empirical Studies of Agile Software Development: A Systematic Review. Information and Software Technology, 50, 833-859 (2008).

7. Sharp, H., Robinson, H., Petre, M.: The role of physical artefacts in agile software devel-opment: Two complementary perspectives. Interacting with Computers 21, 108–116(2009).

8. Abrantes, J. F., Travassos, G. H.: Caracterização de Métodos Ágeis de Desenvolvimento de Software. In: Primeiro Workshop de Desenvolvimento Rápido de Aplicações – VI Sim-pósio Brasileiro de Qualidade de Software, Porto de Galinhas-PE, Brasil (2007).

9. Abrantes, J. F., Travassos, G. H.: Common Agile Practices in Software Processes. In: 2011 International Symposium on Empirical Software Engineering and Measurement, pp.355-358 (2011).

10. Farias, L. D.: Planejamento de Riscos em Ambientes de Desenvolvimento de Software O-rientados à Organização, Dissertação de M.Sc., COPPE/UFRJ, Rio de Janeiro (2002)

11. Hamburg, M.: Basic Statistics: A Modern Approach. Journal of the Royal Statistical So-ciety, Series A (General), 143, 1 (1980).

12. Basili, V.R., Caldiera, C., Rombach, H.D.: Goal/Question/Metric Paradigm. Encyclopae-dia of Software Engineering, vol. 1, pp. 528-532. John Wiley & Sons, New York, (1994)