План реалізації: від наміру до перевірюваного результату

Після глав 18–20 читач може описати архітектурну межу, розкласти зміну на вертикальні зрізи й позначити залежності. Тут ми зберемо ці рішення в план реалізації: послідовність робіт із передумовами, проміжними результатами, доказами та умовами продовження.

План не пророкує майбутнє й не доводить, що обраний дизайн правильний. Він допомагає команді побачити, що відомо, що ще потрібно перевірити, як зміни торкнуться чинної системи та як безпечно зупинити або змінити напрямок. Хороший план можна виконувати й переглядати; поганий лише створює враження, ніби кожна невідомість уже має відповідь.

Імена сервісів, правила бронювання, дати, показники й результати в навчальних прикладах вигадані. Вони не описують реальну компанію.

21.1. На яке запитання відповідає план

План реалізації відповідає на практичне питання: які зміни, у якому порядку, на підставі чого та з якими перевірками дадуть прийняту поведінку? Він пов’язує кілька різних записів, але не замінює їх.

Артефакт	На яке питання відповідає	Чого сам собою не вирішує
PRD (Product Requirements Document — документ вимог до продукту)	Яку проблему й для кого розв’язуємо? Яка поведінка потрібна?	Які саме файли чи таблиці змінити
SAD (Software Architecture Document — документ опису архітектури програмного забезпечення)	Які частини системи та межі залучені?	Чи підтверджені всі припущення про чинну реалізацію
ADR (Architecture Decision Record — запис архітектурного рішення)	Чому прийнято конкретне технічне рішення, які альтернативи відхилено?	Повну послідовність виконання кожної зміни
План реалізації	Що змінюємо поетапно, що залежить від чого і який доказ відкриває наступний етап?	Правильність вимог або відсутність нових фактів
План перевірок	Які перевірки покажуть, що поведінка відповідає очікуванням?	Саме виконання цих перевірок

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

Повний план перевірок розбирається у главі 22. План теж може посилатися на невирішене рішення. Це прийнятно, якщо названі власник, строк або умова рішення і роботи, які чекають на нього. «Пізніше з’ясувати» без відповідального й наслідку — не контрольована невідомість.

21.2. Спершу зберіть вхідні дані

Перед розбиванням на кроки перевірте, які джерела вже є. Важливі не лише документи: чинний код, конфігурація, база даних, журнали, тестове середовище та реальні обмеження постачальника часто точніші за старий опис.

Вхід	Що шукаємо	Як позначити проблему
Вимоги й критерії приймання	Очікувану поведінку, винятки, дозволи, межі обсягу	Суперечність або відсутнє продуктове рішення
Код і тести	Поточні правила, виклики, фонові процеси, сумісність	Висновок, який поки не підтверджено тестом чи виконанням
Контракти API (Application Programming Interface — програмний інтерфейс застосунку)	Формати запитів і відповідей, статуси помилок, споживачів	Версії клієнтів, які можуть лишитися активними
Дані й міграції	Джерело істини, обмеження, обсяг, історію схеми	Чи потрібне перенесення даних і як перевірити його повноту
Інфраструктура та права	Середовища, секрети, черги, мережеві дозволи, перемикачі	Доступ, якого немає або який не можна видати виконавцю
Експлуатація й підтримка	Моніторинг, чергування, ручне відновлення, звернення клієнтів	Хто приймає рішення під час інциденту

Для кожного важливого твердження можна додати коротку мітку: підтверджений факт, припущення, рішення, відкрите питання. Наприклад: «старе бронювання скасовується після підтвердження нового» є продуктовим правилом лише тоді, коли це затвердив власник вимоги. У прикладі далі ми прямо приймемо його як умовне правило для навчання.

Зазначайте ревізію коду, джерело рішення і дату перевірки, коли від них залежить відтворюваність плану. Слова «у нас зараз так» швидко старіють; посилання на конкретний файл, тест, версію контракту або коментар до вимоги дає наступному виконавцю спосіб звіритися.

21.3. Окресліть область впливу

Одна зміна може зачіпати більше шарів, ніж видно з назви задачі. Перевірте принаймні:

• інтерфейс користувача й доступність;
• маршрути та контракти API;
• правила авторизації та ролі;
• структуру й життєвий цикл даних;
• події, черги, планувальники й повторні запуски;
• зовнішні сервіси, ліміти, автентифікацію та тайм-аути;
• налаштування середовищ, дозволи й секрети;
• журнали, метрики, сповіщення та інструкції підтримки;
• документацію, сумісність клієнтів і плани випуску.

Не записуйте всі можливі файли як наперед відомі. Корисно відрізнити підтверджену область від кандидатів після дослідження. Наприклад: «підтверджено: маршрут перенесення й сервіс бронювання; дослідити: чи викликає нагадування старий календарний ідентифікатор». Це не розмиває план; це ставить перевірку до коду, який може виявитися хибним.

