Графи залежностей: що можна робити паралельно

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

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

Після розділу читач може:

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

20.1. Вузол, ребро і напрямок

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

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

A → B означає: робота B потребує результату A.

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

Передумова	Наступна робота	Що саме вона чекає
Власник рішення підтвердив умови скасування	Команда реалізує правило	Дозволені статуси, часову межу, наслідок для користувача
Погоджено формат відповіді маршруту	Сервер і клієнт реалізують свої частини	Назву поля, можливі стани та форму відмови
Видано доступ до тестового календаря	Інтеграційна перевірка	Повноваження для реального запиту в тестовому середовищі
Перевірено сумісну міграцію	Безпечне розгортання схеми	План переходу, поведінку старої версії й спосіб відновлення

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

Prerequisite (передумова) — результат, потрібний, щоб почати або прийняти роботу. Dependency (залежність) — зв’язок між частинами; blocker (блокер) — перешкода, що зараз затримує одну з них. Наприклад, доступ до календаря є залежністю його інтеграційної перевірки й лишається її блокером, доки доступу немає. Перегляд бронювання може рухатися без нього, якщо перенесення відкладене.

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

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

Prerequisite можна перекласти як передумову: вона потрібна, щоб почати або прийняти певну роботу. Dependency — залежність: назва зв’язку між частинами. Blocker — блокер: поточна перешкода, через яку визначена робота не може просунутися. Ці поняття пов’язані, але не тотожні. Наприклад, доступ до постачальника є залежністю для перевірки його середовища; поки доступ не надано, він є її блокером. Маршрут перегляду бронювання може не залежати від цієї перевірки, якщо перенесення запису відкладене.

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

20.2. Напрямок — це не календар

Зв’язок не завжди забороняє почати B до завершення A. З’ясуйте, який саме вихід A потрібен, на якому етапі — для старту, огляду, перевірки чи випуску — і хто надасть його та підтвердить готовність. Попередній контракт або заглушка можуть дозволити почати роботу раніше, але не замінять подальшої перевірки з реальним постачальником.

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

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

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

Для кожного зв’язку спитайте:

• Який конкретний вихід A потрібен B?
• Чи достатньо попереднього контракту або тестового сценарію, щоб почати частину B?
• На якому кроці залежність стає обов’язковою: перший рядок, огляд, перевірка чи випуск?
• Хто може надати відсутнє рішення або доступ?
• Яким спостереженням підтвердимо, що передумову виконано?
• Чи може B бути перевірена із заглушкою, а потім обов’язково з реальним постачальником?

20.3. Орієнтований граф без циклів

Коли кожна стрілка спрямована від передумови до її споживача, мережа має назву DAG (Directed Acyclic Graph — орієнтований ациклічний граф). «Орієнтований» означає, що ребро має напрямок; «без циклів» — що, проходячи за стрілками, неможливо повернутися до того самого вузла.

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

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

Якщо схема має тверді стрілки A → B та B → A, перевірте джерело кожної: можливо, обидві частини чекають на третє спільне рішення. Приклад із формою й API розібрано в §20.10.

Якщо схема має тверді стрілки A → B та B → A, не виправляйте її безкінечним переприсвоєнням статусів. Перевірте джерело обох стрілок. Наприклад, клієнтська форма може чекати на API-помилку, а розробник API — на остаточний текст форми. Можливо, обидві частини насправді чекають на третій вузол: рішення про спільні стани і форму помилки.

20.4. Розгалуження, збирання і власник інтеграції

Одне рішення може відкрити кілька незалежних шляхів. Це розгалуження (fan-out): після погодження схеми окремо починаються робота над збереженням, серверним контрактом і текстом помилки. Кілька гілок можуть зійтися в одному результаті — це збирання (fan-in): інтеграційна перевірка потребує всіх частин, які складають сценарій.

Момент	Передумова	Роботи після неї	Що відкриває збирання
Розгалуження	Узгоджено контракт відповіді	Реалізація сервера; підготовка клієнта; оновлення документації	Узгоджений кандидат кожної потрібної частини
Збирання	Сервер і клієнт готові за спільним контрактом	Інтеграційна перевірка	Фактична відповідь сервера й поведінка клієнта разом
Розгалуження з доступом	Надано обліковий запис тестового постачальника	Перевірка запису; перевірка тайм-ауту; аналіз повтору	Погоджений висновок про реальне середовище

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

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

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

20.5. Критичний шлях, тривалість і резерв часу

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

