Критерії прийнятності для написання критеріїв прийняття

Критерії прийнятності для написання критеріїв прийняття

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

Спочатку давайте швидко визначимо критерії прийнятності.

Критеріями прийнятності є "умови, яким повинен відповідати програмний продукт, щоб бути прийнятим користувачем, замовником або іншими зацікавленими сторонами". (Microsoft Press)

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

Як виглядають ці умови? Хто створює ці умови? Скільки має бути умов? Як вимірюються результати?

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

Однак написання критеріїв не лише відповідальність власника товару. Критерії прийнятності повинні розроблятися як спільні зусилля між розробником та власником товару.

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

Форматування критеріїв прийнятності

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

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

З іншого боку, сценарії, орієнтовані на критерії, як правило, відповідають шаблону «Дано ... Коли ... Тоді ...». Це було отримано на основі поведінкового розвитку (BDD). Ця вимога окреслює очікуваний спостережуваний результат. Це відбувається, коли певна дія виконується з урахуванням певного контексту.

3 характеристики ефективних критеріїв прийняття

1. Тестується з чітко визначеними результатами проходження / відмови

Є критерії, що перевіряються. Це дозволяє тестерам належним чином підтвердити, що всі бажані умови виконані. Якби критерії не перевірялися, тоді не було б можливості для перевірки. Ці критерії повинні бути виконані або не виконані. Розробник повинен знати момент досягнення критерію. Будь-яка двозначність може продовжити зусилля щодо історії.

Наприклад, критерій прийнятності говорить “збільшити кількість записів, доступних у спадному меню”. Розробник не мав уявлення, скільки нових записів додати, і може взяти на себе свободу прийняти число, виходячи зі свого досвіду роботи з продуктом. Подібним чином, ручний тестер може взяти ту саму свободу і прийняти інше визначення збільшення. Це призводить до плутанини, яка повернеться до власника товару.

2. Однозначний і лаконічний

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

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

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

3. Встановіть спільне взаєморозуміння

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

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

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

Коли занадто багато - це проблема

Ми вже вивчали небезпеку незрозумілих критеріїв прийняття. Це призводить до ризику введення сторонніх особливостей в історію. Однак може існувати і дивовижний протилежний випадок: критерії прийняття можуть стати надто детальними.

"Критерії прийняття повинні містити намір, а не рішення" ( Segue Technologies )

Надайте проект "що" (намір) замість "як" (реалізація). В іншому випадку команда розробників може бути позбавлена ​​можливості дослідити різні шляхи вирішення проблеми. У цих рядках, кращі реалізації можуть бути придумані після початкових роздумів про рішення.

Після того, як ви написали свої критерії прийняття, ви можете запитати себе: "Скільки це занадто багато?"

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

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

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

Що тепер?

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

Я вважаю, що не існує “правильного” формату написання критеріїв прийняття. Їх правильність вимірюється ефективністю роботи в команді.

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

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

Більше читати

  • //rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important - Марина З. та Дмирій Г.
  • //www.leadingagile.com/2014/09/acceptance-criteria/ Стіва Повілайтіса
  • //www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ від Segue Technologies
  • //agileforgrowth.com/blog/acceptance-criteria-checklist/ - Камлеш Равлані