Готовность (DoR/DoD)

DoR — Definition of Ready: что должно быть готово, чтобы работа началась. Нужна, чтобы покончить с заявками, которые уходят в работу и через два дня возвращаются, потому что не хватило доступа, данных или решения.
DoD — Definition of Done: что должно быть сделано, чтобы работа считалась завершённой. Нужна, чтобы покончить с «я закончил», когда ещё ничего не протестировано, не задокументировано и не сообщено.

Обе — одна и та же идея на двух концах: записать договорённость заранее, чтобы не спорить потом. И обе задаются по ЭТАПУ доски — у каждой колонки может быть своя.

Два списка, о которых команда договаривается один раз и пользуется всегда: что должно быть готово, чтобы заявка МОГЛА начаться (Definition of Ready), и что должно быть готово, чтобы она считалась ЗАВЕРШЁННОЙ (Definition of Done). Это защищает от заявки, попавшей в спринт без объёма работ, и от той, что «готова», но никем не протестирована.

Здесь вы регистрируете пункт договорённости команды о готовности (DoR/DoD): к какому этапу он относится, является ли он условием ВХОДА в этап или ВЫХОДА из него, действует ли только для одного типа заявки, текст договорённости, блокирует ли он выход из этапа, порядок отображения и активен ли он. Это чек-лист качества потока, пункт за пунктом.

Поле «Вход или выход» определяет, с какой стороны этапа находится договорённость. Пункт ВХОДА — это Definition of Ready: что должно быть готово ДО того, как заявка войдёт в этап (например, «критерии приёмки написаны» перед входом в выполнение). Пункт ВЫХОДА — это Definition of Done: что должно быть сделано, чтобы заявка ВЫШЛА из этапа («code review одобрено»). Поле «Только для типа» ограничивает пункт одним типом заявки — договорённость для бага не обязана действовать для улучшения.

Вы пишете пункт здесь один раз; он копируется в чек-лист самой заявки, когда она входит в этап, с меткой в квадратных скобках (например, [DoD Em execução] testes automatizados verdes).

Обратите внимание: второго списка для отметок нет — исполнитель отмечает там же, где и всегда, внутри заявки, и проверка читает оттуда. Второй список на практике означал бы заброшенный список.

Это самая неочевидная часть. Когда вы перетаскиваете карточку из одной колонки в другую, система проверяет DoD колонки, из которой она уходит, — потому что вопрос звучит так: «можно ли считать это здесь завершённым?».

DoR никогда не блокирует. Она служит проверкой на входе, появляется в чек-листе и работает как напоминание. Если отметить блокировку у пункта DoR, система снимет её и предупредит.

Три возможных исхода при перемещении: ничего не осталось — карточка проходит; остались пункты без блокировки — карточка проходит с предупреждением и списком оставшегося; остались пункты с блокировкой — карточка возвращается на место. Достаточно одного открытого блокирующего пункта.

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

Два честных ограничения барьера, чтобы вы не полагались на него слишком сильно: он срабатывает только при перетаскивании на доске — смена статуса через форму заявки, массово или через «Завершить» здесь не проверяется. И если проверка падает из-за технической ошибки, перемещение проходит. Барьер, останавливающий работу из-за сбоя инфраструктуры, хуже проблемы, которую он предотвращает.

Пункт и отметка узнают друг друга по тексту метки. Если вы измените описание договорённости (или переименуете этап, который входит в метку), система перестанет узнавать то, что уже было отмечено: старая отметка останется видна в истории заявки, а новый пункт появится как невыполненный.

Это правильное поведение — правило изменилось, проверка выполняется заново, — но планируйте изменение: если сделать его посреди спринта, невыполненные пункты вернутся на всю доску.

При сохранении представления кнопкой «Представления» запоминаются четыре вещи: текст поиска, применённые фильтры, какие столбцы видны (и в каком порядке) и по какому столбцу отсортирован список. Применение представления восстанавливает всё сразу — включая сброс сортировки и страницы, на которой вы были, чтобы результат был ровно тем, что описывает представление. Представления, сохранённые до этой версии, остаются в силе: то, чего они не запомнили, при применении просто не меняется.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

Переключатель «Блокирует выход» отделяет рекомендательную договорённость от обязательной: блокирующий пункт удерживает заявку на этапе, пока он не выполнен; неблокирующий пункт отображается как напоминание о договорённости команды, но не мешает продвижению. Используйте блокировку умеренно — если блокировать всё, поток превращается в бюрократию, а команда начинает отмечать пункты не глядя; блокировка нужна для того, что действительно нельзя пропустить без проверки, например «тесты выполнены» перед завершением.

В панели активности записи у каждой заметки есть «Превратить в задачу». Щелчок создаёт тикет с текстом заметки, её автором и ссылкой на эту запись — ничего не нужно перепечатывать. Используйте, когда заметка — это просьба о действии («кому-то нужно это проверить»); сама заметка остаётся на месте. Кнопка появляется только после сохранения записи; сеанс только для чтения (демонстрация) задачу не создаёт.

Только если оставить тип пустым — тогда это общее правило. Если указать тип, пункт будет действовать только для этого типа заявок (ошибка, улучшение, поддержка...).

Учтите одну тонкость: заявка без указанного типа получает только общие правила. Если ваша важная DoD привязана к типу, заявка без типа её обходит.

Откройте запись и посмотрите на «Хронологию» справа: каждое изменение показано как «было одно значение — стало другое», с автором и датой. Если изменений много, используйте два фильтра вверху хронологии — по полю и по человеку. Поиск идёт в базе данных, поэтому старые изменения находятся так же. Можно спросить и Tenkai: «кто изменил договор 482?».