CPM (Critical Path Method — метод критичного шляху) формалізує обчислення ранніх і пізніх дат та запасу часу. PMI (Project Management Institute — Інститут управління проєктами) описує критичну діяльність як таку, що не має загального запасу часу; затримка такої діяльності затримує планове завершення. Тут наведемо ручне спрощене обчислення, не повну модель великого календарного плану.

Для арифметики припустимо, що спільний контракт API (Application Programming Interface — програмний інтерфейс взаємодії) погоджено до початку відліку. Це рішення не входить у наведені тривалості. У графі A — сумісна схема збереження даних, B — серверний API, C — клієнтський інтерфейс, D — інтеграційна перевірка. B потребує A; C може початися за вже погодженим контрактом паралельно з A та B; D чекає на B і C.

Вузол	Результат	Передумова	Оцінка тривалості
A	Підготовлено сумісну схему збереження даних	Немає	1 робочий день
B	Реалізовано серверний API за погодженим контрактом	A	3 робочі дні
C	Показано бронювання у клієнтському інтерфейсі за контрактом	Контракт погоджено до початку відліку	2 робочі дні
D	Перевірено інтегрований сценарій, включно з доступом	B і C	1 робочий день

Ранній календар у робочих днях буде таким:

Вузол	Найраніший початок	Найраніше завершення	Пояснення
A	0	1	Підготовка схеми
B	1	4	Чекає на сумісну схему A
C	0	2	Контракт уже погоджено; клієнт може почати паралельно
D	4	5	Чекає на сервер B і клієнт C

Є два основні ланцюги:

• A → B → D: 1 + 3 + 1 = 5 робочих днів;
• C → D: 2 + 1 = 3 робочі дні.

Отже, критичний шлях — A → B → D, а найраніше завершення — день 5. Клієнтська гілка C має два робочі дні резерву до збирання D. Навіть за узгодженого контракту ребро A → B залишається: серверна реалізація в цьому прикладі не може завершитися раніше за схему.

Прискорення A з одного дня до пів дня так само скоротило б критичний шлях на пів дня, якщо B і D не зміняться. Скорочення C з двох днів до одного дати не змінить: через два дні резерву інтеграція все одно чекатиме на B до дня 4. Це арифметика за заданими оцінками, не підстава жертвувати якістю API.

Резерв і невизначені оцінки

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

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

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

20.6. Два порядки для тієї самої роботи

Порівняймо дві організації тих самих чотирьох робіт. Вузол A — фізична схема збереження даних, а не рішення про контракт. Тривалості A, B, C та D дорівнюють відповідно 1, 3, 2 та 1 робочому дню.

Без погодженого API-контракту цей навчальний варіант ставить A, B, C і D послідовно: схема, сервер, клієнт, інтеграція — разом 7 робочих днів. Тут клієнт чекає на фактичну відповідь сервера; це обране припущення, а не неминучий наслідок відсутності контракту. З контрактом, узгодженим до старту, клієнт C починається паралельно з A і B, тож критичний шлях A → B → D лишається п’ять днів. Порівняння дає два потенційно виграні дні, але не прибирає фізичну залежність B від схеми A: контракт не створює потрібних даних, а сервер не завжди можна підготувати без міграції.

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

Без погодженого API-контракту. У цьому навчальному варіанті команда послідовно готує схему A, реалізує сервер B, після його фактичної відповіді будує клієнт C, а потім перевіряє інтеграцію D. Такий обраний порядок A → B → C → D займає 1 + 3 + 2 + 1 = 7 робочих днів. Це не єдина можлива поведінка команди; приклад показує вартість конкретного припущення, що клієнт має чекати на реалізацію сервера, перш ніж зафіксувати поля й стани.

З погодженим контрактом. Рішення про форму відповіді прийняте до початку відліку й не рахується вузлом A або до тривалості схеми. Клієнт C може початися паралельно з A та B. Сервер B все ще потребує схеми A, а інтеграція D — готових B і C. За цими припущеннями критичний шлях A → B → D становить п’ять днів; клієнтська гілка завершується раніше. У порівнянні з послідовним варіантом модель показує два потенційно виграні дні.

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

20.7. Логічні залежності та ресурсні обмеження

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

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

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

Повний приклад спільного рецензента

Усі оцінки в прикладі вигадані. Після затвердження контракту два зміни можна реалізувати паралельно:

Робота	Реалізація	Огляд одним спільним рецензентом
A: тест контракту сервера	1 день	2 дні
B: зміна збереження	2 дні	2 дні
I: спільна інтеграційна перевірка	1 день	Починається після огляду A і B

