Relação do pagamento de dívidas técnicas com os efeitos de intens de dívida em projeto

Jetzt loslegen. Gratis!
oder registrieren mit Ihrer E-Mail-Adresse
Relação do pagamento de dívidas técnicas com os efeitos de intens de dívida em projeto von Mind Map: Relação do pagamento de dívidas técnicas com os efeitos de intens de dívida em projeto

1. Divida Técnica (DT)

1.1. São tarefas pendendtes que a curto prazo trazem ganhos, mas podem prejudicar o longo prazo de um software

1.2. Identificar e conhecer o seu impacto é essencial para que o time de desenvolvimento possa priorizar os itens que estão em dívida

1.3. Os efeitos mais comumns da DT pelo ponto de vista dos profissionais DT são:

1.3.1. Atraso na entrega

1.3.2. Baixa manutenção do software

1.3.3. Retrabalho

1.3.4. Prejuízo financeiro

1.3.5. Equipe desmotivada

1.3.6. Stakeholders insatisfeitos

1.3.7. Documentação pobre

1.3.8. Código ilegível e com baixo desempenho

1.4. Quais são as práticas mais comuns para pagar a DT?

1.4.1. Refatoração de códigos

1.4.2. Correção de bugs e falhas

1.4.3. Redesenho e reescrita de código

1.4.3.1. Uma das mais utilizadas por Startups

1.4.4. Processo de reengenharia

1.5. Quais são os motivos de não pagar a DT?

1.5.1. Foco em metas de curto praze

1.5.2. Alto custo

1.5.3. Complexidade da DT

1.5.4. Falta de interesse por parte da empresa organizacional

2. Método de Pesquisa

2.1. Questões

2.1.1. RQ1: Quais são os principais efeitos de DT sentidos pelos profissionais de software em seus projetos?

2.1.2. RQ2: Quais são as principais práticas de pagamento usadas pelos praticantes de software quando eles sentem os efeitos do DT em seus projetos?

2.1.3. RQ3: Quais são as principais razões consideradas pelos praticantes de software para justificar o não pagamento de DT quando enfrentam efeitos de DT em seus projetos?

2.2. Coleta de Dados

2.2.1. Q1: Qual é o tamanho da sua empresa?

2.2.2. Q2: Em que país você está trabalhando atualmente?

2.2.3. Q3: Qual é o tamanho do sistema que está sendo desenvolvido nesse projeto?

2.2.4. Q4: Qual é o número total de pessoas deste projeto?

2.2.5. Q5: Qual é a idade deste sistema até agora?

2.2.6. Q6: Para qual função do projeto você está atribuído neste projeto?

2.2.7. Q7: Como você avalia sua experiência nesta função?

2.2.8. Q8: Qual das opções a seguir descreve mais de perto o modelo de processo de desenvolvimento fechado que você segue neste projeto?

2.2.9. Q13: Dê um exemplo de DT que teve um impacto significativo no projeto que você escolheu para nos contar:

2.2.10. Q20: Considerando o item DT que você descreveu na questão 13, quais foram os impactos sentidos no projeto?

2.2.11. Q26: O item da dívida foi quitado (eliminado) do projeto?

2.2.12. Q27: Se sim, como? Se não, por quê?

2.3. Análise de Dados

2.3.1. Para questões fechadas, usou-se estatística descritiva

2.3.2. Para perguntas abertas, aplicou-se técnicas de análise de dados qualitativos

3. Resultados da Pesquisa

3.1. Demografias

3.1.1. Os participantes em sua maioria trabalhavam em empresas de médio porte, que utilizavam o modelo de processo híbrido em equipes de 5 a 9 pessoas

3.1.2. Os participantes em sua maioria eram desenvolvedores que acreditavam possuir alto nível de experiência

3.1.3. Os sistemas referidos possuiam idades entre 2 e 5 anos e possuiam tamanho entre 10 KLOC e 1 milhão de LOC

3.2. Efeitos sentidos da DT

3.2.1. Atraso na entrega

3.2.2. Baixa manutenibilidade

3.2.3. Retrabalho

3.2.4. Baixa qualidade

3.2.5. Custo aumentado