Уточніть і те, що не входить до зміни. «Перенесення не змінює ціну», «не дозволяється переносити завершене бронювання» і «повернення коштів не додаємо» — корисні межі, якщо вони підтверджені продуктовими правилами. Межа обсягу запобігає випадковій підміні мети, але не дає права ігнорувати обов’язкову сумісність, безпеку чи відновлення.

21.4. Плануйте перевірюваний результат, а не перелік команд

git status, міграційна команда або запуск перевірок можуть бути частиною кроку, але самі по собі не кажуть, навіщо його виконують. Для кожного етапу назвіть:

1. Результат: який стан або поведінка має з’явитися.
2. Передумову: що мусить бути відоме чи готове.
3. Зміни: який шар або межу торкаємося.
4. Доказ: тест, порівняння, журнал, ручна демонстрація чи перевірене рішення.
5. Умову продовження: що повинно бути істинним, щоб наступний крок був безпечним.
6. Власника й відновлення: хто вирішує при відмові і що робимо з уже створеним станом.

Крок «оновити схему» надто короткий, якщо після нього не зрозуміло, хто читає нові дані, чи можуть паралельно працювати старий і новий код і за яким доказом міграція завершилася. Натомість «додати сумісну структуру; запустити міграцію в копії реальних за формою даних; звірити кількість і правила; лише після цього розгортати код, який її читає» вже має зрозумілу перевірку та ворота.

Ці ворота не завжди означають формальне погодження людиною. Це може бути автоматизована перевірка або задокументована умова. Людське рішення потрібне там, де змінюється продуктова поведінка, приймається ризик або виконується небезпечна операція, а не на кожному технічному кроці.

21.5. Повний приклад: перенесення бронювання

Умови навчального прикладу

Уявімо сервіс, який зберігає бронювання в базі даних і синхронізує їх із зовнішнім календарем. У цьому прикладі власник продукту вже погодив такі правила:

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

Це не універсальна політика. У справжній роботі її треба звірити з договором, правилами обслуговування, чинними обмеженнями й власником продукту. Ми також припускаємо, що дослідження тестового середовища підтвердило: календар дозволяє спершу зарезервувати новий час, а потім підтвердити або відхилити його. Якщо це припущення не підтвердиться, дивіться окремий приклад у §21.10.

Крок 0. Звірити вихідний стан

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

Доказ і умова продовження: названо джерело істини для статусу бронювання; описано, хто й коли змінює його; тестове середовище відтворює звичайне створення запису. Якщо код та вимоги суперечать один одному, питання повертається власнику вимоги до реалізації.

Крок 1. Перевірити контракт календаря

Результат: короткий технічний висновок про резервування, підтвердження, тайм-аут, повтор і скасування. Перевірка використовує тестовий обліковий запис без справжніх бронювань клієнтів. Висновок включає запит і відповідь, коди відмови, ліміти й спосіб упізнати повтор того самого запиту.

Доказ і умова продовження: передбачуваний повтор повертає той самий результат або безпечно повідомляє про вже виконану операцію; тайм-аут не залишає невідомим, чи створено резерв. Якщо постачальник не дає надійного способу дізнатися стан, робота зупиняється на цьому рішенні: записати невідоме, власника, наслідок і доступні варіанти. Не можна переходити до автоматичного скасування старого місця на підставі припущення.

Крок 2. Додати сумісне зберігання спроби

Результат: окремий запис спроби перенесення з ідентифікаторами старого бронювання, цільового часу й ідемпотентного ключа, поточним станом, зовнішнім ідентифікатором та часовими мітками. Точна схема лишається за архітектурним рішенням після огляду чинної бази. Новий код не робить старі рядки недійсними; старий маршрут продовжує працювати.

Доказ: міграція запускається на копії, сформованій за чинною структурою; старий і новий код можуть співіснувати; перезапуск не дублює спробу. Якщо таблиця створюється, у перевірці мають бути обмеження унікальності й зовнішній зв’язок із початковим бронюванням. Зразок даних до і після зберігається для порівняння.

Крок 3. Реалізувати серверний сценарій під вимкненим перемикачем

Результат: нова операція перевіряє власника, статус, допустимість дати й доступність; створює спробу з ключем ідемпотентності; резервує ціль; позначає нове місце підтвердженим лише після відповіді постачальника. Старе місце скасовується тільки після цього підтвердження.

Доказ: тести показують відмову для чужого, завершеного або неактивного бронювання; двічі надісланий той самий запит не створює двох резервів; конфлікт доступності залишає старий запис недоторканим. Окремо відтворюється тайм-аут між резервуванням та підтвердженням і підтверджується, що повтор спершу перевіряє стан, а не сліпо повторює побічну дію.