Відлік і реалізація обох змін починаються в день 0: A готова на день 1, B — на день 2. Один рецензент оглядає A з дня 1 до 3, потім B — з дня 3 до 5; інтеграція триває ще день, тож граф завершується на день 6. Два рецензенти з потрібним контекстом можуть оглянути зміни паралельно, завершити B на день 4 і інтеграцію — на день 5.

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

Відлік починається після контракту. Розробник A завершує код на день 1, B — на день 2. Один рецензент спершу оглядає A у дні 1–3, а потім B у дні 3–5. Точка інтеграції I триває ще день, отже приклад завершується на день 6. Якщо є два рецензенти з потрібним контекстом і вони можуть працювати одночасно, огляд B завершується на день 4; тоді інтеграція завершується на день 5.

Ресурсне обмеження виникає через спільну місткість:

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

20.8. Приховані зв’язки й архітектурне зчеплення

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

У Software Architecture: The Hard Parts зв’язність розглядається як вплив зміни на інші частини системи. Поділ на служби цього не усуває: спільні дані, транзакції, контракти й порядок повідомлень лише переносять зв’язок через мережу. Перш ніж додавати ребро, з’ясуйте, хто читає дані й володіє станом, які версії співіснують, як перевіряються сумісність і відкат та що стається при повторі чи частковій відмові.

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

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

Neal Ford, Mark Richards, Pramod Sadalage та Zhamak Dehghani в Software Architecture: The Hard Parts розглядають зв’язність через вплив зміни на інші частини системи та порівнюють варіанти контрактів. Поділ системи на менші служби не прибирає зв’язок сам собою: спільні дані, транзакції, контракти і послідовність повідомлень можуть перенести його через мережу. Тому до розкладу запитайте не тільки «яка команда володіє цим компонентом?», а й:

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

20.9. Брукс, людська координація та агентна аналогія

Уявімо, що кілька агентів незалежно назвали одні й ті самі стани по-різному: замість паралелізму команда отримала три реалізації та роботу з узгодження. Переказ закону Брукса у фрагменті Роберта Л. Ґласса пов’язує затримку від додаткових людей із часом на навчання та комунікацію. Це спостереження про людські команди, не кількісний закон для ШІ-агентів; докладніше про межу аналогії — у §21.12. Перед розгалуженням спершу погодьте статуси, джерело істини, правила скасування й повернення та спільний контракт помилок і доступу.

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

Спільні й неподільні результати

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

Приклади вузлів, які часто потребують одного власника рішення:

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

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

У The Mythical Man-Month Frederick P. Brooks Jr. застерігає від простого припущення, що додаткові виконавці пропорційно скорочують час програмної роботи. Він розділяє час, потрібний на навчання людей контексту, і витрати на комунікацію та координацію частин. Завдання також мають неподільний фрагмент: визначення спільного поняття, рішення про правило або погодження межі контракту не прискорюється простим дублюванням виконавців.

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

Тут є обмеження аналогії. Brooks описував роботу людей у контексті програмних проектів свого часу. Переносити його спостереження безпосередньо на сучасні агенти штучного інтелекту (ШІ) як кількісний закон не можна. Різняться швидкість навчання, обсяг контексту, спосіб передачі результату й інструментальні обмеження. Використовуйте ідею як питання до плану: скільки нових зв’язків для погодження створить ще один виконавець і як він одержить узгоджене рішення?

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

20.10. Повний приклад циклу: форма чекає на сервер, сервер — на форму

Уявімо, що команда записала дві передумови:

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

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

Треба відокремити спільне рішення про контракт від остаточної реалізації:

Вузол	Результат	Від чого залежить
C: погодити мінімальний контракт	Стани успіху, відсутності бронювання, заборони доступу й помилки; поля даних	Рішення власника продукту та API
A: реалізувати маршрут	Відповіді відповідно до контракту	C
B: зробити екран	Стан інтерфейсу для тих самих відповідей	C
I: перевірити сценарій разом	Фактична сумісність сервера й інтерфейсу	A і B

Тепер немає циклу: C → A, C → B, а A і B сходяться в I. Під час реалізації текст повідомлень може уточнитися; якщо нове рішення змінює контракт, оновіть C і перевірте вплив на обидва споживачі. Не вважайте це доказом, що контракт було не потрібно мати: саме він дав обом частинам робочу початкову межу.

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

20.11. Як оновлювати граф після відкриття невідомого

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

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

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

