Почніть новий продукт у Taiga

Підготуйте один чіткий результат

Цей сценарій використовує вигаданий сервіс запитів на обладнання. Менеджер записує запит працівника на обладнання та рішення. Самообслуговування працівників — подальше розширення. Під час навчання використовуйте синтетичні записи. Сценарій не дозволяє використання справжніх кадрових даних.

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

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

Виберіть спосіб початку продукту

Виберіть Start from scratch для цього нового сервісу. Використовуйте Import codebase, коли наявний репозиторій має визначати початкову точку. Імпорт вибирають під час створення продукту, тому ухваліть це рішення свідомо.

Під час створення також потрібно вказати, чи Taiga пише Infrastructure code та CI/CD pipelines. Це окремі обов’язки. Якщо команда платформи вже надає певну частину, вимкніть відповідне генерування та опишіть, як ця робота виконується зараз.

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

Додайте контекст до початку розмови

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

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

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

Перегляньте та опублікуйте намір

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

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

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

Підключіть реальне цільове середовище доставки

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

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

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