Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Gerenciamento da Dívida Técnica em Projetos de Software Utilizando Scrum: uma Pesquisa-Ação (Formato eventos Brasil)

Gerenciamento da Dívida Técnica em Projetos de Software Utilizando Scrum: uma Pesquisa-Ação (Formato eventos Brasil)

Apresentação sobre Dívida Técnica resultado do projeto de mestrado.

Frederico Oliveira

March 01, 2016
Tweet

More Decks by Frederico Oliveira

Other Decks in Technology

Transcript

  1. 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)
  2. • 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”.
  3. • Dívida Técnica x Métodos Ágeis • Entregas muito rápidas,

    o pouco tempo para projeto ou a falta de rigor em testes automatizados, levam alguns software a um nível considerável de 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)
  4. • Dívida Técnica x Scrum • Falta da definição do

    papel responsável pela sua redução (Time, Dono do Produto, Scrum Master ou todos eles); • Dono do Produto frequentemente não entende as necessidades e benefícios de reduzir a Dívida Técnica; • Dívida Técnica encontrada nos projetos não se encontra de uma forma estruturada e documentada, que possa ser visualizada pelo time. (BUCH, 2011)
  5. • 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)
  6. 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.
  7. • 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)
  8. • 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
  9. • 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:
  10. 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) e considerar aqueles que o valor do benefício é MAIOR que o custo. • Passo 4: Repetir o passo 3 até que não seja mais possível o pagamento da dívida no ciclo. • Passo 1: extrair os itens da Dívida Técnica associados aos componentes que estarão sendo feitos no ciclo. • Passo 2: reavaliar o Principal com base no plano do próximo ciclo.
  11. • 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.
  12. • Avaliação e Aprendizagem Você é a favor ou contra

    com a continuidade do framework adaptado no projeto? 84% SIM 16% NÃO
  13. • 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.