Крок 4. Узгодити стан і побічні наслідки

Результат: визначені переходи спроби, які можна простежити: requested (запитано), reserved (зарезервовано), confirmed (підтверджено), failed (не вдалося) або needs_resolution (потрібне розв’язання). Кожен перехід має спостережуваний доказ і відповідального.

Доказ: тестова послідовність показує, що нагадування не відправляється на старий час після підтвердження нового; повторна доставка події не створює другого нагадування; відмова скасувати старий резерв переводить запис у стан, який видно підтримці. Для такого часткового успіху є інструкція: перевірити обидва ідентифікатори, підтвердити, що клієнт бачить, і виконати безпечну компенсацію за затвердженим правилом.

Не кожна помилка має зводитися до «відкотити все». Зовнішній календар може вже виконати дію, яку не можна атомарно скасувати разом із транзакцією вашої бази. У плані треба назвати фактичну межу узгодженості й шлях виправлення, а не обіцяти транзакційний відкат там, де його технічно немає.

Крок 5. Перевірити контракт клієнта й споживачів

API (Application Programming Interface — програмний інтерфейс застосунку) документується до підключення кнопки. У нашому умовному контракті відповідь відрізняє «прийнято до обробки» від «перенесення підтверджене». Клієнт не показує успіх, поки сервер не має підтвердження нового часу. Якщо операція асинхронна, клієнт бачить стан і може повернутися до нього після перезавантаження.

Доказ: клієнт, сервер і тестовий генератор контракту однаково трактують успіх, конфлікт і очікування; невідоме поле не вважається підтвердженим часом. Для старих клієнтів не змінюємо значення чинної відповіді без окремого погодженого переходу.

Крок 6. Завершити доступну поведінку й інструкції

Результат: клієнт бачить доступні години, недоступність і результат перенесення; екран доступний клавіатурою й допоміжним засобам; підтримка має пояснення для needs_resolution. Події й журнали не містять зайвих особистих даних.

Доказ: наскрізна перевірка проходить позитивний шлях, конфлікт, втрату мережі та повернення до відкритої спроби. Перевірка журналів підтверджує, що оператор може знайти спробу за внутрішнім ідентифікатором і не мусить шукати персональні дані в незахищених повідомленнях.

Крок 7. Випустити обмежено й вирішити за сигналами

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

До першого ввімкнення мають бути визначені сигнали: частка невдалих перенесень, кількість спроб у needs_resolution, дубльовані резерви, час відповіді, скарги й навантаження на підтримку. Пороги беруться з чинних домовленостей про рівень сервісу та базових вимірів, а не вигадуються після інциденту. Власник випуску бачить дашборд і знає, хто може вимкнути перемикач.

Google Cloud описує канарковий випуск як поступове передавання частини інфраструктури новій версії з перевіркою перед розширенням і підтримкою повернення трафіку до старої версії. Це приклад механіки конкретної платформи, а не готові універсальні відсотки для кожного продукту. Документація Cloud Deploy про стратегії випуску, переглянуто 26 вересня 2026 року.

Крок 8. Назвати, що саме означає відновлення

Якщо спостереження перетнули погоджений поріг, черговий вимикає нові перенесення й зберігає журнали спроб. Кодову версію можна повернути до попередньої, доки попередній код розуміє нову таблицю. Дані спроб не видаляють автоматично: спершу з’ясовують зовнішній стан кожної невизначеної операції. Власник інциденту визначає, чи треба виконати компенсацію, повідомити клієнта або зупинити пов’язану чергу.

Повернути старий виконуваний файл — не те саме, що повернути дані або зовнішній календар до попереднього стану. Amazon Web Services (AWS — назва хмарної платформи Amazon) радить під час переходів підтримувати зворотну сумісність, період співіснування старої й нової логіки та описані процедури аварійного відкату. Це галузеві рекомендації AWS для їхнього контексту декомпозиції баз даних; конкретні кроки треба звіряти з вашим стеком. AWS Prescriptive Guidance: backward compatibility and rollback, переглянуто 26 вересня 2026 року.

21.6. Міграція схеми — окремий план, а не прихована команда

Схема й дані переживають версії застосунку. Старий процес може ще обробляти чергу, коли новий код уже розгорнувся. Через це небезпечну зміну структури не варто ховати між «оновити сервер» і «перевірити сторінку».

Підхід розширити — перевести — звузити (англ. expand-and-contract) може виглядати так:

