estudos experimentais sobre agilidade no...
TRANSCRIPT
ESTUDOS EXPERIMENTAIS SOBRE AGILIDADE NO DESENVOLVIMENTO
DE SOFTWARE E SUA UTIL
ESTUDOS EXPERIMENTAIS SOBRE AGILIDADE NO DESENVOLVIMENTO
DE SOFTWARE E SUA UTILIZAÇÃO NO PROCESSO DE TESTE
José Fortuna Abrantes
Tese de Doutorado apresentada ao Programa de
Pós-Graduação em Engenharia de Sistemas e
Computação, COPPE, da Universidade Federal
do Rio de Janeiro, como parte dos requisitos
necessários à obtenção do título de Doutor em
Engenharia de Sistemas e Computação.
Orientador: Guilherme Horta Travassos
Rio de Janeiro
Março de 2012
ESTUDOS EXPERIMENTAIS SOBRE AGILIDADE NO DESENVOLVIMENTO
ZAÇÃO NO PROCESSO DE TESTE
Tese de Doutorado apresentada ao Programa de
Graduação em Engenharia de Sistemas e
putação, COPPE, da Universidade Federal
do Rio de Janeiro, como parte dos requisitos
necessários à obtenção do título de Doutor em
Engenharia de Sistemas e Computação.
Orientador: Guilherme Horta Travassos
ESTUDOS EXPERIMENTAIS SOBRE AGILIDADE NO DESENVOLVIMENTO
DE SOFTWARE E SUA UTILIZAÇÃO NO PROCESSO DE TESTE
José Fortuna Abrantes
TESE SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO LUIZ
COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA (COPPE) DA
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS
REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE DOUTOR EM
CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.
Examinada por:
________________________________________________
Prof. Guilherme Horta Travassos, D.Sc.
________________________________________________
Prof. Toacy Cavalcante de Oliveira, D.Sc.
________________________________________________
Profa. Ana Regina Cavalcanti da Rocha, D.Sc.
________________________________________________
Profa. Renata Mendes de Araujo, D.Sc.
________________________________________________
Prof. Rafael Prikladnicki, D.Sc.
RIO DE JANEIRO, RJ – BRASIL
MARÇO DE 2012
iii
Abrantes, José Fortuna
Estudos Experimentais sobre Agilidade no
Desenvolvimento de Software e sua Utilização no Processo de
Teste / José Fortuna Abrantes – Rio de Janeiro: UFRJ/COPPE,
2012.
XVI, 320 p.: il.; 29,7 cm.
Orientador: Guilherme Horta Travassos.
Tese (doutorado) – UFRJ/COPPE/Programa de Engenharia
de Sistemas e Computação, 2012.
Referências Bibliográficas: p. 217-228.
1. Abordagens Ágeis. 2. Processo de Teste de Software. 3.
Agilidade em Teste de Software. 4. Engenharia de Software
Experimental. I. Travassos, Guilherme Horta II. Universidade
Federal do Rio de Janeiro, COPPE, Programa de Engenharia de
Sistemas e Computação. III. Título.
iv
A meus pais, Vicente de Paula Abrantes e Iêda Fortuna Abrantes.
À minha esposa, Solange.
Aos meus irmãos, Fernando, Paulo e Vicente.
v
Agradecimentos
Primeiramente a Deus, por estar presente em todos os momentos e por ter me
agraciado com tantas coisas boas e permitir a conclusão de mais esta etapa importante
da minha vida. Nada teria sido possível sem Ele.
A minha mãe, Iêda, e ao meu pai, Vicente, meus exemplos de vida.
A minha esposa Solange, minha fonte de inspiração e de energia, companheira
dedicada e compreensiva, por acreditar em mim e apoiar sempre as minhas iniciativas.
A meus irmãos Fernando, Paulo e Vicente, esteios que me amparam, pelo
companheirismo e motivação nos momentos necessários.
Ao meu Orientador, Guilherme Horta Travassos, pela amizade, confiança e
incentivo, pelas oportunidades proporcionadas e pela orientação sempre firme e segura
na condução dos trabalhos.
Aos professores Ana Regina da Rocha, Rafael Prikladnicki, Renata Mendes de
Araujo e Toacy Cavalcante de Oliveira por concordarem em participar de minha banca
examinadora de doutorado.
Aos pesquisadores Ana Regina da Rocha, Arttu Piri, Asif Qumer, Casper
Lassenius, Ciro Grippi Barbosa Lima, Cristine Martins Gomes de Gusmão, David F.
Rico, Guilherme Zanetti Kümmel, Helio Rodrigues Costa, James D. Arthur, Jason
Cohen, Jo Ann Lane, Jobson Luiz Massollar da Silva, Laurie Williams, Luigi Buglione,
Malik Qasaimeh, Marcio de Oliveira Barros, Mariano Angel Montoni, Muhammad Ali
Babar, N. Poonguzhali, Natheer Khleaf Gharaibeh, Nils Brede Moe, Pekka
Abrahamsson, Renata Mendes de Araujo, Richard Turner, Rick Rabiser, Rodolfo Sergio
Ferreira de Resende, Shvetha Soundararajan, Tore Dybå, Torgeir Dingsoyr, Tuomas
Niinimäki, Usha Varatharajan um agradecimento especial pelas valiosas contribuições
para o desenvolvimento deste trabalho de pesquisa.
vi
À professora Ana Regina da Rocha, pelas oportunidades de aprendizado obtido
nas disciplinas cursadas com ela durante o doutorado.
Às professoras Renata Mendes de Araújo e Claudia Maria Lima Werner por
participarem da banca de meu exame de qualificação, tendo fornecido valiosas
contribuições para os ajustes realizados no trabalho desde então.
À professora Regina Maria Maciel Braga e ao professor José Luiz Casarotto
pelas indicações durante meu processo de seleção na COPPE.
Aos colegas Breno Bernard Nicolau de França, Jobson Luiz Massollar da Silva e
Paulo Sérgio Medeiros dos Santos pelo apoio no acesso aos servidores do laboratório de
engenharia de software e em toda a infra-estrutura computacional que foi utilizada para
implementação dos instrumentos necessários para executar os estudos.
Aos desenvolvedores Ciro Grippi Barbosa Lima, Guilherme Zanetti Kümmel e
Marcos Kalinowski por terem disponibilizado suas respectivas organizações de software
para experimentar o guia de agilidade.
Aos companheiros da Coppe, Adler Diniz de Souza, Alexandre Ribeiro Dantas,
Ana Candida Cruz Natali, Analia Irigoyen Ferreiro Ferreira, Arilo Cláudio Dias Neto,
Carlos Melo Jr., Guilherme Zanetti Kümmel, Jucele França de Alencar Vasconcellos,
Leonardo Gresta Paulino Murta, Marcos Kalinowski, Marco Alexandre de Macedo
Lopes, Marco Antônio Pereira Araujo, Mariano Angel Montoni, Paula Gomes Mian,
Peter Peret Lupo, Rafael Ferreira Barcelos, Reinaldo Cabral Silva Filho, Rodrigo de
Oliveira Spínola, Rosângela Pinto Silva, Sômulo Nogueira Mafra, Tayana Uchôa Conte,
Wagner Antônio Arbex, Wallace Martinho Pereira e Wladmir Araujo Chapetta pela
amizade, pelas sugestões, pela ajuda e disposição em colaborar comigo durante esta
pesquisa.
vii
Resumo da Tese apresentada à COPPE/UFRJ como parte dos requisitos necessários
para a obtenção do grau de Doutor em Ciências (D.Sc.)
ESTUDOS EXPERIMENTAIS SOBRE AGILIDADE NO DESENVOLVIMENTO
DE SOFTWARE E SUA UTILIZAÇÃO NO PROCESSO DE TESTE
José Fortuna Abrantes
Março/2012
Orientador: Guilherme Horta Travassos
Programa: Engenharia de Sistemas e Computação
A busca por aumentar a agilidade nos processos de apoio ao desenvolvimento de
software tem influenciado diferentes iniciativas de pesquisa. Alguns resultados podem
ser observados na literatura técnica, principalmente relacionados a métodos ágeis para
desenvolvimento. Em geral, abordagens ágeis compartilham características e práticas
que visam alcançar agilidade no desenvolvimento. Se por um lado observamos métodos
de desenvolvimento adotando estas características e práticas em um contexto bem
definido, por outro não fica claro como outros processos de software como, por
exemplo, teste de software, poderiam se beneficiar destas características e práticas
visando alcançar agilidade. Desta forma, esta tese apresenta uma abordagem para apoiar
a introdução de agilidade em processos de software, particularmente em processos de
teste de software. Estudos secundários (revisões sistemáticas) e primários (pesquisas de
opinião) foram utilizados para identificar, avaliar e classificar características e práticas,
resultando em 16 características de agilidade e 15 práticas ágeis que deveriam ser
consideradas para obter agilidade em processos de software. As práticas ágeis foram
mapeadas para as características de agilidade e para as atividades de um processo
padrão de teste de software, gerando 240 e 120 mapeamentos respectivamente, que
foram avaliados e atualizados por uma revisão externa (revisão por pares). A partir deste
conhecimento, foi definido um indicador do grau de agilidade de processos de software
e um guia de aplicação, compondo uma base que apóia a estratégia adotada nesta tese
para inserir agilidade em processos de teste de software. Um exemplo detalhado é
apresentado para mostrar a aplicação da estratégia proposta.
viii
Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the
requirements for the degree of Doctor of Science (D.Sc.)
EXPERIMENTAL STUDIES ON AGILITY IN SOFTWARE
DEVELOPMENT AND ITS APPLICATION ON TESTING PROCESSES
José Fortuna Abrantes
March/2012
Advisor: Guilherme Horta Travassos
Department: Computer Science and Systems Engineering
The search to increase agility in processes which support software development
has influenced different research initiatives. Some results can be seen in the technical
literature, mainly related to agile methods for software development. In general, agile
approaches share characteristics and practices aimed at achieving agility in
development. If on the one hand we observe development methods which are adopting
these characteristics and practices in a well-defined context, on the other is not clear
how other software processes, for example, software testing, could benefit from these
characteristics and practices to achieve agility. Thus, this thesis presents an approach to
support the introduction of agility into software processes, particularly in the process of
software testing. Secondary studies (systematic reviews) and primary studies (surveys)
were used to identify, evaluate and classify the characteristics and practices, resulting in
16 characteristics of agility and 15 agile practices that should be considered to obtain
agility in software processes. The agile practices have been mapped to the
characteristics of agility and to the activities of a standard process of software testing,
generating 240 and 120 mappings, respectively, which were evaluated and updated by
an external review (peer review). From this knowledge, we defined an indicator of the
degree of agility of the software processes and an application guide, comprising a base
that supports the strategy adopted in this thesis to insert agility in software testing
processes. A detailed example is presented to show the application of the proposed
strategy.
ix
ÍNDICE
1. Introdução..................................................................................... 1
1.1 Contexto ................................................................................................ 1
1.2 Problema................................................................................................ 3
1.3 Questões de Pesquisa............................................................................. 4
1.4 Objetivos................................................................................................ 6
1.5 Proposta de Solução para o Problema ................................................... 6
1.6 Metodologia de Trabalho....................................................................... 7
1.7 Trabalhos Relacionados....................................................................... 10
1.8 Organização do Trabalho..................................................................... 11
2. Processos de Teste de Software.................................................. 13
2.1 Introdução............................................................................................ 13
2.2 Tipos de Teste de Software ................................................................. 14
2.3 Níveis de Teste de Software ................................................................ 16
2.4 Modelos de Teste de Software............................................................. 19
2.5 Processos de Teste de Software........................................................... 23
2.6 Um Processo Padrão de Teste de Software ......................................... 32
2.7 Os Testes de Software e as Metodologias Ágeis................................. 34
2.8 Conclusão ............................................................................................ 38
3. Características de Agilidade em Processos de Software ............ 39
3.1 Introdução............................................................................................ 39
3.2 Revisão Sistemática de Literatura – Características de Agilidade ...... 43
3.3 Protocolo da quasi – Revisão Sistemática de Literatura ..................... 44
3.4 Execução das Buscas ........................................................................... 48
3.5 Resultados Obtidos .............................................................................. 49
3.6 Caracterização de um Processo Ágil de Software ............................... 62
3.7 Ameaças à Validade do Estudo ........................................................... 64
3.8 Conclusão ............................................................................................ 64
4. Práticas Ágeis para Processos de Software ................................ 66
4.1 Introdução............................................................................................ 66
4.2 Objetivo do Estudo .............................................................................. 71
4.3 Protocolo da Quasi - Revisão Sistemática de Literatura .................... 71
x
4.4 Execução do Protocolo ........................................................................ 75
4.5 Análise dos Resultados Obtidos .......................................................... 79
4.6 Proposta de Práticas Ágeis para Processos de Software...................... 91
4.7 Conclusões........................................................................................... 92
5. Avaliação de Características e Práticas Ágeis............................ 93
5.1 Introdução............................................................................................ 93
5.2 Planejamento do Estudo ...................................................................... 94
5.3 Resultados e Discussão...................................................................... 113
5.4 Ameaças à Validade .......................................................................... 131
5.5 Conclusão .......................................................................................... 131
6. Mapeamento de Práticas Ágeis para Características de Agilidade
e Atividades de Teste de Software ........................................... 135
6.1 Introdução.......................................................................................... 135
6.2 Características de Agilidade para Processos de Software ................. 136
6.3 Atividades do Processo de Teste de Software ................................... 136
6.4 Práticas Ágeis .................................................................................... 137
6.5 Mapeamento das Práticas para as Características de Agilidade ........ 138
6.6 Matriz de Associação entre Práticas Ágeis e Características de
Agilidade ........................................................................................... 143
6.7 Mapeamento das Práticas para as Atividades de Processos de Teste de
Software............................................................................................. 145
6.8 Matriz de Associação entre Práticas Ágeis e Atividades de Processos
de Teste de Software.......................................................................... 148
6.9 Avaliação dos Mapeamentos Estabelecidos das Práticas Ágeis para as
Características de Agilidade e Atividades de Teste de Software ...... 150
6.10 Conclusão .......................................................................................... 165
7. Inserção de Agilidade em Processos de Teste de Software...... 167
7.1 Introdução.......................................................................................... 167
7.2 Visão Geral da Estratégia Adotada.................................................... 169
7.3 Detalhamento da Estratégia Proposta para Apoiar a Inserção de
Características de Agilidade em Processos de Teste de Software..... 173
7.4 Instrumentação para o Guia de Agilidade Proposto .......................... 185
xi
7.5 Exemplo de Aplicação da Estratégia Proposta .................................. 186
7.6 Conclusão .......................................................................................... 206
8. Considerações Finais ................................................................ 207
8.1 Sinopse do Trabalho Realizado ......................................................... 207
8.2 Resultados Obtidos ............................................................................ 210
8.3 Contribuições da Pesquisa ................................................................. 212
8.4 Limitações da Pesquisa...................................................................... 214
8.5 Trabalhos Futuros .............................................................................. 215
Referências Bibliográficas................................................................................ 217
Apêndice A Documentos Considerados na Revisão Sistemática de Literatura
para Identificar Características de Agilidade............................ 229
Apêndice B Documentos Considerados na Revisão Sistemática de Literatura
para Identificar Práticas Ágeis.................................................. 231
Apêndice C Instrumentação do Estudo para Avaliação de Características e
Práticas Ágeis ........................................................................... 233
Apêndice D Instrumentação da Revisão por Pares....................................... 244
Apêndice E Instrumentação do Guia de Agilidade para Processos de Teste de
Software.................................................................................... 267
Apêndice F Análise Detalhada dos Resultados da Revisão dos Mapeamentos
entre Práticas Ágeis e Características de Agilidade ................. 302
Apêndice G Análise Detalhada dos Resultados da Revisão dos Mapeamentos
entre Práticas Ágeis e Atividades de Teste de Software .......... 314
xii
ÍNDICE DE FIGURAS
Figura 1-1 Metodologia de Pesquisa – Fase de Concepção (SPÍNOLA et al., 2008)...... 8
Figura 1-2 - Resumo das Fases da Metodologia Adotada ................................................ 8
Figura 2-1 – Interação entre os processos de teste de software e de desenvolvimento de
software .................................................................................................................. 14
Figura 2-2 – Modelo em Cascata (Adaptado de Davis, 2000) ....................................... 20
Figura 2-3– Modelo em V (Adaptado de Davis, 2000).................................................. 21
Figura 2-4 – Processo Genérico de Teste (Adaptado de Davis, 2000)........................... 24
Figura 2-5 – Processo Genérico Iterativo de Testes (Adaptado de HASS, 2008).......... 28
Figura 2-6 – Processo Padrão – Subprocesso de Planejamento (Dias Neto e Travassos,
2006)....................................................................................................................... 32
Figura 2-7 – Processo Padrão – Subprocesso de Execução (Dias Neto e Travassos,
2006)....................................................................................................................... 33
Figura 3-1 – String de Busca Básica .............................................................................. 47
Figura 3-2 – Percentagens de Incidência das Características nos Artigos ..................... 52
Figura 3-3 – Distribuição das Características por Faixa de Tempo das Publicações ..... 53
Figura 3-4 – Quantitativos de Controles Recuperados pelas Máquinas de Busca ......... 54
Figura 3-5 – Execuções de protocolo ao longo do tempo .............................................. 55
Figura 3-6 - Incidência das Características nos Artigos ................................................. 60
Figura 3-7 – Distribuição das Características por Faixa de Datas de Publicação dos
Artigos .................................................................................................................... 61
Figura 4-1 – String de Busca Básica (Práticas Ágeis).................................................... 75
Figura 4-2 – Percentuais de Documentos por ano de Publicação................................... 84
Figura 4-3 – Percentuais de Incidência nos Artigos ....................................................... 86
Figura 5-1 - Representação Esquemática das Telas do Instrumento de Pesquisa ........ 112
Figura 5-2 - Tela de Pertinência das Características de Agilidade............................... 113
Figura 5-3 – Gráfico de Nível de Pertinência das Características de Agilidade ......... 116
Figura 5-4 – Gráfico de Nível de Pertinência das Práticas Ágeis ............................... 119
Figura 5-5 – Gráfico de Nível de Relevância das Características de Agilidade........... 121
Figura 5-6 – Gráfico de Nível de Relevância das Práticas Ágeis................................. 123
Figura 5-7 - Níveis de Pertinência das Características de Agilidade ........................... 126
Figura 5-8 – Níveis de Pertinência das Práticas Ágeis................................................. 128
xiii
Figura 5-9 – Nível de Relevância das Características de Agilidade............................. 129
Figura 5-10 – Nível de Relevância das Práticas Ágeis................................................. 130
Figura 7-1 - Carga/atualização da base de conhecimento sobre características e práticas
ágeis ...................................................................................................................... 170
Figura 7-2 - Seleção e planejamento das características e práticas ágeis..................... 171
Figura 7-3 - Avaliação dos resultados alcançados........................................................ 172
xiv
ÍNDICE DE TABELAS
Tabela 2-1 Entradas, Atividades e Saídas do Processo Genérico de HASS (2008)....... 27
Tabela 2-2 Subativiades Sugeridas para Planejamento Inicial, Monitoramento Controle
e Replanejamento e Projeto e Desenvolvimento dos Testes (HASS, 2008) .......... 29
Tabela 2-3 Subatividades Sugeridas para Execução, Avaliação e Relato e Fechamento
das Atividades de Teste (HASS, 2008) .................................................................. 31
Tabela 2-4 – Atividades dos Processos de Teste Apresentados ..................................... 33
Tabela 3-1 – Conjunto de Referências em uma Base de Dados..................................... 48
Tabela 3-2 – Características Identificadas para Processos Ágeis de Software............... 50
Tabela 3-3 – Sumário Quantitativo das Referências Recuperadas................................. 55
Tabela 3-4 – Características reforçadas pela quarta execução do protocolo.................. 58
Tabela 3-5 – Incidência das características de Agilidade nos Artigos ........................... 59
Tabela 3-6 - Distribuição das Características por Faixa de Tempo das Publicações ..... 60
Tabela 4-1 – Quantidade Total de Referências Recuperadas ......................................... 76
Tabela 4-2 – Quantidade de Referências Recuperadas sem Repetições ........................ 78
Tabela 4-3 – Quantidade de Referências Recuperadas e Selecionadas.......................... 78
Tabela 4-4 – Descrições dos campos da tabela de dados coletados dos artigos............. 79
Tabela 4-5 – Referências Auxiliares para as Fontes das Práticas................................... 80
Tabela 4-6 – Práticas Consolidadas................................................................................ 81
Tabela 4-7 – Artigos por Ano de Publicação ................................................................. 83
Tabela 4-8 – Quantidade de Artigos por Prática ............................................................ 85
Tabela 4-9 – Práticas com mais de uma ocorrência nos artigos..................................... 87
Tabela 5-1 - Telas do Instrumento de Pesquisa............................................................ 112
Tabela 5-2 – Caracterização dos Participantes e Cálculo dos Pesos Individuais ........ 115
Tabela 5-3 – Avaliação da Pertinência das Características de Agilidade..................... 115
Tabela 5-4 – Características de Agilidade Sugeridas pelos participantes ................... 117
Tabela 5-5 – Avaliação da Pertinência das Práticas Ágeis de Software ..................... 118
Tabela 5-6 – Avaliação da Relevância das Características de Agilidade..................... 120
Tabela 5-7 – Avaliação da Relevância das Práticas Ágeis.......................................... 122
Tabela 5-8 - Pesos Individuais dos Participantes ......................................................... 124
Tabela 5-9 - Pertinência das Características de Agilidade ........................................... 125
xv
Tabela 5-10 - Pertinência das Práticas Ágeis ............................................................... 127
Tabela 5-11 - Relevância das Características de Agilidade ......................................... 129
Tabela 5-12 - Relevância das Práticas Ágeis................................................................ 130
Tabela 5-13 – Características de Agilidade para compor o Corpo de Conhecimento.. 133
Tabela 5-14 - Práticas Ágeis para compor o Corpo de Conhecimento ........................ 133
Tabela 6-1 - Atividades do Processo Padrão de Testes de Software............................ 136
Tabela 6-2 – Produtos de Trabalho das Atividades do Processo Padrão de Testes...... 137
Tabela 6-3 – Matriz de Mapeamento entre Características de Agilidade e Práticas Ágeis
.............................................................................................................................. 144
Tabela 6-4 – Matriz de Mapeamento entre Atividades de Teste e Práticas Ágeis ...... 149
Tabela 6-5 – Distribuição dos Perfis dos Revisores nos Grupos Alocados ................. 153
Tabela 6-6 – Distribuição dos Resultados da Revisão dos Mapeamentos Práticas X
Características....................................................................................................... 161
Tabela 6-7 – Distribuição dos Resultados da Revisão dos Mapeamentos Práticas X
Atividades............................................................................................................. 161
Tabela 6-8 – Alterações nos Mapeamentos (Práticas X Características) Previamente
Estabelecidos a partir dos Resultados da Revisão por Pares ................................ 162
Tabela 6-9 - Matriz de Mapeamento entre Características de Agilidade e Práticas Ágeis
Atualizada............................................................................................................. 164
Tabela 7-1 - Caracterização de Projetos ....................................................................... 175
Tabela 7-2 - Caracterização do Projeto Exemplo......................................................... 187
Tabela 7-3 - Caracterização de Projeto de Software .................................................... 188
Tabela 7-4 - Adequação do Projeto às Abordagens Ágeis ........................................... 189
Tabela 7-5 - Características de Agilidade Escolhidas para o Processo de Software.... 190
Tabela 7-6 - Obtenção de Práticas Ágeis Mapeadas para as Características de Agilidade
.............................................................................................................................. 191
Tabela 7-7 - Restrições pelas Atividades do Processo Padrão de Testes ..................... 193
Tabela 7-8 - Sugestões de Práticas a serem Adotadas, Ordem de Prioridade Estabelecida
pela Equipe de Testes ........................................................................................... 195
Tabela 7-9 - Sugestões de Práticas a serem Adotadas, Ordem de Grau de Agilidade em
Potencial Estimado ............................................................................................... 195
xvi
Tabela 7-10 - Sugestões de Práticas a serem Adotadas, Ordem de Nível de Relevância
.............................................................................................................................. 195
Tabela 7-11 - Grau de Similaridade entre Projetos, Dados dos Projetos ..................... 196
Tabela 7-12 - Grau de Similaridade entre Projetos ...................................................... 197
Tabela 7-13 - Caracterização e Histórico de Projetos de Software .............................. 197
Tabela 7-14 - Apuração de Práticas de Projetos Semelhantes Concluidos com
Resultados Satisfatórios........................................................................................ 198
Tabela 7-15 - Práticas de Projetos Semelhantes Concluídos com Resultados
Satisfatórios .......................................................................................................... 200
Tabela 7-16 - Práticas Escolhidas para o Processo de Testes....................................... 200
Tabela 7-17 - Recálculo do Grau de Agilidade em Potencial Estimado para o Processo
de Testes ............................................................................................................... 202
Tabela 7-18 - Avaliação dos Resultados para o Projeto Concluído ............................. 204
1
1. Introdução
Neste capítulo são apresentados o contexto do trabalho, o problema
que o motivou e as questões de pesquisa. São também apresentados
os objetivos, a metodologia de pesquisa adotada e a organização
deste texto.
1.1 Contexto
Apesar da experiência acumulada pela indústria no desenvolvimento de software
ao longo dos anos, dificuldades neste empreendimento ainda persistem, com casos de
projetos de software excedendo orçamentos, prazos, e quando completados
apresentando níveis de qualidade aquém do esperado.
O mercado exige que o software seja entregue cada vez mais rapidamente,
contudo mais rico em termos de funcionalidades e qualidade com baixo custo. Além
disso, o ambiente de negócios de hoje se apresenta de forma altamente sensível ao
tempo, exigindo que a acomodação de mudanças nos requisitos seja feita rapidamente
durante o desenvolvimento do software.
Pode-se observar nas últimas décadas a necessidade de que processos de
software sejam passíveis de adaptação a modificações tardias ou a modificações não
previstas, especialmente nos requisitos, para atender necessidades específicas dos
negócios em um mercado a cada dia mais dinâmico, mais 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
apropriado e mais rápido do que seus competidores (BOEHM, 2008). A morosidade
para acomodar incertezas e mudanças rápidas leva inevitavelmente à obsolescência do
software e à insatisfação do cliente (KTATA, 2009).
Diferentes abordagens são utilizadas para lidar com mudanças. Abordagens que
podem produzir software de alta qualidade e alta produtividade, mas que não podem
aceitar e acomodar mudanças, hoje em dia, não são muito atrativas. Alcançar alta
qualidade e produtividade, de forma consistente, na solução de problemas cuja escala
2
pode ser alta e em um ambiente onde as mudanças podem acontecer continuamente, tem
sido um dos principais desafios da engenharia de software (JALOTE, 2005).
As organizações de software freqüentemente precisam reagir à dinâmica do
mercado, a novos requisitos do cliente, a inovações tecnológicas, a fusões entre
companhias de software, dentre outros desafios. Nos últimos anos tem sido considerada
a adoção de abordagens ágeis para responder mais eficientemente à crescente dinâmica
dos negócios ou mudanças nas demandas dos clientes (BORJESSON E
MATHIASSEN, 2005). Diferentes métodos de desenvolvimento de software,
conhecidos como métodos ágeis, tem alcançado crescente popularidade e aceitação
(KONGSLI, 2006).
Os métodos ágeis diferem significativamente das abordagens tradicionais ou
prescritivas de desenvolvimento de software, enfatizando mais a produtividade do que
processos rigorosos. Assim, buscam executar apenas atividades ou tarefas de
desenvolvimento que agreguem valor ao negócio, com rapidez, ao mesmo tempo em
que buscam acomodar mudanças nos requisitos dos usuários (ÅGERFALK E
FITZGERALD, 2006). Como atividades ou tarefas de desenvolvimento que agregam
valor podem ser consideradas todas aquelas não ligadas a simplesmente seguir
processos rigorosos, mas associadas com a entregas freqüentes de produtos de software
funcionando e que satisfaçam as necessidades do cliente.
Desenvolvimento ágil de software é um termo utilizado para rotular alguns
métodos sugeridos por profissionais para melhor organizar o desenvolvimento de
software, a fim de produzir com mais rapidez, soluções mais adequadas e com menores
custos. Dentre estes métodos, pode-se citar alguns exemplos: Dynamic Systems
Development Method (STAPLETON, 1997), Open Source Software Development
(O’REILLY, 1999; SHARMA, 2002), Extreme Programming (BECK, 1999; BECK e
ANDRES, 2004), Adaptive Software Development (HIGHSMITH, 2000), Pragmatic
Programming (HUNT E THOMAS, 2000), Crystal (COCKBURN, 2002), Agile
Modeling (AMBLER, 2002), dX (MARTIN, 2002), Lean Development (BOB
CHARETTE, 2002), Feature Driven Development (PALMER e FELSING, 2002),
Scrum (SCHWABER e BEEDLE, 2002), Lean Software Development
(POPPENDIECK e POPPENDIECK, 2003; Poppendieck e Poppendieck, 2006), EVO
(GILB, 2007),
3
Segundo VLAANDEREN et al. (2011), uma das mais importantes inovações em
metodologia de desenvolvimento de software dos últimos anos tem sido a introdução
dos princípios ágeis. 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 processos de software (DYBA E DINGSOYR, 2008).
Para que seja possível alcançar os níveis de qualidade almejados para os sistemas
de software, os testes de software têm um papel fundamental, e o processo de testes de
software torna-se cada vez mais importante para que seja possível atingir os objetivos
de qualidade dentro de custos competitivos e aceitáveis. Isto é também verdadeiro no
contexto das abordagens ágeis para desenvolvimento de software.
As atividades de teste de software estão entre as mais onerosas do conjunto de
atividades que fazem parte do processo de desenvolvimento de software (BEIZER,
1990). Conforme observa WATKINS (2009), muitas organizações consideram o
processo de teste de software muito caro. Contudo, as atividades de teste são relevantes
para avaliação de produtos de software, e são também essenciais para que uma
organização possa alcançar níveis intermediários em modelos de maturidade de
processos de desenvolvimento de software, embora nos níveis iniciais sejam tratados de
forma menos sistemática. A tendência de crescimento da quantidade de empresas
certificadas por modelos de maturidade do processo de desenvolvimento de software é
um fator que contribui para que as organizações valorizem ainda mais as atividades de
teste.
Apesar dos testes serem considerados por muitas abordagens ou metodologias
ágeis de desenvolvimento de software, não tem sido encontrados trabalhos publicados
tratando especificamente de detalhes sobre testes ágeis ou agilidade em processos de
teste de software. As buscas por trabalhos publicados a este respeito não tiveram como
resultado a identificação de artigos de maior relevância sobre o assunto. Portanto,
buscar uma forma de embutir agilidade ou tentar aplicar as idéias dos processos ou
métodos ágeis aos processos de teste de software representa um desafio de pesquisa.
1.2 Problema
É necessário que os processos de software possam se adaptar a modificações de
última hora ou modificações não previstas, especialmente nos requisitos, para atender
necessidades específicas dos negócios em um mercado a cada dia mais dinâmico, mais
4
competitivo e se abrindo a novas possibilidades. Mudanças constantes, especialmente
nos requisitos e no ambiente dos negócios, se transformam em dificuldades para
processos de software muito rígidos.
Com o processo de testes, isso não é muito diferente. Os esforços adicionais que
tem que ser consumidos por causa de mudanças nos requisitos podem tornar obsoletos
ou desatualizados artefatos de teste planejados, projetados e já especificados ou até
mesmo já executados e com seus resultados analisados. É desejável que o processo de
teste de software possa acomodar bem modificações de última hora (ou não previstas),
minimizando o impacto dessas modificações. Ao mesmo tempo, deve manter firme seu
objetivo de revelar o máximo de falhas com o menor custo possível. Em outras palavras,
é desejável que o processo de testes seja ágil o bastante para acomodar mudanças
inevitáveis e não previstas.
Entretanto, como embutir agilidade em um processo de teste de software? Quais
são as características desejáveis em um processo de teste para que ele possa ser
considerado ágil? Estas perguntas, embora aparentemente simples, ainda não possuem
respostas adequadas na literatura técnica.
1.3 Questões de Pesquisa
A questão de pesquisa para este trabalho está associada com a possibilidade de
introduzir características de agilidade em Processos de Teste de Software para prover
uma maior e melhor acomodação de mudanças, inclusive nos requisitos. O processo
deverá ter a capacidade de ser adaptado com rapidez para atender e reagir a mudanças
de última hora nos requisitos e no ambiente, bem como para atender e reagir a riscos ou
situações não previamente consideradas. É possível explorar as características de
agilidade em processos de teste de software?
Acredita-se que a agilidade no processo de teste de software poderá trazer
benefícios para o desenvolvimento de software porque seria possível tentar embutir
características de agilidade no processo sem prejudicar seus objetivos, além de conduzir
a maiores facilidades e economia de esforço quando a necessidade de acomodar
mudanças se apresentar. Uma alternativa para a inserção de características de agilidade
em processos de teste de software poderia ser a adoção de práticas ágeis.
As práticas de uma metodologia de desenvolvimento são mais claras e mais
específicas do que valores (que são universais) e princípios (que ligam os valores às
5
práticas). Por exemplo, é mais fácil saber se alguém comparece às reuniões diárias do
que saber se alguém valoriza suficientemente a comunicação (BECK e ANDRES,
2004).
Um requisito fundamental para esta hipótese é não sobrecarregar o processo de
testes para não se criar uma tendência de aversão (ou justificativa para não se adotar) às
práticas de software necessárias para que as características de agilidade sejam inseridas
no processo. Além disso, a adoção de práticas para se chegar às características de
agilidade deve apresentar baixo custo, para que a inviabilidade econômico-financeira
não seja usada como argumento contrário a essa adoção.
Uma alternativa de solução para se embutir características de agilidade em
processos de teste de software apoiada na adoção de práticas de software, em princípio,
abre algumas frentes de pesquisa para investigar e identificar:
Há alguma solução para embutir características de agilidade no processo
de teste de software a partir da adoção de práticas? Qual?
Quais características de agilidade são pertinentes e devem ou podem ser
candidatas a serem inseridas em um processo de teste de software com a
finalidade de torná-lo ágil?
Quais práticas ágeis de software são pertinentes e podem ser
consideradas para serem adotadas em processos de teste de software com
o objetivo de tentar embutir características de agilidade no processo?
Como fazer o mapeamento das práticas de software para as
características de agilidade que se deseja embutir no processo de teste de
software?
Como estimar o grau de agilidade apresentado por um processo de teste
de software?
Como avaliar a solução proposta para verificar se ela atinge o seu
objetivo e se as características de agilidade e as idéias dos métodos ágeis
podem ser aplicadas com sucesso nos processos de teste de software?
A primeira questão de pesquisa pode ser considerada a questão principal, e as
demais questões secundárias.
6
1.4 Objetivos
A meta deste trabalho consiste em apresentar uma proposta de solução para
embutir agilidade em processos de teste de software, não interferindo nos objetivos
originais do processo, visando reduzir esforço e permitir acomodar mudanças. Esta meta
pode ser decomposta nas seguintes partes:
• Apoiar a seleção de características de agilidade desejáveis para o
processo de testes;
• Definir um mapeamento de práticas de software para as características
selecionadas, de modo a embutir tais características no processo através
da adoção das práticas mapeadas, e;
• Apoiar o planejamento de indicadores que auxiliem observar o grau de
agilidade do processo de testes.
Este trabalho de pesquisa está relacionado com a utilização da abordagem ágil
para reduzir o impacto de mudanças (incluindo requisitos) nos resultados do processo de
teste, fazendo com que o mesmo possa acolher bem as mudanças e não lutar contra elas.
1.5 Proposta de Solução para o Problema
Há duas pressuposições consideradas no desenvolvimento desta pesquisa:
1. A organização tem um processo de teste estabelecido para um determinado
projeto de software (ou para seus projetos de software).
2. A organização deseja inserir agilidade neste processo de teste de software.
O processo de teste está geralmente associado a um processo de
desenvolvimento, podendo-se estabelecer aí uma dependência. Os processos são
distintos, mas o processo de teste faz parte do processo de desenvolvimento, e com ele
interage (McGREGOR e SYKES, 2001). Possivelmente a tentativa de inserção de
agilidade em um processo de teste poderia ter suas chances de sucesso aumentadas se o
processo de desenvolvimento de software no qual ele se insere fosse um processo ágil.
Contudo, este trabalho considera a possibilidade de se inserir agilidade em processos de
teste, independentemente do processo de desenvolvimento associado ser ágil ou não.
7
Neste trabalho a solução elaborada consiste, de modo sucinto, em uma estratégia
que envolve embutir características de agilidade no processo de teste a partir da adoção
de práticas ágeis. O conhecimento sobre características de agilidade tem que ser
disponibilizado para que se possa selecionar as características desejadas para o processo
de teste considerado. Também tem que ser disponibilizado o conhecimento sobre
práticas ágeis de software e atividades de teste de software. Uma base de conhecimento
será carregada inicialmente, a partir de resultados de revisões de literatura e estudos
experimentais envolvendo características de agilidade e práticas ágeis. No contexto
deste trabalho, a expressão “base de conhecimento” deve ser entendida como um
repositório de conhecimento que serve de apoio à solução proposta. Um mapeamento é
estabelecido entre as práticas ágeis e as características de agilidade, bem como entre as
práticas ágeis e as atividades do processo de testes. A partir dos mapeamentos citados
são sugeridas as práticas ágeis candidatas a serem adotadas no processo de teste. A
partir destas sugestões, e de lições aprendidas de projetos de software já concluídos, é
tomada a decisão final sobre as práticas ágeis que vão ser adotadas no processo de teste.
É feita uma estimativa do grau de agilidade esperado para o processo de teste. Os
resultados alcançados são avaliados ao final do projeto de software e poderão servir
como apoio à tomada de decisão em projetos futuros. Também poderão ser usados como
uma das alternativas para atualização da base de conhecimento, juntamente com novas
revisões de literatura e novos estudos experimentais. A estratégia de solução proposta, e
os elementos que a compõem, estão descritos nos capítulos seguintes deste trabalho.
1.6 Metodologia de Trabalho
A metodologia utilizada nesta pesquisa se apóia nos conceitos de engenharia de
software experimental (WOHLIN et al., 2000) e na estrutura apresentada por MAFRA
et al. (2006), na qual são contemplados estudos secundários e primários. Conforme
sugerem MAFRA et al. (2006), a metodologia é dividida em duas fases: (a) definição da
tecnologia e (b) refinamento da tecnologia.
Na primeira fase são realizados estudos secundários buscando o conhecimento
necessário para fundamentar a elaboração de proposta de uma metodologia para
solucionar um problema. Na segunda fase são realizados estudos primários (provas de
conceito, estudos de caso e estudos experimentais) para avaliar a tecnologia, podendo
esta ser então refinada e/ou ter sua compreensão ampliada. De acordo com SPÍNOLA et
8
al. (2008) a fase de concepção de novas tecnologias envolve a execução de estudos
secundários e/ou primários com o objetivo de se obter uma proposta inicial da
tecnologia proposta. A Figura 1-1 ilustra os passos envolvidos nesta fase.
Figura 1-1 Metodologia de Pesquisa – Fase de Concepção (SPÍNOLA et al., 2008)
A metodologia de pesquisa utilizada para a realização deste trabalho inclui
atividades realizadas antes da proposta de tese, para apoiar a elaboração da solução para
resolver o problema e atividades realizadas após o exame de qualificação, para permitir
o desenvolvimento e a avaliação desta solução. A Figura 1-2 abaixo apresenta uma
representação gráfica das fases da metodologia.
Figura 1-2 - Resumo das Fases da Metodologia Adotada
O conjunto de atividades realizadas antes da proposta de tese e que apoiaram a
sua elaboração está sucintamente descrito abaixo.
9
Foi realizada uma revisão informal de literatura sobre agilidade em testes
de software ou testes ágeis, bem como sobre as abordagens ágeis de
processos de desenvolvimento de software, buscando identificar os
fundamentos de tais abordagens.
Foi realizado um estudo secundário (revisão sistemática) sobre as
características de agilidade em processos de desenvolvimento de
software. O estudo foi repetido 2 vezes, para fins de atualização e
ampliação do espaço de busca.
Foi realizada uma revisão informal de literatura sobre práticas de
software no contexto ágil de desenvolvimento de software.
Foi realizado o planejamento e execução de uma pesquisa de opinião
para avaliar características de agilidade e práticas de software. Este
estudo foi executado inicialmente como piloto e foi re-executado
posteriormente.
Foi realizada uma revisão informal de literatura para identificar
processos genéricos de testes de software.
Foram realizados estudos sobre o mapeamento entre características de
agilidade e práticas de software e sobre estimativa de grau de agilidade
em processos de software.
A partir dos estudos feitos foi definida uma versão inicial da estratégia
proposta para embutir características de agilidade em processos de teste
de software.
Após o exame de qualificação o trabalho de pesquisa prosseguiu com outro
conjunto de atividades que passa a ser descrito abaixo.
Ajuste da proposta inicial a partir das sugestões e comentários
apresentados pela banca examinadora durante o exame de qualificação.
Planejamento e execução de uma revisão sistemática de literatura para
identificar práticas ágeis que possam ser consideradas na solução
elaborada para resolver o problema.
10
Repetição da execução do protocolo de revisão sistemática sobre
características de agilidade, mais uma vez, visando atualizar o corpo de
conhecimento.
Repetição da pesquisa de opinião sobre características de agilidade e
práticas ágeis com nova população.
Refinamento dos mapeamentos entre práticas ágeis e características de
agilidade e entre práticas ágeis e atividades do processo de teste.
Adaptação do método de estimativa do grau de agilidade em processos
de software para considerar os níveis de pertinência das características e
das práticas ágeis obtidos a partir da repetição da pesquisa de opinião
realizada antes da proposta de tese.
Explicitação da solução proposta.
Planejamento e execução de revisões por pares para avaliar os
mapeamentos entre práticas e características de agilidade e entre práticas
e atividades de teste.
1.7 Trabalhos Relacionados
De fato foram encontrados trabalhos que abordam parcial e superficialmente os
níveis de abstração e as idéias envolvidas nesta pesquisa. Muitos trabalhos encontrados
na literatura técnica a respeito de seleção de métodos de desenvolvimento para projetos
de software se concentram em apenas duas alternativas: 1- escolher entre as abordagens
ágeis ou as abordagens orientadas a planos; 2- ou escolher uma metodologia especifica
dentre aquelas pertencentes a estes dois grupos. Segundo BOEHM e TURNER (2004a),
os métodos orientados a planos se caracterizam por uma abordagem sistemática de
engenharia que segue cuidadosamente processos específicos que movem o software
através de uma série de representações, dos requisitos até o código pronto. Nos últimos
anos vem surgindo também a preocupação de se escolher as práticas mais apropriadas
para um projeto de software a partir de uma família de métodos ágeis. Além disso, há
trabalhos publicados relacionados com a construção de métodos híbridos, reunindo o
que houver de mais adequado dentre as duas abordagens (ágil ou orientada a planos)
para um determinado projeto de software. Em geral os trabalhos apresentados focam na
seleção de método para processos de desenvolvimento de software. Praticamente não se
11
encontra trabalhos publicados preocupados com processos de software específicos que
façam parte de um processo de desenvolvimento de software.
Alguns trabalhos encontrados sobre o tema podem ser destacados. BOEHM e
TURNER (2004a) apresentam um framework de seleção baseado em riscos, que busca
equilibrar agilidade e disciplina a partir de características do projeto de software para
selecionar uma abordagem de desenvolvimento para um projeto de software.
LITTLE (2005) propõe um framework que se baseia em direcionadores de
complexidade e de incerteza para os projetos de software. É definido um conjunto de
práticas denominadas fundamentais, que são aplicáveis a todos os projetos de software.
Posteriormente, o projeto de software tem suas características analisadas a partir dos
direcionadores de complexidade e incerteza, para determinar que outras práticas ou
atividades devem ser incorporadas ao processo de desenvolvimento a ser usado no
projeto de software.
MNKANDLA (2008) apresenta um framework para selecionar de uma família
de métodos ágeis, as práticas ágeis mais adequadas para um determinado projeto de
software. A proposta de MNKANDLA (2008) primeiro seleciona as metodologias ágeis
adequadas para o projeto de software, de acordo com suas características, depois captura
as práticas das metodologias ágeis selecionadas para o projeto e finalmente customiza as
práticas capturadas das metodologias ágeis, adequando-as para tornar viável o trabalho
de desenvolvimento de software com as práticas selecionadas.
QUMER e HENDERSON-SELLERS (2008) apresentam um framework de 4
dimensões para apoiar organizações a tomarem decisão sobre seleção ou adoção de um
método ágil já disponível ou de um método ágil construído a partir de fragmentos de
métodos ágeis.
1.8 Organização do Trabalho
Além deste capítulo introdutório, o presente documento contém mais sete capítulos.
No segundo capítulo são apresentados os resultados da revisão de literatura efetuada
para identificar processos genéricos de teste de software. No terceiro capítulo são
apresentadas revisões de literatura realizadas para identificar as características de
agilidade em processos de desenvolvimento de software. No quarto capítulo é
apresentada a revisão de literatura para identificar práticas ágeis para processos de
software. No quinto capítulo é apresentado um estudo experimental efetuado para
12
avaliar as características de agilidade e as práticas ágeis identificadas através de revisões
sistemáticas de literatura. No sexto capítulo é apresentado um mapeamento de práticas
ágeis para características de agilidade e para atividades de teste de software, que serve
de base para a solução proposta neste trabalho de pesquisa. Neste mesmo capítulo são
apresentados os resultados de uma revisão por pares para avaliar os mapeamentos
estabelecidos entre práticas ágeis e características de agilidade bem como entre práticas
ágeis e atividades de teste. No sétimo capítulo é descrita a solução elaborada para inserir
agilidade em processos de teste de software. No oitavo capítulo são apresentadas as
considerações finais deste trabalho de pesquisa.
Cabe ressaltar a importância da execução de um estudo visando avaliar o
desempenho do guia proposto. Entretanto, o tempo necessário para isso seria
demasiado, pois se teria que aguardar a execução dos testes como um todo. Desta
forma, este trabalho está relacionado com um trabalho futuro, a nível de mestrado, que
precisa ser feito, em continuidade a este trabalho de pesquisa.
13
2. Processos de Teste de Software
Neste capítulo são apresentados os resultados de uma revisão de
literatura efetuada com o objetivo de identificar um processo
genérico de teste de software para ser adotado nesta pesquisa como
padrão para considerar as atividades a ele associadas no contexto
deste trabalho.
2.1 Introdução
O Glossário Padrão de Terminologia de Engenharia de Software (IEEE 610,
1990) define processo como uma sequência de passos executados para um determinado
propósito. Segundo HASS (2008), processos, em geral, podem ser montados em
hierarquias de processos ou arquiteturas de processos, com a entrada para um processo
sendo uma ou mais saídas de um ou mais processos precedentes. Do mesmo modo, a
saída de um processo deve ser a entrada para um ou mais processos. A conexão entre
processos é a informação que eles produzem e utilizam. As dependências entre
processos podem ser visualizadas em um modelo de processo, que mostra como as
saídas de uns passam a ser as entradas para outros processos.
O processo de testes de software está geralmente associado a um processo de
desenvolvimento de software, podendo-se estabelecer aí uma dependência. Embora,
distintos, o processo de testes faz parte do processo de desenvolvimento de software, e
com ele interage, conforme mostra a Figura 2-1 que se segue, adaptada de McGREGOR
e SYKES (2001). O processo de teste cria conjuntos de casos de teste e conjuntos de
procedimentos de teste a partir dos artefatos de análise e de projeto que são elaborados
no processo de desenvolvimento. Ao final, o processo de testes guia os testadores para
revelar falhas no software e a partir delas os desenvolvedores atuam para localizar e
remover os defeitos responsáveis pelas falhas reveladas. Removidos os defeitos, o ciclo
de interação entre os dois processos se repete, com o software sendo novamente
submetido ao processo de teste, até que não apresente falhas associadas aos casos de
teste planejados.
14
Figura 2-1 – Interação entre os processos de teste de software e de desenvolvimento de software
2.2 Tipos de Teste de Software
Um conceito alternativo para teste de software é que ele é a medida da qualidade
do software em teste [Davis, 2000]. Há diversos tipos de teste de software. DI LUCCA
e FASOLINO (2006) destacam os testes funcionais e os testes não funcionais, que são
complementares e não mutuamente exclusivos. Os testes funcionais são responsáveis
por descobrir falhas das aplicações devido a defeitos na implementação dos requisitos
funcionais especificados. Os testes não funcionais visam verificar a conformidade da
aplicação com os seus requisitos não funcionais. Dentre os tipos de teste não funcionais
DI LUCCA e FASOLINO (2006) citam: teste de desempenho, teste de carga, teste de
stress, teste de compatibilidade, teste de usabilidade, teste de acessibilidade e teste de
segurança.
O teste de desempenho visa verificar se o rendimento real do software atende o
especificado para o software (por exemplo: tempo de resposta, disponibilidade de
serviço). Este tipo de teste é executado simulando muitos acessos simultâneos de
usuários em um intervalo de tempo definido. Em geral, falhas descobertas por testes de
desempenho são devido a defeitos no ambiente de execução, como recursos escassos ou
recursos não bem implantados, mesmo que algum componente de software do nível da
aplicação possa contribuir para a falha ou ineficiência (DI LUCCA e FASOLINO,
2006; NAIK e TRIPATHY, 2008).
O teste de carga requer que o desempenho do software seja avaliado com um
nível de carga pré-definido, e visa medir o tempo necessário para executar diversas
tarefas e funções sob condições pré-definidas. Tais condições incluem a configuração
mínima e os níveis máximos de atividade da aplicação. Elas podem incluir situações
envolvendo diferentes números de usuários em diferentes intervalos de tempo ou
diferentes volumes de transações a serem processadas. Falhas encontradas por testes de
Artefatos Desenvolvidos
Resultados dos Testes
Processo de Desenvolvimento
Processo de Testes
15
carga são em geral devido ao ambiente de execução (DI LUCCA e FASOLINO, 2006;
FOURNIER, 2009). Segundo NAIK e TRIPATHY (2008), os testes de carga exercitam
o software com usuários virtuais e medem o seu desempenho para verificar como ele se
comporta em situações reais. Com tal entendimento, pode-se antecipar e até mesmo
prevenir problemas relacionados com as diferentes demandas em que o software é
solicitado.
O teste de estresse é executado para avaliar o software ou um de seus
componentes quando exigido além dos limites especificados nos requisitos. É utilizado
para avaliar a resposta do software em picos de atividade que podem exceder suas
limitações e se o software falha ou é capaz de se recuperar de tais condições,
conseguindo responder as requisições dos seus usuários. A diferença para os testes de
desempenho e testes de carga é que neles é simulada uma atividade regular, enquanto
que no teste de estresse é simulada uma atividade além dos limites especificados para o
software. As falhas reveladas por testes de stress, geralmente, são devido a defeitos no
ambiente de execução (DI LUCCA e FASOLINO, 2006; FOURNIER, 2009). NAIK e
TRIPATHY (2008) consideram que o objetivo do teste de estresse é avaliar e
determinar o comportamento do software quando exigido até e além da capacidade para
a qual foi especificado. Se falhar nestas condições, os mecanismos de recuperação
previstos devem ser invocados.
O teste de compatibilidade em aplicações web busca revelar falhas devido o uso
de diferentes plataformas de servidor web ou de browsers, em suas diferentes liberações
(releases) ou configurações. Devido ser impraticável testar todas as combinações dos
diversos elementos envolvidos, apenas as combinações mais comuns são usualmente
testadas. (DI LUCCA e FASOLINO, 2006). Segundo NAIK e TRIPATHY (2008) o
teste de compatibilidade verifica se o software funciona do mesmo modo com diferentes
plataformas, sistemas operacionais e sistemas de banco de dados. Denominam ainda, de
teste de compatibilidade retroativo, os testes que verificam se a construção atual do
software apresenta o comportamento esperado com versões mais antigas de plataformas
operacionais e de bancos de dados.
O padrão internacional ISO/IEC 9126-1 (ISO, 2001) define a usabilidade como
uma das categorias de característica de qualidade. O teste de usabilidade busca verificar
a extensão em que a aplicação é fácil de usar e está centrado principalmente no teste da
interface do usuário, com questões ligadas a renderização de conteúdo (gráficos, edição
16
de texto, formatos, dentre outros), clareza de mensagens, prompts e comandos. A
facilidade de uso da interface gráfica de usuário, relatórios, ajuda on-line, mensagens de
erro e manuais devem ser checados sob o ponto de vista de usuários do software. As
características de usabilidade que podem ser testadas incluem: prontidão - verificar
fatores ergonômicos e se os usuários podem fazer o que querem e quando querem de
uma forma que seja clara; eficiência - verificar se os usuários podem fazer o que
quiserem com um número mínimo de passos e de tempo; compreensibilidade - verificar
se os usuários entendem a estrutura do produto com a mínima quantidade de esforço.
(DI LUCCA e FASOLINO, 2006; NAIK e TRIPATHY, 2008).
O teste de acessibilidade pode ser considerado um caso particular de teste de
usabilidade cujo objetivo é verificar se o acesso ao conteúdo da aplicação é permitido
mesmo na presença de reduzidas configurações de hardware e software no lado cliente
da aplicação (por exemplo, a configuração de browser desabilitando visualização
gráfica). De modo simplificado, o teste de acessibilidade consiste em verificar se os
usuários podem entrar, navegar e sair da aplicação com relativa facilidade (DI LUCCA
e FASOLINO, 2006; NAIK e TRIPATHY, 2008).
O teste de segurança busca verificar a eficiência da defesa global de um software
contra acesso indesejado de usuários não autorizados, bem como sua capacidade de
preservar seus recursos contra o uso inapropriado e de garantir a concessão de acesso
para usuários autorizados a serviços e recursos permitidos. As vulnerabilidades que
afetam segurança podem estar no código da aplicação ou em qualquer de seus
componentes de hardware ou de software. Os requisitos de segurança que podem ser
testados são: confidencialidade – se os dados e processos estão protegidos contra
divulgações não autorizadas; integridade – se os dados e processos estão protegidos
contra modificações não autorizadas; disponibilidade – se os dados e processos estão
protegidos contra a negação de serviço a usuários autorizados; (DI LUCCA e
FASOLINO, 2006; NAIK e TRIPATHY, 2008).
2.3 Níveis de Teste de Software
Alguns autores, como COLLOFELLO et al. (1996) se referem aos níveis de teste
como sendo fases de teste. Diferentes níveis de teste dinâmico de software devem ser
empreendidos para mostrar que o software sob teste satisfaz todos os seus requisitos
técnicos, funcionais, não funcionais e principalmente mostrar adequação aos propósitos
17
do negócio (DAVIS, 2000). Neste contexto, são identificados quatro níveis diferentes de
testes: teste de unidade, teste de integração, teste de sistema e teste de aceitação.
Os testes são executados em diferentes níveis, nas fases de desenvolvimento do
software (RÉPÁSI, 2009). Segundo DI LUCCA e FASOLINO (2006) os níveis de teste
são um dos aspectos básicos sobre os quais devem se apoiar os testes funcionais das
aplicações de software. Os níveis de teste especificam os diferentes escopos dos testes a
serem executados (as coleções de componentes a serem testados).
O teste de unidade (também referenciado como teste unitário) visa testar a menor
unidade do software, tentando provocar falhas ocasionadas por defeitos de lógica e de
implementação em cada módulo isoladamente. Para COLLOFELLO et al. (1996) o
teste de unidade é o mais bem entendido dentre os níveis de teste e também o que
apresenta mais controvérsia sobre a quantidade de teste de unidade a ser executada, que
difere de projeto para projeto, dependendo de outras atividades de garantia de qualidade
executadas e dependendo da dificuldade de criação de um ambiente de teste de unidade
(conforme a definição da unidade de teste para o projeto).
Normalmente o teste de unidade é o primeiro nível de teste a ser exercitado. O
teste de unidade é executado para verificar cada componente individual da aplicação. A
nível de teste de unidade, a unidade é isolada do restante do software e o teste é feito
com base em sua especificação (RÉPÁSI, 2009). Diferentes tipos de unidade podem ser
identificados para fins de teste de unidade em uma aplicação: programas, módulos,
funções, procedimentos, units, classes, métodos, componentes. Ainda para aplicações
web, outros tipos de unidade podem ser identificados como páginas web, scripts, forms,
applets, servlets ou outros objetos web. O que deve ser considerado no nível de teste de
unidade deve ser analisado conforme o caso. Para aplicações web, a unidade básica que
pode ser testada é a página, já que qualquer outro objeto web deve estar nela inserido
para poder ser executado, embora haja diferenças entre o teste de páginas cliente e o
teste de páginas servidoras (DI LUCCA e FASOLINO, 2006).
Os testes de integração visam provocar falhas associadas às interfaces entre
módulos, quando estes são integrados para construir a estrutura do software que está
sendo construído. O teste de integração considera partes combinadas de uma aplicação
para verificar como elas trabalham juntas e identificar falhas ocasionadas pelo
acoplamento entre tais partes. Quando cada unidade tiver passado nos testes nível de
unidade, a interoperabilidade entre elas tem que ser avaliada. Os testes a nível de
18
integração visam utilizar pelo menos pares de componentes para verificar a sua
interoperabilidade a partir das especificações técnicas (RÉPÁSI, 2009). Um problema
que surge neste nível de teste está relacionado com a definição de estratégias para
integrar unidades de software a serem testadas como um todo. (DI LUCCA e
FASOLINO, 2006).
Segundo McGREGOR e SYKES (2001), em processos de desenvolvimento
iterativos e incrementais, os testes de integração serão executados continuamente, sendo
o plano de testes de integração particularmente importante nesses ambientes.
O teste de sistema visa avaliar o software, buscando falhas por meio da utilização
do mesmo, como se estivesse sendo operado por um usuário final. Para isso ele é
executado no mesmo ambiente operacional e com dados de entrada que um usuário
utilizaria normalmente. Os testes a nível de sistema apresentam a primeira oportunidade
em que se envolve todas as unidades do software (RÉPÁSI, 2009). O teste de sistema
verifica se o produto satisfaz seus requisitos e visa descobrir falhas que sejam do
sistema inteiro e não de seus componentes individuais. Abordagens caixa preta são
geralmente exploradas para efetuar teste de sistema e identificar falhas no
comportamento da aplicação, visível externamente. As estratégias de teste definem
abordagens para projetar casos de teste que podem ser baseadas em responsabilidade
(caixa preta), baseadas em implementação (caixa branca) ou híbridas (caixa cinza). As
técnicas caixa preta são usadas para projetar casos de teste com base na funcionalidade
especificada para o item a ser testado. As técnicas caixa branca são usadas para projetar
casos de teste com base em análise do código fonte ou da arquitetura do software. As
técnicas caixa cinza são usadas para projetar casos de teste para ambas as abordagens,
baseadas em responsabilidades e baseadas em implementação. (DI LUCCA e
FASOLINO, 2006).
Os testes a nível de aceitação se assemelham aos testes a nível de sistema, mas
sob a perspectiva do cliente (RÉPÁSI, 2009). O teste de aceitação é realizado
geralmente por um restrito grupo de usuários finais do software. Neste nível de teste são
simuladas operações de rotina do software para verificar se seu comportamento está de
acordo com o solicitado. O teste de aceitação é o teste de escopo de sistema conduzido
por um cliente para decidir se aceita ou não um software encomendado (BINDER,
2000). Para SOMMERVILLE (2007), o teste de aceitação é a fase final do processo de
testes antes do software ser aceito para uso operacional. O software é testado com dados
19
fornecidos pelo cliente ao invés de dados fictícios de teste. O teste de aceitação pode
revelar falhas e omissões na definição de requisitos porque os dados reais podem
exercitar o software de forma diferente dos dados fictícios de teste.
Para RÉPÁSI (2009), testes de regressão buscam descobrir regressões do
software, as quais podem ocorrer não intencionalmente, mas em consequência de
mudanças feitas no código. NAIK e TRIPATHY (2008) consideram os testes de
regressão como mais um nível de teste, executado ao longo do ciclo de vida do software
sempre que um componente é modificado, para garantir que a modificação não
introduza novos defeitos nas partes que não foram modificadas. Posteriormente,
reconsideram e afirmam que, de modo mais apropriado, os testes de regressão não
representam mais um nível de teste, mas uma subfase dos níveis de teste de unidade, de
integração ou de sistema. De fato, a necessidade de re-execução dos testes pode
acontecer em qualquer nível de teste, independentemente. Argumentam ainda NAIK e
TRIPATHY (2008), que em testes de regressão, novos testes não são projetados (para
reduzir custos), mas selecionados e priorizados para execução a partir do conjunto de
testes disponíveis, assegurando que defeitos não sejam introduzidos em uma nova
versão do software. A idéia central dos testes de regressão é verificar se algum defeito
foi introduzido nas partes não modificadas do software, em decorrência de mudanças
feitas em uma determinada parte dele para remover alguma falha revelada pelos testes
anteriormente executados. E a princípio, isto pode ocorrer em qualquer nível de teste.
2.4 Modelos de Teste de Software
Para DI LUCCA e FASOLINO (2006) os modelos de teste de software são um
dos aspectos básicos sobre os quais devem se apoiar os testes funcionais das aplicações
de software. Um modelo de teste de software representa os relacionamentos entre
elementos de uma representação ou de uma implementação de um componente de
software.
2.4.1 O Modelo em Cascata
O modelo em cascata tem sido popularmente empregado para testes em projetos
de software. Entretanto, este modelo é utilizado em muitos projetos, devido à idéia
incorreta de que os testes começam com a entrega do código e não são considerados
parte importante do ciclo de vida de desenvolvimento de software. Muitas vezes a
20
aplicação do modelo cascata não traz resultados satisfatórios por causa da atenção tardia
que é dada às atividades de teste. Quando fases anteriores do processo de
desenvolvimento ultrapassam os prazos para elas estabelecidos, em geral é a fase de
testes que sofre com a redução de seu prazo originalmente alocado, numa tentativa de
recuperação dos prazos do projeto, o que pode levar a uma quantidade limitada de testes
sendo executados, podendo afetar a qualidade final do produto [Davis, 2000].
Na Figura 2-2 que se segue, adaptada de DAVIS (2000), pode-se visualizar a
posição das atividades de teste no final do ciclo de vida de desenvolvimento de
software.
Figura 2-2 – Modelo em Cascata (Adaptado de Davis, 2000)
Se os testes são considerados como avaliação da qualidade do software, então, de
acordo com o modelo em cascata, todo o controle de qualidade é executado ao final do
processo de desenvolvimento. Isto não é uma condição aceitável, porque, conforme uma
idéia que já é geralmente aceita por profissionais e estudiosos de engenharia de
software, quanto mais tarde no ciclo de vida de desenvolvimento de software os erros e
faltas são encontrados, mais caro se torna sua correção. Uma falha no código revelada
durante os testes, que esteja relacionada com faltas na especificação de requisitos do
Modelo em Cascata
Especificação de programa
Requisitosdo usuário
Especificação técnica
Código
Testes
Especificação funcional
21
usuário pode levar a uma grande quantidade de retrabalho para se consertar os artefatos
já produzidos.
2.4.2 O Modelo em V
O modelo em V pode ser visto como uma evolução do modelo em cascata, no
sentido de que para cada nível de análise há um nível de síntese que pode ser
identificado nas fases de teste pelas quais passa o software em teste, na medida em que
ele avança no que está representado no lado direito do “V”. Em associação com a
especificação de programas, está a execução dos testes de unidade. A especificação
técnica se associa com a execução dos testes de integração. A especificação funcional,
se associa com a execução dos testes de sistema. Em associação com a especificação de
requisitos do usuário, há a execução dos testes de aceitação.
A Figura 2-3, adaptada de DAVIS (2000), apresenta uma visualização do
modelo em V, mostrando as associações das fases de síntese do software que estão do
lado direito, com as fases de análise do software, que estão do lado esquerdo do modelo.
Figura 2-3– Modelo em V (Adaptado de Davis, 2000)
Pacote deTeste de
Aceitação
Modelo em V
Pacote deTeste deSistema
Pacote deTeste de
Integração
Pacote deTeste deUnidade
Código
Teste deAceitação
Teste deSistema
Teste deIntegração
Teste deUnidade
SínteseAnálise
Especificação de programa
Requisitosdo usuário
Especificação funcional
Especificação técnica
22
O modelo em V enfatiza que a construção dos pacotes de teste deve ser feita
durante o desenvolvimento do software e não apenas ao seu final. Os testes não
começam com a entrega do código como se supõe com o modelo em cascata, mas com a
entrega da documentação que serve de fonte para as atividades de teste (requisitos do
usuário, especificações funcional, técnica e de programa conforme o modelo em V
mostrado na Figura 2-3 acima).
Para DAVIS (2000) o teste estático da documentação é tão importante quanto o
teste dinâmico do código e tem um custo-benefício mais significativo para remover
defeitos mais cedo no processo de desenvolvimento, podendo evitar retrabalho. O teste
estático a que DAVIS (2000) se refere é a revisão da documentação, sendo que é
recomendada a revisão 1, 2 e 3.
A idéia da revisão 1, 2 e 3 engloba revisão tipo 1, revisão tipo 2 e revisão tipo 3.
A revisão tipo 1 é interna ou seja, com foco no interior do artefato sendo revisado e
busca assegurar que este artefato está construído respeitando-se os padrões adotados e
contem as características que dele se espera. Em outras palavras, visa assegurar que o
produto é internamente consistente, acurado (correto em nível de detalhe) e completo.
Por exemplo, uma especificação funcional deve conter tudo o que nela normalmente se
inclui (que pode variar de uma organização para outra) e deve estar livre de incorreções,
inconsistências, ambiguidades e omissões.
A revisão tipo 2 é externa, e voltada para artefatos produzidos em fases
anteriores àquela em que foi produzido o artefato que está sendo revisado. DAVIS
(2000) considera que a revisão tipo 2 é um processo de teste para verificar se o produto
sendo revisado está em conformidade com os requisitos especificados pelos artefatos
produzidos na fase imediatamente anterior do processo, e também se está em
conformidade com os requisitos do usuário.
A revisão tipo 3 é também externa e voltada para os artefatos que vão ser
produzidos em seguida, buscando verificar se o artefato sendo revisado contem
informações suficientes para prosseguir com os trabalhos que vão produzir os artefatos
da próxima fase do processo de desenvolvimento do software.
DAVIS (2000) destaca que a revisão 1, 2 e 3 aplicada ao modelo em V, pode
apoiar fortemente o processo de desenvolvimento do software, no sentido de que muitos
problemas que podem estar inseridos na documentação fonte, são tratados mais cedo no
ciclo de vida de desenvolvimento do software e não são transportados para o código.
23
Uma alternativa ao modelo em V é o modelo em W que é apresentado por
RÉPÁSI (2009). Outros modelos (modelo em H, modelo em X, modelo tipo borboleta,
dentre outros) são referenciados por LIANG et al. (2005). Tais modelos não serão
tratados nesta pesquisa.
2.5 Processos de Teste de Software
Os processos de teste de software são um dos aspectos básicos sobre os quais
devem se apoiar os testes funcionais das aplicações de software. Eles definem o fluxo
de atividades de teste, e outras decisões como quando os testes devem ser iniciados,
quem deve executar os testes, quanto de esforço deve ser utilizado para testes, além de
outras questões similares (DI LUCCA e FASOLINO, 2006).
Teste de software pode ser descrito como um processo e deve ser encarado como
um processo. O propósito do processo de testes de software é prover informação para
assegurar a qualidade do produto. É interessante que se estabeleça um processo genérico
de teste que se aplique a cada um dos níveis de teste dinâmico e a outros tipos de teste
como testes estáticos, análise estática, e análise dinâmica (HASS, 2008).
DAVIS (2000) considera que para um software ser efetivamente testado, o
processo de teste deve, basicamente, mostrar que o software está em conformidade com
os requisitos e que o risco de falha está em um nível aceitável, já que não é viável que
esse risco seja totalmente eliminado.
Nas subseções seguintes, são apresentadas descrições sucintas de alguns
processos genéricos de teste de software encontrados na literatura.
2.5.1 Processo Genérico de Davis
DAVIS (2000) apresenta um processo genérico de testes, como sendo adequado
para ser aplicado a todos os projetos de teste de software. Este processo genérico
contém quatro fases de teste: análise, projeto, cronograma e execução e avaliação. A
fase de análise diz respeito a “o quê” testar; a fase de projeto diz respeito a “como”
testar; a fase de cronograma diz respeito a “quando” testar; a fase de execução e
avaliação diz respeito a “o que aconteceu com os testes”. A Figura 2-4 abaixo, adaptada
de DAVIS (2000), serve para dar uma visão do processo genérico de teste proposto.
24
Figura 2-4 – Processo Genérico de Teste (Adaptado de Davis, 2000)
A fase de análise do processo genérico de testes compreende um subprocesso
que estabelece o escopo do esforço de teste através de uma hierarquia funcional
compreendendo as condições de teste do software a ser testado, e também identifica a
importância relativa das condições de teste e as referencia de volta à documentação
fonte. A fase de análise engloba quatro produtos. O primeiro produto são os documentos
fonte (como requisitos de usuários, especificação funcional), que definem o software
sob teste. Esses documentos fonte são usados para derivar uma hierarquia de funções e
os casos de teste. O segundo produto é a hierarquia funcional, derivada dos documentos
fonte, criada através da quebra do sistema sob teste em funções de negócio de alto nível.
O nível de quebra funcional depende do nível de teste sendo considerado: para teste de
unidade (e de integração), uma função típica pode ser um programa ou módulo dentro
de um programa; para teste de sistema uma função típica pode ser um evento elementar
de negócio; para teste de aceitação uma função típica pode ser um processo de negócio.
O terceiro produto são os casos de teste, elaborados em associação com as funções do
software. Segundo DAVIS (2000), casos de teste são regras específicas que uma função
deve atender para ser considerada conforme com o propósito a ela atribuído. A cada
caso de teste é atribuída uma prioridade que estabelece a importância relativa de cada
caso de teste. Esta priorização é usada para direcionar efetivamente os esforços de teste.
O quarto produto é a referência cruzada das funções e dos casos de teste para os
Processo Genérico de Teste
Análise Projeto Cronograma Execução
Documentação fonte
Referência funcional
Casosde teste
Especificação de teste
Procedimentosde teste
Casos programados
Suitede teste
Procedimentos programados
Casos referenciados
Logsde teste
Casostestados
25
documentos fonte que os derivaram, viabilizando a rastreabilidade e a análise de
impacto entre tais elementos. A análise de impacto permite estimar o impacto de uma
mudança nos artefatos de teste, dada uma mudança na documentação fonte que define o
software sob teste. Além disso, a análise de impacto pode apoiar o diagnóstico de erros
e a determinação da extensão em que os requisitos foram satisfeitos.
A fase de projeto documenta o estímulo e os resultados esperados para
demonstrar que os casos de teste foram satisfeitos. O principal objetivo do projeto é
criar procedimentos de teste detalhados para exercitar os casos de teste de modo
eficiente. A fase de projeto pode ser a que mais consome esforços dentro do processo de
testes. Por isto, deve-se elaborar os procedimentos de teste buscando alcançar a maior
cobertura possível de casos de teste com a mínima quantidade de dados de teste. Isto
pode levar a uma economia de esforços não apenas na fase de projeto, mas também na
fase de execução dos testes, já que os testadores terão menor quantidade de
procedimentos para executar. DAVIS (2000) descreve dois produtos na fase de projeto
de teste. O primeiro produto são as especificações de teste que encerra os casos de teste
agrupados fisicamente por algum critério (por exemplo, agrupamento orientado a fluxo
ou agrupamento orientado a dados) podendo conter também requisitos de ambiente que
devem estar satisfeitos antes de os testes começarem a ser executados. O segundo
produto são os procedimentos de teste detalhados, contendo os dados que o testador terá
que dar entrada no software sob teste, e os resultados esperados a serem verificados. De
modo sucinto, os procedimentos de teste são além de instruções para o testador, um
registro do que deve ser testado e como deve ser testado. Isto leva a uma lista de casos
programados.
A fase de cronograma mostra a seqüência em que os procedimentos de teste
devem ser executados. DAVIS (2000) apresenta dois produtos da fase de cronograma. O
primeiro é a suíte de testes e o segundo a referência cruzada de procedimentos de teste
para suítes de teste. Suíte de teste é um termo arbitrário e normalmente dependente do
tempo que deve representar os marcos de teste para os quais relatórios de progresso
serão requeridos (DAVIS, 2000). BINDER (2000) define suíte de teste como uma
coleção de seqüências de casos de teste que servem a uma meta particular de teste para
uma versão particular de uma implementação sob teste. Dependências são incorporadas
ao conjunto de suítes de teste e de procedimentos de teste para descrever uma ordem de
execução tanto para as suítes de teste quanto para os procedimentos de teste dentro de
26
cada suíte. Uma vez estabelecida a ordem das suítes de teste, a ordem na qual os
procedimentos de teste devem ser exercitados dentro de cada suíte de teste deve ser
documentada. Deste modo, se algum procedimento de teste falhar, o impacto daquela
falha pode ser estabelecido e os procedimentos de teste relacionados podem ser
designados para reteste.
A fase de execução e avaliação inclui registro e gerenciamento dos resultados de
teste. Esta fase pode começar depois que o material de teste para o nível que está sendo
considerado estiver pronto e depois que o software for disponibilizado para o ambiente
de teste. DAVIS (2000) descreve dois produtos da fase de execução e avaliação. O
primeiro produto é o log de testes, que deve ser criado a cada vez que um procedimento
de teste é executado. O log de testes deve conter data e hora em que o procedimento de
teste foi executado, uma declaração sobre sucesso ou falha do procedimento, uma
observação dizendo se o procedimento deve ser re-executado e uma referência a
qualquer problema que tenha surgido. O segundo produto é o estado dos casos de teste
exercitados que deve ser atualizado para refletir o resultado da execução, podendo ser
“testado e aprovado” ou “testado e com falha”, podendo ainda em algumas situações
haver o estado “não possível de ser testado por falta de recursos de teste” ou “não
possível de ser testado por falta de software”. Casos de teste “com falha” devem estar
referenciados em algum relatório de problemas.
Os pacotes de teste mostrados na Figura 2-3 contém em sua formação: uma lista
da documentação fonte que foi utilizada e que define o software sob teste no nível
considerado; a hierarquia funcional e os casos de teste a ela associados, categorizados
por risco e prioridade respectivamente, junto com referência cruzada para a
documentação fonte; a hierarquia das especificações de teste e os procedimentos de
teste associados com referência cruzada para os casos de teste; e o cronograma de
execução dos testes.
Uma questão que surge ao se observar a Figura 2-3 (modelo em V): quando é o
momento de passar de um nível de teste para outro nível de teste dinâmico? Em outras
palavras: quando se deve terminar um nível de teste e começar o próximo nível de teste
dinâmico? A resposta vem através de critérios de entrada e saída dos níveis de teste. O
teste de unidade é o primeiro que deve ser executado após a codificação. O critério de
entrada para o teste de unidade inclui a entrega do pacote de teste de unidade, a entrega
do código e a entrega do ambiente de teste de unidade. O critério de saída para o teste
27
de unidade é o teste bem sucedido do pacote de teste de unidade. Passando este
raciocínio um nível acima, o critério de entrada para o teste de integração inclui a
entrega do pacote de teste de integração, a entrega do código, a entrega do ambiente de
teste de unidade, e também o teste bem sucedido do pacote de teste de unidade. O
critério de saída para o teste de integração é o teste bem sucedido do pacote de teste de
integração. Pode ser observado que o critério de saída de um nível de teste forma parte
do critério de entrada do nível seguinte. A progressão de um nível de teste para outro
deve ser possível mesmo que haja falhas detectadas em associação com casos de teste
de baixa prioridade, pois pode ser que tais falhas não sejam consideradas significativas
o bastante para retardar os testes.
No lado da análise do modelo em V (lado esquerdo da Figura 2-3) há duas
entregas da revisão tipo 3 (vide revisão 1, 2 e 3 tratada na seção 2.4.2): o pacote de teste
e a documentação para o próximo nível. Por exemplo, as entregas da revisão tipo 3 para
requisitos do usuário é o pacote de teste de aceitação e a especificação funcional. As
entregas da revisão tipo 3 são ponto de controle de qualidade para o lado da análise
(lado esquerdo) do modelo em V. No lado da síntese (lado direito da Figura 2-3) os
pontos de controle de qualidade são os critérios de saída de cada nível de teste.
2.5.2 Processo Genérico de Hass
HASS (2008) descreve um processo genérico de teste de software a partir de uma
definição de entradas, uma lista de atividades e uma definição de saídas. As entradas,
atividades de teste e saídas apresentadas por HASS (2008) para este processo genérico
estão registradas na Tabela 2-1.
Tabela 2-1 Entradas, Atividades e Saídas do Processo Genérico de HASS (2008)
Entradas Atividades SaídasEstratégia de teste Planejamento inicial de testes Plano específico de teste
Plano do projetoMonitoramento, controle e re-planejamento de testes Especificação de teste
Plano mestre de teste,Projeto e desenvolvimento dos testes
Especificação de ambiente de teste
Informação de progresso dos testes Execução dos testesAmbiente real de teste, incluindo os dados de teste
Avaliação e relato de testes Logs de testeFechamento das atividades de teste Relatórios de progresso
Relatório resumo dos testesRelatório de experiência dos testes
28
As atividades de monitoramento, controle e replanejamento devem ser
constantes. Monitoramento deve ser contínuo. Controle e replanejamento devem ser
feitos conforme a necessidade. O processo proposto por HASS (2008) é iterativo, com
execução das atividades por mais de uma vez antes que o critério de saída seja atendido.
A Figura 2-5 mostra as iterações a serem previstas no processo genérico de HASS
(2008).
Figura 2-5 – Processo Genérico Iterativo de Testes (Adaptado de HASS, 2008)
A primeira atividade a partir da qual a iteração pode ocorrer é a execução dos
testes, pois é a partir dela que falhas são reveladas. As possíveis iterações podem
ocorrer:
1. quando o defeito que levou à falha é corrigido no objeto de teste, o
procedimento de teste que revelou a falha deve ser re-executado, podendo também ser
executado algum conjunto de testes de regressão.
2. quando o defeito que levou à falha é corrigido no procedimento de teste, o
novo procedimento corrigido deve ser executado. Esta iteração normalmente leva ao
retorno à atividade de projeto e desenvolvimento dos testes.
Projeto e desenvolvimento
dos testes
Planejamentoinicial de testes
Monitoramento,
controle e
re-planejamento
de testes
Execução dos testes
Avaliação erelato de testes
Fechamento das atividades de teste
Correçãodo objetode teste
2
1 3 4
29
A segunda atividade a partir da qual a iteração pode ocorrer é a avaliação e
relatório de testes, pois é a partir dela que se pode depreender se os critérios de saída
foram ou não atendidos. Neste caso, dentre as possíveis iterações que podem ocorrer
tem-se:
3. mais casos de teste devem ser especificados para aumentar a cobertura de
testes, e portanto devem ser executados.
4. os critérios de saída podem sofrer adequações no plano de testes.
Cada atividade do plano genérico de testes de HASS pode ser considerado um
subprocesso que pode ser descrito do mesmo modo que o processo global de testes,
devendo incluir no mínimo uma definição das entradas, uma lista de atividades e uma
definição das saídas, podendo além destas, incluir outras informações que sejam
interessantes para o subprocesso. HASS (2008) descreve um subprocesso para cada uma
das seis atividades listadas para o processo genérico de testes. Nas descrições de cada
um destes subprocessos, o propósito e a lista de atividades sugeridas são apresentados.
O subprocesso associado à atividade de planejamento inicial de testes tem como
propósito verificar a missão dos testes, definir os objetivos dos testes e as decisões
necessárias para transformar a estratégia de teste em um plano operacional para
execução real. O subprocesso associado às atividades de monitoramento, controle e re-
planejamento de testes tem como propósito manter o controle e fazer as correções
necessárias no plano de testes, quando ele não mais refletir a realidade na medida em
que as atividades de teste são executadas e os testes progridem. O subprocesso
associado à atividade de projeto e desenvolvimento dos testes tem como propósito
projetar e escrever testes que alcancem a maior cobertura possível para atender o plano
de testes, bem como definir detalhadamente e estabelecer o ambiente de teste. Este
subprocesso envolve um trabalho altamente iterativo. Estes subprocessos podem ter em
sua lista de subatividades sugeridas as indicadas na Tabela 2-2.
Tabela 2-2 Subativiades Sugeridas para Planejamento Inicial, Monitoramento Controle e Replanejamento e Projeto e Desenvolvimento dos Testes (HASS, 2008)
Para Planejamento InicialPara Monitoramento,
Controle e ReplanejamentoPara Projeto e
DesenvolvimentoVerificação da missão dos testes Coleta de medições Entender a base de testeDefinição dos objetivos dos testes, inclusive cobertura, Análise de medições
Definir a estrutura da especificação de teste
Descrição da abordagem de teste Continuação do avanço dos Identificar as condições de teste
30
Para Planejamento InicialPara Monitoramento,
Controle e ReplanejamentoPara Projeto e
Desenvolvimentotestes
Construção de uma estrutura analítica de testes Revisão de estimativas
Selecionar as técnicas de teste de acordo com a abordagem especificada no plano
Identificação das entregasImplementação de ações corretivas conforme necessidade
Identificar defeitos na base de testes (ex. requisitos)
Estimativa das atividadesComunicação com os interessados Reportar defeitos identificados
Elaboração de orçamento Comunicação com as equipesDesenvolver casos de teste detalhados
Especificação de recursos, inclusive necessidades de treinamento Re-delegação de tarefas Identificar dados de testeDelegação de tarefas Motivação das equipes Comunicar com os interessadosIdentificação de necessidades de ambiente Treinamento das equipes Especificar ambiente de testesEspecificação das métricas necessárias
Participação em atividades de melhoria de processos
Registrar rastros para a base de testes
Identificação dos interessados Auto-aprendizagem Registrar cobertura de testesCoordenação com os interessados
Gerência de configuração de documentos do plano de testes
Realimentar o monitoramento de testes
Elaboração de cronograma Monitorar os testadores junioresDocumentação das decisões no plano de testes Avaliar as ferramentasMotivação das equipes Estabelecer o ambiente de testesComunicação com os interessados
Extrair e possivelmente criar de dados de testePopular as bases de dados de testeGerenciar a configuração dos artefatos de teste
O subprocesso associado à atividade de execução dos testes tem como propósito a
execução real dos testes no ambiente apropriado e registrar esta execução bem como os
resultados. O subprocesso associado à atividade de avaliação e relato de testes tem
como propósito assegurar que o objetivo dos testes, incluindo a cobertura alvo tenham
sido alcançados, além de comunicar os resultados dos testes de maneira que sejam
inteligíveis e úteis para os interessados. O subprocesso associado à atividade de
fechamento das atividades de teste tem como propósito fazer a limpeza após o término
dos testes e guardar ativos físicos de valor e informações relevantes para a organização.
Estes subprocessos podem ter na sua lista de atividades sugeridas aquelas indicadas na
Tabela 2-3.
31
Tabela 2-3 Subatividades Sugeridas para Execução, Avaliação e Relato e Fechamento das Atividades de Teste (HASS, 2008)
Para Execução Para Avaliação e Relato Para Fechamento Recepção do objeto de teste Checagem dos resultados contra
os objetivos (p.e. cobertura alcançada e estimativa de defeitos remanescentes),
Descarte de ambientes de teste desnecessários, inclusive dados de teste
Testes exploratórios
Realimentação para o monitoramento
Armazenamento seguro de artefatos de teste a serem mantidos (gerência de configuração),
Execução de teste fumaça (prontidão)
Produção de relatórios para os interessados Entrega dos artefatos de teste
Elaboração de seqüência de execução dos testes (procedimento detalhado)
Execução de reunião de retrospectiva
Execução dos testesIdentificação de possibilidades de melhoria de processo
Análise das observaçõesComunicação com os interessados
Log do curso de execução dos testesRelato de incidentes, inclusive os encontrados nos artefatos de testeTeste de confirmaçãoComunicação com os interessadosEspecificação de necessidade de testes de regressãoTestes de regressãoComunicação com os interessadosManutenção do ambiente de testesReconstituição do ambiente de teste ao estado original (esp. dados de teste)Monitoramento, treinamento e capacitação de testadores júniorMonitoramento, treinamento e capacitação de não-testadores (usuários ou outros participantes da execução dos testes)Realimentação do monitoramento dos testesGerência de configuração dos artefatos de teste
Com se pode observar, HASS (2008) referencia cada macro-atividade do processo
genérico iterativo de testes representado na Figura 2-5, também como um subprocesso
composto de subatividades sugeridas.
32
2.6 Um Processo Padrão de Teste de Software
Um processo genérico ou padrão de testes deve estar presente no desenvolvimento
de software e as organizações devem ser capazes de moldá-lo para satisfazer cada nível
de teste dinâmico [Davis, 2000].
DIAS NETO e TRAVASSOS (2006) propõem um processo de teste de software
que no contexto deste trabalho será adotado como processo padrão de testes, e que é
composto por dois subprocessos: um subprocesso de planejamento e um subprocesso de
execução dos testes. Os artefatos de teste incluídos no processo proposto são sete
documentos definidos pelo padrão IEEE Standard 829-1998 (1998): Plano de Teste,
Especificação do Projeto de Teste, Especificação de Casos de Teste, Especificação de
Procedimentos de Teste, Histórico dos Testes, Relatório de Incidente de Teste e
Relatório de Resumo de Teste. O processo de testes de software possui três papéis:
gerente de teste, projetista de teste e testador. O subprocesso de planejamento dos testes
é composto por 4 macro-atividades: Planejar Teste, Projetar Teste, Especificar Casos de
Teste e Definir Procedimentos de Teste. As atividades desse subprocesso produzem, ao
final, os seguintes documentos: Plano de Teste, Especificação do Projeto de Teste,
Especificação de Casos de Teste e Especificação de Procedimentos de Teste. O
subprocesso de Execução dos Testes é composto por 2 macro-atividades: Executar
Testes e Analisar Resultados. Ao final deste subprocesso serão produzidos os seguintes
documentos: Histórico dos Testes, Relatório de Incidente de Teste e Relatório de
Resumo de Teste. A Figura 2-6 e a Figura 2-7, adaptadas de DIAS NETO e
TRAVASSOS (2006) mostram os elementos constituintes do processo de teste que eles
propõem.
Figura 2-6 – Processo Padrão – Subprocesso de Planejamento (Dias Neto e Travassos, 2006)
33
Figura 2-7 – Processo Padrão – Subprocesso de Execução (Dias Neto e Travassos, 2006)
O processo genérico proposto por DAVIS (2000) é descrito através de uma
representação orientada a produto de trabalho ou artefatos de teste, de modo diferente
dos outros dois processos que são descritos através de uma representação orientada a
atividades. Analisando-se os produtos de trabalho ou artefatos envolvidos no processo
genérico de DAVIS (2000), verifica-se que o mesmo é aderente aos outros processos
apresentados se observadas as descrições de seus subprocessos com respectivas
subatividades e produtos de trabalho. As diferenças ficam apenas nos níveis de detalhe
dos artefatos produzidos. Sendo assim, será estabelecida aqui uma comparação entre o
processo genérico de HASS (2008) com o processo padrão proposto por DIAS NETO e
TRAVASSOS (2006), através das atividades descritas por seus autores.
Fazendo-se uma comparação entre as atividades dos dois processos de teste
apresentados, o processo genérico de testes proposto por HASS (2008) e o processo
padrão proposto por DIAS NETO e TRAVASSOS (2006), é obtida a Tabela 2-4.
Tabela 2-4 – Atividades dos Processos de Teste Apresentados
Processo Genérico [Hass, 2008]
Processo Padrão[Dias Neto e Travassos, 2006]
Planejamento inicial de testes Planejar TesteProjeto e desenvolvimento dos testes Projetar TesteProjeto e desenvolvimento dos testes Especificar Casos de Teste Projeto e desenvolvimento dos testes Definir Procedimentos de Teste.Execução dos testes Executar TestesAvaliação e relato de testes Analisar ResultadosMonitoramento, controle e re-planejamento de testesFechamento das atividades de teste
Apesar de não haver no processo padrão proposto por DIAS NETO e
TRAVASSOS (2006) atividades específicas para se fazer associação com as atividades
34
de Monitoramento, controle e re-planejamento de testes e Fechamento das atividades de
teste, que estão explicitadas no processo de HASS (2008), pode-se observar que o
processo padrão de DIAS NETO e TRAVASSOS (2006) considera tais atividades. Este
processo padrão inclui documentação que permite o controle dos testes, com uma
comparação entre o que foi planejado e o que ocorreu efetivamente durante os testes,
através do registro das tarefas e dos resultados obtidos. Um dos atributos da ferramenta
de apoio associada ao processo padrão proposto por DIAS NETO e TRAVASSOS
(2006) é possibilitar o controle dos testes através da visualização de gráficos que
indicam o andamento e os resultados dos testes. Na arquitetura da ferramenta de apoio
apresentada, está explicitado um Gerenciador de Processo de Teste que inclui a
atividade “Controlar Processo de Testes”. O processo padrão especifica também o papel
do Gerente de Teste, que é a pessoa responsável pelo planejamento e controle dos testes.
Quanto ao fechamento das atividades de teste, apesar de não explicitada como no
processo de HASS (2008), no processo proposto por DIAS NETO e TRAVASSOS
(2006) demonstra-se a preocupação com tal fechamento, tendo em vista o
armazenamento de todos os dados gerados ao longo dos testes, para permitir a qualquer
momento a consulta a esses dados, para apoiar a realização de novas atividades de teste.
A solução proposta neste trabalho deverá considerar o atendimento a processos de
teste de software semelhantes aos descritos por DIAS NETO e TRAVASSOS (2006)
com seus subprocessos de planejamento e de execução dos testes. O processo de testes
proposto por DIAS NETO e TRAVASSOS (2006) já foi, e vem sendo adotado em
diversos projetos de software da Fundação Coppetec, ligada ao Instituto Alberto Luiz
Coimbra de Pós-graduação e Pesquisa em Engenharia da Universidade Federal do Rio
de Janeiro. Tal processo será utilizado como padrão no contexto deste trabalho de
pesquisa.
2.7 Os Testes de Software e as Metodologias Ágeis
Praticamente todas as metodologias ágeis valorizam os testes, como um fator de
segurança e confiança da equipe, por servir de ponto de equilíbrio para compensar a
redução do rigor de seus processos de desenvolvimento na busca por agilidade.
Entretanto, não se observa na literatura sobre abordagens ágeis para processos de
software, preocupações específicas relacionadas com o processo de teste de software.
Ainda assim, LINDVALL et al. (2002) enfatizam que os testes de software constituem
35
uma questão fundamental para as metodologias ágeis, reforçando a idéia de que
esforços devem ser despendidos para mais pesquisas nessa direção. O tratamento que é
dado às atividades de teste difere um pouco de método para método ágil. A seguir são
apresentadas algumas idéias sobre como os testes são considerados em algumas
metodologias individuais.
Na metodologia Crystal (COCKBURN, 2002), o produto é construído em
incrementos e há previsão de testes em cada incremento. É dada ênfase aos testes de
regressão automatizados.
Um dos princípios da metodologia DSDM (STAPLETON, 1997) estabelece que
os testes devem ser integrados ao longo de todo o ciclo de vida do software. Na DSDM
não há fase de testes. Os produtos devem ser testados em todos os estágios de
desenvolvimento, por testadores e usuários, de modo incremental e iterativo. Na ordem
de prioridades, primeiro devem ser testadas as partes que entregam valor-chave para o
cliente.
Na metodologia DSDM, durante as iterações de modelagem funcional, os itens
são testados continuamente à medida em que são produzidos; há foco pesado no teste de
usabilidade, e os aspectos não-funcionais freqüentemente têm pouca ênfase. Já durante
as iterações de projeto e construção, há testes contínuos para que os componentes
possam alcançar qualidade adequada para liberação; nesta fase são realizados testes não
funcionais (desempenho, stress, e outros). Os testes devem ser feitos dentro de cada
fatia de tempo (time-box) e antes que ela expire. Testes de unidade devem ser feitos
amplamente em todo o software. Um teste final de sistema deve acontecer. Os testes
devem servir de instrumento para conquista de confiança entre os membros da equipe,
encontrando erros e corrigindo-os.
Na metodologia FDD – Feature Driven Development - (PALMER e FELSING,
2002), o testador pode fazer parte do projeto ou pertencer a um grupo externo. O teste
de integração é feito por feature e há um testador para cada equipe. Os casos de teste
são originados na lista de features. Cada testador responde por um conjunto completo de
features e não apenas por features individuais.
A metodologia XP (BECK, 1999; BECK e ANDRES, 2004), dá muita ênfase a
testes de unidade, sendo os testes de aceitação escritos pelo cliente. O cliente escreve as
histórias, que são representadas de modo análogo à representação de requisitos através
36
de casos de uso. De acordo com uma das práticas de XP, (TDD - Test-Driven
Development) os testes de unidade devem ser escritos antes do código.
Para MARTIN (1998) os testes são altamente valorizados na metodologia dX.
Os casos de uso são particionados em unidades testáveis e então os desenvolvedores
alternam-se entre escrever casos de teste e escrever código de produção. Os testes e os
códigos de produção evoluem juntos e ao mesmo tempo. Os testes devem ser escritos
antes do código. Na descrição da metodologia dX, MARTIN (2002) apresenta ou
menciona os testes de aceitação e os testes de unidade. Segundo MARTIN (2002),
modelos são construídos para se verificar se algo funciona. Isto implica que os modelos
devem ser testáveis e não faz sentido construir modelos se não há critérios que possam
ser a eles aplicados para testá-los. Se um modelo não pode ser avaliado, então ele não
tem valor. Na metodologia dX os testes de aceitação são escritos no início de cada
iteração, junto com o cliente, para as histórias de usuário selecionadas para
implementação. Estes testes são entregues aos programadores e servem como
documentação de detalhes dos requisitos. Os testes são escritos primeiro, antes do
código de produção ser escrito. Os testes de unidade são escritos em grandes
quantidades, antes do código a eles associado. A regra é não escrever código antes que
um teste de unidade falhe. Todo código é escrito para fazer com que um teste de
unidade passe.
Em geral as abordagens ágeis valorizam os testes de software como um dos
caminhos para equilibrar a leveza dos respectivos processos e oferecer uma
compensação para se alcançar um pouco mais de confiança no desenvolvimento ágil.
Contudo, cada método apresenta diferentes níveis de detalhe sobre as atividades de
teste.
As práticas de software adotadas nos processos de desenvolvimento podem
influenciar no processo de testes, mesmo aquelas práticas que não estão diretamente
associadas com alguma atividade do processo de testes. Por exemplo, a Implantação
diária que é descrita como a prática de colocar código novo em produção todas as
noites, não referencia diretamente qualquer atividade de teste. Contudo, não faria
sentido colocar código em produção sem testar, pois estaria contrariando os objetivos de
qualidade almejados para o software desenvolvido com a metodologia ágil que
recomendou a prática.
37
Algumas práticas estão diretamente relacionadas com testes, como se pode
depreender da simples observação de suas descrições que referenciam explicitamente o
processo de testes ou alguma de suas atividades. Pode-se observar também, que há
algumas dessas práticas em que os testes são o seu fundamento (ou sua essência),
enquanto que para outras práticas os testes são subsidiários, embora referenciados
explicitamente em suas descrições.
Exemplos de práticas nas quais os testes são o seu fundamento podem ser a
prática de executar testes ao longo do ciclo de vida e a prática de desenvolvimento
orientado a testes (BECK, 1999; BECK e ANDRES, 2004).
Teste ao longo do ciclo de vida – esta prática parte da consideração de que com
rígidas restrições de tempo, as atividades de teste tendem a ser negligenciadas se
deixadas para o final do projeto. Daí, componentes de software devem ser testados pelos
desenvolvedores e usuários à medida em que são desenvolvidos. O teste deve ser
incremental, e os testes de regressão devem ser particularmente enfatizados por causa
do estilo evolucionário de desenvolvimento.
Desenvolvimento orientado a testes – test-driven development – esta prática
recomenda que o desenvolvimento de software deve ser guiado por testes. Escreva os
testes antes de escrever o código. Só escreva código após escrever um teste de unidade
que falhe para aquele código. O teste sempre vem primeiro, eliminando projetos
complicados além do normal e possibilitando focar de fato na obtenção do trabalho
feito. Testes de unidade são implementados antes do código e são executados
continuamente e livre de falhas para que o desenvolvimento possa continuar.
Refatoração – com esta prática, os programadores reestruturam o software sem
modificar seu comportamento, para remover duplicações, melhorar comunicação,
simplificar ou adicionar flexibilidade; todos os testes são mantidos rodando. Testes de
unidade automatizados garantem que nada se quebra, permitindo aos programadores
refatorar com confiança. Os programadores devem sempre deixar o código mais limpo
do que o que eles encontraram, melhorar sua performance e sua capacidade de reação
rápida a mudanças.
Código compartilhado – nesta prática, uma vez que o código e seus testes
associados são verificados e incluídos na base de código, o código pode ser alterado por
qualquer membro da equipe. Qualquer programador pode melhorar qualquer código em
qualquer parte do software a qualquer tempo se ele vê esta oportunidade. Esta posse
38
coletiva de código traz para cada membro da equipe o sentimento de ser o dono de toda
a base de código e previne gargalos que poderiam ocorrer se o “dono” de um
componente não estivesse disponível para realizar uma modificação necessária.
2.8 Conclusão
Neste capítulo foram descritos dois processos genéricos de testes: o de DAVIS (
2000) e o de HASS (2008). Foi descrito um processo padrão proposto por DIAS
NETO e TRAVASSOS (2006) que vem sendo adotado nos projetos da Fundação
Coppetec ligada ao Instituto Alberto Luiz Coimbra de Pós-graduação e Pesquisa em
Engenharia da Universidade Federal do Rio de Janeiro, e que será considerado nas
etapas seguintes desta pesquisa para inserir características de agilidade em processos de
teste de software. No capítulo 3 que se segue são apresentados os resultados de um
estudo secundário (revisão sistemática de literatura) realizado para identificar quais são
as características de um processo ágil de software.
39
3. Características de Agilidade em Processos de
Software
Neste capítulo são apresentados os resultados de uma revisão
sistemática de literatura efetuada com a finalidade de identificar as
características dos processos ágeis de desenvolvimento de software.
3.1 Introdução
A redução do ciclo de desenvolvimento de software foi considerada uma das
principais metas dos processos de desenvolvimento de software na década de 1990.
Naquele cenário, AOYAMA (1998) definiu agilidade de processos de software como
sendo a capacidade de se adaptar com rapidez a mudanças nos requisitos e nos
ambientes que envolvem o software. AOYAMA propôs um processo ágil, derivado de
experiências com desenvolvimento concorrente e distribuído, de lições aprendidas nas
fábricas de software japonesas e de conceitos de processos de construção de hardware.
Daí foi “cunhada” a idéia de processo ágil de software, significando não apenas
desenvolvimento rápido de aplicações, mas principalmente a capacidade de adaptação
rápida e flexível a mudanças em processos, produtos e ambientes.
Os métodos ágeis propõem uma maneira alternativa de olhar para o
desenvolvimento de software, focando a atenção para interações entre pessoas
colaborando para alcançar alta produtividade. Do mesmo modo que os métodos
convencionais, os métodos ágeis têm como meta construir software de alta qualidade
que atenda as necessidades dos usuários (SATO et al. 2006). BOEHM e TURNER
(2003, 2004) entendem que os métodos ágeis prometem satisfação do usuário em alto
grau, taxas de defeitos mais baixas, desenvolvimento de software mais rápido e uma
solução para mudanças rápidas nos requisitos. Contudo, não há definição
universalmente aceita para métodos ágeis na área de engenharia de software (CONBOY
e FITZGERALD, 2004). Em um trabalho mais recente, CONBOY (2009) propõe um
significado para a agilidade no contexto de desenvolvimento de software. Este
significado foi obtido de uma análise conceitual mais bem elaborada, a partir da qual a
40
definição de agilidade no contexto de desenvolvimento de software foi apurada através
da consideração dos componentes que apóiam dois conceitos fundamentais associados
com a agilidade: flexibilidade e leanness. Após 16 iterações examinando os
componentes destes conceitos, em uma análise evolutiva, CONBOY (2009) chegou a
uma definição de agilidade, especificamente desenvolvida para o contexto de
desenvolvimento de software. Esta definição é de base mais conceitual do que
pragmática. Sendo assim, pode ser interessante identificar e observar quais
características devem estar associadas a processos de software a fim de que eles possam
ser considerados ágeis, em um nível de abstração um pouco mais baixo, que permita
entender e trabalhar o significado da agilidade em processos de software. O
entendimento de características de agilidade mais específicas, poderá apoiar
engenheiros de software na busca por melhorias e na exploração da agilidade no
desenvolvimento de software.
Os métodos ágeis buscam as melhores maneiras para acomodar as inevitáveis
mudanças que ocorrem durante o ciclo de vida do software. Segundo HIGHSMITH e
COCKBURN (2001) e ABRAHAMSSON et al. (2002), os métodos ágeis são
projetados para (1), produzir uma primeira versão em semanas e receber um retorno
rápido e mais cedo; (2) criar soluções mais simples para que em caso de necessidade de
alterações elas possam ser feitas mais facilmente e poucas adaptações tenham de ser
realizadas; (3) buscar continuamente a melhoria da qualidade do projeto, viabilizando
uma próxima iteração com menores custos; (4) testar com freqüência, para detectar
defeitos mais cedo e removê-los com custos mais baixos. A presteza para mudar e a
aceitação de mudanças são o fundamento das metodologias ágeis (MATIJASEVIC,
RONCEVIC e OREL 2007).
ABRAHAMSSON et al. (2002) concluem que os métodos ágeis dão maior ênfase
a pessoas, interação, software funcionando, colaboração do cliente e a mudanças do que
a processos , ferramentas, contratos e planos. Segundo MNKANDLA e DWOLATZKY
(2007), os profissionais de desenvolvimento de software em breve estarão se deparando
com questões relacionadas com a certificação ágil. O desenvolvimento ágil tem
impactado profundamente a indústria de software nos últimos anos (DYBA e
DINGSOYR, 2008). Estas questões poderão incluir testes ágeis ou agilidade em testes.
Muitos dos métodos ágeis colocam ênfase em aspectos como a entrega de
software útil e funcionando, confiança nas pessoas, encorajamento da colaboração,
41
busca da excelência técnica, fazer as coisas do jeito mais simples possível e ser sempre
adaptável a novas situações (HIGHSMITH, 2002). Para FAVARO (2002) o paradigma
de desenvolvimento iterativo, que permite que requisitos sejam introduzidos,
modificados ou removidos em iterações sucessivas é o denominador comum dos
processos ágeis.
Apesar de considerarem que não existe um acordo sobre quais são os principais
aspectos que envolvem os métodos ágeis, ABRAHAMSSON et al. (2002, 2010)
estabelecem que um método de desenvolvimento de software é um método ágil se ele é
incremental (produz pequenas liberações (releases) de software em ciclos rápidos),
cooperativo (clientes e desenvolvedores trabalhando juntos e se comunicando de perto),
objetivo e claro (fácil de ser aprendido e modificado) e adaptativo (ser receptivo e
possibilitar que mudanças de última hora sejam feitas).
3.1.1 A Aliança Ágil
A aliança ágil (AGILE ALLIANCE, 2001) é uma organização sem fins
lucrativos que apóia indivíduos e organizações que utilizam abordagens ágeis para
desenvolver software. Guiadas por simples prioridades articuladas no Manifesto para
Desenvolvimento Ágil de Software (AGILE MANIFESTO, 2001), as abordagens ágeis
buscam entregar software que agregue valor aos negócios das organizações e aos
usuários finais de forma mais rápida e com mais alta qualidade.
3.1.2 O Manifesto Ágil
Em 2001 o Manifesto Ágil (AGILE MANIFESTO, 2001) foi formalizado por
um grupo de profissionais, que propuseram muitos dos métodos ágeis de
desenvolvimento de software. Tal manifesto é composto basicamente por uma
declaração de valores e princípios, que devem guiar o desenvolvimento ágil de software.
3.1.2.1 Os Valores
O Manifesto Ágil declara que o desenvolvimento ágil deve focar em quatro
valores fundamentais, onde são especificados os elementos que devem ser mais
valorizados:
Indivíduos e interações do que processos e ferramentas;
Software funcionando do que documentação abrangente;
42
Colaboração do cliente do que negociação de contratos, e;
Responder a mudanças do que seguir um plano.
3.1.2.2 Os Princípios
A Aliança Ágil também documentou os princípios que fundamentam o
Manifesto Ágil (AGILE MANIFESTO, 2001). Os métodos ágeis se baseiam mais em
princípios do que em regras específicas. Ao invés de regras pré-definidas quanto a
papéis, hierarquias, responsabilidades, relacionamentos e atividades, as equipes e o
gerente são guiados por princípios (LARMAN, 2003). Os signatários do Manifesto Ágil
declaram que seguem os 12 princípios a seguir:
1. A prioridade mais alta é satisfazer o cliente através de contínuas entregas
de software que agreguem valor aos negócios mais cedo;
2. Mudanças de requisitos são bem vindas, mesmo que tardias no processo
de desenvolvimento. Processos ágeis aproveitam as mudanças para obter
vantagens competitivas para o cliente;
3. Entregas de software funcionando devem ser freqüentes, de duas
semanas a dois meses, com preferência para intervalos de tempo mais
curtos;
4. O pessoal de negócios e os desenvolvedores devem trabalhar juntos
diariamente ao longo do projeto;
5. Projetos devem ser construídos em torno de indivíduos motivados. Deve
ser dado a eles o ambiente adequado e apoiadas as suas necessidades,
além de confiar neles para realizar o trabalho;
6. O meio mais eficiente e eficaz de transmitir informação para dentro da
equipe de desenvolvimento é a conversa face a face;
7. Software funcionando é a principal medida de progresso;
8. Processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de manter
um ritmo constante indefinidamente;
9. Atenção contínua à excelência técnica e ao bom projeto aumentam a
agilidade;
43
10. A simplicidade, como arte de maximizar a quantidade de trabalho não
executado é essencial;
11. As melhores arquiteturas, requisitos e projetos surgem das equipes auto-
organizadas,e;
12. Em intervalos regulares, as equipes refletem em como se tornar mais
eficientes, e sintonizam e ajustam seu comportamento adequadamente.
Dentro deste contexto, foi empreendida uma revisão sistemática de literatura,
buscando identificar quais são as características que devem estar presentes em um
processo de software para que ele possa ser considerado ágil.
3.2 Revisão Sistemática de Literatura – Características de
Agilidade
Esta seção apresenta a realização de um estudo secundário, utilizando a
estratégia da revisão sistemática da literatura (KITCHENHAM, 2004), com o objetivo
de identificar as características de agilidade de processos de software. Foi realizado um
estudo com o propósito de definir um conjunto de características que pudessem ser
utilizadas para classificar um processo de software como sendo ágil. A questão básica
de pesquisa foi: qual é o significado de “ser ágil” no contexto de processos ágeis de
software?
Como o objetivo do estudo foi realizar a caracterização de uma área, não houve
comparações entre intervenções e alternativas (PAI et al, 2004), nem foi possível fazer
meta-análise, razão pela qual, apesar de sistemático, o estudo foi considerado uma quasi
-revisão sistemática (TRAVASSOS et al., 2008).
Como descrito por ABRANTES e TRAVASSOS (2007, 2007a, 2011), não se
pretendeu investigar características de agilidade para um método ágil em particular, mas
de um modo geral, buscou-se identificar quais seriam as características ou propriedades
desejáveis para que um processo de software seja considerado como sendo ágil,
tornando possível a posterior investigação de como explorar tais características de
agilidade em diferentes processos de software. O protocolo elaborado foi executado
quatro vezes.
44
3.3 Protocolo da quasi – Revisão Sistemática de Literatura
O protocolo utilizado para a quasi - revisão sistemática foi elaborado com a
inclusão dos seguintes elementos: Objetivo, Questão Formulada, Problema, Aplicação,
População, Intervenções, Comparação, Resultado, Controles, Fontes, Linguagem, Tipos
de Trabalhos ou Artigos, Palavras-Chave, Critérios de Inclusão e Exclusão, Processo de
Seleção dos Estudos, Avaliação da Qualidade dos Estudos, Estratégia de Extração de
Informações, Resumo de Resultados, Strings de Busca.
O objetivo é identificar as propriedades ou características dos métodos ágeis de
desenvolvimento de software, de uma maneira geral.
A questão formulada é: quais são as propriedades ou características dos métodos
ágeis de desenvolvimento de software?
O problema considerado é: encontrar propriedades ou características de métodos
ágeis de desenvolvimento de software.
A aplicação dos resultados da quasi - revisão sistemática é servir de base ou
apoiar pesquisas envolvendo (1) atividades de processo em métodos ágeis de
desenvolvimento de software e (2) critérios para seleção de métodos ágeis a serem
aplicados em projetos de desenvolvimento de software.
Foi adotada uma abordagem que estrutura a questão de pesquisa em quatro
elementos básicos: população, intervenção, comparação e resultado [PAI et al, 2004].
Assim, a população considerada foram projetos de desenvolvimento de software. A
intervenção considerada foram processos ou métodos ágeis de desenvolvimento de
software. Não há comparação (intervenção alternativa). O resultado esperado é uma
lista de propriedades ou características de agilidade de métodos de desenvolvimento de
software.
Como controles, foram adotados 3 artigos:
MILLER, G. G. The characteristics of agile software processes, 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.
45
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.
As fontes consideradas na quasi - revisão sistemática são as bases de dados
eletrônicas, disponíveis no portal CAPES, incluindo conferências, journals e relatórios
técnicos indexados por: Compendex EI, IeeeXplore, Inspec, Web of Science, ACM
digital library. Na terceira e quarta execução do protocolo foram consideradas ainda:
Scopus e Science Direct. Estas fontes foram escolhidas porque são as que se tem acesso
para recuperação de referências, bem como maior facilidade para recuperação do texto
completo do artigo quando fosse o caso. Além disso, estas fontes foram consideradas
significativas no sentido de oferecerem publicações pertinentes e que podem contribuir
significativamente para o resultado da pesquisa.
A linguagem considerada para documentos recuperados através de suas
referências é o Inglês, por ser maioria nas bases de dados pesquisadas. Em uma busca
preliminar, não foram encontrados artigos escritos em Português que trouxessem
contribuição para o tema da pesquisa. Além disso, textos em Português, embora se
reconheça a sua importância, muitas vezes não se encontram indexados, o que aumenta
o esforço ou impede sua busca.
Os tipos considerados de trabalhos ou artigos publicados são qualquer tipo que
faça abordagem sobre propriedades ou características de agilidade em processos ou
métodos de desenvolvimento de software.
As palavras-chave definidas para formar a string de busca foram:
Para População:
software, development, project, system, application, engineering, building,
implementation
Para Intervenção:
agile, method, adaptive, rapid, approach, technique, environment, process,
practice, methodology
Para Resultado:
characteristic, attribute, property, feature, characterization, aspect, idea, factor,
dimension, driver, perspective, requirement.
46
Como critério de inclusão e exclusão, foi definido que:
Os documentos devem estar disponíveis na web;
Os documentos devem contemplar propriedades ou características de
agilidade em métodos ágeis de desenvolvimento de software;
Os documentos devem relatar algum exemplo ou caso de utilização de
algum método ágil de desenvolvimento de software.
O processo de seleção dos estudos envolve a participação de 2 pesquisadores.
Um pesquisador aplica a estratégia de busca para a identificação de potenciais
documentos. Os documentos identificados são selecionados pelo mesmo pesquisador
através da leitura e verificação dos critérios de inclusão e exclusão estabelecidos.
Posteriormente a lista de documentos excluídos é avaliada por um segundo
pesquisador. Em caso de conflito o documento é incluído.
Ao final, os documentos são lidos pelos pesquisadores para extração de
informações sobre propriedades ou características dos métodos ágeis de
desenvolvimento de software.
A avaliação da qualidade dos estudos não será feita por tratar-se de uma
pesquisa para fins de caracterização de objeto de estudo (os métodos ágeis). Será
considerado que as fontes dos documentos são confiáveis, e que os textos tenham
passado por revisões externas que serviram de filtragem para que tenham qualidade
suficiente para contribuir com a revisão sistemática.
A estratégia de extração de informações considera que para cada estudo
selecionado após a execução do processo de seleção, serão extraídas as seguintes
informações:
• Título do documento• Autor(es)• Fonte• Ano de publicação• Propriedades ou características de agilidade
O resumo de resultados inclui tabulações. Serão realizadas análises para
identificar similaridades e as propriedades ou características mais relevantes para os
métodos ágeis de desenvolvimento de software. Será considerada a freqüência com que
uma propriedade ou característica tenha sido apontada por autores diferentes.
47
A string de busca, na medida do possível, será a mesma para todas as máquinas.
Contudo, poderá haver adaptações para se adequar a restrições de máquinas de busca
específicas, observando-se as seguintes diretrizes:
1. a string derivada deverá ser logicamente equivalente à string original, ou
2. na impossibilidade de se manter equivalência 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 básicos que estruturam a
questão de pesquisa podem ser relacionados com o operador lógico AND. Isto foi feito
para cada conjunto de palavras-chave escolhidas para representar cada um dos
elementos “população”, “intervenção” e “resultado”. Para cada um destes três elementos
da estrutura, as respectivas palavras-chave foram combinadas com o operador lógico
OR. Foi também utilizado o operador binário NEAR, que é um recurso oferecido pelas
máquinas de busca para estabelecer que uma palavra-chave deva ocorrer próxima à
outra palavra-chave. Este operador pode ser parametrizado para estabelecer a
proximidade ou distância em quantidade de palavras, entre as duas palavras-chave, em
cada ocorrência. Se utilizado o parâmetro zero, as duas palavras-chave devem ocorrer
juntas para satisfazer a condição.
A abordagem utilizada e o detalhamento de cada elemento do protocolo foram
descritos e podem ser encontrados em (ABRANTES e TRAVASSOS, 2007, 2007a,
2011). A string de busca básica, adaptada de acordo para cada máquina de busca, pode
ser vista na Figura 3-1 abaixo:
Figura 3-1 – String de Busca Básica
É vital para a estratégia de busca detectar o máximo de material relevante
possível. Isto é influenciado, também, pela montagem da string de busca. Deixar
material relevante fora da revisão sistemática pode levar à geração de evidências não
(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 methodolog OR approach OR technique OR environment)) AND ((agile) AND (characteristic OR attribute OR propert OR feature OR characterization OR aspect OR idea OR factor OR dimension OR driver OR perspective OR requirement))
48
acuradas. O atributo de “sensibilidade” referenciado por DIESTE e PADUA (2007) é
também conhecido como “recall”. Há um duplo propósito na recuperação de referências
para documentos: obter um alto “recall”, através da recuperação de uma substancial
quantidade de referências, e ao mesmo tempo rejeitar uma grande quantidade de
referências para documentos irrelevantes. O “recall” é a proporção de itens relevantes
que são recuperados (SALTON, 1979) ou a probabilidade de recuperar uma referência
considerada relevante (CHOW e YU, 1982). A precisão é a proporção de itens
recuperados que são considerados relevantes (SALTON, 1979) ou a probabilidade de
que uma referência recuperada seja relevante (CHOW e YU, 1982). A relevância de
uma referência para um documento depende de avaliação do usuário. Uma referência
relevante recuperada é considerada um “hit” e uma referência não relevante recuperada
é considerada um “ruído” (GARFIELD 1970). Não recuperar uma referência relevante
é considerado uma “perda”. Considera-se “ignorado” um documento não relevante que
não é recuperado. Com base nestes conceitos, o conjunto de referências em uma base de
dados (digital ou não) pode ser visto como quatro subconjuntos, conforme mostra a
Tabela 3-1 abaixo:
Tabela 3-1 – Conjunto de Referências em uma Base de Dados
Documentos Relevantes Não-relevantes
Recuperados a (hits) c (ruído)Não Recuperados b (perdas) d (ignorados)
A precisão (P) e o “recall” (R) são definidos como:
P = a / (a+c) 0 ≤ P ≤ 1
R = a / (a+b) 0 ≤ R ≤ 1
Para avaliar R, é necessário aplicar técnicas de amostragem, uma vez que não é
viável obter julgamento de relevância para referências a documentos no subconjunto
dos não recuperados.
3.4 Execução das Buscas
O protocolo foi executado quatro vezes. A primeira execução foi realizada em
novembro/dezembro de 2006, envolvendo 5 bases de dados digitais: Compendex EI,
IeeeXplore, Inspec, Web of Science e ACM Digital Library.
49
O protocolo foi executado novamente em dezembro de 2007, tentando capturar
referências para documentos publicados ou indexados depois de novembro de 2006. As
mesmas strings de busca foram novamente submetidas às mesmas máquinas de busca
utilizadas na primeira execução do protocolo, realizada em novembro/dezembro de
2006.
Depois disso, foi realizada uma terceira execução do protocolo, englobando
agora documentos publicados ou indexados até dezembro de 2007, mas utilizando duas
máquinas de busca diferentes (Science Direct e Scopus) que ainda não haviam sido
utilizadas nas duas execuções anteriores.
A segunda execução do protocolo estendeu o espaço de busca
“cronologicamente”: documentos publicados ou indexados nos últimos meses de 2006 e
durante o ano de 2007 foram pesquisados. A terceira execução do protocolo estendeu o
espaço de busca “geograficamente”: duas novas máquinas de busca, no mesmo período
(até 2007) teoricamente poderiam recuperar novas e diferentes referências para
documentos armazenados em outras bases de dados digitais (Science Direct e Scopus).
Houve ainda uma quarta execução, em janeiro de 2010, para fins de atualização
e/ou confirmação dos resultados obtidos com as execuções anteriores.
3.5 Resultados Obtidos
Na primeira execução do protocolo foram recuperadas 1016 referências, sendo
772 sem repetições. As referências recuperadas incluíram documentos publicados de
1978 até outubro de 2006. Ao final das sucessivas avaliações e observando os critérios
estabelecidos no protocolo, um conjunto de 39 documentos foi selecionado e priorizado
através de leitura de resumos e da parte introdutória. Detalhes do processo de seleção
dos documentos podem ser obtidos em ABRANTES e TRAVASSOS (2007, 2007a,
2011).
As características de agilidade no contexto de processos ágeis de software foram
capturadas em 11 dos documentos selecionados, após aplicação do critério estabelecido
no protocolo (AOYAMA, 1998; MILLER, 2001; COCKBURN, 2002;
ABRAHAMSSON et al, 2002; LINDVALL et al, 2002; ABRAHAMSSON et al, 2003;
BOEHM e TURNER, 2004a; CORAM e BOHNER, 2005; MESO e JAIN, 2006;
HOLMSTROM et al, 2006; HANSSON et al, 2006). As referências destes documentos
estão apresentadas em detalhes no apêndice A1. As ocorrências das características de
50
agilidade encontradas nos artigos tiveram suas denominações e descrições consolidadas.
Dezoito características para processos ágeis de software foram identificadas. Elas estão
descritas na Tabela 3-2 que se segue:
Tabela 3-2 – Características Identificadas para Processos Ágeis de Software
Característica Interpretação
Adaptabilidade
Habilidade e capacidade de adaptar rapidamente o processo para atender e reagir a mudanças de última hora nos requisitos e/ou mudanças de ambiente, bem como atender e reagir a riscos ou situações não previstas.
Auto-organizaçãoAs equipes definem as melhores maneiras de se trabalhar; elas são autônomas e
podem se auto-organizar de acordo para completar os itens de trabalho.
Convergência
Atacar os riscos proativamente faz com que o sistema se torne mais perto da realidade procurada a cada iteração. À medida em que esta ação progride, o sistema é entregue em incrementos. Tudo que estiver ao alcance dos envolvidos no desenvolvimento do software é feito para garantir o sucesso de modo mais rápido.
Emergência
Os processos, princípios e estruturas de trabalho são reconhecidos durante o processo de execução, não sendo definidos a priori; é permitido e aceito que tecnologias e requisitos surjam durante o ciclo de vida do produto.
Equipes Locais
Para algumas metodologias isto significa equipes localizadas nas mesmas salas ou em salas adjacentes; isto funciona para equipes de 4 a 8 pessoas. Todas as metodologias são sensíveis à localização das equipes e estão fortemente baseadas em canais de comunicação ricos e rápidos, apoiando a redução de documentação a ser elaborada e mantida.
Equipes Pequenas
Equipes pequenas, e pequeno número de equipes por projeto, são necessários para promover um ambiente colaborativo e requer menos planejamento para coordenar as atividades dos membros das equipes.
Incorporação de Retroalimentação (feedback)
As equipes devem ser capazes de receber e procurar continuamente por retroalimentação de modo mais freqüente e com mais rapidez.
Leanness
Esta característica está relacionada com a eliminação de perdas e com a habilidade de realizar mais trabalho com menos esforço; é uma característica de processos ágeis que requer o mínimo necessário de atividades para mitigar riscos e alcançar metas; todas as atividades que não são necessárias devem ser removidas do processo de desenvolvimento.
Modularidade
Esta característica permite que um processo seja particionado em componentes chamados de atividades, tornando viável adicioná-los ou removê-los de um processo quando necessário.
Orientação a Pessoas
Privilegiar pessoas em detrimento de processos e tecnologias; desenvolvedores são fortalecidos e encorajados a aumentar sua produtividade, qualidade e desempenho; comunicação e cooperação são fundamentais e necessárias; reuniões em pé e oficinas(workshops) de reflexão dão às pessoas a chance de expor suas preocupações.
Reflexão e Introspecção
Acontecem reuniões no final de cada subprojeto ou iteração, nas quais cada membro da equipe pode discutir o que está sendo bem feito e o que precisa ser melhorado.
Ser Colaborativo
Esta é uma atitude por parte dos membros da equipe de desenvolvimento, dentre os quais a comunicação é encorajada para disseminar informação e apoiar integração rápida de incrementos de software.
Ser Cooperativo
Interação aberta e proximidade entre todos as partes interessadas (stakeholders), especialmente entre clientes e desenvolvedores; o cliente deve ser um elemento ativo no processo de desenvolvimento e deve prover retroalimentação (feedback) de modo regular e freqüente.
51
Característica Interpretação
Ser Incremental
Não tentar construir o sistema todo de uma só vez; o sistema deve ser particionado em incrementos (pequenas liberações – releases – com novas funcionalidades) desenvolvidos em ciclos rápidos e paralelos; quando o incremento estiver completo e testado, ele é integrado ao sistema.
Ser Iterativo
Usar vários ciclos curtos guiados por funcionalidades do produto, nos quais certo conjunto de atividades é completado em poucas semanas; estes ciclos são repetidos muitas vezes pra refinar as entregas.
Testes Constantes
Para prevenir a degradação da qualidade por causa de programas de liberações freqüentes (releases curtas), um alto grau de ênfase é colocado no teste do produto ao longo de seu ciclo de vida; testes de integração devem ser automatizados comconstruções diárias (builds diárias) bem como a execução de testes de regressão para garantir que todas as funcionalidades operem adequadamente.
Time-Boxing
É o estabelecimento de limite ou fatias de tempo para cada iteração programada. Grandes esforços de desenvolvimento são divididos em múltiplas entregas desenvolvidas de modo incremental e concorrente, de maneira previsível.
TransparênciaO método ou processo ágil deve ser fácil de aprender e de ser modificado, além de estar adequadamente documentado.
Uma preocupação durante a consolidação das denominações e descrições das
características de agilidade foi encontrar termos na língua portuguesa que fossem
adequados para substituir as diversas denominações em inglês que surgiram nos artigos
selecionados. Para a característica Leanness, surgiu como alternativa a denominação
“Parcimônia”, utilizada por MILLER (2001). Contudo este termo foi descartado, porque
o seu significado no dicionário Aurélio (FERREIRA, 2004) foi descrito como “ato ou
costume de poupar, de economizar; economia”, não englobando a idéia completa desta
característica, podendo levar a alguma confusão com seu real significado expresso pela
consolidação das descrições apresentadas pelos autores dos artigos selecionados. Uma
terminologia alternativa de tradução imaginada para esta característica foi derivada das
obras que descrevem a metodologia Lean Software Development (POPPENDIECK e
POPPENDIECK, 2003; POPPENDIECK e POPPENDIECK, 2006): “Produção
Enxuta”. Contudo, a utilização desta terminologia também foi descartada, porque
poderia levar o leitor a um esforço excessivo para entender sua descrição, uma vez que
os autores que a empregam explicam o seu significado se apoiando em 7 princípios que
são explicados em 7 capítulos de cada uma destas duas obras referenciadas. Sendo
assim, foi mantida a terminologia Leanness para denominar a característica, com a
descrição consolidada apresentada na Tabela 3-2.
Também o termo Time-boxing foi objeto de preocupação durante a consolidação
das denominações e descrições das características de agilidade. Foram imaginadas
algumas traduções alternativas, como as expressões “Planejamento baseado em
52
intervalos de tempo”, "encaixamento de tempo" , “ fixação de tempo”, “período fixo de
tempo”. Contudo estas expressões poderiam não ser fiéis à idéia básica do significado
da característica, de acordo com as descrições dos autores dos artigos selecionados.
Assim, optou-se por adotar o termo em inglês “Time-boxing”, para denominar a
característica, uma vez que tal terminologia parece ser a que melhor retrata o seu
significado, sendo inclusive utilizada por JALOTE et al. (2004) para referenciar um
modelo de processo iterativo para desenvolvimento de software.
O gráfico na Figura 3-2 a seguir permite visualizar a distribuição das
características encontradas, de acordo com a presença nos respectivos documentos
aproveitados na quasi - revisão sistemática. Os critérios utilizados na contagem foram
descritos junto com o protocolo de pesquisa elaborado para este estudo secundário e
descrito na seção 3.3.
Figura 3-2 – Percentagens de Incidência das Características nos Artigos
Pode-se observar que as características mais freqüentes foram adaptabilidade,
ser incremental e ser iterativo, com 55.56% de incidência para as duas primeiras e
44,44% de incidência para a característica ser iterativo. Dentre estas, a adaptabilidade
parece ser mais diretamente alinhada com um dos valores do Manifesto Ágil publicado
em 2001: “valorizar mais a resposta a mudanças do que seguir um plano”. O gráfico
apresentado na Figura 3-3 mostra a distribuição das características por faixa de tempo
das publicações em que são abordadas.
0,0%
10,0%
20,0%
30,0%
40,0%
50,0%
60,0%
Pe
rce
ntu
ais
de
Inc
idê
nc
ia
Características
Incidência das Características nos Artigos
53
Figura 3-3 – Distribuição das Características por Faixa de Tempo das Publicações
ABRANTES e TRAVASSOS (2007, 2007a, 2011) fazem considerações sobre a
distribuição das características por faixa de tempo e por densidade de publicações nos
períodos de tempo. Exceto para o caso de AOYAMA (1998) todos os demais
documentos aproveitados na quasi - revisão sistemática foram publicados após a
declaração do Manifesto Ágil (AGILE MANIFESTO, 2001).
Considerando o que foi apurado por este estudo secundário e baseado nas
análises efetuadas, ABRANTES e TRAVASSOS (2007, 2007a, 2011) propuseram que
para ser considerado ágil, um processo de software deveria apresentar, no contexto de
desenvolvimento em que está inserido, um grau adequado das características
adaptabilidade, ser incremental, ser iterativo, ser colaborativo, ser cooperativo,
orientação a pessoas, leanness e time-boxing.
Na segunda execução do protocolo foram recuperadas 508 referências, sendo
250 sem repetições. Ao final das sucessivas avaliações e observando os critérios
estabelecidos no protocolo, um conjunto de 24 documentos foi selecionado e priorizado
através de leitura de resumos e da parte introdutória.
Os 24 documentos selecionados foram lidos integralmente. Este novo conjunto
de documentos selecionados não reportou nada de novo com relação às características
identificadas na primeira execução, bem como não apresentou qualquer característica de
agilidade nova ou diferente. Entretanto, os artigos adicionais reforçaram a confiança nos
0123456789
10F
aixa
de
Tem
po
em
An
os
Características
Distribuição das Características por Amplitude de Tempo de Publicações
54
resultados anteriormente obtidos, aumentando o numero de referências para as
características encontradas.
Na terceira execução do protocolo, foram recuperadas 2861 referências, sendo
que após eliminação das repetições sobraram 2634 referências a serem avaliadas. Foram
selecionados para leitura completa e minuciosa 54 documentos. Também nesta terceira
execução nenhuma nova característica ou mudança foi acrescentada ao que já havia sido
identificado na primeira execução. Contudo, a base de pesquisa foi novamente
expandida nas fontes de consulta, reduzindo as chances de que algum documento
importante tenha sido perdido ou não considerado.
A precisão alcançada com as máquinas de busca neste estudo foi muito baixa.
Contudo não foi discrepante de outra revisão sistemática sobre estudos experimentais de
desenvolvimento ágil de software publicada por DYBA e DINGSOYR (2008), que
também apresentou nível baixo de precisão para as referências recuperadas.
Considerando-se os documentos recuperados e aproveitados na primeira
execução do protocolo como controles, a máquina de busca da Scopus recuperou 60%
deles, seguida pelas máquinas da Inspec e Compendex EI que recuperaram 40% cada
uma. Juntas, Scopus e Inspec recuperaram 90% dos controles.
A Figura 3-4 a seguir mostra a distribuição dos controles que foram recuperados
pelas máquinas de busca após a terceira execução do protocolo:
Figura 3-4 – Quantitativos de Controles Recuperados pelas Máquinas de Busca
ABRANTES e TRAVASSOS (2007, 2007a, 2011) comentam com algum
detalhe sugestões de futuros trabalhos sobre processos ágeis de software, bem como
fazem observações sobre ameaças à validade dos resultados alcançados por este estudo.
1
1
1
1
2
2
2
0
Inspec
Web ofScience
ScienceDirect
IeeeXplore
Scopus
ACMDigitalLibrary
Compendex EI
55
Na quarta execução do protocolo, foram recuperadas 2217 referências. Em
termos de máquinas de busca utilizadas, bem como de cronologia das referências
recuperadas, a Figura 3-5 ilustra as repetidas execuções do protocolo de revisão.
Figura 3-5 – Execuções de protocolo ao longo do tempo
A Tabela 3-3 apresenta um resumo quantitativo das referências recuperadas
pelas máquinas de busca, nas quatro execuções do protocolo.
Tabela 3-3 – Sumário Quantitativo das Referências Recuperadas
Base de Dados Exec 1 Exec 2 Exec 3 Exec 4 Todas ExecACM digital library 119 89 208Compendex EI 303 179 327 809IeeeXplore 299 124 201 624Inspec 250 94 7 351Science Direct 997 310 1329Scopus 1864 1339 3203Web of Science 45 22 33 78Totais 1016 508 2861 2217 6602
Na quarta execução do protocolo, o ano de publicação das referências foram
restringidos a 2008 e 2009, uma vez que a intenção era atualizar as pesquisas já
realizadas, que recuperaram referências a documentos publicados até 2007. Foram
assim recuperadas 2217 referências, sendo que as repetições foram eliminadas
utilizando-se os mesmos critérios das execuções anteriores. Um conjunto de 40
documentos foi selecionado, e os documentos priorizados através de leitura e análise
minuciosa de resumos e introdução. Em alguns casos, mais seções de documento foram
lidas. Após isso, os documentos foram integralmente lidos e minuciosamente analisados
Trial 2Trial 1
Compendex EI,Inspec, IeeeXplore,Web of Science,ACM
Scopus,Science Direct
Ano de Publicação
1977 2006 2007
Exec 2
Exec 3
Exec 1
Exec 4
2009
56
tendo em vista o objetivo da revisão sistemática de acordo com o protocolo
estabelecido.
TAROMIRAD e RAMSIN (2008) propuseram 17 características de agilidade
recomendadas para métodos ágeis. Contudo, neste trabalho eles não apresentaram
descrições ou significados para estas características.
Nesta quarta execução do protocolo, características de agilidade no contexto de
processos ágeis de software foram capturadas em 3 dos documentos selecionados: Rico
(2008), QUMER e HENDERSON-SELLERS (2008a) e TAROMIRAD e RAMSIN
(2009).
Pelo critério estabelecido no protocolo, um total de nove características para
processos ágeis de software foram identificadas e consideradas nesta execução. Contudo
os significados destas nove características de agilidade não eram novos nem diferentes
de características já capturadas nas execuções anteriores.
TAROMIRAD e RAMSIN (2009) apresentaram nove características de
agilidade que foram definidas com base no MANIFESTO ÁGIL (2001), nos princípios
ágeis e em artigos que tratavam de características ágeis consideradas usuais. Os autores
argumentaram que tais características podem ser utilizadas para avaliar o grau de
agilidade de qualquer processo de desenvolvimento de software, mesmo aqueles não
ágeis ou tradicionais. Estas características são apresentadas a seguir:
Velocidade- relativa a quão rápido o processo pode produzir resultados;
Sustentabilidade- relativa ao monitoramento e controle da manutenção de
velocidade e qualidade até o fim do processo de desenvolvimento;
Flexibilidade- relativa à capacidade de capturar e lidar, no projeto, com
mudanças esperadas e não esperadas;
Aprendizagem- relativa à habilidade do processo para aprender dos projetos
passados e também de iterações prévias;
Sensibilidade (responsiveness)- relativa à capacidade do processo em prover
retroalimentação (feedback); capacidade de reagir com rapidez e favoravelmente;
Leanness- relativa a como o processo valoriza os intervalos de tempo, utilizando
meios de qualidade assegurada econômicos e simples para produção;
Leveza e Simplicidade- relativa quão leve e simples é o processo de
desenvolvimento.
57
Qualidade Técnica- relativa a como a qualidade técnica é monitorada e
controlada durante o processo de desenvolvimento.
Colaboração Ativa do Usuário- relativa ao grau de envolvimento do cliente no
processo de desenvolvimento.
RICO (2008) em seu estudo sobre relacionamentos entre o uso de métodos ágeis
para desenvolvimento de sites e a sua qualidade, apontou quatro fatores para
caracterizar métodos ágeis: desenvolvimento iterativo, retroalimentação (feedback) do
cliente, equipes bem estruturadas e flexibilidade. Flexibilidade é definida pelo IEEE
(1990) como “a facilidade com a qual um sistema ou componente pode ser modificado
para uso em aplicações ou ambientes diversos daqueles para os quais foi
especificamente projetado”. Equipes bem estruturadas são definidas por GUZZO e
DICKSON (1996) como “grupos de trabalho constituídos de indivíduos que vêm a si
mesmos com uma entidade social, que são independentes por causa das tarefas que
executam, que estão inseridos em um ou mais sistemas sociais mais amplos, e que
executam tarefas que afetam os outros”. A retroalimentação (feedback) do cliente,
conforme KUJALA (2003), é “um termo genérico para referenciar o contato direto com
usuários utilizado em diversas abordagens” e que pressupõe um papel a partir do
informativo, passando pelo aconselhamento ou consultoria, até o participativo. O
desenvolvimento iterativo foi definido por LARMAN (2004 ) como “uma abordagem
para construir software (ou outra coisa qualquer) na qual o ciclo de vida completo é
composto de várias iterações em sequência”.
RICO (2008) apresenta também, para cada característica ou fator apresentado,
subfatores selecionados da literatura técnica sobre métodos ágeis.
QUMER e HENDERSON-SELLERS (2008a) descrevem cinco atributos de
agilidade, descritas conforme se segue:
Flexibilidade- relacionada com a capacidade do processo para acomodar
mudanças esperadas e não esperadas; ela encoraja a aceitação e acomodação de
mudanças (geradas de um ambiente externo ou por um cliente) no produto de software,
no processo, no plano, na equipe de desenvolvimento e no ambiente de
desenvolvimento.
Velocidade- relacionada com a capacidade do processo para produzir resultados
com rapidez;
58
Leanness- relacionada com a capacidade do processo para usar o menor
intervalo de tempo, bem como instrumentos econômicos, simples e de qualidade para a
produção;
Aprendizagem- relacionada com a capacidade do processo para aplicar
conhecimento prévio atualizado e experiência para criar um ambiente de aprendizagem;
Sensibilidade (responsiveness)- relacionada com a capacidade do processo para
exibir sensibilidade, não apenas no sentido de tornar fácil a aceitação de mudanças, mas
de torná-las visíveis ou perceptíveis.
Analisando o significado das características descritas pelos autores dos 3 artigos
(RICO, 2008; QUMER e HENDERSON-SELLERS, 2008a; TAROMIRAD e
RAMSIN, 2009), os valores e os resultados da aplicação destas características para
avaliar XP (BECK, 1999; BECK e ANDRES, 2004) como apresentado por
TAROMIRAD e RAMSIN (2009), e também os subfatores selecionados da literatura
sobre métodos ágeis e destacados por RICO (2008), é possível identificar similaridades
entre as características encontradas nesta quarta execução do protocolo e aquelas já
identificadas nas execuções anteriores.
Nove características identificadas na primeira execução do protocolo são
reforçadas pelos achados desta quarta execução. A Tabela 3-4 a seguir retrata
resumidamente as características encontradas na quarta execução do protocolo, que
reforçam outras identificadas na primeira execução.
Tabela 3-4 – Características reforçadas pela quarta execução do protocolo
Característica obtida na 1ª. Exec.
Referênciana 1ª. Exec.
Característica de Reforço na 4ª. Exec.
Referênciana 4ª. Exec.
Adaptabilidade
Aoyama, 1998; Miller, 2001; Abrahamsson et al., 2003; Holmstrom e Fitzgerald, 2006; Hansson et al., 2006 Flexibilidade
Taromirad e Ramsin, 2009; Rico, 2008; Qumer e Henderson-Sellers, 2008a
Ser Iterativo
Abrahamsson et al., 2003; Holmstrom e Fitzgerald, 2006; Coram e Bohner, 2005; Bohem e Turner, 2004 Velocidade
Taromirad e Ramsin, 2009; Qumer e Henderson-Sellers, 2008a
Incorporação de Realimentação
Meso e Jain, 2006; Holmstrom e Fitzgerald, 2006
Receptividade
Taromirad e Ramsin, 2009; Qumer e Henderson-Sellers, 2008a
Realimentação do Cliente Rico, 2008
59
Característica obtida na 1ª. Exec.
Referênciana 1ª. Exec.
Característica de Reforço na 4ª. Exec.
Referênciana 4ª. Exec.
Leanness
Aoyama, 1998; Miller, 2001; Hansson et al., 2006
Leanness - mesma denominação -
Taromirad e Ramsin, 2009; Qumer e Henderson-Sellers, 2008a
Reflexão e Introspecção
Holmstrom e Fitzgerald, 2006; Cockburn, 2002 Aprendizagem
Taromirad e Ramsin, 2009; Qumer e Henderson-Sellers, 2008a
Testes Constantes Coram e Bohner, 2005
SustentabilidadeTaromirad e Ramsin, 2009
Qualidade TécnicaTaromirad e Ramsin, 2009
Ser Cooperativo
Abrahamsson et al., 2003; Meso e Jain, 2006; Hansson et al., 2006
Colaboração Ativa do Usuário
Taromirad e Ramsin, 2009
TransparênciaAbrahamsson et al.,
2003 Leveza e SimplicidadeTaromirad e Ramsin, 2009
Equipes Pequenas Coram e Bohner, 2005Equipes bem Estruturadas Rico, 2008
Em resumo, 50% das características de agilidade identificadas na primeira
execução do protocolo foram reforçadas pela quarta execução. Não houve identificação
de características novas em relação às execuções anteriores. A Tabela 3-5 apresenta o
quantitativo final de artigos nos quais as características identificadas foram abordadas,
de acordo com o critério estabelecido no protocolo planejado para esta quasi - revisão
sistemática, após a quarta execução do protocolo.
Tabela 3-5 – Incidência das características de Agilidade nos Artigos
Ord Características Número de Artigos Percentagem
1 Adaptabilidade 8 66,7%2 Ser Iterativo 7 58,3%3 Leanness 6 50,0%4 Ser Colaborativo 5 41,7%5 Ser Incremental 5 41,7%6 Incorporação de Realimentação 5 41,7%7 Reflexão e Introspecção 4 33,3%8 Time-boxing 4 33,3%9 Ser Cooperativo 3 25,0%
10 Orientação a Pessoas 3 25,0%11 Testes Constantes 2 16,7%12 Convergência 2 16,7%13 Modularidade 2 16,7%14 Equipes Pequenas 2 16,7%15 Transparência 2 16,7%16 Auto-organização 1 8,3%17 Emergência 1 8,3%18 Equipes Locais 1 8,3%
60
O gráfico da Figura 3-6 que se segue permite uma visualização da incidência das
características nos artigos após a quarta execução do protocolo.
Figura 3-6 - Incidência das Características nos Artigos
Observando a distribuição das 18 características encontradas, após as
atualizações decorrentes da quarta execução do protocolo, pode-se constatar que as
características sendo tratadas com maior freqüência nos artigos foram a adaptabilidade
(66,7%), ser iterativo (58,3%), leanness (50,0%) seguida de ser colaborativo, ser
incremental e incorporação de realimentação com 41,7% de incidência cada uma. As
características com freqüência média foram, reflexão e introspecção, time-boxing, ser
cooperativo e orientação a pessoas. As características menos abordadas nos artigos
foram testes constantes, convergência, modularidade, equipes pequenas, transparência,
auto-organização, emergência, e equipes locais.
Na Tabela 3-6, é apresentada a distribuição quantitativa de artigos tratando
características de agilidade, de acordo com o critério estabelecido no protocolo desta
revisão, por ano de publicação dos documentos, após a quarta execução do protocolo.
Tabela 3-6 - Distribuição das Características por Faixa de Tempo das Publicações
Faixa N° ArtigosCaracterística De Até Amplitude De Artigos Por Ano
Adaptabilidade 1998 2009 12 8 0,67Leanness 1998 2009 12 5 0,42"Ser Iterativo" 2001 2009 9 7 0,78Reflexão e Introspecção 2002 2009 8 4 0,50
0,0%10,0%20,0%30,0%40,0%50,0%60,0%70,0%80,0%
Per
cen
tag
ens
de
Inci
dên
cia
Características
Incidência das Características nos Artigos
61
Faixa N° ArtigosCaracterística De Até Amplitude De Artigos Por Ano
Time-Boxing 1998 2005 8 3 0,38"Ser Incremental" 1998 2004 7 5 0,71“Ser Cooperativo” 2003 2009 7 4 0,57Transparência 2003 2009 7 2 0,29Orientação a Pessoas 2001 2006 6 3 0,50"Ser Colaborativo" 2001 2006 6 3 0,50Testes Constantes 2005 2009 5 2 0,40Incorporação de Realimentação 2006 2009 4 5 1,25
Modularidade 1998 2001 4 2 0,50Equipes Pequenas 2005 2008 4 2 0,50Emergência 2004 2004 1 1 1,00Auto-organização 2004 2004 1 1 1,00Equipes Locais 2002 2002 1 1 1,00Convergência 2001 2001 1 1 1,00
Esta distribuição pode ser visualizada na Figura 3-7 que se segue.
Figura 3-7 – Distribuição das Características por Faixa de Datas de Publicação dos Artigos
As características com maior amplitude de tempo de publicação e com maior
densidade de publicações no período de tempo são: adaptabilidade, leanness, ser
iterativo, reflexão e introspecção, time-boxing, ser incremental, ser cooperativo e
transparência (todas com mais da metade da amplitude da faixa de tempo das
publicações). Algumas características apresentam densidade de publicações de pelo
menos 0,5 artigo publicado por ano: adaptabilidade, ser iterativo, reflexão e
introspecção, ser incremental, ser cooperativo, orientação a pessoas, ser colaborativo,
incorporação de realimentação, modularidade e equipes pequenas.
Na análise dos dados obtidos com as quatro execuções do protocolo, foi
verificado se o significado dos termos mudou ou se foram melhor definidos em
02468
101214
Am
plit
ud
e d
e T
emp
o e
m a
no
s
Características
Distribuição das Características Amplitude de tempo das Pubicações
62
sucessivos artigos publicados ao longo do tempo. Além disso, houve uma preocupação
em preservar o pensamento original do autor ao se extrair as descrições das
características de agilidade identificadas.
Um aspecto interessante a ser observado é a consideração de leanness como uma
característica de agilidade, encontrada em 5 artigos publicados entre 1998 e 2009. De
acordo com CONBOY (2009), leanness é um dos dois conceitos abrangentes que
sustentam o conceito de agilidade, do qual são derivados subconceitos específicos: valor
percebido pelo cliente para os princípios de economia, qualidade e simplicidade.
Contudo, as descrições para leanness observadas nesta revisão tem uma relação mais
estreita com o princípio de economia do que com os princípios de qualidade ou
simplicidade. As idéias de leanness descritas pelos autores em seus artigos (AOYAMA,
1998; MILLER, 2001; HANSSON et al., 2006; QUMER e HENDERSON-SELLERS,
2008a; TAROMIRAD e RAMSIN, 2009) e capturadas nesta revisão estão fortemente
relacionadas com o valor percebido pelo cliente para o princípio da economia, com
respeito a redução de custos, eliminação de perdas e poder fazer mais com menos.
3.6 Caracterização de um Processo Ágil de Software
Os resultados deste estudo foram reforçados pelas execuções repetidas do
protocolo de revisão conforme descrito na seções anteriores. O objetivo da revisão não
foi mapear as características de agilidade encontradas para os valores ou princípios do
MANIFESTO ÁGIL (2001), mas identificar quais são as características desejáveis para
promover agilidade em um processo de software.
Com base no que foi encontrado e identificado, pode-se qualificar algumas
características de agilidade como fundamentais para se alcançar agilidade em processos
de software. De acordo com o contexto aqui apresentado, a característica que parece ser
mais aderente aos valores do manifesto ágil é a adaptabilidade. Depois, considerando-se
aspectos mais pragmáticos, tem-se as características de ser incremental e ser iterativo,
que devem ser consideradas juntas. A estas 3 características devem ser adicionadas
outras 3 que estão diretamente associadas com a idéia básica que norteia os métodos
ágeis, qual seja, focar nas pessoas que conduzem as atividades dos processos. Esta 3
outras características são ser colaborativo, ser cooperativo e orientação a pessoas.
As características ser colaborativo e ser cooperativo são, algumas vezes,
confundidas na literatura técnica, dependendo de suas perspectivas de interpretação.
63
Contudo, nesta quasi - revisão sistemática, estas duas características não foram fundidas
nem confundidas, numa tentativa de preservar a idéia original dos autores. Além disso,
argumentos fortes e confiáveis o suficiente para considerá-las como uma única
característica de modo seguro não foram revelados neste estudo secundário. A diferença
entre estas duas características não está facilmente perceptível nem destacada nos
documentos recuperados e selecionados no estudo. A idéia de cooperação parece estar
mais diretamente ligada ao relacionamento entre clientes e membros da equipe de
desenvolvimento; está associada com o papel da realimentação constante
(ABRAHAMSSON et al., 2003; MESO e JAIN, 2006; HANSSON et al., 2006). Por
outro lado, a idéia de colaboração parece estar associada com o relacionamento entre os
membros da equipe de desenvolvimento e se relaciona com a integração contínua de
novos incrementos de software com funcionalidades novas ou modificadas (MILLER,
2001; CORAM e BOHNER, 2005; HOLMSTROM e FITZGERALD, 2006).
Além disso, duas características interessantes podem ser necessárias para o
sucesso de processos ágeis de software e essenciais a qualquer processo produtivo,
devendo ser aqui consideradas: leanness e time-boxing. É interessante observar que as
entregas devem ser rapidamente produzidas, contudo agregando valor para o cliente,
fornecendo resultados práticos e efetivos.
Outras características identificadas neste estudo também são importantes para o
sucesso de um processo ágil de software. Contudo, elas podem ser consideradas
subsidiárias daquelas aqui referidas como fundamentais. Portanto, com base nas
informações capturadas nas execuções do protocolo deste estudo secundário, um
aforismo com respeito a processos de software pode ser:
De acordo com STEINDL (2005), há 3 níveis de contexto nos quais a agilidade
pode ser útil em uma organização: no nível de projetos de desenvolvimento de software;
no nível de portfólio de projetos de software; e no nível da empresa como um todo,
onde a organização é desafiada por seus competidores. Simplesmente utilizar uma
para ser considerado ágil, um processo de software deve apresentar, no contexto
de desenvolvimento no qual ele está inserido, um grau adequado de pelo menos cada uma
das seguintes características: adaptabilidade, ser iterativo, ser incremental, incorporação
de realimentação, leanness, ser cooperativo, reflexão e introspecção, ser colaborativo,
orientação à pessoas e time-boxing.
64
abordagem ágil em um destes níveis sem considerar o nível seguinte mais alto, não
garante um retorno ótimo. Isto pode ser interpretado como a necessidade de abordagens
ágeis estarem alinhadas nestes 3 níveis de contexto para poder alcançar os melhores
resultados para uma organização de desenvolvimento de software.
A suposição para processos ágeis de software apresentada neste trabalho inclui a
noção de grau de agilidade, na medida em que referencia um grau adequado de cada
característica. Contudo, o grau de agilidade, embora abordado em alguns estudos
descritos na literatura técnica, está fora do escopo da revisão aqui apresentada.
3.7 Ameaças à Validade do Estudo
As limitações ou ameaças à validade deste estudo estão associadas com o
critério que governou a construção da string de busca. A idéia foi evitar a perda de
documentos relevantes. Entretanto, devido à escolha dos termos para formar as strings,
e devido a dificuldades em operar a máquina de busca da ACM digital library, há um
risco de que estudos relevantes possam ter sido omitidos.
O estudo identificou um conjunto de características de agilidade para processos
de software baseado em achados na literatura técnica. Não se pode ter certeza de que o
mesmo conjunto de características seria encontrado se a identificação das características
fosse feita com base em achados nos projetos ágeis de software reais, que possivelmente
poderia levar a resultados diferentes. Assim, pode haver outras características de
agilidade que poderiam ser identificadas se uma visão mais industrial fosse usada neste
estudo.
Também, embora evitasse influências, um critério de exclusão estabelecido no
protocolo (documentos relatando sobre características de um método ágil específico
serão excluídas) pode ter deixado de fora a consideração de alguma características de
agilidade diferente das 18 características identificadas através das 4 execuções do
protocolo.
3.8 Conclusão
Esta quasi – revisão sistemática contribuiu para coletar, identificar, organizar e
analisar as características de agilidade mais destacadas no contexto de processos de
software, seguindo tanto quanto possível uma abordagem de investigação isenta e
confiável (independentemente de processos ou métodos ágeis, comerciais ou não).
65
Foram realizadas execuções do protocolo (planejado para permitir repetição) ao longo
de 4 anos, permitindo a recuperação de mais de 6600 referências a documentos
publicados até janeiro de 2010 e utilizando 7 máquinas de busca diferentes. Foram
identificadas e consolidadas as descrições de 18 características de agilidade. Estas
características foram analisadas e ordenadas com base em sua incidência nos diversos
artigos técnicos.
O resultado deste estudo secundário permitiu que fosse feita uma proposta
preliminar para caracterização de processos ágeis de software. Esta caracterização pode
ser usada como ponto de partida para outros estudos mais específicos com relação à
inserção de um grau adequado de características de agilidade em processos de software
para um dado ambiente de desenvolvimento. Os resultados deste estudo devem ser
objeto de avaliação por um estudo primário planejado para tal fim. Esta avaliação é
necessária para que se possa utilizar as características identificadas com algum grau de
confiança, na busca de agilidade para diferentes processos de software, inclusive o
processo de testes.
No próximo capítulo serão apresentados os resultados da revisão de literatura
executada com o objetivo de identificar práticas ágeis que possam sem empregados nos
processos de software para torná-los ágeis.
66
4. Práticas Ágeis para Processos de Software
Neste capítulo são apresentados os resultados de uma revisão
sistemática de literatura efetuada com a finalidade de identificar
práticas ágeis no contexto dos processos ágeis de desenvolvimento
de software.
4.1 Introdução
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 apropriado e
mais rápido do que seus competidores (BOHEM, 2008). No mundo de hoje, a evolução
do ambiente de negócios das organizações desafia fortemente as práticas de engenharia
de software correntes. Em um contexto de negócios volátil, o desenvolvimento de
software tem que se deparar com esta nova realidade e lidar com a incerteza e as
mudanças rápidas no ambiente de negócios, fazendo uma reengenharia de seus métodos.
Tais aspectos precisam de mais atenção do que antes, pelo fato do software ter se
tornado fonte dominante de diferencial competitivo nos produtos e serviços das
organizações. Muitas das fontes de mudanças são freqüentes e imprevisíveis. A
morosidade para acomodar incertezas e mudanças rápidas leva inevitavelmente à
obsolescência do software e à insatisfação do cliente (KTATA e LÉVESQUE, 2009).
A comunidade de engenharia de software descobriu que os sistemas baseados
em software não são previsíveis, que as habilidade dos desenvolvedores variam
bastante, que documentos técnicos e planos ficam desatualizados muito rapidamente
depois que são produzidos, e que o esforço para mantê-los atualizados, em muitos casos,
é mais caro do que o valor que eles podem oferecer (KOEHNEMANN e COATS,
2009). Os métodos ou processos ágeis de desenvolvimento de software se apresentam
como uma alternativa para resolver questões associadas a esses fatos. Segundo
GLAZER (2010) tem sido demonstrado que os valores, os princípios e as práticas ágeis
podem trazer benefícios para muitas organizações.
67
Provavelmente uma das mais notáveis mudanças na metodologia de
desenvolvimento de software nos últimos 15 anos tenha sido a introdução da palavra
ágil. Uma extensa lista de práticas ágeis está disponível e cada prática está relacionada
com um ou mais aspectos do processo de desenvolvimento. As equipes de
desenvolvimento de software em geral e as equipes ágeis em particular necessitam de
ajuda na escolha da combinação adequada de práticas ágeis com base em suas reais
necessidades (ABBAS, GRAVELL e WILLS, 2010).
No capítulo 2 foi apresentada uma definição de processo (IEEE 610, 1990) que
não contempla as práticas de software. CUGOLA e GHEZZI (1998) definem processo
de software como um conjunto de atividades, métodos, práticas e transformações que
são utilizadas para desenvolver e manter software e seus produtos associados. Segundo
TAROMIRAD e RAMSIN (2009) uma definição completa de processo deve incluir
definições para ciclo de vida de desenvolvimento, papéis, atividades, linguagem de
modelagem, artefatos, práticas ou técnicas, regras e as chamadas atividades guarda-
chuva. Portanto, por esta definição, as práticas de software, fazem parte da definição de
um processo de software.
As práticas são as atividades que implementam os princípios que regem os
processos ou métodos. Estes por sua vez, são idéias, entendimentos ou objetivos que
estão por traz das práticas (JIANG e ARMIN, 2009).
A literatura técnica apresenta alguns métodos ágeis como alternativas para o
desenvolvimento de software, dentre os quais alguns podem ser destacados
(STAPLETON, 1997) (BECK, 1999) (BECK 1999A) (HIGHSMITH, 2000)
(COCKBURN, 2002) (PALMER e FELSING, 2002) (SCHWABER e BEEDLE, 2002)
(POPPENDIECK e POPPENDIECK, 2003) (BECK e ANDRES, 2004)
(POPPENDIECK e POPPENDIECK, 2006) (DSDM CONSORTIUM, 2008).
Coletivamente, as práticas recomendadas por estes e por outros métodos ágeis são
denominadas práticas ágeis (KOEHNEMANN e COATS, 2009).
Nos últimos anos, os métodos ágeis têm se apresentado como uma alternativa
para o desenvolvimento de software. Também pode ser observado o crescimento do
interesse das organizações desenvolvedoras de software por tais métodos. Os métodos
ágeis de desenvolvimento de software têm chamado a atenção 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
68
com mudanças culturais nos ambientes de desenvolvimento de software.
Segundo TAYLOR et al (2006) os métodos ágeis não são ad-hoc e requerem
disciplina por parte das equipes que os utilizam. As idéias em torno do uso de métodos
ágeis para desenvolvimento de software enfatizam ou destacam melhorias na satisfação
do cliente, na moral dos desenvolvedores e na qualidade do produto final
(SRINIVASAN e LUNDQVIST, 2009).
IKOMA et al. (2009) definem agilidade em desenvolvimento de software como
a minimização do tempo gasto desde a geração de produtos de trabalho até a validação
de entregas.
LARMAN (2004) afirma que os métodos ágeis formam um subconjunto dos
métodos iterativos e evolucionários, os quais já seriam utilizados desde a década de
1960. Para OLIVERA (2009) a agilidade é comumente vista como sendo a habilidade
de continuamente se adaptar a um ambiente em constantes mudanças, através da
mobilização dos recursos e processos que se fizerem necessários.
Segundo SHARP et al. (2009), as abordagens de desenvolvimento ágil envolvem
a adoção de um conjunto de práticas que se apóiam mutuamente. Por exemplo, XP
(BECK, 1999; BECK e ANDRES, 2004) pode envolver 13 práticas fundamentais
(como programação por pares) e 11 práticas subsidiárias (como implantação diária).
Nos métodos ágeis, o papel do usuário passa de apenas cliente para um real
associado, engajado no processo de desenvolvimento junto com a equipe. Desse modo,
os processos ágeis devem ser reforçados por uma organização rigorosa dos diferentes
aspectos do envolvimento do usuário em todos os passos do desenvolvimento do
software. Todos os métodos ágeis apóiam a integração do usuário no processo de
desenvolvimento, embora variem no modo e no grau de integração (BESSAM et al.,
2009).
BESSAM et al. (2009) conceituam métodos dirigidos a planos como sendo
caracterizados por iniciar com a elicitação de um conjunto completo de requisitos,
seguido de projeto arquitetural e projeto detalhado. Eles descrevem o que chamaram de
“um conjunto de definições famosas” para metodologias ágeis, encontradas na
literatura, que são relacionadas a seguir:
“Ser ágil significa ser efetivo e manobrável. Um processo ágil é ao mesmo
tempo leve e suficiente” (COCKBURN e HIGHSMITH, 2001);
69
“Um método ágil é uma derivação da prototipação rápida e da experiência de
desenvolvimento rápido, bem como a manifestação de uma filosofia segundo a qual
programar é uma atividade mais artesanal do que um processo industrial” (BOEHM e
TURNER, 2004a);
“Em geral, os métodos ágeis são processos bastante leves e que empregam
ciclos de iterações curtas; eles buscam envolver efetivamente o usuário para estabelecer,
priorizar e verificar os requisitos; tais métodos se amparam no conhecimento tácito de
uma equipe ao invés de enfatizar a documentação” (LARMAN, 2004);
“Os métodos ágeis são iterativos, incrementais, auto-organizáveis e emergentes”
(COHEN et al., 2004);
Contudo, CONBOY e FITZGERALD (2004) afirmam que não há definição
universalmente aceita para método ágil no campo de desenvolvimento de sistemas de
informação.
Os métodos ágeis contemplam, segundo seus proponentes, diversas práticas
ágeis, embora seja perfeitamente possível uma prática adotada em um processo de
software conduzir a resultados desejáveis em termos de agilidade, mesmo que tal prática
não esteja inserida em nenhuma das abordagens associadas com uma metodologia ágil
conhecida.
Para identificar as práticas ágeis em processos de software foi inicialmente
realizada uma revisão informal de literatura, na qual foi possível identificar 49 práticas
ágeis. Tais práticas foram incluídas em um estudo primário com o objetivo de avaliá-
las. Este estudo, com as 49 práticas identificadas através de revisão informal de
literatura, foi conduzido como piloto, e seus resultados iniciais estão relatados no
capítulo 5. Contudo, o levantamento de tais práticas não foi conduzido de forma
sistemática, mas através de uma revisão informal de literatura, e por esse motivo não
pode ser repetido. Além disso, não houve a elaboração de um protocolo de pesquisa que
explicitasse dentre outros aspectos envolvidos na revisão de literatura, os critérios de
inclusão e exclusão de estudos. Assim, a idéia é fazer desta vez uma revisão sistemática,
com um protocolo estabelecido, que possa ser repetido e propicie resultados coerentes
com o estado da arte no campo das práticas ágeis, tentando evitar que subjetividades
influenciem no resultado da revisão sistemática.
O objetivo desta revisão é portanto investigar quais são as práticas de software
recomendadas no contexto de abordagens ágeis para desenvolvimento de software. Um
70
protocolo de pesquisa foi elaborado e executado para conduzir uma revisão sistemática
de literatura, detalhadamente descrita por ABRANTES e TRAVASSOS (2011a). As
buscas foram realizadas em fevereiro de 2010. Os dados obtidos foram analisados e é
apresentada uma consolidação dessas práticas para ser considerada em processos de
software que busquem a agilidade.
A questão básica de pesquisa é determinar quais são as práticas de software
recomendadas para processos ágeis de desenvolvimento de software. Pretende-se chegar
a um conjunto de práticas ágeis de modo geral, que possam ser utilizadas para prover
agilidade a processos de software. Para tal, será realizado um estudo secundário para
investigar e identificar, através de revisão sistemática de literatura (BIOLCHINI et al.,
2005), as práticas de software recomendadas para processos ágeis de desenvolvimento
de software. Em suma, quais são as práticas de software que podem ser consideradas
práticas ágeis, no contexto das abordagens ágeis para desenvolvimento de software?
A questão de pesquisa será estruturada através de 4 elementos básicos:
população, intervenção, comparação e resultado [Pai et al, 2004]. Por se tratar de um
estudo de caracterização, não haverá comparação e nem será possível a aplicação de
meta-análise. Em decorrência disto, este estudo secundário, apesar de sistemático, é
considerado como uma quasi - revisão sistemática (TRAVASSOS et al., 2008) .
A motivação desta pesquisa é servir de apoio à busca de elementos (as práticas)
que possam ser utilizados como alternativa para embutir características de agilidade em
processos de software.
Este capítulo está estruturado da seguinte forma: na seção 4.2 é explicitado o
objetivo do trabalho. Na seção 4.3 é apresentado um protocolo elaborado
especificamente para esta revisão sistemática. Na seção 4.4 descreve-se a execução do
protocolo apresentado na seção 4.3. Na seção 4.5 são apresentados os resultados obtidos
com a revisão sistemática. Na seção 4.6 apresenta-se uma proposta de um conjunto de
práticas de software que podem ser utilizadas para se tentar embutir agilidade em
processos software. Na seção 4.7 são apresentadas as conclusões deste trabalho e
sugestões para seus possíveis desdobramentos.
71
4.2 Objetivo do Estudo
Pretende-se investigar e identificar, através de revisão sistemática de literatura,
quais são as práticas ágeis recomendadas no contexto de abordagens ágeis para
desenvolvimento de software.
Não se pretende focar em práticas para processos específicos, mas de modo
geral, identificar práticas consideradas ágeis que possam ser aplicadas em diversos
processos de software.
4.3 Protocolo da Quasi - Revisão Sistemática de Literatura
O protocolo planejado para esta revisão sistemática de literatura busca, além de
conduzir os trabalhos de pesquisa, possibilitar a repetição do estudo no futuro, seja para
fins de confirmação ou verificação de resultados, seja para fins de atualização do
conjunto de referências incluídas no estudo, através de nova execução formal de todos
os passos considerando novo período de tempo para as publicações pesquisadas. Será
adotada uma abordagem que estrutura a questão de pesquisa conforme apresentado por
PAI et al, (2004). A seguir, são apresentados os elementos que fazem parte do protocolo
adotado na pesquisa.
4.3.1 Objetivo
Identificar quais são as práticas de software recomendadas no contexto das
abordagens ágeis para desenvolvimento de software.
4.3.2 Formulação da Pergunta
Quais são as práticas de software que podem ser consideradas práticas ágeis, no
contexto das abordagens ágeis para desenvolvimento de software?
Problema:
Encontrar e identificar práticas ágeis de desenvolvimento de software.
Aplicação:
Servir de base ou apoiar pesquisas envolvendo práticas de software que podem
ser utilizadas como alternativa para embutir características de agilidade em processos de
software.
População:
72
Projetos de desenvolvimento de software.
Intervenção:
Processos ágeis de desenvolvimento de software.
Comparação:
Não há.
Resultado:
Conjunto de práticas ágeis.
Controles:
1- ABRAHAMSSON, P. SALO, O. RONKAINEN, J. WARSTA, J. (2002),
“Agile Software Development Methods. Review and Analysis”, Espoo. VTT
Publications 478.
2- COHEN, D. LINDVALL, M. COSTA, P. (2004), “An Introduction to Agile
Methods, in: M.V. Zelkowitz (Ed.), Advances in Computers, Advances in Software
Engineering, vol. 62, Elsevier, Amsterdam, 2004.
3- MESO, PETER. JAIN, RADHIKA. (2006) “Contemporary practices in
systems development. Agile Software Development: adaptive systems principles and
best practices”, Information Systems Management, summer.
4.3.3 Seleção de Fontes
As fontes serão bases de dados eletrônicas, disponíveis no portal CAPES,
incluindo conferências, journals e relatórios técnicos indexados por:
Compendex EI
IeeeXplore
Inspec
Web of Science
Scopus
Science Direct
ACM digital library
Estas fontes foram escolhidas porque são as que se tem acesso para recuperação
de referências, bem como maior facilidade para recuperação do texto completo do artigo
quando fosse o caso. Além disso, estas fontes foram consideradas significativas no
sentido de oferecerem publicações pertinentes e que podem contribuir
73
significativamente para o resultado da pesquisa. Estas fontes são consideradas
satisfatórias para apoiar a busca de literatura técnica envolvendo abordagens ágeis,
conforme execuções de protocolos de revisões sistemáticas anteriores sobre outros
temas no mesmo contexto. Além disso, não há disponibilidade de recursos adicionais
(fontes) para serem incluídos neste estudo.
Idioma:
Inglês, por ser maioria nas bases de dados pesquisadas. Em uma busca
preliminar, não foram encontrados artigos escritos em Português que trouxessem
contribuição para o tema da pesquisa. Além disso, textos em Português, embora se
reconheça a sua importância, muitas vezes não se encontram indexados, o que aumenta
o esforço ou impede sua busca.
Tipos de documentos:
Trabalhos ou artigos publicados em fóruns que os tenha submetido à revisão por
pares e que façam abordagem sobre práticas ágeis em processos ou métodos de
desenvolvimento de software.
4.3.4 Palavras-chave
População:
software projects, software systems, software development, software engineering
Intervenção:
agile approaches, agile processes, agile methods, agile methodologies, agile
development, agile software development, agile projects
Resultado:
practices, software practices, agile practices, subpractices, agile techniques,
techniques
4.3.5 Critérios de Inclusão e Exclusão
Os documentos devem estar disponíveis na web;
Os documentos devem contemplar práticas de software ou práticas ágeis no
contexto das abordagens ágeis de desenvolvimento de software;
Os documentos deverão apresentar uma descrição das práticas de software ou
práticas ágeis que contemplarem.
74
4.3.6 Processo de Seleção dos Estudos
O pesquisador aplica a estratégia de busca para a identificação de potenciais
documentos. Os documentos identificados são selecionados pelo mesmo pesquisador
através da leitura e verificação dos critérios de inclusão e exclusão estabelecidos.
Posteriormente a lista de documentos excluídos é avaliada por um segundo
pesquisador. Em caso de conflito o documento é incluído.
Ao final, os documentos são lidos pelos pesquisadores para extração de
informações sobre práticas de software ou práticas ágeis no contexto das abordagens de
desenvolvimento de software.
4.3.7 Avaliação da Qualidade dos Estudos
Não será feita por tratar-se de uma pesquisa para fins de caracterização de objeto
de estudo (as práticas ágeis). Será considerado que as fontes dos documentos são
confiáveis, e que os textos tenham passado por revisões externas que serviram de
filtragem para que tenham qualidade suficiente para contribuir com a revisão
sistemática.
4.3.8 Estratégia de Extração de Informações
Para cada estudo selecionado após a execução do processo de seleção, serão
extraidas as seguintes informações:
• Título do documento
• Autor(es)
• Fonte
• Ano de publicação
• Denominação e descrição da prática de software ou prática ágil
4.3.9 Sumarização de Resultados
Os resultados serão tabulados. Serão realizadas análises para identificar
similaridades e as práticas mais relevantes ou mais significativas para processos de
software no contexto de desenvolvimento ágil de software. Será considerada a
freqüência com que cada prática tenha sido apontada por diferentes autores.
75
4.3.10 String de Busca
Na medida do possível, a string de busca será a mesma para todas as máquinas
de busca. Contudo, poderá haver adaptações para se adequar a restrições de máquinas
de busca específicas, observando-se as seguintes diretrizes:
1. a string derivada deverá ser logicamente equivalente à string original, ou
2. na impossibilidade de se manter equivalência exata, deverá a string
derivada ser mais abrangente para evitar perda de documentos
potencialmente relevantes.
Os elementos básicos que estruturam a questão de pesquisa foram relacionados
do mesmo modo como foi feito para a questão de pesquisa da revisão sistemática de
literatura executada para identificar características de agilidade descrita no capítulo 3.
Segue-se, na Figura 4-1, a string adotada como base para todas as máquinas de
busca:
Figura 4-1 – String de Busca Básica (Práticas Ágeis)
4.4 Execução do Protocolo
As buscas foram realizadas utilizando as sete máquinas de busca de editoras ou
bibliotecas digitais disponíveis no portal CAPES: Compendex EI, IeeeXplore, Inspec,
Web of Science, Scopus, Science Direct, ACM digital library. Segue-se o detalhamento
do que foi realizado.
4.4.1 Avaliação das Strings de Busca
A execução das buscas, em todas as máquinas, foi efetuada com a string adotada
como base, apresentada na Figura 4-1. Esta string foi processada sem problemas pelas
máquinas Compendex EI, IeeeXplore, Inspec, Web of Science, Scopus, Science Direct.
Para a ACM digital library, foi necessário adaptar a string para atender às restrições
impostas por esta máquina de busca, sem contudo, perder sua equivalência lógica. As
buscas foram executadas na primeira semana de fevereiro de 2010, sem restrições de
data de publicação.
("software projects" or "software systems" or "software development" or "software engineering" ) AND("agile approaches" or "agile processes" or "agile methods" or "agile methodologies" or "agile development" or "agile software development" or "agile projects") AND ("practices" or "software practices" or "agile practices" or "subpractices" or "agile techniques" or "techniques")
76
Na Scopus, a busca foi executada na opção advanced search, sem
restrições de data. Na Science Direct a busca foi executada na opção expert search - all
sources - computer science, sem restrições de data. Na Compendex EI a busca foi
executada na opção advanced search, com autostemming off desmarcado, sem restrições
de data. Na Inspec a busca foi executada na opção basic search e include related terms
marcado, sem restrições de data. Na IeeeXplore a busca foi executada na opção adanced
search, com full text and metadata selecionados, sem restrições de data. Na Web of
Science a busca foi executada na opção search acessada na aba Web of Science, sem
restrições de data. Na ACM digital library a busca foi executada com a opção the guide
marcada na opção search, e depois na opção advanced search sobre os resultados, sem
restrições de data. A exportação das referências ocorreu sem problemas para as
máquinas da Compendex EI, Inspec, Web of Science, Scopus e Science Direct. Para a
IeeeXplore, teve que ser efetuada em grupos, por cada página de resultados. Para a
ACM digital library a exportação tornou-se impraticável, já que tinha que ser feita
individualmente por referência recuperada.
A importação das referências para o gerenciador de referências foi efetuada sem
problemas para as exportações feitas pelas máquinas da Compendex EI, Inspec, Web of
Science, Scopus e Science Direct. Para as exportações feitas pela máquina da
IeeeXplore, houve problemas com diversos registros quanto ao padrão bibtex, com
relação ao caracter ‘#’. As correções tiveram que ser feitas manualmente para que as
importações dos diversos arquivos exportados pudessem ser feitas com sucesso.
4.4.2 Execução das Buscas nas Bibliotecas Digitais
A execução das buscas com as sete máquinas acima citadas produziu as
quantidades de referências recuperadas conforme a Tabela 4-1 que se segue.
Tabela 4-1 – Quantidade Total de Referências Recuperadas
Biblioteca Digital Quantidade
Inspec 2124IeeeXplore 1849Scopus 1784Compendex EI 371Science Direct 343Web of Science 69ACM Dig Library 156
TOTAL 6696
77
JALALI e WOHLIN (2010), em seu trabalho de revisão sistemática de literatura
sobre o uso de práticas ágeis e desenvolvimento lean em engenharia de software global,
tentaram reduzir o número de referências irrelevantes recuperadas limitando as buscas a
apenas título, resumo e palavras-chave, além de terem utilizado uma máquina de busca
que permite restringir a recuperação apenas para publicações revisadas por pares (peer-
reviewed publications). Isto não foi adotado nesta revisão porque as máquinas de busca
disponíveis e efetivamente utilizadas não permitem o filtro que JALALI e WOHLIN
(2010) utilizaram em suas buscas. Além disso, tentar aumentar a precisão das buscas
limitando-as a apenas título, resumo e palavras-chave, traz o risco maior de perda de
referências relevantes. Já foram feitos testes em algumas máquinas de busca e elas não
retornaram a referência quando utilizados na search string os termos do conjunto de
palavras-chave extraídos da citação exportada para o gerenciador de referências.
4.4.3 Análise dos Documentos Recuperados
Todas as referências recuperadas foram importadas para o JabRef versão 2.5 ©
2009, disponível em http://jabref.sourceforge.net/, que foi o gerenciador de referências
utilizado para manipular as referências recuperadas pelas máquinas de busca. A
ferramenta JabRef foi muito útil para identificar repetições, categorizar referências,
priorizar leituras, tabular referências, exportar listas para recuperação de documento
completo, dentre outras manipulações de referências utilizadas durante esta revisão.
Nem todas as editoras / bibliotecas digitais permitem as mesmas facilidades para
exportação do material recuperado em formato que possa ser importado por um
gerenciador de referências. A Compendex EI, a Inspec, a Science Direct, a Scopus e a
Web of Science exportam de uma única vez todos os itens recuperados pelas respectivas
máquinas. A Inspec e Web of Science exportaram referências com muitos campos
faltantes (não preenchidos). A IeeeXplore só permite exportação por página de
resultado, além de apresentar incorreções no formato de muitas referências. Nesta
pesquisa, a IeeeXplore permitiu a exportação de 100 itens por página. A ACM digital
library só permite exportação item a item o que dificulta bastante o tratamento das
referências recuperadas.
As repetições foram eliminadas, mantendo-se o artigo remanescente
contabilizado para a biblioteca digital com maior quantidade de itens recuperados.
Todos os controles foram recuperados. O primeiro artigo utilizado como controle foi
78
recuperado pela máquina da Inspec; o segundo artigo utilizado como controle foi
recuperado pela máquina da Science Direct; e o terceiro artigo utilizado como controle
foi recuperado pelas máquinas da Inspec, Web of Science e Scopus. A nova situação
quantitativa, após eliminação de repetições, ficou conforme se observa na Tabela 4-2.
Tabela 4-2 – Quantidade de Referências Recuperadas sem Repetições
Biblioteca Digital Quantidade Sem repetiçãoInspec 2124 2101IeeeXplore 1849 1577Scopus 1784 1021Compendex EI 371 12Science Direct 343 231Web of Science 69 34ACM Dig Library 156 117
TOTAL 6696 5093
Foram recuperadas referências a artigos publicados entre 1998 e 2010. No
conjunto de referências recuperadas houve 23,9% de repetições.
Em seguida, foi feita uma avaliação dos documentos cujas referências haviam
sido recuperadas, a partir de título e resumo, excluindo-se as referências que
nitidamente não tratavam de assuntos pertinentes à pesquisa. Após eliminação também
de tais itens, a nova situação quantitativa ficou conforme mostra a Tabela 4-3.
Tabela 4-3 – Quantidade de Referências Recuperadas e Selecionadas
Biblioteca Digital Quantidade Sem repetição SelecionadosInspec 2124 2101 240IeeeXplore 1849 1577 89Scopus 1784 1021 93Compendex EI 371 12 1Science Direct 343 231 1Web of Science 69 34 15ACM Dig Library 156 117 2
TOTAL 6696 5093 441
4.4.4 Extração de Informações
Os artigos selecionados foram lidos e analisados minuciosamente, para verificar
se atendiam aos objetivos da pesquisa e às condições estabelecidas no protocolo
planejado para esta revisão.
79
Os dados coletados foram registrados em uma tabela com os seguintes campos,
conforme descrito na Tabela 4-4:
Tabela 4-4 – Descrições dos campos da tabela de dados coletados dos artigos
Campo Descrição / Finalidade
OrdemTem a finalidade de ordenar e servir para contar a quantidade de ocorrências de práticas nos artigos.
Código de Grupo
Visa possibilitar o agrupamento das ocorrências de práticas para fins de evitar repetições identificadas a partir de uma análise de descrição das diversas ocorrências para detectar igualdades, similaridades ou diferenças entre as ocorrências.
Prática Tem a finalidade de conter a denominação para a ocorrência.Descrição Conterá a descrição associada com a ocorrência da prática.
MétodoIdentificará a associação da ocorrência da prática com um método ágil, se houver.
Ano Ano de publicação do artigo associado à ocorrência da prática.
FonteReservado para o registro completo da referência ao artigo associado com a ocorrência da prática.
Seguindo os critérios estabelecidos no protocolo de pesquisa, as ocorrências de
práticas foram extraídas dos artigos e tabuladas. Artigos que tratavam de estudos de
desempenho ou questões específicas de uma prática específica não foram considerados.
Isso porque o resultado da revisão seria afetado fortemente e não corresponderia à
realidade uma vez que há uma quantidade bastante expressiva de trabalhos publicados
sobre as algumas práticas mais conhecidas, mais populares ou mais destacadas na
literatura.
Foram encontradas 236 ocorrências de práticas consideradas ágeis, em 24 dos
artigos selecionados. Os demais artigos selecionados trataram das práticas ágeis mas
não apresentaram uma descrição adequada do significado das práticas abordadas,
impedindo seu aproveitamento para o estudo, conforme condições estabelecidas no
protocolo. Os artigos dos quais os dados foram extraídos estão listados no apêndice B.
Tais artigos foram publicados no período de 2001 até 2009.
4.5 Análise dos Resultados Obtidos
As 236 ocorrências de práticas ágeis coletadas foram analisadas a partir de suas
denominações e descrições, para fins de se identificar repetições. A partir da análise
feita, as ocorrências foram agrupadas, levando a um quantitativo de 51 práticas
distintas. Após o levantamento destas 51 práticas distintas foi feito um trabalho de
análise das ocorrências, visando derivar uma denominação e uma descrição comum e
80
consolidada para cada uma das 51 práticas. A Tabela 4-5 a seguir, uma versão
simplificada do apêndice B, é utilizada como auxiliar e fonte de referências para a
tabela seguinte (Tabela 4-6) visando simplificar a apresentação das informações.
Tabela 4-5 – Referências Auxiliares para as Fontes das Práticas
Ref. Fontes das Práticas
1Abrahamsson, P. Salo, O. Ronkainen, J. Warsta, J. (2002) “Agile Software Development Methods. Review and Analysis”, Espoo. VTT Publications 478.
2Aiello, G. Alessi, M. Bruccoleri, M. D’Onofrio C. Vella, G. (2007) “An Agile methodology for Manufacturing Control Systems development”, Engisud S.p.a., Palermo, Italy.
3
Cannizzo, Fabrizio. Marcionetti, Gabriela. Moser, Paul. (2008) “The Toolbox Of A Successful Software Craftsman”, 15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems.
4
Cohen, D. Lindvall, M. Costa, P. (2004) “An Introduction to Agile Methods”, Advances in Computers, Advances in Software Engineering, vol. 62, M. V. Zelkowitz, Ed. Amsterdam: Elsevier.
5
Concas, Giulio. Francesco, Marco Di. Marchesi, Michele. Quaresima, Roberta. Pinna, Sandro. (2008) “Study of the Evolution of an Agile Project Featuring a Web Application Using Software Metrics”, A. Jedlitschka and O. Salo (Eds.): PROFES 2008, LNCS 5089, pp. 386–399
6
Fruhling, Ann. De Vreede, Gert-Jan. (2006) “Field Experiences with eXtremeProgramming: Developing anEmergency Response System”, Journal of Management Information Systems / Spring Vol. 22, No. 4. pp. 39-68.
7
Hazzan, O. Tomayko, J. (2003) “The Reflective Practitioner Perspective in eXtreme Programming”, Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2753, 51-61.
8
Huo, Ming. Verner, June. Zhu, Liming. Ali Babar, Muhammad. (2004) “Software Quality and Agile Methods”, Proceedings of the 28th Annual International Computer Software and Applications Conference (COMPSAC’04).
9
Jureczko, Marian. (2008) “The Level of Agility in Testing Process in a Large Scale Financial Software Project”, In: Software engineering techniques in progress, Oficyna Wydawnicza Politechniki Wrocławskiej, 139-152.
10 Kniberg, Henrik. (2007) “Scrum and XP from the Trenches”, C4Media, Publisher of InfoQ.com. *
11Koehnemann, Harry. Coats, Mark. (2009), “Experiences Applying Agile Practices to Large Systems”, In: 2009 Agile Conference.
12Martin, Angela. Biddle, Robert. Noble, James. (2009) “XP Customer Practices: A Grounded Theory”, 2009 Agile Conference.
13Maurer, Frank. Martel, Sebastien. (2002) “Extreme Programming Rapid Development for Web-Based Applications”, IEEE Internet Computing, January - February.
14
McKinney, Dawn. Denton, Leo F. (2005) “Affective Assessment of Team Skills in Agile CS1 Labs: The Good, the Bad, and the Ugly”, SIGCSE ’05, February 23–27, 2005, St. Louis, Missouri, USA.
15
Mills, David. Sherrell, Linda. Boydstun, Jeff. Wei, Guoqing. (2005) “Experiences Using Agile Software Development for a Marketing Simulation”, Dept. of Comput. Sci., Memphis Univ., TN USA.
16Paige, Richard F. Brooke, Phillip J. (2005) “Agile Formal Method Engineering”, J. Romijn, G. Smith, and J. van de Pol (Eds.): IFM 2005, LNCS 3771, pp. 109–128.
17Paulk, Mark C. (2001) “Extreme Programming from a CMM Perspective”, IEEE Software, November/December.
18
Ramachandran, Vinay. Shukla, Anuja. (2002) “Circle of Life, Spiral of Death: Are XP Teams Following the Essential Practices?”, Dept. of Comput. Sci., North Carolina State Univ., Raleigh NC USA
19Stolberg, Sean. (2009) “Enabling Agile Testing Through Continuous Integration”, 2009 Agile Conference.
81
Ref. Fontes das Práticas
20
Svensson, Harald. H¨ost, Martin. (2005) “Introducing an Agile Process in a Software Maintenance and Evolution Organization”, Proceedings of the Ninth European Conference on Software Maintenance and Reengineering (CSMR’05).
21
Vejandla, Pavan K. Sherrell, Linda B. (2009) “Why an AI Research Team Adopted XP Practices”, Proceedings of the 47th Annual Southeast Regional Conference, ACM-SE 47, March 19-21, Clemson, SC, USA.
22
Williams, Laurie. Upchurch, Richard. (2001) “Extreme Programming for Software Engineering Education?”, 31st ASEE/IEEE Frontiers in Education Conference, October 10 - 13, 2001 Reno, NV.
23
Xiaohua，Wang. Zhi, Wu. Ming, Zhao. (2008) “The Relationship between Developers and Customers in Agile Methodology”, 2008 IEEE International Conference on Global Software Engineering.
24
Xu, Bin. (2009) “Towards High Quality Software Development with Extreme Programming Methodology: Practices from Real Software Projects”, College. of Computer Science & Information Engineering, Zhejiang Gongshang University, Hangzhou China.
25
Zhou, Yinghua. (2009) “UniX Process, Merging Unified Process and Extreme Programming to Benefit Software Development Practice”, 2009 First International Workshop on Education Technology and Computer Science.
*fonte utilizada como apoio, não recuperada pelas máquinas de busca
A Tabela 4-6 a seguir, mostra as denominações de cada prática resultante, com
as respectivas denominações das práticas cujas descrições foram consolidadas, bem
como a fonte de cada uma delas. As fontes das práticas consolidadas estão referenciadas
à coluna “Ref.” da Tabela 4-5 apresentada anteriormente.
Tabela 4-6 – Práticas Consolidadas
Denominação daPrática Resultante
Denominações dasPráticas Consolidadas
Fontes dasPráticas Consolidadas
Cliente presente
Active stakeholder participation
[4]
Customer collaboration [11]
On Site Customer [1,4,5, 6,7, 8,13,14,16,18,20,22,23, 24, 25]
Real Customer Involvement
[12]
Equipe completa Whole Team [12,15]
Display models publicly [4]
Informative work environment
[10]
Maximum project status visibility
[3]
Progress reporting [1]
Visibilidade de Projeto Project visibility [11]
Integração Contínua Continuous integration [1,4,5,6,8,9,10,11,13,15,16,17,18,19,20,22,23,25]
Acceptance testing [2,8]
Customer Tests [15]
82
Denominação daPrática Resultante
Denominações dasPráticas Consolidadas
Fontes dasPráticas Consolidadas
Customer Tests and Test-Driven Development
[21]
Test Driven Development [2,5,10,11,15,25]
Functional Test [22]
Test-driven [14,23]
Testing [1,6,7,13,16,17,18]
Tests [4]
Desenvolvimento orientado a testes Unit Testing
[22]
Code Refactoring [11]
Design Improvement [15]
Refatoração Refactoring [1,4,5,6,8,13,16,17,18,20,22,25]
Programação em par Pair programming [1,4,5,6,7,8,10,11,13,14,15,16,17,18,20,21,22,25]
Adaptive planning [11]
Planning game [1,4,6,7,11,13,15,16,17,20,21,22,23,25]
Sprint Planning meeting [10]
Sprint Planning meeting [1]
Staging [1]
Jogo de planejamento The Planning Game [18]
Developing by Feature [1]
Small / Short Releases [1]
Small release [24]
Small releases [4,6,7,13,15,16,17,18,20,22,25]
Liberações freqüentes (Releases curtas) Sprint
[1]
Metaphor [1,4,7,13,15,16,17,18,20,22,25]
Metáfora System metaphor [6,8,23]
Create simple content [4]
Depict models simply [4]
Design simples Simple design [1,4,6,13,15,16,17,18,20,22,25]
83
Denominação daPrática Resultante
Denominações dasPráticas Consolidadas
Fontes dasPráticas Consolidadas
Collective Code Ownership
[5,14,15,20,22,25]
Propriedade coletiva do código Collective ownership
[1,4,6,7,10,13,16,17,18]
40 hour-week [1,4,7,16,17,18,20,22]
Energized Working [12]
Forty-hour week [6]
Sustainable Pace [10]
Sustainable development [13]
Ritmo sustentável Sustainable Pace [4,15]
Espaço de trabalho aberto Open Workspace
[1,4,22]
Apply modeling standards [4]
Padrões de Código Coding standards [4,6,7,10,13,15,16,17,18,20,22]
Feature List [4]
Backlog de produto Product Backlog [1,10]
Daily Scrum meeting [1]
Reunião diária [10]
Reuniões diárias Stand-up Meetings [4,14]
A distribuição dos 24 artigos utilizados neste estudo, por ano de publicação
ficou conforme a tabela Tabela 4-7 que se segue:
Tabela 4-7 – Artigos por Ano de Publicação
Ano de Publicação Quantidade de Artigos2001 22002 32003 12004 22005 42006 12007 12008 42009 6
TOTAL 24
84
O gráfico na Figura 4-2 que se segue dá uma visão dos percentuais de
documentos aproveitados por ano de publicação.
Figura 4-2 – Percentuais de Documentos por ano de Publicação
Em 2009, observa-se um crescimento expressivo da quantidade de artigos
publicados que satisfazem os critérios estabelecidos no protocolo desta revisão. Seria
temeroso fazer qualquer afirmação sobre este fato, sem uma investigação adequada para
apoiar uma análise conclusiva. Contudo, o mesmo fato pode ser observado em outras
buscas efetuadas nas mesmas fontes, em 4 outras execuções de protocolos de revisão
sistemática. Naquelas execuções, pode-se observar uma tendência de crescimento da
quantidade de artigos publicados sobre abordagens ágeis, independentemente dos
artigos satisfazerem ou não os critérios estabelecidos no protocolo para que sejam
selecionados. Possivelmente, este fato pode estar associado a um interesse crescente por
parte da comunidade de engenharia de software pelas abordagens ágeis de
desenvolvimento de software.
Dentre as 236 ocorrências de práticas ágeis coletadas nos artigos, há práticas
associadas a algumas metodologias ágeis comerciais propostas na literatura a saber:
Extreme Programming (BECK, 1999; BECK e ANDRES, 2004), Scrum (SCHWABER
e BEEDLE, 2002), Feature Driven Development (PALMER e FELSING, 2002),
Crystal (COCKBURN, 2002), Agile Modeling (AMBLER, 2002). Houve também
ocorrências de práticas consideradas ágeis de um modo geral, não estando associadas a
qualquer método ágil comercial. A Tabela 4-8 que se segue mostra cada uma das 51
0,0%
5,0%
10,0%
15,0%
20,0%
25,0%
2001 2002 2003 2004 2005 2006 2007 2008 2009
Percentuais de Documentos Aproveitados por ano de Publicação
85
práticas ágeis distintas identificadas no estudo, com as respectivas freqüências de
ocorrências nos artigos.
Tabela 4-8 – Quantidade de Artigos por Prática
PráticaQuant Artigos
Desenvolvimento orientado a testes 21Integração contínua 19Programação em par 17Jogo de planejamento 17Cliente presente 16Propriedade coletiva do código 15Liberações freqüentes (Releases curtas) 15Metáfora 14Refatoração 14Ritmo sustentável 13Design simples 13Padrões de código 11Equipe completa 5Visibilidade de projeto 4Reuniões diárias 3Espaço de trabalho aberto 3
Backlog de produto 2
Aplicação do artefato correto 1Automação completa da maioria das tarefas de desenvolvimento 1Consideração da testabilidade 1Criação de modelos em paralelo 1Descarte de modelos temporários 1Modelagem de objetos do domínio 1Estimativa de esforço 1Feature teams 1Formalização de modelos de contrato 1Estratégia de diversidade holística 1Retroalimentação imediata 1Propriedade individual de código 1Inspeção 1Iteração com outro artefato 1Regras justas 1Técnica de ajuste de metodologia 1Modelagem em pequenos incrementos 1Modelagem para comunicar 1Modelagem para entender 1Modelagem com os interessados 1Monitoramento 1Paralelismo e avanço contínuo 1Prova com código 1Oficinas (workshops) de reflexão 1Reutilização de recursos 1Revisão e recapitulação 1
86
PráticaQuant Artigos
Análise de causa raiz 1Equipes auto-organizadas com base em cenários 1Sprint backlog 1Reunião de revisão de sprint 1Atualização apenas quando necessário 1Utilização de ferramentas simples 1Histórias de usuário 1
Visões de usuário 1
Dentre estas práticas distintas, 34 ocorreram apenas uma vez nos artigos. As
demais 17 práticas foram abordadas mais de uma vez, sendo a maioria delas associadas
a duas metodologias comerciais bastante difundidas no mercado e na literatura técnica
(Extreme Programming e Scrum). As 17 práticas abordadas mais de uma vez são:
Backlog de produto, Cliente presente, Desenvolvimento orientado a testes, Design
simples, Equipe completa, Espaço de trabalho aberto, Integração contínua, Jogo de
planejamento, Metáfora, Padrões de código, Programação em par, Propriedade coletiva
do código, Refatoração, Liberações freqüentes (Releases curtas), Reuniões diárias,
Ritmo sustentável, Visibilidade de projeto.
O gráfico da Figura 4-3 que se segue mostra os percentuais de incidência de
cada uma destas 17 práticas nos artigos selecionados.
Figura 4-3 – Percentuais de Incidência nos Artigos
Práticas - Percentuais de Incidência nos Artigos
0,0%
10,0%
20,0%
30,0%
40,0%
50,0%
60,0%
70,0%
80,0%
90,0%
100,0%
Desen
volvi
men
to o
rient
ado
a te
stes
Inte
graçã
o co
ntín
ua
Progr
amaç
ão e
m p
ar
Jogo
de
plan
ejam
ento
Client
e pr
esen
te
Propr
ieda
de c
oletiv
a do
código
Relea
ses
curta
s
Met
áfora
Refat
oraç
ão
Ritmo
sust
entá
vel
Design
sim
ples
Padrõ
es de
códi
go
Equipe
com
plet
a
Visibil
idade
de p
roje
to
Reuni
ões
diária
s
Espaç
o de
trab
alho
abe
rto
Backlo
g de
pro
duto
Práticas
Per
cen
tuai
s
87
Observa-se que as práticas consideradas na literatura técnica como fundamentais
para o sucesso das metodologias ou processos ágeis, de uma certa forma, coincidem
com as que tiveram maior incidência nos artigos.
Após a análise das denominações das práticas ágeis nas 236 ocorrências
identificadas, bem como das respectivas descrições apresentadas nos diversos artigos,
foi feito um trabalho de consolidação chegando-se a um conjunto de descrições
consolidadas que são apresentadas na Tabela 4-9 a seguir, para as 17 práticas com mais
de uma ocorrência nos artigos.
Tabela 4-9 – Práticas com mais de uma ocorrência nos artigos
Prática Descrição ConsolidadaBacklog de produto
Esta prática inclui tarefas para criação de uma lista de backlog de produto, e seu controle durante o processo de inserção, remoção, atualização e priorização dos itens da lista. A lista de backlog de produto define tudo o que é necessário para o produto final baseado no conhecimento atual que dele se tem. O backlog de produto define o trabalho a ser feito no projeto, incluindo uma priorização e constante atualização da lista de requisitos para o sistema sendo construído ou melhorado. Itens de backlog podem incluir, por exemplo, funcionalidades, correção de erros, defeitos, requisições de melhorias, atualizações de tecnologia, etc. Questões que requeiram solução antes de outros itens de backlog serem trabalhados, também podem estar na lista.
Cliente presente
Em termos práticos, isso significa colocar o cliente fisicamente próximo aos desenvolvedores ou mover os desenvolvedores para próximo do cliente. Esta prática indica que o cliente deve fazer parte da equipe de desenvolvimento. Para esclarecer e validar requisitos e estabelecer prioridades, um representante de cliente presente trabalha junto da equipe. Trabalhando junto dos desenvolvedores todo o tempo, o cliente pode responder perguntas, resolver questões, estabelecer prioridades, fazer testes de aceitação e assegurar que o desenvolvimento tenha o progresso esperado. Quando surgirem questões, os programadores podem resolver imediatamente com o cliente, ao invés de tentar imaginar quais seriam suas preferências. Esta prática também leva o cliente a mudar mais prontamente os requisitos, ajudando a equipe a mudar o foco dos esforços de desenvolvimento para as necessidades mais prementes.
Desenvol-vimento orientado a testes
Todo programador escreve casos de teste antes de escrever o código. Os testes devem ser escritos antes da implementação e conter o que for necessário para verificar se o código se comporta de acordo com os requisitos do usuário. O desenvolvedor ou testador deve escrever os casos de teste assim que os requisitos estiverem definidos. Além de escrever os testes de unidade antes da codificação, os desenvolvedores devem encorajar os usuários a escrever os testes de aceitação. Ao ser executado pela primeira vez, o caso de teste irá falhar, uma vez que o desenvolvimento do código que implementa a condição sendo testada ainda não foi gerado. Então, escreve-se código apenas o suficiente para o caso de teste passar, seguido de refatoração para remover duplicações e melhorar a legibilidade do código. Escrever drivers de teste antes da codificação força o desenvolvedor a pensar no problema antes da programação. Esta prática aplicada corretamente garante uma suíte de testes para fins de teste de regressão, além de prover documentação para o código implementado, servindo de casos de uso para este mesmo código. Deve-se ter o cliente escrevendo testes de aceitação, que podem se tornar casos de teste de um plano geral de testes para o sistema. Antes de o progarmador integrar o seu código à base de código, ele deve ter todos os seus
88
Prática Descrição Consolidadapróprios testes passando, além de todos aqueles testes já escritos e já incorporadosà base, que também deverão passar. Isto assegura que o novo código sendo integrado para implementar uma nova funcionalidade não quebre o código de alguém que já havia sido incorporado à base de código.
Design simples A ênfase desta prática está em projetar a solução mais simples possível que seja aceitável no momento. Complexidade desnecessária e código extra devem ser removidos assim que reconhecidos. Não se deve incluir aspectos adicionais aos artefatos sem uma boa justificativa para tal. A prática do design simples requer que a equipe não projete para satisfazer necessidades futuras, as quais os desenvolvedores não devem tentar prever. A abordagem de desenvolvimento mais efetiva em termos de custo deve focar em resolver os problemas de hoje ao invés de projetar para mudanças futuras que não se sabe se realmente ocorrerão. Deve-se fazer a coisa mais simples que possa funcionar.
Equipe completa
Refere-se à prática de incluir todos os perfis e perspectivas necessários na equipe para que ela possa ter bom desempenho, enfatizando o espírito de equipe, com todos os seus membros compartilhando um propósito e apoiando-se mutuamente. Clientes, usuários e demais interessados devem ter um envolvimento direto no projeto, a fim de possibilitar entender o comportamento do sistema mais cedo no ciclo de vida.
Espaço de trabalho aberto
Os desenvolvedores devem trabalhar em uma área comum. Uma sala grande com pequenas baias é preferível. Os pares de programadores devem ocupar o centro da área. O layout deve prever áreas comuns para facilitar a comunicação entre as pessoas. Uma configuração alternativa do espaço pode ter estações de trabalho individuais na periferia e máquinas de uso coletivo no centro.
Integração contínua
Na integração contínua, os membros da equipe devem integrar seu trabalho frequentemente, toda vez que novas mudanças ou uma tarefa for completada, para revelar problemas de integração e detectar falhas de sistema o mais cedo possível. Cada pessoa deve fazer a integração pelo menos uma vez por dia. Isto garante que sempre esteja disponível uma versão executável do sistema, contendo todas as novas funcionalidades e modificações, podendo servir de baseline para o trabalho. Depois da integração, todos os testes devem passar, ou o novo código deve ser descartado. Os integrantes da equipe podem fazer a integração sempre que desejarem, a não ser em curtos períodos de tempo em que o código é congelado. Cada integração deve ser verificada imediatamente ou à noite através de uma build automática com execução de todos os testes de integração. Esta prática é um exemplo de uma técnica dinâmica de garantia de qualidade.
Jogo de planejamento
Juntos desenvolvedores e clientes atuam no jogo de planejamento no qual o cliente escolhe as histórias de usuário que incluem os requisitos mais importantes a serem incluídos em uma entrega curta e incremental. Cada incremento curto implementado é experimentado pelo cliente. As histórias remanescentes são reavaliadas em termos de requisitos e prioridades, sendo o jogo de planejamento jogado novamente para definir o próximo incremento a ser implementado. A meta do jogo de planejamento é balancear os interesses do cliente com a capacidade da equipe. O planejamento é contínuo e progressivo. Os desenvolvedores estimam o custo das funcionalidades candidatas e o cliente as prioriza com base no custo e no valor agregado para o negócio. Uma das grandes vantagens do jogo de planejamento é a participação ativa do cliente e da equipe, com o processo de desenvolvimento sendo conhecido por todos. Diretrizes que levam a decisões relacionadas com liberações ou iterações específicas ficam claras para todos, pois cliente e equipe as definem juntos. Após as histórias de usuário terem sido definidas, a equipe de desenvolvimento fornece ao cliente uma estimativa de tempo para implementar cada uma delas. O cliente então prioriza as históriasconsiderando estas estimativas. Posteriormente a equipe informa ao cliente o tempo que irão trabalhar no próximo incremento e baseado nisso o cliente seleciona as histórias que a equipe irá implementar em seguida. Os desenvolvedores então dividem as histórias em tarefas, mas sem envolver o
89
Prática Descrição Consolidadacliente com detalhes de implementação.
Metáfora Esta prática consiste em apresentar uma estória simples e compartilhada que explica a essência de como o sistema funciona para dar a desenvolvedores e cliente um entendimento comum do projeto. De um certo modo, a metáfora serve como uma arquitetura de alto nível para o software. A metáfora serve para fazer a ligação de um domínio conhecido com um domínio com o qual não se está familiarizado. Pensando sobre uma metáfora apropriada, os desenvolvedores expandem suas perspectivas de análise da aplicação sendo desenvolvida. Há dois propósitos principais para a metáfora. Um é a comunicação. A metáfora preenche a lacuna entre desenvolvedores e usuários assegurando facilidades na discussão sobre o software e no fornecimento de exemplos. O segundo propósito é que a metáfora pode apoiar a equipe no desenvolvimento de uma arquitetura para o software.
Padrões de código
Pelo fato de os desenvolvedores programarem diferentes partes do sistema com vários membros da equipe, a adoção de padrões de código é bastante interessante. Eles facilitam o entendimento do código, aumentam a legibilidade e melhoram a consistência entre membros da equipe. Os padrões devem ser fáceis de serem seguidos e devem ser adotados voluntariamente. Deve ser acordado pela equipe, assegurando que a comunicação possa ser feita via código, além de levar os desenvolvedores a entender facilmente o código de seus colegas. Esta prática libera o programador de tomar decisões com respeito a um estilo, torna mais fácil a adoção da prática de programação em par, além de apoiar a prática de propriedade coletiva de código.
Programação em Par
É um esforço de trabalho não isolado onde os desenvolvedores trabalham juntos provendo revisões contínuas e melhoram o perfil geral da equipe. A meta é criar um ambiente que encoraje o aprendizado em equipe e freqüentes revisões em pares. Todo o código produzido é escrito por duas pessoas ao mesmo tempo na mesma máquina. Programando com um parceiro, o programador alterna papéis de controlador e navegador. O controlador tem o controle do teclado e do mouse, se preocupando com questões como saber se a abordagem adotada irá funcionar e se pode ser simplificada mais tarde. Na medida em que implementa o código o controlador vai explicando seu trabalho para o navegador. As principais responsabilidades do controlador são o desenvolvimento dos testes e a construção do algoritmo, ao passo que as obrigações do navegador são observar erros de sintaxe e de semântica, pensando mais estrategicamente e decidindo se aquela é a melhor maneira de implementar a funcionalidade. O par muda de papéis frequentemente durante o dia. À medida em que os dois desenvolvedores do par pensam em diferentes níveis de abstração, a mesma tarefa também é pensada em dois diferentes níveis de abstração ao mesmo tempo. Esta prática ombro-a-ombro serve de processo contínuo de projeto e revisão, levando a redução das taxas de defeito. Esta prática tem sido amplamente reconhecida como inspeção contínua de código. A programação em par também eleva a robustez da equipe, permitindo que ela supere melhor a perda ou a adição de um novo membro. Com a programação em par, o risco do projeto associado à perda de um programador chave é reduzido porque existem várias pessoas familiarizadas com cada parte do sistema.
Propriedade coletiva do código
O repositório de código deve ser de livre acesso para todos os programadores e cada um deve poder fazer mudanças sempre que necessário. Uma vez na base de código, qualquer membro da equipe tem a posse sobre todo código. Todos são encorajados a fazer mudanças no código, em qualquer parte e a qualquer tempo que sintam a necessidade de fazê-las, sem ter que pedir permissão para quem quer que seja. Esta prática pode remover o gargalo de software que normalmente está relacionada com a posse individual do código. Qualquer par de programadores que veja uma oportunidade de adicionar valor a qualquer parte do código pode fazê-lo a qualquer tempo. A propriedade coletiva do código, além de ajudar na melhoria do código, dá mais flexibilidade aos programadores para se ausentar em
90
Prática Descrição Consolidadacasos de necessidade ou para saírem de férias. A disponibilidade de drivers de teste automatizados faz com que os desenvolvedores tenham mais liberdade para modificar o código sem maiores receios de eventuais repercussões que possam causar. Ao poder examinar código escrito por outros, os programadores podem refletir e considerar as razões que levaram os colegas a tomar determinadas decisões específicas. Ao revisar o código escrito por outros, os programadores podem melhorar o entendimento de seu próprio código e de suas interfaces com as demais partes da codificação do software.
Refatoração O software se deteriora com o tempo. Um projeto inicialmente limpo torna-se progressivamente nebuloso a cada modificação nele introduzida. Quando o software tem uma documentação mínima, o código fonte deve permanecer simples e fácil de entender. A refatoração é uma técnica disciplinada para se reestruturar um corpo de código existente ou para constantemente melhorar sua inteligibilidade e manutenibilidade, bem como o seu projeto, alterando sua estrutura interna sem mudar seu comportamento externo nem a funcionalidade do sistema. Foca no código simples, limpo e não repetitivo, que pode ser modificado facilmente. A essência da prática é uma série de pequenas transformações que preservam comportamento. Cada transformação é chamada refatoração e faz pouca coisa, mas uma seqüência delas pode produzir uma reestruturação significativa. Pelo fato da refatoração ser pequena, a possibilidade de algo dar errado é também pequena, com o sistema permanecendo totalmente funcional após cada pequena refatoração. Durante a refatoração os desenvolvedores reconstroem o código e isto provê inspeção da sua funcionalidade. As diferentes formas de refatoração podem envolver a simplificação de declarações complexas, a abstração de soluções comuns para fins de reuso e a remoção de código duplicado. Esta prática reduz a probabilidade de geração de erros durante o desenvolvimento. Entretanto, a prática de refatoração é altamente dependente do conjunto de casos de teste de unidade automatizados. Quando o código é refatorado, ele deve ainda passar por todos os casos de teste de unidade armazenados na base. Se algum caso de teste falhar depois da refatoração, ou o código ou os próprios testes devem ser corrigidos.
Liberações freqüentes (Releasescurtas)
Esta prática visa maximizar o retorno dos projetos assegurando que o maior valor de negócio possível seja entregue ao final de cada release e que cada release tenha uma duração curta. Isso é feito através do processo contínuo de priorização que seleciona sempre as histórias de maior valor para serem implementadas primeiro. Além disso, procura antecipar o retorno entregando software rapidamente. Ciclos curtos reduzem os riscos, possibilitando ao cliente terminar rapidamente com projetos que não agreguem valor para o negócio. Além disso, ciclos de Liberações frequentes ajudam a lidar com mudanças nos requisitos e reduzem o impacto de erros de planejamento. Ao final de cada release, o cliente revê todo o produto podendo identificar defeitos e fazer ajustes nos requisitos futuros.
Reuniões diárias
As reuniões diárias em pé são reuniões rápidas, geralmente de 15 minutos, organizadas para acompanhar o progresso do projeto, destacar questões importantes e organizar as atividades diárias. Cada membro da equipe relata rapidamente no que está trabalhando e o progresso já alcançado. Durante a reunião todos devem ficar de pé, para encorajar os participantes a serem objetivos, não ultrapassar o tempo previsto para a reunião, além de manter todos alertas e com atenção voltada para os assuntos tratados.
Ritmo sustentável
Esta prática enfatiza que se deve trabalhar apenas a quantidade de horas que se possa manter produtividade de modo sustentável. Não trabalhar mais de 40 horas por semana é a regra, além de não mais de 8 horas por dia. Em períodos difíceis quando se trabalha além do tempo, os artefatos produzidos são pobres em qualidade. Os requisitos devem ser selecionados para cada iteração de modo que os desenvolvedores não precisem trabalhar fora de horário nem fazer horas-extras.
Visibilidade de projeto
Projetos ágeis por sua natureza estão continuamente mudando (planos, modelos, código e demais artefatos). Deve haver esforços para fornecer às equipes o status
91
Prática Descrição Consolidadado projeto em que estão engajadas. A psicologia mostra que quanto mais imediata a retroalimentação, mais rapidamente as pessoas mudam o comportamento para se adequar a novas situações. Pode ser criado um painel na web para manter a qualquer tempo o status e as métricas relacionadas com o progresso do projeto. Múltiplos painéis podem ser usados para disponibilizar diferentes tipos de informação que atendam a todos os níveis organizacionais necessários. O avanço do projeto com relação às histórias de usuário que as equipes se comprometeram a entregar no final das iterações deve ser incluído. Modelos devem se tornar acessíveis para todas as equipes.
As práticas que no intervalo de tempo das publicações selecionadas vem sendo
abordadas em publicações de mais de 6 anos diferentes são Desenvolvimento orientado
a testes, Integração contínua, Programação em par, Jogo de planejamento, Cliente
presente, Propriedade coletiva do código, Liberações freqüentes (Releases curtas),
Metáfora, Refatoração, Ritmo sustentável, Design simples, Padrões de código.
4.6 Proposta de Práticas Ágeis para Processos de Software
O desempenho de qualquer prática em termos de agilidade, depende do
ambiente em que é aplicada, do contexto de projeto, da forma de implementação
escolhida para se adotar a prática no processo e também da intensidade com que é
aplicada e acolhida pela equipe.
Contudo, dentre as 51 práticas distintas identificadas nesta revisão, diversas
delas (34) foram alvo de interesse dos pesquisadores apenas pontualmente, a grande
maioria antes de 2004.
Há trabalhos publicados que apontam estudos (surveys) envolvendo mais de 60
práticas ágeis. Já foi feito no contexto de pesquisa do qual faz parte esta revisão, um
ensaio de um survey envolvendo avaliação de 49 práticas ágeis identificadas por revisão
convencional de literatura.
A proposta agora é dar continuidade aos trabalhos de pesquisa, considerando em
princípio, as 17 práticas ágeis consolidadas neste estudo e que não foram alvo de
interesse dos pesquisadores apenas pontualmente, mas abordadas mais vezes ao longo
do tempo. Estas práticas são: Backlog de produto, Cliente presente, Desenvolvimento
orientado a testes, Design simples, Equipe completa, Espaço de trabalho aberto,
Integração contínua, Jogo de planejamento, Metáfora. Padrões de código, Programação
92
em par, Propriedade coletiva do código, Refatoração, Liberações freqüentes (Releases
curtas), Reuniões diárias, Ritmo sustentável, Visibilidade de projeto.
4.7 Conclusões
Foi planejado um protocolo para conduzir uma quasi - revisão sistemática com o
objetivo de identificar quais são as práticas de software recomendadas no contexto das
abordagens ágeis para desenvolvimento de software.
O protocolo foi executado com a utilização de máquinas de busca de 7 bases de
dados digitais. Foram recuperados 6.696 referências a documentos, a partir da estratégia
de busca traçada no protocolo.
Dentre os documentos selecionados para o estudo 24 deles atenderam os
critérios estabelecidos no protocolo gerando 236 ocorrências de práticas ágeis, sendo 51
delas distintas. As práticas foram analisadas sendo que em publicações de 2001 até 2009
34 delas foram abordadas pontualmente (apenas uma vez). As demais 17 práticas
tiveram incidência mais significativa nos artigos pesquisados e foram aqui selecionadas
para dar prosseguimento ao trabalho de pesquisa, em um contexto mais amplo,
envolvendo inserção de agilidade em processos de software através da adoção de
práticas que possam embutir características de agilidade em tais processos.
Além disso, as práticas aqui identificadas tiveram suas descrições, conforme
apresentadas nos artigos, analisadas minuciosamente, para que a partir delas fosse
possível derivar descrições consolidadas para as práticas identificadas. As descrições
consolidadas das 17 práticas aqui propostas foram apresentadas em uma tabela
específica na seção 4.5.
A princípio não se descarta qualquer prática ágil como potencial candidata a uso
na inserção de agilidade em processo de software, dependendo evidentemente das
atividades incluídas em tal processo, às quais a prática possa apoiar. Contudo, a
expectativa é considerar a possibilidade de utilizar como ponto de partida, as 17 práticas
aqui indicadas, após passarem por avaliações.
No próximo capítulo são relatados os resultados de um estudo primário efetuado
com a finalidade de avaliar as características de agilidade identificadas com a quasi-
revisão sistemática descrita no capítulo 3, bem como avaliar as práticas ágeis
identificadas com a quasi - revisão sistemática descrita neste capítulo 4.
93
5. Avaliação de Características e Práticas Ágeis
Neste capítulo são apresentados os resultados de um estudo primário
executado com o objetivo de avaliar as características de agilidade e
as práticas ágeis identificadas através das revisões sistemáticas
apresentadas nos capítulos 3 e 4.
5.1 Introdução
As abordagens de desenvolvimento ágil envolvem a adoção de um conjunto de
práticas que se apóiam mutuamente (SHARP et al., 2009). Uma alternativa de solução
para se embutir características de agilidade em processos de teste de software pode se
basear, portanto, na adoção de um conjunto adequado de práticas de software que irão
concorrer para prover agilidade ao processo. Esta idéia em princípio abre algumas
frentes de pesquisa para investigar e identificar, dentre outras: (1) quais características
de agilidade são pertinentes e devem ou podem ser candidatas a serem inseridas em um
processo de teste de software com a finalidade de torná-lo ágil? (2) quais práticas ágeis
de software são pertinentes e podem ser consideradas para serem adotadas em processos
de teste de software com o objetivo de se tentar embutir características de agilidade
neste processo? (3) quais práticas ágeis estão relacionadas com que características de
agilidade?
Buscando responder as duas primeiras questões, foram realizadas revisões
sistemáticas de literatura para identificar as características de agilidade a serem
consideradas em processos de software (Capítulo 3), bem como para identificar as
práticas ágeis que poderiam ser adotadas nos processos (Capítulo 4) para neles embutir
as características de agilidade desejadas. As características de agilidade e as práticas
ágeis identificadas através das duas revisões sistemáticas de literatura tornaram-se
objeto de estudo em uma pesquisa de opinião planejada para avaliar a pertinência e o
nível de relevância de cada uma delas.
A pesquisa de opinião foi executada duas vezes. A primeira execução aconteceu
em 2009 serviu como piloto para buscar eventuais adequações em seu planejamento
94
visando a execução definitiva. Naquela oportunidade foram utilizadas 18 características
de agilidade identificadas através de revisão sistemática de literatura (capítulo 3) e 49
práticas ágeis identificadas através de revisão convencional de literatura (mencionada
no capítulo 4).
Após a análise dos resultados da primeira execução, foi decidido realizar uma
revisão sistemática de literatura para identificar as práticas ágeis que poderiam ser
consideradas para se tentar embutir características de agilidade em processos de
software (ABRANTES e TRAVASSOS, 2011a) e substituir, na pesquisa de opinião,
aquelas encontradas originalmente por revisão convencional de literatura.
O planejamento da pesquisa de opinião foi atualizado com os resultados da
revisão sistemática de práticas ágeis, e foi novamente executado, em 2011, com
características de agilidade e práticas ágeis identificadas através dos estudos
secundários. Os resultados foram analisados e consolidados para prosseguimento dos
trabalhos desta pesquisa.
Este capítulo está estruturado da seguinte forma: na seção 5.2 é apresentada a
metodologia e o planejamento da pesquisa de opinião. Na seção 5.3 são apresentados e
discutidos os resultados alcançados com a execução do estudo. Na seção 5.4 as ameaças
à validade do estudo são apresentadas. Na seção 5.5 é apresentada uma conclusão para o
estudo.
5.2 Planejamento do Estudo
5.2.1 Definição de Objetivos
O objetivo deste estudo é observar quais atributos (características) podem ser
considerados pertinentes para caracterizar um processo de software como sendo ágil e
quais práticas de software são relevantes para se alcançar a inserção de características
de agilidade em processos de software, sob a perspectiva de pesquisadores em
desenvolvimento ágil de software.
5.2.1.1 Objetivo Global
O objetivo global é analisar um conjunto de características de agilidade e um
conjunto de práticas ágeis identificados através de revisões sistemáticas de literatura
(capítulos 3 e 4) quanto à sua pertinência e relevância relacionadas com a possibilidade
95
de embutir agilidade em um processo de software do ponto de vista de pesquisadores
interessados nas abordagens ágeis para desenvolvimento de software.
5.2.1.2 Objetivo de Medição
O objetivo de medição é, a partir de um conjunto inicial de características de
agilidade, analisar:
1. Quais características de agilidade (incluídas no conjunto inicial) são
pertinentes para caracterizar um processo de software como sendo ágil e devem ser
mantidas no conjunto de características de agilidade para processos de software;
2. Quais características de agilidade (incluídas no conjunto inicial) não são
pertinentes para caracterizar um processo de software como sendo ágil e devem ser
excluídas do conjunto de características de agilidade para processos de software;
3. Quais características de agilidade não incluídas no conjunto inicial e
sugeridas pelos participantes são pertinentes para caracterizar um processo de software
como sendo ágil e devem ser incluídas no conjunto de características de agilidade para
processos de software;
4. Qual é a ordem de relevância das características de agilidade, quando se
considera agilidade em um processo de software.
5. Quais práticas ágeis de software (incluídas no conjunto inicial) são
pertinentes para serem adotadas em um processo ágil de software e devem ser mantidas
no conjunto inicial;.
6. Quais práticas ágeis de software (incluídas no conjunto inicial) não são
pertinentes para serem adotadas em um processo ágil de software e devem ser excluídas
do conjunto inicial de práticas ágeis de software;
7. Quais as práticas ágeis de software não incluídas no conjunto inicial e
sugeridas pelos participantes são pertinentes para serem adotadas em um processo ágil
de software e devem ser incluídas no conjunto de práticas ágeis de software;
8. Qual é a ordem de relevância das práticas ágeis de software, quando se
considera a adoção de práticas ágeis em um processo ágil de software.
5.2.1.3 Objetivo do Estudo
O objetivo do estudo é:
96
Analisar um conjunto de características de agilidade
Com o propósito de caracterizar
Com respeito a sua pertinência para caracterizar um processo de software como sendo
ágil, e a relevância de cada característica de agilidade
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 um conjunto de práticas ágeis de software
Com o propósito de caracterizar
Com respeito a sua pertinência relacionada com abordagens ágeis para um processo de
software, e a relevância de cada prática ágil
Do ponto de vista de pesquisadores em processos ágeis de software,
No contexto de projetos de software que adotam abordagens ágeis de desenvolvimento.
O objeto de estudo inclui as características de agilidade e as práticas ágeis
identificadas conforme descrito na seção 5.1.
5.2.1.4 Questões de Pesquisa
As questões de pesquisa consideradas são,
Q1: As características de agilidade extraídas da literatura técnica são pertinentes
para caracterizar um processo de software como sendo ágil?
Métrica 1: número de características de agilidade classificadas como
pertinentes para caracterizar um processo ágil de software, de acordo com a opinião dos
participantes do estudo.
Q2: Existe alguma característica de agilidade adicional que seja pertinente para
caracterizar um processo ágil de software que não está presente no conjunto inicial?
Métrica 2: número de características de agilidade adicionais para serem
incluídas no conjunto inicial, de acordo com a opinião dos participantes do estudo.
Q3: Existe alguma característica de agilidade presente no conjunto inicial que
não é pertinente para caracterizar um processo ágil de software?
Métrica 3: número de características de agilidade não pertinentes e que devem
ser removidas do conjunto inicial, de acordo com a opinião dos participantes do estudo.
97
Q4: Qual a ordem de relevância de todas as características de agilidade no
conjunto final de características de agilidade, quando se considera uma abordagem ágil
para processos de software?
Métrica 4: ordem em um conjunto de características de agilidade, ordenado por
nível de relevância.
Q5: As práticas ágeis de software extraídas da literatura técnica são pertinentes
com relação às abordagens ágeis para processos de software?
Métrica 5: 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 participantes 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?
Métrica 6: 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?
Métrica 7: número de práticas ágeis de software não pertinentes e que devem ser
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 processos de software que sejam ágeis?
Métrica 8: ordem em um conjunto de práticas ágeis, ordenado por nível de
relevância.
5.2.2 Planejamento Detalhado
5.2.2.1 Definição de Hipóteses
Na definição de hipóteses, os significados de cada variável devem ser
considerados como descrito a seguir.
Cc – conjunto inicial de características de agilidade;
Cf – conjunto final de características de agilidade;
98
Cr – conjunto de características de agilidade classificadas como não pertinentes
e que precisam ser removidas do conjunto inicial de características de agilidade
do estudo;
Ci – conjunto de características de agilidade não presentes no conjunto inicial e
indicadas como pertinentes, que precisam ser incluídas no conjunto inicial de
características de agilidade;
CRLj – nível de relevância para a característica j, onde j é um número entre 1 e
n;
n – total de características de agilidade que foram consideradas pertinentes;
Pc – conjunto inicial de práticas ágeis de software;
Pf – conjunto final de práticas ágeis de software;
Pr – conjunto de práticas classificadas como não pertinentes e que precisam ser
removidas do conjunto inicial de práticas ágeis do estudo;
Pi – conjunto de práticas não presentes no conjunto inicial, indicadas como
pertinentes e que precisam ser incluídas no conjunto inicial de práticas ágeis de
software;
PRLj – nível de relevância para a prática j, onde j é um número entre 1 e m;
m – total de práticas ágeis que foram consideradas pertinentes;
As métricas já elencadas na seção 5.2.1.4, junto com as questões de pesquisa,
são definidas conforme se segue:
M1- número de características de agilidade classificadas como pertinentes para
caracterizar um processo ágil de software, de acordo com a opinião dos
participantes do estudo.
M1 = | Cc | - |Cr|
M2- número de características de agilidade adicionais para serem incluídas no
conjunto inicial, de acordo com a opinião dos participantes do estudo.
M2 = | Ci |
M3- número de características de agilidade não pertinentes e que devem ser
removidas do conjunto inicial, de acordo com a opinião dos participantes do estudo.
99
M3 = | Cr |
M4- ordem em um conjunto de características de agilidade, ordenado por nível
de relevância.
M4 = { CRLj │ 1 ≤ j ≤ n }
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
participantes do estudo.
M5 = | Pc | - |Pr|
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.
M6 = | Pi |
M7- número de práticas ágeis de software não pertinentes e que devem ser
removidas do conjunto inicial de acordo com a opinião dos participantes do estudo.
M7 = | Pr |
M8- ordem em um conjunto de práticas ágeis, ordenado por nível de relevância.
M8 = { PRLj │ 1 ≤ j ≤ m }
As hipóteses são definidas a seguir.
Hipótese Nula 1 (H0 1): o conjunto inicial de características de agilidade é
considerado completo, isto é, todas as características de agilidade presentes no conjunto
inicial são pertinentes para a caracterização de agilidade em processos de software, e
nenhuma característica deve ser incluída nem removida.
H0 1: | Cc | ≠ 0 e M1 = | Cc | e M2 = 0 e M3 = 0
Hipótese Alternativa (H1): existem características de agilidade no conjunto
inicial de características de agilidade que foram classificadas como não pertinentes para
100
a caracterização de agilidade em processos de software. Portanto, elas precisam ser
removidas do conjunto inicial de características de agilidade.
H1: | Cc | ≠ 0 e M 3 ≠ 0
Hipótese Alternativa (H2): existem características de agilidade não presentes
no conjunto inicial de características de agilidade que foram indicadas 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: | Cc | ≠ 0 e M2 ≠ 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.
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: k,j | CRLk ≠ CRLj,
( onde k e j são números entre 1 e n, e k ≠ j )
Hipótese Nula 3 (H0 3): o conjunto inicial de práticas ágeis de software está
completo, isto é, todas as práticas presentes no conjunto inicial são relevantes ou
pertinentes com relação a abordagens ágeis para processos de software, e nenhuma
prática deve ser incluída nem excluída.
H0 3: | Pc | ≠ 0 e M7 = 0 e M6 = 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: | Pc | ≠ 0 e M7 ≠ 0
101
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. Portanto, elas precisam ser incluídas do
conjunto inicial de práticas ágeis.
H5: M6 ≠ 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.
H0 4: PRL1 = PRL2 = … = PRLm
Hipótese Alternativa (H6): existe pelo menos uma prática ágil de software com
nível de relevância diferente das demais práticas ágeis relacionadas com abordagens
ágeis para processos de software.
H6: k,j | PRLk ≠ PRLj,
( onde k e j são números entre 1 e m, e i ≠ j )
5.2.2.2 Definição da Instrumentação
O propósito desta pesquisa de opinião é definir quais características de agilidade
são pertinentes e podem ser mais relevantes para a obtenção de agilidade em processos
de software e quais práticas são pertinentes e podem ser mais relevantes para conduzir à
inserção de características de agilidade nestes processos. A pesquisa de opinião será
preenchida por pesquisadores que estão trabalhando ou estão preocupados com
processos ágeis, identificados nos artigos obtidos com as buscas associadas às revisões
de literatura que foram efetuadas para identificar as características de agilidade e as
práticas ágeis inicialmente incluídas no estudo. Para evitar influências, os autores de
artigos descrevendo características de agilidade e/ou práticas ágeis identificadas
através das revisões de literatura não serão convidados para participar do estudo.
Os pesquisadores participantes devem indicar quatro aspectos:
1. Se as características de agilidade apresentadas podem ser consideradas
pertinentes ou não para caracterizar um processo de software como sendo
102
ágil, e se é necessário incluir novas características de agilidade com seu
significado, ou excluir alguma característica do conjunto inicial.
2. Depois da definição do conjunto final de características de agilidade
pertinentes, 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 e
significa que a característica não tem qualquer influência na caracterização de
um processo de software como sendo ágil. A agilidade de um processo de
software 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). Indica que a característica não afetaria
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 iria
comprometer seriamente a agilidade de um processo de software em todos ou na
maioria dos cenários ou ambientes de desenvolvimento.
(2) Altamente relevante (muito relevante). Indica que a característica tem forte
ou considerável influência na caracterização de um processo de software como
sendo ágil. A ausência da característica comprometeria a agilidade de um
processo de software em todos ou na maioria dos cenários ou ambientes de
desenvolvimento.
(3) Absolutamente relevante. Indica que a característica é vital ou imperativa na
caracterização de um processo de software com sendo ágil. A ausência da
característica impediria a caracterização de um processo de software como um
processo ágil.
3. 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
excluir alguma prática do conjunto inicial de práticas ágeis de software.
103
4. Depois da definição do conjunto final de práticas ágeis pertinentes, é
desejado 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. Quatro níveis de relevância foram
definidos:
(0) Não relevante (sem relevância). É o mais baixo grau de relevância e
significa que 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 seria 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). Indica que a prática não afetaria
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 iria
comprometer seriamente a abordagem ágil para um processo de software em
todos ou na maioria dos cenários ou ambientes de desenvolvimento.
(2) Altamente relevante (muito relevante). Indica que a prática tem forte ou
considerável influência na adoção de uma abordagem ágil. A ausência da
prática comprometeria a abordagem ágil para um processo de software em
todos ou na maioria dos cenários ou ambientes de desenvolvimento.
(3) Absolutamente relevante. Indica que a prática é vital ou imperativa para a
adoção de uma abordagem ágil. A ausência da prática impediria a adoção da
abordagem ágil para um processo de software.
O questionário foi disponibilizado na internet. Os participantes serão contatados
via email. No email de contato eles receberão um código de login e uma senha para
acessar o questionário, evitando que pessoas não autorizadas participem e introduzam
viés nos resultados.
O questionário está dividido em cinco partes:
caracterização do participante;
identificação das características de agilidade pertinentes para
caracterizar um processo de software como um processo ágil;
104
definição do nível de relevância das características de agilidade para
apoiar a caracterização de um processo de software como um
processo ágil;
identificação das práticas ágeis pertinentes para abordagem ágil de
processo de software;
definição do nível de relevância das práticas ágeis de software na
adoção de uma abordagem ágil para um processo de software.
5.2.2.3 Diretrizes para Análise
Atribuindo Peso a um Participante
Para diferenciar as respostas dos participantes, será atribuído um peso para cada
participante de acordo com quatro perspectivas: a formação acadêmica, o número de
artigos sobre processos ágeis publicados, o nível de experiência com o uso de
abordagens ágeis nos projetos de software, o número total de projetos de software
utilizando processos ágeis nos quais participou. A fórmula utilizada para definir o peso
do participante, adaptada de FARIAS (2002), é:
MedianTP
itieipifiS
)()()()()( onde:
• 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, se o participante tem graduação;
= 1, se o participante tem especialização;
= 2, se o participante tem o grau de mestre;
= 3, se o participante tem o grau de doutor;
• 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, se o número de artigos está entre 1 e 2;
= 1, se o número de artigos está entre 3 e 4;
= 2, se o número de artigos está entre 5 e 6;
= 3, se o número de artigos é maior do que 6;
105
• 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, se o nível de experiência é baixo;
= 1, se o nível de experiência é médio;
= 2, se o nível de experiência é alto;
= 3, se o 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.
• Median TP é a mediana do número total de projetos de software
utilizando abordagens ágeis, considerando as respostas de todos os participantes.
As faixas de valores para o indicador p(i) foram definidas 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 de
características de agilidade apresentada no capítulo 3. Foi utilizada uma população de
artigos cujas referências estavam registradas no gerenciador de referências
bibliográficas, 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 recuperados
e contados 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.
Estas medidas serviram de base para a definição das opções de valor para o
indicador sobre o número de artigos relacionados com processos ágeis ou com métodos
ágeis publicados pelo participante.
Identificando a Pertinência das Características de Agilidade e das
Práticas Ágeis
106
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ísticas/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
contexto das abordagens ágeis de software, é necessário primeiramente computar as
respostas de cada participante e considerar seu respectivo peso, tanto para as
características quanto para as práticas. A computação das respostas com os respectivos
pesos, bem como o patamar de corte adotado foi efetuada através das fórmulas a seguir
apresentadas, adaptadas do trabalho de FARIAS (2002) sobre planejamento de riscos
em ambientes de desenvolvimento de software:
m
iiSjiAnswerjPertinence
1))(*),(()( onde:
• Pertinence(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.
• Answer(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
pertinente 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 Pertinence(j) se todos os participantes
respondessem sim com relação à sua pertinência no contexto das abordagens ágeis de
software.
m
iiSThreshold
1)(*5,0 onde:
107
• S(i) é o peso atribuído ao participante i
• m é o total de participantes que responderam à pesquisa
Portanto o critério fica assim:
• Se Pertinence(j) < Treshold então a característica/prática j é
classificada como não pertinente e deve ser removida do conjunto
inicial.
• Se Pertinence(j) ≥ Treshold 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
agilidade/prática ágil, 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 serão consideradas
como pertinentes.
Identificando a Ordem de Relevância das Características de
Agilidade e das Práticas Ágeis
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
respostas de cada participante (multiplicadas por seus respectivos pesos).
m
iiSjiScalejRLevel
1))(*),(()( onde:
• RLevel(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
• Scale(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
108
Após este passo, as características de agilidade/práticas ágeis serão ordenadas
por seus respectivos RLevel(j). A característica/prática mais relevante será aquela com
o maior valor de RLevel(j).
5.2.2.4 Seleção de Contexto
O estudo será executado através do acesso dos participantes a um website para
preencher o questionário, recurso já utilizado por outros pesquisadores em diversos
trabalhos na área de engenharia de software como em SPINOLA et al. (2008), DIAS
NETO e TRAVASSOS (2008), AMBLER (2009), RICO (2011, 2011A) e SANTA
ISABEL (2011), dentre outros. Cada participante terá tempo ilimitado para preencher o
questionário. Cada participante deverá preencher as informações relacionadas com sua
caracterização; depois disso, ele/ela deve indicar a pertinência de um conjunto de
características de agilidade (apresentado em ordem alfabética) para caracterizar um
processo de software como sendo ágil; em seguida ele/ela deverá definir o nível de
relevância destas características; então ele/ela deve indicar a pertinência de um
conjunto de práticas ágeis de software (também apresentadas em ordem alfabética) no
contexto de adoção de uma abordagem ágil para processos de software; e finalmente,
ele/ela deverá definir o nível de relevância destas práticas ágeis.
5.2.2.5 Seleção de Participantes
Conforme indicado na seção 5.2.2.2, a população para esta pesquisa de opinião é
formada por autores de artigos científicos publicados relacionados com abordagens
ágeis identificados e referenciados nas revisões sistemáticas de literatura sobre
características de agilidade e práticas ágeis apresentadas nos capítulos 3 e 4 deste
documento.
Os participantes serão contatados por email e poderão acessar um website onde o
questionário estará disponível, utilizando um código para login e uma senha enviada no
corpo do email de contato.
5.2.2.6 Variáveis
As variáveis independentes do estudo são:
o conjunto inicial de características de agilidade,
109
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,
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.
5.2.2.7 Validade
5.2.2.7.1 Validade de Conclusão
A população será selecionada dentre autores de artigos científicos publicados,
relacionados com abordagens ágeis (Capítulos 3 e 4). Uma das preocupações quanto à
validade de conclusão do estudo está relacionada com a possibilidade de introdução de
influências nas respostas dos participantes. Para evitar isso, não foram convidados a
participar do estudo, os autores de artigos descrevendo características de agilidade e
práticas ágeis, aproveitados nas revisões sistemáticas de literatura que foram a fonte das
características e práticas agora avaliadas.
Supõe-se que esta população é representativa no contexto dos pesquisadores em
abordagens ágeis, sendo que eles responderão ao questionário utilizando seu
conhecimento e experiência neste campo de pesquisa.
Após executar o estudo com essa população, será avaliado o nível de confiança
dos dados obtidos, utilizando-se uma fórmula adaptada de HAMBURG (1980)
apresentada a seguir:
)*/()(0 nNnNE onde:
• E0 = Erro
• N = Tamanho da população
• n = Tamanho da amostra
110
• 1 - E0 = Nível de Confiança
Quanto à validade de conclusão do estudo, a verificação da H0 1 (Hipótese Nula
1) será 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 conjunto de
características a serem removidas do conjunto inicial. O conjunto final de
características de agilidade será definido adicionando-se ao conjunto inicial as
características presentes no conjunto de características a serem incluídas e também
removendo-se do conjunto inicial as características presentes no conjunto de
características a serem excluídas. O resultado destas duas operações produzirá o
conjunto final de caracterí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) é:
1. Para o conjunto de características de agilidade a serem removidas, a
pertinência associada com a característica deve ser menor do que o
patamar estabelecido e já descrito na seção 5.2.2.3;
2. Para ser inserida no conjunto de características de agilidade a serem
incluídas, uma característica com a respectiva descrição de seu
significado deve ser indicada por pelo menos dois participantes.
A verificação da H0 2 (Hipótese Nula 2) será 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áticas ágeis será definido adicionando-se ao conjunto inicial as práticas presentes no
conjunto de práticas a serem incluídas e também removendo-se do conjunto inicial as
práticas presentes no conjunto de práticas a serem excluídas. O resultado destas duas
operações produzirá o conjunto final de práticas ágeis. O critério utilizado para definir
os itens de cada conjunto mencionado (práticas a serem incluídas e práticas a serem
removidas) é:
111
1. Para o conjunto de práticas a serem removidas, a pertinência associada
com a prática 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 descrição de seu significado deve ser indicada por pelo
menos dois participantes.
5.2.2.7.2 Validade de Constructo
Quanto à validade de constructo, este estudo é caracterizado por uma suposta
validade 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 é
validar a pertinência do conjunto inicial de características de agilidade, além de
permitir sua evoluçã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.
5.2.2.7.3 Validade Externa
Quanto à validade externa deste estudo, os participantes são considerados
representativos 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 1998. 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 descrevendo características de agilidade identificadas e consideradas nas
revisões sistemáticas, pois seria possível alguma argumentação de que as opiniões de
tais pesquisadores eventualmente poderiam influenciar os resultados, pelo fato de eles
próprios terem apresentado as características de agilidade em seus artigos, dentro dos
critérios estabelecidos no protocolo 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 foram definidos
utilizando-se diferentes trabalhos científicos publicados na literatura técnica sobre
abordagens ágeis. Cada participante poderá responder o questionário sem limitação de
tempo. Contudo, o questionário digital direcionará o participante para que ele defina, de
acordo com sua percepção, a pertinência das características de agilidade para
112
caracterizar um processo de software como sendo ágil, o nível de relevância de cada
característica de agilidade, a pertinência das práticas ágeis na adoção de uma
abordagem ágil para um processo de software, e o nível de relevância de cada prática
com relação a abordagem ágil para processos de software.
5.2.3 Detalhes de Instrumentação
A instrumentação a ser utilizada neste estudo foi idealizada para ser tão simples
quanto possível e demandar a mínima quantidade de tempo para os participantes
responderem as questões. Esta instrumentação é composta por sete telas numeradas de 1
a 7 como descrito na Tabela 5-1. A língua utilizada no instrumento de pesquisa é a
língua inglesa, por ser a mais acessível e tendo em vista as mais variadas nacionalidades
dos participantes convidados para fazer parte do estudo.
Tabela 5-1 - Telas do Instrumento de Pesquisa
Tela Id Descrição da Tela1 Tela de Login 2 Caracterização do Participante3 Pertinência das Características de Agilidade4 Nível de Relevância das Características de Agilidade5 Pertinência das Práticas de Software6 Nível de Relevância das Práticas de Software7 Tela de Agradecimento
Todas as telas são formatadas em 4 blocos, conforme a representação
esquemática apresentada na Figura 5-1.
Figura 5-1 - Representação Esquemática das Telas do Instrumento de Pesquisa
Bloco 0: contém o título da instrumentação e é fixo em todas as telas.
Bloco 1: contém texto com uma explicação sobre o estudo, na tela 1. Nas telas 2, 3, 4 5 e 6 este bloco contém os passos do questionário. Na tela 7 este bloco estará vazio.
Bloco 2: contém o corpo do questionário. Seu conteúdo varia conforme a tela.
Na tela 1: formulário de autenticação. Na tela 2: corpo da caracterização do participante. Na tela 3: corpo da questão de pertinência das características de agilidade. Na tela 4: corpo da questão do nível de relevância das características de agilidade. Na tela 5: corpo da questão de pertinência das práticas ágeis. Na tela 6: corpo da questão do nível de relevância das prática ágeis de software. Na tela 7: este bloco fica vazio.
Bloco 3: contém as opções de navegação através das telas do instrumento de pesquisa. Na primeira tela ele está vazio. Na penúltima tela (tela 6) ele contém o comando para finalizar as respostas do questionário. Na última tela (tela 7) ele contém o comando para fechar o instrumento.
113
Os detalhes da definição de cada tela da instrumentação estão descritos no
apêndice C. Na Figura 5-2, é apresentado exemplo de uma das telas.
Figura 5-2 - Tela de Pertinência das Características de Agilidade.
As demais telas da instrumentação também são apresentadas no apêndice C
deste documento.
5.3 Resultados e Discussão
5.3.1 Resultados da Primeira Execução do Estudo
Na primeira execução do estudo (julho-agosto de 2009), a população de
participantes da pesquisa de opinião totalizou 141 pesquisadores e incluiu:
os autores dos artigos que foram aproveitados na revisão sistemática de
literatura sobre características de agilidade;
os autores dos demais artigos não aproveitados como contribuintes
diretos com as características de agilidade, mas que tiveram suas idéias
citadas no relatório de resultados da revisão sistemática, nas três
execuções do protocolo;
os signatários originais do Manifesto Ágil em 2001;
114
os profissionais certificados do DSDM CONSORTIUM (2008) com
registros disponíveis no portal da entidade.
A instrumentação da pesquisa de opinião foi disponibilizada via web. Após o
término do prazo em que a instrumentação ficou disponível para preenchimento das
respostas, os resultados foram avaliados seguindo as diretrizes de análise previstas no
plano da pesquisa de opinião descrito na seção 5.2.
O instrumento esteve disponível desde o final do mês de maio de 2009 até o
início do mês de setembro de 2009 no endereço http://lens-ese.cos.ufrj.br/surveyagile/.
Aos participantes foi enviado um convite por email, junto com um login e senha de
acesso. Foram convidados 141 participantes. Dos 141 e-mails enviados, 32 retornaram,
sendo que destes 32, foi possível obter novos endereços para 4 participantes. Assim
chegou-se ao total de 113 emails enviados. Dos 113 enviados, 6 retornaram mensagens
automáticas dizendo que estariam fora de seus locais de trabalho até o mês seguinte. Os
emails para os participantes que ainda não haviam respondido foram novamente
enviados no início do mês de agosto de 2009. Até o início do mês de setembro houve 6
acessos ao instrumento de pesquisa, por 6 participantes diferentes, sendo que apenas 4
deles registraram suas respostas. Infelizmente não há mecanismos adequados para se
verificar se todas as mensagens enviadas por email chegaram aos seus destinatários.
Além dos emails que explicitamente retornaram, há aqueles que apesar de não terem
sido retornados foram obtidos em artigos publicados há bastante tempo e podem não
estar mais sendo utilizados.
Para cada participante foram tabulados seus atributos de caracterização e
computado um peso individual conforme descrito no plano da pesquisa de opinião
(seção 5.2). A Tabela 5-2 a seguir mostra os resultados para cada participante
(identificador, nível de formação, número de artigos publicados sobre métodos ou
processos ágeis, nível de experiência com abordagens ágeis em projetos de software,
número de projetos de software de que participou aplicando abordagens ágeis, peso
calculado para participante). As respostas de cada pesquisador serão ponderadas com
um peso diferenciado de acordo com seu nível de experiência e/ou habilidade.
115
Tabela 5-2 – Caracterização dos Participantes e Cálculo dos Pesos Individuais
Identif.Nível de
FormaçãoNúmero
de ArtigosNível de
ExperiênciaNúmero
de Projetos
Peso Calculado Origem
3 Dsc / Phd 16 Médio 3 1.75 Austrália
7 Especializ. 0 Alto 99 0.75 NI
9 Dsc / Phd 6 Médio 2 1.5 USA
10 Dsc / Phd 30 Muito Alto 5 2.25 NI NI = não informado
Como foram enviados 113 emails com endereços supostamente válidos, e houve
resposta de 4 participantes, o nível de confiança fica em torno de 50,9 % dos dados
coletados.
Uma vez obtidos os pesos dos participantes, pode-se passar para a análise dos
resultados 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 5.2 deste documento, após os cálculos para cada característica de
agilidade avaliada foi elaborada a Tabela 5-3 que se segue, mostrando a pertinência e o
nível de pertinência para cada característica. Detalhes e passos intermediários para
análise dos dados obtidos e como chegar aos valores da Tabela 5-3 estão descritos na
seção 5.2 onde foi apresentado o planejamento para esta pesquisa de opinião. As
descrições detalhadas das características de agilidade foram apresentadas no capítulo 3.
Tabela 5-3 – Avaliação da Pertinência das Características de Agilidade
Ident. Característica PertinênciaNível de
Pertinência
4 Adaptabilidade 6.25 100.00%
9 Emergência 6.25 100.00%
10 Incorporação de realimentação 6.25 100.00%
11 Leanness 6.25 100.00%
13 Modularidade 6.25 100.00%
14 Orientação a pessoas 6.25 100.00%
15 Reflexão e Introspecção 6.25 100.00%
1 Ser colaborativo 6.25 100.00%
2 Ser cooperativo 6.25 100.00%
3 Ser incremental 6.25 100.00%
6 Ser iterativo 6.25 100.00%
7 Testes constantes 6.25 100.00%
17 Time-Boxing 6.25 100.00%
12 Equipes locais 4.75 76.00%
116
Ident. Característica PertinênciaNível de
Pertinência
16 Equipes pequenas 4.75 76.00%
8 Convergência 4.5 72.00%
18 Transparência 4.5 72.00%
5 Auto-organização 3 48.00%
Segue-se um gráfico (Figura 5-3) mostrando os níveis de pertinência apurados
para as características de agilidade. A linha em negrito destaca o patamar de corte
adotado.
Figura 5-3 – Gráfico de Nível de 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 a
característica Auto-organização não será considerada pertinente e não fará parte do
corpo de conhecimento inicial a ser adotado para a estratégia de solução proposta no
contexto mais amplo deste trabalho de pesquisa.
Além das características de agilidade do conjunto inicial enviado para a
pesquisa de opinião, há que se considerar as indicações feitas pelos participantes, que
tiveram oportunidade de sugerir características diferentes. As características sugeridas
com descrição de seus significados são apresentadas na Tabela 5-4 que se segue.
Pertinência das Características de Agilidade
0.00%10.00%20.00%30.00%40.00%50.00%60.00%70.00%80.00%90.00%
100.00%
Ser c
olabor
ativo
Ser c
oope
rativ
o
Ser in
crem
enta
l
Adapt
abilid
ade
Ser it
erat
ivo
Teste
s con
stant
es
Emer
gênc
ia
Inco
rpor
ação
de re
alim
enta
ção
Lean
ness
Mod
ularida
de
Orie
ntaç
ão a
pes
soas
Refle
xão
e In
trosp
ecção
Time-B
oxin
g
Equipe
s loc
ais
Equipe
s pe
quen
as
Conve
rgên
cia
Trans
parê
ncia
Auto-
orga
nizaçã
o
Características
Nív
el
de
Pe
rtin
ên
cia
117
Tabela 5-4 – Características de Agilidade Sugeridas pelos participantes
Particip. Característica Descrição
7Responsabilidade das pessoas
Encorajamento dos desenvolvedores para conduzir um projeto,fazendo com que se sintam responsáveis pelo seu resultado.
9Orientação à aprendizagem
Provisão de ciclos curtos de retroalimentação (feedback) para melhorar a aprendizagem sobre o sistema em desenvolvimento.
Para manter coerência com os critérios estabelecidos no protocolo de revisão
sistemática sobre características de agilidade (Capítulo 3), as características indicadas
sem a descrição de seu significado não serão consideradas. Portanto, o conjunto inicial
de características de agilidade a ser considerado na estratégia de solução proposta no
contexto mais amplo desta pesquisa deveria incluir 17 características do conjunto
inicial (uma foi considerada não pertinente). As duas características sugeridas pelos
participantes não tiveram a indicação de pelo menos dois participantes, o que impede a
sua inclusão. O conjunto de características a partir deste primeiro ensaio do estudo
ficaria assim:
Ser colaborativo, Ser cooperativo, Ser incremental, Adaptabilidade, Ser iterativo,
Testes constantes, Convergência, Emergência, Incorporação de realimentação,
Leanness, Equipes locais, Modularidade, Orientação a pessoas, Reflexão e Introspecção,
Equipes pequenas, Time-Boxing e Transparência.
Portanto, a hipótese nula 1 (H0 1) apresentada no planejamento da pesquisa de
opinião (seção 5.2) não teria sido observada. Contudo há um risco associado com esta
cosntatação, visto que o nível de confiança apurado foi de 50,9%. Este nível baixo
decorre da pequena quantidade de participantes que responderam à pesquisa. Uma
alternativa é repetir a pesquisa de opinião com uma população diferente, em busca de
um nível de confiança mais alto e que reduza os riscos associados com os resultados do
estudo.
Do mesmo modo como foi feito para as características de agilidade, e
aplicando-se os critérios e procedimentos descritos no planejamento da pesquisa de
opinião que se encontra na seção 5.2, foram feitos todos os cálculos também para as
práticas ágeis. Após os cálculos para cada prática ágil avaliada, foi elaborada a Tabela
5-5 que se segue, mostrando a pertinência e o nível de pertinência para cada prática.
118
Detalhes e passos intermediários para análise dos dados obtidos e como chegar aos
valores da Tabela 5-5 estão descritos na seção 5.2.
Tabela 5-5 – Avaliação da Pertinência das Práticas Ágeis de Software
Ident. Prática PertinênciaNível de
Pertinência
14 Adequação aos propósitos do negócio 6.25 100.00%
32 Análise de causa raíz 6.25 100.00%
33 Código compartilhado 6.25 100.00%
40 Continuidade da equipe 6.25 100.00%
10 Desenvolver por funcionalidade 6.25 100.00%
9 Desenvolver software iterativamente 6.25 100.00%
45 Desenvolvimento guiado por testes 6.25 100.00%
12 Documentação 6.25 100.00%
49 Equipe completa / cliente in loco 6.25 100.00%
6 Gerência de configuração 6.25 100.00%
20 Gerenciar requisitos 6.25 100.00%
39 Histórias 6.25 100.00%
16 Implantação incremental 6.25 100.00%
18 Inspeção 6.25 100.00%
7 Integração contínua 6.25 100.00%
19 Manter as pessoas informadas 6.25 100.00%
30 Montagens regulares 6.25 100.00%
37 Pequenas liberações (Releases curtas) 6.25 100.00%
2 Permitir reversão das mudanças 6.25 100.00%
22 Produtividade para modelagem 6.25 100.00%
42 Programação test-first 6.25 100.00%
48 Progresso visível 6.25 100.00%
35 Projeto simples 6.25 100.00%
15 Realimentação frequente 6.25 100.00%
38 Reuniões em pé 6.25 100.00%
31 Revisão de código 6.25 100.00%
44 Teste ao longo do ciclo de vida 6.25 100.00%
4 Teste de unidade automatizado 6.25 100.00%
46 Testes de unidade 6.25 100.00%
23 Trabalho em equipe para modelagem 6.25 100.00%
5 Manter código e testes 5.5 88.00%
8 Implantação diária 4.75 76.00%
26 Jogo de Planejamento 4.75 76.00%
21 Motivação para modelagem 4.75 76.00%
29 Oficinas (Workshops) de reflexão 4.75 76.00%
25 Programação por pares 4.75 76.00%
17 Projeto incremental 4.75 76.00%
119
Ident. Prática PertinênciaNível de
Pertinência
28 Refatoração 4.75 76.00%
3 Teste de aceitação automatizado 4.75 76.00%
13 Trabalho energizado 4.75 76.00%
27 Tratar mudanças de requisitos proativamente 4.75 76.00%
24 Validação de modelagem 4.75 76.00%
36 Base de código única 4 64.00%
43 Teste em diferentes ambientes 4 64.00%
1 Adotar uma estratégia de diversidade holística 3 48.00%
11 Ambiente de desenvolvimento levemente controlado 3 48.00%
34 Equipes enxutas 2.5 40.00%
41 Montagem de 10 minutos 2.5 40.00%
47 Utilização de arquiteturas baseadas em componentes 2.5 40.00%
Segue-se um gráfico (Figura 5-4) mostrando os níveis de pertinência apurados
para as práticas ágeis. A linha em negrito destaca o patamar de corte adotado.
Figura 5-4 – Gráfico de Nível de Pertinência das Práticas Ágeis
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 práticas
Pertinência das Práticas Ágeis
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
80.00%
90.00%
100.00%
Perm
itir re
vers
ão d
as m
udan
ças
Ger
ência
de
conf
igura
ção
Desen
volve
r sof
twar
e ite
rativ
amen
te
Docum
enta
ção
Realim
enta
ção
freque
nte
Insp
eção
Ger
encia
r req
uisito
s
Traba
lho e
m e
quip
e pa
ra m
odelag
em
Revisa
ão d
e có
digo
Códig
o co
mpa
rtilh
ado
Peque
nas
rele
ases
Estór
ias
Progr
amaç
ão te
st-fi
rst
Desen
volvi
men
to g
uiado
por
teste
s
Progr
esso
visí
vel
Man
ter c
ódig
o e
test
es
Impl
anta
ção
diár
ia
Proje
to in
crem
enta
l
Valida
ção
de m
odel
agem
Jogo
de
Planej
amen
to
Refat
oraç
ão
Base
de c
ódig
o ún
ica
Adota
r um
a es
traté
gia d
e div
ersid
ade
holís
tica
Equipe
enxu
ta
Utiliza
ção
de a
rqui
tetu
ras b
asead
as em
com
pone
ntes
Práticas
Nív
el d
e P
ert
inê
nc
ia
120
Adotar uma estratégia de diversidade holística, Ambiente de desenvolvimento levemente
controlado, Equipes enxutas, Montagem de 10 minutos e Utilização de arquiteturas
baseadas em componentes não serão consideradas pertinentes e não farão parte do corpo
de conhecimento inicial a ser adotado para a estratégia de solução proposta no contexto
mais amplo deste trabalho de pesquisa.
No caso das práticas ágeis, talvez pelo fato da lista submetida originalmente à
pesquisa de opinião ser muito extensa e abrangente, não houve indicação de novas
práticas ágeis por parte dos participantes. Contudo, a hipótese nula 2 (H0 2) descrita na
seção 5.2 também não teria sido observada, já que 5 práticas ágeis foram removidas do
conjunto original. Permanecem 44 práticas ágeis no conjunto a ser considerado, de
início, para implementação da proposta de solução. Entretanto, as mesmas ressalvas já
feitas com relação a riscos para o caso da não aceitação da hipótese nula 1 (H0 1),
valem para a hipótese nula 2 (H0 2).
Uma vez identificada a pertinência para cada característica e para cada prática,
pode-se partir para a identificação do nível de relevância destes atributos para fins de
inserção de agilidade em processos de software. Aplicando-se o procedimento de
cálculo do nível de relevância descrito na seção 5.2, chega-se aos resultados para as
características de agilidade, apresentados na Tabela 5-6 que se segue.
Tabela 5-6 – Avaliação da Relevância das Características de Agilidade
Ident. CaracterísticaNível de
Relevância
6 Ser iterativo 100.00%
17 Time-Boxing 100.00%
4 Adaptabilidade 92.00%
10 Incorporação de realimentação 92.00%
1 Ser colaborativo 92.00%
3 Ser incremental 88.00%
2 Ser cooperativo 84.00%
11 Leanness 72.00%
18 Transparência 64.00%
9 Emergência 60.00%
7 Testes constantes 52.00%
8 Convergência 44.00%
16 Equipes pequenas 42.67%
12 Equipes locais 33.33%
Orientação à aprendizagem 24.00%
121
Ident. CaracterísticaNível de
Relevância
14 Orientação a pessoas 24.00%
15 Reflexão e Introspecção 24.00%
13 Modularidade 12.00%
Responsabilidade das pessoas 12.00%
A Figura 5-5 que se segue mostra graficamente o nível de relevância apurado
para as características de agilidade. As linhas sem identificador correspondem a
características indicadas pelos participantes.
Figura 5-5 – Gráfico de Nível de Relevância das Características de Agilidade
Observa-se que a hipótese nula 3 (H0 3) descrita na seção 5.2 não teria sido
observada, já que as características de agilidade não apresentaram todas o mesmo nível
de relevância. Observa-se ainda que uma das características que atingiu 100% de
relevância (ser iterativo) é apontada como um dos denominadores comuns dentre as
principais metodologias ágeis propostas na literatura. As mesmas ressalvas já feitas com
relação a riscos para o caso da não aceitação das hipóteses nulas 1 e 2 (H0 1 e H0 2),
valem para a hipótese nula 3 (H0 3).
Com procedimento semelhante pode-se computar os níveis de relevância para as
práticas de software, cujos resultados são apresentados na Tabela 5-7 que se segue.
Nível de Relevância das Características de Agilidade
0.00%10.00%20.00%30.00%40.00%50.00%60.00%70.00%80.00%90.00%
100.00%
Ser iter
ativo
Time-
Boxin
g
Ser co
labor
ativo
Adapt
abilid
ade
Inco
rpor
ação
de r
ealim
enta
ção
Ser in
crem
enta
l
Ser co
oper
ativo
Lean
ness
Trans
parê
ncia
Emer
gênc
ia
Teste
s con
stant
es
Conve
rgên
cia
Equipe
s peq
uena
s
Equipe
s loc
ais
Orienta
ção
a pes
soas
Reflex
ão e
Intro
spec
ção
Orienta
ção
à apr
endiz
agem
Mod
ular
idade
Respo
nsab
ilidad
e da
s pes
soas
Características
Nív
el d
e R
ele
vâ
nc
ia
122
Tabela 5-7 – Avaliação da Relevância das Práticas Ágeis
Ident. PráticaNível de
Relevância
9 Desenvolver software iterativamente 100.00%
15 Realimentação frequente 100.00%
38 Reuniões em pé 92.00%
7 Integração contínua 88.00%
27 Tratar mudanças de requisitos proativamente 88.00%
37 Pequenas liberações (Releases curtas) 84.00%
49 Equipe completa / cliente in loco 80.00%
6 Gerência de configuração 80.00%
30 Montagens regulares 80.00%
28 Refatoração 80.00%
4 Teste de unidade automatizado 80.00%
14 Adequação aos propósitos do negócio 76.00%
19 Manter as pessoas informadas 76.00%
22 Produtividade para modelagem 76.00%
44 Teste ao longo do ciclo de vida 76.00%
33 Código compartilhado 72.00%
10 Desenvolver por funcionalidade 72.00%
45 Desenvolvimento guiado por testes 72.00%
39 Histórias 72.00%
2 Permitir reversão das mudanças 72.00%
42 Programação test-first 72.00%
35 Projeto simples 72.00%
31 Revisão de código 72.00%
16 Implantação incremental 68.00%
20 Gerenciar requisitos 66.67%
17 Projeto incremental 64.00%
3 Teste de aceitação automatizado 64.00%
26 Jogo de Planejamento 62.67%
32 Análise de causa raíz 60.00%
21 Motivação para modelagem 60.00%
36 Base de código única 56.00%
40 Continuidade da equipe 56.00%
29 Oficinas (Workshops) de reflexão 56.00%
48 Progresso visível 56.00%
18 Inspeção 52.00%
46 Teste de unidade 52.00%
25 Programação por pares 50.67%
5 Manter código e testes 49.33%
23 Trabalho em equipe para modelagem 49.33%
43 Teste em diferentes ambientes 48.00%
123
Ident. PráticaNível de
Relevância
13 Trabalho energizado 48.00%
12 Documentação 41.33%
8 Implantação diária 40.00%
24 Validação de modelagem 40.00%
A Figura 5-6 que se segue mostra graficamente o nível de relevância apurado
para as práticas ágeis.
Figura 5-6 – Gráfico de Nível de Relevância das Práticas Ágeis
Também neste caso observa-se que a hipótese nula 4 (H0 4) não teria sido
observada, 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 o caso das 3
hipóteses nulas anteriores, decorrentes do baixo nível de confiança alcançado.
Assim um corpo de conhecimento poderia ser atualizado com seus respectivos
níveis de relevância com relação a agilidade em processos de software. Contudo, neste
trabalho, estes primeiros resultados foram considerados um ensaio para a segunda
execução de pesquisa de opinião, que foi realizada com novo conjunto de participantes e
novo conjunto de práticas ágeis. Os resultados da segunda execução passam a ser
apresentados na seção 5.3.2 que se segue.
Nível de Relevância das Práticas Ágeis
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
80.00%
90.00%
100.00%
Des
envo
lver
Reu
niõe
s em
pé
Tra
tar
mud
ança
s
Tes
te d
e
Ref
ator
ação
Equ
ipe
com
plet
a
Man
ter
as
Tes
te a
o lo
ngo
Des
envo
lver
por
Cód
igo
Est
ória
s
Des
envo
lvim
ento
Ger
enci
ar
Pro
jeto
Mot
ivaç
ão p
ara
Wor
ksho
ps d
e
Con
tinui
dade
da
Insp
eção
Pro
gram
ação
Tra
balh
o em
Tes
te e
m
Impl
anta
ção
Práticas
Nív
el d
e R
ele
vân
cia
124
5.3.2 Resultados da Segunda Execução do Estudo
O instrumento da pesquisa de opinião esteve disponível de 06 de janeiro de 2011
até 06 de março de 2011 no endereço http://lens-ese.cos.ufrj.br/surveyagile/. Aos
participantes foi enviado um convite por email, junto com um código de login e uma
senha de acesso. Foram convidados 117 participantes diferentes daqueles que
participaram da primeira execução do estudo, escolhidos dentre os autores dos artigos
selecionados nas revisões sistemáticas de literatura apresentadas nos capítulos 3 e 4,
excluídos os autores de artigos dos quais foram extraídas características de agilidade
e/ou práticas ágeis dentro dos critérios estabelecidos nos respectivos protocolos. Dos
117 emails enviados, alguns retornaram mensagens automáticas dizendo que estariam
em férias ou fora de seus locais de trabalho até o mês seguinte. Até o final do mês de
janeiro de 2011 houve 31 acessos, sendo que 21 participantes registraram suas
respostas. 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. 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,2 % dos dados coletados, obtido com a aplicação da fórmula para cálculo do
nível de confiança de uma amostra, adaptada de HAMBURG (1980), conforme
apresentado na seção 5.2.2.
Para cada participante foram tabulados seus atributos de caracterização e
computado um peso individual conforme descrito no planejamento da pesquisa de
opinião, na seção 5.2. A Tabela 5-8 a seguir mostra os resultados para cada participante
(identificador, nível de formação, número de artigos publicados sobre métodos ou
processos ágeis, nível de experiência com abordagens ágeis em projetos de software,
número de projetos de software de que participou aplicando abordagens ágeis, peso
calculado para participante). As respostas de cada pesquisador serão ponderadas com
um peso diferenciado de acordo com seu nível de experiência e/ou habilidade.
Tabela 5-8 - Pesos Individuais dos Participantes
Identif.Nível de
FormaçãoNúmero
de ArtigosNível de
Experiência
Número de
ProjetosPeso
Calculado Origem12 MSc 0 Baixo 0 2,00 NI 25 MSc 2 Baixo 1 2,50 India16 DSc / Phd 0 Médio 0 4,00 NI
125
Identif.Nível de
FormaçãoNúmero
de ArtigosNível de
Experiência
Número de
ProjetosPeso
Calculado Origem24 DSc / Phd 1 Baixo 2 4,00 NI11 DSc / Phd 5 Baixo 0 5,00 Austrália5 MSc 3 Médio 2 5,00 India
18 DSc / Phd 5 Médio 0 6,00 NI26 DSc / Phd 15 Baixo 0 6,00 NI19 DSc / Phd 2 Alto 2 6,00 NI4 DSc / Phd 3 Médio 2 6,00 Áustria
15 MSc 10 Baixo 2 6,00 NI17 DSc / Phd 5 Médio 1 6,50 USA31 DSc / Phd 3 Médio 3 6,50 Canadá27 DSc / Phd 4 Médio 3 6,50 Jordânia10 DSc / Phd 6 Médio 2 7,00 Dinamarca22 MSc 0 Alto 10 9,00 Finlândia23 DSc / Phd 7 Médio 5 9,50 NI3 DSc / Phd 10 Alto 5 10,50 NI
20 DSc / Phd 8 Muito Alto 10 14,00 NI7 DSc / Phd 10 Alto 12 14,00 NI
21 DSc / Phd 30 Muito Alto 30 24,00 Itália NI = não informado
Uma vez obtidos os pesos dos participantes, pode-se passar para a análise dos
resultados 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 5.2 deste documento, após os cálculos para cada característica de
agilidade avaliada foi elaborada a Tabela 5-9 que se segue, mostrando a pertinência e o
nível de pertinência para cada característica.
Tabela 5-9 - Pertinência das Características de Agilidade
Ident. Característica PertinênciaNível de
Pertinência4 Adaptabilidade 160,0 100,0%
14 Orientação a pessoas 157,5 98,4%15 Reflexão e Introspecção 157,5 98,4%1 Ser colaborativo 150,5 94,1%3 Ser incremental 150,5 94,1%7 Testes constantes 150,0 93,8%
17 Time-Boxing 149,0 93,1%6 Ser iterativo 148,0 92,5%2 Ser cooperativo 145,5 90,9%
10 Incorporação de realimentação 127,5 79,7%5 Auto-organização 122,0 76,3%9 Emergência 118,5 74,1%
16 Equipes pequenas 114,5 71,6%13 Modularidade 103,0 64,4%18 Transparência 98,5 61,6%11 Leanness 98,0 61,3%8 Convergência 72,0 45,0%
12 Equipes locais 49,5 30,9%
Na Tabela 5-9, a pertinência das
zero correspondendo à situação em que todos os respondentes consideram a
característica de agilidade como não pertinente e
que todos os respondentes consideram a
Figura 5-7 dá uma visão dos níveis de pertinência apurados para as
agilidade. A linha em negrito destaca o patamar de corte adotado.
Figura 5-7 - Níveis de 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
farão parte do corpo de conhecimento inicial a ser adotado para a estratégia de solução
proposta no contexto mais amplo deste trabalho de pesquisa.
Observa-se que os participantes não sugeriram qualquer
suas respectivas descrições, diferentes daquelas do conjunto inicial. Portanto, o conjunto
de características de agilidade a ser considerado na estratégia de solução proposta no
contexto mais amplo desta pesquisa deve incluir as 16
Ser colaborativo, Ser cooperativo, Ser incremental, Adaptabilidade, Auto
Ser iterativo, Testes constantes, Emergência, Incorporação de realimentação,
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 P
erti
nên
cia
Pertinência das Características de Agilidade
, a pertinência das características pode variar de zero a 160, sendo
zero correspondendo à situação em que todos os respondentes consideram a
de agilidade como não pertinente e 160 correspondendo à situação em
que todos os respondentes consideram a característica de agilidade como pertinente.
dá uma visão dos níveis de pertinência apurados para as características
linha em negrito destaca o patamar de corte adotado.
Níveis de Pertinência das Características de Agilidade
Como o limite inferior adotado no planejamento da pesquisa de opinião para
ser considerada pertinente foi de 50%, temos então que as
Convergência e Equipes Locais não serão consideradas pertinentes e não
farão parte do corpo de conhecimento inicial a ser adotado para a estratégia de solução
proposta no contexto mais amplo deste trabalho de pesquisa.
se que os participantes não sugeriram qualquer característ
suas respectivas descrições, diferentes daquelas do conjunto inicial. Portanto, o conjunto
de agilidade a ser considerado na estratégia de solução proposta no
contexto mais amplo desta pesquisa deve incluir as 16 características
Ser colaborativo, Ser cooperativo, Ser incremental, Adaptabilidade, Auto
Ser iterativo, Testes constantes, Emergência, Incorporação de realimentação,
Características
Pertinência das Características de Agilidade
126
pode variar de zero a 160, sendo
zero correspondendo à situação em que todos os respondentes consideram a
160 correspondendo à situação em
de agilidade como pertinente. A
características de
Níveis de Pertinência das Características de Agilidade
Como o limite inferior adotado no planejamento da pesquisa de opinião para
ser considerada pertinente foi de 50%, temos então que as
não serão consideradas pertinentes e não
farão parte do corpo de conhecimento inicial a ser adotado para a estratégia de solução
característica nova com
suas respectivas descrições, diferentes daquelas do conjunto inicial. Portanto, o conjunto
de agilidade a ser considerado na estratégia de solução proposta no
icas que se seguem:
Ser colaborativo, Ser cooperativo, Ser incremental, Adaptabilidade, Auto-organização,
Ser iterativo, Testes constantes, Emergência, Incorporação de realimentação,
Pertinência das Características de Agilidade
127
Leanness, Modularidade, Orientação a pessoas, Reflexão e Introspecção, Equipes
pequenas, Time-Boxing e Transparência.
A H0 1 apresentada no planejamento da pesquisa de opinião (seção 5.2) não foi
observada. Contudo há um risco associado, embora menor do que no estudo anterior,
visto que o nível de confiança apurado foi de 80,23%.
Do mesmo modo como foi feito para as características de agilidade, e
aplicando-se os critérios e procedimentos descritos no planejamento da pesquisa de
opinião que se encontra na seção 5.2, foram feitos todos os cálculos também para as
práticas ágeis. Após os cálculos para cada prática ágil avaliada, foram elaboradas a
Tabela 5-10 e a Figura 5-8, mostrando a pertinência e o nível de pertinência para cada
prática. Detalhes e passos intermediários para análise dos dados obtidos e como chegar
aos valores da Tabela 5-10 estão descritos na seção 5.2.
Tabela 5-10 - Pertinência das Práticas Ágeis
Ident. Prática Pertinência
Nível de
Pertinência
9 Backlog de produto 120,5 95,3%3 Integração contínua 116,5 92,1%
13 Liberações freqüentes (Releases curtas) 116,5 92,1%10 Visibilidade de projeto 112,5 88,9%11 Refatoração 109,5 86,6%8 Jogo de planejamento 107,5 85,0%
12 Design simples 99,0 78,3%1 Padrões de código 99,0 78,3%
14 Reuniões diárias 96,5 76,3%2 Propriedade coletiva do código 90,5 71,5%
16 Desenvolvimento orientado a testes 75,0 59,3%15 Ritmo sustentável 73,5 58,1%4 Metáfora 69,0 54,5%
17 Equipe completa 64,5 51,0%5 Cliente presente 64,0 50,6%6 Espaço de trabalho aberto 62,5 49,4%7 Programação em Par 49,5 39,1%
Na Tabela 5-10, a pertinência das práticas ágeis pode variar de zero a 126,5,
sendo zero correspondendo à situação em que todos os respondentes consideram a
prática ágil como não pertinente e 126,5 correspondendo à situação em que todos os
respondentes consideram a prática ágil como pertinente. Na figura 5-8 a linha em
negrito destaca o patamar de cortes adotado.
Figura
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
Espaço de trabalho aberto
não farão parte do corpo de conhecimento inicial a ser adotado para a estratégia de
solução proposta no contexto mais amplo deste trabalho de pesquisa.
Não houve indicação de novas
Contudo, a H0 2 descrita na seção 5.2 deste documento também
que 2 práticas ágeis foram removidas do conjunto original. Permanecem 15
ágeis no conjunto a ser considerado, de início, para implementação da proposta de
solução no contexto mais amplo da pesquisa.
a riscos para o caso da refutação da H0 1, valem para a H0 2.
Uma vez identificada a pertinência para cada
pode-se partir para a identificação do nível de
inserção de agilidade em processos de software. Aplicando
cálculo do nível de relevância descrito na seção 5.2, chega
características de agilidade, apresentados na
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 P
erti
nên
cia
Figura 5-8 – Níveis de Pertinência das Práticas Ágeis
Como o limite inferior adotado no planejamento da pesquisa de opinião para
ser considerada pertinente foi de 50%, temos então que as
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 a estratégia de
solução proposta no contexto mais amplo deste trabalho de pesquisa.
Não houve indicação de novas práticas ágeis por parte dos participantes.
H0 2 descrita na seção 5.2 deste documento também não foi
ágeis foram removidas do conjunto original. Permanecem 15
ágeis no conjunto a ser considerado, de início, para implementação da proposta de
mais amplo da pesquisa. As mesmas ressalvas já feitas com relação
a riscos para o caso da refutação da H0 1, valem para a H0 2.
Uma vez identificada a pertinência para cada característica e para cada
se partir para a identificação do nível de relevância destes atributos para fins de
inserção de agilidade em processos de software. Aplicando-se o procedimento de
cálculo do nível de relevância descrito na seção 5.2, chega-se aos resultados para as
de agilidade, apresentados na Tabela 5-11 e na Figura 5-
Práticas
Pertinência das Práticas Ágeis
128
Como o limite inferior adotado no planejamento da pesquisa de opinião para
ser considerada pertinente foi de 50%, temos então que as práticas
radas pertinentes e
não farão parte do corpo de conhecimento inicial a ser adotado para a estratégia de
ágeis por parte dos participantes.
foi observada, já
ágeis foram removidas do conjunto original. Permanecem 15 práticas
ágeis no conjunto a ser considerado, de início, para implementação da proposta de
s mesmas ressalvas já feitas com relação
e para cada prática,
relevância destes atributos para fins de
se o procedimento de
se aos resultados para as
-9.
129
Tabela 5-11 - Relevância das Características de Agilidade
Ident. Característica Nível de Relevância14 Orientação a pessoas 89,1%4 Adaptabilidade 88,7%6 Ser iterativo 84,8%1 Ser colaborativo 84,7%
10 Incorporação de realimentação 84,1%7 Testes constantes 84,1%3 Ser incremental 83,3%
15 Reflexão e Introspecção 80,8%2 Ser cooperativo 79,3%
17 Time-Boxing 63,5%18 Transparência 62,8%9 Emergência 57,7%5 Auto-organização 57,2%
11 Leanness 56,5%13 Modularidade 54,0%16 Equipes pequenas 43,2%
Figura 5-9 – Nível de Relevância das Características de Agilidade
Observa-se que a H0 3 descrita na seção 5.2 não foi observada, já que as
características de agilidade não apresentaram todas o mesmo nível de relevância.
Observa-se ainda que uma das características que atingiu mais de 80% de relevância
(ser iterativo) é apontada como um dos denominadores comuns dentre as principais
metodologias ágeis propostas na literatura. As mesmas ressalvas já feitas com relação a
riscos para o caso da refutação H0 1 e H0 2 também valem para a H0 3.
Nível de Relevância das Características de Agilidade
0,0%
20,0%
40,0%
60,0%
80,0%
100,0%
Orient
ação
a p
esso
as
Adapt
abilid
ade
Ser ite
rativ
o
Ser co
labo
rativ
o
Teste
s con
stan
tes
Inco
rpor
ação
de
reali
men
taçã
o
Ser in
crem
enta
l
Reflex
ão e
Intro
spec
ção
Ser co
oper
ativo
Time-
Boxin
g
Trans
parê
ncia
Emer
gênc
ia
Auto-
orga
niza
ção
Lean
ness
Mod
ular
idade
Equip
es p
eque
nas
Características
Nív
el d
e R
ele
vâ
nc
ia
130
Com procedimento semelhante podem ser computados os níveis de relevância
para as práticas, cujos resultados são apresentados na Tabela 5-12 e na Figura 5-10.
Tabela 5-12 - Relevância das Práticas Ágeis
Ident. Prática Nível de Relevância3 Integração contínua 92,1%9 Backlog de produto 82,7%13 Liberações freqüentes (Releases curtas) 82,4%11 Refatoração 80,2%10 Visibilidade de projeto 75,8%8 Jogo de planejamento 70,7%12 Design simples 62,9%14 Reuniões diárias 57,7%1 Padrões de código 55,7%2 Propriedade coletiva do código 51,7%15 Ritmo sustentável 42,3%5 Cliente presente 37,3%4 Metáfora 34,6%
Figura 5-10 – Nível de Relevância das Práticas Ágeis
Também neste caso observa-se que a H0 4 descrita na seção 5.2 não foi
observada, 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 aceitação das 3
hipóteses nulas anteriores, decorrentes do nível de confiança alcançado. É interessante
observar que nenhuma das práticas recebeu unanimidade no julgamento dos
Nível de Relevância das Práticas Ágeis
0,0%
20,0%
40,0%
60,0%
80,0%
100,0%
Inte
graç
ão c
ontín
ua
Backlo
g de
pro
duto
Releas
es cu
rtas
Refat
oraç
ão
Visibil
idade
de
proje
to
Jogo
de
plan
ejam
ento
Desig
n sim
ples
Reuni
ões d
iárias
Padrõ
es d
e có
digo
Propr
ieda
de co
letiv
a do
códi
go
Desen
volvi
men
to o
rient
ado
a te
stes
Ritmo
sust
entá
vel
Client
e pr
esen
te
Equip
e co
mpl
eta
Met
áfor
a
Práticas
Nív
el d
e R
ele
vân
cia
131
participantes, como aconteceu com uma das características de agilidade, a
adaptabilidade.
Assim um corpo de conhecimento envolvendo 16 características de agilidade e
15 práticas ágeis pode ser atualizado com seus respectivos níveis de relevância com
relação a agilidade em processos de software.
5.4 Ameaças à Validade
As limitações ou ameaças à validade deste estudo estão associadas com o fato de
que o mesmo 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. Não se pode ter
a certeza de que os mesmos conjuntos iniciais seriam obtidos se fosse feita uma
tentativa de identificar 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.
Além disso, no caso da revisão de características de agilidade (Capítulo 3), o
critério estabelecido no protocolo (exclusão de documentos reportando características
de um método ágil em particular), embora evitasse influências, pode ter deixado fora do
conjunto inicial alguma característica diferente daquelas identificadas na revisão
sistemática.
Também há que se considerar que o nível de confiança obtido para a amostra
utilizada no estudo, que ficou em torno de 80,23%, representa um risco, mesmo
considerando-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.
5.5 Conclusão
Os resultados das duas execuções das pesquisas de opinião não foram agregados.
A primeira execução foi considerada como piloto e serviu para aperfeiçoamento do
estudo. Além do fato do nível de confiança alcançado na primeira execução ter sido
baixo, o universo de práticas ágeis incluído nela foi diferente e obtido de modo diferente
(revisão informal de literatura). Além disso, para evitar influências nos resultados, na
segunda execução foram excluídos participantes autores de artigos de onde foram
132
extraídas características de agilidade e práticas ágeis, o que não havia sido feito na
primeira execução do estudo.
A utilização do corpo de conhecimento inicial formado a partir dos resultados
deste estudo apresenta um nível de confiança de 80,2%, alcançado a partir da amostra e
calculado conforme o planejamento do descrito na seção 5.2. Duas características de
agilidade e duas práticas ágeis originárias de revisões sistemáticas de literatura ficaram
fora do corpo de conhecimento.
A partir das respostas dos participantes sobre pertinência das características de
agilidade e de acordo com o critério estabelecido no planejamento da pesquisa de
opinião apresentado na seção 5.2, duas características de agilidade originárias de
revisão sistemática de literatura devem ser excluídas do corpo de conhecimento inicial
a ser estabelecido para apoiar a continuidade dos trabalhos de pesquisa: Convergência e
Equipes Locais.
Também, a partir das respostas dos participantes sobre pertinência das práticas
ágeis e de acordo com o critério estabelecido no planejamento da pesquisa de opinião,
duas práticas ágeis originárias dos estudos secundários devem ser excluídas do mesmo
corpo de conhecimento inicial: 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 as pesquisas que busquem inserir
agilidade em 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%. Contudo, conforme o critério estabelecido
no planejamento do estudo (seção 5.2) esta característica foi mantida no corpo de
conhecimento porque apresentou nível de pertinência de 71,6%.
Das quinze práticas ágeis que devem fazer parte do corpo de conhecimento, dez
apresentam 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%. Cinco práticas apresentam
nível de relevância variando de 34,6% a 46,2%. As práticas que apresentam os mais
baixos níveis de relevância foram: Equipe completa e Metáfora. As outras práticas que
também, apresentaram nível de relevância abaixo de 50% foram: Desenvolvimento
orientado a testes, Ritmo sustentável e Cliente presente.
Não há necessidade de maiores preocupações em se fazer a exclusão de duas
características de agilidade (Convergência e Equipes Locais) e duas práticas ágeis
133
(Espaço de trabalho aberto e Programação em par) do corpo inicial de conhecimento,
desde que na sua utilização sejam previstos mecanismos que permitam a atualização
deste conhecimento quando necessário, porquanto seja possível retorna-las para o corpo
de conhecimento, se no futuro tais características e práticas forem reavaliadas e
consideradas pertinentes e relevantes.
Em suma, com base nos resultados do estudo, devem inicialmente fazer parte do
corpo de conhecimento para apoiar o prosseguimento deste trabalho de pesquisa, as
características de agilidade e práticas ágeis que se apresentam na Tabela 5-13 e na
Tabela 5-14 respectivamente.
Tabela 5-13 – Características de Agilidade para compor o Corpo de Conhecimento
CaracterísticaAdaptabilidadeAuto-organizaçãoEmergênciaEquipes pequenasIncorporação de Retroalimentação (feedback)LeannessModularidadeOrientação a PessoasReflexão e IntrospecçãoSer ColaborativoSer CooperativoSer IncrementalSer IterativoTestes ConstantesTime- BoxingTransparência
Tabela 5-14 - Práticas Ágeis para compor o Corpo de Conhecimento
PráticaBacklog de produto Cliente presenteDesenvolvimento orientado a testesDesign simplesEquipe completaIntegração contínuaJogo de planeja-mentoMetáforaPadrões de códigoPropriedade coletiva do códigoRefatoraçãoLiberações freqüentes (Releases curtas)Reuniões diáriasRitmo sustentávelVisibilidade de projeto
134
Deve-se observar também, que não houve consenso entre os participantes, nem
um entendimento que levasse a uma visão comum, para as carcterísticas de agilidade ou
para as práticas de software avaliadas. Isto pode sugerir ou demandar repetições dos
estudos no futuro.
No capítulo 6 serão apresentados os critérios utilizados na construção, bem
como os resultados de um mapeamento das práticas ágeis para as características de
agilidade e das práticas ágeis para as atividades do processo padrão de testes adotado
nesta pesquisa. Tal mapeamento constitui-se em um dos pilares que vão sustentar a
solução elaborada para inserir agilidade em processos de teste de software.
135
6. Mapeamento de Práticas Ágeis para
Características de Agilidade e Atividades de
Teste de Software
Neste capítulo são apresentados os relacionamentos identificados
entre práticas ágeis e características de agilidade, bem como entre
práticas ágeis e atividades de teste de software. São relatados ainda
os resultados da avaliação destes relacionamentos feita através de
revisão por pares.
6.1 Introdução
O conhecimento sobre características de agilidade foi disponibilizado para que
seja possível selecionar aquelas desejadas para o processo de teste de software
considerado. Também foi disponibilizado o conhecimento sobre práticas ágeis de
software e atividades de teste de software. Foi adotado nesta pesquisa um processo
padrão de teste de software (capítulo 2), a partir do qual foram definidas as atividades
de teste a serem consideradas. Uma base de conhecimento foi inicialmente instanciada,
a partir de resultados das revisões sistemáticas da literatura e estudos envolvendo
avaliações de características de agilidade e práticas ágeis. Um mapeamento é
estabelecido entre as práticas ágeis e as características de agilidade, bem como entre as
práticas ágeis e as atividades do processo padrão de teste de software. A partir das
características do projeto de software sendo considerado e dos mapeamentos citados são
sugeridas as práticas ágeis candidatas a serem adotadas em um processo de teste de
software para o projeto. Este capítulo trata especificamente do mapeamento envolvido
na estratégia de solução proposta.
No contexto desta pesquisa o termo mapeamento será utilizado para referenciar
um relacionamento ou associação entre práticas ágeis e características de agilidade ou
entre aquelas e atividades de teste de software.
136
6.2 Características de Agilidade para Processos de Software
As características de agilidade para processos de software a serem mapeadas
são: Adaptabilidade, Auto-organização, Emergência, Equipes pequenas, Incorporação
de Retroalimentação (feedback), Leanness, Modularidade, Orientação a Pessoas,
Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser
Iterativo, Testes Constantes, Time-Boxing e Transparência. Suas descrições
consolidadas estão no capítulo 3. Elas foram avaliadas pelo estudo apresentado no
capítulo 5.
6.3 Atividades do Processo de Teste de Software
Após a revisão de literatura sobre processos de teste de software (Capítulo 2), foi
selecionado um processo padrão de testes de software (DIAS NETO e TRAVASSOS,
2006), do qual serão derivadas as atividades necessárias para produzir os diversos
produtos de trabalho ou artefatos de teste, visando alcançar os objetivos dos testes de
software para o projeto.
Na Tabela 6-1 são apresentadas as atividades inicialmente escolhidas para a
carga da base de conhecimento, obtidas conforme descrito no capítulo 2. As atividades
indicadas nesta tabela podem, cada uma, envolver um conjunto de subatividades
relacionadas, cujo detalhamento não será tratado neste trabalho.
Tabela 6-1 - Atividades do Processo Padrão de Testes de Software
Atividade Descrição
Planejar Testes
Esta atividade envolve o planejamento do processo de teste a ser seguido para um projeto específico, com estimativa de custos, cronograma e recursos; são ainda definidos os itens a serem testados, as estratégias, métodos e técnicas de teste a serem adotadas, bem como é estabelecido um critério para aceitação do software testado.
Projetar Testes
Esta atividade envolve a especificação detalhada das abordagens a serem seguidas durante a realização dos testes identificadas na atividade “Planejar Testes”, para avaliar os itens de teste nela identificados. Nesta atividade são identificados conjuntos de casos e procedimentos de teste a serem executados para avaliação do software.
Especificar Casos de Teste
Nessa atividade, devem ser especificados todos os casos de teste identificados naatividade anterior (Projetar Testes). Para cada caso de teste devem ser descritos os seus valores de entrada, resultados esperados, recursos necessários para a sua execução, suas restrições e dependências com outros casos de teste.
Definir Procedimentos de Teste.
Esta atividade deve definir procedimentos descrevendo os passos necessários para a execução de um ou de um grupo de casos de teste. Um procedimento de teste precisa conter informações sobre o seu objetivo, requisitos para a sua execução, além dospassos a serem seguidos durante os testes.
137
Atividade Descrição
Executar Testes
Esta atividade envolve executar os procedimentos de teste elaborados para um produto específico, devendo a execução ser devidamente documentada para permitir que outros testadores possam repeti-la de forma semelhante.
Analisar Resultados
Esta atividade envolve avaliar os resultados dos testes para saber se eles obtiveram sucesso. Na maioria das vezes, “sucesso” significa que o sistema funcionou conforme o planejado, e não apresentou resultados diferentes dos resultados esperados, conforme descrito nos casos de teste. Esta atividade também pode envolver a utilização de métricas de teste específicas, calculadas a partir dos resultados alcançados.
Monitorar e Controlar o Processo de Teste
As atividades de monitoramento, controle e re-planejamento de testes tem como propósito manter o controle e fazer as correções necessárias no Plano de Teste, quando este não mais refletir a realidade na medida em que as atividades de teste são executadas e os testes progridem.
Fechar Atividades de Teste
A atividade de fechamento do processo de teste tem como propósito fazer uma limpeza após o término dos testes e guardar ativos físicos de valor e informações relevantes para a organização. Os dados gerados ao longo dos testes são armazenados para permitir a qualquer momento a consulta a esses dados, como uma forma de apoio durante a realização de novas atividades de teste.
As atividades do processo padrão de teste de software adotado neste trabalho,
apresentadas na Tabela 6-1, produzem, ao final, os produtos de trabalho apresentados na
Tabela 6-2 que se segue.
Tabela 6-2 – Produtos de Trabalho das Atividades do Processo Padrão de Testes
Atividade Produtos de Trabalho ou Artefatos Produzidos
Planejar Testes Plano de TesteProjetar Testes Especificação do Projeto de TesteEspecificar Casos de Teste Especificação de Casos de TesteDefinir Procedimentos de Teste Especificação de Procedimentos de TesteExecutar Testes Histórico dos Testes, Relatório de Incidentes de Teste Analisar Resultados Relatório de Resumo dos TestesMonitorar e Controlar o Processo de Teste
Registro das tarefas executadas, do andamento do processo e dos resultados obtidos para os testes.
Fechar Atividades de Teste
Registro de dados de execução e de resultados de teste, disponibilizados como fonte de consulta para apoiar planejamento de futuras instâncias de processos de teste.
6.4 Práticas Ágeis
As prática ágeis a serem mapeadas para as características de agilidade e para as
atividades de teste de software são: Backlog de produto, Cliente presente,
Desenvolvimento orientado a testes, Design simples, Equipe completa, Integração
contínua, Jogo de planejamento, Metáfora, Padrões de código, Propriedade coletiva do
código, Refatoração, Liberações freqüentes (Releases curtas), Reuniões diárias, Ritmo
138
sustentável, Visibilidade de projeto. Suas descrições consolidadas estão no capítulo 4.
Elas também foram avaliadas pelo estudo apresentado no capítulo 5.
6.5 Mapeamento das Práticas para as Características de
Agilidade
O mapeamento entre as práticas ágeis e as características de agilidade pode ser
feito observando-se um ou mais dos possíveis relacionamentos entre elas. Este
mapeamento é importante para que, na escolha das práticas a serem adotadas, sejam
consideradas apenas as características desejadas para o processo de teste de software.
Neste trabalho será adotado o relacionamento que indica se uma determinada prática
pode ou não apoiar ou ajudar a alcançar determinada característica de agilidade,
conforme proposto e utilizado no trabalho de QUMER e HENDERSON-SELLERS
(2008). O trabalho destes autores, dentre os que foram encontrados na literatura técnica,
é o que mais se alinha com as idéias do foco desta pesquisa, no que diz respeito à
associação de práticas ágeis com as características de agilidade.
Nesta seção, cada prática será individualmente analisada com relação a todo o
conjunto de características de agilidade, buscando identificar e indicar se pode ou não
haver o mapeamento da prática para cada uma das características. Em caso afirmativo
será explicitado o raciocínio utilizado para embasar ou fundamentar o mapeamento. A
análise se baseará nos componentes conceituais identificados nas descrições das práticas
e das características de agilidade. Pelo fato de as características de agilidade estarem em
um nível de abstração mais alto, os mapeamentos entre elas e as práticas ágeis serão
definidos através de uma análise criteriosa com base na interpretação dos textos que
descrevem seus respectivos significados (capítulos 4 e 3). Nas tabelas que se seguem,
para cada prática, são inseridas apenas as características para as quais foi possível
identificar um relacionamento, com uma justificativa em termos de contribuição da
prática para a característica. Características não incluídas nas tabelas, não serão
mapeadas para as respectivas práticas.
Prática 1- Backlog de produto
Característica Embasamento: o backlog de produto ...Adaptabilidade mantido atualizado favorece a identificação de eventual necessidade
de mudança.
139
Característica Embasamento: o backlog de produto ...Auto-organização atualizado pode ser mais um elemento para apoiar a identificação das
melhores maneiras para se trabalhar.Emergência pode ser um mecanismo para facilitar a aceitação de que requisitos
surjam.Leanness pode apoiar a eventual eliminação de recursos que não são
necessários para construção do produto, gerando economia, que é um valor percebido pelo cliente.
Reflexão e Introspecção pode apoiar a identificação de eventuais necessidades de melhorias.Ser Colaborativo pode apoiar a disseminação de informações sobre o trabalho a ser
feito.Ser Cooperativo se apresenta como uma das oportunidades para interação entre partes
interessadas.Ser Incremental pode apoiar o planejamento de incrementos ou pequenas liberações
com novas funcionalidades.Ser Iterativo pode ajudar no planejamento dos ciclos curtos a partir dos itens de
backlog.
Prática 2- Cliente presente
CaracterísticaEmbasamento: o cliente presente e fazendo parte da
equipe ...Adaptabilidade favorece a identificação mais rápida de necessidades de mudanças
nos requisitos, alertando a equipe mais cedo para que possa reagir adequadamente a situações não previstas.
Emergência pode favorecer a emergência de requisitos durante o ciclo de vida do produto.
Incorporação de Retroalimentação (feedback)
e portanto mais próximo dos desenvolvedores, pode facilitar aretroalimentação com mais frequência.
Ser Colaborativo pode favorecer a comunicação rápida entre os membros da equipe, já que é uma fonte comum de informações, inclusive de retroalimentação.
Ser Cooperativo tem possibilidade de estar mais próximo da equipe e de ser um elemento ativo no processo de desenvolvimento.
Ser Incremental pode apoiar o planejamento dos incrementos para o produto, inclusive com atualização freqüente das prioridades.
Ser Iterativo pode ajudar na programação dos ciclos curtos, bem como do que estará incluído neles.
Prática 3- Desenvolvimento orientado a testes
Característica Embasamento: o desenvolvimento orientado a testes ...Orientação a Pessoas favorece as chances de melhoria de qualidade do trabalho dos
desenvolvedores.Ser Incremental favorece os testes dos incrementos para posterior integração.Ser Iterativo permite gerar suítes de testes de regressão que ajudam na repetição
dos ciclos de desenvolvimento.Testes Constantes naturalmente conduz a testes constantes.
140
Prática 4- Design simples
CaracterísticaEmbasamento: o design simples (simplicidade nas
soluções) ...Adaptabilidade pode favorecer a adaptação para atender situações não previstas
(mudanças nos requisitos, na equipe, no orçamento, nos fornecedores de recursos, dentre outras)
Emergência pode ajudar na incorporação de requisitos novos, na medida em que facilita a análise do que precisa ser modificado para atender o requisito emergente.
Leanness contribui significativamente para a eliminação de perdas.Orientação a Pessoas representada nos artefatos construídos, favorece a comunicação, que
é um elemento fundamental na interpretação desta característica.
Prática 5- Equipe completa
CaracterísticaEmbasamento: equipes completas, com pessoas de
múltiplos perfis de capacitação e espírito de grupo ...Adaptabilidade apresentam maiores facilidades de adaptação para atender mudanças.Auto-organização podem definir melhor as maneiras mais adequadas de trabalho,
considerando mais possibilidades no processo de escolha.Orientação a Pessoas apresentam condições ou oportunidades de aprendizado dentro da
própria equipe, podendo levar à melhoria de produtividade, qualidade e desempenho.
Reflexão e Introspecção podem ser mais efetivas na identificação do que precisa ser melhorado.
Prática 6- Integração contínua
CaracterísticaEmbasamento: a integração contínua para revelar
falhas ...Convergência apóia as entregas incrementais do software.Incorporação de Retroalimentação (feedback)
facilita a manter continuamente disponível uma versão executável, viabilizando retroalimentações mais freqüentes.
Leanness permite revelar falhas mais cedo, contribuindo para redução de custos e melhoria de qualidade que são valores percebidos pelo cliente.
Ser Incremental apóia as entregas incrementais do software.Testes Constantes conduz naturalmente a testes constantes.
Prática 7- Jogo de planejamento
CaracterísticaEmbasamento: o jogo de planejamento, envolvendo
desenvolvedores e clientes ...Incorporação de Retroalimentação (feedback)
facilita a retroalimentação com maior freqüência e rapidez.
Orientação a Pessoas busca balancear os interesses do cliente com a capacidade da equipe.Ser Cooperativo apresenta como uma de suas vantagens a participação ativa do
cliente.
141
CaracterísticaEmbasamento: o jogo de planejamento, envolvendo
desenvolvedores e clientes ...Ser Incremental pode apoiar a definição dos incrementos.
Prática 8- Metáfora
Característica Embasamento: a metáfora ...Orientação a Pessoas busca o estabelecimento de um entendimento comum para o projeto,
o que pode contribuir para a comunicação, um elemento fundamental desta prática.
Prática 9- Padrões de código
Característica Embasamento: os padrões de código ...Adaptabilidade facilitam o entendimento e a comunicação via código, melhorando as
condições da equipe para fazer mudanças.Leanness podem reduzir o esforço de criação e modificação do código,
podendo levar a redução de custos e melhoria de qualidade.
Prática 10- Propriedade coletiva do código
Característica Embasamento: a propriedade coletiva do código ...Reflexão e Introspecção permite o exame do código escrito por outros, fazendo com que os
programadores adquiram melhor visão do produto como um todo, podendo apresentar contribuições mais significativas para melhorias.
Prática 11- Refatoração
Característica Embasamento: a refatoração ...Adaptabilidade foca no código simples, limpo e não repetitivo, que pode ser
modificado facilmente quando a necessidade de mudança surgir.
Prática 12- Liberações frequentes
Característica Embasamento: as liberações frequentes ...Incorporação de Reatrolimentação (feedback)
favorecem a retroalimentação mais freqüente.
Ser Cooperativo permitem que o cliente possa rever o produto mais frequentemente, podendo identificar defeitos e fazer ajustes nos requisitos, tendo melhores condições de cooperar provendo retroalimentações mais freqüentes.
Ser Incremental naturalmente conduzem aos incrementos desenvolvidos em ciclos rápidos.
142
Prática 13- Reuniões diárias
Característica Embasamento: as reuniões diárias ...Auto-organização são realizadas também para organizar as atividades diárias, podendo,
portanto, apoiar a auto-organização das equipes.Emergência ao permitir o acompanhamento do progresso, podem também apoiar
o reconhecimento de princípios e estruturas de trabalho mais adequados, durante o desenvolvimento, uma vez que requisitos e tecnologias podem emergir ao longo do ciclo de vida do produto.
Incorporação de Retroalimentação (feedback)
proporcionam uma oportunidade para retroalimentações rápidas.
Orientação a Pessoas naturalmente proporcionam oportunidades para a equipe expor suas preocupações, fortalecendo-a, de certa forma, em relação a processos e tecnologias.
Reflexão e Introspecção podem ajudar a consolidar a percepção das pessoas sobre eventuais problemas, preparando-as, de certa forma, para as reuniões de reflexão e introspecção ao final de cada subprojeto.
Prática 14- Ritmo sustentável
Característica Embasamento: o ritmo sustentável ...Orientação a Pessoas valoriza as pessoas e as fortalece ao prover condições para que
apresentem desempenho e qualidade de trabalho aceitáveis.
Prática 15- Visibilidade de projeto
Característica Embasamento: a visibilidade de projeto ...Adaptabilidade fornece às equipes artefatos e status atualizados do projeto, apoiando
a mudança de comportamento para se adequar a novas situações.Incorporação de Retroalimentação (feedback)
viabiliza a disponibilização de informações atualizadas sobre o status do projeto, podendo assim apoiar a busca de retroalimentação por parte dos membros das equipes.
Leanness facilita fornecer às equipes o status atualizado do projeto, podendo estimular a habilidade de realizar mais trabalho com menos esforço, bem como a eliminação de perdas.
Orientação a Pessoas facilita fornecer às equipes artefatos e status atualizados do projeto podendo fazer com que elas se sintam valorizadas, além de melhorar a comunicação, um elemento fundamental desta característica.
Reflexão e Introspecção propicia o conhecimento sobre o status do projeto pelas equipes, podendo conduzir a contribuições mais significativas quanto a “o que” precisa ser melhorado.
143
6.6 Matriz de Associação entre Práticas Ágeis e
Características de Agilidade
A partir das associações identificadas anteriormente, será montada uma matriz
onde em uma das dimensões ficarão representadas as práticas ágeis e na outra dimensão
as características de agilidade. Em cada célula das interseções entre as linhas e as
colunas da matriz, fica um valor (um ou zero), que indica se a prática apóia ou não a
característica de agilidade. Uma prática pode apoiar, nenhuma, ou pode apoiar qualquer
número de características. Uma característica pode ser apoiada por nenhuma ou por
qualquer número de práticas. Esta matriz pode apresentar melhor uma idéia sobre como
fica o mapeamento do conjunto de práticas ágeis para o conjunto de características de
agilidade.
144
Tabela 6-3 – Matriz de Mapeamento entre Características de Agilidade e Práticas Ágeis
[adaptado de QUMER e HENDERSON-SELLERS, 2008]
Características
Práticas
Adap-tabili-dade
Auto-organi-zação
Emer-gência
Equipes peque-
nas
Incor-poração de Retroali-mentação (feedback)
Lean-ness
Modu-laridade
Orien-tação a Pessoas
Refle-xão e
Intros-pecção
Ser Cola-bo-
rativo
Ser Coope-rativo
Ser Incre-mental
Ser Itera-tivo
Testes Cons-tantes
Time-Boxing
Trans-parên-
cia
Backlog de produto
1 1 1 0 0 1 0 0 1 1 1 1 1 0 0 0
Cliente presente 1 0 1 0 1 0 0 0 0 1 1 1 1 0 0 0Desenvolvimento orientado a testes
0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0
Design simples 1 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0
Equipe completa 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0Integração contínua
0 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0
Jogo de planejamento
0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0
Metáfora 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
Padrões de código 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0
Propriedade coletiva do código
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
Refatoração 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Releases curtas 0 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0
Reuniões diárias 0 1 1 0 1 0 0 1 1 0 0 0 0 0 0 0
Ritmo sustentável 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
Visibilidade de projeto
1 0 0 0 1 1 0 1 1 0 0 0 0 0 0 0
145
Houve 4 características que não foram mapeadas por nenhuma das práticas ágeis
identificadas na revisão sistemática da literatura. São elas: equipes pequenas,
modularidade, time-boxing e transparência. Uma possível hipótese que poderia estar
associada com esta ocorrência seria que o conjunto de práticas ágeis identificado e
avaliado pela pesquisa de opinião ainda se encontra incompleto. Também poderia ser
por algum possível no mapeamento realizado. Ou ainda, que as 4 características não são
essenciais, apesar de indicação diversa ter sido encontrada na literatura técnica.
Todas as práticas foram mapeadas para pelo menos uma característica de
agilidade.
6.7 Mapeamento das Práticas para as Atividades de Processos
de Teste de Software
De modo semelhante ao descrito para o mapeamento entre as características de
agilidade e as práticas ágeis, agora será aplicado um procedimento para mapear as
práticas ágeis para as atividades do processo padrão de teste de software. Este
mapeamento, que ainda não pudemos encontrar na literatura técnica, pode ser feito de
modo semelhante ao proposto por QUMER e HENDERSON-SELLERS (2008) para as
características de agilidade, observando-se o relacionamento entre as práticas ágeis e as
atividades do processo de teste. A idéia é determinar se cada prática ágil pode ou não
apoiar cada uma das atividades do processo padrão de teste de software.
Cada prática foi individualmente analisada com relação a todo o conjunto de
atividades de teste de software identificado no processo adotado como genérico,
buscando identificar e indicar se pode ou não haver o mapeamento da prática para cada
uma das atividades. Em caso afirmativo será explicitado o raciocínio utilizado para
embasar ou fundamentar o mapeamento. A análise se baseou nos componentes
conceituais identificados nas descrições das práticas e das atividades de teste, bem como
em valores que cada prática pode eventualmente agregar ao processo de teste de
software, tendo em vista os respectivos artefatos ou produtos de trabalho produzidos por
cada atividade. Nesta análise, procurou-se observar se cada prática poderia apoiar a
obtenção dos produtos de trabalho das atividades, além de considerar cada prática na
essência de suas descrições capturadas na literatura, no contexto dos métodos ágeis.
Outro aspecto importante a ser considerado nesta análise, é que o foco deste trabalho é
146
trazer a agilidade para o processo de teste de software e não incorporar atividades de
teste às práticas ágeis.
As descrições de cada prática e de cada atividade do processo padrão de teste
podem ser encontradas nos capítulos 4 e na seção 6.3 respectivamente. Nas tabelas que
se seguem, para cada prática, são inseridas apenas as atividades para as quais foi
possível identificar um mapeamento com uma justificativa em termos de contribuição
da prática para a atividade. Vale enfatizar que a análise de cada prática com respeito a
possibilidade de sua contribuição para com as atividades do processo de teste de
software, além de se basear nos componentes conceituais de suas respectivas descrições,
foi feita considerando fortemente o que cada atividade tem que gerar como resultado,
tendo em vista os produtos de trabalho ou artefatos produzidos. Atividades não
incluídas nas tabelas, não serão mapeadas para as respectivas práticas.
Prática 1- Backlog de produto
Atividade Embasamento: o backlog de produto ...Planejar Testes pode apoiar a definição dos itens a serem testados. Pode também
facilitar um acompanhamento para manter o plano de testes atualizado.
Prática 2- Cliente presente
Atividade Embasamento: o cliente presente ...Planejar Testes pode auxiliar na solução de eventuais questões incidentes, bem como
na priorização dos itens a serem testados e no estabelecimento de critérios para aceitação.
Projetar Testes pode apoiar a identificação de casos de teste.
Prática 4- Design simples
AtividadeEmbasamento: o design simples, sem complexidade
desnecessária ...Projetar Testes pode facilitar a identificação de casos e procedimentos de teste.Especificar Casos de Teste pode facilitar a identificação de restrições e dependências com outros
casos de teste.Definir Procedimentos de Teste.
pode facilitar a identificação dos passos a serem seguidos durante os testes.
147
Prática 5- Equipe completa
Atividade
Embasamento: ter uma equipe completa, envolvendo diferentes perfis, é benéfico para o processo de teste de software. Por exemplo, um especialista em segurança
pode apoiar ...Projetar Testes na identificação de casos de teste envolvendo questões de
autenticação, autorização e auditoria.Especificar Casos de Teste na especificação detalhada de casos de teste envolvendo questões de
autenticação, autorização e auditoria.
Prática 7- Jogo de planejamento
Atividade Embasamento: o jogo de planejamento, ...Planejar Testes sendo contínuo e progressivo, com prioridades estabelecidas pelo
cliente, pode apoiar o estabelecimento de um plano de testes alinhado com as necessidades do projeto.
Projetar Testes com prioridades estabelecidas pelo cliente, pode apoiar o estabelecimento de prioridades no projeto de teste.
Prática 8- Metáfora
AtividadeEmbasamento: o entendimento comum do projeto
pode ...Planejar Testes apoiar a busca de um planejamento adequado para os testes.Projetar Testes facilitar o projeto de teste, na identificação de casos e procedimentos
de teste.
Prática 12- Liberações frequentes
Atividade Embasamento: liberações freqüentes ...Executar Testes influenciam as iterações ou quantidade de vezes que execuções de
teste devem acontecer.Analisar Resultados influenciam as iterações ou quantidade de vezes que análise de
resultados devem acontecer.Monitorar e Controlar o
Processo de Testeinfluenciam as iterações ou quantidade de registros das tarefas executadas e dos resultados obtidos.
Prática 13- Reuniões diárias
AtividadeEmbasamento: o acompanhamento do progresso do
projeto pode ...Planejar Testes melhorar a comunicação e auxiliar a elaboração de um plano de teste
alinhado com a realidade do projeto.Projetar Testes
facilitar a integração das atividades de teste com as de desenvolvimento.
Especificar Casos de Teste Definir Procedimentos de Teste.Executar Testes
148
AtividadeEmbasamento: o acompanhamento do progresso do
projeto pode ...Analisar ResultadosMonitorar e Controlar o
Processo de Teste
Prática 15- Visibilidade de projeto
AtividadeEmbasamento : fornecer às equipes o status do
projeto pode ...Planejar Testes melhorar a comunicação e auxiliar a elaboração de um plano de teste
alinhado com a realidade do projeto.Projetar Testes
facilitar a integração das atividades de teste com as de desenvolvimento.
Especificar Casos de Teste Definir Procedimentos de Teste.Executar TestesAnalisar ResultadosMonitorar e Controlar o
Processo de Teste
Não foi possível identificar o mapeamento das práticas Desenvolvimento
orientado a testes, Integração contínua, Padrões de código, Propriedade coletiva do
código, Refatoração e Ritmo sustentável para qualquer atividade do processo padrão de
teste de software, em função de não ter sido encontrada uma justificativa para afirmar
que elas contribuem para que alguma das atividades do processo de teste de software
alcancem seus respectivos resultados tendo como foco os produtos de trabalho ou
artefatos que cada atividade deve gerar, conforme apresentado no capítulo 2.
6.8 Matriz de Associação entre Práticas Ágeis e Atividades de
Processos de Teste de Software
A matriz de mapeamento entre as oito atividades do processo padrão de teste de
software e as quinze práticas ágeis identificadas teria, portanto, oito colunas para as
atividades de teste e quinze linhas para as práticas ágeis, com o aspecto apresentado na
Tabela 6-4 que se segue, onde em cada intersecção de linha e coluna há o valor um ou
zero, conforme se tenha identificado ou não um relacionamento entre elas, se a prática
pode ou não apoiar cada atividade de teste, respectivamente. Uma prática pode apoiar,
nenhuma, ou pode apoiar qualquer número de atividades de teste. Uma atividade de
teste pode ser apoiada por nenhuma ou por qualquer número de práticas. Esta matriz
pode apresentar melhor a idéia sobre como fica o mapeamento do conjunto de práticas
149
ágeis para o conjunto de atividades de teste associado com o processo padrão adotado
para este trabalho. Na matriz apresentada, para fins de simplificação, foi omitida a
coluna referente à atividade Fechar atividades de teste, uma vez que não foi
identificado qualquer relacionamento entre ela e alguma prática ágil.
Tabela 6-4 – Matriz de Mapeamento entre Atividades de Teste e Práticas Ágeis
Atividades
Práticas
Plane-jar
TestesProjetar Testes
Especi-ficar
Casos de Teste
Definir Proce-dimen-tos de Teste.
Execu-tar Testes
Anali-sar
Resul-tados
Monitorar e Controlar o Processo de Teste
Backlog de produto 1 0 0 0 0 0 0
Cliente presente 1 1 0 0 0 0 0
Desenvolvimento orientado a testes
0 0 0 0 0 0 0
Design simples 0 1 1 1 0 0 0
Equipe completa 0 1 1 0 0 0 0
Integração contínua 0 0 0 0 0 0 0
Jogo de planejamento 1 1 0 0 0 0 0
Metáfora 1 1 0 0 0 0 0
Padrões de código 0 0 0 0 0 0 0
Propriedade coletiva do código
0 0 0 0 0 0 0
Refatoração 0 0 0 0 0 0 0
Releases curtas 0 0 0 0 1 1 1
Reuniões diárias 1 1 1 1 1 1 1
Ritmo sustentável 0 0 0 0 0 0 0
Visibilidade de projeto
1 1 1 1 1 1 1
Não foram mapeadas para nenhuma atividade de teste as práticas
Desenvolvimento orientado a testes, Integração contínua, Padrões de código,
Propriedade coletiva do código, Refatoração e Ritmo sustentável. Tal fato pode implicar
em restrições quanto a adoção destas práticas ágeis no processo de teste de software
para fins de inserção de agilidade, no sentido de que elas não contribuem para os
resultados das atividades de teste especificadas para este processo padrão adotado no
presente trabalho. Se adotadas, independentemente deste resultado de mapeamento, e
150
mesmo estando mapeadas para alguma característica de agilidade, tais práticas não
contribuiriam efetivamente para promover a agilidade do processo de teste de software,
onerando-o apenas, e ferindo um dos princípios do manifesto ágil: “A simplicidade,
como arte de maximizar a quantidade de trabalho não executado é essencial” no
desenvolvimento ágil de software. Implementar uma prática, demanda esforço, tem
custos e pode eventualmente ser invasiva em um processo de software, gerando efeito
diverso do desejado para o processo.
6.9 Avaliação dos Mapeamentos Estabelecidos das Práticas
Ágeis para as Características de Agilidade e Atividades de
Teste de Software
Para dar prosseguimento aos trabalhos desta pesquisa, os mapeamentos
estabelecidos entre as práticas ágeis e as características de agilidade, bem como entre as
práticas ágeis e as atividades de teste de software foram submetidos a uma avaliação
externa.
A opção escolhida para avaliar tais mapeamentos foi uma revisão por pares,
cujos detalhes são apresentados a seguir.
6.9.1 Planejamento da Revisão por Pares
A população de participantes foi selecionada a partir de uma busca por
pesquisadores/desenvolvedores efetuada na base de dados do CNPq, através da
plataforma Lattes (www.cnpq.br/lattes). Os seguintes perfis foram utilizados na busca
por pesquisadores/desenvolvedores: experiência com métodos ágeis, experiência com
diferentes visões de processos de software, experiência com teste de software,
experiência ou forte contato com a indústria.
Foram selecionados 55 participantes para a revisão por pares, sendo 20 com
experiência em métodos ágeis, 28 com experiência em processos de software, 21 com
experiência em teste de software, e 36 que mantêm forte contato com a indústria. A
sobreposição destes perfis é apresentada na seção 6.9.2.
O volume de trabalho para realizar a revisão de todos os mapeamentos
envolvidos é muito significativo. Por isto, o trabalho foi dividido, através da formação
de 3 grupos, com 5 práticas para cada. Em cada grupo serão apresentadas as associações
das práticas com cada uma das 16 características de agilidade e com as 8 atividades de
151
teste de software, conforme descrito na seção 6.8. O critério de alocação das práticas a
cada um dos 3 grupos levou em conta a necessidade de tentar equilibrar o esforço por
parte dos revisores, buscando um equilíbrio entre mapeamentos estabelecidos e
mapeamentos não estabelecidos a serem analisados pelos revisores. Além disso, buscou-
se de uma certa forma, equilibrar nos 3 grupos as quantidades de práticas que no estudo
descrito no capítulo 5 alcançaram níveis de pertinência mais altos, medianos e mais
baixos.
A instrumentação para realizar a revisão foi elaborada, prevendo que o revisor
teria 3 possibilidades para expressar seus resultados. Para cada mapeamento, seja entre
práticas ágeis e características de agilidade, seja entre práticas ágeis e atividades de teste
de software, o revisor poderia, após sua análise: 1- Discordar do mapeamento
previamente estabelecido; 2- Concordar com o mapeamento previamente estabelecido,
mas discordar da justificativa apresentada para este mapeamento; 3- Identificar um
mapeamento novo, não identificado previamente. E ainda, o revisor poderia concordar
com o mapeamento e com a justificativa previamente estabelecida, caso em que ele não
teria que fazer qualquer registro no instrumento da revisão. Os conjuntos completos de
instrumentos preparados para a revisão envolvendo as características de agilidade são
apresentados no apêndice D. Cada conjunto inclui as descrições de cada prática ágil
alocada ao grupo, as descrições de todas as características de agilidade, e uma planilha
com instruções, termo de consentimento e formulário para registro dos resultados da
revisão.
Cada pesquisador/desenvolvedor identificado na forma do que já foi descrito nos
parágrafos anteriores desta seção recebeu uma primeira mensagem, convidando-o para
participar do estudo. Para aqueles que responderam positivamente, foi enviada, na
sequência de chegada das respostas, uma segunda mensagem com orientações e em
anexo a instrumentação associada ao grupo, para realizar a revisão dos mapeamentos
entre práticas ágeis e características de agilidade, conforme já descrito nesta seção. A
alocação dos revisores aos grupos foi feita alocando-se cada revisor, na medida em que
ia respondendo positivamente, a cada grupo a partir do grupo 1, seqüenciado pelos
grupos 2 e 3. Após a alocação de um revisor ao grupo 3, o revisor respondente seguinte
foi alocado ao grupo 1 e a sequência foi mantida até a alocação do último revisor que
respondeu positivamente, sob a forma de uma fila circular.
152
Na medida em que os revisores retornavam o resultado de suas revisões, para
aqueles que responderam (através do termo de consentimento) que gostariam de
participar da segunda etapa da revisão (mapeamentos entre práticas ágeis e atividades de
teste de software), foi enviada, na sequência de chegada dos retornos com os resultados
das revisões sobre práticas ágeis e características de agilidade, uma terceira mensagem
com orientações e em anexo a instrumentação associada com o grupo ao qual o revisor
já estava alocado, para agora realizar a revisão dos mapeamentos entre práticas ágeis e
atividades de teste de software. Os conjuntos completos de instrumentos preparados
para a revisão envolvendo as atividades de teste são apresentados no apêndice D. Cada
conjunto inclui as descrições de cada prática ágil alocada ao grupo, as descrições de
todas as atividades de teste com seus respectivos produtos de trabalho, e uma planilha
com instruções e formulário para registro dos resultados da revisão. As práticas
alocadas a cada um dos 3 grupos em que o trabalho de revisão foi dividido podem ser
observadas nos instrumentos elaborados. No apêndice D são também apresentados os
textos de cada uma das 3 mensagens enviadas aos revisores.
No dia 20 de dezembro de 2011 foi enviada uma mensagem de lembrete para os
revisores que haviam recebido o material da revisão envolvendo mapeamentos das
práticas ágeis para as características de agilidade há mais de 10 dias e ainda não tinham
retornado os resultados.
6.9.2 Execução da Revisão por Pares
Para cada um dos 55 pesquisadores/desenvolvedores selecionados foi enviado
por email, um convite para participar da revisão. Os convites foram enviados no dia 08
de dezembro de 2011. Dos emails enviados, 8 falharam e tiveram novos emails
pesquisados. Destes, 3 falharam novamente, ficando o número total de 52 convidados.
A superposição dos perfis destes 52 participantes convidados se deu da seguinte
forma: 6 com experiência em métodos ágeis, 4 com experiência em métodos ágeis e
experiência em teste de software, 5 com experiência em métodos ágeis e forte contato
com a indústria, 4 com experiência em métodos ágeis e experiência em teste de software
além de forte contato com a indústria; 4 com experiência em processos de software, 1
com experiência em processos de software e experiência em teste de software, 12 com
experiência em processos de software e forte contato com a indústria, 4 com experiência
em processos de software e experiência em teste de software além de forte contato com
153
a indústria; 2 com experiência em teste de software, 10 com experiência em teste de
software e forte contato com a indústria.
As respostas ao convite começaram a acontecer no mesmo dia 08 de dezembro.
A última resposta chegou no dia 20 de dezembro. Dos 52 convidados, 20 responderam
que sim, gostariam de participar da revisão. Dois responderam que não. Não
responderam ao convite 30 pesquisadores/desenvolvedores.
Dentre os 20 que responderam sim, um desistiu posteriormente, alegando não
dispor do tempo necessário para realizar o trabalho de revisão. Dos 19 que restaram 8
retornaram as revisões dos mapeamentos entre práticas ágeis e características de
agilidade, todos manifestando, no termo de consentimento, a concordância em participar
também da revisão dos mapeamentos de práticas ágeis para atividades de teste de
software. O primeiro retorno com respostas sobre os mapeamentos envolvendo
características de agilidade ocorreu em 13 de dezembro e o último retorno chegou dia
08 de janeiro de 2012. Para estes 8 participantes foi enviada a terceira mensagem com
instruções e instrumentação em anexo para realização da última etapa da revisão (os
mapeamentos envolvendo atividades de teste). O primeiro envio desta terceira
mensagem aconteceu no mesmo dia em que o revisor retornava os resultados da revisão
envolvendo as características de agilidade. Destes 8 revisores, 5 retornaram as revisões
dos mapeamentos entre práticas ágeis e atividades de teste. O primeiro retorno com os
resultados desta segunda etapa de revisões aconteceu no dia 20 de dezembro de 2011 e
o último retorno chegou no dia 04 de janeiro de 2012. A Tabela 6-5 mostra a
distribuição dos perfis dos revisores que responderam positivamente aceitando o convite
para participar do estudo nos 3 grupos de revisão. Todos os grupos foram contemplados
com os 4 perfis de revisores.
Tabela 6-5 – Distribuição dos Perfis dos Revisores nos Grupos Alocados
Id
Exp. emMétodos
Ágeis
Exp. em Proc. de Software
Exp. em Teste de Software
Forte contato
IndústriaGrupo
AlocadoRespondeu
Caract.Respondeu Atividades
G1-1 sim 1 não nãoG1-2 sim sim 1 não nãoG1-3 sim sim sim 1 não nãoG1-4 sim sim 1 sim simG1-5 sim sim 1 não nãoG1-6 sim 1 não nãoG1-7 sim 1 sim nãoG2-1 sim sim 2 sim simG2-2 sim sim 2 não nãoG2-3 sim 2 sim não
154
Id
Exp. emMétodos
Ágeis
Exp. em Proc. de Software
Exp. em Teste de Software
Forte contato
IndústriaGrupo
AlocadoRespondeu
Caract.Respondeu Atividades
G2-4 sim sim 2 sim simG2-5 sim sim 2 sim nãoG2-6 sim sim 2 não nãoG3-1 sim sim 3 desistiu desistiuG3-2 sim 3 não nãoG3-3 sim sim 3 não nãoG3-4 sim sim sim 3 não nãoG3-5 sim sim 3 não nãoG3-6 sim sim 3 sim simG3-7 sim sim sim 3 sim sim
Dentre os revisores que responderam sobre os relacionamentos entre práticas
ágeis e características de agilidade há 3 com experiência em métodos ágeis, 1 com
experiência em processos de software, 6 com experiência em teste de software e 5 com
forte contato com a indústria. Dentre os revisores que responderam sobre os
relacionamentos entre práticas ágeis e atividades de teste de software há 2 com
experiência em métodos ágeis, 1 com experiência em processos de software, 4 com
experiência em teste de software e 4 com forte contato com a indústria. As
sobreposições destes perfir podem ser observadas na Tabela 6-5.
6.9.3 Análise de Resultados da Revisão por Pares
No total geral, foram revisados 240 mapeamentos entre práticas ágeis e
características de agilidade, e 120 mapeamentos entre práticas ágeis e atividades de teste
de software.
Os critérios para aceitar ou não a opinião dos revisores no sentido de modificar
os mapeamentos estabelecidos envolvem uma análise minuciosa dos textos
apresentados como justificativa para as modificações sugeridas, verificando se eles
apresentavam uma fundamentação adequada para cada caso. Além disso, foi observado
se era possível identificar, nos textos apresentados pelos revisores como justificativa,
alguma evidência de que o revisor eventualmente poderia ter se enganado ao interpretar
os significados apresentados para as práticas ágeis/características de
agilidade/atividades de teste de software ou as justificativas para os mapeamentos
previamente estabelecidos.
Nas seções que se seguem são apresentados os resultados da revisão por pares,
feita para os mapeamentos previamente estabelecidos.
155
6.9.3.1 Mapeamentos das Práticas Ágeis para as Características de
Agilidade
Dos mapeamentos entre práticas ágeis e características de agilidade revisados
(240 mapeamentos), 2 foram suprimidos e 10 foram adicionados, em decorrência dos
resultados da revisão por pares. A seguir são apresentadas as discrepâncias observadas,
as análises destas discrepâncias e as decisões tomadas quanto aos mapeamentos entre
práticas ágeis e características de agilidade, apenas para os mapeamentos que foram
modificados em função da análise dos resultados. Para os mapeamentos que não foram
modificados, as análises dos resultados são apresentadas no apêndice F.
6.9.3.1.1 Discordâncias dos Mapeamentos Previamente Estabelecidos (Práticas
X Características)
Para cada mapeamento entre as práticas ágeis e as características de agilidade,
separados por grupo e para cada revisor, as justificativas para as discordâncias quanto
aos mapeamentos que foram previamente estabelecidos serão apresentadas e analisadas
conforme se segue. Os revisores não serão identificados, sendo aqui referenciados por
um código alfanumérico de acordo com a Tabela 6-5. Os critérios utilizados foram
apresentados na seção 6.9.3.
Grupos 1 e 3
Os revisores dos grupos 1 e 3 não apresentaram resultados que após serem
analisados gerassem modificações nos mapeamentos previamente estabelecidos entre
práticas ágeis e características de agilidade.
Grupo 2
Os revisores do grupo 2 apresentaram resultados que após serem analisados
geraram modificações nos mapeamentos previamente estabelecidos entre práticas ágeis
e características de agilidade. Segue a análise destes resultados.
Prática: Padrões de código
Característica: Leanness
Justificativa revisor G2-1: “Não concordo que o uso de padrões de código
contribui com redução de custos, pois existe um esforço extra de refactoring do
156
software para implementar os padrões, compensando o esforço reduzido na
criação e modificação de código.”
Análise: Não foram encontrados estudos apresentando evidências sobre a
relação entre esforço de implementação de padrões de código e redução de
esforço na criação do código por uso destes mesmos padrões.
Decisão: suprimir o mapeamento.
6.9.3.1.2 Discordâncias das Justificativas para Mapeamentos Previamente
Estabelecidos (Práticas X Características)
Para cada mapeamento entre as práticas ágeis e as características de agilidade,
separados por grupo e para cada revisor, as discordâncias quanto às justificativas para os
mapeamentos que foram previamente estabelecidos serão apresentadas e analisadas. Os
revisores não serão identificados, sendo também aqui referenciados por um código
alfanumérico de acordo com a Tabela 6-5. Os critérios utilizados foram apresentados na
seção 6.9.3.
Grupo 1
Prática: Backlog de Produto
Característica: Adaptabilidade
Justificativa revisor G1-4: “mantido atualizado favorece a identificação de quais
partes devem ser modificadas (a necessidade de mudança do meu ponto de vista,
não é identificada através do backlog)”
Análise: O revisor tem razão. O conhecimento atualizado do que deve ser feito
para se chegar ao produto final não necessariamente significa capacidade e/ou
habilidade para adaptar rapidamente o processo e reagir a mudanças de última
hora.
Decisão: suprimir o mapeamento.
Grupo 2 e 3
Os revisores que trabalharam os mapeamentos entre práticas ágeis e
características de agilidade incluídos nos grupos 2 e 3 concordaram com as justificativas
apresentadas para cada um dos mapeamentos.
157
6.9.3.1.3 Mapeamentos Adicionais Sugeridos (Práticas X Características)
Para cada mapeamento adicional entre as práticas ágeis e as características de
agilidade identificado pelos revisores, separados por grupo e para cada revisor, as
justificativas para inclusão do novo mapeamento serão apresentadas e analisadas. Os
revisores não serão identificados, sendo também aqui referenciados por um código
alfanumérico de acordo com a Tabela 6-5. Os critérios utilizados foram apresentados na
seção 6.9.3.
Grupo 1
Prática: Cliente presente
Característica: Leanness
Justificativa revisor G1-4: “a retroalimentação do cliente em tempo real,
indicando o que é essencial, ajuda na identificação precoce de partes do processo
que poderiam estar sendo considerados como de alto risco do ponto de vista dos
desenvolvedores mas que não representam riscos reais ao cliente. Estas partes
deveriam ser removidas do processo.”
Análise: O cliente presente poderia manter atualizadas as prioridades de
esforços para se atingir um nível de qualidade adequado a cada funcionalidade
do software, evitando desperdícios ou dispêndios de esforços desnecessários
especialmente em atividades de garantia de qualidade.
Decisão: adicionar o mapeamento.
Prática: Cliente presente
Característica: Orientação à Pessoas
Justificativa revisor G1-7: “o fato do cliente estar presente significa claramente a
intenção de privilegiar pessoas e suas necessidades no projeto”
Análise: A prática não implica em intenção clara de privilegiar pessoas e suas
necessidades. Contudo, pode apoiar dois elementos fundamentais da
característica: comunicação e cooperação.
Decisão: adicionar o mapeamento.
Prática: Cliente presente
158
Característica: Reflexão e Introspecção
Justificativa revisor G1-7: “O cliente participa da reflexão.”
Análise: O cliente fazendo parte da equipe pode apoiar na identificação do que
está sendo bem feito e do que precisa ser melhorado.
Decisão: adicionar o mapeamento.
Prática: Propriedade coletiva de código
Característica: Orientação à Pessoas
Justificativa revisor G1-7: “ter o código com acesso coletivo é claramente
privilegiar a equipe, dando-lhe responsabilidade.”
Análise: A propriedade coletiva de código, se efetivamente exercitada pela
equipe, pode apoiar a comunicação e eventualmente melhorar produtividade e
qualidade. Portanto pode, se exercitada (não basta estar instituída) apoiar a
característica.
Decisão: adicionar o mapeamento.
Grupo 2
Prática: Padrões de código
Característica: Ser Colaborativo
Justificativa revisor G2-5: “Incluir esta característica pois as pessoas vão
colaborando uma com as outras na definição do código, mesmo que seja na
utilização de padrões. É inerente a comunicação entre os desenvolvedores.”
Análise: A prática pode ser mais uma opção para reforçar a comunicação via
código, além de facilitar a integração, o que é encorajado pela característica.
Decisão: adicionar o mapeamento.
Grupo 3
Prática: Equipe completa
Característica: Time-boxing
Justificativa revisor G3-6: “Equipes completas podem ser mais efetivas no
momento de decidir limites de tempo para as iterações”
159
Análise: De fato as equipes completas podem apresentar mais capacidade para
buscar a fatia de tempo mais adequada para dividir um processo do projeto, e
fazer a divisão do trabalho em múltiplas entregas.
Decisão: adicionar o mapeamento.
Prática: Equipe completa
Característica: Leanness
Justificativa revisor G3-6: “Equipes completas oferecem a oportunidade de
combinar diversas habilidades no sentido de maximizar o desempenho.”
Análise: Possivelmente a equipe completa pode apoiar a realização de mais
trabalho com menos esforço, além de facilitar a remoção de atividades não
necessárias para se construir o produto conforme os requisitos.
Decisão: adicionar o mapeamento.
Prática: Liberações frequentes
Característica: Adaptabilidade
Justificativa revisor G3-6: “As liberações frequentes permitem que as
funcionalidades do projeto sejam priorizadas, ou que novas funcionalidades
sejam incluídas/excluídas, de acordo com as necessidade de adaptação à
mudanças estratégicas ou no escopo do projeto.”
Análise: As liberações frequentes, com funcionalidades de maior valor sendo
priorizadas podem apoiar a capacidade do processo ser adaptado para atender
mudanças de última hora nos requisitos e/ou no ambiente de desenvolvimento.
Decisão: adicionar o mapeamento.
Prática: Reuniões diárias
Característica: Ser Colaborativo
Justificativa revisor G3-7: Comentário: “Entendo a emergência dos processos
como a característica que faz com que estes processos surjam de forma
autônoma a medida que a equipe realiza o seu trabalho. Sendo assim, qual seria
a relação com as reuniões diárias.”
160
“Complementando o comentário acima, vejo a prática de reuniões diárias muito
mais ligada com colaboração e cooperação, que não aparecem entre os seus
relacionamentos.”
Análise: As prática favorece a disseminação de informações e o apoio à
integração de incrementos de software.
Decisão: adicionar o mapeamento.
Prática: Visibilidade de projeto
Característica: Auto-organização
Justificativa revisor G3-6: “A visibilidade do projeto fornece às equipes
informações que apóiam a auto-organização de forma que estas possam se
adequar à novas situações.”
Análise: O status atualizado do projeto, com seus artefatos, disponíveis para as
equipes pode contribuir para que as melhores maneiras de se trabalhar sejam
identificadas para completar os itens de trabalho.
Decisão: adicionar o mapeamento.
Em síntese, foram suprimidos 2 mapeamentos entre práticas ágeis e
características de agilidade (Padrões de código x Leanness, Backlog de produto
x Adaptabilidade). Foram adicionados 10 mapeamentos (Cliente presente x
Leanness, Cliente presente x Orientação à Pessoas, Cliente presente x
Reflexão e Introspecção, Propriedade coletiva de código x Orientação à Pessoas,
Padrões de código x Ser Colaborativo, Equipe completa x Time-boxing, Equipe
completa x Leanness, Liberações freqüentes x Adaptabilidade, Reuniões diárias
x Ser Colaborativo, Visibilidade de projeto x Auto-organização).
6.9.3.2 Mapeamentos das Práticas Ágeis para as Atividades de Teste
Com base nos resultados da revisão, não houve modificações dos mapeamentos
inicialmente estabelecidos entre práticas ágeis e atividades de teste de software. As
discrepâncias observadas, as análises destas discrepâncias e as decisões tomadas quanto
aos mapeamentos entre práticas ágeis e atividades de teste de software que levaram a
este resultado estão no apêndice G.
161
6.9.4 Resumo dos Resultados da Revisão por Pares
Foram obtidos 8 retornos com avaliações dos mapeamentos entre práticas ágeis e
características de agilidade, e 5 retornos com avaliações dos mapeamentos entre práticas
ágeis e atividades de teste de software. As distribuições quantitativas destes retornos
com relação aos grupos entre os quais o trabalho foi dividido e com relação aos
resultados obtidos, podem ser vistas na Tabela 6-6 e na Tabela 6-7 que se seguem.
Tabela 6-6 – Distribuição dos Resultados da Revisão dos Mapeamentos Práticas X Características
Resultado Grupo 1 Grupo 2 Grupo 3 TotaisDiscordância dos Mapeamentos 1 3 4 8Discordâncias das Justificativas 1 - - 1Mapeamentos Adicionais 15 13 7 35Totalizadores (Discrepâncias) 17 16 11 44
Tabela 6-7 – Distribuição dos Resultados da Revisão dos Mapeamentos Práticas X Atividades
Resultado Grupo 1 Grupo 2 Grupo 3 TotaisDiscordância dos Mapeamentos - - 11 11Discordâncias das Justificativas - - - -Mapeamentos Adicionais 5 6 - 11Totalizadores 5 6 11 22
Dentre os retornos obtidos dos revisores, apenas um mapeamento, entre práticas
ágeis e características de agilidade (Integração contínua X Ser Colaborativo) foi
identificado por 2 revisores (G2-3 e G2-4). Todos os demais retornos dos 360
mapeamentos revisados, seja por discrepância do mapeamento propriamente dito, seja
por discrepância quanto à justificativa previamente estabelecia, seja por mapeamento
adicional não identificado previamente, envolvem apenas a avaliação de um revisor.
Apenas um mapeamento teve a discordância de algum revisor sobre a justificativa para
ele apresentada previamente (Backlog de produto X Adaptabilidade). Excluindo-se o
revisor que discordou de todos os mapeamentos entre práticas ágeis e atividades de
testes, os 120 mapeamentos revisados não apresentaram discordâncias, apenas tiveram
identificados mapeamentos adicionais.
De acordo com os dados coletados, a análise e as decisões apresentadas na seção
anterior, as modificações a seguir apresentadas devem ser feitas na matriz de
162
associações entre práticas ágeis e características de agilidade e na matriz de associações
entre práticas ágeis e atividades de teste de software.
6.9.4.1 Mapeamentos entre Práticas Ágeis e Características de Agilidade
A Tabela 6-8 a seguir mostra um resumo das modificações definidas para os
mapeamentos entre práticas ágeis e características de agilidade, a partir das análises
apresentadas nas seções anteriores em cada uma das tabelas com os mapeamentos
adicionais ou que apresentaram discrepâncias.
Tabela 6-8 – Alterações nos Mapeamentos (Práticas X Características) Previamente Estabelecidos a partir dos Resultados da Revisão por Pares
Suprimidos Modificação da Justificativa AdicionadosPrática Característica Prática Característica Prática Característica
Padrões de código Leanness
Cliente presente Leanness
Backlog de produto Adaptabilidade
Cliente presente
Orientação à Pessoas
Cliente presente
Reflexão e Introspecção
Propriedade coletiva de código
Orientação à Pessoas
Padrões de código Ser ColaborativoEquipe completa Time-boxingEquipe completa LeannessLiberações frequentes AdaptabilidadeReuniões diártias Ser ColaborativoVisibilidade de projeto Auto-organização
6.9.4.2 Mapeamentos entre Práticas Ágeis e Atividades de Teste de
Software
Para o caso das atividades de teste de software não foram apuradas pelas análises
apresentadas nas seções anteriores nenhuma necessidade de alteração de mapeamentos
com as práticas ágeis, seja supressão, alteração de justificativa ou adição de
mapeamentos.
163
6.9.5 Novas Matrizes de Associação Atualizadas
Aplicando-se as modificações apresentadas na seção anterior, quanto à supressão
e/ou adição de relacionamentos ou associações entre as práticas ágeis e as características
de agilidade. Não houve modificações nos mapeamentos entre as práticas ágeis e as
atividades de teste de software. A nova matriz de associação entre as práticas ágeis e as
características de agilidade se apresenta conforme Tabela 6-9. A matriz de associação
entre as práticas ágeis e as atividades de teste de software permanece como apresentado
na Tabela 6-4.
164
Tabela 6-9 - Matriz de Mapeamento entre Características de Agilidade e Práticas Ágeis Atualizada
Características
PráticasAdap-tabili-dade
Auto-organi-zação
Emer-gência
Equipes peque-
nas
Incor-poração de Retroali-mentação (feedback)
Lean-ness
Modu-lari-dade
Orien-tação a Pessoas
Reflexão e In-
tros-pe-
cção
Ser Cola-bo-
rativo
Ser Coope-rativo
Ser Incre-mental
Ser Itera-tivo
Testes Cons-tantes
Time-Boxing
Transpa-rên-cia
Backlog de produto 0 1 1 0 0 1 0 0 1 1 1 1 1 0 0 0
Cliente presente 1 0 1 0 1 1 0 1 1 1 1 1 1 0 0 0Desenvolvimento orientado a testes
0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0
Design simples 1 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0
Equipe completa 1 1 0 0 0 1 0 1 1 0 0 0 0 0 1 0
Integração contínua 0 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0
Jogo de planejamento 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0
Metáfora 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
Padrões de código 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0Propriedade coletiva do código
0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0
Refatoração 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Releases curtas 1 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0
Reuniões diárias 0 1 1 0 1 0 0 1 1 1 0 0 0 0 0 0
Ritmo sustentável 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
Visibilidade de projeto 1 1 0 0 1 1 0 1 1 0 0 0 0 0 0 0
165
6.10 Conclusão
Este capítulo tratou os mapeamentos entre práticas ágeis e características de
agilidade e entre práticas ágeis e atividades do processo padrão de teste de software
adotado. Tais mapeamentos são uma parte do trabalho que envolve a solução para
inserir agilidade em processos de teste de software, a ser apresentada no capítulo 7.
Elaborar estes mapeamentos não é uma tarefa trivial. Por isso todos os
mapeamentos envolvendo as práticas ágeis, as características de agilidade e as
atividades de teste de software foram avaliados através de uma revisão por pares, que
contribuiu para o seu aperfeiçoamento e/ou fortalecimento. A grande maioria dos
mapeamentos inicialmente estabelecidos (ou não) tiveram a concordância dos revisores.
Algumas considerações sobre ameaças à validade da revisão se fazem necessárias:
A quantidade de revisores que retornaram seus resultados foi pequena.
Embora a revisão dos mapeamentos entre práticas ágeis e atividades de teste
demandasse menor esforço e apesar dos revisores terem manifestado sua
concordância em participar também dela, houve quantidade menor de
retornos para estes mapeamentos do que para os mapeamentos entre práticas
ágeis e características de agilidade que demandaram maior esforço.
Embora os perfis dos revisores tenham sido definidos de modo que suas
opiniões fossem válidas e importantes para apoiar o prosseguimento desta
pesquisa, dos 8 respondentes sobre os mapeamentos entre práticas ágeis e
características de agilidade, 5 não tinham experiência em métodos ágeis.
Dos 5 respondentes sobre os mapeamentos entre práticas ágeis e atividades
de teste de software, 1 não tinham experiência em teste de software.
Houve uma distribuição bastante esparsa das discordâncias apresentadas,
sendo que apenas 1 mapeamento (não estabelecido inicialmente) teve
discordância de mais de um revisor (mapeamento adicional entre a prática
Integração contínua e a característica Ser Colaborativo).
Há um risco de ter havido interpretação não muito adequada de alguma
justificativa apresentada pelos revisores durante a análise dos resultados,
podendo conduzir a decisões também inadequadas.
No caso dos mapeamentos das práticas ágeis para as atividades do processo de teste
de software, estão sendo trabalhados dois componentes concretos do processo que são
166
mais palpáveis, inclusive com as atividades de teste tendo seus resultados associados
com produtos de trabalho produzidos. Já no caso dos mapeamentos das práticas ágeis
para as características de agilidade, estão sendo trabalhados um componente concreto do
processo (as práticas) em contraposição a um componente altamente abstrato (as
características de agilidade). Portanto, estes mapeamentos devem ser revistos e
aperfeiçoados sempre que possível, devendo a ferramenta que fizer uso deles prever a
possibilidade de atualizar a base de conhecimento idealizada nesta pesquisa.
A definição destes mapeamentos, avaliados e atualizados, pode agora ser agregada
ao guia de agilidade para processos de teste de software, onde já se incluem outros
elementos dentre os quais se incluem também a caracterização de projetos de software e
a avaliação de resultados alcançados. Tal avaliação realimenta a consideração de lições
aprendidas em um processo de melhoria contínua da solução para inserir agilidade em
processos de teste de projetos de software. A estimativa do grau de agilidade associado
ao processo de testes sendo considerado no projeto de software, tem como base as
matrizes de relacionamentos agora apresentadas, além de outros critérios derivados de
estudos feitos sobre o assunto, em especial as pesquisas de opinião realizadas e descritas
no capítulo 5.
A idéia é oferecer uma alternativa para calcular a agilidade estimada do processo de
teste de software, que reflita o nível de agilidade em potencial que poderia ser alcançado
pelo processo, obtido a partir da base de conhecimento que faz parte da solução
elaborada nesta pesquisa. Haverá também um cálculo para a agilidade real do processo
de testes, que reflete o nível de agilidade efetivamente alcançado, obtido a partir de
avaliações qualitativas feitas pela equipe de testes em um dado ponto ou ao final do
projeto. As avaliações dos resultados alcançados, feitas pela equipe de testes, servirão
também para fins de atualização da base de conhecimento, conforme já descrito
anteriormente.
No capítulo 7 é apresentada uma descrição detalhada de um guia elaborado para
apoiar as equipes de teste na tarefa de inserir agilidade em processos de teste de
software. Para facilitar o entendimento, a descrição será ilustrada com um exemplo de
aplicação do guia.
167
7. Inserção de Agilidade em Processos de Teste
de Software
Neste capítulo é apresentada uma estratégia proposta para a
inserção de características de agilidade em processos de teste de
software, materializada através de um guia elaborado para apoiar
as equipes de testes no planejamento de agilidade para os processos
de teste de software em seus projetos. Uma instrumentação foi
preparada para aplicação do guia nas organizações. Um exemplo de
uso é apresentado detalhadamente.
7.1 Introdução
Neste capítulo é apresentada uma proposta de estratégia definida para apoiar a
inserção de características de agilidade em processos de teste de software, a partir das
características e práticas ágeis identificadas através de revisões sistemáticas de
literatura, avaliadas através do estudo primário apresentado no capítulo 5. Esta
estratégia está fundamentada no tripé que apóia as abordagens ágeis: valores, princípios
e práticas. A estratégia elaborada pode ser útil em organizações que valorizam e
desejam a agilidade em seus processos de teste de software, e serve para guiar a equipe
de testes no planejamento de melhoria do processo de teste de software em termos de
agilidade. Este direcionamento estratégico na seleção de características e práticas é
importante tendo em vista os seguintes fatores:
O volume de conhecimento é considerável e está esparso na literatura
sobre abordagens ágeis;
A proliferação de metodologias ágeis que se apresentam como
alternativas para processos de desenvolvimento de software sem
contemplar o processo de teste de software com recomendações ou
diretrizes concretas e mais específicas;
A necessidade de viabilizar e guiar a escolha de diferentes possibilidades
de características de agilidade para um processo de teste de software,
168
levando-o a algum grau de agilidade, tendo em vista ser este atributo um
espectro;
A necessidade de amenizar a dificuldade de seleção e planejamento das
características de agilidade a serem inseridas em um processo de teste de
software, tendo em vista a escassez de conhecimento científico
comprovado por evidências a respeito de testes ágeis ou agilidade em
testes;
A necessidade de organizar uma base de conhecimento que inclua não
apenas as características e as práticas ágeis, mas também as combinações
possíveis de mapeamentos entre elas, para viabilizar a inserção de
características no processo de teste de software a partir da adoção de
práticas mapeadas;
A possibilidade de avaliar e manter os resultados alcançados visando
recolher e aplicar lições aprendidas com sucessos e insucessos de
projetos passados, para melhorar processos de teste de software em
projetos futuros.
Em adição, considera-se a estratégia de solução apresentada importante porque a
agilidade pode ser desejável por parte das organizações de software que buscam por
melhorias em seus processos de teste de software. Acredita-se ainda que esta estratégia
possa reduzir a carga de esforço da equipe de testes e possa também aumentar as suas
chances de sucesso na busca de um grau de agilidade adequado para os projetos das
organizações que desenvolvem software.
Foi idealizado um guia para apoiar a seleção das características de agilidade a
serem inseridas em um processo de teste de software, a partir da adoção de práticas
ágeis independentemente de metodologias específicas. Com este guia, pretende-se
também apoiar a avaliação dos resultados alcançados após a execução do projeto, com
as características inseridas em seu processo de teste.
Resultados de avaliações de projetos semelhantes já concluídos podem ser
utilizados como lições aprendidas, para apoiar a inserção de características de agilidade
no processo de teste associado com um novo projeto de software. São apresentadas a
seguir, as fases e os elementos que compõem tal estratégia representada pelo guia
idealizado.
169
A estratégia de solução apresentada tem como pressuposições apenas que haja
um processo de teste estabelecido para o projeto e que a organização deseja inserir
agilidade neste processo (seção 1.5). Ela poderá ser aplicada independentemente do
processo mais amplo de desenvolvimento (no qual está inserido o processo de teste) ser
ágil ou não, estar ou não utilizando um método ágil. Além disso, a estratégia
apresentada deve ser aplicada preferencialmente no início do projeto, para evitar
eventuais comprometimentos do desempenho do processo de teste quanto à agilidade.
7.2 Visão Geral da Estratégia Adotada
Segue-se uma representação esquemática do procedimento associado com o guia
idealizado para apoiar a inserção de características de agilidade em processos de teste de
software. Tal procedimento pode ser dividido em 3 fases que são: fase 1 – carga
inicial/atualização da base de conhecimento sobre características e práticas ágeis; fase 2
– seleção e planejamento das características e práticas ágeis; fase 3 – avaliação dos
resultados alcançados. A fase 1 deve ser executada uma vez para fazer a carga inicial da
base de conhecimento e posteriormente só será executada quando houver necessidade
de atualização da referida base. As idéias empregadas na fase 1 (carga da base de
conhecimento) já foram utilizadas em trabalhos de outros pesquisadores do grupo de
Engenharia de Software Experimental (DIAS NETO e TRAVASSOS, 2008; SPÍNOLA
e TRAVASSOS, 2008) e aqui foram adaptadas para o contexto desta pesquisa. Estando
carregada ou atualizada, a base de conhecimento poderá ser utilizada para diversos
projetos de software. As fases 2 e 3 devem ser executadas pelo menos uma vez para
cada projeto. A Figura 7-1 dá uma idéia do conjunto de atividades associado com a fase
1, carga/atualização da base de conhecimento sobre características e práticas ágeis.
170
Figura 7-1 - Carga/atualização da base de conhecimento sobre características e práticas ágeis
De modo semelhante ao apresentado por DIAS NETO e TRAVASSOS (2008), a
fase 1 envolve carregar o conhecimento inicial obtido com as revisões de literatura
realizadas para identificar características de agilidade (capítulo 3) e práticas ágeis
(capítulo 4), e com a pesquisa de opinião (capítulo 5), todas apresentadas com detalhes
por ABRANTES e TRAVASSOS (2007, 2007a, 2011, 2011a). Na fase 1 a carga inicial
da base de conhecimento é efetuada a partir das características de agilidade e das
práticas ágeis identificadas na literatura e posteriormente avaliadas através de pesquisa
de opinião. São carregados também pesos iniciais para cada característica e cada prática,
a partir da mesma pesquisa de opinião. São registrados os mapeamentos entre as
características de agilidade e as práticas ágeis, obtidos a partir da análise da
possibilidade das práticas apoiarem (ou não) as características de agilidade. Do mesmo
modo, são registrados os mapeamentos entre as atividades de um processo padrão de
teste e as práticas ágeis, a partir da análise da possibilidade das práticas apoiarem (ou
não) as atividades do processo padrão de teste na obtenção de seus respectivos artefatos,
conforme descrito detalhadamente no capítulo 6. Sempre que houver necessidade, seja
por atualizações das revisões de literatura ou realização de novas pesquisas de opinião,
seja por adequações feitas nos mapeamentos ou por lições aprendidas de projetos
anteriores, a critério da equipe de testes na organização que está utilizando o guia, a
base de conhecimento poderá ser atualizada. A fase seguinte (fase 2) envolve a seleção
171
e o planejamento das características de agilidade e das práticas ágeis a serem adotadas
no processo de testes. A Figura 7-2 dá uma idéia do conjunto de atividades associado
com a fase 2.
Figura 7-2 - Seleção e planejamento das características e práticas ágeis
A primeira atividade da fase 2 é a caracterização do projeto, visando explicitar o
nível de adequação do projeto de software às abordagens ágeis. A partir desta
informação a equipe de testes pode decidir se deseja prosseguir com a fase 2 ou se
deseja interromper a sequência de atividades a ela associada. Caso a decisão seja pelo
prosseguimento, a base de conhecimento é consultada e características de agilidade são
apresentadas à equipe de testes de software que poderá então selecionar as
características de agilidade desejadas para o processo de teste. A partir das
características selecionadas, a base de conhecimento é novamente consultada para se
obter as práticas ágeis associadas a tais características. Para as práticas obtidas, são
verificadas eventuais restrições em função do mapeamento estabelecido, de tais práticas,
para as atividades do processo padrão de teste de software. O conjunto de práticas assim
obtido é apresentado para a equipe de teste, com níveis de relevância estimados para
cada prática em relação aos diferentes graus de agilidade também estimados, que
potencialmente, poderiam ser atingidos pelo processo de teste de software com aquelas
práticas. Para estas estimativas, serão feitas consultas à base de conhecimento sobre os
pesos das práticas e das características de agilidade. Os resultados de projetos
172
semelhantes já concluídos podem ser usados para apoiar a tomada de decisão. A equipe
de testes escolhe então as práticas que deseja adotar no planejamento de agilidade para o
processo de teste de software. O resultado da escolha das práticas ficará armazenado.
A fase 3 envolve a avaliação dos resultados alcançados pelo processo de teste de
software com a adoção das práticas selecionadas na fase 2. A Figura 7-3 dá uma idéia
do conjunto de atividades associado com a fase 3.
Figura 7-3 - Avaliação dos resultados alcançados
Os itens planejados na fase 2 para embutir agilidade no processo de teste de
software ficaram armazenados. Na fase 3, eles serão reapresentados ao final do projeto,
para que haja uma avaliação do processo de teste de software planejado, quanto aos
resultados alcançados em termos de agilidade. A avaliação deve ser feita pela equipe de
testes do projeto de software. O guia direcionará a equipe de testes quanto à forma de
avaliação e quanto aos itens a serem avaliados.
Com a adoção da estratégia apresentada, o comportamento organizacional
poderá ser afetado no sentido de que, doravante, a organização deverá se preocupar
formalmente com a atualização da base de conhecimento, para uso no planejamento de
agilidade para os processos de teste de software de seus projetos. Poderá haver a
introdução ou a consolidação de uma cultura de melhoria contínua na organização, para
um processo de software específico, no caso o processo de teste de software. Se a
estratégia for bem sucedida, poderá haver mais conforto por parte da organização em
lidar com mudanças, reduzindo os receios de queda de qualidade dos produtos de
software quando estas mudanças tiverem que ser abraçadas ou atendidas, para buscar a
173
satisfação do cliente. Se a estratégia for mal sucedida, poderá haver descrédito para com
as abordagens ágeis e seu emprego no processo de teste de software.
7.3 Detalhamento da Estratégia Proposta para Apoiar a
Inserção de Características de Agilidade em Processos de
Teste de Software
7.3.1 Fase 1- Carga/atualização da base de conhecimento sobre
características e práticas ágeis
As características de agilidade e as práticas ágeis com respectivas denominações,
descrições e níveis de relevância, bem como as atividades do processo padrão de teste
de software, em uma versão inicial do guia serão aquelas identificadas pelas respectivas
revisões sistemáticas de literatura (ABRANTES e TRAVASSOS, 2007, 2007a, 2011,
2011a), também apresentadas nos capítulos 2, 3, 4 e 5, podendo ser evoluídas e
atualizadas sempre que novos conhecimentos forem disponibilizados. Devem ser
mantidos atualizados na base de conhecimento, os mapeamentos entre práticas e
características, e entre práticas e atividades do processo de teste de software,
apresentados no capítulo 6. A atualização da base poderá ser feita a critério da
organização e deverá seguir o procedimento descrito na seção 7.2 sobre a carga da base
de conhecimento. O conhecimento anterior será preservado, mantendo-se na base
resultados de projetos concluídos. As atualizações poderão acontecer no momento em
que a equipe de testes perceber essa necessidade e/ou novo conhecimento estiver
disponível.
Os projetos encerrados, após avaliação de resultados alcançados, permanecerão
na base para fins de apoio à tomada de decisão pela equipe de testes quanto ao
planejamento de inserção de características de agilidade em processos de teste de
software para projetos de software futuros, que guardem semelhança com algum projeto
já encerrado.
A Tabela 6-1 apresentada no capítulo 6, seção 6.3, mostra as atividades
inicialmente escolhidas para a carga da base de conhecimento, adaptadas de DIAS
NETO e TRAVASSOS (2006) E HASS (2008). As atividades indicadas nesta tabela
podem, cada uma, envolver um conjunto de subatividades com elas relacionadas, cujo
detalhamento não será tratado neste trabalho.
174
7.3.2 Fase 2 - Seleção e planejamento das características e práticas ágeis
A fase de seleção e planejamento das características e práticas ágeis, conforme
apresentado na seção 7.2 envolve os seguintes passos: Caracterização do Projeto;
Decisão sobre Prosseguimento; Seleção das Características; Obtenção de Práticas
Mapeadas; Restrições pelas Atividades de Teste; Sugestões de Práticas a serem
Adotadas; Escolha das Práticas; Registro das Práticas Escolhidas. Segue-se o
detalhamento de cada passo.
Passo 1 - Caracterização do Projeto
Neste passo, é feita a caracterização do projeto de software no qual se insere o
processo de teste de software candidato às características de agilidade, com duas
finalidades: avaliar a adequação do projeto de software às abordagens ágeis de
desenvolvimento de software e permitir a seleção de projetos semelhantes, na base de
conhecimento, já encerrados e avaliados com algum grau de sucesso, quanto à
agilidade, para servir de apoio à tomada de decisão pela equipe de testes na seleção das
práticas ágeis sugeridas pela estratégia proposta.
A solução adotada para caracterizar um projeto de software neste trabalho
envolve algumas idéias que foram adaptadas de trabalhos já publicados abordando a
caracterização de projetos de software (BERGER, 2003; BOEHM e TURNER, 2004a;
QUMER e HENDERSON-SELLERS; 2007 MNKANDLA, 2008). Trata-se de um
conjunto de atributos e opções de valores associados, utilizados para caracterizar
projetos de software no contexto da estratégia aqui proposta, podendo evoluir ao longo
do uso do guia elaborado para inserção de características de agilidade em processos de
teste de software.
Na Tabela 7-1 abaixo, são apresentados os parâmetros escolhidos para
caracterizar projetos de software, com indicação de possíveis valores para cada
parâmetro. A quantidade de parâmetros poderá vir a ser reduzida, se for o caso, com o
objetivo de evitar que a usabilidade do guia seja comprometida. Todos os parâmetros
serão utilizados para identificar projetos semelhantes já concluídos e avaliados
registrados na base de conhecimento. Apenas alguns parâmetros serão utilizados para
apurar o grau de adequação do projeto com as abordagens ágeis, conforme descrito a
seguir. Os valores dos parâmetros para o projeto deverão ser preenchidos durante a fase
175
de planejamento do projeto. Os exemplos de valores alternativos apresentados na Tabela
7-1 foram capturados de obras clássicas sobre engenharia de software (PRESSMAN,
2006; SOMMERVILLE, 2007) bem como adaptados dos trabalhos de BERGER (2003),
BOEHM e TURNER (2004a), QUMER e HENDERSON-SELLERS (2007) E
MNKANDLA (2008).
Tabela 7-1 - Caracterização de Projetos
Parâmetro Exemplos de Valores Alternativos
Modelo de Ciclo de Vida Iterativo e incremental, RAD, Espiral, .....
Duração Estimada do Projeto Número de meses
Indicador de Complexidade do Problema Muito Alta, Alta, Média, Baixa, Muito Baixa
Indicador de Instabilidade dos Requisitos Muito Alta, Alta, Média, Baixa, Muito Baixa
Tamanho da Equipe do Projeto Quantidade de pessoas
Criticalidade do Projeto Muito Alta, Alta, Média, Baixa, Muito Baixa
Ambiente Físico Localizado, Distribuído
Plataforma de Execução Sistema embarcado, Web, Desktop, ...
Domínio da Aplicação Contábil, Bancário, Estoques, Vendas, ...
Nesta tabela, todas as características de projeto indicadas serão utilizadas para
apurar semelhança entre projetos de software. Contudo, apenas 5 delas (Duração
Estimada do Projeto, Indicador de Complexidade do Problema, Indicador de
Instabilidade dos Requisitos, Tamanho da Equipe do Projeto e Criticalidade do Projeto)
serão utilizadas para apurar a adequação do projeto de software às abordagens ágeis. A
seguir, é apresentada uma explanação sucinta de cada atributo de caracterização de
projeto utilizado neste trabalho.
Modelo de Ciclo de Vida: Projetos podem guardar algum grau semelhança entre si
quando empregam o mesmo modelo. Os possíveis valores serão tabelados. A Tabela 7-1
apresenta exemplos de valores alternativos.
Duração Estimada do Projeto: O valor a ser informado é a quantidade de meses
estimada para a duração do projeto. Quanto menor o prazo, mais significativa a
abordagem ágil para o projeto. MNKANDLA (2008) considera em seu trabalho de
pesquisa sobre métodos ágeis (seleção de práticas ágeis para um projeto de software) a
duração estimada de até 2 meses para um projeto de software como a primeira faixa de
176
classificação mais adequada para aplicação de uma abordagem ágil ao projeto, e
duração estimada para projetos acima de 2 anos como última faixa de classificação,
menos adequada para aplicação de abordagens ágeis, estando os prazos intermediários
(3 meses até 2 anos) distribuídos em mais 4 faixas de classificação. LITTLE (2005)
utiliza como um direcionador de incerteza para determinar práticas ágeis a serem
incorporadas a um processo de desenvolvimento de software, a duração estimada do
projeto, classificando-a em 5 faixas, a primeira de 1 a 4 semanas, a última de 13 a 24
meses. A partir dos prazos de projetos mencionados na literatura que descreve
individualmente as metodologias ágeis (STAPLETON, 1997; BECK, 1999; BECK
1999a; HIGHSMITH, 2000; PALMER e FELSING, 2002; COCKBURN, 2002;
SCHWABER e BEEDLE, 2002; POPPENDIECK e POPPENDIECK, 2003, BECK e
ANDRES, 2004; POPPENDIECK e POPPENDIECK, 2006; DSDM CONSORTIUM,
2008), foi adotada neste trabalho a seguinte classificação: 4- até 2 meses; 3- de 3 a 6
meses; 2- de 7 meses a 1 ano; 1- de 13 meses a 2 anos; 0- mais que 2 anos. Quanto
maior o valor da classificação adotada (menor duração estimada), mais adequada é a
abordagem ágil para ser aplicada no projeto.
Indicador de Complexidade do Problema: As possibilidades de classificação serão
mapeadas para os valores: 4- Muito Baixa, para projetos que não envolvem cálculos
complexos nem regras de negócio complicadas; 3- Baixa, para projetos que envolvem
cálculos pouco complexos ou regras de negócio um pouco complicadas; 2- Média, para
projetos que envolvem cálculos complexos ou regras de negócio complicadas; 1- Alta,
para projetos que envolvem cálculos significativamente complexos ou regras de negócio
significativamente complicadas; 0- Muito Alta, para projetos que envolvem cálculos
muito complexos ou regras de negócio muito complicadas. Quanto menos complexo o
processamento envolvido (valores mais altos), mais adequada é a abordagem ágil para
ser aplicada no projeto.
Indicador de Instabilidade dos Requisitos: As possibilidades de classificação serão
mapeadas para os valores: 4- Muito Alta, para requisitos muito instáveis, com risco
muito alto de afetar o escopo do projeto; 3- Alta, requisitos instáveis com razoável risco
de afetar o escopo do projeto; 2- Média, para requisitos com grau médio de estabilidade,
com algum grau de risco de afetar o escopo do projeto; 1- Baixa, requisitos
praticamente estáveis com baixo risco de afetar o escopo do projeto; 0- Muito Baixa,
requisitos estáveis, praticamente sem risco de afetar o escopo do projeto. Quanto menos
177
estáveis os requisitos (valores mais altos), mais adequada é a abordagem ágil para ser
aplicada no projeto.
Tamanho da Equipe do Projeto: O valor a ser informado é a quantidade de pessoas
participando do projeto. Quanto menor a quantidade de pessoas, mais indicada é a
abordagem ágil para o projeto. A partir dos tamanhos de equipe mencionados na
literatura técnica que descreve individualmente as metodologias ágeis, será a princípio
adotada a seguinte classificação: 4- até 6 pessoas; 3- de 7 a 10 pessoas; 2- de 11 a 39
pessoas; 1- de 40 a 80 pessoas; 0- mais de 80 pessoas. Quanto maior o valor da
classificação adotada, mais adequada é a abordagem ágil para ser aplicada ao projeto.
Criticalidade do Projeto: As possibilidades de classificação serão mapeadas para os
valores que se seguem, adaptadas dos níveis de criticalidade de um projeto apresentados
por COCKBURN (2002a): 0- Muito Baixa, falhas do software podem causar
desconfortos como atrasos na entrega de algum produto ou serviço ou longos tempos de
espera; (-1)- Baixa, falhas do software podem resultar em perdas de recursos que podem
ser recuperados sem maiores problemas; (-4)- Média, falhas do software podem resultar
em perdas de recursos que podem ser recuperados, mas com dificuldade razoável; (-5)-
Alta, falhas do software podem resultar em perdas de recursos que não podem mais ser
recuperados; (-8)- Muito Alta, falhas do software podem resultar em grave ameaça a
lesões corporais ou a perda de vida(s). Quanto menos graves os riscos (valores mais
altos), mais adequada é a abordagem ágil para ser aplicada no projeto. Os valores
inicialmente atribuídos a este indicador pesam no sentido de contra-indicar a abordagem
ágil para o projeto e devem ser ajustados à medida em que a experiência com o guia for
avançando.
Ambiente Físico: Os possíveis valores serão tabelados. Diferentes graus de distribuição
das equipes (casos de desenvolvimento distribuído de software) não serão a princípio
considerados. A Tabela 7-1 apresenta exemplos de valores alternativos.
Plataforma de Execução: Este indicador deverá ser informado conforme o ambiente
em que o software será executado. Os possíveis valores serão tabelados. A Tabela 7-1
apresenta exemplos de valores alternativos.
Domínio da Aplicação: Este indicador deverá ser informado conforme a natureza da
aplicação associada ao software. Os possíveis valores serão tabelados. A Tabela 7-1
apresenta exemplos de valores alternativos.
178
Alguns dos indicadores apresentados (4) serão utilizados apenas para apurar a
semelhança do projeto que tem a agilidade sendo planejada pelo guia proposto, com
projetos já concluídos e avaliados, disponíveis na base de conhecimento. São eles:
Modelo de Ciclo de Vida, Ambiente Físico, Plataforma de Execução e Domínio da
Aplicação. Alguns outros indicadores (5) serão utilizados, além disso, também para
apurar o grau de adequação do projeto às abordagens ágeis: Duração Estimada do
Projeto, Indicador de Complexidade do Problema, Indicador de Instabilidade dos
Requisitos, Tamanho da Equipe e Criticalidade do Projeto.
Na escolha dos parâmetros a serem utilizados para caracterizar projetos de
software neste trabalho, uma diretriz observada foi tentar reduzir ao máximo a
quantidade de parâmetros, para evitar a sobrecarga da estratégia proposta e também
evitar comprometer o planejamento de agilidade para o processo de teste de software
com algo muito pesado ou que demandasse muito esforço por parte da equipe de testes.
O trabalho apresentado por BERGER (2003) inclui 22 critérios de caracterização de
projetos que apóiam a definição do modelo de ciclo de vida mais adequado para um
projeto. De uma certa forma, o parâmetro modelo de ciclo de vida já guarda uma
associação com os valores destes 22 critérios, possibilitando a redução na sua
quantidade. Contudo, alguns deles, por serem mais específicos no contexto das
abordagens ágeis, foram também incluídos. Além disso, foram adaptados outros
critérios sugeridos e utilizados em trabalhos relacionados com o contexto das
abordagens ágeis como os de BOEHM e TURNER (2004A), LITTLE (2005), QUMER
e HENDERSON-SELLERS (2007), MNKANDLA (2008). Na escolha e adaptação
destes critérios, foram consideradas também as recomendações feitas pelos proponentes
de metodologias ágeis destacadas na literatura técnica (STAPLETON, 1997; BECK,
1999; BECK 1999A; HIGHSMITH, 2000; COCKBURN, 2002; PALMER e FELSING,
2002; SCHWABER e BEEDLE, 2002; POPPENDIECK e POPPENDIECK,
2003,BECK e ANDRES, 2004; POPPENDIECK e POPPENDIECK, 2006, DSDM
CONSORTIUM, 2008.), com respeito a adequação das mesmas às características dos
projetos de software.
Passo 2 - Decisão sobre Prosseguimento
Após a caracterização do projeto, alguns dos parâmetros indicados no passo
anterior serão utilizados para derivar o grau de adequação das abordagens ágeis para o
179
projeto considerado. Os parâmetros são Duração Estimada do Projeto, Indicador de
Complexidade do Problema, Indicador de Instabilidade dos Requisitos, Tamanho da
Equipe do Projeto e Criticalidade do Projeto. Os valores apurados para tais parâmetros
serão acumulados e o grau de adequação de uma abordagem de agilidade para o projeto
será expresso em termos de percentual em relação ao maior valor que poderia ser obtido
se para todos os parâmetros fosse apurado o valor máximo. Será inicialmente adotado
aqui o patamar mínimo de 50% de adequação para recomendar o prosseguimento do
plano de agilidade para o processo de teste do projeto, ficando a decisão a cargo da
equipe de testes. Um exemplo é apresentado na seção 7.4. Com base neste grau de
adequação, a equipe de testes deve decidir se deseja continuar ou não com a estratégia
de inserção de agilidade no processo de teste de software do projeto. Caso a decisão seja
continuar, antes de passar ao passo seguinte, todos os valores apurados para os
parâmetros de caracterização do projeto serão armazenados para utilização futura.
Passo 3 – Seleção das Características
As características de agilidade são apresentadas à equipe de testes para que ela
possa selecionar aquelas que deseja considerar no plano para inserir características de
agilidade no processo de teste de software do projeto.
Passo 4 – Obtenção de Práticas Mapeadas
A partir do mapeamento entre características de agilidade e práticas ágeis são
obtidas as práticas inicialmente candidatas a serem adotadas no processo de teste de
software do projeto. Todas as práticas mapeadas para pelo menos uma das
características de agilidade selecionadas, são incluídas.
Passo 5 – Restrições pelas Atividades de Teste
As atividades do processo padrão de teste de software adotado neste trabalho são
apresentadas à equipe de testes para que ela selecione aquelas que farão parte da
instância do processo de teste de software específico planejado para o projeto de
software em questão. Nesta oportunidade, a equipe de testes poderá também incluir
atividades de teste diferentes daquelas disponíveis na base de conhecimento. As práticas
ágeis obtidas no passo 4, como inicialmente candidatas a serem adotadas no processo de
180
teste de software, são verificadas quanto às restrições impostas pelas atividades do
processo padrão de teste de software, através do mapeamento entre práticas ágeis e
atividades do processo padrão. Permanecerão candidatas a serem adotadas apenas
aquelas práticas que não apresentarem incompatibilidades com as atividades do
processo de teste de software. É considerada incompatível com as atividades a prática
ágil que não apóia ou que não contribui para pelo menos uma atividade do processo.
Esta informação é obtida na base de conhecimento através do mapeamento estabelecido
entre as práticas ágeis e as atividades do processo de teste de software. Chega-se assim,
a um conjunto de práticas ágeis realmente candidatas a serem adotadas.
Passo 6 – Sugestões de Práticas a serem Adotadas
Neste passo, o grau de agilidade em potencial, estimado para cada prática
candidata, com relação às características de agilidade selecionadas no passo 3, é
calculado com base na matriz de mapeamento das práticas para as características de
agilidade. Para cada prática, este grau de agilidade em potencial é a soma dos pesos das
características com ela associadas e escolhidas, multiplicada pelo peso da própria
prática e este produto dividido pela quantidade de características. Um grau de agilidade
em potencial, estimado para o processo de teste de software também é calculado (soma
dos produtos dos pesos de cada característica selecionada pelo peso de cada prática para
elas mapeadas, dividida pela soma dos produtos dos pesos de cada característica
mapeada pelo peso de todas as 15 práticas da base de conhecimento). As práticas são
apresentadas para escolha, em ordem de prioridade estabelecida pela equipe de testes a
partir das características selecionadas no passo 3, em ordem de grau de agilidade em
potencial estimado e em ordem de nível de relevância registrado na base de
conhecimento para cada prática ágil.
Passo 7 – Escolha das Práticas
Neste passo, a equipe de testes poderá escolher dentre as indicadas, as práticas
que deseja adotar no processo de teste de software. Como apoio à tomada de decisão,
seriam apresentadas à equipe de testes do projeto, uma lista ordenada das práticas mais
freqüentemente bem avaliadas em projetos semelhantes concluídos e cujos processos de
teste de software foram considerados como bem sucedidos em termos de agilidade.
181
A equipe de testes poderá também inserir práticas diferentes daquelas
originalmente sugeridas com a estratégia proposta. Práticas ágeis não definidas a partir
das características de agilidade escolhidas no passo 3, mas derivadas de projetos
semelhantes e concluídos com resultados satisfatórios quanto à agilidade de seu
processo de teste de software, são apresentadas como opção para a equipe de testes.
Para selecionar os projetos semelhantes é utilizado um indicador denominado de
coeficiente de similaridade entre projetos de software, calculado como um percentual
das características de projeto com valores coincidentes nos dois projetos, em relação ao
total de características usadas para representar os projetos. Será inicialmente adotado
aqui o patamar mínimo de 50% de coeficiente de similaridade entre projetos para
considerar um projeto similar ao outro. Será considerado concluído com resultados
satisfatórios o projeto que apresentar nível de avaliação de sucesso acima de 50% para
seu conjunto de práticas ágeis. O grau definitivo de agilidade em potencial estimada
para o processo de teste de software do projeto é recalculado após a escolha das práticas
pela equipe de testes.
Passo 8 – Registro das Práticas Escolhidas
As práticas ágeis definitivamente escolhidas são armazenadas para utilização
posterior. Após o planejamento da inserção de características de agilidade no processo
de teste de software, encerra-se a fase 2 do procedimento associado com o guia para
inserção de agilidade em processos de teste de software. Todo o planejamento fica
armazenado para eventuais consultas e aguarda a execução do projeto como um todo
para que sejam feitas na fase 3, as avaliações dos resultados alcançados pelo processo
de teste de software com a adoção das práticas planejadas para obtenção de agilidade.
7.3.3 Fase 3 - Avaliação dos resultados alcançados
Após a execução de todo o projeto, deve ser feita uma avaliação dos resultados
alcançados pelo processo de teste de software que teve a agilidade planejada. Esta
avaliação visa o aperfeiçoamento da seleção de características de agilidade e de práticas
ágeis, o aperfeiçoamento do planejamento de agilidade para o processo de teste de
software, bem como disponibilizar experiências e lições aprendidas para aproveitamento
em projetos futuros.
182
O planejamento efetuado é submetido à avaliação pela equipe de testes. Para as
questões a serem avaliadas, foi idealizada uma escala que demandasse o mínimo esforço
e reduzisse ao máximo a dificuldade do avaliador em fazer o enquadramento do
resultado alcançado nas possíveis categorias (alto, médio e baixo). A equipe de testes do
projeto indicará respostas para as seguintes questões:
1. Em que grau as práticas planejadas foram efetivamente adotadas e seguidas
durante a execução das atividades de teste? Para cada prática, a seguinte
classificação será considerada: 2- Alto, efetivamente adotada e seguida; 1-
Médio, adotada e seguida parcialmente; 0- Baixo, praticamente não foi seguida
ou não foi adotada.
2. A partir dos resultados observados, qual o grau de adequação em que cada
prática contribuiu para as características de agilidade e para o sucesso das
respectivas atividades do processo de teste de software, quanto à agilidade? Para
cada prática adotada será informado o grau de adequação, com a seguinte
classificação: 2- Alto, a prática contribuiu em alto grau para o sucesso da
atividade; 1- Médio, a prática contribuiu modestamente para o sucesso da
atividade; 0-Baixo, a prática não contribuiu para o sucesso da atividade.
Também serão solicitadas as evidências observadas durante a execução do
processo de teste de software que justificam as respostas para cada prática
avaliada.
3. Qual a adequação das prioridades planejadas para as práticas ágeis no processo
de teste de software? Os graus de agilidade estimados para cada prática
selecionada receberiam a seguinte classificação: 2- Alta adequação, a ordem da
maioria das práticas sugeridas parecem coerentes com os resultados que elas
alcançaram; 1- Média adequação, a ordem de algumas práticas sugeridas está
discrepante em relação ao resultado que elas alcançaram; 0- Baixa adequação, a
ordem das práticas sugeridas está significativamente diferente em relação ao
resultado que elas alcançaram.
4. Qual o grau atribuído ao resultado final da aplicação do conjunto de práticas
planejadas, no processo de teste de software, com relação à agilidade do mesmo?
2- Bom, o processo de teste de software teve condições de se adaptar sem
maiores problemas quando mudanças não previstas se apresentaram; 1-
183
Razoável, o processo de teste de software conseguiu se adaptar com alguma
dificuldade, mas atendeu a mudanças não previstas que se apresentaram durante
a execução do projeto; 0- Ruim, o processo de teste de software teve grandes
dificuldades para se adaptar ou não conseguiu se adaptar a mudanças não
previstas que se apresentaram durante a execução do projeto. Também serão
solicitadas as evidências observadas durante a execução do processo de teste de
software que justificam a resposta.
As respostas a estas questões são tratadas e ficam armazenadas. Estas
informações poderão ser utilizadas no futuro como apoio à tomada de decisão no
planejamento de inserção de características de agilidade em processos de teste de
software para projetos semelhantes.
O resultado da avaliação da aplicação da estratégia de solução é utilizado de
duas formas. Uma das formas, a nível de projeto, para apoiar decisões na seleção e
planejamento de agilidade para processos de teste de projetos futuros. Outra forma, a
nível de organização, para atualizar a base de conhecimento, possibilitando identificar
necessidades de atualização de mapeamentos, atividades de processo de teste, práticas
ágeis e características de agilidade. Além disso, tais resultados podem apoiar a
adequação/atualização de limites ou pontos de corte utilizados pela estratégia,
inicialmente estabelecidos em 50%, como os limites de nível de pertinência das práticas
e características de agilidade utilizadas na apuração de resultados da pesquisa de
opinião, adequação do projeto com as abordagens ágeis, similaridade entre projetos de
software e nível estimado de sucesso dos projetos (seção 7.3.2).
A atualização do mapeamento pode ser feita a partir da freqüência de práticas
selecionadas para o processo de teste de software e que não contribuem para o seu
sucesso, apesar de mapeadas para determinadas características e atividades selecionadas
para o processo de teste de software. A atualização do mapeamento pode também ser
feita a partir da freqüência de práticas que contribuem para o sucesso do processo de
teste de software, apesar de não mapeadas para pelo menos uma atividade de teste (caso
das incluídas pela equipe testes). A mesma atualização poderá ainda ser feita a partir da
freqüência de práticas não selecionadas, apesar de mapeadas para atividades e
características de agilidade escolhidas pela equipe de testes.
184
A atualização de atividades do processo de teste de software poderá ser feita a
partir da freqüência de atividades em projetos de sucesso, definidas e adotadas pela
equipe de testes nos projetos, apesar de não inseridas no processo padrão adotado e
portanto não sugeridas pela estratégia de solução proposta. Esta atualização poderá ser
feita também a partir da freqüência de atividades do processo padrão adotado que não
são selecionadas pela equipe de testes, para o processo de teste de software dos projetos.
A atualização de práticas ágeis poderá ser feita a partir da freqüência de práticas
não selecionadas pela equipe de testes, apesar de mapeadas para atividades e
características de agilidade escolhidas. Também poderá haver atualização a partir da
freqüência de práticas selecionadas, mas que não apresentem nível de sucesso
satisfatório para os projetos em que são adotadas e seguidas (observando que o
problema pode não ser com o mapeamento, mas sim com a prática de software,
possivelmente com a maneira de implementá-la em função do ambiente e do contexto
do projeto de software).
A atualização de características de agilidade poderá ser feita a partir da
freqüência de características de agilidade selecionadas e inseridas em processos de teste
de software que não foram bem sucedidos e/ou a partir da freqüência de características
de agilidade não escolhidas para os processos de teste de software dos projetos.
Estas atualizações poderão ainda ser deflagradas por conseqüência de novos
conhecimentos obtidos através de revisões de literatura e/ou pesquisas de opinião e/ou
outro estudo experimental envolvendo elementos chave da estratégia de solução:
características de agilidade, práticas ágeis, atividades do processo padrão de teste de
software e mapeamentos entre tais elementos.
A atualização da base de conhecimento a partir das avaliações citadas dependerá
da formação de um histórico de projetos concluídos e avaliados que permita derivar
conclusões com algum grau de confiança.
Os resultados das avaliações de cada projeto para os quesitos 1 e 2 anteriormente
descritos nesta seção poderão ser utilizados para calcular um grau de agilidade efetivo
mais próximo do real, em contraposição ao grau de agilidade potencial estimado. O
valor de incidência de cada prática para apoiar cada característica, que está
uniformizado em 1 na matriz de mapeamento, poderá ser alterado, conforme as
avaliações para o grau de adequação em que cada prática contribuiu para as
185
características de agilidade do processo de teste de software; seria adotado 100% do
valor para o caso de práticas avaliadas com “Grau Alto”, 50% do valor para o caso de
práticas avaliadas com “Grau Médio” e anulação completa do valor para o caso de
práticas avaliadas com “Grau Baixo” de contribuição para as características de
agilidade. Na estratégia proposta inicialmente, o grau de agilidade é computado
utilizando-se como pesos os níveis de pertinência das práticas e características, que
foram derivados de ambientes mais acadêmicos do que industriais, uma vez que são
originários do estudo primário apresentado no capítulo 5. No futuro, com histórico
significativo de projetos avaliados na organização que adotar o guia, poderá haver
modificação dos valores na base de conhecimento, fazendo com que os resultados
alcançados possam modificar também os graus de agilidade em potencial estimados
para os projetos, apoiando assim o planejamento da inserção de características de
agilidade em processos de teste de software. Além disso, após formação de histórico
que permita avaliar o emprego deste guia na organização, as escalas de avaliações
poderão ser modificadas para incluir novos valores (p. ex. Muito Alto, Alto, Médio,
Baixo e Muito Baixo, que permitiria adotar modificações nos valores dos mapeamentos
da contribuição de cada prática para cada característica de agilidade – 100%, 75%, 50%,
25% e nulo respectivamente). Em outras palavras, o guia de agilidade estaria sendo
adaptado ao ambiente específico da organização que o utiliza.
7.4 Instrumentação para o Guia de Agilidade Proposto
Foi preparado, utilizando software de planilha eletrônica, um conjunto de
formulários que serve de instrumento para aplicação do guia de agilidade proposto. Os
formulários foram distribuídos em grupos de acordo com sua finalidade.
No primeiro grupo (Instruções) há um formulário contendo as instruções iniciais
para o usuário utilizar o instrumento associado ao guia de agilidade, bem como para
fazer o preenchimento de formulários.
No segundo grupo (Sumário) há uma lista resumida de todos os formulários que
compõem o instrumento.
No terceiro grupo (BC00 a BC07) estão agrupados aqueles formulários que
contêm a base de conhecimento que apóia o guia de agilidade. O usuário do guia pode
186
utilizar este conjunto de formulários para consultas, sempre que desejar ou julgar
necessário.
No quarto grupo (GA01 a GA08) estão agrupados os formulários que devem ser
utilizados pelo usuário para fazer o planejamento propriamente dito de agilidade para o
processo de teste de software. Esse grupo de formulários está associado aos 8 passos do
procedimento para planejar agilidade para um processo de teste de software, conforme
apresentado na seção anterior. Há ainda o formulário GA09 que apresenta o grau de
agilidade em potencial estimado para o processo de teste, após o usuário do guia
terminar de fazer suas escolhas ou opções.
No quinto grupo de (AV01, AV01a) estão formulários que o usuário do guia de
agilidade utilizará para avaliar os resultados alcançados, em termos de agilidade, pelo
processo de teste. As avaliações ficam registradas e vão alimentar o histórico de
projetos concluídos da base de conhecimento. Tal histórico poderá apoiar o
planejamento de agilidade para processos de teste de projetos futuros.
Deste conjunto total de formulários, o usuário terá que preencher poucas
informações em 5 formulários do conjunto GA (GA01, GA02, GA03, GA05 e GA07)
para realizar o planejamento de agilidade para o processo de teste. Apenas quando o
projeto for concluído, o usuário do guia deverá preencher 1 formulário (AV01) para
avaliar os resultados alcançados pelo processo de teste, em termos de agilidade.
Os formulários, apresentados detalhadamente no apêndice E, foram utilizados
para produzir o exemplo que está descrito na próxima seção.
7.5 Exemplo de Aplicação da Estratégia Proposta
Nesta seção será apresentado um exemplo de aplicação da estratégia proposta,
de acordo com as fases apresentadas na seção 7.2. e detalhamento apresentado na seção
7.3. O projeto de software que será utilizado para exemplificar o emprego da estratégia
proposta envolve a construção de software para planejamento e execução orçamentária
de uma organização industrial. O projeto tem as características apresentadas na Tabela
7-2 que se segue:
187
Tabela 7-2 - Caracterização do Projeto Exemplo
Parâmetro Valor
Modelo de Ciclo de Vida Iterativo e incremental
Duração Estimada do Projeto 5 meses
Indicador de Complexidade do Problema Média
Indicador de Estabilidade dos Requisitos Média
Tamanho da Equipe do Projeto 7
Criticalidade do Projeto Baixa
Ambiente Físico Localizado
Plataforma de Execução Web
Domínio da Aplicação Contábil / Orçamentário
7.5.1 Fase 1- Carga/atualização da base de conhecimento sobre
características e práticas ágeis
Para efeito deste exemplo vamos supor a base de conhecimento previamente
carregada conforme especificado na seção 7.3.1, com o guia pronto para ser utilizado.
Devem estar previamente armazenadas e atualizadas as seguintes informações:
características de agilidade e práticas ágeis com respectivas
denominações, descrições e níveis de pertinência e de relevância
apurados na pesquisa de opinião apresentada no capítulo 5;
atividades de teste a serem consideradas, com denominações e
respectivas descrições mais produtos de trabalho - aquelas consolidadas
no capítulo 2 e apresentadas nas tabelas Tabela 6-1 e Tabela 6-2;
mapeamento entre as práticas ágeis de software e as características de
agilidade, conforme apresentado no capítulo 6, Tabela 6-9;
o mapeamento entre as práticas ágeis de software e as atividades do
processo padrão de teste de software, conforme apresentado no capítulo
6;
os possíveis valores para os parâmetros de caracterização de projetos de
software, com as respectivas classificações quando for o caso, conforme
apresentado na seção 7.3.2, Tabela 7-1;
188
os possíveis valores para os parâmetros utilizados na avaliação de
projetos concluídos, conforme apresentado na seção 7.3.3 ;
os projetos de software planejados com a estratégia proposta e já
concluídos e avaliados pelos respectivos responsáveis;
Com a base de conhecimento carregada (inclusive com algum histórico de
projetos concluídos e avaliados), prossegue-se com o exemplo, na fase 2 do
procedimento associado com o guia elaborado.
7.5.2 Fase 2 - Seleção e planejamento das características e práticas ágeis
Esta fase inclui oito passos descritos a seguir em continuidade ao exemplo sendo
apresentado.
Passo 1 - Caracterização do Projeto
Neste passo a equipe de testes faz a caracterização do projeto, sendo guiada no
preenchimento dos valores para os atributos definidos na seção 7.3.2. Segue-se a Tabela
7-3, com uma visão dos dados de caracterização do projeto exemplo.
Tabela 7-3 - Caracterização de Projeto de Software
Parâmetro Valores
Id do Projeto 11
Descrição Sucinta do ProjetoAcompanhamento e Controle do Planejamento e da Execução Orçamentária
Status do Projeto Iniciado
Data Início do Projeto
Data Término do Projeto
Representante do Cliente Glen Miller
Representante da Equipe de Desenvolvimento Desenvolvedor 10
Código da Equipe de Desenvolvimento SD-130
Data de Planejamento da Agilidade p/ Proc Teste do Projeto 14/fev/12
Data de Avaliação da Agilidade do Proc Teste do Projeto
Resultado Final da Avaliação do Processo de Teste
1 Modelo de Ciclo de Vida Iterativo e incremental
2 Duração Estimada do Projeto 5 meses
3 Indicador de Complexidade do Problema Média
4 Indicador de Estabilidade dos Requisitos Média
5 Tamanho da Equipe do Projeto 7
6 Criticalidade do Projeto Baixa
7 Ambiente Físico Localizado
8 Plataforma de Execução Web
9 Domínio da Aplicação Contábil / Orçamentário
189
Passo 2 - Decisão sobre Prosseguimento
O grau de adequação do projeto exemplo às abordagens ágeis é calculado
conforme Tabela 7-4 que se segue. De acordo com o estabelecido na seção 7.3.2, apenas
alguns parâmetros de caracterização do projeto são usados para determinar o seu grau
de adequação com as abordagens ágeis.
Tabela 7-4 - Adequação do Projeto às Abordagens Ágeis
Id ParâmetroValor
Informado Valor Máximo Valor Atribuido
2 Duração Estimada do Projeto 5 meses 4 33 Indicador de Complexidade do Problema média 4 24 Indicador de Estabilidade dos Requisitos média 4 25 Tamanho da Equipe do Projeto 7 4 36 Criticalidade do Projeto baixa 0 -1
TOTALIZADORES 16 9
Grau de adequação do projeto com as abordagens ágeis 56,3%
O grau de adequação do projeto com as abordagens ágeis é calculado pela
proporção entre o somatório dos valores atribuídos a cada parâmetro (9), em relação ao
somatório de total máximo que se poderia obter para todos os parâmetros (16). Portanto
o grau de adequação de tal projeto com as abordagens ágeis seria de 56,3%. Neste
ponto, a equipe de testes poderá prosseguir ou interromper o planejamento da agilidade
para o processo de teste de software. Se desejar prosseguir, os dados são armazenados,
passando-se ao passo 3.
Passo 3 – Seleção das Características
A equipe de testes seleciona as características de agilidade que deseja inserir no
processo de teste de software do projeto. Tais características são apresentadas na forma
da Tabela 5-11, apresentada no capítulo 5, em ordem de nível de relevância.
Neste exemplo, supõe-se que as características selecionadas pela equipe de
testes foram as apresentadas na Tabela 7-5.
190
Tabela 7-5 - Características de Agilidade Escolhidas para o Processo de Software
Característica
Ser ColaborativoSer CooperativoSer IncrementalAdaptabilidadeSer IterativoTestes ConstantesIncorporação de Retroalimentação (feedback)LeannessOrientação a Pessoas
Assim, foram selecionadas 9 características de agilidade a partir da base de
conhecimento.
Passo 4 – Obtenção de Práticas Mapeadas
A partir do mapeamento entre características de agilidade e práticas ágeis
apresentado no capítulo 6, incluído na base de conhecimento conforme Tabela 6-3,
apresentada na seção 6.9.5 e adaptada na página seguinte (Tabela 7-6), são obtidas as
práticas inicialmente candidatas a serem adotadas no processo de teste de software do
projeto. Isto é feito selecionando-se todas as práticas (registradas nas linhas da matriz)
que têm o valor 1 na interseção com pelo menos uma coluna de cada uma das
características que foram selecionadas no passo anterior.
191
Tabela 7-6 - Obtenção de Práticas Ágeis Mapeadas para as Características de Agilidade
100,0% 76,3% 74,1% 71,6% 79,7% 61,3% 64,4% 98,4% 98,4% 94,1% 90,9% 94,1% 92,5% 93,8% 93,1%
Características
Adaptabili-dade
Auto-organi-zação
Emer-gência
Equi-pes
peque-nas
Incorpora-ção de
Retroali-mentação (feedback)
Lean-ness
Modu-larida-
de
Orien-tação a
Pes-soas
Refle-xão e Intros-pecção
Ser Colabo-rativo
Ser Coope-rativo
Ser Incre-mental
Ser Iterati-
vo
Testes Cons-tantes
Time Boxing
Seleção Totais
Grau cada
práticaPráticas
Id 4 5 9 16 10 11 13 14 15 1 2 3 6 7 17 (com pesos)
Backlog de produto 9 0 1 1 0 0 1 0 0 1 1 1 1 1 0 0 5 8 45,8%
Cliente presente 5 1 0 1 0 1 1 0 1 1 1 1 1 1 0 0 8 10 40,0%Desenvolvimento orientado a testes 16
0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 4 425,0%
Design simples 12 1 0 1 0 0 1 0 1 0 0 0 0 0 0 0 3 4 22,6%
Equipe completa 17 1 1 0 0 0 1 0 1 1 0 0 0 0 0 1 3 6 14,7%
Integração contínua 3 0 0 0 0 1 1 0 0 0 0 0 1 0 1 0 4 4 33,6%
Jogo de planejamento 8 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 3 3 25,7%
Metáfora 4 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 6,0%
Padrões de código 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 2 2 16,9%Propriedade coletiva do código
2 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 27,8%
Refatoração 11 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 9,6%
Releases curtas 13 1 0 0 0 1 0 0 0 0 0 1 1 0 0 0 4 4 37,3%
Reuniões diárias 14 0 1 1 0 1 0 0 1 1 1 0 0 0 0 0 3 6 23,1%
Ritmo sustentável 15 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 6,4%
Visibilidade de projeto 10 1 1 0 0 1 1 0 1 1 0 0 0 0 0 0 4 6 33,5%
192
Na Tabela 7-6 acima, a característica transparência não aparece na última
coluna, para melhorar legibilidade, já que apresenta todos os valores iguais a zero. Os
percentuais apresentados na primeira linha são os níveis de pertinência das
características, apurados com a pesquisa de opinião apresentada no capítulo 5. Na
coluna “Seleção” está registrada a quantidade de características selecionadas para as
quais as práticas estão mapeadas, e na coluna “Totais”, está registrada a quantidade total
de características para as quais as práticas estão mapeadas. Apenas a prática propriedade
coletiva de código não foi selecionada neste primeiro momento.
Passo 5 – Restrições pelas Atividades de Teste
As práticas ágeis obtidas no passo 4, tem que passar pelas restrições impostas
pelas atividades do processo padrão de teste de software, através do mapeamento entre
práticas ágeis e atividades do processo padrão de teste de software apresentado no
capítulo 6, Tabela 6-4, seção 6.8, adaptada conforme mostrado na Tabela 7-7 que se
segue.
A equipe de testes seleciona as atividades que deseja considerar para o processo
de teste de software do projeto. Serão excluídas do conjunto obtido no passo 4, todas as
práticas que não apresentarem pelo menos um valor diferente de zero nas interseções da
linha correspondente à prática com a coluna de cada atividade selecionada pela equipe
de testes, neste passo 5. Chega-se assim a um conjunto de práticas ágeis realmente
candidatas a serem adotadas no processo de teste de software.
Aqui é também oferecida à equipe de testes uma oportunidade de incluir
atividades de teste diferentes daquelas já incluídas na base de conhecimento. Se for o
caso, a equipe de teste fornecerá para cada atividade nova incluída: nome ou
denominação, descrição e produtos de trabalho ou artefatos de teste produzidos pela
atividade. As atividades incluídas pela equipe de testes ficarão armazenadas no histórico
do processo de teste do projeto, mas não irão afetar de imediato os mapeamentos com as
práticas ágeis. Neste exemplo foram escolhidas todas as atividades de teste.
193
Tabela 7-7 - Restrições pelas Atividades do Processo Padrão de Testes
Atividades
Planejar Testes
Projetar Testes
Especificar Casos de
Teste
Definir Procedimentos de
Teste.Executar Testes
Analisar Resultados
Monitorar e Controlar o Processo de
Teste
Fechar Atividades de
Teste Totais SeleçãoPráticas
Id 1 2 3 4 5 6 7 8
Backlog de produto 9 1 0 0 0 0 0 0 0 1 1Cliente presente 5 1 1 0 0 0 0 0 0 2 2Desenvolvimento orientado a testes 16 0 0 0 0 0 0 0 0 0 0Design simples 12 0 1 1 1 0 0 0 0 3 3Equipe completa 17 0 1 1 0 0 0 0 0 2 2Integração contínua 3 0 0 0 0 0 0 0 0 0 0Jogo de planejamento 8 1 1 0 0 0 0 0 0 2 2Metáfora 4 1 1 0 0 0 0 0 0 2 2Padrões de código 1 0 0 0 0 0 0 0 0 0 0Propriedade coletiva do código 2 0 0 0 0 0 0 0 0 0 0Refatoração 11 0 0 0 0 0 0 0 0 0 0Releases curtas 13 0 0 0 0 1 1 1 0 3 3Reuniões diárias 14 1 1 1 1 1 1 1 0 7 7Ritmo sustentável 15 0 0 0 0 0 0 0 0 0 0Visibilidade de projeto 10 1 1 1 1 1 1 1 0 7 7
194
Na Tabela 7-7, a coluna “Totais” registra a quantidade total de atividades para as
quais as práticas foram mapeadas, e a coluna “Seleção” registra a quantidade de
atividades selecionada para as quais as práticas foram mapeadas.
De modo simplificado, as práticas identificadas no passo 4 são verificadas na
base de conhecimento quanto ao mapeamento para as atividades do processo padrão de
teste de software que foram escolhidas neste passo 5. As práticas mapeadas para pelo
menos uma das atividades, permanecem como candidatas a serem adotadas no processo
de teste de software: Backlog de produto, Cliente presente, Design simples, Equipe
completa, Visibilidade de projeto, Jogo de planejamento, Metáfora, Reuniões diárias e
Liberações freqüentes (Releases curtas).
Passo 6 – Sugestões de Práticas a serem Adotadas
Neste passo o grau de agilidade estimado de cada prática candidata obtida no
final do passo 5 é determinado com relação às características de agilidade selecionadas
no passo 3. Este grau de agilidade é estimado com base na matriz de mapeamento das
práticas para as características de agilidade e na forma definida na seção 7.5.1. Como
resultado são obtidas as práticas em ordem decrescente da que acrescenta maior grau de
agilidade estimado ao processo de teste de software. O grau de agilidade em potencial
estimado foi calculado no passo 4, para cada prática, considerando os pesos obtidos nos
resultados do survey apresentado no capítulo 5, conforme Tabela 7-6 (Grau para cada
prática, com pesos).
As práticas são apresentadas para seleção seqüenciadas por ordem de prioridade
segundo os critérios: escolha do cliente (no passo 3 – prioridade das características),
grau de agilidade em potencial estimado (no passo 4) e níveis de relevância obtidos no
resultado do survey sobre características de agilidade e práticas ágeis. Segue-se a
apresentação das práticas listadas em ordem conforme os critérios citados, para apoiar a
escolha por parte da equipe de testes (Tabela 7-8, Tabela 7-9 e Tabela 7-10). A
sequência das práticas na Tabela 7-8 é definida em função da quantidade de
características de agilidade e de atividades de teste de software para as quais cada
prática está mapeada. Esta sequência é determinada através do instrumento preparado
para aplicação do guia, detalhado no apêndice E.
195
Tabela 7-8 - Sugestões de Práticas a serem Adotadas, Ordem de Prioridade Estabelecida pelaEquipe de Testes
Id Prática10 Visibilidade de projeto
14 Reuniões diárias5 Cliente presente
13 Releases curtas12 Design simples8 Jogo de planejamento
17 Equipe completa9 Backlog de produto 4 Metáfora
Pode ser observado que algumas prioridades definidas pela equipe de testes não
aparecem na tabela. Isto deve-se ao fato de que, apesar de selecionadas ou priorizadas as
características, as respectivas práticas não foram mapeadas, na base de conhecimento,
para pelo menos uma atividade de teste, fazendo com que tais práticas não fossem
selecionadas.
Tabela 7-9 - Sugestões de Práticas a serem Adotadas, Ordem de Grau de Agilidade em Potencial Estimado
Id PráticaGrau de Agilidade em
Potencial Estimado9 Backlog de produto 45,8%
5 Cliente presente 40,0%13 Releases curtas 37,3%10 Visibilidade de projeto 33,5%8 Jogo de planejamento 25,7%
14 Reuniões diárias 23,1%12 Design simples 22,6%17 Equipe completa 14,7%4 Metáfora 6,0%
Tabela 7-10 - Sugestões de Práticas a serem Adotadas, Ordem de Nível de Relevância
Id PráticaNível de
Relevância9 Backlog de produto 82,7%
13 Releases curtas 82,4%10 Visibilidade de projeto 75,8%8 Jogo de planejamento 70,7%12 Design simples 62,9%14 Reuniões diárias 57,7%5 Cliente presente 37,3%17 Equipe completa 34,9%4 Metáfora 34,6%
196
Passo 7 – Escolha das Práticas
Neste passo a equipe de testes escolhe quais as práticas do passo anterior deseja
adotar no processo de teste de software. Práticas ágeis derivadas de projetos
semelhantes concluídos, com resultados satisfatórios (grau de avaliação igual ou
superior ao limite mínimo estabelecido) são apresentadas para fins de apoio à tomada de
decisão. Após a escolha, o grau definitivo de agilidade em potencial estimado para o
processo de teste de software do projeto é calculado (é a soma dos produtos dos pesos
das características selecionadas pelos pesos das práticas selecionadas dividida pelo
produto da quantidade de características selecionadas pela quantidade de práticas
selecionadas).
A determinação da semelhança entre o projeto sendo planejado e um projeto
concluído e bem sucedido armazenado será obtida pelo percentual de atributos de
caracterização coincidentes nos dois projetos. Isto poderá ser refinado ou ajustado com
o progresso do guia proposto, possivelmente com atribuição de pesos diferenciados para
cada característica de projeto. No caso deste exemplo pode-se considerar os projetos
concluídos armazenados, conforme a Tabela 7-11 que se segue:
Tabela 7-11 - Grau de Similaridade entre Projetos, Dados dos Projetos
Id ParâmetroProjeto 11 (corrente) Projeto 1 Projeto 2 Projeto 10
1Modelo de Ciclo de Vida
Iterativo e incremental Cascata Cascata
Iterativo e incremental
2Duração Estimada do Projeto 5 meses 9 meses 7 meses 6 meses
3
Indicador de Complexidade do Problema Média Baixa Baixa Média
4
Indicador de Estabilidade dos Requisitos Média Alta Média Média
5Tamanho da Equipe do Projeto 7 8 5 6
6 Criticalidade do Projeto Baixa Muito Baixa Baixa Baixa
7 Ambiente Físico Localizado Localizado Localizado Localizado
8Plataforma de Execução Web Desktop Web Web
9 Domínio da AplicaçãoContábil / Orçamentário
Administração Patrimonial
Administração de Equipamentos Contábil
Segue-se na Tabela 7-12 uma comparação dos atributos do Projeto corrente
(projeto 11) com os atributos dos demais projetos concluídos armazenados. Nesta
tabela, o valor 1 significa que o atributo é similar ao atributo correspondente do Projeto
197
corrente (projeto 11). Os atributos 2 e 5 poderão, no futuro, vir a ter a similaridade
apurada empregando critério mais elaborado, dependendo do que for observado quando
o histórico de projetos da organização evoluir quantitativamente com o uso do guia.
Tabela 7-12 - Grau de Similaridade entre Projetos
Id Parâmetro Projeto 1 Projeto 2 Projeto 10
1 Modelo de Ciclo de Vida 0 0 1
2Duração Estimada do Projeto 0 0 0
3
Indicador de Complexidade do Problema 0 0 1
4Indicador de Estabilidade dos Requisitos 0 1 1
5Tamanho da Equipe do Projeto 0 0 0
6 Criticalidade do Projeto 0 1 17 Ambiente Físico 1 1 18 Plataforma de Execução 0 1 19 Domínio da Aplicação 0 0 0
Grau de Similaridade Estimado entre os Projetos 11,1% 44,4% 66,7%
O limite adotado na versão inicial do guia, para esta similaridade, é de 50%,
podendo ser ajustado futuramente. Portanto o projeto 10 será considerado similar e uma
vez que ele foi bem sucedido, suas práticas mais bem avaliadas serão também
apresentadas para a equipe de testes, que poderá utilizá-las como apoio à tomada de
decisão. Segue a Tabela 7-13 com os dados do Projeto 10 hipotético, encontrado nos
dados históricos dos projetos já concluídos pela organização que está utilizando este
guia.
Tabela 7-13 - Caracterização e Histórico de Projetos de Software
Parâmetro Exemplos de Valores Alternativos
Id do Projeto 10Descrição Sucinta do Projeto Gerencia de Plano ContábilStatus do Projeto ConcluidoData Início do Projeto 19/jul/10Data Término do Projeto 27/jan/11Representante do Cliente MozartRepresentante da Equipe de Desenvolvimento Desenvolvedor 4Código da Equipe de Desenvolvimento SD-33Data de Planejamento da Agilidade p/ Proc 17/jul/10
198
Parâmetro Exemplos de Valores AlternativosTeste do ProjetoData de Avaliação da Agilidade do Proc Teste do Projeto 30/jan/11Resultado Final da Avaliação do Processo de Teste Sucesso
1 Modelo de Ciclo de Vida Iterativo e incremental2 Duração Estimada do Projeto 63 Indicador de Complexidade do Problema Média4 Indicador de Estabilidade dos Requisitos Média5 Tamanho da Equipe do Projeto 66 Criticalidade do Projeto Baixa7 Ambiente Físico Localizado8 Plataforma de Execução Web9 Domínio da Aplicação Contábil
Continuando o exemplo, segue a Tabela 7-14, para o projeto 10 bem sucedido
armazenado no histórico de projetos encerrados, com os valores resultantes de sua
avaliação final. Há nesta tabela entradas para cada prática avaliada, conforme disposto
na seção 7.3.3.
Tabela 7-14 - Apuração de Práticas de Projetos Semelhantes Concluidos com Resultados Satisfatórios
Id Pro-jeto
Id Prá-tica Prática
Quesito Avaliado
Ava-liação
Valor Máxi-
mo
Valor Atri-buido
Grau Ava-liação
da Prá-tica
Evi-dên-cias
Descrição Prática
10 9Backlog de produto
1- Grau em que foi adotada e seguida Alto 2 2
10 9Backlog de produto
2- Contribuição para o sucesso das atividades de teste Médio 2 1 75,0%
10 10Visibilidade de projeto
1- Grau em que foi adotada e seguida Médio 2 1
10 10Visibilidade de projeto
2- Contribuição para o sucesso das atividades de teste Alta 2 2 75,0%
10
Estratégia de comprometi-mento por partes
1- Grau em que foi adotada e seguida Alto 2 2
Criação de 3 conjuntos alternativos de requisitos para adequar à liberação parcial de orçamento
199
Id Pro-jeto
Id Prá-tica Prática
Quesito Avaliado
Ava-liação
Valor Máxi-
mo
Valor Atri-buido
Grau Ava-liação
da Prá-tica
Evi-dên-cias
Descrição Prática
10
Estratégia de comprometimento por partes
2-Contribuição para o sucesso das atividades de teste Alto 2 2
100,0%
Criação de 3 conjuntos alternativos de requisitos para adequar à liberação parcial de orçamento
10 4 Metáfora
1- Grau em que foi adotada e seguida Baixo 2 0
10 4 Metáfora
2- Contribuição para o sucesso das atividades de teste Baixo 2 0 0,0%
10
3- Adequação das prioridades planejadas para as práticas Alta 2 2
10
4- Resultado das práticas para o processo de testes Bom 2 2
Totalizadores 20 14
Nível avaliado de
sucesso: 70,0%
Nível (is) de teste em que o guia foi utilizado: SistemaComentários (texto livre) sobre o desempenho do processo de teste em termos de agilidade:
O nível avaliado de sucesso é de 70% e o projeto neste exemplo terá suas
práticas consideradas junto com a de outros projetos também de sucesso, se fosse o
caso, utilizadas como apoio à decisão a ser tomada pela equipe de testes. Isto porque o
patamar inferior do nível de sucesso para que um projeto seja considerado bem sucedido
ou satisfatório foi adotado inicialmente como sendo 50%. Este é um dos parâmetros de
configuração do guia de agilidade, que poderá ser ajustado no futuro, a partir da
formação de um histórico significativo de projetos concluídos para a organização
usuária do guia.
200
Assim, a Tabela 7-15 que se segue será apresentada para a equipe de testes, em
adição às 3 anteriormente apresentadas (Tabela 7-8, Tabela 7-9 e Tabela 7-10), para
apoiar a tomada de decisão. Na Tabela 7-15 a prática “Estratégia de comprometimento
por partes” não apresenta número de Id porque ela não é originária da base de
conhecimento, mas de projetos concluídos bem sucedidos que se assemelham ao projeto
exemplo.
Tabela 7-15 - Práticas de Projetos Semelhantes Concluídos com Resultados Satisfatórios
Id Prática Grau de Avaliação
Estratégia de comprometimento por partes 100,0%9 Backlog de produto 75,0%
10 Visibilidade de projeto 75,0%
Como as práticas 9 e 10 já haviam sido incluídas, será apresentada ao usuário do
guia apenas a sugestão da prática Estratégia de comprometimento por partes, junto com
sua descrição. Neste momento, alternativamente, haveria uma oportunidade de se incluir
manualmente práticas não consideradas pelo guia, mas julgadas importantes pela equipe
de testes. Estas práticas não influenciariam imediatamente os cálculos de grau de
agilidade em potencial estimado, mas permaneceriam aguardando o final do projeto
para serem avaliadas e se bem sucedidas poderiam ser consideradas em projetos futuros.
No momento oportuno, poderiam ser consideradas pela equipe de testes na organização
e avaliadas para fins de inclusão na base de conhecimento. Se incluídas na base, tais
práticas seriam também mapeadas para as características de agilidade e para as
atividades do processo padrão de teste de software adotado nesta pesquisa.
Segue a Tabela 7-16 mostrando as práticas supostamente escolhidas pela equipe
de testes para o projeto corrente sendo considerado no exemplo.
Tabela 7-16 - Práticas Escolhidas para o Processo de Testes
Id Prática9 Backlog de produto
10 Visibilidade de projeto5 Cliente presente
13 Liberações frequentes8 Jogo de planejamento
12 Design simples14 Reuniões diárias
Estratégia de comprometimento por partesPainel de Acompanhamento
201
Na Tabela 7-16 a prática “Painel de Acompanhamento” não apresenta Id porque
não faz parte da base de conhecimento, é um exemplo de inclusão por parte da equipe
de testes de forma autônoma e independente.
A prática Estratégia de comprometimento por partes, adotada em projetos de
sucesso encontrado no histórico de projetos bem sucedidos em termos de agilidade, não
faz parte da base de conhecimento, mas foi selecionada pela equipe de testes para tentar
inserir características de agilidade no processo de teste de software.
Ainda, a prática Painel de Acompanhamento foi adotada pela equipe de testes,
especificamente para este projeto, não estando nem na base de conhecimento, nem no
histórico de projetos bem sucedidos. Sua descrição, fornecida pelo usuário do guia é:
Quadro atualizado em tempo real, com cada parte do software sendo desenvolvido, os
desenvolvedores a ela alocados, o n. de testes de unidade a ela associados realizados
com e sem sucesso. Isto demonstra o grau de liberdade que o guia apresenta para a
equipe de testes fazer suas escolhas e experiências. A prática adicional será armazenada
junto com todas as demais para este projeto corrente, e será avaliada ao final de sua
execução, permanecendo no histórico e podendo apoiar decisões em projetos futuros.
Passo 8 – Registro das Práticas Escolhidas
De acordo com os resultados do passo 7, a equipe de testes teria tomado a
decisão final sobre quais práticas incluir no processo de teste de software. As atividades
de teste definidas no passo 5 e as práticas ágeis definitivamente escolhidas são
armazenadas para utilização posterior, a fim de serem avaliadas ao final da execução do
projeto. O grau de agilidade estimado para o processo de teste de software seria
calculado conforme se segue.
202
Tabela 7-17 - Recálculo do Grau de Agilidade em Potencial Estimado para o Processo de Testes
100,0% 76,3%
74,1% 71,6% 79,7% 61,3% 64,4% 98,4% 98,4% 94,1% 90,9% 94,1% 92,5% 93,8% 93,1% 61,6%
Soma Produtos PixPCjxPPi
Características Ada-
pta-bilida-
de
Auto-orga-niza-ção
E-mer-gên-cia
Equipes peque-
nas
Incorporação de
Retroalime-ntação
(feedback)Lean-ness
Modu-larida-
de
Orienta-ção a
Pessoas
Reflexão e Introspec-
ção
Ser Colabo-rativo
Ser Coope-rativo
Ser Incre-men-
tal
Ser Itera-tivo
Testes Constan-
tes
Time Bo-xing
Transpa-rência
Ape-nas
Caract Selec
Todas as Ca-
ract
Perti-nência cada
prática
Práticas Defi-nidas
Todas as Práticas
PráticasId 4 5 9 16 10 11 13 14 15 1 2 3 6 7 17 18 (com
pesos)
Backlog de produto 9 0 1 1 0 0 1 0 0 1 1 1 1 1 0 0 0 5 8 95,3% 4,1228 6,4924
Cliente presente 5 1 0 1 0 1 1 0 1 1 1 1 1 1 0 0 0 8 10 50,6% 3,5968 4,4696Desenvolvimento orientado a testes
16 0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0 4 4 59,3% 0,0000 2,2456
Design simples 12 1 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0 3 4 78,3% 2,0323 2,6120
Equipe completa 17 1 1 0 0 0 1 0 1 1 0 0 0 0 0 1 0 3 6 51,0% 0,0000 2,6896
Integração contínua 3 0 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0 4 4 92,1% 0,0000 3,0276Jogo de planejamento
8 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0 3 3 85,0% 2,3131 2,3131
Metáfora 4 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 54,5% 0,0000 0,5369
Padrões de código 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 2 2 78,3% 0,0000 1,5188Propriedade coletiva do código
2 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 1 2 71,5% 0,0000 1,4085
Refatoração 11 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 86,6% 0,0000 0,8656
Releases curtas 13 1 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0 4 4 92,1% 3,3586 3,3586
Reuniões diárias 14 0 1 1 0 1 0 0 1 1 1 0 0 0 0 0 0 3 6 76,3% 2,0764 3,9740
Ritmo sustentável 15 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 1 58,1% 0,0000 0,5719Visibilidade de projeto 10 1 1 0 0 1 1 0 1 1 0 0 0 0 0 0 0 4 6 88,9% 3,0182 4,5717
Grau de Agilidade Potencial Estimado: 50,5%
203
Na Tabela 7-17, Pi é o mapeamento da prática i para cada característica; PCj é o
peso da característica j (adotado como sendo o nível de pertinência apurado para a
característica, conforme descrito no capítulo 5); PPi é o peso da prática i (adotado como
sendo o nível de pertinência apurado para a prática, conforme descrito no capítulo 5).
O valor calculado para o grau de agilidade estimado para o processo de teste de
software seria de 50,5% (consideradas apenas as práticas da base de conhecimento).
Este grau de agilidade estimado foi calculado assim:
( ∑ Pi x PCj x PPi das 7 práticas definidas ) / ( ∑ Pi x PCj x PPi de todas as 15 práticas )
7.5.3 Fase 3 - avaliação dos resultados alcançados
Após a execução de todo o projeto, deve ser feita uma avaliação dos resultados
alcançados para o processo de teste de software quanto a agilidade.
Para o planejamento efetuado é apresentado um conjunto de questões a serem
avaliadas pela equipe de testes, para cada prática ágil planejada e para o processo de
teste de software como um todo. O guia apoiará a equipe de testes na avaliação,
observando o disposto na seção 7.3.3, de modo semelhante à Tabela 7-18 que se segue.
A coluna “valor atribuído” fica transparente para o avaliador, sendo completada
posteriormente conforme já apresentado na seção 7.3.3. O avaliador deve preencher as
colunas “Avaliação”, “Evidências” e “Descrição da prática (se fora da base de
conhecimento)”, esta última quando for o caso. A Tabela 7-18 só seria preenchida ao
término do projeto exemplo. Contudo uma visão da mesma tabela para um projeto já
avaliado (Projeto Id = 10) foi utilizada e apresentada anteriormente nesta seção (Tabela
7-14).
204
Tabela 7-18 - Avaliação dos Resultados para o Projeto Concluído
Projeto Id = 11, Acompanhamento e Controle do Planejamento e da Execução Orçamentária
Id Proje
-to
Id Práti-ca Prática
Quesito Avaliado
Ava-lia-ção
Valor Má-ximo
Valor Atri-buido
Grau Avalia-ção da Prática
Evi-dên-cias
Descrição da Prática (se
fora da base de conheci-
mento)
11 9Backlog de produto
1- Grau em que foi adotada e seguida 2
11 9Backlog de produto
2- Contribuição para o sucesso das atividades de teste 2
11 10Visibilidade de projeto
1- Grau em que foi adotada e seguida 2
11 10Visibilidade de projeto
2- Contribuição para o sucesso das atividades de teste 2
11
Estratégia de comprometimento por partes
1- Grau em que foi adotada e seguida 2
Criação de 3 conjuntos alternativos de requisitos para adequar à liberação parcial de orçamento
11
Estratégia de comprometimento por partes
2- Contribuição para o sucesso das atividades de teste 2
Fora da base de conhecimento, mas já adotada com sucesso em projetos semelhantes concluidos.
11 13Liberações frequentes
1- Grau em que foi adotada e seguida 2
11 13Liberações frequentes
2- Contribuição para o sucesso das atividades de teste 2
11 14Reuniões diárias
1- Grau em que foi adotada e seguida 2
11 14Reuniões diárias
2- Contribuição para o sucesso das atividades de teste 2
11 12 Design simples
1- Grau em que foi adotada e seguida 2
11 12 Design simples
2- Contribuição para o sucesso das atividades de teste 2
11 8Jogo de planejamento
1- Grau em que foi adotada e seguida 2
205
Id Proje
-to
Id Práti-ca Prática
Quesito Avaliado
Ava-lia-ção
Valor Má-ximo
Valor Atri-buido
Grau Avalia-ção da Prática
Evi-dên-cias
Descrição da Prática (se
fora da base de conheci-
mento)
11 8Jogo de planejamento
2- Contribuição para o sucesso das atividades de teste 2
11
Painel de Acompanhamento
1- Grau em que foi adotada e seguida 2
Quadro atualizado em tempo real, com cada parte do software sendo desenvolvido, os desenvolvedores a ela alocados, o n. de testes de unidade a ela associados realizados com e sem sucesso.
11
Painel de Acompanhamento
2- Contribuição para o sucesso das atividades de teste 2
Adotada especificamente neste projeto, fora da base de conhecimento e fora do histórico de projetos concluidos.
11 5 Cliente presente
1- Grau em que foi adotada e seguida 2
11 5 Cliente presente
2- Contribuição para o sucesso das atividades de teste 2
11
3- Adequação das prioridades planejadas para as práticas 2
11
4- Resultado das práticas para o processo de testes 2
TOTALIZADORES
40 0
Nível avaliado de sucesso:
Nível (is) de teste em que o guia foi utilizado:Comentários (texto livre) sobre o desempenho do processo de teste em termos de agilidade:
Deve-se observar instruções para cada quesito a ser avaliado em termos de
agilidade, conforme a seção 7.3.3. O quesito 2- Contribuição para o sucesso das
atividades de teste, deverá ser avaliado tendo em vista cada característica de agilidade
armazenada na base de conhecimento e selecionada na fase de planejamento (fase 2)..
206
7.6 Conclusão
Neste capítulo foi explicitada a descrição de uma estratégia de apoio à inserção
de características de agilidade em processos de teste de software. Também foram
descritos em detalhes o procedimento associado e um guia elaborado para apoiar a
aplicação da estratégia proposta em projetos reais de organizações. Foi apresentado um
exemplo para ilustrar a utilização do guia elaborado para inserção de características de
agilidade em processos de teste de software.
Tendo em vista a consciência sobre as ameaças à validade que pairam sobre os
resultados dos estudos, e numa tentativa de minimizar seus impactos negativos, a
estratégia proposta prevê a possibilidade de uso, pelo usuário do guia, de alternativas
diferentes daquelas registradas na base de conhecimento. Assim, provê mecanismos
para que a equipe de testes possa inserir atividades de teste e práticas ágeis
diferenciadas, conforme seu entendimento. Além disso, o guia fortalece e/ou reforça a
idéia de melhoria contínua do procedimento para planejar agilidade em testes, através
de mecanismos de avaliação e/ou atualização da base de conhecimento, à medida em
que este evolui na organização.
Há que ser ressaltada a necessidade de se executar um estudo mais amplo sobre
a viabilidade e desempenho desta abordagem e o guia a ela associado. A aplicação da
estratégia proposta deve ser em nível de processo de teste de software. Portanto, é
necessário um tempo de maturação e observação, tornando esta execução inviável neste
momento.
No capítulo 8 serão apresentadas as considerações finais desta pesquisa.
207
8. Considerações Finais
Neste capítulo é apresentado um resumo com a descrição sucinta do
trabalho realizado, junto com os resultados alcançados, as
contribuições da pesquisa, suas limitações e sugestões de trabalhos
futuros para sua continuidade.
8.1 Sinopse do Trabalho Realizado
Nos últimos anos, em especial após o advento do Manifesto Ágil (2001), pode
ser observado um interesse crescente pelas abordagens ágeis por parte da comunidade
de Engenharia de Software. Isto pode ser evidenciado pela quantidade crescente de
artigos publicados ao longo dos anos sobre o tema, conforme pode ser observado nos
quantitativos de artigos recuperados pelas diferentes máquinas de busca utilizadas nas
revisões sistemáticas apresentadas nos capítulos 3 e 4 desta tese.
Conforme mencionado no capítulo 1, mudanças constantes, especialmente nos
requisitos e no ambiente, são cada vez mais imperativas, além de inerentes à dinâmica
dos negócios no mundo contemporâneo, se transformando em dificuldades para
processos de software muito rígidos. Tais processos precisam ser ágeis o suficiente para
serem capazes de acomodar incertezas e mudanças rápidas, em ambientes de negócios
altamente sensíveis ao tempo.
Em geral, até o momento a literatura técnica sobre abordagens ágeis tinha como
foco principal tratar os processos de desenvolvimento de software como um todo ou em
sua forma mais ampla. Assim, não foram encontrados trabalhos na literatura técnica que
tratassem detalhadamente a agilidade aplicada a um processo de software específico e
integrante do processo de desenvolvimento, como por exemplo, o processo de teste de
software.
Esta tese objetivou apresentar uma abordagem para introduzir características de
agilidade em processos de teste de software. A alternativa escolhida para alcançar o
objetivo foi a adoção, nestes processos, de práticas que permitam obter as características
de agilidade desejadas. Para isso, as características de agilidade e as práticas ágeis
foram identificadas através de revisão sistemática da literatura e tiveram sua pertinência
208
e relevância avaliadas através de pesquisa de opinião com especialistas da área de
agilidade em processos de software. As atividades de teste de software foram
identificadas a partir de um processo padrão de teste de software, com base em modelos
pré-estabelecidos e encontrados na literatura técnica, adotado como padrão nesta tese.
Após sua avaliação, as práticas ágeis foram relacionadas com as características de
agilidade e com as atividades de teste de software, tomando por base as possíveis
influências que as práticas teriam em permitir atingir determinada característica de
agilidade e apoiar a obtenção dos produtos de trabalho das atividades de teste. Estes
relacionamentos, em seguida, se tornaram objeto de avaliação por revisores externos.
Com base nestes resultados, uma base de conhecimento foi organizada juntamente com
um guia para introduzir agilidade em processos de teste de software. O guia apóia o
engenheiro de software na tomada de decisão sobre a inclusão de um conjunto de
práticas ágeis a serem implementadas no processo de teste de software e a calcular um
grau de agilidade em potencial estimado para este processo, supondo que as práticas
sejam satisfatoriamente implementadas. O guia prevê ainda, apoio à avaliação do
processo de teste de software, em termos de agilidade, quando o projeto do software for
concluído. Após esta avaliação, o grau de agilidade real alcançado pelo processo de
teste de software é determinado conforme descrito na seção 7.3.3, permitindo aprimorar
o conhecimento existente que poderá ser utilizado em futuros projetos.
Portanto, a solução apresentada para introduzir agilidade em processos de teste
de software integra mecanismos de aprendizado, prevendo atualização e/ou
incorporação de conhecimento adicional à base instalada, para fins de melhoria contínua
do guia, com base em novos estudos e/ou lições aprendidas com projetos concluídos.
Espera-se que tais mecanismos de atualização e/ou incorporação de novos
conhecimentos, na medida em que forem aplicados, possam gradualmente, tornar o guia
cada vez mais especializado para o ambiente e contextos específicos da organização que
o utiliza, propiciando resultados mais satisfatórios ao longo do tempo.
O trabalho de pesquisa realizado pressupõe que a organização que utilizará o
guia possui um processo de teste de software estabelecido, e deseja torná-lo ágil no
contexto de desenvolvimento de software, esteja ele inserido em um processo ágil ou
tradicional de desenvolvimento de software. Na elaboração da estratégia de solução
apresentada para introduzir características de agilidade em processos de teste de
software houve a preocupação de criar uma solução alternativa que não fosse
209
excessivamente intrusiva. A idéia de não ser intrusiva é no sentido de tentar, com a sua
aplicação, não afetar ou afetar o mínimo possível, o desempenho do processo de teste de
software previamente estabelecido, em termos de alcance de seus objetivos pré-
definidos e para os quais ele foi idealizado.
Também se preocupou para que o guia de agilidade fosse o mais “leve” possível,
o que levou ao abandono de algumas idéias, como por exemplo a consideração de
planejamento de agilidade a cada iteração, como está na própria natureza das
abordagens ágeis; a consideração de planejamento por nível de teste, logo descartada,
porque os processos genéricos de teste de software apresentados pelos autores dos
artigos pesquisados pressupostamente já são aplicáveis aos diferentes níveis de teste de
software; utilizar o método AHP – Analytic Hierarchy Process (SAATY, 2000) para
priorizar critérios de escolha de características de agilidade/práticas ágeis. Este método
(AHP) já foi empregado por MIKULENAS e BUTLERIS (2010) na apresentação de
uma abordagem para construir modelos de avaliação da adequação de metodologias
ágeis a organizações de tecnologia da informação. A idéia de utilizar o método AHP foi
descartada uma vez que o esforço necessário para sua aplicação foi considerado acima
do que seria desejado para o guia de agilidade, podendo gerar uma sobrecarga excessiva
para seus aplicadores.
Pode-se dizer que a solução apresentada para introduzir agilidade tem uma parte
genérica e uma parte específica. A parte genérica pode ser aplicada a diferentes
processos de software. A parte específica estaria associada com a identificação das
atividades do processo de software específico que se deseja atender, que no caso do
objetivo final desta tese é o processo de teste de software. Outro processo de software
específico poderia ter sido escolhido como alvo, e ter suas atividades identificadas e
mapeadas para as práticas ágeis, sendo estas identificações e mapeamentos carregados
na base de conhecimento. Desse modo, em princípio o guia de agilidade poderia ser
aplicado também para este outro processo específico. Em outras palavras, o guia
apresentado para introduzir agilidade em processos de software poderia ser aplicado a
outros processos que não o de teste de software, desde que as atividades dos outros
processos possam ser identificadas e mapeadas para as práticas ágeis, sendo então
incorporadas à base de conhecimento.
Assim, a inserção de agilidade em processos de desenvolvimento de software
pode ser exercitada também no sentido inverso dos níveis de abstração dos processos,
210
ou seja, ao invés de focar apenas no processo de desenvolvimento como um todo, partir
de seus processos constituintes e convergir para as características de agilidade
aplicáveis ao processo de desenvolvimento de software em nível de abstração ou de
granularidade mais alta.
Nas seções seguintes são apresentados de forma sucinta, os resultados obtidos
com este trabalho de pesquisa, suas contribuições e limitações, bem como sugestões de
trabalhos futuros para evoluir os resultados alcançados.
8.2 Resultados Obtidos
Nesta seção, os resultados obtidos no trabalho de pesquisa serão relacionados
com as questões de pesquisa apresentadas no capítulo 1, seção 1.3.
Questão: “Há alguma solução para embutir características de agilidade no
processo de teste de software a partir da adoção de práticas? Qual?”
Resultado: A princípio, sim. Foi elaborada uma estratégia de solução para
introduzir agilidade em processos de teste de software. Nesta pesquisa foi adotado um
processo padrão de teste de software e suas atividades foram consideradas na estratégia
de solução proposta. Um guia de agilidade, visando apoiar as equipes de teste no
planejamento de agilidade para processos de teste de software, faz parte da solução,
juntamente com a instrumentação necessária para sua aplicação nas organizações de
software. Entretanto, uma avaliação experimental é necessária para observar o
desempenho desta estratégia frente às soluções ad-hoc usualmente empregadas pela
indústria.
Questão: “Quais as características de agilidade são pertinentes e devem ou
podem ser candidatas a serem inseridas em um processo de teste de software com a
finalidade de torná-lo ágil?”
Resultado: Um conjunto de 18 características de agilidade, para processos de
software de modo geral e independentemente de metodologias ágeis específicas foi
identificado através de revisão sistemática da literatura e avaliado através de pesquisa de
opinião com especialistas em abordagens ágeis. Estas características foram incorporadas
211
a uma base de conhecimento de forma a apoiar a estratégia de solução proposta para
introduzir agilidade em processos de teste de software.
Questão: “Quais práticas ágeis de software são pertinentes e podem ser
consideradas para serem adotadas em processos de teste de software com o objetivo de
tentar embutir características de agilidade neste processo?”
Resultado: As práticas ágeis foram identificadas através de revisão sistemática
de literatura e avaliadas através de pesquisa de opinião com especialistas em abordagens
ágeis. Estas práticas foram incorporadas a uma base de conhecimento para apoiar a
estratégia de solução proposta para introduzir agilidade em processos de teste de
software.
Questão: “Como fazer o mapeamento das práticas de software para as
características de agilidade que se deseja embutir no processo de teste de software?”
Resultado: Os relacionamentos entre práticas de software e características de
agilidade foram identificados. Posteriormente estes relacionamentos foram avaliados
através de revisão por pares e atualizados com base nos resultados. Em seguida os
relacionamentos foram incorporados à base de conhecimento para apoiar a estratégia de
solução proposta para introduzir agilidade em processos de teste de software.
Questão: “Como estimar o grau de agilidade apresentado por um processo de
teste de software?”
Resultado: Não foram encontradas na literatura técnica alternativas para avaliar
o grau de agilidade de processos de software que pudesse ser aplicada diretamente em
um processo de teste de software real. Algumas idéias apresentadas por QUMER e
HENDERSON-SELLERS (2008) foram selecionadas, adaptadas e aprimoradas para
estimar o grau de agilidade em potencial de um projeto de teste de software que teve sua
agilidade planejada com o guia proposto.
212
Questão: “Como avaliar a solução proposta para verificar se ela atinge o seu
objetivo e se uma abordagem ágil pode ser aplicada com sucesso nos processos de teste
de software?”
Resultado: A avaliação da solução proposta passa necessariamente pela
avaliação do desempenho em termos de agilidade dos processos de teste de software
que tenham o seu planejamento de agilidade apoiado por esta solução. O guia para
introduzir agilidade em processos de teste de software prevê a avaliação dos resultados
por ele alcançados, em termos de agilidade, ao final do projeto. Os quesitos para avaliar
o desempenho do processo de teste de software foram considerados pelo guia de
agilidade proposto e estão incluídos na instrumentação preparada para sua aplicação.
Contudo, para tal avaliação, fazem-se necessários estudos que incluam a aplicação do
guia para planejar a agilidade em diferentes processos de teste de software, em
diferentes ambientes e contextos, aguardando em seguida o término da execução dos
projetos para avaliar os resultados alcançados. Embora toda a instrumentação esteja
pronta, não foi possível executar estudos para avaliar viabilidade e desempenho da
estratégia proposta, inclusive porque ela tem que ser aplicada a nível de processo de
teste e necessitaria de um tempo para observação e maturação não disponível neste
momento.
8.3 Contribuições da Pesquisa
O conhecimento necessário para se fazer o planejamento e introduzir agilidade
em processos de software e, particularmente, em processos de teste de software está
esparso na literatura técnica. Este fato por si só aumenta a complexidade em planejar
agilidade em processos de teste pelos engenheiros de software. Alem disso, há o fato de
que ainda não existe maturidade suficiente no contexto das abordagens ágeis para que se
possa ter um padrão de terminologia consistente e não ambíguo, facilitando o
entendimento destas abordagens para desenvolver software. Neste sentido, o trabalho de
pesquisa apresentado consolidou em uma única base, o conhecimento inicial e,
acreditamos, necessário para planejar agilidade em processo de teste de software. As
inconsistências terminológicas foram na medida do possível tratadas e os
relacionamentos identificados entre os conceitos foram explicitados.
213
Foi elaborado um guia para planejar a introdução de agilidade em processos de
teste de software, com a instrumentação a ele associada, contemplando a avaliação de
resultados e a utilização de lições aprendidas de projetos de software concluídos para
apoiar o planejamento de agilidade em projetos futuros. Não se pode garantir o sucesso
da agilidade planejada com o guia elaborado para processos de teste de diferentes
projetos de software. Isto porque o sucesso dependerá de diversos fatores que por sua
vez são influenciados pelo perfil da organização que utiliza o guia, do ambiente de
desenvolvimento, do contexto dos projetos de software que terão seus processos de teste
planejados e também da forma como as práticas sugeridas são implementadas pelas
equipes de testes. Contudo, existe a expectativa de que a utilização continuada do guia
em uma organização e o planejamento também apoiado por lições aprendidas em
projetos concluídos (dependente da formação de uma base histórica de projetos) poderá
aumentar as chances de sucesso do planejamento de agilidade para os processos de teste
de software na organização. Além disso, os limites ou pontos de corte inicialmente
adotados e sugeridos com o guia, bem como o conhecimento sobre características de
agilidade, práticas ágeis, atividades de teste de software e seus relacionamentos poderão
ser atualizados conforme a necessidade da organização, aumentando assim, as chances
de sucesso em obter agilidade em seus processos de teste de software.
O guia de planejamento de agilidade para processo de teste de software
apresentado é independente de metodologias ágeis específicas, proporcionando
flexibilidade e liberdade de escolha por parte das organizações usuárias. Este guia pode
ser estendido com relativa facilidade. O esforço na elaboração do guia, inclusive para
preencher a base de conhecimento, poderá ser reaproveitado em grande parte, para
planejar a agilidade em outros processos de software. Para isso o novo processo alvo
deverá ter suas atividades identificadas e os seus relacionamentos com as práticas ágeis
estabelecidos. Além disso, o guia pode reforçar a idéia de uma cultura de melhoria de
processo na organização, a partir da retroalimentação de resultados alcançados por
projetos concluídos.
Segundo ABRAHAMSSON, OZA e SIPONEM (2010) um problema
fundamental nas abordagens ágeis é combinar abrangência com profundidade em um
método, de forma sensata. A abrangência se refere à menor ou maior quantidade de
fases do processo que o método cobre. A profundidade se refere ao nível de detalhe em
que cada fase do processo é considerada pelo método. Para aqueles autores, em geral os
214
métodos que procuram atender plenamente estas duas dimensões, correm o risco de se
tornar o que eles chamam de “dinossauro metodológico”, ou seja, difíceis de serem
aplicados. Com a estratégia proposta, a profundidade do guia não é muito flexível, no
sentido de que ele não prevê abertura para planejar ao nível de subatividades de teste.
Contudo, o guia elaborado tem a abrangência definida pela equipe de testes, no sentido
de que ela pode selecionar qualquer conjunto de atividades de teste para planejar a
agilidade do processo. Desse modo, o guia de agilidade é flexível, permitindo a equipe
de testes buscar o equilíbrio desejado da abrangência variável, com a profundidade fixa
ao nível das macro-atividades de teste de software.
A estratégia de solução apresentada pode, também, ser considerada um gerador
de hipóteses para futuros trabalhos de pesquisa no contexto das abordagens ágeis. Por
exemplo, os diversos relacionamentos indicados entre práticas ágeis e características de
agilidade/atividades de teste de software representam comportamentos que necessitam
evidências mais fortes sobre sua existência e pertinência.
8.4 Limitações da Pesquisa
Uma limitação da solução apresentada nesta tese é o fato de não ter sido
considerada na elaboração do guia a influência da cultura organizacional e do
comportamento dos indivíduos no desempenho dos processos de software dos quais eles
participam. Pode ser que uma solução que conduza um processo de teste de software ao
sucesso com uma determinada equipe, não alcance o mesmo resultado em projetos
similares, mas com uma equipe diferente. A avaliação da similaridade entre projetos é
considerada para apoiar o planejamento de agilidade para o processo de teste de um
projeto corrente ou futuro, através de lições aprendidas, mas não leva em conta o perfil
de diferentes equipes (indivíduos diferentes podem apresentar comportamentos
diferentes; os mesmos indivíduos podem apresentar comportamentos diferentes em
tempos e circunstâncias diferentes).
Outra limitação do trabalho apresentado é que ele está atrelado ao processo
padrão de teste de software adotado e utilizado para gerar as atividades de teste da base
de conhecimento, apesar do guia prever a possibilidade de inclusão de atividades
diferentes quando a equipe de testes estiver realizando o planejamento de agilidade para
o processo de teste de software.
215
O fato de o guia não ter sido avaliado através de um estudo experimental
representa outra limitação, impedindo a coleta de evidências das situações ou diferentes
contextos em que ele pode alcançar o resultado desejado e aquelas em que isso não é
possível.
O trabalho apresentado não contempla nem apóia a implementação das práticas
ágeis, o que seria de grande utilidade para muitas equipes de teste sem experiência com
as abordagens ágeis, uma vez que o modo de implementar tais práticas pode ser um
fator crítico de sucesso para a agilidade de um processo de teste de software. Contudo,
como acontece com alguns modelos de maturidade de processo de software, esta
evolução precisa ser pensada como uma melhoria e será relacionada como uma
possibilidade para trabalhos futuros.
A solução apresentada não prevê a consideração em nível de detalhe de
subatividades do processo de teste de software, limitando inicialmente sua aplicação em
profundidade.
8.5 Trabalhos Futuros
Julga-se interessante continuar a investigação de mecanismos para inserir
agilidade em processos de software, através de outros estudos para aprimorar esta tarefa,
seja no processo de teste de software ou em outro processo de software específico,
podendo incluir dentre outros, os estudos a seguir relacionados.
Identificar o momento mais oportuno e realizar avaliações adicionais das
características e práticas identificadas.
Realizar estudos para verificar na literatura técnica a existência de
relacionamentos entre práticas ágeis e atividades de processos de teste de
software que possam apoiar os mapeamentos estabelecidos neste
trabalho. O mesmo se aplica para os relacionamentos entre as práticas
ágeis e as características de agilidade.
Planejar e executar estudos experimentais para avaliar a aplicação do
guia pelas organizações e identificar que melhorias precisam ser feitas de
modo mais imediato. Muitas vezes algumas mudanças consideradas a
princípio não muito significativas podem ser de real valor para algumas
organizações.
216
Mesmo que alguns estudos experimentais já tivessem sido feitos dentro
das limitações de prazo desta tese, estudos adicionais seriam necessários
para coletar evidências e identificar em que ambientes de
desenvolvimento e contextos de projeto, o guia apresentado funciona
bem e conduz o processo de teste de software a um desempenho
aceitável em termos de agilidade, e em que ambientes ou contextos isso
não acontece.
Planejar e executar estudos experimentais para avaliar/confirmar a
adequação do guia para diferentes níveis de teste ou se alguma
adequação precisa ser feita com a finalidade de atender algum nível de
teste específico.
Efetuar estudos para explorar mais a definição do grau de agilidade
estimado e alcançado para um processo, o que nesta pesquisa não foi
suficientemente investigado.
A solução apresentada utiliza uma base de conhecimento que inclui
características de agilidade, práticas ágeis e atividades de teste de
software, com seus relacionamentos. Seria interessante realizar um
estudo a fim de derivar uma estrutura organizada para este conhecimento,
através de classificações, conforme foi feito por VEGAS, JURISTO e
BASILI (2009) para as técnicas de teste de software. Tal estudo pode
apoiar a investigação dos relacionamentos entre práticas ágeis e
características de agilidade/atividades de teste de software, bem como
apoiar a identificação de lacunas que precisam ser exploradas. Além
disso, as classificações poderiam apoiar a seleção de características e
práticas para o planejamento de agilidade para um processo de teste de
software.
Estudar a possibilidade de estender o guia de agilidade para considerar
subatividades do processo de teste de software, flexibilizando sua
aplicação em profundidade.
217
Referências Bibliográficas
ABBAS, NOURA. GRAVELL, ANDREW M. WILLS, GARY B. (2010) “Using Factor Analysis to Generate Clusters of Agile Practices”, In: AGILE Conference, August 9 - 13, Orlando, Florida.
ABRAHAMSSON, P. OZA, N. SIPONEM, M.T. (2010) “Agile Software Development Methods: A Comparative Review”, in Agile Software Development – Current Research na Future Directions, Dingsoyr, T. Dyba, T., Moe, N.B., Eds. Berlin Heidelberg: Springer Verlag, pp. 31-79.
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 ComputerSociety, p. 244-254
ABRANTES, JOSÉ FORTUNA. TRAVASSOS, GUILHERME HORTA (2007) “Revisão quasi-Sistemática da Literatura: Caracterização de Métodos Ágeis de Desenvolvimento de Software”, COPPE / UFRJ, Relatório Técnico, RT – ES-714 / 2007.
ABRANTES, JOSÉ FORTUNA. TRAVASSOS, GUILHERME HORTA (2007a) “Caracterização de Métodos Ágeis de Desenvolvimento de Software” SBQS 2007 (Simpósio Brasileiro de Qualidade de Software) - WDRA (Workshop de Desenvolvimento Rápido de Aplicações)
ABRANTES, JOSÉ FORTUNA. TRAVASSOS, GUILHERME HORTA (2011) “Práticas e Características de Agilidade em Processos de Teste de Software”, COPPE / UFRJ, Relatório Técnico, RT – ES-743 / 2011.
ABRANTES, JOSÉ FORTUNA. TRAVASSOS, GUILHERME HORTA, (2011a)“Common Agile Practices in Software Processes”, In: 5th International Symposium on Empirical Software Engineering and Measurement, September 22-23, 2011 – Banff, Alberta, Canada.
ADOLPH, STEVE. (2006) What lessons can the agile community learn from a maverick fighter pilot?. In: AGILE 2006 Conference, pp. 94--99.
AGERFALK, P. FITZGERALD, B. (2006) “Flexible and distributed software processes: old petunias in new bowls?” Communications of the ACM 49 (10) 27–34.
AGILE ALLIANCE. (2001) Available at http://www.agilealliance.com/home, Accessed in 2009 January, 12.
218
AGILE ENTERPRISE. (2008) “Enterprise Agile Process” available at http://www.e-architects.com/AE/index.html, accessed in 2008 September, 14.
AGILE MANIFESTO. (2001) Available at http://agilemanifesto.org, Accessed in 2007August, 23.
AGILE SOFTWARE DEVELOPMENT PORTAL (2008) “Breed”, available at http://agile.csc.ncsu.edu/index.html, accessed in 2008 September, 14.
AIELLO, G. ALESSI, M. BRUCCOLERI, M. D'ONOFRIO C. VELLA, G. (2007) "An Agile methodology for Manufacturing Control Systems development", Engisud S.p.a., Palermo, Italy.
AMBLER, S. (2002) “Agile Modeling: Effective Practices for Extreme Programming and the Unified Process”, New York, John Wiley & Sons Inc.
AMBLER, S.W. (2009) "Agile Practices Survey Results: July 2009", disponível em http://www.ambysoft.com/surveys/practices2009.html, acessado em 25 de fevereiro de 2010.
AOYAMA, MIKIO. (1998) “Agile Software Process and Its Experience”, Proceedings of the 1998 International Conference on Software Engineering, p. 3-12.
AOYAMA, MIKIO. (1998a) “Web-Based Agile Software Development”, IEEE Software November/ December 1998.
BECK, K. (1999) “Extreme Programming Explained: Embrace Change”, Reading, Mass., Addison-Wesley.
BECK, K. (1999a) “Embracing Change with Extreme Programming”, Ieee Computer, v. 32, n. 10, p. 70-77.
BECK, K. Andres, Cynthia. (2004) “Extreme Programming Explained: Embrace Change”, Second Edition, Addison Wesley Professional.
BEIZER, B. (1990) “Software Testing Techniques”, 2nd edition. Boston, MA: International Thomson Computer Press.
BERGER, P. (2003), “Instanciação de Processos de Software em Ambientes Configurados na Estação TABA”, Dissertação de Mestrado COPPE/UFRJ. Rio de Janeiro.
BESSAM, AMMAR. KIMOUR, MOHAMED T. MELIT, ALI. (2009) “Separating Users’ Views in a Development Process for Agile Methods”, In: Fourth International Conference on Dependability of Computer Systems.
BINDER, ROBERT V. (2000) “Testing Object-Oriented Systems- Models, Patterns and Tools”, Addison-Wesley.
BOEHM, B. & TURNER. R. (2003) “Observations on balancing discipline and agility”, Proceedings of the Agile Development Conference.
219
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, 718-719.
BOEHM, B. & TURNER, R. (2004a) “Balancing agility and discipline: A Guide for the Perplexed”, Pearson Education Inc, Boston, MA.
BOHEM, B. (2008), “Making a difference in the software century”, IEEE computer society.
BORJESSON, A. MATHIASSEN, L. (2005) “Improving software organizations: agility challenges and implications”, Information Technology & People Vol. 18 No. 4, 2005 pp. 359-382.
CANNIZZO, FABRIZIO. MARCIONETTI, GABRIELA. MOSER, PAUL. (2008) "The Toolbox Of A Successful Software Craftsman", 15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems.
CAPES BR Portal- Portal de Periódicos da CAPES, http://www.periodicos.capes.gov.br
CHOW, D. YU, C.T. (1982) “On the Construction of Feedback Queries”, Journal of the ACM, v. 29, n. 1, p. 127-151.
COCKBURN A. AND HIGHSMITH J. (2001), "Agile Software Development: The Business of Innovation." Computer v. 34, n.9, pp. 120-127.
COCKBURN, A. (2002) “Agile Software Development Joins the ‘Would be’ Crowd”, Cutter IT Journal, v.15, n.2.
COCKBURN, A. (2002a) “Agile Software Development”, Boston, Addison-Wesley.
COLLOFELLO, J.S. YANG, Z. TVEDT, J. D. MERRILL, D. RUS, I. (1996) “Modeling Software Testing Processes”, Proceedings of the IEEE Fifteenth Annual International Phoenix Conference on Computers and Communications, 289-293.
COHEN, D. LINDVALL, M. COSTA, P. (2004), “An Introduction to Agile Methods”, In: M.V. Zelkowitz (Ed.), Advances in Computers, Advances inSoftware Engineering, vol. 62, Elsevier, Amsterdam, 2004.
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.
CONBOY, K. (2009) Agility from First Principles: Reconstructing the Concept of Agility in Information Systems Development. Information Systems Development, vol 20, n. 3, pp. 329-354.
CONCAS, GIULIO. FRANCESCO, MARCO DI. MARCHESI, MICHELE. QUARESIMA, ROBERTA. PINNA, SANDRO. (2008) "Study of the Evolution
220
of an Agile Project Featuring a Web Application Using Software Metrics", A. Jedlitschka and O. Salo (Eds.): PROFES 2008, LNCS 5089, pp. 386-399
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 (ECBS’05).
CUGOLA, G. GHEZZI, C. (1998), "Software Processes: a Retrospective and a Path to the Future", In Proc. of the Software Process Improvement and Practice Conference, pp. 101-123.
DAVIS, GRAHAM. (2000) “Managing the test process”, Ieee Proceedings International Conference on Software Methods and Tools, p. 119-126.
DI LUCCA, G. A. FASOLINO, A. R. (2006) “Testing Web-based applications: The state of the art and future trends”, Information and Software Technology, 48, 1172-1186.
DIAS NETO, A.C. TRAVASSOS, G.H. (2006) “Maraká: Infra-estrutura Computacional para Apoiar o Planejamento e Controle dos Testes de Software“, in V Simpósio Brasileiro de Qualidade de Software – SBQS
DIAS NETO, A.C. TRAVASSOS, G.H. (2008), ―Uma Estratégia de Apoio à Seleção de Abordagens de Teste Baseado em Modelos para Projetos de Software‖, No: Workshop de Teses e Dissertações em Qualidade de Software (WTDQS‘08), Junho, Florianópolis, SC.
DIESTE, O. PADUA, A.G. (2007) “Developing Search Strategies for Detecting Relevant Experiments for Systematic Reviews”, First International Symposium on Empirical Software Engineering and Measurement, ESEM-2007.
DSDM CONSORTIUM. (2008) Dynamic Systems Development Method, 4.2 public version, available at http://www.dsdm.org/version4/2/public/introduction.asp accessed in 2008 Aug 11.
DYBA, T. DINGSOYR, T. (2008) Empirical Studies of Agile Software Development: A Systematic Review. Information and Software Technology, v.50 n.9-10, p.833-859, August.
FARIAS, L.D. (2002) "Planejamento de Riscos em Ambientes de Desenvolvimento de Software Orientados à Organização", Dissertação de M.Sc., COPPE/UFRJ, Rio de Janeiro, Agosto.
FAVARO, J. (2002) “Managing Requirements for Business Value”, Ieee Software, v.19 p. 15-17.
FERREIRA, AURÉLIO B. HOLLANDA. (2004) “Novo Dicionário da Língua Portuguesa”. Curitiba: Editora Positivo.
FOURNIER, G. (2009) “Essential Software Testing A Use-Case Approach“, Auerbach Publications, CRC Press, Taylor & Francis Group, New York USA.
221
FRUHLING, ANN. DE VREEDE, GERT-JAN. (2006) "Field Experiences with eXtreme Programming: Developing an Emergency Response System", Journal of Management Information Systems / Spring Vol. 22, No. 4. pp. 39-68.
GARFIELD, E. (1970) “The Role of Man and Machine in an International Selective Dissemination of Information System: Ways to Compile More Effective User Profiles, Based on ISI’ s Five Years of SDI System Experience”, Proceedings of User’s of Documentation: FID International Congress on Documentation, Buenos Aires.
GILB, K. (2007) “Evolutionary Project Management & Product Development”, unfinished book.
GLAZER, HILLEL. (2010) “Love and Marriage: CMMI and Agile Need Each Other”, CrossTalk: The Journal of Defense Software Engineering. Volume 23, No. 1, Jan/Feb.
GUZZO, R. A. DICKSON, M. W. (1996)Teams in organizations: Recent research on performance and effectiveness. Annual Review of Psychology, 47, 1, pp. 307--338.
HAMBURG, MORRIS, (1980) “Basic Statistics: A Modern Approach”, Journal of the Royal Statistical Society, Series A (General), Vol. 143, No. 1.
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.
HASS, A. M. J. (2008) “Testing processes”, IEEE International Conference on Software Testing Verification and Validation Workshop ICSTW.
HAZZAN, O. TOMAYKO, J (2003) "The Reflective Practitioner Perspective in eXtreme Programming", Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2753, 51-61.
HAZZAN, O. DUBINSKY, Y. (2006) “Can Diversity in Global Software Development be Enhanced by Agile Software Development?”, ACM Digital Library.
HIGHSMITH, J. (2000) “Adaptive Software Development: A collaborative approach to Manage Complex Systems”, New York, NY, Dorset House Publishing.
HIGHSMIHT, J. (2002) “Agile Software Development Ecosystems”, Addison Wesley.
HIGHSMIHT, J. COCKBURN, A. (2001) “Agile Software Development: The Business of Innovation”, Computer, v. 34, n. 9, p. 120-122.
HOLMSTROM, HELENA. FITZGERALD, BRIAN. et al. (2006) “Contemporary practices in systems development. Agile Practices Reduce Distance in Global Software Development”, Information Systems Management, summer.
222
HUANG, LIANG. HOLCOMBE, MIKE. (2009) “Empirical investigation towards the effectiveness of Test First programming”, Information and Software Technology 51 (2009) 182–194
HUNT, A. THOMAS, D. (2000) “The Pragmatic Programming”, Addison-Wesley.
HUO, MING. VERNER, JUNE. ZHU, LIMING. ALI BABAR, MUHAMMAD. (2004) "Software Quality and Agile Methods", Proceedings of the 28th Annual International Computer Software and Applications Conference (COMPSAC'04).
IKOMA, MIKIO., OOSHIMA, MASAYUKI., TANIDA, TAKAHIRO., et al., (2009), “Using a Validation Model to Measure the Agility of Software Development in aLarge Software Development Organization”, ICSE’09, May 16-24, Vancouver, Canada.
IEEE 610. (1990) “IEEE Standard Glossary of Software Engineering Terminology”, IEEE Piscataway, NJ std 610.12.
IEEE Standard 829-1998 (1998) “Standard for Software Test Documentation”, IEEE Press.
ISO (2001). “Information Technology – Software Product Quality. Part 1: Quality Model”, ISO/IEC 9126-1:2001, International Organization for Standardization.
JALALI, SAMIREH. WOHLIN, CLAES. (2010) “Agile Practices in Global Software Engineering – A Systematic Map”, In: 2010 International Conference on Global Software Engineering.
JALOTE, P. et al. (2004) “Timeboxing: a process model for iterative software development”, The Journal of Systems and Software n. 70, p. 117-127
JALOTE, PANKAJ. (2005) “An Integrated Approach to Software Engineering”, Springer Science + Business Media, Inc.
JIANG, LI. EBERLEIN, ARMIN. (2009), “An Analysis of the History of Classical Software Development and Agile Development”, In: IEEE International Conference on Systems, Man, and Cybernetics San Antonio, TX, USA - October
JURECZKO, MARIAN. (2008) "The Level of Agility in Testing Process in a Large Scale Financial Software Project", In: Software engineering techniques in progress, Oficyna Wydawnicza Politechniki Wroc?awskiej, 139-152.
KTATA, OUALID. LÉVESQUE, GHISLAIN. (2009), “Agile development: Issues and avenues requiring a substantial enhancement of the business perspective in large projects”, C3S2E-09, May 19-21, Montreal [QC, CANADA] Editor: B C. DESAI.
KITCHENHAM, B. (2004) “Procedures for Performing Systematic Reviews”, Joint Technical Report Software Engineering Group, Department of Computer Science Keele University, United King and Empirical Software Engineering, National ICT Australia Ltd, Australia.
223
KOEHNEMANN, HARRY. COATS, MARK. (2009), “Experiences Applying Agile Practices to Large Systems”, In: 2009 Agile Conference.
KONGSLI, V. (2006) “Towards Agile Security in Web Applications”, Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA’06, Portland, Oregon, USA.Cockburn, A., “Writing Effective Use Cases”. Addison-Wesley, ISBN 0-201-70225-8, 2001.
KRUCHTEN, P. (1996) “A Rational Development Process”, Crosstalk v. 9, n. 7 p. 11-16
KRUCHTEN, P. (2000) “The Rational Unified Process: an Introduction”, Addison-Wesley
Kujala, S. User involvement (2003) A review of the benefits and challenges. Behaviour and Information Technology, 22, 1, pp. 1--16.
LARMAN, CRAIG. (2003) “Agile and Iterative Development: A Managers Guide”, Addison Wesley
LARMAN, C. (2004) Agile and iterative development: A manager’s guide. Boston, MA: Pearson Education.
LIANG, W. FU, X. LI, Z. XIAO, R. HU, J. (2005) “Research and Realization of Software Testing Model Based on CSCW”, Proceedings of the 9th International Conference on Computer Supported Cooperative Work in Design, May 24-26, 2005, Coventry, UK.
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.
LITTLE, TODD. (2005) “Context-Adaptive Agility: Managing Complexity and Uncertainty”, IEEE Software, May/June.
LUCCA, G.A.D. FASOLINO, A.R. (2006) “Testing Web-based applications: The state of the art and future trends”, Information and Software Technology, Vol. 48(12), pp. 1172 – 1186.
MCGREGOR, J. D. SYKES, D. A. (2001) “A practical guide to testing object-oriented software”, Addison-Wesley Longman Publishing Co., Inc., Boston, MA.
MCKINNEY, DAWN. DENTON, LEO F. (2005) "Affective Assessment of Team Skills in Agile CS1 Labs: The Good, the Bad, and the Ugly", SIGCSE '05, February 23-27, 2005, St. Louis, Missouri, USA.
MAFRA, S.N., BARCELOS, R.F., TRAVASSOS, G.H., “Aplicando uma Metodologia Baseada em Evidência na Definição de Novas Tecnologias de Software”, In: Proc. of the XX Simpósio Brasileiro de Engenharia de Software (SBES), Florianópolis, 2006.
224
MARTIN, ANGELA. BIDDLE, ROBERT. NOBLE, JAMES. (2009) "XP Customer Practices: A Grounded Theory", 2009 Agile Conference.
MARTIN, R.C. (1998), “RUP vs. XP”, preliminary chapter of “Object Oriented Analysis and Design with Applications”, 2d. ed., Grady Booch, Robert C, Martin, James Newkirk, Addison Wesley Longman, Inc. available at http://www.objectmentor.com/resources/articles/RUPvsXP.pdf, accessed in 12.11.2008.
MARTIN, R.C. (2002) “UML for Java Programmers”, Prentice Hall, Englewood Cliffs, New Jersey.
MATIJASEVIC, BORIS. RONCEVIC, HRVOJE. OREL, OGNJEN. (2007) “Agile Software Development Supporting Higher Education Reform”, ITI 2007. 29th International Conference on Information Technology Interfaces, p. 375-380.
MAURER, FRANK. MARTEL, SEBASTIEN. (2002) "Extreme Programming Rapid Development for Web-Based Applications", IEEE Internet Computing, January - February.
MESO, PETER. JAIN, RADHIKA. (2006) “Contemporary practices in systems development. Agile Software Development: adaptive systems principles and best practices”, Information Systems Management, summer.
MIKULĖNAS, G. BUTLERIS, R. (2010) “An Approach for Constructing Evaluation Model of Suitability Assessment of Agile Methods using Analytic Hierarchy Process”, Electronics and Electrical Engineering, Kaunas: Technologija, no. 10(106), p. 99–104.
MILLER, GRANVILLE G. (2001) “The Characteristics of Agile Software Processes”, Proceedings of the 39th Int’l Conf. and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS’01).
MILLS, DAVID. SHERRELL, LINDA. BOYDSTUN, JEFF. WEI, GUOQING. (2005) "Experiences Using Agile Software Development for a Marketing Simulation", Dept. of Comput. Sci., Memphis Univ., TN USA.
MNKANDLA, E. DWOLATZKY, B. (2007) “Agile Methodologies Selection Toolbox”, International Conference on Software Engineering Advances, ICSEA 2007, p. 72-77.
MNKANDLA, E. (2008) A Selection Framework For Agile Methodology Practices: A Family of Methodologies Approach, PhD Thesis, University of the Witwatersrand, Johannesburg, South Africa.
NAIK, K. TRIPATHY, P. (2008) “Software Testing and Quality Assurance – Theory and Practice”, John Wiley & Sons, Inc., Hoboken, New Jersey
NOOR, M. A. RABISER, RICK. GRUNBACHER, PAUL. (2008) Agile product line planning: A collaborative approach and a case study. Journal of Systems and Software 81, 868—882.
225
O’REILLY, T. (1999) “Lessons from Open Source Software Development”, Communications of the ACM, Vol 42 (n. 4) 32-37
PAIGE, RICHARD F. BROOKE, PHILLIP J. (2005) “Agile Formal Method Engineering”, J. Romijn, G. Smith, and J. van de Pol (Eds.): IFM 2005, LNCS 3771, pp. 109–128.
PAI, M. MCCULLOCH, M. GORMAN, J.D. et al. (2004) “Systematic Reviews and meta-analyses: An illustrated, step-by-step guide”, The National Medical Journal of India, vol. 17, n.2.
PALMER, S.R. FELSING, J.M. (2002) “A Practical Guide to Feature-Driven Development”, Prentice Hall, Upper Saddle River, NJ.
PAULK, MARK C. (2001) "Extreme Programming from a CMM Perspective", IEEE Software, November/December.
POPPENDIECK, M. POPPENDIECK, T. (2003) “Lean Software Development: An Agile Toolkit”, Addison Wesley.
POPPENDIECK, M. POPPENDIECK, T. (2006) “Implementing Lean Software Development From Concept to Cash”, Addison Wesley Professional.
PRESSMAN, ROGER S. (2006) “Engenharia de Software”, 6. ed. São Paulo: McGraw-Hill Interamericana do Brasil.
QUMER, A. HENDERSON-SELLERS, B. (2008) An evaluation of the degree of agility in six agile methods and its applicability for method engineering. Information and Software Technology, n.50, pp 280-295.
QUMER, A. HENDERSON-SELLERS, B. (2008a): A framework to support the evaluation, adoption and improvement of agile methods in practice. The Journal of Systems and Software, 81, pp.1899—1919.
RAMACHANDRAN, VINAY. SHUKLA, ANUJA. (2002) "Circle of Life, Spiral of Death: Are XP Teams Following the Essential Practices?", Dept. of Comput. Sci., North Carolina State Univ., Raleigh NC USA
RÉPÁSI, TIBOR. (2009) “Software Testing – State of the Art and Current Research Challenges”, In: 5th International Symposium on Applied Computational Intelligence and Informatics, May 28–29, 2009 – Timişoara, Romania.
RICO, DAVID F. (2008) Effects of Agile Methods on Website Quality for Electronic Commerce. In: 41st Hawaii International Conference on System Sciences.
RICO, D. F. (2011) "Survey of Organizational Culture and Psychological Empowerment", disponível em http://FreeOnlineSurveys.com/rendersurvey.asp?sid=157umiwjd300zi4837206, acessado em 15 de janeiro de 2011.
RICO, D. F. (2011a) "Project Management Training and Project Performance", disponível em
226
http://freeonlinesurveys.com/rendersurvey.asp?sid=44j3657vnh3ycpt844600, acessado em 15 de janeiro de 2011.
SAATY, T. L. (2000), “The Fundamentals of Decision Making and Priority Theory with the Analytic Hierarchy Process”, RWS Publications.
SALTON, G. (1979) “Mathematics and Information Retrieval”, Journal of Documentation, v. 35, n. 1, p. 1-29.
SANTA ISABEL, S. L. (2011) "Seleção de Abordagens de Teste para Aplicações Web", Dissertação de M.Sc., COPPE/UFRJ, Rio de Janeiro, Julho.
SATO, D. BASSI, D. BRAVO, M. GOLDMAN, A. KON, F. (2006) “Experiences Tracking Agile Projects: an Empirical Study”, Journal of the Brazilian Computer Society, v. 12, n. 3, Dec.
SCHWABER, K. BEEDLE, M. (2002), “Agile Software Development with Scrum”, Upper Saddle River, NJ, Prentice-Hall.
SEI, (2008) “Software Engineering Institute - Capability Maturity Model for Software”, available at http://www.sei.cmu.edu/cmm/, accessed in 2008 December, 11.
SHARMA, S. SUGUMARAM, V. RAJAGOPALAN, B. (2002) “A framework for creating hybrid-open source software communities. Information Systems Journal, v. 12, n. 1, p. 7-25.
SHARP, HELEN. ROBINSON, HUGH. PETRE, MARIAN. (2009), “The role of physical artefacts in agile software development: Two complementary perspectives”, Interacting with Computers v. 21 pp. 108–116.
SOMMERVILLE, IAN. (2007) “Engenharia de Software”, 8. ed. São Paulo: Pearson Education do Brasil.
SPINOLA, R. O. DIAS-NETO, A. C.TRAVASSOS, G. H.(2008) "Abordagem para Desenvolver Tecnologia de Software com Apoio de Estudos Secundários e Primário", In: Experimental Software Engineering Latin American Workshop (ESELAW), Salvador, Novembro.
SPINOLA, R.O., TRAVASSOS, G.H. (2008). "Arcabouço para Apoiar a Definição e aGarantia de Qualidade de Requisitos de Ubiqüidade em Projetos de Software".In: II Workshop on Pervasive and Ubiquitous Computing, 2008, Campo Grande,Brasil.
SRINIVASAN, JAYAKANTH., LUNDQVIST, KRISTINA. (2009), “Using Agile Methods in Software Product Development: A Case Study”, In: Sixth International Conference on Information Technology: New Generations.
STAPLETON, J. (1997), “Dynamic Systems Development Method – The method in practice”, Addison-Wesley.
227
STEINDL, C. (2005) From agile software development to agile businesses. In: 31st EUROMICRO Conference on Software Engineering and Advanced Applications.
STOLBERG, SEAN. (2009) "Enabling Agile Testing Through Continuous Integration", 2009 Agile Conference.
SVENSSON, HARALD. HOST, MARTIN. (2005) "Introducing an Agile Process in a Software Maintenance and Evolution Organization", Proceedings of the Ninth European Conference on Software Maintenance and Reengineering (CSMR'05).
TAROMIRAD, MASOUMEH. RAMSIN, RAMAN. (2008) An Appraisal of Existing Evaluation Frameworks for Agile Methodologies. In: 15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems.
TAROMIRAD, MASOUMEH. RAMSIN, RAMAN. (2009) CEFAM: Comprehensive Evaluation Framework for Agile Methodologies. In: 32nd Annual IEEE Software Engineering Workshop.
TAYLOR, P.S. GREER, D. SAGE, P. et all. (2006) “Do Agile GSD Experience Reports Help the Practitioner?”, ACM Digital Library.
TRAVASSOS, G. H. ; SANTOS, P. S. M; MIAN, P. ; DIAS NETO, A.C. ; BIOLCHINI, J. (2008). An Environment to Support Large Scale Experimentation in Software Engineering. In: IEEE International Conference on Engineering of Complex Computer Systems, Belfast. Proceedings of ICECCS 2008.
VEGAS, S., JURISTO, N., BASILI, V. R., (2009), “Maturing Software Engineering Knowledge`through Classifications: A Case Study on Unit Testing Techniques”, Ieee Transactions on Software Engineering, VOL. 35, NO. 4, JULY/AUGUST.
VEJANDLA, PAVAN K. SHERRELL, LINDA B. (2009) "Why an AI Research Team Adopted XP Practices", Proceedings of the 47th Annual Southeast Regional Conference, ACM-SE 47, March 19-21, Clemson, SC, USA.
VLAANDEREN, KEVIN. JANSEN, SLINGER. BRINKKEMPER, SJAAK. JASPERS, ERIK., (2011) “The agile requirements refinery: Applying SCRUM principles to software product management”, Information and Software Technology, 53, 58–70.
WATKINS, JOHN. (2009) “Agile Testing – How to Succeed in an Extreme Testing Environment. New York: Cambridge University Press.
WILLIAMS, LAURIE. UPCHURCH, RICHARD. (2001) "Extreme Programming for Software Engineering Education?", 31st ASEE/IEEE Frontiers in Education Conference, October 10 - 13, 2001 Reno, NV.
228
WOHLIN, C., RUNESON, P., HOST, M., OHLSSON, M.C., REGNELL, B., WESSLÉN, A., “Experimentation in Software Engineering – An Introduction”, Kluwer Academic Publishers, ISBN 0-7923-8682-5, 2000.
XIAOHUA WANG. ZHI, WU. MING, ZHAO. (2008) "The Relationship between Developers and Customers in Agile Methodology", 2008 IEEE International Conference on Global Software Engineering.
XU, BIN. (2009) "Towards High Quality Software Development with Extreme Programming Methodology: Practices from Real Software Projects", College. of Computer Science & Information Engineering, Zhejiang Gongshang University, Hangzhou China.
ZHOU, YINGHUA. (2009) "UniX Process, Merging Unified Process and Extreme Programming to Benefit Software Development Practice", 2009 First International Workshop on Education Technology and Computer Science.
229
Apêndice A Documentos Considerados na Revisão Sistemática de Literatura para Identificar
Características de Agilidade
A.1 Artigos obtidos na primeira execução do protocolo, em
Nov-Dez/2006
Ord Autor(es) Título Fonte Ano
01
Abrahamsson, P.; Warsta, J.; Siponen, M.T. & Ronkainen, J.
New directions on agile methods: a comparative analysis
IEEE Computer Society, pp. 244--254 2003
02Boehm, B. &Turner, R.
Balancing agility and discipline: Evaluating and integrating agile and plan-driven methods
Institute of Electrical and Electronics Engineers Computer Society, Piscataway, NJ 08855-1331, UnitedStates, 26, 718-719 2004
03Meso, Peter. Jain, Radhika
Contemporary practices in systems development. Agile Software Development: adaptive systems principles and best practices
Information Systems Management, summer 2006
04
Holmstrom, Helena. Fitzgerald, Brian. et al.
Contemporary practices in systemsdevelopment. Agile Practices Reduce distance in Global Software Development
Information Systems Management, summer. 2006
05Miller, Granville G.
The Characteristics of Agile Software Processes
Proceedings of the 39th Int’l Conf. and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS’01). 2001
06 Aoyama, Mikio. Agile Software Process and Its Experience
Proceedings ofthe 1998 International Conference on Software Engineering, p. 3-12. 1998
07
Coram, Michael. Bohner, Shawn.
The Impact of Agile Methods on SoftwareProject Management
Proceedings of the 12th IEEE International Conferenceand Workshops on the Engineering of Computer-Based Systems (ECBS’05) 2005
08
Hansson, C. Dittrich, Y. Gustafsson, B. Zarnak, S.
How agile are industrialsoftware development practices?
The Journal of Systems and Software 79,1295–1311. 2006
09 Cockburn, A.Agile Software Development Joins the ‘Would be’ Crowd
Cutter IT Journal, v.15, n.2 2002
230
Ord Autor(es) Título Fonte Ano
10
Abrahamsson, P. Salo, O. Ronkainen, J. Warsta, J.
Agile Software Development Methods. Review and Analysis.
Espoo. VTT Publications 478 2002
11Lindvall, M. Basili, V. et al. Empirical Findings in Agile Methods.
Extreme Programming and Agile Methods –SP/Agile Universe, pp. 197--207 2002
A.2 Artigos obtidos na quarta execução do protocolo, em
Jan/2010
Ord Autor(es) Título Fonte Ano
12
Taromirad, Masoumeh. Ramsin, Raman.
CEFAM: Comprehensive Evaluation Framework for Agile Methodologies.
32nd Annual IEEE Software Engineering Workshop 2009
13 Rico, David F.Effects of Agile Methods on Website Quality for Electronic Commerce.
41st Hawaii International Conference on System Sciences 2008
14
Qumer, A. Henderson-Sellers, B.
A framework to support the evaluation, adoption and improvement of agile methods in practice.
The Journal of Systems and Software, 81, pp.1899--1919 2008
231
Apêndice B Documentos Considerados na Revisão Sistemática de Literatura para Identificar Práticas Ágeis
Ord Autor(es) Título Fonte Ano
01
Koehnemann, Harry. Coats, Mark.
Experiences Applying Agile Practices to Large Systems 2009 Agile Conference. 2009
02
Cohen, D. Lindvall, M. Costa, P. An Introduction to Agile Methods
Advances in Computers, Advances in Software Engineering, vol. 62, M. V. Zelkowitz, Ed. Amsterdam: Elsevier. 2004
03
Abrahamsson, P. Salo, O. Ronkainen, J. Warsta, J.
Agile Software Development Methods. Review and Analysis
Espoo. VTT Publications 478. 2002
04
Fruhling, Ann. De Vreede, Gert-Jan.
Field Experiences with eXtremeProgramming: Developing an Emergency Response System
Journal of Management Information Systems / Spring Vol. 22, No. 4. pp. 39-68. 2006
05
Paige, Richard F. Brooke, Phillip J. Agile Formal Method Engineering
J. Romijn, G. Smith, and J. van de Pol (Eds.): IFM 2005, LNCS 3771, pp. 109–128. 2005
06Jureczko, Marian.
The Level of Agility in Testing Process in a Large Scale Financial Software Project
Software engineering techniques in progress, Oficyna Wydawnicza Politechniki Wroc?awskiej, 139-152. 2008
07 Xu, Bin.
Towards High Quality Software Development with Extreme Programming Methodology: Practices from Real Software Projects
College of Computer Science & Information Engineering, Zhejiang Gongshang University, Hangzhou China. 2009
08 Stolberg, Sean.Enabling Agile Testing Through Continuous Integration 2009 Agile Conference. 2009
09
Martin, Angela. Biddle, Robert. Noble, James.
XP Customer Practices: A Grounded Theory 2009 Agile Conference. 2009
10 Zhou, Yinghua.
UniX Process, Merging Unified Process and Extreme Programming to Benefit Software Development Practice
2009 First International Workshop on Education Technology and Computer Science. 2009
11
Cannizzo, Fabrizio. Marcionetti, Gabriela. Moser, Paul.
The Toolbox Of A Successful Software Craftsman
15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems. 2008
12
Huo, Ming. Verner, June. Zhu, Liming. Ali Babar, Muhammad Software Quality and Agile Methods
Proceedings of the 28th Annual International Computer Software and Applications Conference (COMPSAC'04). 2004
232
Ord Autor(es) Título Fonte Ano
13
Maurer, Frank. Martel, Sebastien.
Extreme Programming Rapid Development for Web-Based Applications
IEEE Internet Computing, January - February. 2002
14 Paulk, Mark C.Extreme Programming from a CMM
Perspective IEEE Software, November/December. 2001
15
Vejandla, Pavan K. Sherrell, Linda B.
Why an AI Research Team Adopted XP Practices
Proceedings of the 47th Annual Southeast Regional Conference, ACM-SE 47, March 19-21, Clemson, SC, USA. 2009
16
Concas, Giulio. Francesco, Marco Di. Marchesi, Michele. Quaresima, Roberta. Pinna, Sandro.
Study of the Evolution of an Agile Project Featuring a Web Application Using Software Metrics
A. Jedlitschka and O. Salo (Eds.): PROFES 2008, LNCS 5089, pp. 386-399 2008
17Hazzan, O. Tomayko, J.
The Reflective Practitioner Perspective in eXtreme Programming
Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2753, 51-61. 2003
18
Xiaohua?Wang. Zhi, Wu. Ming, Zhao.
"The Relationship between Developers and Customers in Agile Methodology
2008 IEEE International Conference on GlobalSoftware Engineering. 2008
19
Aiello, G. Alessi, M. Bruccoleri, M. D'Onofrio C. Vella, G.
An Agile methodology for Manufacturing Control Systems development
Engisud S.p.a., Palermo, Italy. 2007
20
Svensson, Harald. H¨ost, Martin.
Introducing an Agile Process in a Software Maintenance and Evolution Organization
Proceedings of the Ninth European Conference on Software Maintenance and Reengineering (CSMR'05). 2005
21
Mills, David. Sherrell, Linda. Boydstun, Jeff. Wei, Guoqing.
Experiences Using Agile Software Development for a Marketing Simulation
Dept. of Comput. Sci., Memphis Univ., TN USA. 2005
22
McKinney, Dawn. Denton, Leo F.
Affective Assessment of Team Skills in Agile CS1 Labs: The Good, the Bad, and the Ugly
SIGCSE '05, February 23-27, 2005, St. Louis, Missouri, USA. 2005
23
Ramachandran, Vinay. Shukla, Anuja.
Circle of Life, Spiral of Death: Are XP Teams Following the Essential Practices?
Dept. of Comput. Sci., North Carolina State Univ., Raleigh NC USA 2002
24
Williams, Laurie. Upchurch, Richard.
Extreme Programming for Software Engineering Education?
31st ASEE/IEEE Frontiers in Education Conference, October 10 - 13, 2001 Reno, NV. 2001
233
Apêndice C Instrumentação do Estudo para Avaliação de Características e Práticas Ágeis
C.1 Definição das Telas da Instrumentação
C.1.1 Tela de Login
Segue o conteúdo de cada bloco da tela de login.
Block 0Survey on Characteristics of Agility in Software Processes
Block 1
This Survey is being accomplished by the Experimental Software Engineering Group at COPPE – Federal University of Rio de Janeiro. It aims at validating characteristics of agility for software processes in general. Also it aims at validating software practices regarding agile approaches for a software process.The purpose is not to analyse individual answers. So the analysis will be done by grouping. The time estimated to fill out the survey is of around 10 minutes. Your contribution is very important for our research.The execution of this survey can not be resumed, so if you started, please execute it until ending. It includes a total of 5 steps: subject characterization; pertinence of the characteristics of agility; relevance of the characteristics of agility; pertinence of the software practices and relevance of the software practices.
Please do not use the browser’s Back and Forward buttons. Use only the links available at the survey’s page. Thanks.
José Fortuna Abrantes – DSc Candidate – jfa@ cos.ufrj.brGuilherme Horta Travassos – Professor at COPPE/UFRJ – [email protected]
Block 2Log in form: fields Login, Password; button Login. Block 3Empty
C.1.2 Termo de Consentimento e Caracterização do Participante
Segue o conteúdo de cada bloco da tela do termo de consentimento e caracterização do participante.
Block 0Survey on Characteristics of Agility in Software Processes
234
Block 1
1- Subject Characterization 2- Pertinence of the Characteristics3- Relevance of the Characteristics 4- Pertinence of the Practices 5- Relevance of the Practices
Block 2Fill all fields accordingly to your personal information(* required fields. Email is required for access control only)Name* EmailAffiliationCountry* Higher Academic Degree: (Undergraduation, Specialization, Master Degree,PhD/DSc)* Number of papers published on Agile Processes or Agile Methods: (quantity)* Experience Level on Agile Approaches Usage in Software Projects: (Low, Medium, High, Very High)* Estimated number of software projects using Agile Approaches you haveparticipated in: (quantity)* I agree to participate in this survey (Yes, No)
Block 3Button (Start the Survey)
c.1.3 Identificação da Pertinência das Características de Agilidade
Segue o conteúdo de cada bloco da tela de identificação da pertinência das características de agilidade.
Block 0Survey on Characteristics of Agility in Software Processes
Block 11- Subject Characterization 2- Pertinence of the Characteristics3- Relevance of the Characteristics 4- Pertinence of the Practices 5- Relevance of the Practices
Block 2Step 2: Identification of the Pertinence of the Characteristics of Agility
How to proceed: for each characteristic, inform whether you think it is pertinent to characterize agility in software processes.(Move the mouse over the name of the characteristic for its complete description)
Agility Characteristics Table (include all listed in appendix 2.1)
Characteristic of Agility Is it Pertinent ?
235
“Being Collaborative” O Yes O No“Being Cooperative” O Yes O No“Being Incremental” O Yes O NoAdaptability O Yes O NoAuto-organization O Yes O NoBeing Iterative O Yes O No
If you think there are other pertinent characteristics other than those presented in the table above, you can fill the table bellow, including up to 5 new agility features in software processes, one characteristic per row:
Additional Characteristics of Agility
Block 3Message: If you finished this step you can proceed to Button (Next Step)
C.1.4 Definição do Nível de Relevância para as Características de Agilidade
Segue o conteúdo de cada bloco da tela de definição do nível de relevância para as características de agilidade.
Block 0Survey on Characteristics of Agility in Software Processes
Block 11- Subject Characterization 2- Pertinence of the Characteristics3- Relevance of the Characteristics 4- Pertinence of the Practices 5- Relevance of the Practices
Block 2Step 3: Definition of the Relevance Level for the Characteristics of Agility
How to proceed: for each characteristic, define its relevance level regarding agility in software processes.(Move the mouse over the name of the characteristic for its complete description)You may compare this step with the following scenario: a car has many features (e.g.: power, fuel consumption, number of passengers, optional items, max speed reached, acceleration, comfort level, among others). Which characteristics do you consider more relevant when selecting a car to buy?
The options are:D- No relevant (without relevance) Lowest level of relevance and it means the characteristic which would not have any influence in the characterization of a software process as being agile. The agility of a software process would not be
236
affected if the said characteristic were absent in the software process, independently from particular scenarios or development environments.C- Little relevant (insignificant) Indicates that the characteristic would not affect significantly or has a small influence on the characterization of a software process as being agile. The absence of the characteristic would not seriously compromise the agility of a software process in all or in the majority of scenarios or development environments.B- Highly relevant (very relevant) Indicates that the characteristic has strong influence on the characterization of a software process as being agile. The absence of the characteristic would compromise the agility of a software process in all or in most scenarios or development environments.A- Absolutely relevant: Indicates that the characteristic is vital or imperative in characterizing a software process as being agile. The absence of the characteristic would prevent the characterization of a software process as an agile one.
Table of Characteristics (include all considered as pertinent, as well as any characteristic added by the subject in the previous step)
Characteristic of Agility Relevance Level“Being Collaborative” O D O C O B O A“Being Cooperative” O D O C O B O A“Being Incremental” O D O C O B O AAdaptability O D O C O B O AAuto-organization O D O C O B O ABeing Iterative O D O C O B O A
Block 3Message: If you finished this step you can proceed to Button (Next Step)
C.1.5 Identificação da Pertinência das Práticas Ágeis
Segue o conteúdo de cada bloco da tela de identificação da pertinência das práticas ágeis.
Block 0Survey on Characteristics of Agility in Software Processes
Block 11- Subject Characterization 2- Pertinence of the Characteristics3- Relevance of the Characteristics 4- Pertinence of the Practices5- Relevance of the Practices
Block 2 Step 4: Identification of the Pertinence in Software Practices
How to proceed: for each practice, state whether you think it is pertinent to an agile approach for software processes.(Move the mouse over the name of the practice for its complete description)
237
Table of Practices (include all listed in appendix 2)Practice Is it Pertinent ?
Adopt a holistic diversity strategy O Yes O NoAllow for changes reversibility O Yes O NoAutomated acceptance testing O Yes O NoAutomated unit tests O Yes O NoCode and tests O Yes O NoConfiguration management O Yes O No
If you think there are other pertinent software practices other than those presented in the table above, you can fill the table bellow with up to 5 new software practices regarding an agile approach for software processes, one practice per field:
Additional Software Practices
Block 3Message: If you finished this step you can proceed to Button (Next Step)
C.1.6 Definição do Nível de Relevância para as Práticas Ágeis
Segue o conteúdo de cada bloco da tela de definição do nível de relevância para as práticas ágeis.
Block 0Survey on Characteristics of Agility in Software Processes
Block 11- Subject Characterization 2- Pertinence of the Characteristics3- Relevance of the Characteristics 4- Pertinence of the Practices 5- Relevance of the Practices
Block 2Step 3: Definition of the Relevance Level for the Software Practices
How to proceed: for each practice, define its relevance level regarding adoption of an agile approach for software processes.(Move the mouse over the name of the practice for its complete description)You may compare this step with the following scenario: using a car entails many practices (e.g.: respecting speed limits, using seat belts, not answering cell phones while driving, maintaining fuel tank level above half, calibrating tyres on a weekly basis, amongst others). Which practices do you consider more relevant when using a car and considering a safety approach?
The options are:
238
D- No relevant (without relevance) Lowest level of relevance, it means thepractice would not have any influence on the adoption of an agile approach. The agile approach of a software process would not be affected if the referenced practice were absent in the software process, independently of particular scenarios or development environments.
C- Little relevant (insignificant) Indicates that the practice would not significantly affect it, or that it has a small influence on the adoption of an agile approach for a software process. The absence of the practice would not seriously compromise the agile approach for the software process in all or on the majority of scenarios or development environments.
B- Highly relevant (very relevant) Indicates the practice has strong or considerable influence on the adoption of an agile approach. The absence of the practice would compromise the agile approach for a software process in all or on the majority of scenarios or development environments.
A- Absolutely relevant Indicates the practice is vital or imperative for the adoption of an agile approach. The absence of the practice would prevent the agile approach for a software process.
Table of Practices (include all considered as pertinent, as well as any practice added by the subject in the previous step)
Software Practice Relevance LevelAdopt a holistic diversity strategy O D O C O B O AAllow for changes reversibility O D O C O B O AAutomated acceptance testing O D O C O B O AAutomated unit tests O D O C O B O ACode and tests O D O C O B O AConfiguration management O D O C O B O A
Block 3Button (Finish Survey)
C.1.7 Tela de Agradecimento
Segue o conteúdo de cada bloco da tela de agradecimentos.
Block 0Survey on Characteristics of Agility in Software Processes
Block 1Survey Finished
Block 2We would like to thank you for your collaboration !!!
Results of this study will be used only for our research regarding agility in software processes. As soon as we have completed our technical report we will
239
advise all participants. If you would like to receive more information or are interested to help improve this research, please mail us.
José Fortuna Abrantes – DSc Candidate – [email protected] Horta Travassos – Professor at COPPE/UFRJ – [email protected]
If you deem it opportune, please place your comments here:Your Comments:
………………….
Block 3Button (Close the Survey)
C.2 Apresentação das Telas da Instrumentação
O instrumento associado com a aplicação da pesquisa de opinião disponibilizado na web inclui uma série de 8 telas que passam a ser descritas a seguir. Na Figura C-1 é mostrada a tela de login, que contem uma explicação adicional e resumida sobre a pesquisa de opinião, além do que foi enviado para o participante por email.
Figura C-1 – Pesquisa de Opinião – Tela de Login
240
Na Figura C-2 é mostrada a tela de caracterização do participante, com informações que serão utilizadas na apuração dos resultados finais.
Figura C-2 – Pesquisa de Opinião – Tela de Caracterização
Na Figura C-3 é mostrada a tela de registro da pertinência das características de agilidade. Rolando-se a tela pode ser acessada uma tabela onde o participante pode incluir até 5 novas características diferentes das apresentadas no instrumento.
Figura C-3 – Pesquisa de Opinião – Tela de Pertinência das Características
Na Figura C-4 é mostrada a tela de registro da relevância das características de agilidade, incluindo as características acrescentadas pelo participante na tela anterior.
241
Figura C-4 – Pesquisa de Opinião – Tela de Relevância das Características
Na Figura C-5 é mostrada a tela de registro da pertinência das práticas de software. Rolando-se a tela pode ser acessada uma tabela onde o participante pode incluir até 5 novas práticas diferentes das originalmente apresentadas no instrumento.
Figura C-5 – Pesquisa de Opinião – Tela de Pertinência das Práticas
Na Figura C-6 é mostrada a tela de registro da relevância das práticas de software, incluindo as práticas acrescentadas pelo participante na tela anterior.
242
Figura C-6 – Pesquisa de Opinião – Tela de Relevância das Práticas
Na Figura C-7 é mostrada a tela de agradecimentos, onde o participante, se desejar, pode incluir livremente um comentário sobre a pesquisa.
Figura C-7 – Pesquisa de Opinião – Tela de Agradecimento
Na Figura C-8 é mostrada a última tela do instrumento, a tela de finalização.
243
Figura C-8 – Pesquisa de Opinião – Tela de Finalização
Para as práticas e para as características, nas telas de pertinência e de relevância
(Figuras 3,4,5 e 6), passando-se o mouse sobre os respectivos ícones (azuis) em cada linha da tabela, é mostrada uma descrição detalhada para cada característica de agilidade e para cada prática de software.
Para as práticas e para as características, nas telas de relevância (Figuras 4 e 6),
passando-se o mouse sobre o ícone (vermelho) no cabeçalho da tabela de relevância, é mostrada uma descrição detalhada dos níveis de relevância para as práticas de software e para as características de agilidade.
244
Apêndice D Instrumentação da Revisão por Pares
D.1 Mensagem 1 – Convite para Participar da Revisão
Prezados Pesquisador/Desenvolvedor,Estamos desenvolvendo pesquisas no contexto de agilidade em processos de software. Em nosso trabalho de pesquisa, identificamos características de agilidade e práticas ágeis. Tais características e práticas foram avaliadas e agrupadas. Posteriormente identificamos relações entre elas, associando cada prática ágil com cada característica de agilidade, segundo um critério estabelecido.
Neste sentido, nos dirigimos a você para gentilmente pedir sua colaboração no sentido de nos ajudar a revisar estes relacionamentos e verificar se eles fazem sentido de acordo com o seu conhecimento e experiência. O material a ser trabalhado envolve dois arquivos: um deles com 3 a 4 páginas contém descrições sobre as práticas, características e os relacionamentos que foram identificados por nós; o outro contém uma página (planilha para as respostas).
Se concordar em fazer esta revisão, pedimos que nos informe, após o que lhe enviaremos o material necessário para realizar a revisão.
Após nos enviar o resultado desta revisão, e dependendo de seu interesse, poderemos enviar uma segunda etapa do trabalho, em volume menor e mais simples de revisar, que trata da relação das práticas de agilidade e sua possível relação com processos de teste de software, o que pode ser de seu interesse, considerando os processos de teste de software para seus projetos.
Antecipadamente agradecemos sua atenção e aguardamos sua resposta.
Guilherme Horta Travasssos – [email protected]é Fortuna Abrantes – [email protected]
D.2 Mensagem 2 – Encaminhamento de Instruções e Instrumentação sobre a Revisão dos Mapeamentos entre Práticas Ágeis e Características de AgilidadePrezado Pesquisador/Desenvolvedor,Obrigado por concordar em participar do trabalho de revisão que nos ajudará a compreender um pouco mais sobre a percepção que se tem sobre agilidade em processos de software. Solicitamos gentilmente que revise os relacionamentos entre as práticas ágeis e características de agilidade que foram inicialmente estabelecidos por nós. Para isso, use seu conhecimento e experiência na área para identificar se estes relacionamentos são adequados ou não. Além disso, seria muito importante se você pudesse nos indicar relacionamentos que você entende existir, porém nós não conseguimos identificar.O material a ser utilizado para a revisão com as respectivas instruções está sendo enviado juntamente com esta mensagem. São 2 arquivos anexos. O arquivo “Revisão PxC.xls” contem abas para capturar a caracterização do participante, o termo de consentimento e as instruções para realizar a revisão e registrar seus resultados; o segundo arquivo “Mapeamento PxC.pdf” contem as descrições das características de
245
agilidade, as descrições das práticas ágeis e os relacionamentos estabelecidos (ou não) entre as práticas ágeis e as características de agilidade que devem ser revistos por você.
Ao terminar, pedimos nos enviar o arquivo “Revisão PxC.xls” devidamente preenchido com a caracterização, o termo de consentimento e os resultados da revisão para o email [email protected]. De acordo com os procedimentos ético-científicos, seu anonimato será garantido no contexto dos dados desta pesquisa.
Conforme mencionado em nossa primeira mensagem, após receber os resultados desta revisão, poderemos enviar, caso indicado na aba correspondente, um segundo conjunto de informações, em volume menor e mais simples de revisar, mas que poderá trazer benefícios para os processos de teste de software de seus projetos.
Em caso de dúvida favor entrar em contato.
Antecipadamente agradecemos sua atenção e colaboração.
Guilherme Horta Travasssos – [email protected]é Fortuna Abrantes – [email protected]
D.3 Mensagem 3 - Encaminhamento de Instruções e Instrumentação sobre a
Revisão dos Mapeamentos entre Práticas Ágeis e Atividades de Teste de Software
Prezado Pesquisador/Desenvolvedor,
Agradecemos novamente sua disponibilidade em nos ajudar. Estamos encaminhando
agora o material para a segunda etapa de revisão sobre práticas de agilidade e processos
de teste de software. Este material trata os relacionamentos entre práticas ágeis e
atividades de teste de software derivadas de processos genéricos de teste, baseados no
padrão IEEE, usualmente utilizado como base para decisão nas organizações.
Solicitamos sua colaboração no sentido de revisar os relacionamentos entre as práticas
ágeis e atividades de teste que estabelecemos de modo semelhante ao que foi realizado
por você para os relacionamentos entre práticas ágeis e características de agilidade.
O material a ser utilizado nesta revisão com as respectivas instruções se encontra nos 2
arquivos anexados a esta mensagem. O arquivo “Revisão PxA.xls” contem as instruções
para realizar a revisão e registrar seus resultados; o segundo arquivo “Mapeamento
PxA.pdf” contem as descrições das atividades de teste, as descrições das práticas ágeis e
os relacionamentos estabelecidos (ou não) entre as práticas ágeis e as atividades de teste
de software, objetos desta etapa da revisão.
246
Ao terminar, pedimos enviar o arquivo “Revisão PxA.xls” preenchido com os resultados
da revisão para o email [email protected] .
Em caso de dúvida favor entrar em contacto.
Agradecemos sua colaboração nesta revisão.
Guilherme Horta Travassos – [email protected]
José Fortuna Abrantes – [email protected]
D.4 Mensagem com Lembrete sobre a Revisão dos Mapeamentos entre Práticas Ágeis e Características de Agilidade
Prezado Pesquisador/Desenvolvedor,Somos gratos por sua disposição em nos ajudar. Desculpe-nos se estamos sendo inoportunos, mas gentilmente estamos relembrando, no caso de eventual esquecimento, nossa necessidade em receber o quanto antes, seu retorno sobre o material da revisão anteriormente encaminhada.
Aproveitamos esta oportunidade para mais uma vez expressar nossos agradecimentos pela sua colaboração.
Guilherme Horta Travassos – [email protected]é Fortuna Abrantes – [email protected]
D. 5 Instrumentação para o Grupo 1 – Características de Agilidade5.1- Descrições do significado de cada característica de agilidade
Característica Interpretação
Adaptabilidade Habilidade e capacidade de adaptar rapidamente o processo para atender e reagir a mudanças de última hora nos requisitos e/ou mudanças de ambiente, bem como atender e reagir a riscos ou situações não previstas.
Auto-organização As equipes definem as melhores maneiras de se trabalhar; elas são autônomas e podem se auto-organizar de acordo para completar os itens de trabalho.
Emergência Os processos, princípios e estruturas de trabalho são reconhecidos durante o processo de execução, não sendo definidos a priori; é permitido e aceito que tecnologias e requisitos surjam durante o ciclo de vida do produto.
Equipes pequenas Equipes pequenas, e pequeno número de equipes por projeto, são necessários para promover um ambiente colaborativo e requer menos planejamento para coordenar as atividades dos membros das equipes.
Incorporação de Retroalimentação (feedback)
As equipes devem ser capazes de receber e procurar continuamente por retroalimentação de modo mais freqüente e com mais rapidez.
247
Característica Interpretação
Leanness Esta característica está relacionada com a eliminação de perdas e com a habilidade de realizar mais trabalho com menos esforço; é uma característica de processos ágeis que requer o mínimo necessário de atividades para mitigar riscos e alcançar metas; todas as atividades que não são necessárias devem ser removidas do processo de desenvolvimento.
Modularidade Esta característica permite que um processo seja particionado em componentes chamados de atividades, tornando viável adicioná-los ou removê-los de um processo quando necessário.
Orientação a Pessoas Privilegiar pessoas em detrimento de processos e tecnologias; desenvolvedores são fortalecidos e encorajados a aumentar sua produtividade, qualidade e desempenho; comunicação e cooperação são fundamentais e necessárias; reuniões em pé e oficinas (workshops) de reflexão dão às pessoas a chance de expor suas preocupações.
Reflexão e Introspecção Acontecem reuniões no final de cada subprojeto ou iteração, nas quais cada membro da equipe pode discutir o que está sendo bem feito e o que precisa ser melhorado.
Ser Colaborativo Esta é uma atitude por parte dos membros da equipe de desenvolvimento, dentre os quais a comunicação é encorajada para disseminar informação e apoiar integração rápida de incrementos de software.
Ser Cooperativo Interação aberta e proximidade entre todos as partes interessadas(especialmente entre clientes e desenvolvedores); o cliente deve ser um elemento ativo no processo de desenvolvimento e deve prover retroalimentação (feedback) de modo regular e freqüente.
Ser Incremental Não tentar construir o sistema todo de uma só vez; o sistema deve ser particionado em incrementos (pequenas liberações com novas funcionalidades) desenvolvidos em ciclos rápidos e paralelos; quando o incremento estiver completo e testado, ele é integrado ao sistema.
Ser Iterativo Usar vários ciclos curtos guiados por funcionalidades do produto, nos quais certo conjunto de atividades é completado em poucas semanas; estes ciclos são repetidos muitas vezes pra refinar as entregas.
Testes Constantes Para prevenir a degradação da qualidade por causa de programas de liberações frequentes, um alto grau de ênfase é colocado no teste do produto ao longo de seu ciclo de vida; testes de integração devem ser automatizados com construções diárias (builds diárias) bem como a execução de testes de regressão para garantir que todas as funcionalidades operem adequadamente.
Time Boxing É o estabelecimento de limite ou fatias de tempo para cada iteração programada. Grandes esforços de desenvolvimento são divididos em múltiplas entregas desenvolvidas de modo incremental e concorrente, de maneira previsível.
Transparência O método ou processo ágil deve ser fácil de aprender e de ser modificado, além de estar adequadamente documentado.
5.2- Descrições do significado de cada prática ágil do grupo 1
Prática Descrição ConsolidadaBacklogde produto
Esta prática inclui tarefas para criação de uma lista de backlog de produto, e seu controle durante o processo de inserção, remoção, atualização e priorização dos itens da lista. A lista de backlog de produto define tudo o que é necessário para o produto final baseado no conhecimento atual que dele se tem. O backlog de produto define o trabalho a ser feito no projeto, incluindo uma priorização e constante atualização da lista de
248
Prática Descrição Consolidadarequisitos para o sistema sendo construído ou melhorado. Itens de backlog podem incluir, por exemplo, funcionalidades, correção de erros, defeitos, requisições de melhorias, atualizações de tecnologia, etc. Questões que requeiram solução antes que outros itens de backlog sejam trabalhados também podem estar na lista.
Cliente presente
Em termos práticos, isso significa colocar o cliente fisicamente próximo aos desenvolvedores ou mover os desenvolvedores para próximo do cliente. Esta prática indica que o cliente deve fazer parte da equipe de desenvolvimento. Para esclarecer e validar requisitos e estabelecer prioridades, um representante do cliente trabalha junto da equipe todo o tempo. Assim o cliente pode responder a perguntas, resolver questões, estabelecer prioridades, fazer testes de aceitação e assegurar que o desenvolvimento tenha o progresso esperado. Quando surgem questionamentos, os programadores podem resolver imediatamente com o cliente, ao invés de tentar imaginar quais seriam suas preferências. Esta prática também leva o cliente a mudar mais prontamente os requisitos, ajudando a equipe a mudar o foco dos esforços de desenvolvimento para as necessidades mais prementes.
Design simples
A ênfase desta prática está em projetar a solução mais simples possível e que seja viável no momento. Complexidade desnecessária e código extra devem ser removidos assim que reconhecidos. Não se deve incluir aspectos adicionais aos artefatos sem uma boa justificativa para tal. A prática do design simples requer que a equipe não projete para satisfazer necessidades futuras, as quais os desenvolvedores não devem tentar prever. A abordagem de desenvolvimento mais efetiva em termos de custo deve focar em resolver os problemas de hoje ao invés de projetar para mudanças futuras que não se sabe se realmente ocorrerão. Deve-se trabalhar a solução mais simples que possa funcionar.
Proprie-dade coletiva do código
O repositório de código deve ser de livre acesso para todos os programadores e permitir mudanças sempre que necessário. Uma vez na base de código, qualquer membro da equipe tem a posse sobre todo código. Todos são encorajados a fazer mudanças no código, em qualquer parte e a qualquer tempo que sintam a necessidade de fazê-las, sem ter que pedir permissão para quem quer que seja. Esta prática pode remover o gargalo de software que normalmente está relacionada com a posse individual do código. Qualquer par de programadores que veja uma oportunidade de adicionar valor a qualquer parte do código pode fazê-lo a qualquer tempo. A propriedade coletiva do código, além de ajudar na melhoria do código, dá mais flexibilidade aos programadores para se ausentar em casos de necessidade ou para saírem de férias. A disponibilidade de drivers de teste automatizados faz com que os desenvolvedores tenham mais liberdade para modificar o código sem maiores receios de eventuais repercussões que possam causar. Ao poder examinar o código escrito por outros, os programadores podem refletir e considerar as razões que levaram os colegas a tomar determinadas decisões específicas, ou podem melhorar o entendimento de seu próprio código e de suas interfaces com as demais partes da codificação do software.
Refatora-ção
O software se deteriora com o tempo. Um projeto que inicialmente parece enxuto e/ou perfeito pode torna-se progressivamente sobrecarregado e/ou deteriorado a cada modificação nele introduzida. Quando o software tem uma documentação mínima, o código fonte deve permanecer simples e fácil de entender. A refatoração é uma técnica disciplinada para se reestruturar um corpo de código existente ou para constantemente melhorar sua inteligibilidade e manutenibilidade, bem como o seu projeto, alterando sua estrutura interna sem mudar seu comportamento externo nem a funcionalidade do sistema. O foco é obter código simples, limpo e não repetitivo, que pode ser modificado facilmente. A essência da prática é uma série de pequenas transformações que preservam comportamento. Pelo fato das transformações serem pequenas, a possibilidade de algo dar errado é também pequena, com o sistema permanecendo totalmente funcional após cada refatoração. Durante a refatoração os desenvolvedores reconstroem o código e isto já provê inspeção da sua funcionalidade. As diferentes formas de refatoração podem envolver a simplificação de declarações complexas, a abstração de soluções comuns para fins de reuso e a remoção de código duplicado. Esta prática reduz a probabilidade de geração de erros durante o desenvolvimento. Entretanto, a prática de refatoração é altamente dependente do conjunto de casos de teste de unidade automatizados. Quando o código é refatorado, ele deve ainda passar
249
Prática Descrição Consolidadapor todos os casos de teste de unidade armazenados. Se algum caso de teste falhar depois da refatoração, as devidas correções devem ser efetuadas.
5.3- Relacionamento das Práticas Ágeis com as Características de Agilidade
As associações entre as práticas ágeis e as características de agilidade pode ser feita observando-se um ou mais dos possíveis relacionamentos entre elas. Neste trabalho será adotado o relacionamento que indica se uma determinada prática pode ou não apoiar ou ajudar a alcançar determinada característica de agilidade, conforme proposto e utilizado no trabalho de Qumer e Henderson-Sellers (2008).
Neste trabalho, cada prática será individualmente analisada com relação a todo o conjunto de características de agilidade, buscando identificar e indicar se pode ou não haver o relacionamento da prática com cada uma das características. Em caso afirmativo será explicitado o raciocínio utilizado para embasar ou fundamentar o relacionamento. A análise se baseará nos componentes conceituais identificados nas descrições das práticas e das características de agilidade (registradas nos itens 1 e 2 acima). Pelo fato de as características de agilidade estarem em um nível de abstração mais alto, os relacionamentos entre elas e as práticas ágeis serão definidos através de uma análise criteriosa com base na interpretação dos textos que descrevem seus respectivos significados (itens 1 e 2 acima). Nas tabelas que se seguem, para cada prática, são inseridas apenas as características para as quais foi possível identificar um mapeamento com uma justificativa aceitável em termos de contribuição da prática para a característica.
Prática 1- Backlog de produto
CaracterísticaEmbasamento: o backlog de produto ...
Adaptabilidade mantido atualizado favorece a identificação de eventual necessidade de mudança.
Auto-organização atualizado pode ser mais um elemento para apoiar a identificação das melhores maneiras para se trabalhar.
Emergência pode ser um mecanismo para facilitar a aceitação de que requisitos emerjam.Leanness pode apoiar a eventual eliminação de recursos que não são necessários para
construção do produto, gerando economia, que é um valor percebido pelo cliente.
Reflexão e Introspecção
pode apoiar a identificação de eventuais necessidades de melhorias.
Ser Colaborativo pode apoiar a disseminação de informações sobre o trabalho a ser feito.Ser Cooperativo se apresenta como uma das oportunidades para interação entre as partes
interessadas.Ser Incremental pode apoiar o planejamento de incrementos ou pequenas liberações com novas
funcionalidades.Ser Iterativo pode ajudar no planejamento dos ciclos curtos a partir dos itens de backlog.
Não foi possível identificar o mapeamento da prática para as seguintes características: Equipes pequenas, Incorporação de Retroalimentação (feedback), Modularidade, Orientação a Pessoas, Testes Constantes, Time Boxing e Transparência.
Prática 2- Cliente presente
250
CaracterísticaEmbasamento: o cliente presente e fazendo parte da equipe ...
Adaptabilidade favorece a identificação mais rápida de necessidades de mudanças nos requisitos, alertando a equipe mais cedo para que possa reagir adequadamente a situações não previstas.
Emergência pode favorecer a emergência de requisitos durante o ciclo de vida do produto.
Incorporação de Retroalimentação (feedback)
facilita a retroalimentação mais frequente.
Ser Colaborativo pode favorecer a comunicação rápida entre os membros da equipe, já que é uma fonte comum de informações, inclusive de retroalimentação.
Ser Cooperativo tem possibilidade de estar mais próximo da equipe e de ser um elemento ativo no processo de desenvolvimento.
Ser Incremental pode apoiar o planejamento dos incrementos para o produto, inclusive com atualização freqüente das prioridades.
Ser Iterativo pode ajudar na programação dos ciclos curtos, bem como do que estará incluído neles.
Não foi possível identificar o mapeamento da prática para as seguintes características: Auto-organização, Equipes pequenas, Leanness, Modularidade, Orientação a Pessoas, Reflexão e Introspecção, Testes Constantes, Time Boxing e Transparência.
Prática 4- Design simples
CaracterísticaEmbasamento: o design simples (simplicidade nas soluções) ...
Adaptabilidade pode favorecer a adaptação para atender situações não previstas (mudanças nos requisitos, na equipe, no orçamento, nos fornecedores de recursos, dentre outras)
Emergência pode ajudar na incorporação de requisitos novos, na medida em que facilita a análise do que precisa ser modificado para atender o requisito emergente.
Leanness contribui significativamente para a eliminação de perdas.Orientação a Pessoas
representada nos artefatos construídos, favorece a comunicação, que é um elemento fundamental na interpretação desta característica.
Não foi possível identificar o mapeamento da prática para as seguintes características: Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing, Transparência, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Modularidade, Equipes pequenas, Incorporação de Retroalimentação (feedback) e Auto-organização.
Prática 10- Propriedade coletiva do código
CaracterísticaEmbasamento: a propriedade coletiva do código ...
Reflexão e Introspecção
permite o exame do código escrito por outros, fazendo com que os programadores adquiram melhor visão do produto como um todo, podendo apresentar contribuições mais significativas para melhorias.
Não foi possível identificar o mapeamento da prática para as seguintes características: Adaptabilidade, Auto-organização, Emergência, Equipes pequenas, Incorporação de Retroalimentação (feedback), Leanness, Modularidade, Orientação a Pessoas, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
Prática 11- Refatoração
CaracterísticaEmbasamento: a refatoração ...
Adaptabilidade foca no código simples, limpo e não repetitivo, que pode ser modificado facilmente quando a necessidade de mudança surgir.
251
Não foi possível identificar o mapeamento da prática para as seguintes características: Auto-organização, Emergência, Equipes pequenas, Incorporação de Retroalimentação (feedback), Leanness, Modularidade, Orientação a Pessoas, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
5.4 Guia Geral
Revisão de Relacionamentos entre Práticas Ágeis e Carcterísticas de Agilidade
Este arquivo contem 3 planilhas, sendo a primeira, este guia geral (0- Guia Geral);
Passos:
1- Preencher planilha de caracterizacão do participante e termo de consentimento (planilha 1- Caracteriz Consentimento)
2- Observar instruções para revisão e registrar resultados (planilha 2- Revisão)
5.5 Caracterização e Consentimento
Caracterização do Participante: (observe os comentários nas células, para preenchimento)
Nome:
Email:
Afiliação atual:
País:
Grau Acadêmico mais elevado:
Número de artigos publicados sobre abordagens ágeis:
Nível de experiência na utilização de abordagens ágeis em projetos de software:
Número estimado de projetos de software utilizando abordagens ágeis de que participou:
252
Termo de Consentimento: (observe os comentários nas últimas células, para preencher sua concordância)
Eu declaro que concordo em participar de estudos (revisões) conduzidospelos pesquisadores Prof. Guilherme Horta Travassos e doutorando José Fortuna Abrantes.
Toda informação coletada nestes estudos é confidencial, e meu nome não será identificado emmomento algum. Da mesma forma, me comprometo a manter sigilo das tarefas solicitadas edos documentos apresentados e que fazem parte das revisões.
Eu entendo que participo das revisões de livre e espontânea vontade com o único intuitode contribuir para o avanço e desenvolvimento de técnicas, ferramentas e processospara a Engenharia de Software.
Concorda em participar da revisão sobre práticas ágeis e características de agilidade?
Concorda em participar da segunda etapa desta pesquisa (praticas ágeis e processos de teste de software)?
5.6 Revisão
Revisão por Pares do Relacionamento entre Práticas Ágeis e Características de Agilidade
Instruções
1. No arquivo “Mapeamento PxC.pdf” estão registrados relacionamentos entre práticas ágeis e características de agilidade, juntamente com o embasamento ou justificativa para sua definição, bem como relacionamentos não definidos por não ter sido identificada uma justificativa aceitável para tal definição. No início do item 3 do arquivo (relacionamentos) está registrada a perspectiva com que as análises foram conduzidas para se chegar às definições dos relacionamentos. Como apoio, neste mesmo arquivo, estão as descrições dos significados de cada prática e de cada característica.
2. Pede-se que você analise os relacionamentos registrados e identifique apenas aqueles dos quais você discorda, considerando as mesmas perspectivas registradas no arquivo “Mapeamento PxC.pdf”. Você pode discordar: 1- de um relacionamento definido, 2- apenas da justificativa de um relacionamento definido ou ainda, 3- de um relacionamento não definido (o qual não foi identificado, mas você considera necessário e consegue identificar uma justificativa para que ele tivesse sido definido).
3. Pede-se que você registre no formulário abaixo, uma linha para cada discordância, identificando o tipo de discordância, a prática, a característica relacionada e a justificativa para sua discordância. Se necessário, inclua mais linhas.
4. Ao terminar pede-se o favor de enviar este arquivo com o resultado de sua revisão para o email [email protected]
AVALIADOR:
Discordância Prática Característica Comentário com a justificativa
253
Comentários das colunasDiscordância: Indicar,
1- discorda do relacionamento definido2- discorda apenas da justificativa do relacionamento definido3- discorda do relacionamento não definido
Prática: Inclua o nome da prática.Característica: Inclua o nome da característica
D.6 Instrumentação para o Grupo 2 – Características de Agilidade6.1- Descrições do significado de cada característica de agilidade
São as mesmas da seção D.5.1
6.2- Descrições do significado de cada prática ágil do grupo 2
Prática Descrição ConsolidadaDesenvol-vimento orientado a testes
Todo programador escreve casos de teste antes de escrever o código. Os testes devem ser escritos antes da implementação e conter o que for necessário para verificar se o código se comporta de acordo com os requisitos do usuário. O desenvolvedor ou testador deve escrever os casos de teste assim que os requisitos estiverem definidos. Além de escrever os testes de unidade antes da codificação, os desenvolvedores devem encorajar os usuários a escrever os testes de aceitação. Ao ser executado pela primeira vez, o caso de teste irá falhar, uma vez que o desenvolvimento do código que implementa a condição sendo testada ainda não foi gerado. Então, escreve-se código apenas o suficiente para o caso de teste passar, seguido de refatoração para remover duplicações e melhorar a legibilidade do código. Escrever drivers de teste antes da codificação força o desenvolvedor a pensar no problema antes da programação. Esta prática aplicada corretamente garante uma suíte de testes para fins de teste de regressão, além de prover documentação para o código implementado, servindo de casos de uso para este mesmo código. Deve-se ter o cliente escrevendo testes de aceitação, que podem se tornar casos de teste de um plano geral de testes para o sistema. Antes de o progarmador integrar o seu código à base de código, ele deve ter todos os seus próprios testes passando, além de todos aqueles testes já escritos e já incorporados à base, que também deverão passar. Isto assegura que o novo código sendo integrado para implementar uma nova funcionalidade não quebre o código de alguém que já havia sido incorporado à base de código.
Integra-ção contínua
Na integração contínua, os membros da equipe devem integrar seu trabalho frequentemente, toda vez que novas mudanças ou uma tarefa for completada, para revelar problemas de integração e detectar falhas de sistema o mais cedo possível. Cada pessoa deve fazer a integração pelo menos uma vez por dia. Isto garante que sempre esteja disponível uma versão executável do sistema, contendo todas as novas funcionalidades e modificações, podendo servir de baseline para o trabalho. Depois da integração, todos os testes devem passar, ou o novo código deve ser descartado. Os integrantes da equipe podem fazer a integração sempre que desejarem, a não ser em curtos períodos de tempo em que o código é congelado. Cada integração deve ser verificada imediatamente ou à noite através de uma build automática com execução de todos os testes de integração. Esta prática é um exemplo de uma técnica dinâmica de garantia de qualidade.
Jogo de planeja-mento
Juntos desenvolvedores e clientes atuam no jogo de planejamento no qual o cliente escolhe as histórias de usuário que incluem os requisitos mais importantes a serem incluídos em uma entrega curta e incremental. Cada incremento curto implementado é experimentado pelo cliente. As histórias remanescentes são reavaliadas em termos de requisitos e prioridades, sendo o jogo de planejamento jogado novamente para definir o
254
Prática Descrição Consolidadapróximo incremento a ser implementado. A meta do jogo de planejamento é balancear os interesses do cliente com a capacidade da equipe. O planejamento é contínuo e progressivo. Os desenvolvedores estimam o custo das funcionalidades candidatas e o cliente as prioriza com base no custo e no valor agregado para o negócio. Uma das grandes vantagens do jogo de planejamento é a participação ativa do cliente e da equipe, com o processo de desenvolvimento sendo conhecido por todos. Diretrizes que levam a decisões relacionadas com liberações ou iterações específicas ficam claras para todos, pois cliente e equipe as definem juntos. Após as histórias de usuário terem sido definidas, a equipe de desenvolvimento fornece ao cliente uma estimativa de tempo para implementar cada uma delas. O cliente então prioriza as histórias considerando estas estimativas. Posteriormente a equipe informa ao cliente o tempo que irão trabalhar no próximo incremento e baseado nisso o cliente seleciona as histórias que a equipe irá implementar em seguida. Os desenvolvedores então dividem as histórias em tarefas, mas sem envolver o cliente com detalhes de implementação.
Padrões de código
Pelo fato de os desenvolvedores programarem diferentes partes do sistema com vários membros da equipe, a adoção de padrões de código é bastante interessante. Eles facilitam o entendimento do código, aumentam a legibilidade e melhoram a consistência entre membros da equipe. Os padrões devem ser fáceis de serem seguidos e devem ser adotados voluntariamente. Deve ser acordado pela equipe, assegurando que a comunicação possa ser feita via código, além de levar os desenvolvedores a entender facilmente o código de seus colegas. Esta prática libera o programador de tomar decisões com respeito a um estilo, torna mais fácil a adoção da prática de programação em par, além de apoiar a prática de propriedade coletiva de código.
Ritmo sustentá-vel
Esta prática enfatiza que se deve trabalhar apenas a quantidade de horas que se possa manter produtividade de modo sustentável. Não trabalhar mais de 40 horas por semana é a regra, além de não mais de 8 horas por dia. Em períodos difíceis quando se trabalha além do tempo, os artefatos produzidos são pobres em qualidade. Os requisitos devem ser selecionados para cada iteração de modo que os desenvolvedores não precisem trabalhar fora de horário nem fazer horas-extras.
6.3- Relacionamento das Práticas Ágeis com as Características de Agilidade
As associações entre as práticas ágeis e as características de agilidade pode ser feita observando-se um ou mais dos possíveis relacionamentos entre elas. Neste trabalho será adotado o relacionamento que indica se uma determinada prática pode ou não apoiar ou ajudar a alcançar determinada característica de agilidade, conforme proposto e utilizado no trabalho de Qumer e Henderson-Sellers (2008).
Neste trabalho, cada prática será individualmente analisada com relação a todo o conjunto de características de agilidade, buscando identificar e indicar se pode ou não haver o relacionamento da prática com cada uma das características. Em caso afirmativo será explicitado o raciocínio utilizado para embasar ou fundamentar o relacionamento. A análise se baseará nos componentes conceituais identificados nas descrições das práticas e das características de agilidade (registradas nos itens 1 e 2 acima). Pelo fato de as características de agilidade estarem em um nível de abstração mais alto, os relacionamentos entre elas e as práticas ágeis serão definidos através de uma análise criteriosa com base na interpretação dos textos que descrevem seus respectivos significados (itens 1 e 2 acima). Nas tabelas que se seguem, para cada prática, são inseridas apenas as características para as quais foi possível identificar um mapeamento com uma justificativa aceitável em termos de contribuição da prática para a característica.
Prática 3- Desenvolvimento orientado a testes
255
CaracterísticaEmbasamento: o desenvolvimento orientado a testes ...
Orientação a Pessoas favorece as chances de melhoria de qualidade do trabalho dos desenvolvedores.
Ser Incremental favorece os testes dos incrementos para posterior integração.Ser Iterativo permite gerar suítes de testes de regressão que ajudam na repetição dos
ciclos.Testes Constantes naturalmente conduz a testes constantes.
Não foi possível identificar o mapeamento da prática para as seguintes características: Adaptabilidade, Auto-organização, Emergência, Equipes pequenas, Incorporação de Retroalimentação (feedback), Leanness, Modularidade, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Time Boxing e Transparência.
Prática 6- Integração contínua
CaracterísticaEmbasamento: a integração contínua para revelar falhas ...
Incorporação de Retroalimentação (feedback)
facilita a manter continuamente disponível uma versão executável, viabilizando retroalimentações mais freqüentes.
Leanness permite revelar falhas mais cedo, contribuindo para redução de custos e melhoria de qualidade que são valores percebidos pelo cliente.
Ser Incremental apóia as entregas incrementais do software.Testes Constantes conduz naturalmente a testes constantes.
Não foi possível identificar o mapeamento da prática para as seguintes características: Adaptabilidade, Auto-organização, Emergência, Equipes pequenas, Modularidade, Orientação a Pessoas, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Ser Iterativo, Time Boxing Transparência.
Prática 7- Jogo de planejamento
CaracterísticaEmbasamento: ojogo de planejamento, envolvendo
desenvolvedores e clientes ...Incorporação de Retroalimentação (feedback)
facilita a retroalimentação com maior freqüência e rapidez.
Orientação a Pessoas busca balancear os interesses do cliente com a capacidade da equipe.
Ser Cooperativo apresenta como uma de suas vantagens a participação ativa do cliente.
Ser Incremental pode apoiar a definição dos incrementos.
Não foi possível identificar o mapeamento da prática para as seguintes características: Adaptabilidade, Auto-organização, Emergência, Equipes pequenas, Leanness, Modularidade, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
Prática 9- Padrões de código
CaracterísticaEmbasamento: os padrões de código ...
Adaptabilidade facilitam o entendimento e a comunicação via código, melhorando as condições da equipe para fazer mudanças.
Leanness podem reduzir o esforço de criação e modificação do código, podendo levar a redução de custos e melhoria de qualidade.
256
Não foi possível identificar o mapeamento da prática para as seguintes características: Auto-organização, Emergência, Equipes pequenas, Incorporação de Retroalimentação (feedback), Modularidade, Orientação a Pessoas, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
Prática 14- Ritmo sustentável
CaracterísticaEmbasamento: o ritmo sustentável ...
Orientação a Pessoas valoriza as pessoas e as fortalece ao prover condições para que apresentem desempenho e qualidade de trabalho aceitáveis.
Não foi possível identificar o mapeamento da prática para as seguintes características: Adaptabilidade, Auto-organização, Emergência, Equipes pequenas, Incorporação de Retroalimentação (feedback), Leanness, Modularidade, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
6.4 Guia GeralÉ a mesma da seção D.5.4
6.5 Caracterização e ConsentimentoSão os mesmos da seção E.5.5
6.6 RevisãoÉ a mesma da seção D.5.6
D.7 Instrumentação para o Grupo 3 – Características de Agilidade7.1- Descrições do significado de cada característica de agilidade
São as mesmas da seção D.5.1
7.2- Descrições do significado de cada prática ágil do grupo 3
Prática Descrição ConsolidadaEquipe completa
Refere-se à prática de incluir todos os perfis e perspectivas necessários na equipe para que ela possa ter bom desempenho, enfatizando o espírito de equipe, com todos os seus membros compartilhando um propósito e apoiando-se mutuamente. Clientes, usuários e demais interessados devem ter um envolvimento direto no projeto, a fim de possibilitar entender o comportamento do sistema mais cedo no ciclo de vida.
Metáfora Esta prática consiste em apresentar uma estória simples e compartilhada que explica a essência de como o sistema funciona, para dar a desenvolvedores e cliente um entendimento comum sobre o projeto. De um certo modo, a metáfora serve como uma arquitetura de alto nível para o software. A metáfora serve para fazer a ligação de um domínio conhecido com um domínio com o qual não se está familiarizado. Pensando sobre uma metáfora apropriada, os desenvolvedores podem expandir suas perspectivas de análise da aplicação sendo desenvolvida. Há dois propósitos principais para a metáfora. Um é a comunicação. A metáfora preenche a lacuna entre desenvolvedores e usuários assegurando facilidades na discussão sobre o software e no fornecimento de exemplos. O segundo propósito da metáfora é a contribuição para que a equipe desenvolva uma arquitetura apropriada para o software.
Liberações frequentes
Esta prática visa maximizar o retorno dos projetos assegurando que o maior valor de negócio possível seja entregue ao final de cada release e que cada release tenha uma duração curta. Isso é feito através do processo contínuo de priorização que seleciona sempre as histórias de maior valor para serem implementadas primeiro. Além disso, procura antecipar o retorno entregando software rapidamente. Ciclos curtos reduzem os riscos, possibilitando ao cliente terminar rapidamente com projetos que não agreguem valor para o negócio. Além disso, ciclos de liberações frequentes ajudam a lidar com mudanças nos requisitos e reduzem o impacto de erros de planejamento.
257
Prática Descrição ConsolidadaAo final de cada release, o cliente revê todo o produto podendo identificar defeitos e fazer ajustes nos requisitos futuros.
Reuniões diárias
As reuniões diárias em pé são reuniões rápidas, geralmente de 15 minutos, organizadas para acompanhar o progresso do projeto, destacar questões importantes e organizar as atividades diárias. Cada membro da equipe relata rapidamente no que está trabalhando e o progresso já alcançado. Durante a reunião todos devem ficar de pé, para encorajar os participantes a serem objetivos, não ultrapassar o tempo previsto para a reunião, além de manter todos alertas e com atenção voltada para os assuntos tratados.
Visibilidade de projeto
Projetos ágeis por sua natureza estão continuamente mudando (planos, modelos, código e demais artefatos). Deve haver esforços para fornecer às equipes o status do projeto em que estão engajadas. A psicologia mostra que quanto mais imediata aretroalimentação, mais rapidamente as pessoas mudam o comportamento para se adequar a novas situações. Pode ser criado um painel na web para manter a qualquer tempo o status e as métricas relacionadas com o progresso do projeto. Múltiplos painéis podem ser usados para disponibilizar diferentes tipos de informação que atendam a todos os níveis organizacionais necessários. O avanço do projeto com relação às histórias de usuário que as equipes se comprometeram a entregar no final das iterações deve ser incluído. Modelos devem se tornar acessíveis para todas as equipes.
7.3- Relacionamento das Práticas Ágeis com as Características de Agilidade
As associações entre as práticas ágeis e as características de agilidade pode ser feita observando-se um ou mais dos possíveis relacionamentos entre elas. Neste trabalho será adotado o relacionamento que indica se uma determinada prática pode ou não apoiar ou ajudar a alcançar determinada característica de agilidade, conforme proposto e utilizado no trabalho de Qumer e Henderson-Sellers (2008).
Neste trabalho, cada prática será individualmente analisada com relação a todo o conjunto de características de agilidade, buscando identificar e indicar se pode ou não haver o relacionamento da prática com cada uma das características. Em caso afirmativo será explicitado o raciocínio utilizado para embasar ou fundamentar o relacionamento. A análise se baseará nos componentes conceituais identificados nas descrições das práticas e das características de agilidade (registradas nos itens 1 e 2 acima). Pelo fato de as características de agilidade estarem em um nível de abstração mais alto, os relacionamentos entre elas e as práticas ágeis serão definidos através de uma análise criteriosa com base na interpretação dos textos que descrevem seus respectivos significados (itens 1 e 2 acima). Nas tabelas que se seguem, para cada prática, são inseridas apenas as características para as quais foi possível identificar um mapeamento com uma justificativa aceitável em termos de contribuição da prática para a característica.
Prática 5- Equipe completa
CaracterísticaEmbasamento: equipes completas, com pessoas de múltiplos perfis de
capacitação e espírito de grupo ...Adaptabilidade apresentam maiores facilidades de adaptação para atender mudanças.Auto-organização podem definir melhor as maneiras mais adequadas de trabalho, considerando
mais possibilidades no processo de escolha.Orientação a Pessoas
apresentam condições ou oportunidades de aprendizado dentro da própria equipe, podendo levar à melhoria de produtividade, qualidade e desempenho.
258
CaracterísticaEmbasamento: equipes completas, com pessoas de múltiplos perfis de
capacitação e espírito de grupo ...Reflexão e Introspecção
podem ser mais efetivas na identificação do que precisa ser melhorado.
Não foi possível identificar o mapeamento da prática para as seguintes características: Emergência, Equipes pequenas, Incorporação de Retroalimentação (feedback), Leanness, Modularidade, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
Prática 8- Metáfora
CaracterísticaEmbasamento: a metáfora ...
Orientação a Pessoas busca o estabelecimento de um entendimento comum para o projeto, o que pode contribuir para a comunicação, um elemento fundamental desta prática.
Não foi possível identificar o mapeamento da prática para as seguintes características: Adaptabilidade, Auto-organização, Emergência, Equipes pequenas, Incorporação de Retroalimentação (feedback), Leanness, Modularidade, Reflexão e Introspecção, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
Prática 12- Liberações frequentes
CaracterísticaEmbasamento: as liberações frequentes ...
Incorporação de Retroalimentação (feedback)
favorecem a retroalimentação mais freqüente.
Ser Cooperativo permitem que o cliente possa rever o produto mais frequentemente, podendo identificar defeitos e fazer ajustes nos requisitos, tendo melhores condições de cooperar provendo retroalimentações mais freqüentes.
Ser Incremental naturalmente conduzem aos incrementos desenvolvidos em ciclos rápidos.
Não foi possível identificar o mapeamento da prática para as seguintes características: Adaptabilidade, Auto-organização, Emergência, Equipes pequenas, Leanness, Modularidade, Leanness, Modularidade, Orientação a Pessoas, Reflexão e Introspecção, Ser Colaborativo, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
Prática 13- Reuniões diárias
CaracterísticaEmbasamento: as reuniões diárias ...
Auto-organização são realizadas também para organizar as atividades diárias, podendo, portanto, apoiar a auto-organização das equipes.
Emergência ao permitir o acompanhamento do progresso, podem também apoiar o reconhecimento de princípios e estruturas de trabalho mais adequados, durante o desenvolvimento, uma vez que requisitos e tecnologias podem emergir ao longo do ciclo de vida do produto.
Incorporação de Retroalimentação (feedback)
proporcionam uma oportunidade para retroalimentações rápidas.
Orientação a Pessoas naturalmente proporcionam oportunidades para a equipe expor suas preocupações, fortalecendo-a, de certa forma, em relação a processos e tecnologias.
259
CaracterísticaEmbasamento: as reuniões diárias ...
Reflexão e Introspecção podem ajudar a consolidar a percepção das pessoas sobre eventuais problemas, preparando-as, de certa forma, para as reuniões de reflexão e introspecção ao final de cada subprojeto.
Não foi possível identificar o mapeamento da prática para as seguintes características: Adaptabilidade, Equipes pequenas, Leanness, Modularidade, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
Prática 15- Visibilidade de projeto
CaracterísticaEmbasamento: a visibilidade de projeto ...
Adaptabilidade fornece às equipes artefatos e status atualizados do projeto, apóiando a mudança de comportamento para se adequar a novas situações.
Incorporação de Retroalimentação (feedback)
viabiliza a disponibilização de informações atualizadas sobre o status do projeto, podendo assim poiar a busca de retroalimentação por parte dos membros das equipes.
Leanness facilita fornecer às equipes o status atualizado do projeto, podendo estimular a habilidade de realizar mais trabalho com menos esforço, bem como a eliminação de perdas.
Orientação a Pessoas facilita fornecer às equipes artefatos e status atualizados do projeto podendo fazer com que elas se sintam valorizadas, além de melhorar a comunicação, um elemento fundamental desta característica.
Reflexão e Introspecção propicia o conhecimento sobre o status do projeto pelas equipes, podendo conduzir a contribuições mais significativas quanto a “o que” precisa ser melhorado.
Não foi possível identificar o mapeamento da prática para as seguintes características: Auto-organização, Emergência, Equipes pequenas, Modularidade, Ser Colaborativo, Ser Cooperativo, Ser Incremental, Ser Iterativo, Testes Constantes, Time Boxing e Transparência.
7.4 Guia GeralÉ a mesma da seção D.5.4
7.5 Caracterização e ConsentimentoSão os mesmos da seção D.5.5
7.6 RevisãoÉ a mesma da seção D.5.6
D.8 Instrumentação para o Grupo 1 – Atividades de Teste8.1- Descrições do significado de cada atividade de teste
Atividade Descrição
Planejar TestesEsta atividade envolve o planejamento do processo de teste a ser seguido para um projeto específico, com estimativa de custos, cronograma e recursos; são ainda definidos os itens a serem testados, as estratégias, métodos e técnicas de teste a serem adotadas, bem como é estabelecido um critério para aceitação do software testado.
Produtos de Trabalho: Plano de Teste
260
Atividade Descrição
Projetar TestesEsta atividade envolve a especificação detalhada das abordagens a serem seguidas durante a realização dos testes identificadas na atividade “Planejar Testes”, para avaliar os itens de teste nela identificados. Nesta atividade são identificados conjuntos de casos e procedimentos de teste a serem executados para avaliação do software.
Produtos de Trabalho: Especificação do Projeto de Teste
Especificar Casos de Teste
Nessa atividade, devem ser especificados todos os casos de teste identificados na atividade anterior (Projetar Testes). Para cada caso de teste devem ser descritos os seus valores de entrada, resultados esperados, recursos necessários para a sua execução, suas restrições e dependências com outros casos de teste.
Produtos de Trabalho: Especificação de Casos de Teste
Definir Procedimentos de Teste.
Esta atividade deve definir procedimentos descrevendo os passos necessários para a execução de um ou de um grupo de casos de teste. Um procedimento de teste precisa conter informações sobre o seu objetivo, requisitos para a sua execução, além dos passos a serem seguidos durante os testes.
Produtos de Trabalho: Especificação de Procedimentos de Teste
Executar TestesEsta atividade envolve executar os procedimentos de teste elaborados para um produto específico, devendo a execução ser devidamente documentada para permitir que outros testadores possam repeti-la de forma semelhante.
Produtos de Trabalho: Histórico dos Testes, Relatório de Incidentes de Teste
Analisar Resultados
Esta atividade envolve avaliar os resultados dos testes para saber se eles obtiveram sucesso. Na maioria das vezes, “sucesso” significa que o sistema funcionou conforme o planejado, e não apresentou resultados diferentes dos resultados esperados, conforme descrito nos casos de teste. Esta atividade também pode envolver a utilização de métricas de teste específicas, calculadas a partir dos resultados alcançados.
Produtos de Trabalho: Relatório de Resumo dos TestesMonitorar e
Controlar o Processo de Teste
As atividades de monitoramento, controle e re-planejamento de testes tem como propósito manter o controle e fazer as correções necessárias no Plano de Teste, quando este não mais refletir a realidade na medida em que as atividades de teste são executadas e os testes progridem.
Produtos de Trabalho: Registro das tarefas executadas, do andamento do processo e dos resultados obtidos para os testes.
Fechar Atividades de Teste
A atividade de fechamento do processo de teste tem como propósito descartar artefatos desnecessários após o término dos testes e guardar ativos físicos de valor, bem como informações que sejam relevantes para a organização. Os dados gerados ao longo dos testes são armazenados para permitir a qualquer momento a consulta a esses dados, como uma forma de apoio durante a realização de novas atividades de teste ou auditoria de execução dos testes.
Produtos de Trabalho: Registro de dados de execução e de resultados de teste, disponibilizados como fonte de consulta para apoiar planejamento de futuras instâncias de processos de teste.
8.2- Descrições do significado de cada prática ágil do grupo 1São as mesmas da seção D.5.2
8.3- Relacionamento das Práticas Ágeis com as Atividades de Teste de Software
261
A idéia é determinar se cada prática ágil pode ou não apoiar cada uma das atividades do processo padrão de teste de software. Cada prática foi individualmente analisada com relação a todo o conjunto de atividades de teste identificado em um processo de teste adotado como genérico, buscando identificar e indicar se pode ou não haver o relacionamento da prática com cada uma das atividades. Em caso afirmativo foi explicitado o raciocínio utilizado para embasar ou fundamentar o relacionamento. A análise se baseou nos componentes conceituais identificados nas descrições das práticas e das atividades de teste, bem como em valores que cada prática pode eventualmente agregar ao processo de teste de software, tendo em vista os respectivos artefatos ou produtos de trabalho produzidos por cada atividade. Nesta análise, procurou-se observar se cada prática poderia apoiar a obtenção dos produtos de trabalho das atividades, além de considerar cada prática na essência de suas descrições capturadas na literatura, no contexto dos métodos ágeis. Outro aspecto importante a ser considerado nesta análise, é que o foco deste trabalho é trazer a agilidade para o processo de teste de software e não incorporar atividades de teste às práticas ágeis.
As descrições de cada prática e de cada atividade do processo padrão de teste de software estão registradas nos itens 1 e 2 acima. Nas tabelas que se seguem, para cada prática, são inseridas apenas as atividades para as quais foi possível identificar um relacionamento com uma justificativa aceitável em termos de contribuição da prática para a atividade. Vale enfatizar que a análise de cada prática com respeito a possibilidade de sua contribuição para com as atividades do processo de teste de software, além de se basear nos componentes conceituais de suas respectivas descrições, foi feita considerando fortemente o que cada atividade tem que gerar como resultado, tendo em vista os produtos de trabalho ou artefatos produzidos (como já citado, estão registrados nos itens 1 e 2 acima).
Prática 1- Backlog de produto
Atividade Embasamento: o backlog de produto ...Planejar Testes pode apoiar a definição dos itens a serem testados. Pode também facilitar um
acompanhamento para manter o plano de testes atualizado.
Não foi possível identificar o relacionamento da prática com as seguintes atividades do processo padrão de testes: Projetar Testes, Especificar Casos de Teste, Definir Procedimentos de Teste, Executar Testes, Analisar Resultados, Monitorar e Controlar Processo de Teste e Fechar Atividades de Teste.
Prática 2- Cliente presente
Atividade Embasamento: o cliente presente ...Planejar Testes pode auxiliar na solução de eventuais questões incidentes, bem como na
priorização dos itens a serem testados e no estabelecimento de critérios para aceitação.
Projetar Testes pode apoiar a identificação de casos de teste.
Não foi possível identificar o relacionamento da prática com as seguintes atividades do processo padrão de testes: Especificar Casos de Teste, Definir Procedimentos de Teste, Executar Testes, Analisar Resultados, Monitorar e Controlar Processo de Teste e Fechar Atividades de Teste.
Prática 4- Design simples
Atividade Embasamento: o design simples, sem complexidade desnecessária ...Projetar Testes pode facilitar a identificação de casos e procedimentos de teste.
262
Atividade Embasamento: o design simples, sem complexidade desnecessária ...Especificar Casos de Teste pode facilitar a identificação de restrições e dependências com outros
casos de teste.Definir Procedimentos de Teste.
pode facilitar a identificação dos passos a serem seguidos durante os testes.
Não foi possível identificar o relacionamento da prática com as seguintes atividades do processo padrão de teste: Planejar Testes, Executar Testes, Analisar Resultados, Monitorar e Controlar Processo de Teste e Fechar Atividades de Teste.
Prática 10- Propriedade coletiva do código
Não foi possível identificar o relacionamento desta prática com qualquer atividade do processo padrão de teste de software, em função de não ter sido encontrada uma justificativa aceitável para afirmar que ela contribui para que alguma das atividades do processo alcancem seus respectivos resultados tendo como foco suas descrições e os produtos de trabalho ou artefatos que cada atividade deve gerar.
Prática 11- Refatoração
Não foi possível identificar o relacionamento desta prática com qualquer atividade do processo padrão de teste de software, em função de não ter sido encontrada uma justificativa aceitável para afirmar que ela contribui para que alguma das atividades do processo alcancem seus respectivos resultados tendo como foco suas descrições e os produtos de trabalho ou artefatos que cada atividade deve gerar.
8.4 Resultados da Revisão Revisão por Pares do Relacionamento entre Práticas Ágeis e Atividades de Teste
Instruções
1. No arquivo “Mapeamento PxA.pdf” estão registrados relacionamentos entre práticas ágeis e atividades de teste, juntamente com o embasamento ou justificativa para sua definição, bem como relacionamentos não definidos por não ter sido identificada uma justificativa aceitável para tal definição. No início do item 3 do arquivo (relacionamentos) está registrada a perspectiva com que as análises foram conduzidas para se chegar às definições dos relacionamentos. Como apoio, neste mesmo arquivo, estão as descrições dos significados de cada prática e de cada atividade de teste.
2. Pede-se que você analise os relacionamentos registrados e identifique apenas aqueles dos quais você discorda, considerando as mesmas perspectivas registradas no arquivo “Mapeamento PxA.pdf”. Você pode discordar: 1- de um relacionamento definido, 2- apenas da justificativa de um relacionamento definido ou ainda, 3- de um relacionamento não definido (o qual não foi identificado, mas você considera necessário e consegue identificar uma justificativa para que ele tivesse sido definido).
3. Pede-se que você registre no formulário abaixo, uma linha para cada discordância, identificando o tipo de discordância, a prática, a atividade relacionada e a justificativa para sua discordância. Se necessário, inclua mais linhas.
4. Ao terminar pede-se o favor de enviar este arquivo com o resultado de sua revisão para o email [email protected]
AVALIADOR:
Discordância Prática Atividade Comentário com a justificativa
Comentários das colunas
263
Discordância: Indicar,1- discorda do relacionamento definido2- discorda apenas da justificativa do relacionamento definido3- discorda do relacionamento não definido
Prática: Inclua o nome da prática.Atividade: Inclua o nome da atividade
D.9 Instrumentação para o Grupo 2 – Atividades de Teste9.1- Descrições do significado de cada atividade de teste
São as mesmas da seção D.8.19.2- Descrições do significado de cada prática ágil do grupo 2
São as mesmas da seção D.6.2
9.3- Relacionamento das Práticas Ágeis com as Atividades de Teste de Software
A idéia é determinar se cada prática ágil pode ou não apoiar cada uma das atividades do processo padrão de teste de software. Cada prática foi individualmente analisada com relação a todo o conjunto de atividades de teste identificado em um processo de teste adotado como padrão, buscando identificar e indicar se pode ou não haver o relacionamento da prática com cada uma das atividades. Em caso afirmativo foi explicitado o raciocínio utilizado para embasar ou fundamentar o relacionamento. A análise se baseou nos componentes conceituais identificados nas descrições das práticas e das atividades de teste, bem como em valores que cada prática pode eventualmente agregar ao processo de teste de software, tendo em vista os respectivos artefatos ou produtos de trabalho produzidos por cada atividade. Nesta análise, procurou-se observar se cada prática poderia apoiar a obtenção dos produtos de trabalho das atividades, além de considerar cada prática na essência de suas descrições capturadas na literatura, no contexto dos métodos ágeis. Outro aspecto importante a ser considerado nesta análise, é que o foco deste trabalho é trazer a agilidade para o processo de teste de software e não incorporar atividades de teste às práticas ágeis.
As descrições de cada prática e de cada atividade do processo padrão de teste de software estão registradas nos itens 1 e 2 acima. Nas tabelas que se seguem, para cada prática, são inseridas apenas as atividades para as quais foi possível identificar um relacionamento com uma justificativa aceitável em termos de contribuição da prática para a atividade. Vale enfatizar que a análise de cada prática com respeito a possibilidade de sua contribuição para com as atividades do processo de teste de software, além de se basear nos componentes conceituais de suas respectivas descrições, foi feita considerando fortemente o que cada atividade tem que gerar como resultado, tendo em vista os produtos de trabalho ou artefatos produzidos (como já citado, estão registrados nos itens 1 e 2 acima).
Prática 3- Desenvolvimento orientado a testes
Não foi possível identificar o relacionamento desta prática com qualquer atividade do processo padrão de teste de software, em função de não ter sido encontrada uma justificativa aceitável para afirmar que ela contribui para que alguma das atividades do processo alcancem seus respectivos resultados tendo como foco suas descrições e os produtos de trabalho ou artefatos que cada atividade deve gerar.
Prática 7- Jogo de planejamento
Atividade Embasamento: o jogo de planejamento, ...
264
Atividade Embasamento: o jogo de planejamento, ...Planejar Testes
sendo contínuo e progressivo, com prioridades estabelecidas pelo cliente, pode apoiar o estabelecimento de um plano de testes alinhado com as necessidades do projeto.
Projetar Testes
com prioridades estabelecidas pelo cliente, pode apoiar o estabelecimento de prioridades no projeto de teste.
Não foi possível identificar o relacionamento da prática com as seguintes atividades do processo padrão de teste de software: Especificar Casos de Teste, Definir Procedimentos de Teste, Executar Testes, Analisar Resultados, Monitorar e Controlar Processo de Teste e Fechar Atividades de Teste.
Prática 9- Padrões de código
Não foi possível identificar o relacionamento desta prática com qualquer atividade do processo padrão de teste de software, em função de não ter sido encontrada uma justificativa aceitável para afirmar que ela contribui para que alguma das atividades do processo alcancem seus respectivos resultados tendo como foco suas descrições e os produtos de trabalho ou artefatos que cada atividade deve gerar.
Prática 12- Liberações frequentes
Atividade Embasamento: liberações frequentes ...Executar Testes influenciam as iterações ou quantidade de vezes que execuções de teste devem
acontecer.Analisar Resultados influenciam as iterações ou quantidade de vezes que análise de resultados
devem acontecer.Monitorar e Controlar
Processo de Testeinfluenciam as iterações ou quantidade de registros das tarefas executadas e dos resultados obtidos.
Não foi possível identificar o relacionamento da prática com as seguintes atividades do processo padrão de testes: Planejar Testes, Projetar Testes, Especificar Casos de Teste, Definir Procedimentos de Teste e Fechar Atividades de Teste.
Prática 13- Reuniões diárias
AtividadeEmbasamento: o acompanhamento do progresso do projeto
pode ...Planejar Testes melhorar a comunicação e auxiliar a elaboração de um plano de
teste alinhado com a realidade do projeto.Projetar Testes
facilitar a integração das atividades de teste com as de desenvolvimento.
Especificar Casos de Teste Definir Procedimentos de Teste.Executar TestesAnalisar ResultadosMonitorar e Controlar Processo de
Teste
Não foi possível identificar o relacionamento da prática com a atividade Fechar Atividades de Teste do processo padrão de testes.
9.4 Resultados da RevisãoÉ a mesma da seção D.8.4
D.10 Instrumentação para o Grupo 3 – Atividades de Teste
10.1- Descrições do significado de cada atividade de testeSão as mesmas da seção D.8.1
265
10.2- Descrições do significado de cada prática ágil do grupo 3São as mesmas da seção D.7.2
10.3- Relacionamento das Práticas Ágeis com as Atividades de Teste de Software
A idéia é determinar se cada prática ágil pode ou não apoiar cada uma das atividades do processo padrão de teste de software. Cada prática foi individualmente analisada com relação a todo o conjunto de atividades de teste identificado em um processo de teste adotado como padrão, buscando identificar e indicar se pode ou não haver o relacionamento da prática com cada uma das atividades. Em caso afirmativo foi explicitado o raciocínio utilizado para embasar ou fundamentar o relacionamento. A análise se baseou nos componentes conceituais identificados nas descrições das práticas e das atividades de teste, bem como em valores que cada prática pode eventualmente agregar ao processo de teste de software, tendo em vista os respectivos artefatos ou produtos de trabalho produzidos por cada atividade. Nesta análise, procurou-se observar se cada prática poderia apoiar a obtenção dos produtos de trabalho das atividades, além de considerar cada prática na essência de suas descrições capturadas na literatura, no contexto dos métodos ágeis. Outro aspecto importante a ser considerado nesta análise, é que o foco deste trabalho é trazer a agilidade para o processo de teste de software e não incorporar atividades de teste às práticas ágeis.
As descrições de cada prática e de cada atividade do processo padrão de teste de software estão registradas nos itens 1 e 2 acima. Nas tabelas que se seguem, para cada prática, são inseridas apenas as atividades para as quais foi possível identificar um relacionamento com uma justificativa aceitável em termos de contribuição da prática para a atividade. Vale enfatizar que a análise de cada prática com respeito a possibilidade de sua contribuição para com as atividades do processo de teste de software, além de se basear nos componentes conceituais de suas respectivas descrições, foi feita considerando fortemente o que cada atividade tem que gerar como resultado, tendo em vista os produtos de trabalho ou artefatos produzidos (como já citado, estão registrados nos itens 1 e 2 acima).
Prática 5- Equipe completa
Atividade Embasamento: um especialista em segurança pode auxiliar, por exemplo, ...Projetar Testes na identificação de casos de teste envolvendo questões de autenticação,
autorização e auditoria.Especificar Casos de Teste
na especificação detalhada de casos de teste envolvendo questões de autenticação, autorização e auditoria.
Não foi possível identificar o relacionamento da prática com as seguintes atividades do processo padrão de testes: Planejar Testes, Definir Procedimentos de Teste, Executar Testes, Analisar Resultados, Monitorar e Controlar Processo de Teste e Fechar Atividades de Teste.
Prática 8- Metáfora
Atividade Embasamento: o entendimento comum do projeto pode ...Planejar Testes
apoiar a busca de um planejamento adequado para os testes.
Projetar Testes
facilitar o projeto de teste, na identificação de casos e procedimentos de teste.
266
Não foi possível identificar o relacionamento da prática com as seguintes atividades do processo padrão de teste de software: Especificar Casos de Teste, Definir Procedimentos de Teste, Executar Testes, Analisar Resultados, Monitorar e Controlar Processo de Teste e Fechar Atividades de Teste.
Prática 6- Integração contínua
Não foi possível identificar o relacionamento desta prática com qualquer atividade do processo padrão de teste de software, em função de não ter sido encontrada uma justificativa aceitável para afirmar que ela contribui para que alguma das atividades do processo alcancem seus respectivos resultados tendo como foco suas descrições e os produtos de trabalho ou artefatos que cada atividade deve gerar.
Prática 14- Ritmo sustentável
Não foi possível identificar o relacionamento desta prática com qualquer atividade do processo padrão de teste de software, em função de não ter sido encontrada uma justificativa aceitável para afirmar que ela contribui para que alguma das atividades do processo alcancem seus respectivos resultados tendo como foco suas descrições e os produtos de trabalho ou artefatos que cada atividade deve gerar.
Prática 15- Visibilidade de projeto
Atividade Embasamento : fornecer às equipes o status do projeto pode ...Planejar Testes melhorar a comunicação e auxiliar a elaboração de um plano de
teste alinhado com a realidade do projeto.Projetar Testes
facilitar a integração das atividades de teste com as de desenvolvimento.
Especificar Casos de Teste Definir Procedimentos de Teste.Executar TestesAnalisar ResultadosMonitorar e Controlar Processo
de Teste
Não foi possível identificar o relacionamento da prática com a atividade Fechar Atividades de Teste do processo padrão de testes.
10.4 Resultados da Revisão
É a mesma da seção D.8.4
267
Apêndice E Instrumentação do Guia de Agilidade para Processos de Teste de Software
E-1 Formulário Instruções
Guia para Planejamento de Agilidade em Processos de Teste de Software
INSTRUÇÕES
Este guia contém diversas planilhas, algumas das quais deverão ser preenchidas por você.
As planilhas GA (Guia de Agilidade) farão o planejamento de agilidade propriamente dito, algumas sem que você tenha que preenchê-las.
As planilhas BC (Base de Conhecimento) armazenam o conhecimento previamente armazenado, só devem ser usadas para consulta.
A planilha AV (Avaliação) contem os quesitos a serem avaliados. Preenchê-la quando o projeto for concluído.
Você deve iniciar acessando a planilha GA01 e seguir as instruções nela contidas. No final das instruções você será orientado sobre qual é a planilha seguinte a ser acessada.
A cada planilha que você for acessando haverá instruções para preenchimento de dados, escolha de opções e orientação sobre qual é a planilha seguinte.
Siga assim até ser instruido para concluir o processo de planejamento.
E-2 Formulário Sumário
Guia para Planejamento de Agilidade em Processos de Teste de Software
Sumário das planilhas que fazem parte do quia de agilidade
As planilhas GA (Guia de Agilidade) farão o planejamento de agilidade propriamente dito, algumas sem que você tenha que preenchê-las.
As planilhas BC (Base de Conhecimento) armazenam o conhecimento previamentearmazenado, só devem ser usadas para consulta.A planilha AV (Avaliação) contem os quesitos a serem avaliados. Preenchê-la quando o projeto for concluido.
Planilha DescriçãoBC00 Limites ou Patamares de CorteBC01 Características de AgilidadeBC02 Atividades de Teste de Software e seus Produtos de TrabalhoBC03 Práticas ÁgeisBC04 Mapeamento das Práticas Ágeis para as Características de AgilidadeBC05 Mapeamento das Práticas Ágeis para as Atividades de Teste
268
BC06 Histórico de Projetos - Atributos de Caracterização e StatusBC07 Histórico de Projetos - Práticas AvaliadasGA01 Caracterização do Projeto de SoftwareGA01a Detalhes sobre Valores de Atributos de ProjetoGA02 Adequação do Projeto às Abordagens ÁgeisGA03 Escolha das Características de AgilidadeGA04 Obtenção das Práticas MapeadasGA05 Seleção das Atividades de Teste de Software para o ProjetoGA05a Restrições pelas Atividades de TesteGA05b Atualização das Práticas MapeadasGA06 Sugestão de Práticas a serem AdotadasGA06a Coeficiente de Similaridade entre Projetos de Software
GA06bPráticas bem Sucedidas de Projetos Semelhantes com Resultados Satisfatórios
GA07 Práticas Escolhidas para o Processo de TestesGA08 Registro das Práticas EscolhidasGA08a Grau de Agilidade em Potencial Estimado para o Processo de Testes
GA09Conclusão do Planejamento de Agilidade para o Processo de Teste do Projeto
AV01 Avaliação de Resultados para o Projeto ConcluidoAV01a Detalhes sobre a Avaliação das Práticas
E-3 Grupo de Formulários Base De Conhecimento (BC00 – BC07)
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareBC00 Limites ou Patamares de Corte
Id Limite ou Patamar Valor
1 Adequação do Projeto às Abordagens Ágeis 50,0%2 Similaridade entre Projetos de Software 50,0%3 Nível Estimado de Sucesso do Processo de Teste 50,0%4 Grau de Avaliação da Prática em Projetos Concluidos 50,0%
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareBC01 Características de Agilidade
Id Caracte-rística DescriçãoPerti-nência
Rele-vância
1 Ser Colaborativo
Esta é uma atitude por parte dos membros da equipe de desenvolvimento, dentre os quais a comunicação é encorajada para disseminar informação e apoiar integração rápida de incrementos de software. 94,1% 84,7%
2 Ser Cooperativo
Interação aberta e proximidade entre todos as partes interessadas (especialmente entre clientes e desenvolvedores); o cliente deve ser um elemento ativo no processo de desenvolvimento e deve prover retroalimentação (feedback) de modo regular e freqüente. 90,9% 79,3%
269
3 Ser Incremental
Não tentar construir o sistema todo de uma só vez; o sistema deve ser particionado em incrementos (pequenas liberações com novas funcionalidades) desenvolvidos em ciclos rápidos e paralelos; quando o incremento estiver completo e testado, ele é integrado ao sistema. 94,1% 83,3%
4 Adaptabilidade
Habilidade e capacidade de adaptar rapidamente o processo para atender e reagir a mudanças de última hora nos requisitos e/ou mudanças de ambiente, bem como atender e reagir a riscos ou situações não previstas. 100,0% 88,7%
5 Auto-organização
As equipes definem as melhores maneiras de se trabalhar; elas são autônomas e podem se auto-organizar de acordo para completar os itens de trabalho. 76,3% 57,2%
6 Ser Iterativo
Usar vários ciclos curtos guiados por funcionalidades do produto, nos quais certo conjunto de atividades é completado em poucas semanas; estes ciclos são repetidos muitas vezes pra refinar as entregas. 92,5% 84,8%
7Testes Constantes
Para prevenir a degradação da qualidade por causa de programas de liberações frequentes, um alto grau de ênfase é colocado no teste do produto ao longo de seu ciclo de vida; testes de integração devem ser automatizados com construções (builds) diárias bem como a execução de testes de regressão para garantir que todas as funcionalidades operem adequadamente. 93,8% 84,1%
9 Emergência
Os processos, princípios e estruturas de trabalho são reconhecidos durante o processo de execução, não sendo definidos a priori; é permitido e aceito que tecnologias e requisitos emerjam durante o ciclo de vida do produto. 74,1% 57,7%
10
Incorporação de Retroalimentação (feedback)
As equipes devem ser capazes de receber e procurar continuamente por retroalimentaçãode modo mais freqüente e com mais rapidez. 79,7% 84,1%
11 Leanness
Esta característica está relacionada com a eliminação de perdas e com a habilidade de realizar mais trabalho com menos esforço; é uma característica de processos ágeis que requer o mínimo necessário de atividades para mitigar riscos e alcançar metas; todas as atividades que não são necessárias devem ser removidas do processo de desenvolvimento. 61,3% 56,5%
13 Modularidade
Esta característica permite que um processo seja particionado em componentes chamados de atividades, tornando viável adicioná-los ou removê-los de um processo quando necessário. 64,4% 54,0%
14Orientação a Pessoas
Privilegiar pessoas em detrimento de processos e tecnologias; desenvolvedores são fortalecidos e encorajados a aumentar sua produtividade, qualidade e desempenho; comunicação e cooperação são fundamentais e necessárias; reuniões em pé e oficinas (workshops) de reflexão dão às pessoas a chance de expor suas preocupações. 98,4% 89,1%
270
15Reflexão e Introspecção
Acontecem reuniões no final de cada subprojeto ou iteração, nas quais cada membro da equipe pode discutir o que está sendo bem feito e o que precisa ser melhorado. 98,4% 80,8%
16Equipes pequenas
Equipes pequenas, e pequeno número de equipes por projeto, são necessários para promover um ambiente colaborativo e requer menos planejamento para coordenar as atividades dos membros das equipes. 71,6% 43,2%
17 Time-boxing
É o estabelecimento de limite ou fatias de tempo para cada iteração programada. Grandes esforços de desenvolvimento são divididos em múltiplas entregas desenvolvidas de modo incremental e concorrente, de maneira previsível. 93,1% 63,5%
18 Transparência
O método ou processo ágil deve ser fácil de aprender e de ser modificado, além de estar adequadamente documentado. 61,6% 62,8%
As características 8- Convergência e 12- Equipes Locais foram excluídas em função do resultado do survey.
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareBC02 Atividades de Teste de Software e seus Produtos de Trabalho
Id Atividade DescriçãoProdutos de
Trabalho
1Planejar Testes
Esta atividade envolve o planejamento do processo de teste a ser seguido para um projeto específico, com estimativa de custos, cronograma e recursos; são ainda definidos os itens a serem testados, as estratégias, métodos e técnicas de teste a serem adotadas, bem como é estabelecido um critério para aceitação do software testado. Plano de Teste
2 Projetar Testes
Esta atividade envolve a especificação detalhada das abordagens a serem seguidas durante a realização dos testes identificadas na atividade “Planejar Testes”, para avaliar os itens de teste nela identificados. Nesta atividade são identificados conjuntos de casos e procedimentos de teste a serem executados para avaliação do software.
Especificação de Projeto de Teste
3
Especificar Casos de Teste
Nessa atividade, devem ser especificados todos os casos de teste identificados na atividade anterior (Projetar Testes). Para cada caso de teste devem ser descritos os seus valores de entrada, resultados esperados, recursos necessários para a sua execução, suas restrições e dependências com outroscasos de teste.
Especificação de Casos de Teste
271
4
Definir Procedimentos de Teste
Esta atividade deve definir procedimentos descrevendo os passos necessários para a execução de um ou de um grupo de casos de teste. Um procedimento de teste precisa conter informações sobre o seu objetivo, requisitos para a sua execução, além dos passos a serem seguidos durante os testes.
Especificação de Procedimentos de Teste
5Executar Testes
Esta atividade envolve executar os procedimentos de teste elaborados para um produto específico, devendo a execução ser devidamente documentada para permitir que outros testadores possam repeti-la de forma semelhante.
Histórico dos Testes, Relatório de Incidentes de Teste
6Analisar Resultados
Esta atividade envolve avaliar os resultados dos testes para saber se eles obtiveram sucesso. Na maioria das vezes, “sucesso” significa que o sistema funcionou conforme o planejado, e não apresentou resultados diferentes dos resultados esperados, conforme descrito nos casos de teste. Esta atividade também pode envolver a utilização de métricas de teste específicas, calculadas a partir dos resultados alcançados.
Relatório deResumo dos Testes
7
Monitorar e Controlar Processo de Teste
As atividades de monitoramento, controle e re-planejamento de testes tem como propósito manter o controle e fazer as correções necessárias no Plano de Teste, quando este não mais refletir a realidade na medida em que as atividades de teste são executadas e os testes progridem.
Registro das tarefas executadas, do andamento do processo e dos resultados obtidos para os testes.
8
Fechar Atividades de Teste
A atividade de fechamento do processo de teste tem como propósito descartar artefatos desnecessários após o término dos testes e guardar ativos físicos de valor, bem como informações que sejam relevantes para a organização. Os dados gerados ao longo dos testes são armazenados para permitir a qualquer momento a consulta a esses dados, como uma forma de apoio durante a realização de novas atividades de teste ou auditoria de execução dos testes.
Registro de dados de execução e de resultados de teste, disponibilizados como fonte de consulta para apoiar planejamento de futuras instâncias de processos de teste.
272
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareBC03 Práticas Ágeis
Id Prática DescriçãoPerti-nência
Rele-vância
9 Backlog de produto
Esta prática inclui tarefas para criação de uma lista de backlog de produto, e seu controle durante o processo de inserção, remoção, atualização e priorização dos itens da lista. A lista de backlog de produto define tudo o que é necessário para o produto final baseado no conhecimento atual que dele se tem. O backlog de produto define o trabalho a ser feito no projeto, incluindo uma priorização e constante atualização da lista de requisitos para o sistema sendo construído ou melhorado. Itens de backlog podem incluir, por exemplo, funcionalidades, correção de erros, defeitos, requisições de melhorias, atualizações de tecnologia, etc. Questões que requeiram solução antes que outros itens de backlog sejam trabalhados também podem estar na lista. 95,3% 82,7%
5 Cliente presente
Em termos práticos, isso significa colocar o cliente fisicamente próximo aos desenvolvedores ou mover os desenvolvedores para próximo do cliente. Esta prática indica que o cliente deve fazer parte da equipe de desenvolvimento. Para esclarecer e validar requisitos e estabelecer prioridades, um representante do cliente trabalha junto da equipe todo o tempo. Assim o cliente pode responder a perguntas, resolver questões, estabelecer prioridades, fazer testes de aceitação e assegurar que o desenvolvimento tenha o progresso esperado. Quando surgem questionamentos, os programadores podem resolver imediatamente com o cliente, ao invés de tentar imaginar quais seriam suas preferências. Esta prática também leva o cliente a mudar mais prontamente os requisitos, ajudando a equipe a mudar o foco dos esforços de desenvolvimento para as necessidades mais prementes. 50,6% 37,3%
273
16Desenvolvimento orientado a testes
Todo programador escreve casos de teste antes de escrever o código. Os testes devem ser escritos antes da implementação e conter o que for necessário para verificar se o código se comporta de acordo com os requisitos do usuário. O desenvolvedor ou testador deve escrever os casos de teste assim que os requisitos estiverem definidos. Além de escrever os testes de unidade antes da codificação, os desenvolvedores devem encorajar os usuários a escrever os testes de aceitação. Ao ser executado pela primeira vez, o caso de teste irá falhar, uma vez que o desenvolvimento do código que implementa a condição sendo testada ainda não foi gerado. Então, escreve-se código apenas o suficiente para o caso de teste passar, seguido de refatoração para remover duplicações e melhorar a legibilidade do código. Escrever drivers de teste antes da codificação força o desenvolvedor a pensar no problema antes da programação. Esta prática aplicada corretamente garante uma suíte de testes para fins de teste de regressão, além de prover documentação para o código implementado, servindo de casos de uso para este mesmo código. Deve-se ter o cliente escrevendo testes de aceitação, que podem se tornar casos de teste de um plano geral de testes para o sistema. Antes de o programador integrar o seu código à base de código, ele deve ter todos os seus próprios testes passando, além de todos aqueles testes já escritos e já incorporados à base, que também deverão passar. Isto assegura que o novo código sendo integrado para implementar uma nova funcionalidade não quebre o código de alguém que já havia sido incorporado à base de código. 59,3% 46,2%
12 Design simples
A ênfase desta prática está em projetar a solução mais simples possível e que seja viável no momento. Complexidade desnecessária e código extra devem ser removidos assim que reconhecidos. Não se deve incluir aspectos adicionais aos artefatos sem uma boa justificativa para tal. A prática do design simples requer que a equipe não projete para satisfazer necessidades futuras, as quais os desenvolvedores não devem tentar prever. A abordagem de desenvolvimento mais efetiva em termos de custo deve focar em resolver os problemas de hoje ao invés de projetar para mudanças futuras que não se sabe se realmente ocorrerão. Deve-se trabalhar a solução mais simples que possa funcionar. 78,3% 62,9%
274
17 Equipe completa
Refere-se à prática de incluir todos os perfis e perspectivas necessários na equipe para que ela possa ter bom desempenho, enfatizando o espírito de equipe, com todos os seus membros compartilhando um propósito e apoiando-se mutuamente. Clientes, usuários e demais interessados devem ter um envolvimento direto no projeto, a fim de possibilitar entender o comportamento do sistema mais cedo no ciclo de vida. 51,0% 34,9%
3 Integração contínua
Na integração contínua, os membros da equipe devem integrar seu trabalho frequentemente, toda vez que novas mudanças ou uma tarefa for completada, para revelar problemas de integração e detectar falhas de sistema o mais cedo possível. Cada pessoa deve fazer a integração pelo menos uma vez por dia. Isto garante que sempre esteja disponível uma versão executável do sistema, contendo todas as novas funcionalidades e modificações, podendo servir de baseline para o trabalho. Depois da integração, todos os testes devem passar, ou o novo código deve ser descartado. Os integrantes da equipe podem fazer a integração sempre que desejarem, a não ser em curtos períodos de tempo em que o código é congelado. Cada integração deve ser verificada imediatamente ou à noite através de uma build automática com execução de todos os testes de integração. Esta prática é um exemplo de uma técnica dinâmica de garantia de qualidade. 92,1% 92,1%
275
8 Jogo de planejamento
Juntos desenvolvedores e clientes atuam no jogo de planejamento no qual o cliente escolhe as histórias de usuário que incluem os requisitos mais importantes a serem incluídos em uma entrega curta e incremental. Cada incremento curto implementado é experimentado pelo cliente. As históriasremanescentes são reavaliadas em termos de requisitos e prioridades, sendo o jogo de planejamento jogado novamente para definir o próximo incremento a ser implementado. A meta do jogo de planejamento é balancear os interesses do cliente com a capacidade da equipe. O planejamento é contínuo e progressivo. Os desenvolvedores estimam o custo das funcionalidades candidatas e o cliente as prioriza com base no custo e no valor agregado para o negócio. Uma das grandes vantagens do jogo de planejamento é a participação ativa do cliente e da equipe, com o processo de desenvolvimento sendo conhecido por todos. Diretrizes que levam a decisões relacionadas com liberações ou iterações específicas ficam claras para todos, pois cliente e equipe as definem juntos. Após as histórias de usuário terem sido definidas, a equipe de desenvolvimento fornece ao cliente uma estimativa de tempo para implementar cada uma delas. O cliente então prioriza as histórias considerando estas estimativas. Posteriormente a equipe informa ao cliente o tempo que irão trabalhar no próximo incremento e baseado nisso o cliente seleciona as histórias que a equipe irá implementar em seguida. Os desenvolvedores então dividem as histórias em tarefas, mas sem envolver o cliente com detalhes de implementação. 85,0% 70,7%
4 Metáfora
Esta prática consiste em apresentar uma estória simples e compartilhada que explica a essência de como o sistema funciona, para dar a desenvolvedores e cliente um entendimento comum sobre o projeto. De um certo modo, a metáfora serve como uma arquitetura de alto nível para o software. A metáfora serve para fazer a ligação de um domínio conhecido com um domínio com o qual não se está familiarizado. Pensando sobre uma metáfora apropriada, os desenvolvedores podem expandir suas perspectivas de análise da aplicação sendo desenvolvida. Há dois propósitos principais para a metáfora. Um é a comunicação. A metáfora preenche a lacuna entre desenvolvedores e usuários assegurando facilidades na discussão sobre o software e no fornecimento de exemplos. O segundo propósito da metáfora é a contribuição para que a equipe desenvolva uma arquitetura apropriada para o software. 54,5% 34,6%
276
1 Padrões de código
Pelo fato de os desenvolvedores programarem diferentes partes do sistema com vários membros da equipe, a adoção de padrões de código é bastante interessante. Eles facilitam o entendimento do código, aumentam a legibilidade e melhoram a consistência entre membros da equipe. Os padrões devem ser fáceis de serem seguidos e devem ser adotados voluntariamente. Deve ser acordado pela equipe, assegurando que a comunicação possa ser feita via código, além de levar os desenvolvedores a entender facilmente o código de seus colegas. Esta prática libera o programador de tomar decisões com respeito a um estilo, torna mais fácil a adoção da prática de programação em par, além de apoiar a prática de propriedade coletiva de código. 78,3% 55,7%
2Propriedade coletiva do código
O repositório de código deve ser de livre acesso para todos os programadores e permitir mudanças sempre que necessário. Uma vez na base de código, qualquer membro da equipe tem a posse sobre todo código. Todos são encorajados a fazer mudanças no código, em qualquer parte e a qualquer tempo que sintam a necessidade de fazê-las, sem ter que pedir permissão para quem quer que seja. Esta prática pode remover o gargalo de software que normalmente está relacionada com a posse individual do código. Qualquer par deprogramadores que veja uma oportunidade de adicionar valor a qualquer parte do código pode fazê-lo a qualquer tempo. A propriedade coletiva do código, além de ajudar na melhoria do código, dá mais flexibilidade aos programadores para se ausentar em casos de necessidade ou para saírem de férias. A disponibilidade de drivers de teste automatizados faz com que os desenvolvedores tenham mais liberdade para modificar o código sem maiores receios de eventuais repercussões que possam causar. Ao poder examinar o código escrito por outros, os programadores podem refletir e considerar as razões que levaram os colegas a tomar determinadas decisões específicas, ou podem melhorar o entendimento de seu próprio código e de suas interfaces com as demais partes da codificação do software. 71,5% 51,7%
277
11 Refatoração
O software se deteriora com o tempo. Um projeto que inicialmente parece enxuto e/ou perfeito pode torna-se progressivamente sobrecarregado e/ou deteriorado a cada modificação nele introduzida. Quando o software tem uma documentação mínima, o código fonte deve permanecer simples e fácil de entender. A refatoração é uma técnica disciplinada para se reestruturar um corpo de código existente ou para constantemente melhorar sua inteligibilidade e manutenibilidade, bem como o seu projeto, alterando sua estrutura interna sem mudar seu comportamento externo nem a funcionalidade do sistema. O foco é obter código simples, limpo e não repetitivo, que pode ser modificado facilmente. A essência da prática é uma série de pequenas transformações que preservam comportamento. Pelo fato das transformações serem pequenas, a possibilidade de algo dar errado é também pequena, com o sistema permanecendo totalmente funcional após cada refatoração. Durante a refatoração os desenvolvedores reconstroem o código e isto já provê inspeção da sua funcionalidade. As diferentes formas de refatoração podem envolver a simplificação de declarações complexas, a abstração de soluções comuns para fins de reuso e a remoção de código duplicado. Esta prática reduz a probabilidade de geração de erros durante o desenvolvimento. Entretanto, a prática de refatoração é altamente dependente do conjunto de casos de teste de unidade automatizados. Quando o código é refatorado, ele deve ainda passar por todos os casos de teste de unidade armazenados. Se algum caso de teste falhar depois da refatoração, as devidas correções devem ser efetuadas. 86,6% 80,2%
13Liberações freqüentes(Releases curtas)
Esta prática visa maximizar o retorno dos projetos assegurando que o maior valor de negócio possível seja entregue ao final de cada release e que cada release tenha uma duração curta. Isso é feito através do processo contínuo de priorização que seleciona sempre as histórias de maior valor para serem implementadas primeiro. Além disso, procura antecipar o retorno entregando software rapidamente. Ciclos curtos reduzem os riscos, possibilitando ao cliente terminar rapidamente com projetos que não agreguem valor para o negócio. Além disso, ciclos de liberações frequentes ajudam a lidar com mudanças nos requisitos e reduzem o impacto de erros de planejamento. Ao final de cada release, o cliente revê todo o produto podendo identificar defeitos e fazer ajustes nos requisitos futuros. 92,1% 82,4%
278
14 Reuniões diárias
As reuniões diárias em pé são reuniões rápidas, geralmente de 15 minutos, organizadas para acompanhar o progresso do projeto, destacar questões importantes e organizar as atividades diárias. Cada membro da equipe relata rapidamente no que está trabalhando e o progresso já alcançado. Durante a reunião todos devem ficar de pé, para encorajar os participantes a serem objetivos, não ultrapassar o tempo previsto para a reunião, além de manter todos alertas e com atenção voltada para os assuntos tratados. 76,3% 57,7%
15 Ritmo sustentável
Esta prática enfatiza que se deve trabalhar apenas a quantidade de horas que se possa manter produtividade de modo sustentável. Não trabalhar mais de 40 horas por semana é a regra, além de não mais de 8 horas por dia. Em períodos difíceis quando se trabalha além do tempo, os artefatos produzidos são pobres em qualidade. Os requisitos devem ser selecionados para cada iteração de modo que os desenvolvedores não precisem trabalhar fora de horário nem fazer horas-extras. 58,1% 42,3%
10 Visibilidade de projeto
Projetos ágeis por sua natureza estão continuamente mudando (planos, modelos, código e demais artefatos). Deve haver esforços para fornecer às equipes o status do projeto em que estão engajadas. A psicologia mostra que quanto mais imediata aretroalimentação, mais rapidamente as pessoas mudam o comportamento para se adequar a novas situações. Pode ser criado um painel na web para manter a qualquer tempo o status e as métricas relacionadas com o progresso do projeto. Múltiplos painéis podem ser usados para disponibilizar diferentes tipos de informação que atendam a todos os níveis organizacionais necessários. O avanço do projeto com relação às históriasde usuário que as equipes se comprometeram a entregar no final das iterações deve ser incluído. Modelos devem se tornar acessíveis para todas as equipes. 88,9% 75,8%
As práticas ágeis 6- Espaço de trabalho aberto e 7- Programação em par foram excluídas em função do resultado do survey.
279
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareBC04 Mapeamento das Práticas Ágeis para as Características de Agilidade
Características
Adaptabilidade
Auto-organi-zação
Emer-
gência
Equipes peque-
nas
Incorpora-ção de
Retroali-mentação (feedback)
Lean-ness
Modu-larida-
de
Orienta-ção a
Pessoas
Reflexão e Introspec-
ção
Ser Cola-bo-
rativo
Ser Coo-pe-
rativo
Ser Incre-men-
tal
Ser Iterati-
vo
Testes Constan-
tes
Time Bo-xing
Trans-pa-
rênciaPráticas Id 4 5 9 16 10 11 13 14 15 1 2 3 6 7 17 18
Backlog de produto 9 0 1 1 0 0 1 0 0 1 1 1 1 1 0 0 0Cliente presente 5 1 0 1 0 1 1 0 1 1 1 1 1 1 0 0 0Desenvolvimento orientado a testes 16 0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0
Design simples 12 1 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0Equipe completa 17 1 1 0 0 0 1 0 1 1 0 0 0 0 0 1 0Integração contínua 3 0 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0Jogo de planejamento 8 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0Metáfora 4 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0Padrões de código 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0Propriedade coletiva do código 2 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0
Refatoração 11 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Releases curtas 13 1 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0Reuniões diárias 14 0 1 1 0 1 0 0 1 1 1 0 0 0 0 0 0Ritmo sustentável 15 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0Visibilidade de projeto 10 1 1 0 0 1 1 0 1 1 0 0 0 0 0 0 0
As características 8- Convergência e 12- Equipes Locais foram excluídas em função do resultado do survey. As práticas ágeis 6- Espaço de trabalho aberto e 7- Programação em par foram excluídas em função do resultado do survey.
280
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareBC05 Mapeamento das Práticas Ágeis para as Atividades de Teste
Atividades
Planejar Testes
Projetar Testes
Especificar Casos de
Teste
Definir Procedimen-tos de Teste.
Executar Testes
Analisar Resultados
Monitorar e Controlar Processo de Teste
Fechar Atividades de Teste
Práticas Id 1 2 3 4 5 6 7 8
Backlog de produto 9 1 0 0 0 0 0 0 0
Cliente presente 5 1 1 0 0 0 0 0 0
Desenvolvimento orientado a testes 16 0 0 0 0 0 0 0 0Design simples 12 0 1 1 1 0 0 0 0
Equipe completa 17 0 1 1 0 0 0 0 0Integração contínua 3 0 0 0 0 0 0 0 0
Jogo de planejamento 8 1 1 0 0 0 0 0 0
Metáfora 4 1 1 0 0 0 0 0 0Padrões de código 1 0 0 0 0 0 0 0 0
Propriedade coletiva do código 2 0 0 0 0 0 0 0 0Refatoração 11 0 0 0 0 0 0 0 0Releases curtas 13 0 0 0 0 1 1 1 0Reuniões diárias 14 1 1 1 1 1 1 1 0
Ritmo sustentável 15 0 0 0 0 0 0 0 0
Visibilidade de projeto 10 1 1 1 1 1 1 1 0
As práticas ágeis 6- Espaço de trabalho aberto e 7- Programação em par foram excluídas em função do resultado do survey.
281
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareBC06 Histórico de Projetos - Atributos de Caracterização e Status
Id Parâmetro
Exemplos de Valores
Alternativos21 Id do Projeto22 Descrição Sucinta do Projeto
23 Status do ProjetoIniciado, Concluido, Avaliado
24 Data Início do Projeto25 Data Término do Projeto26 Representante do Cliente
27Representante da Equipe de Desenvolvimento
28Código da Equipe de Desenvolvimento
29
Data de Planejamento da Agilidade p/ Proc Teste do Projeto
30Data de Avaliação da Agilidade do Proc Teste do Projeto
31Resultado Final da Avaliação do Processo de Teste
Sucesso, Fracasso, Não definido
1 Modelo de Ciclo de VidaIterativo e incremental, RAD, Espiral, .....
2 Duração Estimada do Projeto Número de meses
3Indicador de Complexidade do Problema
Muito Alta, Alta, Média, Baixa, Muito Baixa
4Indicador de Instabilidade dos Requisitos
Muito Alta, Alta, Média, Baixa, Muito Baixa
5 Tamanho da Equipe do ProjetoQuantidade de pessoas
6 Criticalidade do ProjetoMuito Alta, Alta, Média, Baixa, Muito Baixa
7 Ambiente Físico Localizado, Distribuído
8 Plataforma de ExecuçãoSistema embarcado, Web, Desktop, ...
9 Domínio da AplicaçãoContábil, Bancário, Estoques, Vendas, ...
Id Parâmetro Projeto 1 Projeto 2 Projeto 1021 Id do Projeto 1 2 10
22 Descrição Sucinta do ProjetoControle Patrimonial da Instituição
Custeio de Veículos
Gerencia de Plano Contábil
23 Status do Projeto Concluído Concluído Concluído24 Data Início do Projeto 15/fev/10 15/mar/09 19/jul/1025 Data Término do Projeto 18/dez/10 22/out/09 27/jan/1126 Representante do Cliente Michelangelo Portinari Mozart
27Representante da Equipe de Desenvolvimento Desenvolvedor 5
Desenvolvedor 11
Desenvolvedor 4
28Código da Equipe de Desenvolvimento SD-103 SD-99 SD-33
29Data de Planejamento da Agilidade p/ Proc Teste do 13/fev/10 10/mar/09 17/jul/10
282
Projeto
30Data de Avaliação da Agilidade do Proc Teste do Projeto 19/dez/10 30/out/09 30/jan/11
31Resultado Final da Avaliação do Processo de Teste Não definido Fracasso Sucesso
1 Modelo de Ciclo de Vida Cascata CascataIterativo e incremental
2 Duração Estimada do Projeto 9 meses 7 meses 6
3Indicador de Complexidade do Problema Baixa Baixa Média
4Indicador de Instabilidade dos Requisitos Alta Média Média
5 Tamanho da Equipe do Projeto 8 5 66 Criticalidade do Projeto Muito Baixa Baixa Baixa7 Ambiente Físico Localizado Localizado Localizado8 Plataforma de Execução Desktop Web Web
9 Domínio da AplicaçãoAdministração Patrimonial
Administração de Equipamentos Contábil
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareBC07 Histórico de Projetos - Práticas Avaliadas
Id Proje-
to
Id Prática Prática Quesito Avaliado
Avali-ação
Va-lor
Má-ximo
Va-lor
Atri-bui-do
Grau Avaliação da Práti-
ca
Evi-dên-cias
Descrição Prática
10 9Backlog de produto
1- Grau em que foi adotada e seguida Alto 2 2
10 9Backlog de produto
2- Contribuição para o sucesso das atividades de teste Médio 2 1
75,0%
10 10Visibilidade de projeto
1- Grau em que foi adotada e seguida Médio 2 1
10 10Visibilidade de projeto
2- Contribuição para o sucesso das atividades de teste Alta 2 2
75,0%
10
Estratégia de comprometimento por partes
1- Grau em que foi adotada e seguida Alto 2 2
Criação de 3 conjun-tos alterna-tivos de requisitos para ade-quar à liberação parcial de orçamento
283
10
Estratégia de comprometimento por partes
2- Contribuição para o sucesso das atividades de teste
Alto 2 2100,0
%
Criação de 3 conjun-tos alterna-tivos de requisitos para ade-quar à liberação parcial de orçamento
10 4 Metáfora
1- Grau em que foi adotada e seguida Baixo 2 0
10 4 Metáfora
2- Contribuição para o sucesso das atividades de teste Baixo 2 0 0,0%
10
3- Adequação das prioridades planejadas para as práticas Alta 2 2
10
4- Resultado das práticas para o processo de testes
Muito bom 2 2
TOTALIZADORES
20 14
Nível avaliado de sucesso: 70,0%
Limite Nível Sucesso: 50,0%
Nível (is) de teste em que o guia foi utilizado: Sistema
Comentários (texto livre) sobre o desempenho do processo de teste em termos de agilidade:
E-4 Grupo de Formulários Guia de Agilidade (GA01 – GA09)
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA01 Caracterização do Projeto de Software
Insira os valores para o seu projeto na coluna em amarelo:(na planilha BC06 há exemplos do histórico de projetos; na planilha GA01a há detalhes sobre os valores)
Id ParâmetroExemplos de Valores
AlternativosNovo Projeto sendo
Planejado21 Id do Projeto22 Descrição Sucinta do Projeto23 Status do Projeto Iniciado, Concluido,
284
Avaliado
24 Data Início do Projeto25 Data Término do Projeto26 Representante do Cliente
27Representante da Equipe de Desenvolvimento
28Código da Equipe de Desenvolvimento
29Data de Planejamento da Agilidade p/ Proc Teste do Projeto
30Data de Avaliação da Agilidade do Proc Teste do Projeto
31Resultado Final da Avaliação do Processo de Teste
Sucesso, Fracasso, Não definido
1 Modelo de Ciclo de VidaIterativo e incremental, RAD, Espiral, .....
2 Duração Estimada do Projeto Número de meses
3Indicador de Complexidade do Problema
Muito Alta, Alta, Média, Baixa, Muito Baixa
4Indicador de Instabilidade dos Requisitos
Muito Alta, Alta, Média, Baixa, Muito Baixa
5 Tamanho da Equipe do Projeto Quantidade de pessoas
6 Criticalidade do ProjetoMuito Alta, Alta, Média, Baixa, Muito Baixa
7 Ambiente Físico Localizado, Distribuído
8 Plataforma de ExecuçãoSistema embarcado, Web, Desktop, ...
9 Domínio da AplicaçãoContábil, Bancário, Estoques, Vendas, ...
Após completar o preenchimento, prossiga com a planilha GA02
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA01a Detalhes sobre Valores de Atributos de Projeto
3- Indicador de Complexidade do Problema: este indicador será utilizado tanto para apurar a semelhança com projetos já concluídos e avaliados, quanto para apurar o grau de adequação do projeto com as abordagens ágeis. As possibilidades de classificação serão mapeadas para os valores: 4- Muito Baixa, para projetos que não envolvem cálculos complexos nem regras de negócio complicadas; 3- Baixa, para projetos que envolvem cálculos pouco complexos ou regras de negócio um pouco complicadas; 2- Média, para projetos que envolvem cálculos complexos ou regras de negócio complicadas; 1- Alta, para projetos que envolvem cálculos significativamente complexos ou regras de negócio significativamente complicadas; 0- Muito Alta, para projetos que envolvem cálculos muito complexos ou regras de negócio muito complicadas. Quanto menos complexo o processamento envolvido (valores mais altos), mais adequada é a abordagem ágil para ser aplicada no projeto.
4- Indicador de Instabilidade dos Requisitos: este indicador será utilizado tanto para apurar a semelhança com projetos já concluídos e avaliados, quanto para apurar o grau de adequação do projeto com as abordagens ágeis. As possibilidades de classificação serão mapeadas para os valores: 4- Muito Alta, para requisitos muito instáveis, com risco muito alto de afetar o escopo do projeto; 3- Alta, requisitos instáveis com razoável risco de afetar o escopo do projeto; 2- Média, para requisitos com grau médio de estabilidade, com algum grau de risco de afetar o escopo do
285
projeto; 1- Baixa, requisitos praticamente estáveis com baixo risco de afetar o escopo do projeto; 0- Muito Baixa, requisitos estáveis, praticamente sem risco de afetar o escopo do projeto. Quanto menos estáveis os requisitos (valores mais altos), mais adequada é a abordagem ágil para ser aplicada no projeto.
6- Criticalidade do Projeto: este indicador será utilizado tanto para apurar a semelhança com projetos já concluídos e avaliados, quanto para apurar o grau de adequação do projeto com as abordagens ágeis. As possibilidades de classificação serão mapeadas para os valores que se seguem, adaptadas dos níveis de criticalidade de um projeto apresentados por Cockburn (2002a): 0- Muito Baixa, falhas do software podem causar desconfortos como atrasos na entrega de algum produto ou serviço ou longos tempos de espera; (-1)- Baixa, falhas do software podem resultar em perdas de recursos que podem ser recuperados sem maiores problemas; (-4)- Média, falhas do software podem resultar em perdas de recursos que podem ser recuperados, mas com dificuldade razoável; (-5)- Alta, falhas do software podem resultar em perdas de recursos que não podem mais ser recuperados; (-8)- Muito Alta, falhas do software podem resultar em grave ameaça a lesões corporais ou a perda de vida(s). Quanto menos graves os riscos (valores mais altos), mais adequada é a abordagem ágil para ser aplicada no projeto. Os valores inicialmente atribuídos a este indicador pesam no sentido de contra-indicar a abordagem ágil para o projeto e podem ser ajustados à medida em que a experiência com o guia for avançando.
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA02 Adequação do Projeto às Abordagens Ágeis
Preencha a coluna "Valor Atribuido" conforme os comentários em cada célulaPreencha a opção de prosseguimento (Sim ou Não)
Id ParâmetroValor
InformadoValor
MáximoValor
Atribuido2 Duração Estimada do Projeto 0 4
3Indicador de Complexidade do Problema 0 4
4Indicador de Instabilidade dos Requisitos 0 4
5 Tamanho da Equipe do Projeto 0 46 Criticalidade do Projeto 0 0
TOTALIZADORES 16
Grau de adequação do projeto com as abordagens ágeis 56,3% Mínimo = 50,0%
Prossguir com o planejamento da agilidade?
Sim ou Não Resp:
Recomenda-se escolher o prosseguimento apenas se o grau de adequação estimado estiver igual ou acima de 50%.Contudo, tentativa de proesseguimento pode ser feitas se o interessado julgar conveniente.
Se sua decisão for continuar o planejamento da agilidade para o processo de teste, então prossiga com a planilha GA03Caso contrário o planejamento deve ser interrompido agora, neste ponto.
286
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA03 Escolha e Priorização das Características de Agilidade
Preencha a coluna em amarelo com suas escolhas (valor 1 para as escolhidas).Manter o valor 99 para as características que você não deseja no processo de teste.Se necessário, consulte a planilha BC01 para ver o significado de cada característica, não esquecendo que sua planilha de retorno é a G03.
Prioridada-de 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99
Id 4 5 9 16 10 11 13 14 15 1 2 3 6 7 17 18
Caracterís-tica
Adapta-bili-dade
Auto-orga-ni-zação
E-mer-gên-cia
Equipes pequenas
Incorpora-ção de Retroali-mentação (feedback)
Lean-ness
Modu-laridade
Orien-tação a Pessoas
Reflexão e Intros-pecção
Ser Cola-bo-rativo
Ser Coo-pe-rati-vo
Ser Incre-mental
Ser Iterati-vo
Testes Cons-tantes
Time-boxing
Trans-pa-rên-cia
Após preenchimento, prossiga com a planilha GA05.(Atenção, não precisa haver preenchimento da planilha G04)
287
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA04 Obtenção das Práticas Mapeadas
Atenção: não deve haver preenchimento nesta planilha
100,0% 76,3% 74,1% 71,6% 79,7% 61,3% 64,4% 98,4% 98,4% 94,1% 90,9% 94,1% 92,5% 93,8% 93,1% 61,6%
Características
Adap-tabili-dade
Auto-orga-
ni-zação
Emer-gên-cia
Equi-pes
pequenas
Incor-poração de
Retroali-mentação (feedback)
Leanness
Mo-du-
larida-de
Orien-tação a Pes-soas
Refle-xão e Intros-pecção
Ser Cola-bo-
rativo
Ser Coo-pe-
rativo
Ser Incre-men-
tal
Ser Ite-rati-
vo
Testes Cons-tantes
Time Bo-xing
Transpa-
rência
Se-le-ção
To-tais
Grau cada
práticaPráticas Id 4 5 9 16 10 11 13 14 15 1 2 3 6 7 17 18
Backlog de produto 9 0 1 1 0 0 1 0 0 1 1 1 1 1 0 0 0 0 8Cliente presente 5 1 0 1 0 1 1 0 1 1 1 1 1 1 0 0 0 0 10Desenvolvimento orientado a testes 16 0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0 0 4
Design simples 12 1 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0 4Equipe completa 17 1 1 0 0 0 1 0 1 1 0 0 0 0 0 1 0 0 6Integração contínua 3 0 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0 0 4Jogo de planejamento 8 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0 0 3Metáfora 4 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1Padrões de código 1 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 2Propriedade coletiva do código 2 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 2
Refatoração 11 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1Releases curtas 13 1 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0 0 4Reuniões diárias 14 0 1 1 0 1 0 0 1 1 1 0 0 0 0 0 0 0 6Ritmo sustentável 15 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1Visibilidade de projeto 10 1 1 0 0 1 1 0 1 1 0 0 0 0 0 0 0 0 6
Caract. Selecionadas: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
As características 8- Convergência e 12- Equipes Locais foram excluídas em função do resultado do survey. As práticas ágeis 6- Espaço de trabalho aberto e 7- Programação em par foram excluídas em função do resultado do survey.
288
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA05 Seleção das Atividades de Teste de Software para o Projeto
Preencha a coluna em amarelo com suas escolhas, digitando o valor 1 no lugar do valor 99.Manter o valor 99 para as atividades que você não deseja ou não executa no processo de teste.Se necessário, consulte a planilha BC02 para ver o significado de cada atividade, não esquecendo que sua planilha de retorno é a GA05.
Atividades de Teste Adicionais (optativas)
Prioridadade 99 99 99 99 99 99 99 99 101 102
Id 1 2 3 4 5 6 7 8 Nome DescriçãoProd Trab Nome Descrição
Prod Trab
AtividadePlanejar Testes
Projetar Testes
Especificar Casos de Teste
Definir Procedimen-tos de Teste.
Executar Testes
Analisar Resultados
Monitorar e Controlar Processo de Teste
Fechar Atividades de Teste
Se desejar, você pode incluir até duas atividades de teste adicionais descrevendo para cada uma: nome, descrição e produtos de trabalho gerados.Se necessário para se orientar, consulte a planilha BC02, não esquecendo de retornar para esta planilha GA05.
Após preenchimento, prossiga com a planilha GA06.(Atenção, não precisa haver preenchimento das planilhas GA05a GA05b)
289
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA05a Restrições pelas Atividades de Teste
Atenção: não deve haver preenchimento nesta planilha
Atividades
Planejar Testes
Projetar Testes
Especificar Casos de
Teste
Definir Procedimen-tos de Teste
Executar Testes
Analisar Resultados
Monitorar e
Controlar Processo de Teste
Fechar Atividades de Teste Totais
Seleção
Práticas Id 1 2 3 4 5 6 7 8
Backlog de produto 9 1 0 0 0 0 0 0 0 1 0Cliente presente 5 1 1 0 0 0 0 0 0 2 0Desenvolvimento orientado a testes 16
0 0 0 0 0 0 0 00 0
Design simples 12 0 1 1 1 0 0 0 0 3 0Equipe completa 17 0 1 1 0 0 0 0 0 2 0Integração contínua 3 0 0 0 0 0 0 0 0 0 0Jogo de planejamento 8 1 1 0 0 0 0 0 0 2 0Metáfora 4 1 1 0 0 0 0 0 0 2 0Padrões de código 1 0 0 0 0 0 0 0 0 0 0Propriedade coletiva do código 2 0 0 0 0 0 0 0 0 0 0Refatoração 11 0 0 0 0 0 0 0 0 0 0Releases curtas 13 0 0 0 0 1 1 1 0 3 0Reuniões diárias 14 1 1 1 1 1 1 1 0 7 0Ritmo sustentável 15 0 0 0 0 0 0 0 0 0 0Visibilidade de projeto 10 1 1 1 1 1 1 1 0 7 0
Atividades Selecionadas: 0 0 0 0 0 0 0 0
290
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA05b Atualização das Práticas Mapeadas
Atenção: não deve haver preenchimento desta planilha
Selecionadas pelas
Atividades
Selecionadas pelas
CaracterísticasSeleção
CompostaPráticas Id
Backlog de produto 9 0 0 0
Cliente presente 5 0 0 0Desenvolvimento orientado a testes 16 0 0 0
Design simples 12 0 0 0Equipe completa 17 0 0 0
Integração contínua 3 0 0 0
Jogo de planejamento 8 0 0 0
Metáfora 4 0 0 0
Padrões de código 1 0 0 0Propriedade coletiva do código 2 0 0 0
Refatoração 11 0 0 0
Liberações frequentes 13 0 0 0
Reuniões diárias 14 0 0 0
Ritmo sustentável 15 0 0 0
Visibilidade de projeto 10 0 0 0
291
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA06 Sugestão de Práticas a serem Adotadas Aqui você pode ter uma idéia das
práticas candidatas a serem inseridas no processo de teste do projeto, por diferentes prioridades: 1- selecionadas pelas características escolhidas por você, 2- pelo grau de agilidade estimado para cada uma delas, e 3- pelo nível de relevância das práticas armazenados na base de conhecimento (valores mais altos aumentam chances de sucesso). Na planilha GA06a você pode conhecer os projetos do histórico disponível na base de conhecimento e o grau de similaridade entre cada um deles e o seu projeto. Na planilha GA06b você pode conhecer as práticas dos projetos similares que tiveram desempenho satisfatório nos respectivos projetos concluídos. MAS ATENÇÃO: só utilize dados de projetos do histórico para apoiar sua decisão se os projetos forem de sua organização (se desejar observe a planilha BC06); caso contrário utilize apenas as informações sobre as práticas que estão nesta planilha (GA06) para apoiá-lo em suas escolhas. Você deve prosseguir com o preenchimento da planilha GA07, escolhendo as práticas para o processo de testes do projeto, apoiando-se nas informações desta GA06, e alternativamente nas informações adicionais das planilhas GA06a e GA06b.
Atenção: não deve haver preenchimento nesta planilhaPara visualizar em ordem de prioridade do usuário/cliente, classifique a tabela por col.G, col.DPara visualizar em ordem de grau de agilidade estimado para cada prática, classifique por col.EPara visualizar em ordem de relevância das práticas, classifique por col.F
Seleciona-das pelas Atividades
Selecionadas pelas
Caracterís-ticas
Grau de Agilidade
em Potencial Estimado
Nível de Relevância
das Práticas Seleção Composta
Id Práticas
10 Visibilidade de projeto 0 0 #DIV/0! 75,8% 013 Liberações frequentes 0 0 #DIV/0! 82,4% 014 Reuniões diárias 0 0 #DIV/0! 57,7% 03 Integração contínua 0 0 #DIV/0! 92,1% 09 Backlog de produto 0 0 #DIV/0! 82,7% 011 Refatoração 0 0 #DIV/0! 80,2% 08 Jogo de planejamento 0 0 #DIV/0! 70,7% 012 Design simples 0 0 #DIV/0! 62,9% 01 Padrões de código 0 0 #DIV/0! 55,7% 0
2Propriedade coletiva do código 0 0 #DIV/0! 51,7% 0
16Desenvolvimento orientado a testes 0 0 #DIV/0! 46,2% 0
15 Ritmo sustentável 0 0 #DIV/0! 42,3% 05 Cliente presente 0 0 #DIV/0! 37,3% 017 Equipe completa 0 0 #DIV/0! 34,9% 04 Metáfora 0 0 #DIV/0! 34,6% 0
292
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA06a Coeficiente de Similaridade entre Projetos de Software Atenção: não deve haver preenchimento nesta planilha
Id Parâmetro Projeto 1 Projeto 2 Projeto 1021 Id do Projeto 1 2 10
1 Modelo de Ciclo de Vida Cascata CascataIterativo e incremental
2 Duração Estimada do Projeto 9 meses 7 meses 63 Indicador de Complexidade do Problema Baixa Baixa Média4 Indicador de Estabilidade dos Requisitos Alta Média Média5 Tamanho da Equipe do Projeto 8 5 66 Criticalidade do Projeto Muito Baixa Baixa Baixa7 Ambiente Físico Localizado Localizado Localizado8 Plataforma de Execução Desktop Web Web
9 Domínio da AplicaçãoAdministração Patrimonial
Administração de Equipamentos Contábil
Id Parâmetro Projeto 1 Projeto 2 Projeto 1021 Id do Projeto 1 2 101 Modelo de Ciclo de Vida 0 0 02 Duração Estimada do Projeto 0 0 03 Indicador de Complexidade do Problema 0 0 04 Indicador de Estabilidade dos Requisitos 0 0 05 Tamanho da Equipe do Projeto 0 0 06 Criticalidade do Projeto 0 0 07 Ambiente Físico 0 0 08 Plataforma de Execução 0 0 09 Domínio da Aplicação 0 0 0
Limite: Grau de Similaridade Estimado entre os Projetos: 0,0% 0,0% 0,0% 50,0%
293
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA06b Práticas bem Sucedidas de Projetos Semelhantes com Resultados Satisfatórios
Atenção: não deve haver preenchimento nesta planilha
Id Práticas Grau de Avaliação
- - -- - -- - -- - -
Limite do Grau de Avaliação: 50,0%
As informações desta planilha são alternativas para apoiá-lo em suas decisõesna próxima planilha, GA07 (escolha das práticas para o processo de teste)
294
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA07 Práticas Escolhidas para o Processo de Testes
Na coluna "Escolhidas", marque com 1 (um) as desejadas para o processo de testes do projeto(as demais práticas devem ser mantidas com o valor zero)
Id Práticas Escolhidas
10 - 0Se desejar, utilize a planilha GA06 com práticas sugeridas por 3 diferentes critérios, e/ou a planilha GA06b com práticas bem avaliadas em projetos similares que alcançaram sucesso. Você poderá também inserir práticas que considera importantes e que deseja incluir no seu processo de teste, apesar de não sugerida por este guia. Para tal, preencha até 3 práticas adicionais logo abaixo das práticas sugeridas (preferencialmente com uma breve descrição além do nome). As práticas escolhidas ficarão registradas para posterior avaliação quando o projeto estiver concluído. Você agora poderá verificar o Grau de Agilidade Estimado para o Processo de Teste na planilha GA09.
13 - 014 - 03 - 09 - 011 - 08 - 012 - 01 - 02 - 016 - 015 - 05 - 017 - 04 - 0
- - 0- - 0- - 0- - 0
Práticas Adicionais0 00 00 0
295
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA08 Registro das Práticas Escolhidas
Id Práticas Escolhidas13 - 014 - 010 - 00 0 03 - 09 - 0
11 - 08 - 0
12 - 01 - 02 - 0
16 - 015 - 05 - 0
17 - 04 - 0
- - 0- - 0- - 0- - 0
0 0 00 0 00 0 0
296
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA08a Grau de Agilidade em Potencial Estimado para o Processo de Testes
100,0% 76,3% 71,6% 79,7% 61,3% 64,4% 98,4% 98,4% 94,1% 90,9% 94,1% 92,5% 93,8% 93,1% 61,6% Características
Adaptabili-dade
Auto-orga-
ni-zação
Equi-pes
peque-nas
Incorpora-ção de
Realimen-tação
(feedback)Lean-ness
Modu-larida-
de
Orienta-ção a
Pessoas
Reflexão e Introspe-
cção
Ser Colabo-rativo
Ser Coope-rativo
Ser Incre-mental
Ser Iterati-
vo
Testes Constan-
tes
Time Bo-xing
Trans-pa-
rênciaSele-ção
To-tais
Grau cada
práticaPráticas Id 4 5 16 10 11 13 14 15 1 2 3 6 7 17 18
Backlog de produto 9
0 1 1 0 0 1 0 0 1 1 1 1 1 0 0 0 0
Cliente presente 5 1 0 1 0 1 1 0 1 1 1 1 1 1 0 0 0 0Desenvolvimento orientado a testes 16
0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 0 0
Design simples 12 1 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0Equipe completa 17 1 1 0 0 0 1 0 1 1 0 0 0 0 0 1 0 0Integração contínua 3
0 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0 0Jogo de planejamento 8
0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0 0
Metáfora 4 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0Padrões de código 1
1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0Propriedade coletiva do código 2
0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0
Refatoração 11 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Releases curtas 13 1 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0 0Reuniões diárias 14 0 1 1 0 1 0 0 1 1 1 0 0 0 0 0 0 0Ritmo sustentável 15 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0Visibilidade de projeto 10
1 1 0 0 1 1 0 1 1 0 0 0 0 0 0 0 0
Características Selecionadas: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
As características 8- Convergência e 12- Equipes Locais foram excluídas em função do resultado do survey. As práticas ágeis 6- Espaço de trabalho aberto e 7- Programação em par foram excluídas em função do resultado do survey.
297
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareGA09 Conclusão do Planejamento de Agilidade para o Processo de Teste do Projeto
O planejamento da agilidade para o processo de teste deste projeto -0
está concluido.
O grau de agilidade estimado para o processo de teste é: ****
Armazene todos estes dados para utilização futura.Após o fechamento do projeto, por favor acesse a última planilha (AV01) paraavaliar o resultado alcançado para o projeto em termos de agilidade para o seu processo de teste.
Esta avaliação é importante para o aprimoramento deste guia e seu uso em projetos futuros.
Obrigado.
298
E-5 Grupo de Formulários Avaliação (AV01, AV01a)
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareAV01 Avaliação de Resultados para o Projeto Concluido (Preencher apenas células em amarelo.)
Id Proje-
to
Id Prá-tica
Prá-tica Quesito Avaliado
Avalia-ção
Valor Máxi-
mo
Valor Atri-buido
Grau Avalia-ção da Prática Evidências
Descrição Prática
0 13 -
1- Grau em que foi adotada e seguida
2
0 13 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 14 -1- Grau em que foi adotada e seguida 2
0 14 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 10 -
1- Grau em que foi adotada e seguida
2
0 10 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 0 0
1- Grau em que foi adotada e seguida
2
0 0 0
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 3 -
1- Grau em que foi adotada e seguida
2
0 3 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 9 -
1- Grau em que foi adotada e seguida
2
0 9 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 11 -
1- Grau em que foi adotada e seguida
2
0 11 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 8 -
1- Grau em que foi adotada e seguida
2
0 8 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 12 -
1- Grau em que foi adotada e seguida
2
299
0 12 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 1 -
1- Grau em que foi adotada e seguida
2
0 1 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 2 -
1- Grau em que foi adotada e seguida
2
0 2 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 16 -
1- Grau em que foi adotada e seguida
2
0 16 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 15 -
1- Grau em que foi adotada e seguida
2
0 15 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 5 -
1- Grau em que foi adotada e seguida
2
0 5 -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 0 0
1- Grau em que foi adotada e seguida
2
0 0 0
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 - -
1- Grau em que foi adotada e seguida
2
0 - -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 - -
1- Grau em que foi adotada e seguida
2
0 - -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 - -
1- Grau em que foi adotada e seguida
2
0 - -
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 0
1- Grau em que foi adotada e seguida
2
0 0
2- Contribuição para o sucesso das atividades de teste 2 0,0%
300
0 0 0
1- Grau em que foi adotada e seguida
2
0 0 0
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0 0 0
1- Grau em que foi adotada e seguida
2
0 0 0
2- Contribuição para o sucesso das atividades de teste 2 0,0%
0
3- Adequação das prioridades planejadas para as práticas 2
0
4- Resultado das práticas para o processo de testes 2
TOTALIZADORES 92 0
Nível avaliado de sucesso: 0,0% Limite: 50,0%
Nível (is) de teste em que o guia foi utilizado:Comentários (texto livre) sobre o desempenho do processo de teste em termos de agilidade:
Guia para Planejamento de Agilidade em Processos de Teste de SoftwareAV01a Detalhes sobre a Avaliação das Práticas
1- Em que grau as práticas planejadas foram efetivamente adotadas e seguidas durante a execução das atividades de teste? Para cada prática, a seguinte classificação será considerada: 2- Alto, efetivamente adotada e seguida; 1- Médio, adotada e seguida parcialmente; 0- Baixo, praticamente não foi seguida ou não foi adotada
2- A partir dos resultados observados, qual o grau de adequação em que cada prática contribuiu para as características de agilidade e para o sucesso das respectivas atividades do processo de teste de software, quanto à agilidade? Para cada prática adotada será informado o grau de adequação, com a seguinte classificação: 2- Alto, a prática contribui em alto grau para o sucesso da atividade; 1-Médio, a prática contribui modestamente para o sucesso da atividade; 0-Baixo, a prática não contribui para o sucesso da atividade. Também serão solicitadas as evidências observadas durante a execução do processo de teste de software que justificam as respostas para cada prática avaliada.
3- Qual a adequação das prioridades planejadas para as práticas ágeis no processo de teste de software? Os graus de agilidade estimados para cada prática selecionada receberiam a seguinte classificação: 2- Alta adequação, a ordem da maioria das práticas sugeridas parecem coerentes com os resultados que elas alcançaram; 1- Média adequação, a ordem de algumas práticas sugeridas está discrepante em relação ao resultado que elas alcançaram; 0- Baixa adequação, a
301
ordem das práticas sugeridas está significativamente diferente em relação ao resultado que elas alcançaram.
4- Qual o grau atribuído ao resultado final da aplicação do conjunto de práticas planejadas, no processo de teste de software, com relação à agilidade do mesmo? 2-Bom, o processo de teste de software teve condições de se adaptar sem maiores problemas quando mudanças não previstas se apresentaram; 1- Razoável, o processo de teste de software conseguiu se adaptar com alguma dificuldade, mas atendeu a mudanças não previstas que se apresentaram durante a execução do projeto; 0- Ruim, o processo de teste de software teve grandes dificuldades para se adaptar ou não conseguiu se adaptar a mudanças não previstas que se apresentaram durante sua execução. Também serão solicitadas as evidências observadas durante a execução do processo de teste de software que justificam a resposta.
302
Apêndice F Análise Detalhada dos Resultados da Revisão dos Mapeamentos entre Práticas Ágeis e
Características de Agilidade
Dos mapeamentos entre práticas ágeis e características de agilidade revisados
(240 mapeamentos), 2 foram suprimidos e 10 foram adicionados, em decorrência dos
resultados da revisão por pares. A seguir são apresentadas as discrepâncias observadas,
as análises destas discrepâncias e as decisões tomadas quanto aos mapeamentos entre
práticas ágeis e características de agilidade que não geraram modificações em relação ao
previamente estabelecido e apresentado no capítulo 6.
F.1 Discordâncias dos Mapeamentos Previamente Estabelecidos (Práticas X
Características)
Para cada mapeamento entre as práticas ágeis e as características de agilidade,
separados por grupo e para cada revisor, as justificativa para as discordâncias quanto
aos mapeamentos que foram previamente estabelecidos serão apresentadas e analisadas
conforme se segue. Os revisores não serão identificados, sendo aqui referenciados por
um código alfanumérico de acordo com a Tabela 6-5. Os critérios utilizados foram
apresentados na seção 6.9.3.
Grupo 1
Prática: Design simples
Característica: Orientação a Pessoas
Justificativa revisor G1-7: “Não vejo qualquer associação neste caso.”
Análise: O texto da justificativa precisa ser adaptado para mostrar com mais
clareza o relacionamento: a prática enfatiza a idéia de evitar complexidade
desnecessária nos artefatos de projeto produzidos, sendo que tais artefatos
contribuem para melhorar a comunicação entre membros da equipe de
desenvolvimento, sendo esta comunicação um elemento fundamental e
necessário, como está na descrição da característica.
Decisão: manter o mapeamento.
303
Grupo 2
Prática: Desenvolvimento orientado a testes
Característica: Orientação a Pessoas
Justificativa revisor G2-1: “Se o desenvolvimento orientado a testes é um
processo, então não concordo que essa prática privilegie pessoas em detrimento
de processos.”
Análise: A abrangência do significado de processo é ampla e talvez se possa
apresentar considerações válidas para classificar o desenvolvimento orientado a
testes como um processo. Contudo, no contexto das abordagens ágeis,
desenvolvimento orientado a testes é em geral tratado e descrito por proponentes
de diversas metodologias ágeis, como uma prática, não um processo. Além
disso, não há, na descrição da prática, indícios nos quais se basear para rotular
esta prática como um processo. No máximo, a análise da descrição da prática
pode levar ao entendimento de que ela seja uma estratégia de desenvolvimento,
mas não um processo. Contudo, independentemente da classificação ou não da
prática como um processo, ela aumenta as chances de um trabalho produzido
com qualidade melhor do que sem sua adoção em um processo de software. A
qualidade do produto é um dos indicadores que os desenvolvedores são
encorajados a melhorar, como se depreende claramente pela descrição da
característica. Se a prática facilita a obtenção de qualidade no produto, então ela
fortalece os desenvolvedores que o produzem, e assim tem relacionamento com
a orientação a pessoas.
Decisão: manter o mapeamento.
Prática: Integração contínua
Característica: Leanness
Justificativa revisor G2-1: “Não concordo que integração contínua contribui com
redução de custos, pois existe um esforço extra para codificar os testes
automatizados, compensando o esforço reduzido na remoção de defeitos.”
Análise: Independentemente de ser contínua ou não, os testes de integração
terão que ser executados, sob pena de repassar problemas para serem detectados
só a nível de teste de sistema, com custos ainda mais elevados. A eliminação de
perdas é uma idéia central na descrição desta característica. O questionamento
304
pode sim se prender à questão de qual é a maneira mais adequada de se
implementar a prática em uma determinada organização desenvolvedora.
Implementações diferentes terão também custos diferentes, e a definição da
opção mais adequada é ponto crucial para o sucesso desta prática.
Decisão: manter o mapeamento.
Grupo 3
Prática: Equipe completa
Característica: Orientação a Pessoas
Justificativa revisor G3-7: “Acho que trata-se de dois temas diferentes. A prática
implica em ter todos os perfis dentro da equipe, mas não necessariamente de ter
uma maior orientação às pessoas. É possível que haja formalismos e que estes
precedam as características, propostas e anseios das pessoas.”
Análise: As questões apresentadas estão relacionadas com o modo como se
implementa a prática na organização. Se formalismos forem necessários para
implementá-la na organização, eles deverão ser adequados para que a prática
possa produzir os efeitos desejados. Diferentes perfis, compartilhando um
propósito e apoiando-se mutuamente podem sim apoiar a busca de melhoria de
produtividade, qualidade e desempenho do trabalho das pessoas.
Decisão: manter o mapeamento.
Prática: Metáfora
Característica: Orientação a Pessoas
Justificativa revisor G3-7: “Mais uma vez, a prática e a característica parecem
estar tratando de temas diferentes. A metáfora trata de uma analogia entre o tema
do projeto e um conceito conhecido pela equipe, com a intenção de facilitar a
comunicação. Neste sentido, concordo com o embasamento. No entanto, ele não
implica em uma orientação a pessoas. Senti falta de algo que eu caracterizaria
como uma característica que, se não me falha a memória, aparece no XP do Kent
Beck. Ela seria o "Travel Light", que considero muito ligado à metáfora. Você
usa a metáfora para resumir o conhecimento sobre o projeto e reduzir o número
de artefatos produzidos. É discutível, mas está lá.”
305
Análise: A comunicação é um elemento fundamental da característica
Orientação à Pessoas e a prática contribui para a comunicação. O revisor
concorda neste sentido, como ele próprio registra em seu comentário. A questão
colocada prende-se mais a falta de um outro conceito que tem associação com
uma metodologia específica, o que foi evitado e descartado nas execuções das
revisões sistemáticas que identificaram as características.
Decisão: manter o mapeamento.
Prática: Reuniões Diárias
Característica: Emergência
Justificativa revisor G3-7: “Entendo a emergência dos processos como a
característica que faz com que estes processos surjam de forma autônoma a
medida que a equipe realiza o seu trabalho. Sendo assim, qual seria a relação
com as reuniões diárias.”
Análise: A prática visa o acompanhamento diário do progresso do projeto, o
destaque de questões importantes e a organização das atividades diárias. A
oportunidade de evidenciar estas 3 questões diariamente pode apoiar o
reconhecimento e adoção de estruturas de trabalho, princípios e tecnologias mais
adequados durante o desenvolvimento do software.
Decisão: manter o mapeamento.
Prática: Visibilidade de Projeto
Característica: Orientação a Pessoas
Justificativa revisor G3-7: “Também não acho que a visibilidade esteja ligado
com a orientação a pessoas. Pode haver algum relacionamento aqui se você
puxar para o lado da psicologia, aumentando o buy-in das pessoas no projeto por
conta delas estarem cientes quanto ao seu acompanhamento, mas creio que é um
argumento fraco. Precisaria ser testado e embasado com outras referências. Mas
ainda assim, acho que o principal problema aqui é que orientação a pessoas é
uma característica muito vaga - talvez você possa definir melhor o que entende
por ela.”
Análise: A descrição da característica inclui claramente a comunicação como
sendo um de seus elementos fundamentais. A prática enfatiza a importância da
306
visibilidade de artefatos atualizados disponíveis para as equipes, comunicando o
status do projeto. Portanto pode a prática apoiar um elemento fundamental da
característica, de modo prático e objetivo, embora a questão de psicologia
levantada pelo revisor também faça sentido, mas não está ligada ao contexto
desta pesquisa.
Decisão: manter o mapeamento.
F.2 Discordâncias das Justificativas para Mapeamentos Previamente
Estabelecidos (Práticas X Características)
Um revisor do grupo 1 apresentou uma argumentação que resultou em um
mapeamento suprimido, cuja análise de resultado foi apresentada na seção 6.9.3.1.2. Os
demais revisores dos grupos 2 e 3 concordaram com as justificativas apresentadas para
cada um dos mapeamentos entre práticas ágeis e características de agilidade.
F.3 Mapeamentos Adicionais Sugeridos (Práticas X Características)
Para cada mapeamento adicional entre as práticas ágeis e as características de
agilidade identificado pelos revisores, separados por grupo e para cada revisor, as
justificativas para inclusão do novo mapeamento serão apresentadas e analisadas. Os
revisores não serão identificados, sendo também aqui referenciados por um código
alfanumérico de acordo com a Tabela 6-5. Os critérios utilizados foram apresentados na
seção 6.9.3. Serão apresentadas aqui apenas as análise das sugestões que não geraram
modificações nos mapeamentos previamente estabelecidos.
Grupo 1
Prática: Backlog de Produto
Característica: Incorporação de Realimentação
Justificativa revisor G1-7: “O backlog, como instrumento de comunicação, apóia
a retroalimentação contínua.”
Análise: O conhecimento do trabalho a ser feito para se chegar ao produto final
não necessariamente significa capacidade para buscar e incorporar realimentação
contínua e rapidamente.
Decisão: não adicionar o mapeamento.
307
Prática: Backlog de Produto
Característica: Modularidade
Justificativa revisor G1-4: “dependendo da estrutura e da organização do
backlog, alguns dos processos (e as atividades que o compõem) poderão ser
definidos de uma forma mais simples facilitando a sua divisão”
Análise: Não há clareza nesta argumentação; o conhecimento do trabalho a ser
feito para se chegar ao produto pode apoiar a identificação de componentes a
serem adicionados ou removidos, mas não necessariamente viabiliza essa adição
ou remoção.
Decisão: não adicionar o mapeamento.
Prática: Cliente presente
Característica: Auto-organização
Justificativa revisor G1-7: “o cliente é parte da equipe. Participa de sua
reorganização.”
Análise: A auto-organização é uma característica que está atrelada à equipe de
desenvolvimento, que pode apresentá-la ou não, independentemente de ter o
cliente como parte da equipe.
Decisão: não adicionar o mapeamento.
Prática: Design simples
Característica: Ser Colaborativo
Justificativa revisor G1-4: “artefatos simples favorecem a comunicação entre os
desenvolvedores (os nivela de uma forma mais homogênea para que possam se
comunicar melhor)“
Análise: Embora os artefatos simples possam não prejudicar a comunicação, não
há, na descrição da prática, nada relacionado com comunicação ou com
integração rápida de incrementos de software.
Decisão: não adicionar o mapeamento.
Prática: Design simples
Característica: Testes Constantes
308
Justificativa revisor G1-4: “código simples facilita a implementação de testes”
Análise: A remoção de complexidade desnecessária e de código extra não
apóiam diretamente a aplicação contínua de testes para garantir que as
funcionalidades operem adequadamente.
Decisão: não adicionar o mapeamento.
Prática: Propriedade coletiva de código
Característica: Auto-organização
Justificativa revisor G1-7: “a visibilidade comum do código facilita a auto-
organização”
Análise: O conhecimento do código escrito por outros não necessariamente
apóia capacidade para definir as melhores maneiras de organizar as equipes.
Decisão: não adicionar o mapeamento.
Prática: Propriedade coletiva de código
Característica: Incorporação de Realimentação
Justificativa revisor G1-7: “o código torna-se meio de comunicação”
Análise: O conhecimento do código escrito por outros não necessariamente
apóia busca contínua, freqüente e rápida de retroalimentação.
Decisão: não adicionar o mapeamento.
Prática: Propriedade coletiva de código
Característica: Ser Cooperativo
Justificativa revisor G1-7: “ter o código com acesso coletivo é claramente
privilegiar a equipe, dando-lhe responsabilidade.”
Análise: Não há elementos na descrição da prática que permitam identificar
apoio à interação aberta entre o cliente e os desenvolvedores.
Decisão: não adicionar o mapeamento.
Prática: Refatoração
Característica: Emergência
Justificativa revisor G1-4: “código simples e refatorado pode facilitar a
implementação de novos requisitos emergentes”
309
Análise: O código refatorado não necessariamente contribui de forma direta para
que estruturas de trabalho ou tecnologias surjam durante o ciclo de vida do
produto.
Decisão: não adicionar o mapeamento.
Prática: Refatoração
Característica: Modularidade
Justificativa revisor G1-7: “o resultado da refatoração não contribui para a
modularidade?”
Análise: O revisor não tem certeza desta justificativa. Não há indícios na
descrição da modularidade (aqui trata-se do processo) de que ela possa ser
apoiada por artefatos refatorados.
Decisão: não adicionar o mapeamento.
Prática: Refatoração
Característica: Testes Constantes
Justificativa revisor G1-7: “a refatoração implica na necessidade de testes.
Quanto mais robusto o código, mais segurança em sua refatoração e vice-versa?”
Análise: A refatoração demanda testes (não necessariamente constantes) mas
não apóia a constância dos teses.
Decisão: não adicionar o mapeamento.
Grupo 2
Prática: Desenvolvimento orientado a testes
Característica: Ser Colaborativo
Justificativa revisor G2-3: “As atividades realizadas de integração e
comunicação são facilitadas e deste modo também a escrita dos testes“
Análise: A estratégia de escrever testes antes do código não implica em processo
colaborativo.
Decisão: não adicionar o mapeamento.
Prática: Desenvolvimento orientado a testes
Característica: Reflexão e Introspecção
310
Justificativa revisor G2-5: “creio que esta característica facilita avaliar (testar) o
que foi feito de bom e o que precisa melhorar e deveria ser incluída”
Análise: A estratégia de escrever testes antes do código não necessariamente
apóia, ao final das iterações, avaliar o que está sendo bem feito e o que precisa
ser melhorado.
Decisão: não adicionar o mapeamento.
Prática: Integração contínua
Característica: Modularidade
Justificativa revisor G2-5: “pelo fato de se desenvolver por modulo, a cada
interação fica mais fácil incluir ou remover módulos facilmente, de acordo com
os resultados da interação. Creio que esta característica deva ser incluída”
Análise: Houve um engano por parte do revisor quanto ao significado da
característica.
Decisão: não adicionar o mapeamento.
Prática: Integração contínua
Característica: Ser Colaborativo
Justificativa revisor G2-4: “Apóia a comunicação entre os participantes para a
integração rápida de incrementos de software.”
Justificativa revisor G2-3: “As atividades realizadas de integração e
comunicação são facilitadas entre os membros da equipe”
Análise: Apesar deste ser o único mapeamento não identificado previamente e
recomendado por mais de um revisor, na essência das descrições, a prática mais
demanda a característica do que a apóia.
Decisão: não adicionar o mapeamento.
Prática: Jogo de planejamento
Característica: Adaptabilidade
Justificativa revisor G2-5: “Creio que esta característica deveria ser incluída,
pois permite se planejar folgas para problemas e requisitos ainda não pensados”
Análise: A prática permite um planejamento mais adequado das entregas e um
melhor equilíbrio entre as prioridades e necessidades do cliente com a
311
capacidade das equipes. Contudo, não interfere no processo em si, muito menos
em sua capacidade de se adaptar rapidamente a situações não previstas.
Decisão: não adicionar o mapeamento.
Prática: Padrões de código
Característica: Emergência
Justificativa revisor G2-5: “novos padrões podem surgir que venham a facilitar o
desenvolvimento e aprimorar o processo. Creio que deve ser incluída a
característica”
Análise: Não há indícios nas descrições de que a prática possa apoiar
diretamente a característica.
Decisão: não adicionar o mapeamento.
Prática: Padrões de código
Característica: Incorporação de Retroalimentação (Feedback)
Justificativa revisor G2-3: “Facilita a integração e comunicação entre os
memnros, possibilitando retroalimentação.”
Análise: Não há indícios nas descrições de que a prática possa apoiar
diretamente a característica.
Decisão: não adicionar o mapeamento.
Prática: Padrões de código
Característica: Ser Iterativo
Justificativa revisor G2-5: “Incluir esta característica pelo fato de a iteração
entre os membros da equipe proporcionar maior precisão. Ciclos curtos com
padrões definidos e iteração entre a equipe vai garantindo um código mais
perfeito”
Análise: Pode ser que o revisor tenha se confundido na interpretação da
descrição da característica.
Decisão: não adicionar o mapeamento.
Prática: Ritmo sustentável
Característica: Leanness
312
Justificativa revisor G2-3: “Favorece a melhoria contínua das atividades”
Análise: Considerando-se as descrições da prática e da característica, a
justificativa apresentada está muito abstrata ou o revisor se confundiu na
interpretação destas descrições.
Decisão: não adicionar o mapeamento.
Prática: Ritmo sustentável
Característica: Reflexão e Introspecção
Justificativa revisor G2-3: “A discussão dos pontos positivos e de melhoria
favorece a produtividade.“
Análise: Possivelmente o revisor se confundiu na interpretação das descrições.
Decisão: não adicionar o mapeamento.
Prática: Ritmo sustentável
Característica: Time-boxing
Justificativa revisor G2-4: “Contribui em maior previsibilidade e assertividade
no alcance das atividades do backlog definido para um determinado sprint.”
Análise: Não ficou clara a justificativa apresentada para associar a prática com a
característica, a partir de suas descrições.
Decisão: não adicionar o mapeamento.
Grupo 3
Prática: Reuniões diárias
Característica: Ser Cooperativo
Justificativa revisor G3-7: Comentário: “Entendo a emergência dos processos
como a característica que faz com que estes processos surjam de forma
autônoma a medida que a equipe realiza o seu trabalho. Sendo assim, qual seria
a relação com as reuniões diárias.”
“Complementando o comentário acima, vejo a prática de reuniões diárias muito
mais ligada com colaboração e cooperação, que não aparecem entre os seus
relacionamentos.”
Análise: A prática, por si só, não considera a presença do cliente, portanto não
necessariamente contribui ou apóia a característica.
313
Decisão: não adicionar o mapeamento.
Prática: Visibilidade de projeto
Característica: Time-boxing
Justificativa revisor G3-6: “A visibilidade do projeto fornece o embasamento
para estabelecer limites de tempo das iterações em função da definição ou
alterações nos planos de trabalho“
Análise: Não há, na descrição da prática, indícios de que possa contribuir
diretamente para a característica.
Decisão: não adicionar o mapeamento.
Prática: Visibilidade de projeto
Característica: Transparência
Justificativa revisor G3-7: “Acho que existe um relacionamento forte aqui -
dando visibilidade do projeto às equipes e stakeholders, me parece que você está
aumentando a transparência.”
Análise: Possivelmente o revisor se enganou ao interpretar a descrição da
característica.
Decisão: não adicionar o mapeamento.
314
Apêndice G Análise Detalhada dos Resultados da Revisão dos Mapeamentos entre Práticas Ágeis e
Atividades de Teste de Software
Com base nos resultados da revisão, não houve modificações dos mapeamentos
inicialmente estabelecidos entre práticas ágeis e atividades de teste de software. A
seguir são apresentadas as discrepâncias observadas, as análises destas discrepâncias e
as decisões tomadas quanto aos mapeamentos entre práticas ágeis e atividades de teste
de software que levaram a este resultado. São apresentadas neste apêndice as análises
dos resultados que não geraram modificações nos mapeamentos previamente
estabelecidos entre práticas ágeis e atividades de teste de software.
G.1 Discordâncias dos Mapeamentos Previamente Estabelecidos (Práticas X
Atividades)
Para cada mapeamento entre as práticas ágeis e as atividades de teste, separados
por grupo e para cada revisor, as justificativa para as discordâncias quanto aos
mapeamentos que foram previamente estabelecidos serão apresentadas e analisadas
conforme se segue. Os revisores não serão identificados, sendo aqui referenciados por
um código alfanumérico de acordo com a Tabela 6-5 apresentada na seção 6.9.2. Os
critérios utilizados foram apresentados na seção 6.9.3.
Grupo 1 e Grupo 2
Os revisores que trabalharam os mapeamentos entre práticas ágeis e atividades
de teste de software incluídos nos grupos 1 e 2 concordaram com os mapeamentos
previamente identificados e estabelecidos.
Grupo 3
Prática: Todas
Atividade: Todas
Justificativa revisor G3-7: “.... Existem duas razões para isto. A primeira é que
não conheço processos ágeis que sigam o rigor de um processo de testes tão
detalhado quanto o que você propõe. Processos ágeis, até onde vai meu
315
conhecimento, tendem a focar em testes de unidade, automatizados por meio de
código-fonte específico para a sua execução. Não há, IMHO planejamento a
priori, projeto, especificação de casos, procedimentos e fechamento de
atividades. Execução e análise ocorrem conjuntamente e de forma transparente,
em função da automação. Sendo assim, me parece estranho comparar um
processo formal de testes com as práticas dos processos ágeis.
A segunda razão é que, considerando uma relação mais ampla entre as práticas e
o processo de testes, eu discordo dos relacionamento que você propõe. Veja que
o primeiro é muito específico (casos de teste de segurança). Entendo que uma
equipe completa esteja relacionada com a produção de casos de teste, mas neste
caso porque apenas com as atividades de projeto e especificação? O mesmo
pode ser dito com relação à metáfora.
Por outro lado, senti falta de um relacionamento entre ritmo sustentável e as
atividades de teste. Em processos como o XP, por exemplo, os casos de teste são
utilizados para resguardar um pedaço de código, garantindo que ele continuará
funcionando a medida que o sistema se expande. É, em certo grau, uma
perspectiva similar ao princípio Open-Closed do Bertrand Meyer, que propõe
que um software seja expandido pela criação de novas classes e extensão de
estruturas hierárquicas, sem a alteração do código anteriormente escrito, que
deve continuar funcionando.”
Análise: Não foi apresentada uma justificativa individualizada para cada
mapeamento; além disso, há indícios de que o revisor analisou os mapeamentos
com uma perspectiva totalmente diferente daquela que faz parte do contexto
desta pesquisa e daquela com que os demais revisores realizaram o trabalho de
revisão. Por este motivo, nada será modificado a partir deste retorno.
Decisão: manter os mapeamentos.
O revisor G3-6 retornou o seguinte comentário: “Não identifiquei nenhum
problema nos relacionamentos entre Práticas Ágeis e Atividades de Teste que você
enviou, nem novos relacionamentos.”
G.2 Discordâncias das Justificativas para Mapeamentos Previamente
Estabelecidos (Práticas X Atividades)
316
Não foram observadas discordâncias das justificativas para os mapeamentos
previamente estabelecidos, por parte dos revisores incluídos em qualquer um dos 3
grupos em que o trabalho de revisão foi dividido.
G.3 Mapeamentos Adicionais Sugeridos (Práticas X Atividades)
Para os mapeamentos adicionais entre as práticas ágeis e atividades de teste de
software identificados pelos revisores, separados por grupo e para cada revisor, as
justificativas para inclusão do novo mapeamento serão apresentadas e analisadas. Os
revisores não serão identificados, sendo também aqui referenciados por um código
alfanumérico de acordo com a Tabela 6-5 apresentada na seção 6.9.2. Os critérios
utilizados foram apresentados na seção 6.9.3. Serão apresentadas aqui apenas as análises
dos resultados que não geraram modificações nos mapeamentos previamente
estabelecidos entre práticas ágeis e atividades de teste de software.
Grupo 1
O revisor G1-4 replicou uma mesma justificativa para mais de um
relacionamento, que foi aqui também replicado para facilitar o entendimento da
análise.
Prática: Backlog de produto
Atividade: Planejar Testes
Justificativa revisor G1-4: “Obs: eu não discordo dos relacionamentos
levantados, entretanto gostaria de colocar que como a prática "Backlog de
produto" ajuda na atividade "Planejar Testes" e como a atividade "Planejar
Testes" tem como output o input da atividade "Projetar Testes", poderia se dizer
que o Backlog de produtos ajuda sim na atividade "Projetar Testes".
Análise: O encadeamento de atividades por si só não justifica o mapeamento de
uma prática para cada atividade encadeada. Se assim fosse, uma prática que
apoiasse a primeira atividade estaria, por conseqüência do encadeamento,
mapeada para todas as atividades seguintes.
Decisão: não adicionar o mapeamento.
Prática: Backlog de produto
Atividade: Projetar Testes
317
Justificativa revisor G1-4: “Obs: eu não discordo dos relacionamentos
levantados, entretanto gostaria de colocar que como a prática "Backlog de
produto" ajuda na atividade "Planejar Testes" e como a atividade "Planejar
Testes" tem como output o input da atividade "Projetar Testes", poderia se dizer
que o Backlog de produtos ajuda sim na atividade "Projetar Testes".
Análise: O encadeamento de atividades por si só não justifica o mapeamento de
uma prática para cada atividade encadeada. Se assim fosse, uma prática que
apoiasse a primeira atividade estaria, por conseqüência do encadeamento,
mapeada para todas as atividades seguintes.
Decisão: não adicionar o mapeamento.
Prática: Refatoração
Atividade: Projetar Testes
Prática: Backlog de produto
Atividade: Projetar Testes
Justificativa revisor G1-4: “O mesmo raciocínio poderia ser aplicado em relação
a prática "Refatoração" que deixa o código mais simples o que por sua contribui
para as atividades: "Projetar Testes", "Especificar casos de Testes" e "Definir
procedimento de Testes"
Análise: O encadeamento de atividades por si só não justifica o mapeamento de
uma prática para cada atividade encadeada. Se assim fosse, uma prática que
apoiasse a primeira atividade estaria, por conseqüência do encadeamento,
mapeada para todas as atividades seguintes.
Decisão: não adicionar o mapeamento.
Prática: Refatoração
Atividade: Especificar Casos de Testes
Justificativa revisor G1-4: “O mesmo raciocínio poderia ser aplicado em relação
a prática "Refatoração" que deixa o código mais simples o que por sua contribui
para as atividades: "Projetar Testes", "Especificar casos de Testes" e "Definir
procedimento de Testes"
Análise: O encadeamento de atividades por si só não justifica o mapeamento de
uma prática para cada atividade encadeada. Se assim fosse, uma prática que
318
apoiasse a primeira atividade estaria, por conseqüência do encadeamento,
mapeada para todas as atividades seguintes.
Decisão: não adicionar o mapeamento.
Prática: Refatoração
Atividade: Definir Procedimentos de Testes
Justificativa revisor G1-4: “O mesmo raciocínio poderia ser aplicado em relação
a prática "Refatoração" que deixa o código mais simples o que por sua contribui
para as atividades: "Projetar Testes", "Especificar casos de Testes" e "Definir
procedimento de Testes"
Análise: O encadeamento de atividades por si só não justifica o mapeamento de
uma prática para cada atividade encadeada. Se assim fosse, uma prática que
apoiasse a primeira atividade estaria, por conseqüência do encadeamento,
mapeada para todas as atividades seguintes.
Decisão: não adicionar o mapeamento.
Grupo 2
Prática: Desenvolvimento orientado a testes
Atividade: Projetar Testes
Justificativa revisor G2-1: “O desenvolvimento orientado a testes é uma
estratégia de apoio para projetar, especificar casos e procedimentos de testes,
além de apoiar a execução e análise dos resultados dos testes.”
Análise: Não há indício na descrição da prática que possa ser interpretado como
apoio a esta atividade. A prática é uma estratégia que obriga a escrever os testes
antes do código e depois escrever o código que passe nos testes. Iterativamente.
Decisão: não adicionar o mapeamento.
Prática: Desenvolvimento orientado a testes
Atividade: Especificar Casos de Teste
Justificativa revisor G2-1: “O desenvolvimento orientado a testes é uma
estratégia de apoio para projetar, especificar casos e procedimentos de testes,
além de apoiar a execução e análise dos resultados dos testes.”
Análise: Não há indício na descrição da prática que possa ser interpretado como
319
apoio a esta atividade. A prática é uma estratégia que obriga a escrever os testes
antes do código e depois escrever o código que passe nos testes. Iterativamente.
Decisão: não adicionar o mapeamento.
Prática: Desenvolvimento orientado a testes
Atividade: Definir Procedimentos de Teste
Justificativa revisor G2-1: “O desenvolvimento orientado a testes é uma
estratégia de apoio para projetar, especificar casos e procedimentos de testes,
além de apoiar a execução e análise dos resultados dos testes.”
Análise: Não há indício na descrição da prática que possa ser interpretado como
apoio a esta atividade. A prática é uma estratégia que obriga a escrever os testes
antes do código e depois escrever o código que passe nos testes. Iterativamente.
Decisão: não adicionar o mapeamento.
Prática: Desenvolvimento orientado a testes
Atividade: Executar Testes
Justificativa revisor G2-1: “O desenvolvimento orientado a testes é uma
estratégia de apoio para projetar, especificar casos e procedimentos de testes,
além de apoiar a execução e análise dos resultados dos testes.”
Análise: Não há indício na descrição da prática que possa ser interpretado como
apoio a esta atividade. A prática é uma estratégia que obriga a escrever os testes
antes do código e depois escrever o código que passe nos testes. Iterativamente.
Decisão: não adicionar o mapeamento.
Prática: Desenvolvimento orientado a testes
Atividade: Analisar resultados
Justificativa revisor G2-1: “O desenvolvimento orientado a testes é uma
estratégia de apoio para projetar, especificar casos e procedimentos de testes,
além de apoiar a execução e análise dos resultados dos testes.”
Análise: Não há indício na descrição da prática que possa ser interpretado como
apoio a esta atividade. A prática é uma estratégia que obriga a escrever os testes
antes do código e depois escrever o código que passe nos testes. Iterativamente.
Decisão: não adicionar o mapeamento.
320
Prática: Reuniões Diárias
Atividade: Fechar Atividades de Teste
Justificativa revisor G2-4: “Podem fornecer subsídios para determinar o que é
descartável e relevante para apoiar a realização de novos projetos de teste.”
Análise: Pela descrição da prática ela não tem esta finalidade nem há indícios
em sua interpretação que possam apoiar esta atividade.
Decisão: não adicionar o mapeamento.
Grupo 3
O revisor G3-6 retornou o seguinte comentário: “Não identifiquei nenhum
problema nos relacionamentos entre Práticas Ágeis e Atividades de Teste que você
enviou, nem novos relacionamentos.”