Оновлення графа:

1. Запишіть факт окремо від припущення. «Постачальник не повертає підсумковий стан після тайм-ауту» — спостереження; «треба переписати інтеграцію» — висновок для перевірки.
2. Назвіть споживачів результату. Які функції чекають на це рішення? Які можуть продовжити роботу?
3. Уточніть тип зв’язку. Потрібен контракт, дозвіл, тестове середовище, ресурс чи лише бажана послідовність?
4. Додайте вузол або змініть ребро. Не сховуйте нову передумову в одному коментарі до старого запиту на зміну.
5. Знайдіть відповідального та доказ. Хто відповідає на питання, і що покаже, що відповідь отримана?
6. Перерахуйте критичний шлях і резерв. Якщо додано роботу чи змінено оцінку, стара дата більше не походить із поточного графа.
7. Повідомте виконавців, яких зміна зачепила. Якщо агент продовжує роботу з попереднім контрактом, його результат може стати витратою на переробку.

20.12. Мінімальний текстовий запис залежностей

Навіть без спеціального засобу планування команда може вести короткий запис:

Поле	Що записати
Вузол і результат	Короткий ідентифікатор та завершувана робота
Передумова й тип зв’язку	Результат, рішення, доступ, контракт, ресурс або бажаний порядок; зазначте «немає», якщо передумови немає
Готовність	Спостереження, що підтверджує передумову
Виконавець	Хто відповідає за результат
Ресурс	Спільна людина, середовище чи постачальник
Паралельність	Що можна почати, що мусить чекати до перевірки
Інтеграція	Хто з’єднує частини та за яким сценарієм
Невизначеність	Діапазон тривалості й причина, якщо це допомагає рішенню

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

Вузол	Передумова	Можна почати	Коли готовий
A: сумісна схема збереження	Підтверджене правило доступу	Після рішення власника; паралельно з C	Міграція перевірена на старій і новій версіях
B: серверний API	A; погоджений контракт відповіді	Після A	Маршрут відповідає контракту й перевіряє власника
C: клієнтський інтерфейс	Погоджений контракт відповіді	Може початися паралельно з A і B	Позитивний, порожній та помилковий стани показані без витоку
D: інтеграція	B і C	Після обох кандидатів	Спільний сценарій пройшов на зв’язаних частинах

Для A, B, C і D у цій таблиці відповідно видно перевірку міграції на старій і новій версіях, відповідність API контракту й перевірку власника, показ позитивного/порожнього/помилкового станів без витоку, а також проходження спільного сценарію на з’єднаних частинах. Повні поля плану реалізації наведено в §21.16; цей запис потрібен лише для передумов, ресурсів і точки інтеграції.

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

20.13. Відкритий приклад графа GitHub Actions

У закріпленому за commit файлі test.yml FastAPI вузол changes перевіряє змінені шляхи; роботи test і benchmark залежать від нього, а test розгортає матрицю операційних систем, версій Python і наборів залежностей. Так спільний попередній вузол розгалужується на кілька перевірок, а одна робота — на варіанти матриці. Це реальний приклад технічного графа перевірок CI, не граф розробки продуктового сценарію або внутрішній календар FastAPI.

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

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

20.14. Запуск агентів за графом, а не за кількістю слотів

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

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

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

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

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

Офіційна документація OpenAI Multi-agent рекомендує віддавати паралельним агентам незалежні обмежені задачі з чітким питанням і результатом; це рекомендація конкретного засобу оркестрації, а не доказ, що паралельність завжди пришвидшує команду.

20.15. Коли граф потрібно замінити або доповнити

Граф показує логічну послідовність, але інші проблеми можуть вимагати окремих рішень та обліку ресурсів:

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

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

20.16. Підсумок

Граф іде від передумови до роботи-споживача й показує розгалуження, точки збирання, критичний шлях і резерв, але не охоплює сам собою ресурсні черги. Рецензент, тестове середовище, доступ, постачальник і контекст людей можуть створити окремі ресурсні чи організаційні обмеження. Цикл часто вказує на пропущене спільне рішення або неправильно сформульовану вимогу до старту й завершення; назвіть потрібне рішення до паралельної роботи. Коли з’являється нова залежність, оновіть граф, оцінку та очікування зачеплених виконавців. Перед запуском звірте передумови, ресурси, спільні файли, інтеграційного власника й доказ завершення. Моделі Брукса та Team Topologies допомагають говорити про координацію людської роботи, але їх перенесення на ШІ-агентів лишається аналогією, не законом. Глава 21 збирає ці рішення в план реалізації.

