Перейти к основному содержимому

⚡ Документация микро-спецификации

Микро-спецификация является документом, который позволяет использовать минималистичный подход к документированию небольших рабочих элементов (например, исправлений ошибок, мелких изменений UI, обновлений конфигурации), требующих небольших усилий. Цель который — обеспечить достаточный контекст для реализации и проверки, избегая избыточной бюрократии.

Применимость:

Используется для задач, которые:

  • Оцениваются в менее 1 дня усилий.
  • Не затрагивают множественные компоненты системы.
  • Не требуют введения новых архитектурных паттернов или технологий.
  • Являются очевидными и простыми в реализации (например, исправление опечатки, изменение цвета кнопки, обновление значения в конфигурационном файле).

Процесс составления​

Шаг 1: Определение сути изменений​

Цель: Четко сформулировать, что именно нужно изменить или исправить.

Действия:

  • Кратко опишите текущее (неправильное/неоптимальное) состояние.
  • Четко опишите желаемое (правильное/целевое) состояние.
  • Укажите конкретное место в системе, где требуется изменение (например, название файла, экран, строка кода, если это очевидно).

Шаг 2: Формулировка обоснования​

Цель: Объяснить зачем нужно это изменение, чтобы любой член команды мог понять его ценность или необходимость.

Действия:

  • Укажите причину: это исправление бага, улучшение UX, обновление по требованию заказчика, соответствие новому гайдлайну и т.д.
  • Если это исправление бага, кратко опишите, как воспроизвести проблему (или укажите ссылку на тикет баг-трекера).

Шаг 3: Определение критериев приемки​

Цель: Задать объективные и проверяемые условия, по которым можно будет определить, что задача выполнена успешно.

Действия:

  • Используйте простой, активный залог.
  • Формулируйте критерии как проверяемые утверждения. Часто достаточно одного-двух критериев.
  • Рекомендация: Для максимальной ясности можно использовать упрощенный синтаксис EARS (например, WHEN... THEN...), но это не обязательно, если критерий и так однозначен.

Пример плохого критерия: "Исправить баг". Пример хорошего: "После клика по кнопке 'Отправить' форма больше не зависает, а отображается сообщение 'Данные успешно отправлены'".

Шаг 4: Валидация и финализация​

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

Действия:

  • Задайте себе вопрос: "Может ли разработчик, не имеющий контекста этой задачи, взять этот документ и сразу приступить к реализации?"
  • Задайте себе вопрос: "Может ли тестировщик или сам разработчик однозначно проверить, что задача выполнена, используя только эти критерии приемки?"
  • Если на оба вопроса ответ "да" — спецификация готова.

Шаблон документа "Микро-спецификация"​

# Микро-спецификация: [Краткое и понятное название задачи]

**Текущее состояние:** 

[Описание того, что есть сейчас и что не так.]

**Желаемое состояние:** 

[Описание того, что должно быть после реализации задачи.]

**Место изменения:** 

[Конкретный файл, модуль, экран, URL и т.д. Где именно нужно внести правки?]

## Обоснование 

[Объяснение причины внесения изменений. Например: "Исправление критического бага, мешающего пользователям входить в систему", "Обновление текста согласно новому маркетинговому гайдлайну", "Изменение цвета для улучшения доступности".]

## Стратегия тестирования

* [Тестовый кейс]
   * Описание кейса
* [Другой тестовый кейс]
   * Описание кейса

---

## Чек-лист качества микро-спецификации

*(Заполняется автором после завершения документа)*

| Критерий                                                                          | Выполнено | Комментарий |
| --------------------------------------------------------------------------------- | --------- | ----------- |
| Указано конкретное место в системе, где нужно внести изменение                    | ☐        |             |
| Обоснование содержит бизнес или пользовательскую ценность                         | ☐        |             |
| Все критерии приемки сформулированы в активном залоге и используют EARS (WHEN/IF) | ☐        |             |
| Каждый критерий приемки является **проверяемым** и **однозначным**                | ☐        |             |
| В спецификации нет составных требований (разделены на отдельные пункты)           | ☐        |             |
| Любой разработчик может взять спецификацию и сразу приступить к работе            | ☐        |             |