{"id":9558,"date":"2019-11-27T14:35:20","date_gmt":"2019-11-27T16:35:20","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=9558"},"modified":"2019-12-19T16:38:44","modified_gmt":"2019-12-19T18:38:44","slug":"divida-tecnica-por-que-fazer-quando-fazer-e-como-priorizar","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2019\/11\/divida-tecnica-por-que-fazer-quando-fazer-e-como-priorizar\/","title":{"rendered":"D\u00edvida t\u00e9cnica: Por que fazer, quando fazer e como priorizar"},"content":{"rendered":"\n
O primeiro passo \u00e9 admitir: existe d\u00edvida t\u00e9cnica no seu sistema. Seja por decis\u00f5es estrat\u00e9gicas para acelerar um lan\u00e7amento e ganhar mercado, seja por mudan\u00e7as tecnol\u00f3gicas ou novas pr\u00e1ticas que pedem que c\u00f3digo antigo seja revisitado.<\/p>\n\n\n\n
Em praticamente todas as empresas que j\u00e1 trabalhei, existia (e imagino que ainda exista) algum tipo de d\u00edvida t\u00e9cnica. Em algumas, para n\u00e3o falar todas, presenciei o cabo-de-guerra entre a equipe t\u00e9cnica, desejando tratar esses itens e defendendo o porque s\u00e3o importantes, e os respons\u00e1veis pelo produto, promovendo a cria\u00e7\u00e3o de novas features.<\/p>\n\n\n\n
Neste post eu vou te dar pelo menos um bom motivo para pagar d\u00edvidas t\u00e9cnicas, deixar uma dica de quando faz\u00ea-las e uma sugest\u00e3o de como prioriz\u00e1-las.<\/p>\n\n\n\n
Porque fazer<\/h2>\n\n\n\n
Facilidade de manuten\u00e7\u00e3o, ganho de performance, compatibilidade com novas tecnologias, diminuir o tempo que o time gasta lidando com os sintomas dessa d\u00edvida t\u00e9cnica (e claro, o tempo que seu time passa lidando com esses sintomas, ele est\u00e1 perdendo de fazer novas features, que melhorariam seu time-to-market)\u2026 Existem v\u00e1rios \u00f3timos motivos pra investir esfor\u00e7o e resolver a causa ra\u00edz, mas eu vou falar s\u00f3 de um.<\/p>\n\n\n\n
Quando todos argumentos se esgotarem e ainda assim ficar a impress\u00e3o de que \u201cisso \u00e9 capricho de desenvolvedor\u201d, ainda vale a pena. Por qu\u00ea? Pela satisfa\u00e7\u00e3o dos seus funcion\u00e1rios.<\/p>\n\n\n\n
Qualquer empregador vai falar que achar m\u00e3o de obra especializada \u00e9 dif\u00edcil. Ser\u00e1 que n\u00e3o vale incluir um item no seu backlog pra manter um bom empregado? Voc\u00ea ralou para achar um especialista, e agora que o encontrou, negligenciar a opini\u00e3o dele pode gerar insatisfa\u00e7\u00e3o.<\/p>\n\n\n\n
Recentemente conversei com um gerente de produto de uma startup, e ele disse que uma das perguntas da entrevista que passou era: \u201cse um desenvolvedor amea\u00e7ar sair caso um item X n\u00e3o seja desenvolvido, o que voc\u00ea faz?\u201d Segundo ele, v\u00e1rias respostas estariam certas na linha de entender esse item X, mas existe uma resposta errada: \u201c\u00e9 s\u00f3 um desenvolvedor, eu deixo sair\u201d<\/strong>.<\/p>\n\n\n\n
Talvez voc\u00ea n\u00e3o seja surpreendido com um funcion\u00e1rio falando isso explicitamente, mas ligue seu radar se a equipe reclamar muito de d\u00edvida t\u00e9cnica. \u00c0s vezes isso j\u00e1 \u00e9 um indicativo da infelicidade desses profissionais e curr\u00edculos podem j\u00e1 estar sendo disparados para outras empresas.<\/p>\n\n\n\n
Quando fazer<\/h2>\n\n\n\n
Se voc\u00ea leu a se\u00e7\u00e3o acima e ficou convencido, ou j\u00e1 come\u00e7ou o texto com a inten\u00e7\u00e3o de lidar com d\u00edvida t\u00e9cnica, a partir daqui eu posso te ajudar.<\/p>\n\n\n\n
Aceitar que vamos trabalhar com d\u00edvida t\u00e9cnica n\u00e3o significa que vamos parar tudo e ficar semanas focados nesses itens.<\/p>\n\n\n\n
Importante: estou considerando aqui que os \u201cjuros\u201d dessa d\u00edvida t\u00e9cnica estejam sob controle. Se n\u00e3o estamos fazendo nada da d\u00edvida e seria apenas uma melhoria para o processo, essa sugest\u00e3o se aplica. Agora, se voc\u00ea tem um inc\u00eandio, talvez voc\u00ea precise de um plano de a\u00e7\u00e3o mais agressivo, incluindo talvez parar e trabalhar apenas na d\u00edvida t\u00e9cnica.<\/p><\/blockquote>\n\n\n\n
No universo do Scrum, o termo \u201chardening sprint\u201d \u00e9 usado para designar uma sprint inteira dedicada a consertar bugs e resolver d\u00edvidas t\u00e9cnicas. Deixo claro que por mais que o termo seja usado, o Scrum desaconselha totalmente essa pr\u00e1tica, sugerindo por exemplo, considerar uma parte do esfor\u00e7o da sprint para tratar esses itens.<\/p>\n\n\n\n
Recentemente estive com um time que tinha uma quantidade consider\u00e1vel de d\u00edvida t\u00e9cnica e, por alguns meses, at\u00e9 se dedicaram a trabalhar apenas nelas. Foi um per\u00edodo de insatisfa\u00e7\u00e3o tanto das pessoas desenvolvedoras, quanto das pessoas de produto. Com o tempo, eles voltaram ao desenvolvimento de features, e o backlog de d\u00edvida t\u00e9cnica ficou parado, onerando capacity do time com pequenas demandas originadas das mesmas. Eles n\u00e3o trabalhavam com Scrum, nem nenhuma outra metodologia\/framework. Existia, por\u00e9m, um quadro tipo<\/strong> kanban (k min\u00fasculo aqui).<\/p>\n\n\n\n
A solu\u00e7\u00e3o ent\u00e3o para garantir que d\u00edvida t\u00e9cnica seria endere\u00e7ada sem paralisar totalmente a entrega de features foi usar limites de WIP (Work in Progress).<\/p>\n\n\n\n
O time n\u00e3o utilizava Kanban, nem limites de WIP (e nem era algo para se implantar no momento), mas chegamos num combinado: Em qualquer dado momento, existir\u00e1 um item de d\u00edvida t\u00e9cnica no quadro do time, sendo trabalhado.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Essa estrutura garantiu que existia um espa\u00e7o para trabalhar em resolver d\u00edvida t\u00e9cnica, e tranquilizou stakeholders no sentido de mostrar que n\u00e3o ir\u00edamos \u201cparar tudo\u201d para trabalhar nesses itens.<\/p>\n\n\n\n
Dependendo do tamanho do seu time e da sua necessidade, esse limite de WIP pode ser diferente de 1.<\/p>\n\n\n\n
<\/figure>\n\n\n\n
![\"\"\/](\"https:\/\/i.imgur.com\/0aseY9m.png\")
<\/figure>\n\n\n\n![\"\"\/](\"https:\/\/i.imgur.com\/YhE46Kf.png\")
<\/figure>\n\n\n\n