Техническият дълг в Scrum екипа
Научете как техническият дълг влияе на Scrum екипите, защо практиката на hardening sprints се проваля и как да използвате Definition of Done, за да поддържате кода чист и лесен за поддръжка.
Техническият дълг не е счетоводен трик. Той представлява натрупаното забавяне, породено от преки пътища, липсващи автоматизирани тестове, остарели библиотеки и крехка архитектура. Когато екипите го пренебрегват, всяка бъдеща промяна струва двойно по-скъпо и отнема три пъти повече време. В Scrum техническият дълг често се третира като външно атмосферно явление, нещо, което сполетява екипа отвън. В действителност техническият дълг се създава директно вътре в самия Sprint. Ръководството Scrum Guide вменява на Developers пълната отговорност за налагането на качество чрез придържане към Definition of Done. Ако дългът ви залива, значи вашата Definition of Done не работи.
Definition of Done като таван на дълга
Definition of Done е официален ангажимент, гарантиращ, че всеки Increment покрива необходимите критерии за качество на продукта. Когато даден елемент отговаря на този стандарт, дългът не може да проникне в продукционна среда. Когато екипите занижават изискванията на Definition of Done, само за да обявят целта Sprint Goal за постигната, те вземат кредит при заробващи лихви.
Една стабилна Definition of Done описва ясно какво задължително трябва да се изпълни, преди кодът да се приеме за завършен. Ако дадена потребителска история бъде отбелязана като готова без интеграционни тестове или проверки за сигурност, вие не сте приключили по-рано. Просто сте прехвърлили неплатения труд за следващия месец. С течение на времето тези отложени задачи създават скрито триене, което забавя скоростта на следващите Sprint цикли. Строгата Definition of Done действа като бариера, която спира нискокачествената работа да стане приета норма.
Как екипите създават технически дълг
Дългът не възниква случайно. Екипите правят конкретни компромиси по време на Sprint, подлъгани от илюзията за бързина. Ето най-честите начини, по които Scrum екипите натрупват дълг:
- Прескачане на компонентните и автоматизираните интеграционни тестове с цел предаване на елемент от Backlog преди края на Sprint.
- Запазване на остарели схеми в базата данни и писане на сложни транслиращи слоеве вместо провеждане на миграции.
- Игнориране на предупреждения от компилатора, остарели методи и неактуализирани зависимости, докато обновяването им не прерасне в опасен проект.
- Твърдо кодиране на бизнес логика или конфигурационни параметри, само за да се покрие бързо един-единствен критерий за приемане.
Защо отделните refactoring sprints се провалят
Когато дългът стане непоносим, екипите често искат hardening sprint или refactoring sprint. Това е антимодел. В Scrum Guide не съществуват итерации за почистване. Всеки Sprint трябва да завършва с ценен, използваем Increment. Период от две седмици, в който разработчиците не пишат никаква нова функционалност и не създават видима стойност за клиента, се аргументира изключително трудно пред заинтересованите страни. Освен това този подход учи екипа, че може да пише хаотичен код по време на обичайните Sprint цикли, разчитайки, че фазата за почистване ще ги спаси накрая.
Вместо да отделяте цели периоди за разчистване, борете се с дълга поетапно. Прилагайте скаутското правило, оставяйте кода по-чист, отколкото сте го заварили. Всеки път, когато променяте даден модул за нова функционалност, преструктурирайте съседния код, добавяйте липсващите тестове и актуализирайте интерфейсите. Така връщането на дълга става естествена част от нормалното продуктово развитие, без да искате специално позволение за прозорци за поддръжка.
Визуализиране на дълга в Product Backlog
Част от дълга е твърде голям, за да бъде отстранен с дребни подобрения в рамките на една потребителска история. Мигрирането към нова версия на основна работна рамка или смяната на система за автентикация изискват целенасочено планиране. Тези по-мащабни технически инициативи трябва да намерят място директно в Product Backlog, редом с функционалностите за потребителите.
Разработчиците трябва да си партнират с Product Owner, за да представят тази работа през призмата на ползите за бизнеса. Ако кажете на един Product Owner, че искате да пренапишете дадена услуга, той може да откаже. Ако обаче обясните, че текущата услуга за разплащания генерира по десет потребителски грешки на ден и пречи на екипа да свърже нови системи за плащане, инвестицията придобива смисъл. В крайна сметка техническият дълг е тежест за продукта и справянето с него изисква пълна прозрачност.