Технічний борг: звідки виникає, чим загрожує, якого управління потребує

Всім привіт! Мене звати Андрій Троянов, я Delivery Manager у компанії Innovecs. У цій статті я поділюсь набутим досвідом роботи із технічним боргом, підходами до його швидкого повернення, мінімізації на попередніх та поточних проєктах.

Незважаючи на весь існуючий об’єм матеріалу на цю тему, вона досі є актуальною. Сподіваюсь, що мої знання будуть корисні інженерам, керівникам проєктів, власникам продуктів, тестувальникам та іншим зацікавленим особам. Я розбавлю теорію практичними прикладами, і звісно ж, буду радий дискусії у коментарях.

Що таке технічний борг і чому він виникає?

Технічний борг виникає, коли команда розробки змушена прискорити процес постачання продукту чи оновлення, відкладаючи рефакторинг на майбутнє (зазвичай невідоме). Згідно з теорією Стіва МакКоннелла (Steve McConnell) — відомого автора книжок «Завершений код», «Швидка розробка» тощо — зазвичай існує дві глобальні причини виникнення технічного боргу.

1. Навмисний технічний борг. У гонитві за зменшенням time-to-market та цілями бізнесу по колонізації ринку команди розробляють продукт у шалених темпах, відкладаючи базові інженерні покращення на потім та фокусуючись виключно на швидкості постачання (release to web/production). При цьому команди жертвують якістю: вартість забезпечення якості суттєво зростає під час внутрішніх та зовнішніх доробок, ніж на початку циклу, коли вона включена в процес розробки та на неї виокремлюється час, зусилля та кошти.
2. Ненавмисний технічний борг. Трапляється, що код вимагає покращення через певний проміжок часу, а команди дізнаються про це із власного гіркого досвіду — коли продукт після виходу в світ отримує негативний зворотний відгук від користувачів. У результаті RCA (аналізу першопричин) команди виявляють, що або залежності у модулях були погано прорефакторені, або сам код продукту застарів і потребує масштабного оновлення.

Незважаючи на зрозумілу бінарність розподілу, сучасна індустрія виокремлює 13 видів технічного боргу. Серед них борг по якості коду продукту займає рівнозначне місце серед інших. Про це більш поглиблено я розкажу у наступній статті.

Які бувають технічні борги?

Мартін Фаулер (Martin Fowler) — один із авторів Manifesto for Agile Software Development — допрацював теорію згаданого вище Стіва МакКоннелла, додавши до дихотомії «навмисний/ненавмисний» ще одну ознаку. Вона розподілена за принципом «розсудливий/необачний» у контексті визначення технічного боргу. Відповідно вимальовується матриця із 4 квадрантів, що відображають види технічного боргу:

• Необачний/навмисний.
• Необачний/ненавмисний.
• Розсудливий/навмисний.
• Розсудливий/ненавмисний.

Як ми вже з’ясували, різниця між навмисним та ненавмисним боргом полягає у зворотному підході до роботи та ступені обачності команди, коли база коду потребує відлагодження. Різниця між розсудливим та необачним базується на:

• повному усвідомленні командами факту накопичення боргу: «Ми знаємо, що ми пожертвували рефакторингом у цій ітерації/задачі/фічі та маємо його виплатити якомога швидше»;
• неусвідомленні: «Ми накопичили борг? Ми не рефакторили код достатньо? А у нас в DoD (definition of done) закладений рефакторинг взагалі?».

Тобто при розсудливому ухваленні рішення технічний борг починає накопичуватись через низку причин. Проте команда та бізнес цілком свідомо відкривають «позику», знижуючи якість і підвищуючи криву витрат під завершення проєкту. У разі необачного накопичення, поява технічного боргу зумовлена банальною втратою пильності команди, відсутністю частого перегляду DoD, або сильним штормінгом у середні команди. Ця стадія командного розвитку характеризується великою кількістю конфліктів, які можуть переходити у персональні протистояння замість конструктиву та нормальної взаємодії.

У будь-якому разі кожна команда зіштовхнеться із наявністю певного технічного боргу у продукті. Нерентабельно займатися виключно інженерією в ім’я надлишкової якості продукту, не даючи цінності ні бізнесу, ні користувачам. Головна різниця виявиться в обсязі технічного боргу. Одні будуть потрапляти в узгоджений відсоток, визначений в метриках якості. Інші будуть вимушені займатись дуже частим «прибиранням» — доопрацюванням та погашенням накопиченого відсотка до загальноприйнятих стандартів якості.