1. Розширити: додати нове поле або таблицю, не видаляючи того, від чого залежить попередня версія. Новий елемент спочатку необов’язковий.
2. Підготувати обидва варіанти: розгорнути код, який розуміє старі та нові дані. Якщо потрібне перенесення, зробити його повторюваним і вимірюваним.
3. Порівняти: звірити кількість, вибірку крайніх випадків, часові зони й записи без відповідника. За потреби тимчасово читати старе й нове та порівнювати результат.
4. Перемкнути читання й запис: лише коли дані й споживачі готові, переключити нову поведінку; спостерігати за помилками та розбіжностями.
5. Звузити: видаляти стару структуру лише після завершення періоду співіснування й підтвердження, що старі версії, резервні процедури та зовнішні споживачі її більше не використовують.

Цей порядок не є готовим рецептом для кожної бази. Великий зворотний заповнювач може блокувати таблицю, тригер — створити подвійну дію, а два поля можуть мати різні правила часової зони. Архітектор має вибрати техніку й узгодити її з можливостями сховища. План повинен фіксувати послідовність і доказ, а не приховувати особливості платформи за модним словом.

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

21.7. Поганий план і його виправлення

Припустімо, local_time містить локальний час бронювання, а нове utc_time має зберігати його як UTC (Coordinated Universal Time — координований універсальний час). Початковий запис у вигаданому сервісі каже:

Видалити поле local_time, перевести всі споживачі на utc_time, перевірити бронювання.

Це не план переходу. Не сказано, що є джерелом істини; чи вже заповнено utc_time; як трактують історичні значення; які версії вебзастосунку, мобільного клієнта й фонового процесу лишаються активними; чи безпечно повторити міграцію; що робити, якщо частина записів не має часової зони. «Перевірити бронювання» не називає даних або очікуваного результату. Видалення поля також руйнує шлях повернення попереднього коду.

Переписаний план:

1. Підтвердити семантику часу. Власник продукту затверджує, чи local_time означає локальний час місця бронювання або часовий пояс клієнта. Розробник знаходить місце, де це правило зараз застосовується, і фіксує приклади переходу через літній час.
2. Додати сумісне поле. Міграція додає utc_time, яке допускає порожнє значення. Старий код і далі працює. Доказ: попередня версія запускається зі зміненою схемою на тестовій копії.
3. Перенести дані повторювано. Скрипт заповнює лише порожні значення, пише контрольний звіт і не змінює рядок, якщо джерело часу неоднозначне. Доказ: кількість успішно перетворених, пропущених і конфліктних записів збігається зі звітом.
4. Порівняти читання. Тимчасова перевірка обчислює обидва значення для репрезентативних часових поясів, записів із літнім часом і граничних дат. Власник продукту погоджує конфлікти до перемикання.
5. Перемкнути нові читання й записи. Розгорнути сумісний код, залишивши запис старого поля на час співіснування. Під наглядом перевірити помилки, розбіжності й фонові завдання.
6. Прибрати старе окремою зміною. Лише після перевірки всіх споживачів і завершення вікна відкату зупинити старий запис; поле видаляти окремою міграцією з дозволом власника даних. Архів звірки лишається доступним.

Проміжні докази показують, чи безпечно переходити далі. Якщо невизначених записів багато, команда не «виправляє» їх навмання заради завершення графіка: власник вимоги вирішує правило, а план змінюється з поясненням.

21.8. Перевірки — це докази для рішень

Перевірки розподіляються по етапах. Перевірка статичного типу не доводить, що зовнішній календар скасовує правильний запис; сценарій у тестовій базі не доводить, що стара версія сумісна з новою схемою.

Перевірка	Що вона може підтвердити	Чого вона не підтверджує сама
Перевірка функції	Правило для локального набору входів	Поведінку бази, мережі й зовнішнього сервісу
Перевірка інтеграції	Взаємодію кількох частин у тестовому середовищі	Реальні ліміти, права й дані клієнта
Перевірка контракту	Узгодженість форми запиту, відповіді та очікувань споживачів	Усі бізнес-наслідки після випуску
Перевірка міграції	Повторюваність і перетворення на конкретній копії	Відновлюваність резервної копії, якщо її не перевіряли
Перевірка випуску	Роботу в цільовому середовищі та наявність сигналів спостереження	Безпечність усіх майбутніх навантажень
Ручний перегляд	Те, що досвідчена людина перевірила визначений артефакт	Те, чого вона не переглядала або не могла побачити

Для кожного важливого доказу збережіть, до якої ревізії він належить, що саме запускали, результат, обмеження й власника. «Тести зелені» без коміту, набору перевірок і часу виконання не дозволяють відрізнити результат для поточного коду від старого запуску. У цьому курсі ми не вважаємо, що кількість агентів, малий розмір патча чи успішна компіляція замінюють приймальні докази.

Якщо частину перевірок можна виконати лише вручну — наприклад, юридичну оцінку тексту або експертну перевірку безпеки, — назвіть це обмеження, виконавця й момент. Позначка «автоматизовано» не повинна зникати під час переказу плану.

21.9. План випуску й план відновлення пов’язані, але різні

