Goal описує стан після задачі

Goal має описувати не загальний намір на кшталт «покращити процес», а стан системи після виконання. Він відповідає на питання: хто отримує користь, яка поведінка змінюється, де це видно і що має залишитися без змін.

Ціль описує поведінку системи, а не список файлів, класів чи технічних кроків. Спосіб реалізації краще залишати плану.

Формула Goal
користувач або роль
+ нова поведінка
+ місце прояву
+ стабілізатор (що не повинно змінитися)

Від vague request до перевірюваної цілі

НечіткоПеревірюваніше
Покращити процес повернення.Оператор може додати необовʼязковий коментар до refund-request.
Зробити форму зручнішою.Коментар відображається в деталях повернення для фінансового перегляду.
Додати поле notes.Значення зберігається та передається в події refund.created.

Шаблон блоку Goal

  1. Визначте тип задачі: feature, bugfix, refactoring, tests, документація, investigation або міграція.
  2. Назвіть користувача, роль або компонент, який отримає результат.
  3. Опишіть нову чи виправлену поведінку.
  4. Вкажіть місця, де результат можна спостерігати.
  5. Додайте ознаки готовності та критичну поведінку, яку не можна змінити.
## Мета

[Роль] отримує можливість [дія або результат].
Зміна помітна в [інтерфейс, API, подія чи документація].
Готовність підтверджується тим, що [спостережувані ознаки].
При цьому [поведінка, яка залишається незмінною].

Goal для різних типів задач

ТипРезультат
Нова функціяНова доступна користувачеві або системі поведінка
BugfixУсунений дефект і підтвердження правильного сценарію
РефакторингЗмінена внутрішня структура без зміни зовнішньої поведінки
ТестиПовторно запускний захисний сценарій
InvestigationВисновок, підкріплений аналізом і доказами

Що не є Goal

  • Scope — це частини системи, яких стосується робота.
  • Constraints — правила та заборони під час виконання.
  • Рішення — конкретний спосіб реалізації.
  • Побажання — загальні оцінки без критерію перевірки.

Канонічне джерело уроку · JavaRush

Відкрити матеріал JavaRush