Підходи до управління технічним боргом

Стратегії роботи із технічним боргом залежать від обраного процесу управління проєктом та умовами контракту між замовником і виконавцем у аутсорсингу. У гнучких фреймворках і методологіях, зокрема у Скрам, управління технічним боргом відбувається прозоро із залученням достатньої кількості зацікавлених осіб із різним ступенем відповідальності за робочий продукт. До команди розробки залучаються й інші зацікавленні особи залежно від організаційної структури — наприклад, спонсор проєкту, власник бізнесу, тощо. На моїх попередніх проєктах, де я використовував Scrum/SAFe, були задіяні наступні підходи до управлінням боргом:

1. Пріоритезувати технічний борг прозоро на зустрічах з «причісування беклогу» (Refinement or Grooming) із власником продукту, брати в роботу в кожну ітерацію (відсоток варіювався у розмірі 10-20% в залежності від мети ітерації або її наближення до релізу).
2. Закладати рефакторинг окремим пунктом в DoD (критерії готовності продукту, погодження його продукту та командою розробки). Часто регулювати DoD — в основному ми переглядали та корегували раз у 2-3 місяці перед новим (program increment).
3. Відслідковувати відсоток технічного боргу у беклогу продукту у порівнянні із задачами та ризиками; стандартизувати розподіл кількості таких задач у пропорції із ризиками за ітераціями.
4. У кожен program increment (PI) брати архітектурні та інфраструктурні енейблери в достатній кількості, забезпечуючи стабільність продукту.
5. Постійно пояснювати ризики, пов’язані із недостатнім плануванням, роботою над нефункціональними вимогами рішення у грошовому еквіваленті до початку та під час розробки проєкту (коли власник продукту подає попередні total cost of ownership на розгляд спонсору проєкту).
6. Застосовувати метрики відслідковування накопичення технічного боргу та регулярно переглядати їх щодня, перед ревізією беклога та протягом ретроспективи. Наприклад: кількість виявлених дефектів на N рядків коду, глибина наслідування, цілісність коду, колективне володіння базою коду (collective code ownership) тощо.
7. Закладати рефакторинг в оцінку (абсолютну чи відносну) під час кожного планування (release planning, PI planning, iteration planning, replenishment — у разі можливості).
8. Збирати та ділитись набутими знаннями та практиками управління технічним боргом мінімум раз у IP (Innovation and Planning). Зазвичай це кожна п’ята ітерація інновацій та планування у SAFe.

Якщо існують певні контрактні зобов’язання, або проєкт постачається за більш жорсткими методологіями, я запропонував би наступні дії:

• Прописувати рефакторинг у RFP (request for proposal) у відповідь на запит замовника у SoW (statement of work).
• Детально описувати нефункціональні вимоги у документах за вимогами.
• Стандартизувати процедури у плані управління якістю проєкту/продукту.
• Визначити допустиму похибку технічного боргу у метриках якості.
• Закладати рефакторинг у прорахунок вартості якості продукту (cost of quality).
• Підтримувати актуальність технічної документації.

Поділюсь декількома практичними прикладами роботи із технічним боргом на минулих проєктах. На одному із них ми працювали у кооперації із декількома вендорами, і весь бекенд був написаний на coffeescript. Протягом приблизно півроку ми пропонували «декофеїнізацію»: активно переконували CTO та архітектора з боку замовника, щоб почати рух у сторону конвертації коду на JavaScript, попередньо заручившись підтримкою інших команд.

Ми пробували аргументувати по-різному, багато мітингували, малювали схеми, працювали із запереченнями і відмовами ключових зацікавлених осіб. Зрештою ми все ж таки переконали технічне керівництво замовників та навіть декількох зацікавлених бізнес-осіб у користі конвертації, яка суттєво зменшує витрати на розвиток і підтримку продукту. І ми отримали зелене світло! Декофеїнізація всього беку зайняла приблизно чотири місяці роботи нашої команди і дуже мотивувала її учасників протягом цього часу. Більш того — коли команди та власники продукту з боку замовника пішли у місячну відпустку після успішного релізу, декофеїнізація була єдиним завданням нашої команди на два спринта.

