Upload
tdc-globalcode
View
324
Download
1
Embed Size (px)
Citation preview
Dívida Técnica
(Technical Debt)
Artefatos imaturos,
incompletos ou
inadequados no ciclo de
desenvolvimento de
software que causam
custos altos e baixa
qualidade.
(SEAMAN e GUO, 2011)
• Dívida Técnica NÃO é somente código e a sua
qualidade. (KRUCHTEN et al., 2012)
• Dívida Técnica pode ser caracterizada por aspectos
relacionados com o desenvolvimento do software
como um todo (KRUCHTEN et al., 2012) :
• Falta de testes automatizados; (STERLING, 2010)
• Documentação desatualizada. (BROWN et al., 2010)
“O único que pode mudar este código é o Fredy!”
“Vamos terminar os testes no próximo Sprint!”
“Nós não temos tempo para atualizar essas duas bases de
dados, por isso, vamos sincronizá-las depois”.
• Dívida Técnica x Métodos Ágeis
• Entregas muito rápidas, o poucotempo para projeto ou a falta de rigorem testes automatizados, levamalguns software a um nível considerávelde Dívida Técnica.
(KRUCHTEN et al., 2012)
• Definir uma estratégia para reduzir a Dívida
Técnica é difícil, pois é algo que NÃO é parte do
processo de desenvolvimento regular, que se
concentra na implementação das funcionalidades.
(BUCH, 2011)
• Dívida Técnica x Scrum
• Falta da definição do papel responsável pela suaredução (Time, Dono do Produto, Scrum Master ou todoseles);
• Dono do Produto frequentemente não entende asnecessidades e benefícios de reduzir a Dívida Técnica;
• Dívida Técnica encontrada nos projetos não se encontrade uma forma estruturada e documentada, que possaser visualizada pelo time.
(BUCH, 2011)
Motivation
• Carolyn Seaman e Yuepu Guo propõem um framework
de gerenciamento da Dívida Técnica.
Fonte: Adaptado de Umbc (2014)
• Lista de DT: atividades não realizadas de forma correta e
que correm o risco de causarem problemas futuros se não
forem concluídas. (SEAMAN e GUO, 2011)
Fonte: Adaptado de Seaman e Guo. (2011) e Oliveira (2011)
Monitoramento da Dívida Técnica ao longo do tempo
Fonte: Adaptado de Seaman e Guo (2011)
Principal Juros
Avaliar a aplicação dos três estágios do framework de gerenciamento da Dívida
Técnica proposto por Seaman e Guo (2011), por meio de uma pesquisa-ação, no contexto
real de dois projetos de software que utilizam Scrum.
• Pesquisa-Ação (DICK, 1993) , (KOCK et. al, 1997), (THIOLLENT, 2011), (O´BRIEN, 1998)
• Pesquisadores e participantes estão envolvidos de modo
cooperativo;
• Problemas reais.
• 4 ciclos
• Identificação;
• Medição;
• Tomada de Decisão;
• Adaptação do framework.
• Seminários
Fonte: Adaptado de Susman (1983)
• SoftOne: Vtiger e Trello
• SoftTwo: Jira
• Diagnosticar
• Primeira dificuldade: três medidas de natureza
probabilística. Não há valor real dos juros acumulados
de uma dívida no projeto.
• Segunda dificuldade: as ferramentas usadas não são
capazes de criar gráficos para comparações entre os
Juros e o Principal.
Agimos na 1ª dificuldade
• Planejamento das Ações e Agir
• Reduzir de 3 para 2 medidas: Principal e Valor
Acumulado dos Juros (VAJ), sendo que o último é:
VAJ = VAJ + novo esforço extra
• Campos a serem preenchidos na identificação e
medição:
Tomada de Decisão (5 passos ficaram 4):
• Passo 3: para cada item do Passo 1, comparar o custo(Principal) com o benefício (Valor dos Juros) econsiderar aqueles que o valor do benefício é MAIORque o custo.
• Passo 4: Repetir o passo 3 até que não seja maispossível o pagamento da dívida no ciclo.
• Passo 1: extrair os itens da Dívida Técnica associadosaos componentes que estarão sendo feitos no ciclo.
• Passo 2: reavaliar o Principal com base no plano dopróximo ciclo.
• Avaliação e Aprendizagem
• 5 novas dívidas foram criadas.
• Tempo médio gasto no preenchimento dos campos de
identificação e medição: 6 minutos.
• Avaliação e Aprendizagem
Você é a favor ou contra com a continuidade do framework adaptado no projeto?
84% SIM
16% NÃO
• Apesar da condução de 3 ciclos da pesquisa-ação
considerando o framework original e 1 ciclo para as
adaptações, este estudo ainda não é conclusivo.
• Novos ciclos referentes à nova abordagem devem ser
conduzidos nos projetos escolhidos para este estudo para
validar realmente as mudanças no framework.
• O framework de Seaman e Guo (2011) é um primeiro e
importante passo, porém com as adaptações realizadas é
mais aceito pelos participantes da pesquisa.