1-s2 0-S0950584917305098-main en pt

Prévia do material em texto

listas de conteúdos disponíveis em ScienceDirectlistas de conteúdos disponíveis em ScienceDirect
Tecnologia da Informação e Software
Página inicial do jornal: www.elsevier.com/locate/infsofPágina inicial do jornal: www.elsevier.com/locate/infsof
dívida técnica e ágil de software práticas e processos de desenvolvimento: uma pesquisa do setor 
médico
Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,Johannes Holvitie • , uma , b , Sherlock A. Licorish c , Rodrigo O. Spínola d , e , Sami Hyrynsalmi f ,
Stephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , bStephen G. MacDonell c , h , Thiago S. Mendes g , Jim Buchan h , Ville Leppänen uma , b
uma Centro de Turku de Ciências da Computação, Laboratório de Desenvolvimento de Software, Turku, Finlândiauma Centro de Turku de Ciências da Computação, Laboratório de Desenvolvimento de Software, Turku, Finlândia
b Universidade de Turku, Departamento de Tecnologia da Informação, Turku, Finlândiab Universidade de Turku, Departamento de Tecnologia da Informação, Turku, Finlândia
c Universidade de Otago, Departamento de Ciência da Informação, Dunedin, Otago, Nova Zelândiac Universidade de Otago, Departamento de Ciência da Informação, Dunedin, Otago, Nova Zelândia
d Universidade Salvador, Programa de Pós-Graduação em Sistemas e Computadores, Salvador, Bahia, Brasild Universidade Salvador, Programa de Pós-Graduação em Sistemas e Computadores, Salvador, Bahia, Brasil
e Universidade Federal da Bahia, Central de Projetos Fraunhofer de Software e Engenharia de Sistemas, Salvador, Brasile Universidade Federal da Bahia, Central de Projetos Fraunhofer de Software e Engenharia de Sistemas, Salvador, Brasil
f Tampere University of Technology, Pori Campus, Pori, Finlândiaf Tampere University of Technology, Pori Campus, Pori, Finlândia
g Instituto Federal da Bahia, Departamento de Informática, Santo Amaro, Bahia, Brasilg Instituto Federal da Bahia, Departamento de Informática, Santo Amaro, Bahia, Brasil
h Auckland University of Technology, Escola de Engenharia, Computação e Ciências Matemáticas, Auckland, Nova Zelândiah Auckland University of Technology, Escola de Engenharia, Computação e Ciências Matemáticas, Auckland, Nova Zelândia
articleinfo
Palavras-chave:
dívida técnica
gestão da dívida técnico software 
Agile Development Survey 
Practitioner
ABSTRATO
Contexto: desenvolvimento de software contemporâneo é normalmente realizada em ambientes dinâmicos, com recursos escassos que são propensos à Contexto: desenvolvimento de software contemporâneo é normalmente realizada em ambientes dinâmicos, com recursos escassos que são propensos à 
acumulação de dívida técnica. Embora este fenômeno geral é reconhecido, o que permanece desconhecido é específica da dívida how técnico fi camente acumulação de dívida técnica. Embora este fenômeno geral é reconhecido, o que permanece desconhecido é específica da dívida how técnico fi camente acumulação de dívida técnica. Embora este fenômeno geral é reconhecido, o que permanece desconhecido é específica da dívida how técnico fi camente 
se manifesta em e uma ff ECTS processos de software, e como as técnicas de desenvolvimento de software empregadas acomodar ou mitigar a presença se manifesta em e uma ff ECTS processos de software, e como as técnicas de desenvolvimento de software empregadas acomodar ou mitigar a presença se manifesta em e uma ff ECTS processos de software, e como as técnicas de desenvolvimento de software empregadas acomodar ou mitigar a presença 
dessa dívida.
Objetivos. Buscou-se recorrer a conhecimentos e experiências praticante, a fim de classificar o e ff ECTS de uso método ágil de gestão da Objetivos. Buscou-se recorrer a conhecimentos e experiências praticante, a fim de classificar o e ff ECTS de uso método ágil de gestão da Objetivos. Buscou-se recorrer a conhecimentos e experiências praticante, a fim de classificar o e ff ECTS de uso método ágil de gestão da Objetivos. Buscou-se recorrer a conhecimentos e experiências praticante, a fim de classificar o e ff ECTS de uso método ágil de gestão da 
dívida técnica, dada a popularidade e sucesso percebido de métodos ágeis. Nós exploramos a amplitude de praticantes ' conhecimento sobre dívida técnica, dada a popularidade e sucesso percebido de métodos ágeis. Nós exploramos a amplitude de praticantes ' conhecimento sobre dívida técnica, dada a popularidade e sucesso percebido de métodos ágeis. Nós exploramos a amplitude de praticantes ' conhecimento sobre 
dívida técnica; how técnico da dívida se manifesta em todo o processo de software; eo e percebida ff ECTS de práticas comuns de dívida técnica; how técnico da dívida se manifesta em todo o processo de software; eo e percebida ff ECTS de práticas comuns de dívida técnica; how técnico da dívida se manifesta em todo o processo de software; eo e percebida ff ECTS de práticas comuns de 
desenvolvimento de software ágeis e processos em débito técnico. Ao fazer isso, abordamos uma lacuna pesquisa em conhecimento dívida 
técnica e fornecer romance e recomendações gerenciais acionáveis.
Método: Nós concebido, testado e executadoum questionário de pesquisa multi-nacional para abordar nossos objetivos, recebendo 184 Método: Nós concebido, testado e executado um questionário de pesquisa multi-nacional para abordar nossos objetivos, recebendo 184 
respostas de praticantes no Brasil, Finlândia e Nova Zelândia.
Resultados: Nosso fi achados indicam que: 1) Os praticantes estão conscientes da dívida técnica, embora, não estava sob utilização do Resultados: Nosso fi achados indicam que: 1) Os praticantes estão conscientes da dívida técnica, embora, não estava sob utilização do Resultados: Nosso fi achados indicam que: 1) Os praticantes estão conscientes da dívida técnica, embora, não estava sob utilização do Resultados: Nosso fi achados indicam que: 1) Os praticantes estão conscientes da dívida técnica, embora, não estava sob utilização do 
conceito, 2) dívida técnica comumente reside em sistemas legados, no entanto, casos concretos de dívida técnica são difíceis de conceituar o que 
torna problemático para gerenciar , 3) Indagado práticas e processos ágeis ajudar a reduzir a dívida técnica; em particular, as técnicas que a 
verificar e manter a estrutura e a clareza de artefactos implementados (por exemplo, padrões de codificação e Refatorando) um positivamente ff ect verificar e manter a estrutura e a clareza de artefactos implementados (por exemplo, padrões de codificação e Refatorando) um positivamente ff ect verificar e manter a estrutura e a clareza de artefactos implementados (por exemplo, padrões de codificação e Refatorando) um positivamente ff ect 
gestão da dívida técnica.
conclusões: O fato de que os casos de dívida técnicos tendem a ter características em comum significa que uma abordagem sistemática para a conclusões: O fato de que os casos de dívida técnicos tendem a ter características em comum significa que uma abordagem sistemática para a 
sua gestão é viável. Contudo, não obstante o e positiva ff ECTS de algumas práticas ágeis de gestão de dívida técnica, as partes concorrentes ' interesses sua gestão é viável. Contudo, não obstante o e positiva ff ECTS de algumas práticas ágeis de gestão de dívida técnica, as partes concorrentes ' interesses sua gestão é viável. Contudo, não obstante o e positiva ff ECTS de algumas práticas ágeis de gestão de dívida técnica, as partes concorrentes ' interesses sua gestão é viável. Contudo, não obstante o e positiva ff ECTS de algumas práticas ágeis de gestão de dívida técnica, as partes concorrentes ' interesses sua gestão é viável. Contudo, não obstante o e positiva ff ECTS de algumas práticas ágeis de gestão de dívida técnica, as partes concorrentes ' interesses 
continuam a ser uma preocupação.
1. Introdução
Um desenvolvedor de software pode seguir vários caminhos alternativos para produzir “ software Um desenvolvedor de software pode seguir vários caminhos alternativos para produzir “ software Um desenvolvedor de software pode seguir vários caminhos alternativos para produzir “ software 
trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes trabalhando ” [ 1] . Possivelmente, esses caminhos em fl influência, e estão em fl influenciadas por, as partes 
interessadas ' de fi definições de done [ 2] . Todas as alternativas podem produzir software trabalhando para interessadas ' de fi definições de done [ 2] . Todas as alternativas podem produzir software trabalhando para interessadas ' de fi definições de done [ 2] . Todas as alternativas podem produzir software trabalhando para interessadas ' de fi definições de done [ 2] . Todas as alternativas podem produzir software trabalhando para interessadas ' de fi definições de done [ 2] . Todas as alternativas podem produzir software trabalhando para interessadas ' de fi definições de done [ 2] . Todas as alternativas podem produzir software trabalhando para interessadas ' de fi definições de done [ 2] . Todas as alternativas podem produzir software trabalhando para interessadas ' de fi definições de done [ 2] . Todas as alternativas podem produzir software trabalhando para 
um cliente, mas em tomar alguns caminhos a implementação resultante pode ser mais complexa do que 
aqueles
decorrentes de outras abordagens. Se houver a ser futuras iterações no desenvolvimento de um 
produto de software ou serviço, e estas iterações deve construir sobre uma implementação mais 
complexo, é evidente que o caminho escolhido um ff ECTS e continuará a uma ff ect desenvolvimento: complexo, é evidente que o caminho escolhido um ff ECTS e continuará a uma ff ect desenvolvimento: complexo, é evidente que o caminho escolhido um ff ECTS e continuará a uma ff ect desenvolvimento: complexo, é evidente que o caminho escolhido um ff ECTS e continuará a uma ff ect desenvolvimento: complexo, é evidente que o caminho escolhido um ff ECTS e continuará a uma ff ect desenvolvimento: 
é mais fácil para o progresso de desenvolvimento de software em cima de uma implementação 
menos complexa.
O desalinhamento potencial do cliente e desenvolvedor perspectivas
https://doi.org/10.1016/j.infsof.2017.11.015
Recebeu 05 setembro de 2016; Recebido em forma revisada 25 de novembro de 2017; Aceito 29 de novembro de 2017
• Correspondente do autor em: Universidade de Turku, Departamento de Tecnologia da Informação, Turku, Finlândia.• Correspondente do autor em: Universidade de Turku, Departamento de Tecnologia da Informação, Turku, Finlândia.
Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut.fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),Endereço de e-mail: jjholv @ utu. fi ( J. Holvitie), sherlock.licorish@otago.ac.nz (SA Licorish), rodrigo.spinola@fpc.ufba.br (Spínola RO), sami.hyrynsalmi@tut. fi ( S. Hyrynsalmi),
stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).stephen.macdonell@otago.ac.nz (SG MacDonell), thiagomendes@dcc.ufba.br (TS Mendes), jim.buchan@aut.ac.nz (J. Buchan), ville.leppanen@utu. fi ( V. Leppänen).
Tecnologia da Informação e Software xxx (xxxx) xxx-xxx
0950-5849 / © 2017 autores. Publicado por Elsevier Este é um artigo de acesso aberto sob a licença CC-BY (http://creativecommons.org/licenses/BY/4.0/).
Por favor, citar este artigo como: Holvitie, JJ, Tecnologia da Informação e Software (2017), https://doi.org/10.1016/j.infsof.2017.11.015
quanto aos critérios para julgar se ou não uma característica é feito pode levar a dívida técnica. O quanto aos critérios para julgar se ou não uma característica é feito pode levar a dívida técnica. O quanto aos critérios para julgar se ou não uma característica é feito pode levar a dívida técnica. O 
cliente analisa a integridade funcional de recursos para informar decisões sobre iterações 
posteriores. O desenvolvedor, no entanto, observa simultaneamente funcional e completude posteriores. O desenvolvedor, no entanto, observa simultaneamente funcional e completude posteriores. O desenvolvedor, no entanto, observa simultaneamente funcional e completude 
aplicação para os recursos. Como questões relacionadas à implementação são invisíveis para o 
cliente o desenvolvedor é o principal responsável pela gestão de integridade nesta dimensão. 
Notavelmente, o desenvolvedor deve entender como isso integralidade um ff ECTS entrega ao cliente Notavelmente, o desenvolvedor deve entender como isso integralidade um ff ECTS entrega ao cliente Notavelmente, o desenvolvedor deve entender como isso integralidade um ff ECTS entrega ao cliente 
e, com base nesse entendimento, exercer a gestão apropriada. Por exemplo, digamos que em uma 
próxima iteração de um componente para o qual um Ad hoc interface foi projetada será usado. O próxima iteração de um componente para o qual um Ad hoc interface foi projetada será usado. O próxima iteração de um componente para o qual um Ad hoc interface foi projetada será usado. O 
desenvolvedor é o único partido capaz de saber isso e deve decidir se gastar parte da iteração em 
um redesenho da interface é uma estratégia preferida ao longo usando a interface existente, 
incoerente. Assim, a dupla perspectivas sobre o de fi-incoerente. Assim, a dupla perspectivas sobre o de fi-
definição de feito, juntamente com a percepção da diferença entre o que pode ser observado por 
todas as partes interessadas e completude recurso de software, e as ações previsíveis ou caminhos 
que poderiam ser tomadas em relação a esta lacuna, expõe os motivos para a dívida técnica ' s que poderiam ser tomadas em relação a esta lacuna, expõe os motivos para a dívida técnica ' s que poderiam ser tomadas em relação a esta lacuna, expõe os motivos para a dívida técnica ' s 
existência, descreva sua manifestação na prática, e levar a seus procedimentos de gestão, 
respectivamente.
Enquanto como uma dívida técnico fenômeno não é novo, sua conceituação é bastante recente [3]Enquanto como uma dívida técnico fenômeno não é novo, sua conceituação é bastante recente [3]
. dívida técnica descreve as consequências das acções de desenvolvimento de software que 
priorizam intencionalmente ou não restrições de valor e / ou projeto do cliente, tais como prazos de 
entrega, mais de mais considerações sobre implementação e técnicas de concepção. Estes incluem 
questões como a obtenção e manutenção de cobertura de teste ou extensibilidade código. 
Conceitualmente, dívida técnica é um análogo de fi nanceira da dívida, com os conceitos associados, Conceitualmente, dívida técnica é um análogo de fi nanceira da dívida, com os conceitos associados, Conceitualmente, dívida técnica é um análogo de fi nanceira da dívida, com os conceitos associados, 
tais como níveis de dívida, acumulação da dívida ao longo do tempo e suas prováveis 
​​consequências, e a pressão para pagar a dívida em algum momento no tempo.
dívida técnica não deve ser equiparado a sub-óptima software eo e negativo ff ECTS decorrentes dívida técnica não deve ser equiparado a sub-óptima software eo e negativo ff ECTS decorrentes dívida técnica não deve ser equiparado a sub-óptima software eo e negativo ff ECTS decorrentes 
de tais desenvolvimentos, no entanto. Há situações em que a decisão de acumular dívida técnica (ou 
seja, não pagá-lo) tem boa relação custo-bene fi t para uma equipe. O uso de ideias de dívida técnicas seja, não pagá-lo) tem boa relação custo-bene fi t para uma equipe. O uso de ideias de dívida técnicas seja, não pagá-lo) tem boa relação custo-bene fi t para uma equipe. O uso de ideias de dívida técnicas 
de compartimentar e caracterizar o desvio entre os estados de software atuais e ótimas podem 
fornecer um mecanismo para a governança de ativos de gerenciamento-like da dívida [4] . Por fornecer um mecanismo para a governança de ativos de gerenciamento-like da dívida [4] . Por fornecer um mecanismo para a governança de ativos de gerenciamento-like da dívida [4] . Por 
exemplo, a decisão de não gastar recursos na melhoria de uma estrutura software de trabalho que 
fornece a funcionalidade desejada é razoável se a informação disponível indica que há probabilidade 
de haver (pontual) vantagem ou benefício adicional fi t no retorno para este e ff ort.de haver (pontual) vantagem ou benefício adicional fi t no retorno para este e ff ort.de haver (pontual) vantagem ou benefício adicional fi t no retorno para este e ff ort.de haver (pontual) vantagem ou benefício adicional fi t no retorno para este e ff ort.de haver (pontual) vantagem ou benefício adicional fi t no retorno para este e ff ort.
Enquanto a consideração e aplicação do conceito de dívida técnica têm aumentado 
exponencialmente no contexto acadêmico [5] , Com o melhor dos autores ' conhecimento vários exponencialmente no contexto acadêmico [5] , Com o melhor dos autores ' conhecimento vários exponencialmente no contexto acadêmico[5] , Com o melhor dos autores ' conhecimento vários exponencialmente no contexto acadêmico [5] , Com o melhor dos autores ' conhecimento vários exponencialmente no contexto acadêmico [5] , Com o melhor dos autores ' conhecimento vários 
aspectos do conceito ' s uso na indústria de software permanecem unstudied, incluindo os contextos aspectos do conceito ' s uso na indústria de software permanecem unstudied, incluindo os contextos aspectos do conceito ' s uso na indústria de software permanecem unstudied, incluindo os contextos 
nos quais o e ff ECTS de dívida técnica são susceptíveis de ter a maior relevância e impacto. Em nos quais o e ff ECTS de dívida técnica são susceptíveis de ter a maior relevância e impacto. Em nos quais o e ff ECTS de dívida técnica são susceptíveis de ter a maior relevância e impacto. Em 
particular, alguns estudos anteriores tentaram capturar o e ff ECTS de práticas de desenvolvimento de particular, alguns estudos anteriores tentaram capturar o e ff ECTS de práticas de desenvolvimento de particular, alguns estudos anteriores tentaram capturar o e ff ECTS de práticas de desenvolvimento de 
software comuns e processos - os caminhos percorridos - em dívida técnica. Na mesma linha, como 
uma comunidade que não tem certeza sobre a amplitude dos praticantes ' conhecimento sobre dívida uma comunidade que não tem certeza sobre a amplitude dos praticantes ' conhecimento sobre dívida uma comunidade que não tem certeza sobre a amplitude dos praticantes ' conhecimento sobre dívida 
técnica e como dívida técnica é manifestado como eles funcionam. A palavra ' e ff ect ' é usado aqui técnica e como dívida técnica é manifestado como eles funcionam. A palavra ' e ff ect ' é usado aqui técnica e como dívida técnica é manifestado como eles funcionam. A palavra ' e ff ect ' é usado aqui técnica e como dívida técnica é manifestado como eles funcionam. A palavra ' e ff ect ' é usado aqui técnica e como dívida técnica é manifestado como eles funcionam. A palavra ' e ff ect ' é usado aqui técnica e como dívida técnica é manifestado como eles funcionam. A palavra ' e ff ect ' é usado aqui técnica e como dívida técnica é manifestado como eles funcionam. A palavra ' e ff ect ' é usado aqui 
para capturar se uma prática ou processo em particular é percebido para aumentar ou diminuir o 
tamanho da dívida técnica ou os resultados positivos ou negativos que emergem dessa dívida.
Conhecimentos relativos ao e ff ECTS de práticas de desenvolvimento de software ou processos Conhecimentos relativos ao e ff ECTS de práticas de desenvolvimento de software ou processos Conhecimentos relativos ao e ff ECTS de práticas de desenvolvimento de software ou processos 
sobre dívida técnica é potencialmente importante para os profissionais, uma vez que deve tomar 
decisões sobre os métodos de desenvolvimento que vão usar. Na ausência de su ffi conhecimento decisões sobre os métodos de desenvolvimento que vão usar. Na ausência de su ffi conhecimento decisões sobre os métodos de desenvolvimento que vão usar. Na ausência de su ffi conhecimento 
ciente sobre o e ff ecte de um método ' s práticas e processos, essas decisões podem ter ciente sobre o e ff ecte de um método ' s práticas e processos, essas decisões podem ter ciente sobre o e ff ecte de um método ' s práticas e processos, essas decisões podem ter ciente sobre o e ff ecte de um método ' s práticas e processos, essas decisões podem ter ciente sobre o e ff ecte de um método ' s práticas e processos, essas decisões podem ter 
consequências inesperadas sobre dívida técnica, e, finalmente, equipes ' desempenho. Com base consequências inesperadas sobre dívida técnica, e, finalmente, equipes ' desempenho. Com base consequências inesperadas sobre dívida técnica, e, finalmente, equipes ' desempenho. Com base 
nessas observações, e de acordo com nosso desejo de ganhar uma ampla gama de entrada para 
sustentar nosso entendimento, fomos solicitado a realizar uma pesquisa multi-nacional para 
investigar dívida técnica na prática. Este estudo exploratório procurou estender o nosso 
conhecimento sobre a profundidade e amplitude de praticantes ' conhecimento sobre dívida técnica; conhecimento sobre a profundidade e amplitude de praticantes ' conhecimento sobre dívida técnica; conhecimento sobre a profundidade e amplitude de praticantes ' conhecimento sobre dívida técnica; 
how técnico da dívida é manifestada; eo e percebida ff ECTS dehow técnico da dívida é manifestada; eo e percebida ff ECTS dehow técnico da dívida é manifestada; eo e percebida ff ECTS de
práticas ágeis comuns de desenvolvimento de software e processos em débito técnico.
Isto signi trabalho fi cativamente estende os autores ' contribuições preliminares anteriores. Uma Isto signi trabalho fi cativamente estende os autores ' contribuições preliminares anteriores. Uma Isto signi trabalho fi cativamente estende os autores ' contribuições preliminares anteriores. Uma Isto signi trabalho fi cativamente estende os autores ' contribuições preliminares anteriores. Uma Isto signi trabalho fi cativamente estende os autores ' contribuições preliminares anteriores. Uma 
publicação anterior envolvendo alguns dos presentes autores
[6] relata a concepção, construção e teste do instrumento de pesquisa, além de sua execução na [6] relata a concepção, construção e teste do instrumento de pesquisa, além de sua execução na 
Finlândia. Que a publicação anterior descreve cenários onde dívida técnica é utilizada, os meios de 
comunicação em que os inquiridos utilizam o conceito, e seus níveis de conhecimento existentes. 
Além disso, o e percebida ff ect de práticas e processos em dívida técnica ágeis comuns é consultado. Além disso, o e percebida ff ect de práticas e processos em dívida técnica ágeis comuns é consultado. Além disso, o e percebida ff ect de práticas e processos em dívida técnica ágeis comuns é consultado. 
o e ff ect de desenvolvimento contínuo, as causas e as origens também são capturados para dívida o e ff ect de desenvolvimento contínuo, as causas e as origens também são capturados para dívida o e ff ect de desenvolvimento contínuo, as causas e as origens também são capturados para dívida 
técnica.
O presente trabalho se estende deste estudo inicial para uma multi-nacional que envolve 
participantes no Brasil e Nova Zelândia. Isto permitiu a entrega de vários resultados inovadores. Mais 
notavelmente, análise do conhecimento anterior, a conformidade com os dados de fi definições e ágil notavelmente, análise do conhecimento anterior, a conformidade com os dados de fi definições e ágil notavelmente, análise do conhecimento anterior, a conformidade com os dados de fi definições e ágil 
técnica e ff ECTS agora considerar os respondentes ' funções de desenvolvimento. Nós também informar técnica e ff ECTS agora considerar os respondentes ' funções de desenvolvimento. Nós também informar técnica e ff ECTS agora considerar os respondentes ' funções de desenvolvimento. Nós também informar técnica e ff ECTS agora considerar os respondentes ' funções de desenvolvimento. Nós também informar técnica e ff ECTS agora considerar os respondentes ' funções de desenvolvimento. Nós também informar 
sobre dívida técnica ' se ff ECTS em várias características de desenvolvimento de software (por exemplo, sobre dívida técnica ' se ff ECTS em várias características de desenvolvimento de software (por exemplo, sobre dívida técnica ' se ff ECTS em várias características de desenvolvimento de software (por exemplo, sobre dívida técnica ' se ff ECTS em várias características de desenvolvimento de software (por exemplo, sobre dívida técnica ' se ff ECTS em várias características de desenvolvimento de software (por exemplo, 
o seu e percebida ff ect na agilidade). Além disso, devido ao aumento do tamanho do conjunto de dados o seu e percebida ff ect na agilidade). Além disso, devido ao aumento do tamanho do conjunto de dados o seu e percebidaff ect na agilidade). Além disso, devido ao aumento do tamanho do conjunto de dados 
a análise con fi ança é aumentada, e por isso quando a análise aplicável, estatística acompanha a a análise con fi ança é aumentada, e por isso quando a análise aplicável, estatística acompanha a a análise con fi ança é aumentada, e por isso quando a análise aplicável, estatística acompanha a 
apresentação dos resultados.
As restantes secções deste artigo estão estruturadas da seguinte forma.
Seção 2 descreve o contexto do estudo, com foco em trabalhos relacionados sobre a dívida técnica e Seção 2 descreve o contexto do estudo, com foco em trabalhos relacionados sobre a dívida técnica e 
desenvolvimento ágil de software. A abordagem de pesquisa empregada é descrito em seção 3 com desenvolvimento ágil de software. A abordagem de pesquisa empregada é descrito em seção 3 com desenvolvimento ágil de software. A abordagem de pesquisa empregada é descrito em seção 3 com 
o estabelecimento das questões de pesquisa, seguido de explicações sobre a concepção e 
implementação do estudo de pesquisa que lhes respostas. secção 4 apresenta os resultados da implementação do estudo de pesquisa que lhes respostas. secção 4 apresenta os resultados da implementação do estudo de pesquisa que lhes respostas. secção 4 apresenta os resultados da 
pesquisa ea análise subsequente destes resultados. Chave fi achados, implicações e trabalho futuro, pesquisa ea análise subsequente destes resultados. Chave fi achados, implicações e trabalho futuro, pesquisa ea análise subsequente destes resultados. Chave fi achados, implicações e trabalho futuro, 
bem como limitações do estudo, são discutidas em seção 5 . Finalmente, observações finais são bem como limitações do estudo, são discutidas em seção 5 . Finalmente, observações finais são bem como limitações do estudo, são discutidas em seção 5 . Finalmente, observações finais são 
fornecidos em seção 6 .fornecidos em seção 6 .fornecidos em seção 6 .
2. Antecedentes
Nesta seção nós fornecemos o fundo estudo. Nós fi examinar primeiro o conceito de dívida Nesta seção nós fornecemos o fundo estudo. Nós fi examinar primeiro o conceito de dívida Nesta seção nós fornecemos o fundo estudo. Nós fi examinar primeiro o conceito de dívida 
técnica, incluindo sua origem e evolução. Nós, então, fornecer uma análise e avaliação de estudos 
transversais relevantes existentes, observando a signi fi características cativas de dívida técnica. Esta transversais relevantes existentes, observando a signi fi características cativas de dívida técnica. Esta transversais relevantes existentes, observando a signi fi características cativas de dívida técnica. Esta 
avaliação e avaliação fornecer o trabalho de fi definição de dívida técnica utilizada em nosso estudo. avaliação e avaliação fornecer o trabalho de fi definição de dívida técnica utilizada em nosso estudo. avaliação e avaliação fornecer o trabalho de fi definição de dívida técnica utilizada em nosso estudo. 
Finalmente, o desenvolvimento ágil de software e seus métodos são brie fl y examinado, de modo a Finalmente, o desenvolvimento ágil de software e seus métodos são brie fl y examinado, de modo a Finalmente, o desenvolvimento ágil de software e seus métodos são brie fl y examinado, de modo a 
fornecer um contexto e justi fi cação para a nossa consideração de determinadas práticas ágeis e fornecer um contexto e justi fi cação para a nossa consideração de determinadas práticas ágeis e fornecer um contexto e justi fi cação para a nossa consideração de determinadas práticas ágeis e 
processos no instrumento de pesquisa.
2.1. de fi dívida técnica ning2.1. de fi dívida técnica ning2.1. de fi dívida técnica ning
O termo “ dívida técnica ” foi cunhada por Ward Cunningham [3] ,O termo “ dívida técnica ” foi cunhada por Ward Cunningham [3] ,O termo “ dívida técnica ” foi cunhada por Ward Cunningham [3] ,O termo “ dívida técnica ” foi cunhada por Ward Cunningham [3] ,O termo “ dívida técnica ” foi cunhada por Ward Cunningham [3] ,O termo “ dívida técnica ” foi cunhada por Ward Cunningham [3] ,O termo “ dívida técnica ” foi cunhada por Ward Cunningham [3] ,
quando descreveu o fenômeno de cumprir um prazo de liberação, fazendo adaptações e concessões 
em um produto. Ele também delineou como o e ff ecte sentida depois foram análogas às que estão em um produto. Ele também delineou como o e ff ecte sentida depois foram análogas às que estão em um produto. Ele também delineou como o e ff ecte sentida depois foram análogas às que estão 
associadas com a contracção de fi da dívida financeira. Cunningham [3] reconheceu que, na maioria associadas com a contracção de fi da dívida financeira. Cunningham [3] reconheceu que, na maioria associadas com a contracção de fi da dívida financeira. Cunningham [3] reconheceu que, na maioria associadas com a contracção de fi da dívida financeira. Cunningham [3] reconheceu que, na maioria associadas com a contracção de fi da dívida financeira. Cunningham [3] reconheceu que, na maioria 
das vezes, a dívida técnica exigida de retorno, enquanto a incapacidade de gerenciar ativos poderia 
levar a uma completa paralisação como o interesse e e ff ecte das adaptações (ou falta dela) se tornar levar a uma completa paralisação como o interesse e e ff ecte das adaptações (ou falta dela) se tornar levar a uma completa paralisação como o interesse e e ff ecte das adaptações (ou falta dela) se tornar 
insuportável.
o de fi definição de dívida técnica foi posteriormente revisto em várias ocasiões, geralmente a o de fi definição de dívida técnica foi posteriormente revisto em várias ocasiões, geralmente a o de fi definição de dívida técnica foi posteriormente revisto em várias ocasiões, geralmente a 
generalizar o que Cunningham tinha descrito anteriormente para todas as situações aplicáveis 
​​enquanto categorizar suas características. Steve McConnell ' s de fi nição, que separa acúmulo ​​enquanto categorizar suas características. Steve McConnell ' s de fi nição, que separa acúmulo ​​enquanto categorizar suas características. Steve McConnell ' s de fi nição, que separa acúmulo ​​enquanto categorizar suas características. Steve McConnell ' s de fi nição, que separa acúmulo ​​enquanto categorizar suas características. Steve McConnell ' s de fi nição, que separa acúmulo 
intencionais e não intencionais de dívida técnica [7] , Tem sido amplamente adoptado pelo meio intencionais e não intencionais de dívida técnica [7] , Tem sido amplamente adoptado pelo meio intencionais e não intencionais de dívida técnica [7] , Tem sido amplamente adoptado pelo meio 
académico (por exemplo, em [8,9] e reconhecidos no [5] ): O fi tipo primeiro de dívida técnica é o académico (por exemplo, em [8,9] e reconhecidos no [5] ): O fi tipo primeiro de dívida técnica é o académico (por exemplo, em [8,9] e reconhecidos no [5] ): O fi tipo primeiro de dívida técnica é o académico (por exemplo, em [8,9] e reconhecidos no [5] ): O fi tipo primeiro de dívida técnica é o académico (por exemplo, em [8,9] e reconhecidos no [5] ): O fi tipo primeiro de dívida técnica é o académico (por exemplo, em [8,9] e reconhecidos no [5] ): O fi tipo primeiro de dívida técnica é o académico (por exemplo, em [8,9] e reconhecidos no [5] ): O fi tipo primeiro de dívida técnica é o 
tipo que é incorrido involuntariamente. Por exemplo, uma abordagem de design apenas acaba por 
ser um programador júnior propenso a erros ou apenas escreve código ruim. Esta dívida técnica é 
o resultado não estratégica de fazer um mau trabalho. Em alguns casos, este tipo de dívida pode 
ser incorrido sem saber ... O segundo tipo de dívida técnica é o tipo em que se incorre
J. Holvitie et al. Tecnologia da Informação e Software xxx (xxxx) xxx-xxx
2
intencionalmente. Isso geralmente ocorre quando uma organização toma uma decisão 
consciente para otimizar para o presente ao invés de para o futuro. “ Se nós don ' t obtereste consciente para otimizar para o presente ao invés de para o futuro. “ Se nós don ' t obter este consciente para otimizar para o presente ao invés de para o futuro. “ Se nós don ' t obter este consciente para otimizar para o presente ao invés de para o futuro. “ Se nós don ' t obter este consciente para otimizar para o presente ao invés de para o futuro. “ Se nós don ' t obter este 
lançamento feito na hora, não ganhou ' t ser um próximo lançamento ”...lançamento feito na hora, não ganhou ' t ser um próximo lançamento ”...lançamento feito na hora, não ganhou ' t ser um próximo lançamento ”...lançamento feito na hora, não ganhou ' t ser um próximo lançamento ”...
Com base McConnell ' avaliação s, Brown et al. [10] fornecer uma descrição do e ff ECTS de Com base McConnell ' avaliação s, Brown et al. [10] fornecer uma descrição do e ff ECTS de Com base McConnell ' avaliação s, Brown et al. [10] fornecer uma descrição do e ff ECTS de Com base McConnell ' avaliação s, Brown et al. [10] fornecer uma descrição do e ff ECTS de Com base McConnell ' avaliação s, Brown et al. [10] fornecer uma descrição do e ff ECTS de Com base McConnell ' avaliação s, Brown et al. [10] fornecer uma descrição do e ff ECTS de Com base McConnell ' avaliação s, Brown et al. [10] fornecer uma descrição do e ff ECTS de 
dívida técnica durante o desenvolvimento de software por relacionar o conceito a sua fi contrapartida dívida técnica durante o desenvolvimento de software por relacionar o conceito a sua fi contrapartida dívida técnica durante o desenvolvimento de software por relacionar o conceito a sua fi contrapartida 
financeira:
A metáfora destaca que, como fi da dívida financeira, dívida técnica incorre em pagamento de A metáfora destaca que, como fi da dívida financeira, dívida técnica incorre em pagamento de A metáfora destaca que, como fi da dívida financeira, dívida técnica incorre em pagamento de 
juros na forma de aumento dos custos futuros devido a escolhas anteriores de design e 
implementação rápida e suja. Gostar
fi da dívida financeira, por vezes, dívida técnica pode ser necessária. Pode-se continuar a pagar fi da dívida financeira, por vezes, dívida técnica pode ser necessária. Pode-se continuar a pagar 
juros ou pagar o principal por rearquitetar e refatoração para reduzir os pagamentos de juros 
futuros. Como este de fi definição é o único de fi definição - para o melhor dos autores 'futuros. Como este de fi definição é o único de fi definição - para o melhor dos autores 'futuros. Como este de fi definição é o único de fi definição - para o melhor dos autores 'futuros. Como este de fi definição é o único de fi definição - para o melhor dos autores 'futuros. Como este de fi definição é o único de fi definição - para o melhor dos autores 'futuros. Como este de fi definição é o único de fi definição - para o melhor dos autores 'futuros. Como este de fi definição é o único de fi definição - para o melhor dos autores 'futuros. Como este de fi definição é o único de fi definição - para o melhor dos autores '
conhecimento - com uma referência monetária explícita, é de interesse a partir de um de fi definição conhecimento - com uma referência monetária explícita, é de interesse a partir de um de fi definição conhecimento - com uma referência monetária explícita, é de interesse a partir de um de fi definição conhecimento - com uma referência monetária explícita, é de interesse a partir de um de fi definição conhecimento - com uma referência monetária explícita, é de interesse a partir de um de fi definição 
perspectiva quando se envolver praticantes (Veja o
Questionário para operacionalização de ambos de fi definições http: //soft.utu.Questionário para operacionalização de ambos de fi definições http: //soft.utu.Questionário para operacionalização de ambos de fi definições http: //soft.utu.Questionário para operacionalização de ambos de fi definições http: //soft.utu.
fi / tds16 / questionnaire.pdf , Pergunta 22). Dado que o de previamente sintetizado fi definições são fi / tds16 / questionnaire.pdf , Pergunta 22). Dado que o de previamente sintetizado fi definições são fi / tds16 / questionnaire.pdf , Pergunta 22). Dado que o de previamente sintetizado fi definições são fi / tds16 / questionnaire.pdf , Pergunta 22). Dado que o de previamente sintetizado fi definições são fi / tds16 / questionnaire.pdf , Pergunta 22). Dado que o de previamente sintetizado fi definições são 
tanto abstrato e genérico, outros pesquisadores têm procurado contextualizar dívida técnica. Por 
exemplo, Alves et al. [9] fornecida uma ontologia para a dívida técnica, explicando que 13 di ff tipos exemplo, Alves et al. [9] fornecida uma ontologia para a dívida técnica, explicando que 13 di ff tipos exemplo, Alves et al. [9] fornecida uma ontologia para a dívida técnica, explicando que 13 di ff tipos exemplo, Alves et al. [9] fornecida uma ontologia para a dívida técnica, explicando que 13 di ff tipos exemplo, Alves et al. [9] fornecida uma ontologia para a dívida técnica, explicando que 13 di ff tipos 
erent de dívida técnica pode ser útil distinguidos (por exemplo, design, arquitetura e dívida testes [11,12]erent de dívida técnica pode ser útil distinguidos (por exemplo, design, arquitetura e dívida testes [11,12]
). A contextualização da dívida técnica em seu modelo é aparente através do nome do tipo que 
indica o contexto software a partir do qual o tipo ' exemplos s originam. Kruchten et al. forneceram indica o contexto software a partir do qual o tipo ' exemplos s originam. Kruchten et al. forneceram indica o contexto software a partir do qual o tipo ' exemplos s originam. Kruchten et al. forneceram 
uma paisagem Técnico da dívida [8] (Adicionalmente discutido por Izurieta et al. [13] ) Que captura um uma paisagem Técnico da dívida [8] (Adicionalmente discutido por Izurieta et al. [13] ) Que captura um uma paisagem Técnico da dívida [8] (Adicionalmente discutido por Izurieta et al. [13] ) Que captura um uma paisagem Técnico da dívida [8] (Adicionalmente discutido por Izurieta et al. [13] ) Que captura um uma paisagem Técnico da dívida [8] (Adicionalmente discutido por Izurieta et al. [13] ) Que captura um 
conjunto de causas que são ditas para levar ao surgimento de dívida técnica.
Na paisagem Técnico da dívida, as causas são introduzidos, colocando-os em relação aos dois 
eixos. o fi eixo primeira caracteriza a sua visibilidade, de visíveis (ou seja, os novos recursos, eixos. o fi eixo primeira caracteriza a sua visibilidade, de visíveis (ou seja, os novos recursos, eixos. o fi eixo primeira caracteriza a sua visibilidade, de visíveis (ou seja, os novos recursos, 
funcionalidade adicional, defeitos e baixa qualidade externa) para quase invisível (ou seja, dívida 
estrutural da dívida arquitectónica, a dívida teste, a dívida documentação, a complexidade do código, 
baixa qualidade interna, estilo de codificação violações e código de cheiros), enquanto o segundo 
eixo caracteriza o tipo de problema, de evolução para a qualidade (onde os problemas listados 
anteriormente, os novos recursos, funcionalidade adicional, a dívida arquitetônico, dívida estrutural e 
da dívida teste são questões evolução, codificação violações de estilo, código de cheiros, defeitos, e 
baixa qualidade externa são questões de qualidade e dívida documentação, a complexidade do 
código e baixa queda de qualidade interna entre eles).
Autores da paisagem argumentam que as causas que são claramente visíveis na verdade não 
contam dívida como técnico, enquanto os problemas na sua maioria invisíveis contam. O raciocínio 
dada para essa divisão é que as questões visíveis têm representações explícitas e auto-evidentes. A 
organização de desenvolvimento entende daí a necessidade, ou pelo menos a oportunidade, para 
gerenciá-los. As questões na sua maioria invisíveis acumular dívida técnica porque o seu surgimento, 
presença e e negativo ff ECTS permanecem largamentedesconhecidos. Somente os desenvolvedores presença e e negativo ff ECTS permanecem largamente desconhecidos. Somente os desenvolvedores presença e e negativo ff ECTS permanecem largamente desconhecidos. Somente os desenvolvedores 
de software que adquiriram conhecimento adicional através do desenvolvimento compreender essas 
questões.
No nosso instrumento de pesquisa procuramos considerar essas duas causas visíveis e 
invisíveis como nós queremos descobrir se respondentes semelhante perceber 
esta divisão (ver http: //soft.utu. fi / tds16 /esta divisão (ver http: //soft.utu. fi / tds16 /esta divisão (ver http: //soft.utu. fi / tds16 /esta divisão (ver http: //soft.utu. fi / tds16 /
questionnaire.pdf , Pergunta 31 para os autores ' adaptação desta).questionnaire.pdf , Pergunta 31 para os autores ' adaptação desta).questionnaire.pdf , Pergunta 31 para os autores ' adaptação desta).questionnaire.pdf , Pergunta 31 para os autores ' adaptação desta).
Em ir um passo adiante, uma série de estudos têm-se esforçado para validar vários 
contextualizações e clari fi cátions de dívida técnica, muitas vezes através da utilização de contextualizações e clari fi cátions de dívida técnica, muitas vezes através da utilização de contextualizações e clari fi cátions de dívida técnica, muitas vezes através da utilização de 
instrumentos de entrevista ou pesquisa. Nós analisamos estes próxima situar nosso estudo, no 
estado actual do conhecimento.
2.2. estudos transversais de dívida técnica
Uma ampla gama de estudos transversais de dívida técnica têm sido relatados na literatura, 
alguns dos quais procurou caracterizar o fenômeno, enquanto outros abordados como dívida técnica 
é incorrido. Nós
rever uma selecção não exaustiva desses estudos aqui, a fim de fornecer o contexto para o nosso 
próprio trabalho baseado em inquéritos.
Klinger et al. [14] entrevistado quatro arquitetos de software sobre a acumulação de dívida Klinger et al. [14] entrevistado quatro arquitetos de software sobre a acumulação de dívida Klinger et al. [14] entrevistado quatro arquitetos de software sobre a acumulação de dívida 
técnica. Eles observaram que muitas vezes a decisão de incorrer em dívida foi derivado das 
motivações dos interessados ​​não técnicos, e, portanto, poderia ser um ff ected por concorrentes motivações dos interessados ​​não técnicos, e, portanto, poderia ser um ff ected por concorrentes motivações dos interessados ​​não técnicos, e, portanto, poderia ser um ff ected por concorrentes 
interesses dos intervenientes (por exemplo, uma solução tecnicamente sub-óptima foi escolhido 
devido a preocupações de prensagem de negócios). Foi, no entanto, concluiu que quanti fi cação de devido a preocupações de prensagem de negócios). Foi, no entanto, concluiu que quanti fi cação de devido a preocupações de prensagem de negócios). Foi, no entanto, concluiu que quanti fi cação de 
dívida técnica deve tornar a informação relevante mais disponível (de modo a ser visível para a 
equipe do projeto), e, portanto, deve permitir mais e ff gerenciamento de projetos ective.equipe do projeto), e, portanto, deve permitir mais e ff gerenciamento de projetos ective.equipe do projeto), e, portanto, deve permitir mais e ff gerenciamento de projetos ective.
Snipes et ai. [15] pesquisadas duas placas de controle de mudanças para compreender os fatores de Snipes et ai. [15] pesquisadas duas placas de controle de mudanças para compreender os fatores de Snipes et ai. [15] pesquisadas duas placas de controle de mudanças para compreender os fatores de 
decisão que cercam a governança da dívida defeito. eles identifi-
fi ed um conjunto de factores que um ff acumulação ected e redução da dívida técnica, relacionando-os fi ed um conjunto de factores que um ff acumulação ected e redução da dívida técnica, relacionando-os fi ed um conjunto de factores que um ff acumulação ected e redução da dívida técnica, relacionando-os fi ed um conjunto de factores que um ff acumulação ected e redução da dívida técnica, relacionando-os 
para o sucesso das estratégias de gestão escolhidos. Snipes et ai. [15] observou ainda que a maioria para o sucesso das estratégias de gestão escolhidos. Snipes et ai. [15] observou ainda que a maioria para o sucesso das estratégias de gestão escolhidos. Snipes et ai. [15] observou ainda que a maioria 
dos recursos de gerenciamento de defeito de software foram gastos em identi fi catião e dos recursos de gerenciamento de defeito de software foram gastos em identi fi catião e dos recursos de gerenciamento de defeito de software foram gastos em identi fi catião e 
caracterização, em vez da remoção real de defeitos (e, em última análise, a redução do débito 
técnico).
Martini e Bosch [16] estudou as necessidades de informação dos ágil arquitetos de software e Martini e Bosch [16] estudou as necessidades de informação dos ágil arquitetos de software e Martini e Bosch [16] estudou as necessidades de informação dos ágil arquitetos de software e 
proprietários do produto em relação a dívida técnica arquitetônica (ATD). Eles analisaram dados 
qualitativos e quantitativos recolhidos a partir de quatro grandes empresas de desenvolvimento de 
software. Seus
fi achados indicam que, para as funções de arquiteto e proprietário do produto, as necessidades de informação fi achados indicam que, para as funções de arquiteto e proprietário do produto, as necessidades de informação 
foram di ff erent. Notavelmente, os proprietários do produto valorizado atratividade de mercado e especificidade fi o foram di ff erent. Notavelmente, os proprietários do produto valorizado atratividade de mercado e especificidade fi o foram di ff erent. Notavelmente, os proprietários do produto valorizado atratividade de mercado e especificidade fi o foram di ff erent. Notavelmente, os proprietários do produto valorizado atratividade de mercado e especificidade fi o foram di ff erent. Notavelmente, os proprietários do produto valorizado atratividade de mercado e especificidade fi o 
valor do cliente c mais altamente do que os arquitetos de software.
Martini et al. [17] Também relatou um estudo para estabelecer causas para a acumulação de Martini et al. [17] Também relatou um estudo para estabelecer causas para a acumulação de Martini et al. [17] Também relatou um estudo para estabelecer causas para a acumulação de 
ATD, bem como a sua refatoramento. O estudo foi executado como um estudo de caso múltiplo em fi ve ATD, bem como a sua refatoramento. O estudo foi executado como um estudo de caso múltiplo em fi ve ATD, bem como a sua refatoramento. O estudo foi executado como um estudo de caso múltiplo em fi ve 
grandes empresas de desenvolvimento de software. Com base nas entrevistas realizadas uma série 
de causas para ATD foi identi fi ed e validado (por exemplo, a incerteza dos casos de utilização em de causas para ATD foi identi fi ed e validado (por exemplo, a incerteza dos casos de utilização em de causas para ATD foi identi fi ed e validado (por exemplo, a incerteza dos casos de utilização em 
estágios iniciais). Martini et al. apresentados dois modelos para a acumulação de ATD e evolução: 
crise e fases. O modelo de crise capturado um fenômeno contemporâneo, onde ATD foi permitido 
acumular até o ponto ao adicionar um novo valor para o negócio era demasiado pesado, e uma 
grande refatoração teve que ser executado. O Modelo Fases capturado o di ff períodos de tempo erent grande refatoração teve que ser executado. O Modelo Fases capturado o di ff períodos de tempo erent grande refatoração teve que ser executado. O Modelo Fases capturado o di ff períodos de tempo erent 
em relação ao recurso de pesquisa, design e implementação, que poderia ser identi fi ed ter di ff Ering em relação ao recurso de pesquisa, design e implementação, que poderia ser identi fi ed ter di ff Ering em relação ao recurso de pesquisa, design e implementação, que poderia seridenti fi ed ter di ff Ering em relação ao recurso de pesquisa, design e implementação, que poderia ser identi fi ed ter di ff Ering em relação ao recurso de pesquisa, design e implementação, que poderia ser identi fi ed ter di ff Ering 
propriedades de acumulação ATD. Assim, este modelo poderia ser usado para reconhecer di ff Ering propriedades de acumulação ATD. Assim, este modelo poderia ser usado para reconhecer di ff Ering propriedades de acumulação ATD. Assim, este modelo poderia ser usado para reconhecer di ff Ering 
ATD acumulação, evasão e refatoração oportunidades.
Spinola et al. [18] compilou uma lista de folclore dívida técnica e os profissionais pesquisados Spinola et al. [18] compilou uma lista de folclore dívida técnica e os profissionais pesquisados Spinola et al. [18] compilou uma lista de folclore dívida técnica e os profissionais pesquisados 
​​para determinar a extensão do seu acordo com essas crenças. Consenso foi indicada por: “ dívida ​​para determinar a extensão do seu acordo com essas crenças. Consenso foi indicada por: “ dívida ​​para determinar a extensão do seu acordo com essas crenças. Consenso foi indicada por: “ dívida 
técnica muitas vezes acumula via otimizações de curto prazo, a redução da dívida técnica é bom 
para o moral, não-gestão da dívida resultados técnicos em insustentabilidade ”, epara o moral, não-gestão da dívida resultados técnicos em insustentabilidade ”, epara o moral, não-gestão da dívida resultados técnicos em insustentabilidade ”, e
“ não toda a dívida técnica é negativo - é por isso que não deve ser evitada, mas sim, conseguiu ”. O “ não toda a dívida técnica é negativo - é por isso que não deve ser evitada, mas sim, conseguiu ”. O “ não toda a dívida técnica é negativo - é por isso que não deve ser evitada, mas sim, conseguiu ”. O “ não toda a dívida técnica é negativo - é por isso que não deve ser evitada, mas sim, conseguiu ”. O 
estudo ' s autores notaram, no entanto, que o baixo número de respostas (=estudo ' s autores notaram, no entanto, que o baixo número de respostas (=estudo ' s autores notaram, no entanto, que o baixo número de respostas (=
N 37) limita a generalização da sua re-N 37) limita a generalização da sua re-N 37) limita a generalização da sua re-
sultados.
Lim et al. [19] entrevistou 35 profissionais a respeito de como técnico da dívida manifesta e Lim et al. [19] entrevistou 35 profissionais a respeito de como técnico da dívida manifesta e Lim et al. [19] entrevistou 35 profissionais a respeito de como técnico da dívida manifesta e 
como ele foi geralmente gerida. No seu estudo, Lim et al. observou que 75% de seus entrevistados 
inicialmente indicaram que não estavam familiarizados com o termo “ dívida técnica ”. Depois de inicialmente indicaram que não estavam familiarizados com o termo “ dívida técnica ”. Depois de inicialmente indicaram que não estavam familiarizados com o termo “ dívida técnica ”. Depois de inicialmente indicaram que não estavam familiarizados com o termo “ dívida técnica ”. Depois de inicialmente indicaram que não estavam familiarizados com o termo “ dívida técnica ”. Depois de 
descrever o conceito, os entrevistados que estavam familiarizados com o conceito indicou que 
decisões informadas, por vezes, resultou na equipe incorrer em dívida técnica, e que o e ff ECTS decisões informadas, por vezes, resultou na equipe incorrer em dívida técnica, e que o e ff ECTS decisões informadas, por vezes, resultou na equipe incorrer em dívida técnica, e que o e ff ECTS 
deste fenômeno são a longo prazo. Além disso, a gestão da dívida técnica foi visto como sendo 
geralmente di ffi cult, como rastreamento de casos de dívida técnicos não uniformes foi um exercício geralmente di ffi cult, como rastreamento de casos de dívida técnicos não uniformes foi um exercício geralmente di ffi cult, como rastreamento de casos de dívida técnicos não uniformes foi um exercício 
desafiador.
Codabux et al. [20] estudadas, dentro de uma grande organização de software, como dívida Codabux et al. [20] estudadas, dentro de uma grande organização de software, como dívida Codabux et al. [20] estudadas, dentro de uma grande organização de software, como dívida 
técnica poderia ser caracterizada, a dívida ' se ff ECTS no desenvolvimento de software, e os seus técnica poderia ser caracterizada, a dívida ' se ff ECTS no desenvolvimento de software, e os seus técnica poderia ser caracterizada, a dívida ' se ff ECTS no desenvolvimento de software, e os seus técnica poderia ser caracterizada, a dívida ' se ff ECTS no desenvolvimento de software, e os seus técnica poderia ser caracterizada, a dívida ' se ff ECTS no desenvolvimento de software, e os seus 
procedimentos de gestão. Eles concluíram que uma taxonomia in-house foi percebido como útil para 
a caracterização da dívida técnica, enquanto as medidas explícitas foram encorajados para a gestão 
(por exemplo, equipes dedicadas e descrições de tarefas). Codabux et al.
J. Holvitie et al. Tecnologia da Informação e Software xxx (xxxx) xxx-xxx
3
[20] descobriu que priorizar a gestão da dívida técnica, particularmente com base em partes [20] descobriu que priorizar a gestão da dívida técnica, particularmente com base em partes 
interessadas ' percepções da gravidade da dívida, foi classificado alto entre as medidas para interessadas ' percepções da gravidade da dívida, foi classificado alto entre as medidas para interessadas ' percepções da gravidade da dívida, foi classificado alto entre as medidas para 
combater a dívida técnica. Estes resultados foram obtidos por meio de entrevistas com 28 gerentes 
de projeto.
Ernst et al. [21] inquiridas 1831 entrevistados a partir de três grandes organizações e recebeu Ernst et al. [21] inquiridas 1831 entrevistados a partir de três grandes organizações e recebeu Ernst et al. [21] inquiridas 1831 entrevistados a partir de três grandes organizações e recebeu 
536 questionários completamente preenchidos. Eles exploraram se praticantes compartilhado uma 
dívida comum de técnico fi nição, se problemas com componentes de arquitetura estavam entre os dívida comum de técnico fi nição, se problemas com componentes de arquitetura estavam entre os dívida comum de técnico fi nição, se problemas com componentes de arquitetura estavam entre os 
principais contribuintes de dívida técnica, e se houve práticas e ferramentas prontamente disponíveis 
para a gestão da dívida técnico e monitoramento. Estes autores estabeleceram que os profissionais 
de software e gerentes tinham um entendimento uniforme da dívida técnica. Além disso, o estudo ' s de software e gerentes tinham um entendimento uniforme da dívida técnica. Além disso, o estudo ' s de software e gerentes tinham um entendimento uniforme da dívida técnica. Além disso, o estudo ' s 
autores descobriram que as escolhas de arquitectura, especialmente nas fases iniciais do ciclo de 
vida de desenvolvimento de software (como observado também por Martini et al. [17] ), Foram um dos vida de desenvolvimento de software (como observado também por Martini et al. [17] ), Foram um dos vida de desenvolvimento de software (como observado também por Martini et al. [17] ), Foram um dos 
principais contribuintes da dívida técnica. Além disso, revelou-se que há uma falta de apoio 
ferramenta para gerenciamento de dívida técnica arquitetônica. No entanto, há limites para o grau em 
que os resultados de Ernst et ai. poderia ser considerado como geral ou típico, uma vez que capturou 
a percepção de funcionários de três empresas.
Finalmente, um estudo muito recente por Behutiye et al. [22] relata os resultados de uma Finalmente, um estudo muito recente por Behutiye et al. [22] relata os resultados de uma Finalmente, um estudo muito recente por Behutiye et al. [22] relata os resultados de uma 
revisão sistemática da literatura que abordou o conceito de dívida técnica no contexto do 
desenvolvimentoágil de software. A análise de 38 artigos relevantes levou os autores a identificar 
áreas de interesse, porque a dívida técnica e de pesquisa e ff ect classi fi cações, bem como áreas de interesse, porque a dívida técnica e de pesquisa e ff ect classi fi cações, bem como áreas de interesse, porque a dívida técnica e de pesquisa e ff ect classi fi cações, bem como áreas de interesse, porque a dívida técnica e de pesquisa e ff ect classi fi cações, bem como áreas de interesse, porque a dívida técnica e de pesquisa e ff ect classi fi cações, bem como 
estratégias de gestão de pesquisa existente. Os resultados deste trabalho adicionar ao corpo de 
conhecimento em torno de dívida técnica, e apoiar a unidade para estudar mais este assunto.
Ao rever o corpo de pesquisa que acabamos de descrever é notável que existe uma lacuna de 
investigação particular. Embora estudos examinaram especi fi aspectos c de dívida técnica, incluindo investigação particular. Embora estudos examinaram especi fi aspectos c de dívida técnica, incluindo investigação particular. Embora estudos examinaram especi fi aspectos c de dívida técnica, incluindo 
como técnico da dívida se acumula durante o desenvolvimento de software, fatores de decisão para 
a governança da dívida, e como dívida técnica pode ser caracterizada, trabalho anterior não 
proporciona um tratamento sistemático das características dos casos de dívida técnicas concretas. 
Há também muito pouco trabalho sobre a dinâmica, o tamanho e e ff ECTS causada pela dívida Há também muito pouco trabalho sobre a dinâmica, o tamanho e e ff ECTS causada pela dívida Há também muito pouco trabalho sobre a dinâmica, o tamanho e e ff ECTS causada pela dívida 
técnica quando desenvolvimento de software está em curso. Da mesma forma, enquanto as práticas 
de desenvolvimento ágil de software são disse a ser capaz de resistir (e atenuante) a e ff ECTS de de desenvolvimento ágil de software são disse a ser capaz de resistir (e atenuante) a e ff ECTS de de desenvolvimento ágil de software são disse a ser capaz de resistir (e atenuante) a e ff ECTS de 
dívida técnica [23] , Trabalhos anteriores não examinou o e ff ECTS de tais práticas sobre a ocorrência dívida técnica [23] , Trabalhos anteriores não examinou o e ff ECTS de tais práticas sobre a ocorrência dívida técnica [23] , Trabalhos anteriores não examinou o e ff ECTS de tais práticas sobre a ocorrência dívida técnica [23] , Trabalhos anteriores não examinou o e ff ECTS de tais práticas sobre a ocorrência dívida técnica [23] , Trabalhos anteriores não examinou o e ff ECTS de tais práticas sobre a ocorrência 
e gestão de dívida técnica.
Na verdade, ainda não está claro se e quando dívida técnica é provável a acumular o máximo 
em termos da especificidade fi c as fases de desenvolvimento de software. Ernst et al. [21] note que em termos da especificidade fi c as fases de desenvolvimento de software. Ernst et al. [21] note que em termos da especificidade fi c as fases de desenvolvimento de software. Ernst et al. [21] note que em termos da especificidade fi c as fases de desenvolvimento de software. Ernst et al. [21] note que em termos da especificidade fi c as fases de desenvolvimento de software. Ernst et al. [21] note que 
componentes de arquitetura e decisões earlystage contribuir para dívida técnica, no entanto, se estas 
ocorrem dentro de um específico fi fase de desenvolvimento c, especialmente em relação a outras ocorrem dentro de um específico fi fase de desenvolvimento c, especialmente em relação a outras ocorrem dentro de um específico fi fase de desenvolvimento c, especialmente em relação a outras 
fases de desenvolvimento de software, permanece indeterminada. Como tal, insights sobre estas 
questões poderia ser útil para os responsáveis ​​pela gestão da dívida técnica. Além recomendações 
para os profissionais, os resultados de tais investigações também enriquecer o conjunto base de 
conhecimento e literatura em torno da dívida técnica. A seguir, consideramos parte da literatura que 
abordou o desenvolvimento ágil de software, que define o tom para a nossa agenda de pesquisa e a 
especificidade fi técnicas c que são usados ​​no trabalho atual (consulte seção 3 ).especificidade fi técnicas c que são usados ​​no trabalho atual (consulte seção 3 ).especificidade fi técnicas c que são usados ​​no trabalho atual (consulte seção 3 ).especificidade fi técnicas c que são usados ​​no trabalho atual (consulte seção 3 ).especificidade fi técnicas c que são usados ​​no trabalho atual (consulte seção 3 ).
2.3. desenvolvimento de software Agile
O Manifesto Ágil [1] ré fl ECTS uma filosofia de desenvolvimento de software que enfatiza um O Manifesto Ágil [1] ré fl ECTS uma filosofia de desenvolvimento de software que enfatiza um O Manifesto Ágil [1] ré fl ECTS uma filosofia de desenvolvimento de software que enfatiza um O Manifesto Ágil [1] ré fl ECTS uma filosofia de desenvolvimento de software que enfatiza um O Manifesto Ágil [1] ré fl ECTS uma filosofia de desenvolvimento de software que enfatiza um 
contexto em que os recursos são escassos e as necessidades volatilidade é alta. Dadas as muitas 
vozes de apoio a métodos ágeis, estas abordagens tornaram-se amplamente adotado e estudado
[24] . O desenvolvimento ágil é implementado por vários métodos, e de acordo com Dyba et al. [25] , [24] . O desenvolvimento ágil é implementado por vários métodos, e de acordo com Dyba et al. [25] , [24] . O desenvolvimento ágil é implementado por vários métodos, e de acordo com Dyba et al. [25] , [24] . O desenvolvimento ágil é implementado por vários métodos, e de acordo com Dyba et al. [25] , 
Dos muitos fl avors de ágil programação, Extrema (XP) [26] e Scrum [23] são dois dos mais Dos muitos fl avors de ágil programação, Extrema (XP) [26] e Scrum [23] são dois dos mais Dos muitos fl avors de ágil programação, Extrema (XP) [26] e Scrum [23] são dois dos mais Dos muitos fl avors de ágil programação, Extrema (XP) [26] e Scrum [23] são dois dos mais Dos muitos fl avors de ágil programação, Extrema (XP) [26] e Scrum [23] são dois dos mais Dos muitos fl avors de ágil programação, Extrema (XP) [26] e Scrum [23] são dois dos mais Dos muitos fl avors de ágil programação, Extrema (XP) [26] e Scrum [23] são dois dos mais 
amplamente estudado. Da mesma forma, estas duas abordagens também são considerados para ser 
o mais adotado na indústria de desenvolvimento de software [27,28] . Assim, agora brie fl y examinar o mais adotado na indústria de desenvolvimento de software [27,28] . Assim, agora brie fl y examinar o mais adotado na indústria de desenvolvimento de software [27,28] . Assim, agora brie fl y examinar o mais adotado na indústria de desenvolvimento de software [27,28] . Assim, agora brie fl y examinar o mais adotado na indústria de desenvolvimento de software [27,28] . Assim, agora brie fl y examinar 
essas abordagens.
O método XP é visto para implementar o manifesto ágil ' sO método XP é visto para implementar o manifesto ágil ' sO método XP é visto para implementar o manifesto ágil ' s
recomendações, principalmente através de 12 práticas, que são aplicados em todo o 
desenvolvimento de software. Por exemplo, a On-Site clientedesenvolvimento de software. Por exemplo, a On-Site cliente
prática (ver o Questionário http: //soft.utu. fi / tds16 / questionário. pdf , Q14 para as práticas do método prática (ver o Questionário http: //soft.utu. fi / tds16 / questionário. pdf , Q14 para as práticas do método prática (ver o Questionário http: //soft.utu. fi / tds16 / questionário. pdf , Q14 para as práticas do método prática (ver o Questionário http: //soft.utu. fi / tds16 / questionário. pdf , Q14 para as práticas do método prática (ver o Questionário http: //soft.utu. fi / tds16 / questionário. pdf , Q14 para as práticas do método 
de Extreme Programming) apela para que o cliente possa estar sempre disponível. Esta prática é dito 
para diminuir otempo de feedback, como os desenvolvedores podem consultar o cliente ' s opinião e para diminuir o tempo de feedback, como os desenvolvedores podem consultar o cliente ' s opinião e para diminuir o tempo de feedback, como os desenvolvedores podem consultar o cliente ' s opinião e 
resolver problemas rapidamente, resultando em menos reajustes caros [26] . Como complemento, o resolver problemas rapidamente, resultando em menos reajustes caros [26] . Como complemento, o resolver problemas rapidamente, resultando em menos reajustes caros [26] . Como complemento, o 
método de scrum fi nes processos e artefactos do processo. Aqui, o feedback do cliente (como método de scrum fi nes processos e artefactos do processo. Aqui, o feedback do cliente (como método de scrum fi nes processos e artefactos do processo. Aqui, o feedback do cliente (como 
mencionado para XP) é implementado principalmente na iteração comentário processo (ver o mencionado para XP) é implementado principalmente na iteração comentário processo (ver o mencionado para XP) é implementado principalmente na iteração comentário processo (ver o 
questionário http: // macio. utu. fi / tds16 / questionnaire.pdf , Q15 para os componentes do processo questionário http: // macio. utu. fi / tds16 / questionnaire.pdf , Q15 para os componentes do processo questionário http: // macio. utu. fi / tds16 / questionnaire.pdf , Q15 para os componentes do processo questionário http: // macio. utu. fi / tds16 / questionnaire.pdf , Q15 para os componentes do processo questionário http: // macio. utu. fi / tds16 / questionnaire.pdf , Q15 para os componentes do processo 
abstraída do método scrum), que exige a conclusão de cada iteração de desenvolvimento com uma 
reunião em que o Dono do produto serve como um representante do cliente e fornece feedback [23] . reunião em que o Dono do produto serve como um representante do cliente e fornece feedback [23] . reunião em que o Dono do produto serve como um representante do cliente e fornece feedback [23] . reunião em que o Dono do produto serve como um representante do cliente e fornece feedback [23] . reunião em que o Dono do produto serve como um representante do cliente e fornece feedback [23] . 
Como Scrum de fi processos nes e XP se concentra em práticas, em conjunto, estes métodos Como Scrum de fi processos nes e XP se concentra em práticas, em conjunto, estes métodos Como Scrum de fi processos nes e XP se concentra em práticas, em conjunto, estes métodos 
fornecem uma representação adequada de desenvolvimento ágil de software [29] . Temos usado, fornecem uma representação adequada de desenvolvimento ágil de software [29] . Temos usado, fornecem uma representação adequada de desenvolvimento ágil de software [29] . Temos usado, 
portanto, estes métodos como base para a investigação específica fi práticas de desenvolvimento de portanto, estes métodos como base para a investigação específica fi práticas de desenvolvimento de portanto, estes métodos como base para a investigação específica fi práticas de desenvolvimento de 
software c e processos neste trabalho.
3. abordagem Research
Nos três subsecções seguintes ( Pontos 3.1, 3.2 e 3,3 ) nósNos três subsecções seguintes ( Pontos 3.1, 3.2 e 3,3 ) nósNos três subsecções seguintes ( Pontos 3.1, 3.2 e 3,3 ) nósNos três subsecções seguintes ( Pontos 3.1, 3.2 e 3,3 ) nósNos três subsecções seguintes ( Pontos 3.1, 3.2 e 3,3 ) nós
explicar nossa abordagem de pesquisa. Nós fi primeiro de fi ne nossas questões de pesquisa emexplicar nossa abordagem de pesquisa. Nós fi primeiro de fi ne nossas questões de pesquisa emexplicar nossa abordagem de pesquisa. Nós fi primeiro de fi ne nossas questões de pesquisa emexplicar nossa abordagem de pesquisa. Nós fi primeiro de fi ne nossas questões de pesquisa emexplicar nossa abordagem de pesquisa. Nós fi primeiro de fi ne nossas questões de pesquisa em
seção 3.1 E descrever a forma como o estudo foi desenvolvido em seção 3.2 . Em seguida, no fi secção seção 3.1 E descrever a forma como o estudo foi desenvolvido em seção 3.2 . Em seguida, no fi secção seção 3.1 E descrever a forma como o estudo foi desenvolvido em seção 3.2 . Em seguida, no fi secção seção 3.1 E descrever a forma como o estudo foi desenvolvido em seção 3.2 . Em seguida, no fi secção seção 3.1 E descrever a forma como o estudo foi desenvolvido em seção 3.2 . Em seguida, no fi secção seção 3.1 E descrever a forma como o estudo foi desenvolvido em seção 3.2 . Em seguida, no fi secção 
final ( seção 3.3 ), Descreve-se como e por que o estudo é realizado em três países (Brasil, Finlândia final ( seção 3.3 ), Descreve-se como e por que o estudo é realizado em três países (Brasil, Finlândia final ( seção 3.3 ), Descreve-se como e por que o estudo é realizado em três países (Brasil, Finlândia 
e Nova Zelândia).
3.1. Questões de pesquisa
relatórios anteriores [20,23] indicam que o “ dívida técnica ” metáfora tem sido aplicado por relatórios anteriores [20,23] indicam que o “ dívida técnica ” metáfora tem sido aplicado por relatórios anteriores [20,23] indicam que o “ dívida técnica ” metáfora tem sido aplicado por relatórios anteriores [20,23] indicam que o “ dívida técnica ” metáfora tem sido aplicado por relatórios anteriores [20,23] indicam que o “ dívida técnica ” metáfora tem sido aplicado por relatórios anteriores [20,23] indicam que o “ dívida técnica ” metáfora tem sido aplicado por relatórios anteriores [20,23] indicam que o “ dívida técnica ” metáfora tem sido aplicado por 
alguns médicos na indústria de desenvolvimento de software, e que esta metáfora também pode ser 
facilmente compreendida pelos membros da equipe não-técnicas (por exemplo, clientes, pessoal de 
gerentes e de vendas) [21] . Na verdade, foi alegado que tais metáforas poderia ajudar a fechar a gerentes e de vendas) [21] . Na verdade, foi alegado que tais metáforas poderia ajudar a fechar a gerentes e de vendas) [21] . Na verdade, foi alegado que tais metáforas poderia ajudar a fechar a 
lacuna de comunicação entre os indivíduos e as equipes de técnicos e não técnicos (incluindo 
gerentes de projeto) [7] . A utilidade de tal conhecimento seria, naturalmente, depender de indivíduos 'gerentes de projeto) [7] . A utilidade de tal conhecimento seria, naturalmente, depender de indivíduos 'gerentes de projeto) [7] . A utilidade de tal conhecimento seria, naturalmente, depender de indivíduos 'gerentes de projeto) [7] . A utilidade de tal conhecimento seria, naturalmente, depender de indivíduos '
percepções sobre dívida técnica, que podem ser em fl influenciadas por suas origens. No entanto, percepções sobre dívida técnica, que podem ser em fl influenciadas por suas origens. No entanto, percepções sobre dívida técnica, que podem ser em fl influenciadas por suas origens. No entanto, 
com o melhor de nosso conhecimento, trabalho anterior não considera esta questão, especialmente 
a partir de um de papéis e backgroundspeci fi c perspectiva.a partir de um de papéis e backgroundspeci fi c perspectiva.a partir de um de papéis e backgroundspeci fi c perspectiva.
Nós, portanto, examinar se os interessados ​​técnicos e não técnicos compartilham o mesmo 
entendimento do ' dívida técnica ' metáfora, como os entrevistados foram expostos a ela, e se eles entendimento do ' dívida técnica ' metáfora, como os entrevistados foram expostos a ela, e se eles entendimento do ' dívida técnica ' metáfora, como os entrevistados foram expostos a ela, e se eles entendimento do ' dívida técnica ' metáfora, como os entrevistados foram expostos a ela, e se eles entendimento do ' dívida técnica ' metáfora, como os entrevistados foram expostos a ela, e se eles 
percebem a metáfora para ser útil, respondendo à fi questão de pesquisa primeiro:percebem a metáfora para ser útil, respondendo à fi questão de pesquisa primeiro:percebem a metáfora para ser útil, respondendo à fi questão de pesquisa primeiro:
RQ1 ( a) Há di ff rências em diversas partes interessadas