На іншому проєкті ми одразу домовились, що кожен восьмий день спринта ми виокремлювали на рефакторинг коду, в той час як тестувальники тестили сценарії регресії білда для тестування прийомки оновлень продукту користувачами (UAT). Ще два дні залишалися для виправлення дефектів і підготовки до рев’ю спринта. Ми це погодили на рівні CTO/CDO (Chief Delivery Officer). І цей підхід був відображений у негласних згодах команд.

Як технічний борг впливає на розвиток проєктів, і які наслідки його ігнорування?

Аналогічно із заборгованістю з регулярних платежів накопичення технічного боргу та його вчасне непогашення неухильно призводять до погіршення якості продукту, послуги або загального результату.

У гонитві за благою метою — швидким поверненням інвестицій (ROI) — бізнес, забуваючи про технічну частину проєкту, закриваючи вуха від аргументів інженерів, підкладає сам собі бомбу сповільненої дії. Я маю на увазі витрати на підтримку, що зростатимуть ближче під завершення й різко підскочуть при передачі продукту у операційну діяльність та підтримку. Продукт стане настільки невиправдано дорогим для подальшого розвитку, що переписати його із нуля буде дешевше.

Із подальшої еволюції — наприклад, запуску одного чи декількох суміжних проєктів — інвестиції, витрачені на перезапуск, будуть безглуздими. Постійне погіршення одного із ключових обмежень проєкту — а це, власне, якість — призведе до автоматичного впливу на інші обмеження: графік, ризики, ресурси, витрати та зміст. Це нівелюватиме здобуті результати в кожній області.

Коли борг стає деструктивним елементом системи, він розкладає її зсередини, призводячи до неминучої ентропії. Проблеми накопичуються, як снігова лавина, а несвоєчасне виправлення може зовсім не допомогти.

Цього всього можна уникнути, якщо налагодити своєчасний план комунікацій та управління технічним боргом, особливо у контексті практик гнучких постачань продукту — старий, добрий Agile. І дійсно — майже всі фреймворки, такі як Scrum, SAFe, RAD, XP, FDD, DSDM, частково Kanban та Lean та їх гібриди — ScrumBan, Scrum+XP, тощо — за своєю суттю спрямовані на:

• щоденну взаємодію між технічними командами та бізнес-людьми;
• спрощення комунікації;
• можливість погоджувати комплексні питання прозоро, швидко та різнобічно.

Незважаючи на те, що часті зміни вимог прямо пропорційно впливають на появу технічного боргу, більшість Agile-фреймворків збалансовано адаптовані до швидкої відповіді і мінімізації як ризиків, так і технічних перешкод.

Налагоджена комунікація між командами та зацікавленими особами побудована на принципах прозорості і довіри: чесні оцінки, зрозумілий DoD, своєчасно озвучені ризики, публічно визнанні помилки з обох боків. Це все створює необхідне соціальне середовище для відкритого діалогу, який, у свою чергу, гарантує взаєморозуміння та вирівнювання беклогу згідно із поточними пріоритетами.

Висновки

Нижче підсумую ключові рекомендації з управління технічним боргом:

• Визначайте стратегію управління технічним боргом заздалегідь.
• Погодьте цю стратегію із ключовими учасниками проєкту.
• Відкрито адресуйте питання наявності технічного боргу на загальних зустрічах (ревʼю-ітерації, ретроспектива, планування ітерації, планування PI), або через проксі (скрам-майстер, власник продукту) тощо.
• Пріорітезуйте борг-задачі разом із «фічами» та ризиками в процесі «причісування» беклогу продукту.
• Закладайте рефакторинг в оцінки виконання задач, сторіз, оновлень.
• Проговорюйте практики роботи із технічним боргом на ретроспективі та беріть визначенні дії (action items) в кожну наступну ітерацію.
• Постійно відслідковуйте тренди метрик якості, щоб своєчасно визначити та зменшити вплив боргу на продукт.
• Зробіть свій DoD для всіх учасників проєкту прозорим (wiki-сторінка або фізична роздруківка на дошці команди) та регулярно оновлюйте його.

Я щиро сподіваюсь, що ця стаття додала до вашого арсеналу роботи із технічним боргом нових інструментів, які ви зможете використовувати надалі. Або тепер у вас є хоча б інформація для роздумів. А може бути і так, що виникли додаткові питання або бажання висловити іншу точку зору. В будь-якому разі з радістю запрошую вас до розмови у коментарях.