Випуск відповідає на питання, хто отримає зміну, в якій послідовності, за якими сигналами ми продовжимо й хто зупинить розширення. Відновлення відповідає, як повернути послугу до безпечного стану після помилки та що робити з даними й побічними діями, які вже відбулися.

До першого випуску запишіть:

• поточну версію й точний артефакт, який запускається;
• ввімкнене охоплення та механізм швидко його зупинити;
• сигнали здоров’я, джерело базового рівня й пороги рішення;
• хто спостерігає й у який період;
• умову розширення, умову паузи й дію при відмові;
• сумісність коду, схеми даних, черг і зовнішніх інтеграцій;
• відновлювальну дію, яка не створить повторних списань, бронювань чи листів;
• джерело правди після часткового успіху, відповідального та порядок зв’язку з підтримкою.

Якщо перемикач вимикає лише інтерфейс, але фоновий процес далі створює зовнішні бронювання, це не повний аварійний вимикач. Перевірте, яку саме дію він зупиняє. Те саме стосується відкату: стара версія програми може не розуміти вже записану нову схему або статуси.

21.10. Коли зовнішній сервіс не підтримує потрібну операцію

Під час Кроку 1 головного прикладу команда може виявити, що постачальник не підтримує атомарне перенесення й не дозволяє резервувати новий час, поки старий іще активний. Тоді три очікувані операції — «скасувати старе», «створити нове», «відновити старе» — не обов’язково утворюють одну транзакцію. Після тайм-ауту команда може не знати, чи новий запис уже з’явився.

План не повинен мовчки перетворити це на «додати кілька повторів». Спершу визначають точне обмеження в тестовому середовищі й перевіряють доступні можливості пошуку стану, унікальних ключів, компенсації та строку відповіді. Далі готують рішення з наслідками:

Варіант	Що зберігає	Новий ризик або обмеження	Хто вирішує
Запитати сервіс про нову підтримувану операцію	Автоматизований перенос, якщо постачальник додасть контракт	Очікування й невизначений строк	Власник продукту та власник інтеграції
Запропонувати час, дочекатися відповіді людини, тоді вручну узгодити дві дії	Контрольований сценарій без удавання атомарності	Повільніше; потрібна операційна процедура	Власник обслуговування
Залишити бронювання незміненим і запропонувати клієнту звернутися до підтримки	Не ризикує мовчки втратити старий запис	Продуктова обіцянка стає меншою	Власник продукту
Виконати скасування й створення послідовно	Може звільнити старий час раніше	Клієнт може залишитися без обох місць	Не приймати без оцінки наслідків і явного погодження

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

Це є contingency: умовний варіант дій при конкретному спостереженні. Він не дорівнює довільному збільшенню оцінки на відсоток. Умова запускає його, власник має право прийняти наступне рішення, а вплив на мету записаний.

21.11. Shape Up: часовий апетит — межа дизайну, а не передбачення

У Shape Up «апетит» означає, скільки часу команда вважає доцільним витратити на ідею; оцінка, навпаки, намагається порахувати вже задумане рішення. Автори описують це як «спочатку час — потім дизайн» і як роботу з фіксованим часом та змінним обсягом. Це корисно, коли власник ставки погодив, що можна скоротити, якщо виявляться складнощі; воно не надає виконавцю права самостійно видаляти обов’язкові вимоги. Shape Up, “Set Boundaries”, переглянуто 26 вересня 2026 року.

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

У практиці Shape Up схема Hill Chart допомагає розрізнити роботу, де ще треба з’ясувати підхід, і роботу, де вже зрозуміле виконання. У тексті цю думку можна записати без графіка:

Область	Стан знання	Наступна корисна дія
Контракт календаря	Ще на підйомі: невідомо, чи безпечне резервування	Перевірити тестову операцію й зафіксувати можливі відповіді
Розширення таблиці	Спосіб зрозумілий, ще не застосований	Підготувати міграцію та доказ сумісності
Відмова після підтвердження	Частина правил відома; компенсація потребує рішення	Власник сервісу погоджує дію підтримки

Hill Chart — спосіб показати стан розв’язання невідомого, а не відсоток готового коду й не точна оцінка строку. Самі автори Shape Up пишуть, що уявного «вже знаю як» недостатньо: підхід має бути перевірений реальною роботою. Shape Up, “Show Progress”, переглянуто 26 вересня 2026 року.

У цієї методики є специфічний контекст: ставки й цикли Basecamp. Не переносіть їх механічно в команду з регуляторними вимогами, зовнішньою датою або системою, яку не можна безпечно зупинити. Механізм circuit breaker (умовний запобіжник проєкту) у Shape Up за замовчуванням пропонує не продовжувати невдалу ставку без переосмислення; це не наказ кинути критичний інцидент або обов’язок завершити фіксований обсяг будь-якою ціною. Shape Up, “The Betting Table”, переглянуто 26 вересня 2026 року.