Джерела та подальше читання

Матеріали перевірено 23 вересня 2026 року; актуальні приклади та документацію повторно звірено 26 вересня. Усі дні й оцінки у прикладах вище вигадані. Перенесення принципів планування на ШІ-агентів позначене як навчальна інженерна аналогія.

1. Ryan Singer, Shape Up: Stop Running in Circles and Ship Work that Matters, вебкнига Basecamp; переглянуто 23 вересня 2026 року. Прочитано главу 12: Map the Scopes. Автор розглядає межі scope (окремої області роботи) як те, що виявляється з реальних зв’язків роботи, а не лише з ролей виконавців; межі можуть уточнюватися в процесі.
2. Neal Ford, Mark Richards, Pramod Sadalage і Zhamak Dehghani, [Software Architecture: The Hard Parts, розділ 2: Discerning Coupling in Software Architecture](https://www.oreilly.com/library/view/software-architecture-the/9781492086888/ch02.html) та [розділ 13: Contracts](https://www.oreilly.com/library/view/software-architecture-the/9781492086888/ch13.html), O’Reilly Media, жовтень 2021 року; переглянуто 23 вересня 2026 року. Використано доступний видавничий попередній перегляд і зміст розділів про зв’язність, контракти та розподілені процеси; повний текст книги тут не читали. Приписані цим розділам теми підтверджені змістом і видавничим preview, а приклади в главі є навчальним синтезом.
3. Scott W. Kramer і James L. Jenkins, “Critical path method calculations: Understanding the basics of CPM calculations”, матеріал PMI Global Congress 2006—North America; переглянуто 23 вересня 2026 року. Пояснює залежності, тривалості, ранні й пізні дати, запас часу та критичний шлях. Цей навчальний розділ використовує спрощений ручний приклад, не повне календарне планування.
4. GitHub, Using jobs in a workflow, поточна документація GitHub Actions; переглянуто 26 вересня 2026 року. Описує передумови jobs через поле needs, а також поведінку наступних робіт після помилки чи пропуску залежності.
5. FastAPI contributors, файл перевірок test.yml, відкритий файл конфігурації автоматизації у репозиторії FastAPI; переглянуто 26 вересня 2026 року; посилання закріплене за commit 50113da16fec53b66b80d75e80a89296de4fa5a5. Показує, що роботи test і benchmark очікують завершення changes, а test запускає матрицю комбінацій середовища. Це доказ конфігурації конкретного відкритого репозиторію на час перегляду, не загальний граф розробки проєкту.
6. Matthew Skelton і Manuel Pais, Team Interaction Modeling with Team Topologies, офіційний матеріал Team Topologies; дату оновлення сторінки не вказано; переглянуто 23 вересня 2026 року. Описує співпрацю, надання можливості «як сервіс» і фасилітацію як режими взаємодії команд, а також обговорює когнітивне навантаження. Ці організаційні моделі не є прямим алгоритмом планування вузлів програмної задачі.
7. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 20-те ювілейне видання 1995 року; переглянуто 23 вересня 2026 року. Переглянуто бібліографію видавця й легальну 22-сторінкову вибірку видавничих сторінок із змістом книг і розділів. Повного розділу «The Mythical Man-Month» тут не читали; посилання на аргумент про навчання й координацію є обережним нагадуванням про концепцію книги, не оцінкою сучасних команд або агентів.
8. Atlassian Support, Link work items та Create or remove dependencies on your timeline, документація Jira Cloud; переглянуто 23 вересня 2026 року. Розрізняє посилання «blocks/is blocked by» та залежність на часовій шкалі, де передумова має завершитися до початку наступної роботи; адміністратор може конфігурувати доступні типи посилань.
9. OpenAI, Multi-agent, поточна документація OpenAI Agents API; переглянуто 26 вересня 2026 року. Рекомендує паралелити незалежні задачі з чітким результатом, залишати залежні кроки координатору та погоджувати роботу агентів над спільними файлами. Це документація поведінки продукту й рекомендація постачальника, не незалежний вимір прискорення.
10. Robert L. Glass, “People,” Facts of Software Engineering Management, InformIT, 22 листопада 2002 року; переглянуто 26 вересня 2026 року. У фрагменті з книги Facts and Fallacies of Software Engineering переказано закон Брукса та пояснено витрати на навчання нових учасників і комунікацію в людській команді. Це вторинний виклад, не твердження про продуктивність ШІ-агентів.