​​Как совмещать Бизнесовые фичи и Развитие инженерки

Вот мы зафиксировали нижний порог уровня качества выпускаемых фич с помощью Definition of Done.
Не факт, что этот нижний порог — высокий. Скорее всего, тут и там в процессах разработки есть несовершенство и техдолг. Это несовершенство нас тормозит и делает продукт менее качественным.

Например, мы не могли включить в DoD пункт про Unit тесты, пока не было однозначных договоренностей в виде Unit Tests Best Practices. Без них этот пункт не принёс бы ценности: его было бы легко нарушить, или отмазаться, написав один незначительный тест.

Отсутствие Best Practices дает свободу вкусовщине, что может привести к срачам на ревью и разножопице в реализации компонентов. При совместном владении кодом это негативно влияет на Time2Market и на стабильность и поддериживаемость систем в целом.

Как бы так сделать, чтобы команда могла вынырнуть из потока бизнесовых фич, подтянуть инженерные практики и процессы, доработать инструменты для самих разработчиков, улучшить CI/CD, расплатиться с техдолгом?
При чем не однократно, типа субботника, а сделать это непрерывным процессом.

У нас такая проблема была и для её решения мы собрали непрерывный процесс развития разработки.

Раньше я писал про Dual Track Development, когда задачи прорабатываются меньшими циклами разной длины параллельно запилу конкретной фичи в спринте.

С учётом процесса развития разработки у нас получается Tripple Track Development:

1️⃣ — Проработка задач из бэклога
2️⃣ — Разработка фичи в спринте
3️⃣ — Развитие инженерных практик и процессов

В следующем посте подробно опишу этот третий трек и какие результаты он приносит.