Яйцерезка, радиаторы и холодильники

Часто в среде Agile-практиков таск-трекеры называют “информационными холодильниками”, а плакаты и наглядную визуализацию важной для команды информации - “информационными радиаторами”. Не стоит закрывать сразу эту статью, далее про Agile не будет ни слова;)

Я работал с многими таск-трекерам: Jira, Trello, Mantis, Redmine, и многими менее известными от HP и других компаний. И даже написал свой за неимением лучшего на тот момент. Застал версию Jira, когда текущий базовый функционал в виде “Scrum”/”Kanban” -досок был в виде отдельного плагина.

Надеюсь, мой опыт и видение на использование таск-трекеров в командах разработки будет полезно, постараюсь объяснить их назначение через паттерны проектирования. Удачного чтения!)

Мне понравилось описание на сайте senior.ua, привожу его:

Читая этот текст, мне на ум пришла...

В конце 0-вых годов, когда я начинал свою карьеру в сфере разработки ПО, был очень популярен стиль интеграции корпоративных систем - Общая База Данных (англ. Shared Database). В центре была большая База Данных, которая хранила в себе большой объём информации, часто слабосвязанной друг с другом, т.е. в одной схеме могли быть данные по транзакциям, клиентам, пароли к личному кабинету и прочее.

Бизнес-логика, как правило, тоже была на стороне БД. Она была представлена в виде функций и хранимых процедур, т.е. не важно из какого канал пришёл запрос: сотрудник сделал ли это из “толстого” настольного приложения или клиент через web-сайт, в конце цепочки манипуляции данными всегда вызывались одни и те же процедуры.

С одной стороны такая универсальность позволяла править логику и создавать фичи прям в проде без CI/CD и инженерных практик. Поправил процедурку и готово!) Но опытному читателю уже становиться понятно, к чему это привело… Процедуры пухли, т.к. каждый добавлял в них свои “if else” согласно новым требованиями, не особое вникая в уже описанную логику. Работает же, не трогай!

Я был свидетелем процедуры на 6000 строк, это было незабываемо;) Очевидно, что такой подход плохо масштабируется в части нагрузки, не способствует параллельной разработке в нескольких командах, поэтому многие компания стали к середине 10-ых от него отказываться в пользу других стилей, например тех же микросервисов.

Роберт “Дядя Боб” Мартин утверждает в Чистой Архитектуре, что База Данных - это всего лишь деталь реализации. Самая важная часть системы - ядро, реализующее бизнес-правила вашего домена. Он приводит пример создания FitNesse, когда решение о типе и вендоре БД принималось в самый последний момент.

Согласен с Дядей Бобом, что проектирование новой системы или новой фичи не должно начинаться с проектирования сущностей в БД. Если делать ровно наоборот - начинать с создания таблиц и их связей, то в итоге наши бизнес-сущности и правила должны будут жить с этими ограничениями: размерностями полей, видами связей, скоростью поиска и прочими.

С ними всё хорошо) И будет, я надеюсь. Они представляют, как правило, набор шаблонов для создания элементов (задач, требований, дефектов ,..) и видов процессов, т..е. это некие лучшие практики, которые смогут помочь большинству команд и организаций выстроить свой процесс.

Но после перехода от трекинга задач вашего проекта в почте/мессенджере к такому инструменту возникает новая проблема - “Джирафикация”. Когда сначала команды разработки, а потом и заказчики начинают общаться используя словарь инструмента, а не бизнес-процесса. Вот пример:

Доклад Алексея Кривицкого и выступление Дмитрия Павлова приводят примеры таких искажений.

Таким образом, сравнивая Shared Databases и таск-трекеры, на мой взгляд, последние также должны служить хранилищем данных о процессе и его артефактах, а не быть их источником. Они должны быть всего лишь деталями реализация вашего бизнес-процесса, а не его основой. Иначе возникает опасная зависимость - упала Jira, работать не можем(. Бизнес-логика не должна зависеть от деталей!

Согласен, что просто взять и выкинуть такие инструменты как Jira нельзя, да и не нужно. Они, как мне кажется, должным быть. Без них в большой организации наступил бы хаос с точки зрения управления большими инициативами и множеством команд. Но начинать, как мы поняли выше, нужно не с них.

- А с чего тогда нужно начать?

Когда команды начинают работу с своим процессом с предложенных таск-трекером шаблонов, то получается, что часть информации хранится где-то ещё (в переписке, отдельных отчетах, в головах, …), потому что не умещается в “стандартные” шаблоны. Что, конечно, не идет на пользу общей прозрачности процесса. У кого были такие случаи, когда “все таски дан”, а для релиза на прод еще нужно кучу всего сделать?

Рекомендуем следующие шаги:

1. Визуализировать свой процесс - на стикерах, доске или электронных аналогах.
2. Пожить с ним какое-то время, изменить/добавить/удалить то, что не соответствует действительности
3. Повторить п.1 и п.2 несколько раз
4. И только через несколько итераций, когда “процесс устаканится на бумаге”, его можно переносить в необходимый вам инструмент.

Описанным способом я действовал несколько раз в разных контекстах и организация. И результат всегда был ожидаем - Инверсия Зависимости. Команды и их процессы переставали зависеть от таск-трекеров, а скорее наоборот последним нужно было измениться или уступить место другим инструментам, чтобы соответствовать требованиям команд.

Если проектировать системы и процессы от инструментов, а не от потребностей, может получиться только утилизация этих самых инструментов, а не удовлетворение этих самых потребностей.

Поделитесь этой статьёй со знакомыми и коллегами, кто ещё верит, что купив “правильный инструмент”, можно сразу решить все проблемы. Как мы знаем из одного старого манифеста, люди и взаимодействие важнее процессов и инструментов. Сделайте инструменты зависимыми от вас, а не наоборот!