21.12. Малі партії та координація

DORA (DevOps Research and Assessment — дослідження DevOps та оцінювання) описує малі партії як спосіб швидше одержати зворотний зв’язок, перевірити гіпотези й раніше виправити проблему. У рекомендаціях DORA партія має бути незалежною настільки, щоб її можна було перевірити окремо; збирати багато малих частин у пізню велику поставку — протилежність задуму. Джерело також застерігає, що прискорене створення великого коду з допомогою штучного інтелекту робить перегляд та інтеграцію важчими. Це висновки DORA з їхньої дослідницької програми, а не гарантія, що кожен маленький коміт поліпшить будь-який проєкт. Книжка Accelerate: The Science of Lean Software and DevOps Ніколь Форсгрен, Джеза Гамбла й Джина Кіма подає дослідження того, які організаційні й технічні практики пов’язані з показниками постачання програмного забезпечення. Ми використовуємо її як дослідницький контекст, а не як гарантію причинного ефекту для окремого плану. IT Revolution, Accelerate, переглянуто 23 вересня 2026 року. DORA, “Working in small batches”, переглянуто 26 вересня 2026 року.

Для плану це означає: спершу побудувати й перевірити тонку, але корисну взаємодію, рано з’єднати межі, а решту поведінки додавати за вимірюваними кроками. Малий набір змінених рядків не є малим релізним ризиком, якщо всі ризики зібрані в одній міграції наприкінці.

Фредерік П. Брукс-молодший у другому розділі The Mythical Man-Month розглядає межі спроб прискорити пізню програмну роботу простим додаванням людей. В опублікованому фрагменті книги Роберта Л. Ґласса цей аргумент переказано через час на навчання нових учасників і складність комунікації. Для плану це дає практичне запитання: хто передаватиме контекст, переглядатиме й об’єднуватиме частини? Це історичне спостереження про людські команди, а не вимірювання продуктивності сучасних агентів. Видавнича сторінка Брукса підтверджує бібліографію та назву розділу; деталі про навчання й комунікацію тут наведені як переказ Ґласса, а не як прямий переказ повного розділу Брукса. Брукс, сторінка видавця; Ґласс, “People,” Fact 3, переглянуто 23 вересня 2026 року.

Коли план передбачає паралельні виконавці, назвіть спільні контракти, порядок інтеграції й особу, яка зводить результат. Віддавайте окремо лише те, що можна перевірити без прихованого рішення від іншого виконавця. Якщо всі паралельні гілки потім чекають на одну людину, черга на огляд чи інтеграцію може зсунути календарне завершення; це ресурсне обмеження фактичного плану, а не автоматично нове ребро логічної залежності.

21.13. Планування в Codex і Claude Code: допомога, не гарантія

Стаття OpenAI Developers від 23 лютого 2026 року повідомляє про нативний режим планування Codex, який допомагає сформувати послідовність кроків для перегляду до змін. Вона також описує цикл довгої задачі: планування, внесення змін, перевірка результату, виправлення й оновлення стану. Це опис продукту й приклад того, як ним користуватися; він не доводить, що згенерований план повний або відповідає політиці конкретної команди. OpenAI, “Run long horizon tasks with Codex”, переглянуто 26 вересня 2026 року.

Документація Anthropic для Claude Code описує Plan mode як режим, де інструмент читає файли й пропонує план без редагування до погодження. Це обмеження режиму зміни файлів, а не перевірка точності аналізу чи схвалення продуктових рішень. Контракт конкретного агента розглядається у главі 46; він уточнює права й обов’язки одного виконавця, а не замінює план системної зміни. Claude Code, “Plan before editing”, переглянуто 26 вересня 2026 року.

Практичний промпт може просити агента спочатку назвати джерела вимог і версію коду, відокремити факт від припущення, виявити клієнтів даних, скласти залежності й назвати доказ кожного етапу. Окремо попросіть позначити незворотні кроки та умову паузи. Потім людина перевіряє, чи не вигадав агент існуючі маршрути, права, назви таблиць або можливості постачальника.

План агента — чернетка артефакту. Він не замінює PRD, ADR, домовлений контракт, огляд архітектури, авторизацію небезпечної дії чи реальний запуск потрібних перевірок. Збережіть рішення і джерела поруч із роботою, а не лише в історії чату, яка може бути недоступною наступному виконавцю.

21.14. Приклад GitHub: критерії, реалізація й постачання

Задача ivanviragine/wade #515 описує збій після завершення планувальної сесії: батьківський процес отримував помилку доступу до файлів і хибно повідомляв, що артефакт відсутній. Задача вимагала розрізнити відсутній файл і заборону читання, зберегти вихідне робоче дерево для відновлення, не змінювати зовнішню задачу під час невдалого збирання та повторно пройти перевірки після повернення доступу.

