Agile in it 8 методів декомпозиції задач
Agile in IT: 8 методів декомпозиції задач
Як же провести декомпозицію вимог в Product Backlog? Розглянемо 8 технік, які допоможуть ефективно виконати розбивку вимог на User Stories. У роботі по Agile великим плюсом буде одночасне застосування декількох варіантів декомпозиції, тому важливо представляти спектр можливих методів.
Зупинимося на цих моментах трохи докладніше. Розробка ПО досить непередбачуваний процес і містить багато завдань і залежностей, які важко точно оцінити заздалегідь. Цілком природно, що в процесі реалізації якісь вимоги зажадають більше часу, ніж прогнозувалося спочатку. Вплив на реліз великих і дрібних завдань в цьому випадку буде різним:
- Якщо в рамках ітерації (спринту) ми працюємо над кількома великими і складними завданнями, то, по-перше, такі завдання буде складно оцінити з високою точністю, по-друге, недооцінка навіть однієї з них може сильно вплинути на досягнення цілей спринту. Адже не випустити 1 з 2 запланованих фич, це відразу -50% корисного результату.
- Дрібні і атомарні завдання навпаки мають не такий серйозний вплив на цілі спринту, так як їх більше планується на спринт (а значить кожна має менший внесок) і їх оцінка буде набагато точніше.
Декомпозицію завдань можна проводити як на початку чергового спринту при його плануванні, так і під час спринту, виконуючи розбивку вимог для наступних ітерацій. Другий варіант кращий. Краще не прив'язувати декомпозицію задач до конкретного спринту, щоб приходити до його планування з уже готовим, розбитим на призначені для користувача історії беклогом. В цьому випадку, якщо є запас декомпозіровать вимог, то:
- По-перше, ми не обмежуємо вибір завдань для спринту (можемо працювати тільки над тим, що декомпозіровать).
- По-друге, при плануванні вже не потрібно витрачати час на розбивку і команда може зосередитися на формуванні спринту виходячи з пріоритетів, обговорити залежності і нюанси реалізації вимог.
Існує дві концепції, два базові підходи до декомпозиції великих завдань на призначені для користувача історії - «горизонтальне» і «вертикальне» розбиття:
- У разі «горизонтальної» декомпозиції, завдання розбиваються на кшталт роботи (функції), яку необхідно виконати, по компонентам, які задіяні в роботі. В цьому випадку при розбитті загальної великого завдання розробнику буде виділена одна частина, тестувальників інша, технічного письменнику третя і так далі. Фактично кожна з частин не приводить до кінцевого результату сама по собі, щоб випустити готовий функціонал, необхідна реалізація всієї сукупності пов'язаних завдань усіма учасниками процесу.
- «Вертикальний» метод декомпозиції навпаки передбачає виділення дрібніших завдань, фич, функцій таким, чином, що кожна така призначена для користувача історія може бути реалізована і випущена окремо від інших завдань. При цьому в розробку можуть бути залучені різні ролі, можуть бути задіяні кілька модулів і систем.
Розбиття задач з використанням «вертикального» методу більше відповідає Agile принципам і його застосування набагато більш ефективним, основні причини в наступному:
- При «вертикальному» розбитті кожна задача може бути реалізована, протестована і продемонстрована замовнику \ користувачам, будучи для них зрозумілою і вимірної на відміну від «технічних» завдань при «горизонтальної» декомпозиції.
- При «вертикальної» декомпозиції кожна кінцева призначена для користувача історія несе в собі цінність для бізнесу, а значить такі завдання простіше порівнювати і пріоритезувати.
- Оскільки в реалізації завдань, які розбиті по «вертикальному» принципом беруть участь фахівці різних ролей, то їм простіше виявити можливі складнощі, залежно та ризики, які можуть виникнути в процесі роботи.
Тепер, коли з необхідністю і принципами декомпозиції все ясно, розглянемо різні методи розбиття великих завдань беклога на атомарні призначені для користувача історії. В усіх цих випадках і техніках застосовується принцип «вертикальний» декомпозиції.
Метод 1: Розбиття по етапах \ фаз бізнес процесу.
Використовуючи цей метод можна спробувати розбити велику задачу, яка описує якийсь бізнес процес на складові частини і етапи. Для цього в даному процесі необхідно виділити послідовну ланцюжок кроків. які можуть бути реалізовані і виконані незалежно один від одного. В якості пояснення цього методу декомпозиції можна навести такий приклад:
В результаті ми розбиваємо великий бізнес процес на складові його етапи. Якісь етапи при цьому можуть бути критичними і обов'язковими, а якісь опциональнимі. Така декомпозиція дає можливість:
- По-перше, визначити різні пріоритети для кожної історії і зосередитися в першу чергу на найважливіших для бізнесу етапах.
- По-друге, при такому розбитті краще зрозумілий сам процес, його кроки і складові частини, можливі залежності меду етапами.
Метод 2: Розбиття по позитивним і негативним сценаріями.
Фактично кожна функціональність має правильний \ прямий сценарій використання, який призводить до очікуваного \ позитивного результату. Однак, коли користувач працює з тих чи інших функціоналом можуть відбутися відхилення від правильного процесу: передані не ті дані, виконані не всі обов'язкові умови, немає необхідних прав доступу і т.п. Такі відхилення від прямого сценарію роботи приведуть до негативних результатів (дія не виконається, функція відпрацює некоректно і т.п.).
Відповідно ми можемо виконати декомпозицію на очікуваний сценарій використання функціоналу і на неправильні, але можливі і ймовірні сценарії роботи. Для кожного сценарію важливо виділити окремі призначені для користувача історії:
- Для позитивного - реалізація належного функціонування функціоналу.
- Для негативних - реалізувати правильну відпрацювання тієї чи іншої можливої помилки, розробити альтернативний сценарій.
Як приклад декомпозиції вимог на позитивні \ негативні сценарії знову розглянемо функцію покупки в інтернет магазині:
Подібний тип декомпозиції дозволяє виділити, проаналізувати і запланувати відпрацювання різних виключень і невірних сценаріїв використання ПЗ, які в будь-якому випадку будуть виникати.
Метод 3: Розбиття за правилами \ умов бізнес процесу.
На відміну від попереднього методу в даному випадку ми розбиваємо процес не на етапи а на логічні гілки, можливі варіанти відпрацювання функціоналу. Фактично ми визначаємо набір сценаріїв, за якими може виконуватися процес при виконанні тих чи інших правил \ умов.
- В якості ілюстрації даного методу декомпозиції візьмемо той же приклад: необхідно реалізувати для клієнта функцію покупки в інтернет магазині.
- В даному випадку ми можемо виділити, наприклад, наступний набір правил для здійснення покупки:
- Визначено мінімальна сума, якщо сума покупки менше, то клієнтові показується відповідна підказка.
- Якщо сума покупки перевищує певне значення, то клієнтові пропонуються додаткові варіанти оплати.
- Якщо виставлений рахунок не оплачений протягом 2 днів, то замовлення автоматично скасовується.
- Реалізацію кожного такого умови, можна винести в окреме завдання
Даний метод розбиття вимог дозволяє:
- Виявити і винести в окрему призначену для користувача історію різні правила і обмеження, які можуть зустрічатися в рамках процесу \ функціоналу. Так менше ризик забути або пропустити якісь важливі умови.
- Як правило реалізація в бізнес процесі тих чи інших умов буде мати різний пріоритет: щось потрібно реалізувати в першій версії продукту, а без чогось певний час можна обійтися. Декомпозиція єдиного процесу за умовами \ правилам дозволить побудувати черговість реалізації окремих користувальницьких історій.
Метод 4: Розбиття за видами операцій.
На прикладі все того ж інтернет магазину можна зробити таку декомпозицію функціональності по роботі з карткою продукту:
Декомпозіруя функціональність таким чином досить легко відповісти на наступні питання:
- Які з операцій є дійсно необхідними для роботи з тим чи іншим об'єктом? Як правило операції пов'язані і не має сенсу реалізовувати, наприклад, створення об'єкта без можливості його переглядати. Однак, виділення операцій дозволить розставити для них пріоритети.
- Яким чином необхідно реалізувати кожну з операцій? Можливо одна і та ж операція повинна бути реалізована кількома способами. В цьому випадку декомпозицію можна продовжити і винести реалізацію кожного із способів в окрему призначену для користувача історію. Наприклад, нам необхідно реалізувати створення нового об'єкта через інтерфейс web-додатки, через панель адміністратора на сайті магазина, шляхом додавання інформації в базу даних і т.д.
Метод 5: Декомпозиція за типами платформи / ОС.
Тут все досить просто - критерієм розбиття вимог на складові частини є необхідність реалізації одного і того ж функціоналу для різних платформ, пристроїв, операційних систем.
Наприклад, нам необхідно розробити в веб-додатку функцію оплати користувачем якийсь покупки. В цьому випадку можна декомпозировать вимога на завдання по реалізації функції покупки:
Розбиваючи вимога таким чином, може досить легко виділити найбільш пріоритетні напрямки для розвитку продукту і сфокусуватися на них в першу чергу. Наприклад спочатку ви можемо зосередитися на розробці мобільної версії додатка, а версію для десктоп залишити для більш пізніх релізів.
Метод 6: Розбиття за типами даних і параметрам.
Для деяких функцій можна можна виділити різні типи даних або параметрів, які вони повинні обробляти. Відповідно, ми можемо розбити велике вимога \ фичу на ряд дрібних користувальницьких історій, в рамках кожної з яких потрібно реалізувати роботу тільки з якимось одним типом даних.
Як приклад можна розглянути функцію пошуку для інтернет-магазину. В даному випадку декомпозиція на підзадачі може бути виконана на основі різних запитів з пошуку, наприклад:
- Пошук з використанням тексту (найменування товару)
- Пошук з використанням числових значень (номер товару)
- Пошук з використанням регулярних виразів
При використанні даного методу декомпозиції ми можемо чітко визначити допустимі і недопустимі параметри для реалізованої функції (наприклад, функції пошуку). В цьому випадку підтримку частини типів даних \ параметрів можна передбачити відразу, а інші можуть бути реалізовані у спрощений спосіб або заборонені до використання.
Метод 7: Розбиття за ролями \ прав доступу.
Багато бізнес процеси і функціональності часто мають на увазі участь \ роботу з ними кількох ролей і груп користувачів. Кожна група користувачів з певної роллю і правами доступу, може виконувати тільки певну частину функцій із загального процесу.
При розбитті функціоналу по роботі з товарами в інтернет магазині на основі ролей використання можна виділити, наприклад, такі завдання:
Розбиваючи загальну функціональність на ролі, які повинні виконувати її частини, ми більш чітко розуміємо, які саме функції необхідні і хто має права для їх виконання. У цьому випадку на перших етапах можна пріоритезувати і реалізувати тільки базові набори функцій для кожної з ролей, а в наслідку розширювати їх можливості.
Метод 8: Декомпозиція за сценаріями тестування \ тест-кейсів.
Дана стратегія декомпозиції дозволяє розбити великі призначені для користувача історії задаючи питання, як та чи інша частина функціональності буде перевірена. Ми визначаємо які сценарії необхідно перевірити, які тести виконати, щоб дізнатися, чи працює ця функція. В результаті ми сформуємо набір тест-кейсів, кожен з яких і буде являти собою окрему задачу. Кожне завдання має бути реалізована так, щоб тестовий сценарій був успішно пройдений.
Розглянемо приклад функціональності - клієнт вибирає товар в інтернет магазині і відкладає його в «кошик» для здійснення покупки. В рамках цієї функціональності можуть бути виділені наступні тестові сценарії (нижче тільки приклад частини можливих тест-кейсів):
- Товар є в наявності і він доступний покупки.
- Товар є в наявності, але він вже зарезервовано іншим покупцем
- Товару немає в наявності
Які переваги дає використання даного методу декомпозиції:
- Ця стратегія фактично об'єднує багато техніки декомпозиції, які були розглянуті раніше. У процесі формування списку тест-кейсів ми автоматично проаналізуємо:
- Умови і правила бізнес процесу
- Позитивні і негативні сценарії використання функціоналу
- Формати даних і параметрів.
- Аналізуючи тестовий сценарій легко зрозуміти наскільки він поширений і вірогідний в умови реального використання продукту, що дозволяє виставити відповідні пріоритети.
- При такому способі розбивки ми відразу отримуємо і опис для завдання \ користувальницької історії і сценарій, за яким можна перевірити успішність її реалізації.