Sin título

Página 1

O tema da dívida técnica (TD) tem recebido significativa atenção por parte dos pesquisadores nos últimos anos, uma vez que o modo como é gerenciado tem um impacto significativo na velocidade e nos benefícios do desenvolvimento de software [9]. O conceito foi inicialmente introduzido no contexto do desenvolvimento ágil, onde foi observado que um foco puro na entrega do próximo recurso pode ter consequências negativas significativas, uma vez que a capacidade de desenvolvimento adicional pode se deteriorar. Nesse contexto, Ward Cunningham propôs o conceito de dívida técnica [5] como uma metáfora para motivar a necessidade de refatoração [6]. Isso conecta a noção de dívida técnica diretamente ao problema de decidir quando e como refatorar a realização de um sistema para melhorar sua estrutura como base para uma evolução futura. Hoje, a TD está conectada com muitos aspectos diferentes no desenvolvimento de software, como a dívida de documentação, a dívida de requisitos, etc. (cf. [9]). No entanto, em nosso tratamento neste artigo, focaremos na intenção original do termo e nos concentraremos na estruturação da realização do sistema, em particular no nível arquitetural, e sua consequência para o sistema final e o esforço geral de desenvolvimento. Como suposição importante, teremos a perspectiva de que a dívida técnica equivale a uma realização abaixo do ideal de um sistema de software (ou parte dele), o que dificulta o desenvolvimento posterior. Mais precisamente, diferenciamos a dívida técnica potencial (PTD), ou seja, qualquer forma de realização de software que possa ser considerada abaixo do ideal, e a dívida técnica efetiva (ETD), ou seja, qualquer problema na realização de software que efetivamente impeça o desenvolvimento posterior [14]. ]. Assim, o software pode conter dívida técnica em potencial que não se torna efetiva: embora o software seja suboptimizado, isso não tem impacto no desenvolvimento futuro. Isso acontece se a parte correspondente do sistema não estiver sujeita a mais evolução. De uma perspectiva prática, é importante administrar uma dívida técnica eficaz e não se desviar de uma possível dívida técnica. Assim, vamos nos concentrar aqui no ETD. Embora o TD tenha recebido atenção significativa, até o momento não há um método bem formalizado que possa ser usado ao mesmo tempo para lidar com a dívida técnica. É aqui, onde este artigo pretende contribuir. Mais precisamente, forneceremos: 1. Uma formalização detalhada para permitir a quantificação da dívida técnica (efetiva). 2. Uma base formal e precisa para a tomada de decisões sobre dívida técnica, com base em nossa formalização técnica da dívida. 3. Mostramos que uma abordagem de tomada de decisão precisa leva necessariamente a problemas práticos. Abordamos isso fornecendo aproximações sistemáticas e bem definidas. 4. Derivamos um procedimento de tomada de decisão praticamente aplicável baseado em nossa formalização, que incorpora aproximações definidas e pode ser usado na prática no desenvolvimento iterativo. Consideramos a maior parte de nossa contribuição a formalização subjacente, pois ela pode fornecer a base para vários métodos específicos, além do que apresentamos. Assim, nosso foco principal com a abordagem que fornecemos é identificar claramente as aproximações que fazemos em cima de uma formalização precisa. Esperamos que outras abordagens específicas sejam derivadas no futuro, na mesma base formal, usando diferentes combinações ou tipos de aproximações. Um benefício adicional de nossa formalização completa é que ele identifica claramente as restrições e suposições de nossa abordagem. O resto do artigo está estruturado da seguinte forma. A seção 2 discute o trabalho relacionado à dívida técnica e sua gestão. Na Seção 3, fornecemos a base formal de nossa abordagem, enquanto a Seção 4 estende isso para a tomada de decisão em relação à dívida técnica. A seção 5 fornece as aproximações relevantes para tornar essa abordagem prática. Finalmente, na Seção 6, reunimos isso e derivamos um procedimento prático de tomada de decisão, enquanto na Seção 7 concluímos.

Neste trabalho, pretendemos fornecer várias contribuições. Nosso primeiro e provavelmente mais importante é desenvolver uma formalização detalhada do conceito de dívida técnica. Isso fornece uma base para uma abordagem formal à tomada de decisão do DT. Com a ajuda dessa formalização, pudemos demonstrar que uma análise precisa do endividamento técnico requer um espaço de busca basicamente infinito e requer a identificação de realizações do sistema teoricamente ótimas, o que é praticamente inviável. Embora isso seja, por si só, um resultado negativo, é importante saber quais são os limites fundamentais da gestão técnica da dívida. Consideramos isso um resultado fundamental sobre a gestão técnica da dívida em geral e não apenas sobre nossa abordagem específica. Em uma segunda etapa, desenvolvemos aproximações da abordagem que permitiram derivar um método praticamente aplicável e discutimos de que maneira essas aproximações se desviam dos valores reais. Em resumo, isso nos ajudou a derivar uma abordagem de tomada de decisão técnica da dívida que é suficientemente leve para integrá-la até mesmo em abordagens de desenvolvimento ágil com despesas gerais insignificantes. Naturalmente, as aproximações específicas que discutimos são apenas alguns exemplos de possíveis aproximações. Com base na teoria subjacente, diferentes conjuntos de aproximações poderiam ser usados ​​para desenvolver diferentes métodos de decisão. Nesse sentido, os fundamentos teóricos desenvolvidos fornecem a base para toda uma família de métodos de decisão para dívida técnica.

