Для того, щоб отримати веб-сайт потрібно сформувати вимоги до цього сайту. Що там має бути? Чи є там реєстрація? Які активні елементи і що за функції вони виконують? Звучить ніби просто: хочу кнопку Реєстрація. Що не зрозуміло? Але за кожною кнопочкою є питання. Це реєстрація з реферальною ссилкою? Які дані неохідні від користувача – тільки пошта і пароль чи ще номер телефону? Чи є інтеграція з сторонніми сервісами, наприклад: login with Google account і т.д.? Чому на дизайнах є лише кнопка логіну, а де інші елементи? Ряд маленьких патань, які відстрочують бажану реєстрацію.
В ІТ вимоги - це як фундамент будинку. Чим правильніше його закласти, тим краще буде стояти будинок. І навпаки, якщо зробити на тяп-ляп – чекай тріщину. Якщо у вас часто виникає багато питань, і особливо типових питань, до задач, які знаходяться на стадіх розробки – це проблема. Один із інструментів, якими ви можете скористатись для її вирішення - це DoR.
Definition of Ready (DoR) – перелік вимог, за якими можна визначити чи «готова» задача до розробки. Тобто, це як чекліст у пілотів літака перед злітом/посадкою. Перед тим, як підняти літак у небо чи посадити на землю пілот має упевнитись, що все працює/передає необхідні дані і т.д. DoR може відрізнятись від проекту до проекту та від типу задач. Для того щоб створити цей документ необхідно вислухати тих, хто створює User Story – бізнес-аналітики, продукт оунери, тих, хто робить дизайн – технічний: тех.ліди, архітектори, UI/UX: дизайнер, ну і звичайно відповідальних за якість – тестувальників. Зібравши фідбек з членів команди, що кожному з них критично необхідно мати в задачі – ви сформуєте DoR.
В інтернеті багато прикладів використання різних моделей типу SMART чи INVEST. Але я люблю прості практичні приклади від себе, тому нижче приклад DoR для User Story, який ви можете використати:
Задача має бути повною та несуперечливою.
Для задач, в яких змінюється/додається UI має бути додано клікабельний прототип.
У разі необхідності інтеграції з стороннім сервісом, в задачі має бути представлені технічна документація цього сервісу.
В задачі мають бути присутні шаблони/прототипи артефактів (наприклад, інвойси, шаблони листів і т.д.)
В задачі має бути присутній апрув від замовника.
У разі додавання нових термінів у задачі має бути присутня лінка на глосарій.
У разі необхідності виконати підрахунки, в задачі має бути присутня формула і приклад розрахунку.
Цей список можна ще продовжити. Ви маєте вибрати/дописати все, що потрібно саме вам і так у вас з’явиться DoR. На одному з моїх проектів DoR було просто спасінням. Це скоротило час передачі задачі до розробки, і тим самим пришвидшило поставки результатів замовникам і кінцевим корситувачам. Також, для кожного типу задач може бути свій список. Так для Tech Story чи Sub-task може бути свій набір параметрів і своє коло зацікавлених. Всім успішних проектів!
