Такс, команду зібрали 🤖🫡

Тепер їм треба дати підхід до роботи і скоординувати їх так, щоб не перетворити проєкт на слоп і хаос. І тут якраз з’являється одна з ключових ідей BMAD Method — дотримання 4 фаз Agile-розробки. Головне правило: жодна наступна дія не починається без затвердженого документа з попередньої фази. (привіт, waterfall🌊)Але в контексті роботи з ШІ це має сенс, бо ці документи — це не просто “документи заради документів”. Це спосіб зберігати контекст і не давати агентам вигадувати все з голови. Ось як виглядає цей шлях 👇1️⃣ Фаза 1: Аналіз (Analysis) 🔬

На цьому етапі ви працюєте з Аналітиком, щоб провести мозковий штурм, дослідити ринок або технічні деталі майбутнього проєкту. Результат фази — базовий бриф проєкту (Project Brief) або документ PRFAQ.2️⃣ Фаза 2: Планування (Planning) 📋

Підключається Продакт-менеджер, який перетворює короткий бриф на чіткий PRD (Product Requirements Document) — повноцінний документ із вимогами до продукту. Якщо у продукту є візуальний інтерфейс, на цьому етапі також проєктується UX-дизайн.3️⃣ Фаза 3: Проєктування (Solutioning) 🏗

Час для Архітектора. Він розробляє детальну технічну архітектуру системи. Важливий нюанс методології: тільки після затвердження архітектури загальні вимоги розбиваються на великі модулі (Епіки) та дрібні задачі для розробника (User Stories). Це потрібно для того, щоб кожна задача була не просто “зроби мені фічу”, а вже враховувала обрану архітектуру, технології та технічні обмеження.4️⃣ Фаза 4: Імплементація (Implementation) 💻

І лише тепер ШІ-Розробник береться за написання коду. Робота йде ітеративно та сфокусовано — крок за кроком, окремо по кожній User Story. Після імплементації фічі інший агент обов’язково проводить code review. Що маємо на виході і чому це круто? Власне, самі артефакти📚

Після кожної фази маємо окумент, який стає прямою інструкцією і збереженим контекстом для наступного етапу. Завдяки цьому наступний ШІ-агент не починає роботу з чистого аркуша і не вигадує функціонал з голови. Він діє в межах затвердженого контракту. І от саме це, на мою думку, дуже важливо в AI-driven development. Бо коли немає контракту, немає контексту і немає чіткої послідовності, ШІ дуже швидко починає робити “ну я так зрозумів”.#AINativeBA #SDLC