EN / RU
Текущая тема: Темно-синий

Артефакты Доджо

Dojo Feature

Фича, существующая в нарративе до того, как появится в реальности.

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

Ключевые характеристики:

  • Часто упоминается, редко завершается
  • Существует в виде демо, моков или фиче-флагов
  • Считается «в работе» бесконечно
  • Используется для сигнала о движении, а не для создания ценности

Next-Gen Synergy Platform

v2.0 (Alpha-Ready)
Статус: Запланировано на Q3

Dojo Requirement

Требование, созданное чтобы существовать, а не быть выполненным.

Dojo Requirement — это формально заявленная потребность, намеренно расплывчатая, расширяемая или внутренне гибкая. Она обеспечивает непрерывное обсуждение и переосмысление, не допуская окончательного завершения. Её цель — поддерживать процесс, а не направлять исполнение.

Ключевые характеристики:

  • Двусмысленное и открытое для интерпретаций
  • Смысл меняется без изменения формулировок
  • Порождает циклы уточнений вместо решений
  • Считается «учтённым» через документацию или обсуждение
Requirement ID: #DOJO-777

Решение должно обеспечивать надёжные взаимодействия, использующие синергетические точки данных для повышения пользовательской ценности.

Requirement ID: #DOJO-888

Добавить в таблицу новую колонку с названием Статус, чтобы видеть больше информации.

Dojo Acceptance Criteria

Критерии, подтверждающие согласие, а не завершение.

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

Ключевые характеристики:

  • Высокоуровневые и непроверяемые
  • Удовлетворяются через ревью или консенсус
  • Редко поддаются тестированию на практике
  • Используются для закрытия задач без их завершения
Чек-лист Приёмки
  • Стейкхолдеры согласованы
  • «Look and feel» корректен
  • Нет очевидных блокеров

Dojo Checkbox

Элемент интерфейса, который никогда не ведёт себя так, как ожидается.

Dojo Checkbox — это элемент интерфейса, поведение которого фундаментально нестабильно. Любая попытка исправить его неизбежно ломает другую, ранее работавшую часть системы, связанную с чекбоксом. Со временем он становится неприкасаемым — обрастает предупреждениями, комментариями, тикетами и встречами — и в итоге признаётся «работающим так, как задумано».

Ключевые характеристики:

  • Его исправление вызывает регрессии в других местах
  • Владелец неясен, историчен или оспаривается
  • Становится постоянной темой обсуждений
  • В итоге исключается из реального использования, но сохраняется для вида

Dojo Document

Документация, существующая исключительно для того, чтобы на неё указывать.

Dojo Document существует не для того, чтобы объяснять, а чтобы отражать вопросы. Он служит щитом против запросов на ясность и подотчётность. Документ обычно содержит циклические ссылки, устаревшие диаграммы и заглушки «Coming Soon» в самых критических разделах — что гарантирует его полную непригодность к действию.

Ключевые характеристики:

  • Существует прежде всего для цитирования, а не чтения
  • Содержит циклические ссылки и устаревшие иллюстрации
  • Критические разделы помечены «TBD» или «Coming Soon»
  • Отражает вопросы вместо того, чтобы отвечать на них
TBD
(To Be Delegated)

TBD
(To Be Defined)

Dojo Commit

Коммит, сделанный сегодня, чтобы завтра его можно было обсудить, откатить или удалить.

Dojo Commit создаётся с единственной целью: оправдать будущий комментарий или коммит, который его удалит или откатит. Обычно минимален по объёму — часто это изменение одной строки или комментария — и демонстрирует активность, а не создаёт долгосрочную ценность.

Ключевые характеристики:

  • Намеренно временный
  • Малозначимое или косметическое изменение
  • Создан, чтобы спровоцировать будущее обсуждение или зачистку
  • Служит видимости, а не функциональности
refactor(core): optimize whitespace distribution
создан 2 минуты назад автором Senior Dojer
a1b2c3d
- const dojo = "efficiency";
+ const dojo = "efficiency";
- return true;
+ // TODO: Validate truthiness later
+ return true;

Dojo Refactoring

Изменение без улучшения.

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

Ключевые характеристики:

  • Меняет структуру, а не поведение
  • Порождает обсуждения без решений
  • Часто повторяется циклами
  • Откладывает реальные исправления под видом прогресса

До

function process() {
init(true);
return "done";
}

После

function process() {
start(true);
return "done";
}

Dojo Hotfix

Быстрое исправление, восстанавливающее доверие, а не корректность.

Dojo Hotfix — это срочное изменение, применяемое для устранения хорошо заметной проблемы при сознательном игнорировании первопричины. Оно восстанавливает поверхностную стабильность ровно настолько, чтобы удовлетворить стейкхолдеров, с негласной договорённостью, что «нормальное исправление» будет обсуждено позже — обычно бесконечно.

Ключевые характеристики:

  • Исправляет симптомы, а не причины
  • Внедряется в условиях нехватки времени
  • Восстанавливает временную поверхностную стабильность
  • Оставляет глубинные проблемы нетронутыми
  • Привносит будущую нестабильность
КРИТИЧЕСКАЯ ОШИБКА СИСТЕМЫ
HOTFIX ПРИМЕНЁН