Acreditamos que é uma grande vantagem da nossa abordagem que primeiro desenvolvemos uma base geral, precisa e formal, que depois relaxamos para obter uma abordagem viável em vez de desenvolver diretamente um método aproximado. Ao contrário de outros métodos, isso nos permite identificar claramente todas as suposições feitas na abordagem técnica de gerenciamento da dívida. Estas são, em particular: • Uma restrição ao custo como a única medida do impacto da dívida técnica. • A gestão técnica da dívida deve basear-se numa abordagem de decisão racional, tendo em conta o desenvolvimento futuro (tanto planeado como potencial). • A dívida técnica deve ser caracterizada como uma diferença na evolução entre duas realizações do sistema (com comportamento externo idêntico). • Um sistema livre de dívidas seria um sistema com comportamento de evolução ideal. Embora as suposições acima sejam fundamentais para toda a nossa abordagem, também introduzimos as seguintes aproximações como suposições adicionais para nossa abordagem de decisão. • Podemos estimar custos de reestruturação.4 • Podemos estimar a probabilidade de etapas de evolução. • Podemos, de maneira significativa, determinar uma (melhor) realização alternativa do sistema, de modo que faça sentido substituir a dívida técnica por uma dívida técnica relativa. • As etapas de evolução individual podem ser tratadas como suficientemente independentes. Esta é talvez uma das suposições mais difíceis. No entanto, provavelmente, isso pode ser resolvido frequentemente combinando vários passos pequenos e relacionados em etapas mais grosseiras, mas menos interativas. • É possível se concentrar em um conjunto de etapas de evolução representativas. Isso pode ser feito de maneira simples, concentrando-se apenas nas etapas que fazem parte do product backlog, respectivamente requisitos. O esforço pode ser ainda mais reduzido, concentrando-se apenas nas etapas de evolução com alta probabilidade e alta interação com os itens de dívida técnica. Enquanto essas suposições se mantiverem, acreditamos que nossa abordagem é a maneira mais apropriada de administrar dívidas técnicas. No entanto, do ponto de vista prático, também prevemos alguns problemas que podem surgir na prática.

Na prática, pode ser difícil introduzir o manuseio de um item de dívida técnica em uma iteração planejada (ou até mesmo um sprint com timebox), já que o foco já foi definido nas próximas etapas de evolução. Este é um problema em particular se a introdução de um item de dívida técnica pode levar à queda de uma etapa de evolução planejada devido a restrições de tempo ou esforço. Do ponto de vista prático, uma abordagem como a pista arquitetônica pode ser mais apropriada [1]. No entanto, tal abordagem, que requer reservar algum tempo ao longo do desenvolvimento para lidar com itens de dívida técnica, teria o problema de que a decisão sobre itens de dívida técnica precisaria ser feita várias iterações à frente. Embora nosso modelo possa ser aplicado também a essa situação, a probabilidade de erros aumenta devido à crescente incerteza. Outra questão que pode surgir é que, no início, um item de dívida técnica não é tratado porque a probabilidade de algumas etapas de evolução é estimada como baixa (cf. item 1 do TD na Figura 3). Assim, o maior custo de evolução é tomado para as primeiras etapas de evolução, em vez de abordar o item de dívida técnica. Mais tarde, no entanto, verifica-se que teria sido benéfico abordar imediatamente a dívida técnica. Embora isso seja lamentável, poderíamos argumentar que essa ainda é a abordagem mais racional. Se as estimativas sobre o futuro precisarem ser feitas - e argumentarmos que administrar a dívida técnica requer tais estimativas - tais situações podem ocorrer. Nós vemos potencial para trabalhos futuros interessantes baseados em nossa abordagem. Primeiro de tudo, achamos que pode ser interessante analisar o potencial de outras aproximações. Isto será particularmente relevante no contexto de estudos de caso, onde diferentes aproximações podem ser avaliadas. Esperamos que também possa levar a resultados interessantes, se ampliarmos as métricas além do custo de desenvolvimento para benefício do cliente, custos de treinamento, tempo de colocação no mercado e critérios semelhantes. Embora isso esteja longe de ser trivial, supomos que a abordagem básica que descrevemos aqui também será útil para abordar essas extensões. A estrutura formal subjacente é muito difícil de validar diretamente. Nosso objetivo aqui é uma abordagem (como é típico em outras ciências), onde a validação de modelos é baseada em previsões de modelos (por exemplo, o Teorema 1). Assim, teremos como objetivo extrair propriedades adicionais e analisá-las com base em estudos de casos específicos. A gestão técnica geral da dívida é muito difícil de validar objetivamente, pois seria necessário comparar o desenvolvimento com uma certa abordagem de gestão com a situação sem ela. Planejamos usar o feedback dos desenvolvedores como um proxy para caracterizar os benefícios do gerenciamento técnico da dívida. Em particular, planejamos usar o feedback do desenvolvedor como base para determinar quão fácil ou difícil é fornecer as várias entradas. Esperamos que isso também seja uma prova importante para futuras pesquisas.