Пов’язаний запит на злиття (pull request, PR) PR #516 містить проблему, обов’язкову поведінку й критерії приймання, а також підсумок реалізації. У підсумку описано типізоване строге читання стану, збереження недоступного робочого дерева й команду відновлення wade plan --recover, яка повторно перевіряє прив’язку, завершеність, точний вміст, огляд і валідність до зміни стану постачальника. Автор PR повідомляє про проходження 4 446 тестів, 180 цільових тестів і огляд без зауважень, що вимагали б дії на конкретній ревізії.

Порівняння показує три різні рівні:

Рівень	Що видно в цьому прикладі	Що можна стверджувати
Намір і критерії	Помилка доступу має не виглядати як відсутній файл; артефакт зберігається; відновлення повторно перевіряється	Це запитана поведінка задачі #515
Реалізація та звіт	У PR є зміни коду, тестів, інструкцій і опис відновлення; автор зазначає результати перевірок	Гілка PR намагається виконати критерії, а звіт повідомляє про виконані перевірки
Постачання	PR #516 злили в main 25 вересня 2026 року; це підтверджує інтеграцію до репозиторію, але не розгортання для користувачів	Можна стверджувати, що код злитий; не можна стверджувати, що його розгорнули

Злиття є фактом про інтеграцію, а не незалежною перевіркою звіту автора; без відтворюваних команд і ревізії результати тестів лишаються його повідомленням.

Це добрий приклад для планування саме тому, що критерії, код, перевірки та стан PR можна зіставити. Але він не є незалежним аудитом власних тестових результатів автора. Issue та PR перевірено 26 вересня 2026 року; у тексті розрізнено злиття з випуском, адже стан сторінки й подальше розгортання можуть змінитися.

Висновок для власного плану простий: статус «код готовий» не дорівнює «пройшов перевірку», «влитий», «випущений» або «спостережуваний у користувачів». Для кожного твердження потрібен свій доказ.

21.15. Як змінювати план і не стирати історію

Новий факт може змінити порядок робіт, оцінку, обсяг або архітектуру. Запишіть:

1. що саме спостерігли й де це підтверджено;
2. яке припущення або рішення більше не діє;
3. які залежності, користувачі, ризики та докази зачеплено;
4. які варіанти доступні й хто може вибрати між ними;
5. що саме змінилося у плані та з якої ревізії;
6. чи потрібні повторні перевірки для вже готових частин.

Не переписуйте стару версію так, наче команда завжди знала нове. Збережіть стислий журнал рішення: «23 вересня перевірка в тестовому календарі показала, що тайм-аут не повертає ідентифікатор резерву; через це спершу додаємо пошук стану за ідемпотентним ключем, потім змінюємо сценарій повтору». Так команда й огляд можуть відрізнити нове знання від помилки виконання.

Якщо зміна зачіпає ціль або ризик, узгодьте план із власником рішення. Інженер може запропонувати зменшити обсяг або змінити техніку, але не повинен самостійно відмовлятися від юридично потрібної поведінки, захисту даних чи погодженого результату.

21.16. Мінімальний запис, який можна передати іншому виконавцю

Текстовий план може бути коротшим за цю главу. Передача достатня, якщо наступна людина може відрізнити факт від відкритого питання й виконати кроки без здогаду про критичну політику.

Поле	Приклад запису
Мета й межа	Клієнт переносить власне майбутнє бронювання; зміна ціни не входить
Джерела й ревізія	Посилання на критерії приймання, ADR, базову гілку та відповідні тести
Факти / припущення / рішення	Постачальник у тесті підтвердив резервування; тайм-аут потребує окремої перевірки
Етапи й залежності	Після погодження контракту паралельно починаються сумісна міграція й клієнтська робота; серверний сценарій використовує готову міграцію; пілот починається після інтеграції та перевірки обох частин
Доказ для кожного етапу	Результат перевірки контракту, звіт міграції, тести повтору, спостереження пілота
Зупинка й відновлення	Невідомий зовнішній стан переводить спробу в needs_resolution; нові спроби можна вимкнути
Власники рішень	Продуктове правило — власник продукту; часткова відмова — черговий разом із власником інтеграції
Відомі обмеження	Кодову версію можна повернути окремо; створений зовнішній запис потребує звірки
Історія плану	Дата, причина зміни, що переставили або звузили

Не кожному невеликому виправленню потрібен документ на кілька сторінок. Чим більше систем, даних, дозволів, незворотних дій і невідомих, тим більше контексту має пережити разом із роботою. Мінімальний запис — не шаблон для бюрократії, а межа передавання відповідальності.

21.17. Підсумок

