A Place for Everything - система отслеживания задач Майка Зорнека

Майк Зорнек (Mike Zornek) описал систему, которую использует для отслеживания задач разработки, когда может сам определять рабочий процесс команды. Система конкретная и с чёткими принципами: всё живёт в GitHub Issues и GitHub Projects, работа проходит через девять явных стадий-статусов, у задач есть тип, а pull request'ы пишутся как связные истории. Он подчёркивает, что это система, к которой он пришёл сам, а не универсальное предписание: приходя в команду с уже налаженным процессом, он сначала задаёт вопросы, а не меняет чужой пайплайн на свой.

Держать задачи рядом с кодом

Главное решение по размещению - вести задачи в GitHub Issues и отображать расписание через GitHub Projects, максимально близко к репозиторию. Логика в том, что знания о коде должны находиться рядом с самим кодом, а не уплывать в отдельный инструмент, который со временем забывают или забрасывают. Зорнек отмечает, что команды часто меняют инструменты для документации, и оставленные там знания теряются при переездах. Вторая причина - прозрачность: заинтересованные лица видят, что находится в работе, могут отслеживать прогресс по крупным эпикам и оценивать риски по срокам без лишних вопросов.

Тот же мотив стоит за filesystem-is-graph-database и идеей "у работы должно быть своё место" в jxnl-codex-maxxing: сохранять записи там же, где находится сам артефакт, чтобы они не расходились.

Девять статусов вместо трёх

Зорнек использует больше стадий статуса, чем принято на большинстве досок: Opportunities, On Deck, In Progress, Needs Review, Done (Merged), Deployed (Shipped), To Be Verified, Verified и Canceled. Вся суть именно в высокой детализации: с первого взгляда понятно, вмёрджена ли готовая задача, развёрнута или уже проверена стейкхолдером со стороны бизнеса. Он разделяет "merged", "deployed" и "verified", поскольку это принципиально разные состояния готовности, а их объединение скрывает реальный статус работы.

Названия имеют значение. Первую колонку он намеренно называет Opportunities, а не Backlog. Бэклог подразумевает долг, который вы обязаны закрыть; "возможности" же могут лежать сколь угодно долго, могут никогда не пойти в работу, и это нормально. Это даёт идее публичное место для обсуждения без постоянного чувства вины от бесконечно растущего списка. Зорнек прямо называет обратную сторону такого подхода: колонка может раздуться так, что в ней станет невозможно ориентироваться, и решение здесь - периодически чистить её и закрывать задачи. Закрывать идеи, не попавшие в приоритет, разрешено.

Такая смена формулировки - выбор слова, меняющего отношение к накопившемуся списку, - аналогична подходу в para-method с сортировкой по степени применимости (actionability) и перекликается с принципом "без чувства вины", характерным для basb-overview. Название формирует поведение.

Типы для навигации по длинному списку

Если статус отвечает на вопрос, где находится задача, то тип отвечает на вопрос, что это такое, - и это особенно важно, когда список Opportunities разрастается. Его типы: Task (включая работу не с кодом), Bug, Feature, Enhancement, Enhancement: UI (улучшения юзабилити без изменения поведения), Security, Code Refactor / DevOps и Documentation. Разделение на Enhancement и Enhancement: UI оправдывает себя только тогда, когда список становится достаточно большим для фильтрации.

Pull request'ы как истории

Задачи фактически закрываются именно в pull request'ах, поэтому Зорнек связывает их напрямую. PR ссылается на закрываемый issue, чтобы при мёрдже тот закрылся автоматически, либо содержит Related to: #123, если работа продвигает задачу вперёд, но не завершает её полностью.

Основную роль играют три привычки. Использовать шаблон PR как ориентир по умолчанию, а не строгое правило: его можно проигнорировать, если изменение нагляднее подать иначе. Оформлять PR как связную историю: сформулировать проблему, описать само изменение, объяснить, как оно решает проблему, и дать чёткие шаги для проверки, включая seed-код, если в dev-окружении нет нужных данных для воспроизведения сценария. Открывать PR заранее в виде draft'ов, чтобы остальные видели текущую работу, а статус "open" и формальный запрос ревью оставлять на момент, когда код действительно готов к проверке.

Его шаблоны варьируются от заготовки в две строки (строка Fixes # плюс секция "How to test/verify") до более подробного варианта с блоками Problem Statement, About the Change, How to Test and Verify и чек-листом для автора. Чек-лист предлагает автору провести самопроверку перед передачей кода: написаны ли тесты, явно ли указаны типы (typespecs), учтена ли производительность, зафиксированы ли решения в документации, есть ли изменения в именовании, о которых нужно знать остальным, требуется ли обновление changelog'а, стоит ли сразу завести связанные follow-up задачи. Зорнек подчёркивает: конкретные вопросы не так важны, как сама привычка сделать паузу на самопроверку до того, как PR станет чужой проблемой. Последнее правило - самое старое: держите PR небольшими и учитесь разбивать изменения на части.

PR в виде связной истории бережёт внимание читателя; это то же уважение ко времени будущего читателя, на котором строится progressive-summarization: проделать работу по сжатию и объяснению самому, чтобы ревьюеру не приходилось восстанавливать контекст с нуля.