Глоссарий

Как читать. Термины сгруппированы по этапам, а не по алфавиту: слово чаще всего ломается там, где оно работает. Английская форма дана первой — она каноническая, и именно её стоит писать в документах, если в команде нет договорённости об обратном.

01 — Постановка

Definition of Ready

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

Русского перевода не прижилось: говорят «дор» или «критерии готовности». Частая подмена — считать готовностью объём описания. Готовность про другое: есть ли ответы на вопросы, которые иначе всплывут в середине разработки.

Definition of Done

Условия, при которых работа считается завершённой: код смержен, тесты пройдены, документация обновлена — что именно, решает команда.

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

Acceptance criteria

Критерии приёмки — проверяемые условия для конкретной задачи. Отвечают на вопрос «как мы поймём, что сделано правильно».

Признак негодного критерия простой: его нельзя проверить, не спросив автора. «Работает корректно», «удобно», «быстро» — не критерии, а намерения. Быстро — это сколько миллисекунд и на какой выборке.

Scope

Объём задачи: что входит в работу. В документах пишут «объём», в речи склоняют латиницу — «скоуп», «в скоупе», «выходит за скоуп».

Scope creep — расширение объёма по ходу без пересмотра сроков и оценки. Главный признак будущей проблемы виден сразу: граница описана только изнутри. Сказано, что входит, и не сказано, что не входит.

Stakeholder

Заинтересованная сторона — тот, чьи интересы затрагивает система. Прижилось как «стейкхолдер», и это тот случай, когда калька точнее перевода.

Подменять словом «заказчик» опасно: заказчик один, стейкхолдеров несколько, и их интересы расходятся. Классический пример — система учёта рабочего времени: сотруднику нужна гибкость и минимум полей, финансовому директору — строгая привязка ко времени и запрет правок задним числом. Требование, написанное со слов одного, всплывает на приёмке у второго.

User story

Пользовательская история в формате «как роль, я хочу действие, чтобы цель».

Не спецификация, а напоминание о разговоре — так задумано в оригинале. Опускают обычно последнюю часть, про цель, а именно она объясняет зачем и позволяет предложить другое решение.

02 — Аналитика

Functional / non-functional requirement

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

Русская калька «нефункциональные» вводит в заблуждение — звучит как «необязательные». В жизни они чаще всего просто отсутствуют в постановке и появляются в виде инцидента через месяц после релиза.

Traceability

Трассировка — прослеживаемая связь между требованием, его реализацией и его проверкой.

Проверяется двумя вопросами. По любому пункту постановки — где код и где тест. По любому дефекту — какое требование нарушено. Без этого изменение требования не превращается в изменение теста, и расхождение обнаруживается на проде.

Assumption

Допущение — то, что принято без проверки: уточнять дорого, долго или не у кого.

Опасно не само допущение, а незаписанное допущение. Записанное отличимо от факта и может быть оспорено; незаписанное через неделю читается как установленное требование, в том числе автором.

Business rule

Бизнес-правило — ограничение предметной области, не зависящее от интерфейса и от системы: скидка не превышает половины суммы, договор без подписи не действует.

Живёт дольше экранов и переезжает из системы в систему. Типовая ошибка — описать правило внутри сценария. При втором сценарии его перепишут заново, и две формулировки разойдутся.

Edge case

Краевой случай — поведение на границе диапазона: ноль, пусто, максимум, одновременность, повтор, отрицательное значение там, где его не ждали.

Часто смешивают с corner case — сочетанием нескольких границ сразу. Различие практическое: краевые случаи перебираются списком, сочетания — нет, и их приходится выбирать по риску.

03 — Разработка

Refinement

Уточнение бэклога: регулярный разбор задач до того, как их берут в планирование. В речи «рефайнмент», раньше говорили «груминг».

Встреча есть почти везде, работа на ней — не всегда. Признак вырождения: на рефайнменте не появляется новых вопросов к постановке, только оценки. Значит задачи разбирают как данность, а не проверяют на готовность.

Technical debt

Технический долг — решение, принятое сознательно ради скорости, с намерением переделать позже.

Ключевое слово «сознательно». Если намерения не было, а получилось плохо — это не долг, а дефект. Различие не терминологическое: долг планируют и возвращают, дефект чинят.

Blocker

Блокер — причина, по которой работа не может продолжаться. В речи почти всегда во множественном: «есть блокеры?».

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

04 — Тестирование

Defect / bug / incident

В английской практике это три разных слова. Bug — ошибка в коде. Defect — расхождение поведения с требованием. Incident — событие в промышленной среде, затронувшее пользователей.

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

Regression

Регрессия — отказ того, что раньше работало. Регрессионное тестирование, «регресс» в речи — проверка ранее работавшей функциональности после изменений.

Практический признак: если после каждого релиза чинят что-то, чего в релизе не было, регрессионного набора либо нет, либо он не покрывает связанные области.

UAT

User acceptance testing, приёмочное тестирование — проверка со стороны заказчика или будущих пользователей: решает ли система их задачу.

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

05 — Деплой

Release / deploy

Не синонимы, хотя в русской речи используются как одно. Deploy — код доставлен на сервер. Release — функциональность стала доступна пользователю.

Разводятся фича-флагом: код выложен и молчит, включается отдельным решением. Пока слова смешаны, разговор о поэтапной раскатке невозможен — непонятно, о каком из двух событий речь.

Rollback

Откат — возврат предыдущей версии.

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

Feature flag

Фича-флаг — переключатель, включающий функциональность без новой выкладки. Даёт раскатку на часть пользователей и выключение без отката.

Цена — ветвление поведения. У системы столько состояний, сколько комбинаций живых флагов, и постановка должна описывать поведение при выключенном флаге тоже. Забытый включённым флаг — отдельный жанр инцидента.

Hotfix

Хотфикс — правка в обход обычного цикла, потому что ждать нельзя.

Признак здорового процесса — хотфикс попадает в постановку задним числом. Если нет, следующая плановая версия его затирает, и дефект возвращается тем же составом.