План реалізації з’єднує бажану поведінку з послідовністю змін та доказами. Спершу звіряються вимоги, код, дані, контракти й середовище; суперечності та припущення залишають видимими. Область впливу охоплює не лише екран і сервер, а й споживачів даних, дозволи, фонові процеси, зовнішні сервіси й підтримку.

Кожен суттєвий етап має результат, передумову, доказ, умову продовження та відповідального. Міграція схеми, сумісність старої й нової версій, випуск, спостереження та відновлення описуються окремо. Після нового факту план змінюється з причиною й наслідками, не переписуючи історію невизначеності.

Shape Up допомагає думати про часовий апетит і невідоме; дослідження DORA — про коротші партії та зворотний зв’язок; досвід Брукса нагадує враховувати координацію. Жодна з цих ідей не перетворює термін на гарантію. Режим планування в кодовому агенті може запропонувати шлях, але не підтвердить сам собою продуктове рішення, сумісність, коректність даних чи готовність до випуску.

Джерела

1. Basecamp, Shape Up, Chapter 3: Set Boundaries, без дати оновлення; переглянуто 26 вересня 2026 року. Визначення appetite, різниця між ним і оцінкою, межа фіксованого часу та змінного обсягу.

2. Basecamp, Shape Up, Chapter 8: The Betting Table, без дати оновлення; переглянуто 26 вересня 2026 року. Контекст ставки на обмежений цикл і circuit breaker; практика Basecamp не подається як обов’язкова для всіх команд.

3. Basecamp, Shape Up, Chapter 13: Show Progress, без дати оновлення; переглянуто 26 вересня 2026 року. Hill Chart як спосіб показати невідоме, рух до визначеного рішення й завершення.

4. DORA, Working in small batches, сторінка востаннє оновлена 8 грудня 2025 року; переглянуто 26 вересня 2026 року. Аргументи про зворотний зв’язок, перевірювані партії, роботу з допомогою штучного інтелекту та ризик пізно зібраних змін.

5. AWS Prescriptive Guidance, Migrating business logic from the database to the application layer, без дати оновлення на сторінці; переглянуто 26 вересня 2026 року. Поради щодо сумісності під час співіснування версій, перемикачів функції та процедур відновлення в контексті декомпозиції баз даних AWS.

6. Google Cloud, Use a deployment strategy, сторінка востаннє оновлена 24 вересня 2026 року; переглянуто 26 вересня 2026 року. Механіка поступового канаркового випуску та підтримка відкату в Cloud Deploy.

7. OpenAI Developers, Run long horizon tasks with Codex, стаття від 23 лютого 2026 року; переглянуто 26 вересня 2026 року. Описує режим планування та робочий цикл Codex як характеристику продукту й рекомендацію постачальника, не незалежну оцінку точності планів.

8. Anthropic, Claude Code: Plan before editing, поточна документація Claude Code; переглянуто 26 вересня 2026 року. Описує режим плану як читання й пропозицію кроків до дозволу редагувати; не є свідченням правильності згенерованого плану.

9. ivanviragine/wade, Issue #515 та Pull Request #516, перевірено 26 вересня 2026 року. Issue визначає критерії, PR описує реалізацію й звіти перевірок, а запис GitHub API підтверджує злиття в main 25 вересня. Результати тестів повідомлені автором; джерело не підтверджує випуск у продуктивне середовище.

10. Addison-Wesley Professional, The Mythical Man-Month: Essays on Software Engineering, друге видання, опубліковане 2 серпня 1995 року. Сторінка видавця містить зміст із назвою розділу 2; повний текст розділу в цьому дослідженні не читався.

11. Robert L. Glass, Facts and Fallacies of Software Engineering, “People,” Fact 3, опублікований фрагмент InformIT від 22 листопада 2002 року; переглянуто 26 вересня 2026 року. Переказує закон Брукса й називає час на введення нових людей у курс справ та ускладнення комунікації. Використано як вторинний виклад, а не як першоджерело.

12. IT Revolution, Accelerate: The Science of Lean Software and DevOps, книга Ніколь Форсгрен, Джеза Гамбла й Джина Кіма, видана у 2018 році; сторінку видавця переглянуто 23 вересня 2026 року. Використано для ідентифікації книги й дослідницького контексту; конкретні практики у главі підтверджено сучасною сторінкою DORA.

Межі висновків. Shape Up і AWS описують власні методики та контексти. DORA повідомляє про зв’язок практик із результатами в межах своєї дослідницької програми; це не гарантує результат окремої функції. Документація Codex і Claude Code — джерела поведінки конкретних продуктів. PR #516 злили в main, але її тести й огляд наведені зі звіту автора й не підтверджують розгортання. Приклад бронювання вигаданий; усі його продуктові правила є умовами вправи, а не фактами про реальний сервіс.