Будь-яка дискусія про процеси розробки програмного забезпечення заснована на декількох класичних підходах, як створити сучасне програмне забезпечення. Ми повинні встановити певну частоту, щоб доставити продукти з очікуваною частотою, беручи до уваги потреби ринку. Тривалість ітерації повинна відображати необхідну швидкість адаптації до змін у списку продуктів. Здається, що підхід до управління пріоритетами абсолютно інтуїтивний, і вам не потрібно глибоко розуміти стандартизацію, щоб використовувати його у розробці програмного забезпечення. Проте, встановлення будь-якого процесу означає декларацію загальних принципів для кожного члена команди. І тут лежать ускладнення: як пояснити будь-якому члену команди, що означає якась цифра або слово поруч із завданням або продуктом? Особливо в проектах з багатьма командами. Завжди можна винайти власну систему пріоритетів, але це призводить до необхідності пояснення принципів вашої системи для кожного нового члена команди. Якщо проект великий і у вас є багато нових співробітників, добре, це проблема. Тому легше використовувати деякі перевірені часом міжнародні стандарти або підходи. У цій статті я хотів би обговорити використання методу MoSCoW для пріоритетування в розробці продукту як де-факто найпоширеніший спосіб раціоналізації роботи під час ітерацій, які забезпечують швидкі і вимірювані результати. Як ілюстрацію я дам приклад методу пріоритетування на замовлення та проблеми, з якими я зіткнувся з цим підходом. Потім ми зануримося в розпад методу MoSCoW, щоб розглянути кожну пріоритетність з живими прикладами. Стаття може бути корисною для менеджерів продуктів або будь-кого, хто переслідує процес розробки продукту, який добре працює. Весело провести час з індивідуальним підходом до пріоритету пункту Дуже давно, в одній команді продуктів, ми намагалися вирішити проблему з пріоритетами пунктів у наших циклах розробки. Сам процес був дуже незрілим: терміни реалізації часто порушувалися, команда повинна була працювати занадто довго, а випуски продуктів були незадовільної якості. У той момент ми використовували чисельні пріоритети 1-2-3-4 і вони зовсім не допомагали. Потім ми вирішили спростити спілкування між членами команди і ввели додатковий пріоритет «5». Цей пріоритет став би найвищим пріоритетом, більш важливим, ніж «1», і означає «showstopper» - квиток або предмет, який повинен бути реалізований ASAP, незважаючи на будь-яке інше завдання в ітерації. Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. Звичайно, метод пріоритетизації не був загальною проблемою в цьому процесі. Були фундаментальні проблеми в підході до планування, управління ризиками та самої стратегії. Але якщо у вас є багато проблем на вашому столі, винахід власної незрозумілої методології не виглядає найкращим рішенням. Впровадження підходу «Московія» Деякі стандарти строго кодифіковані в міжнародних RFC з кращої практики з таких органів, як IETF або IEEE, в той час як інші стали стандартами на власному рівні. той, який я хотів би ввести, потрапляє в останню категорію. Цей підхід був запропонований Дай Клеггом в книзі « Назва «MoSCoW» не має зв'язку з північною столицею і була створена як абревіатура категорій пріоритетизації: У вас є, Хотілося б мати, ВУЗ має, Ці категорії можуть бути пов'язані з числовими пріоритетами 1-2-3-4 і допомогти однозначно визначити послідовність завдань або пунктів в ітерації розробки продукту. Ясна мета кожної категорії робить цей метод таким коштовним, і під час цієї статті я хотів би охопити кожну пріоритет з прикладами в розвитку Agile. Метод випадку Fast-Track: підхід RAD M S Co W По-перше, необхідно встановити прикладний сценарій використання підходу. Припустимо, що ми є членами продуктної команди, яка розробляє продукт B2B. У цьому продукті наші клієнти можуть зберігати і обмінюватися файлами для своїх проектів. Щоб зробити це простішим, наша команда додасть деякі базові функції, такі як «Запрошення користувача» - функціональність додавання нового учасника до проекту. Ми обіцяли нашим клієнтам, що ми будемо впроваджувати цю функцію до певної дати; ми маємо зобов'язання. У цьому прикладі ми не будемо сегментувати членів команди за спеціальністю (Dev, DevOps, QA), і будемо уявляти нашу команду як канонічну універсальну команду Scrum. Сценарій запрошення користувача підготував технічні вимоги, UX / UI. Функція вже була розбита на значущі елементи, які мають сенс, і всі ці елементи були оцінені. Настав час використовувати підхід до пріоритетування, і без подальшого занепокоєння, давайте категоризуємо ці пункти. Має бути - 1 Приоритет Must Have "1" використовується для завдань, функцій, елементів backlog продукту, історій користувачів або помилок, які повинні бути включені в наступну ітерацію розробки. Наприклад, під час планування ми зрозуміли, що деякі завдання повинні бути розроблені через угоди з клієнтами або вони є бізнес-критичними з якоїсь іншої причини. Основна ідея полягає в тому, що ці елементи є вирішальними і неможливими до переговорів. Виходячи з прикладу нової функції продукту, припустимо, що ми хочемо впровадити функцію «запросити нового користувача до проекту». категорія «Мужно мати» відображає завдання MVP і створює базові функціональні можливості. Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. Потрібно мати - 2 Друга категорія близька до «Мусить бути», але це те, що ми могли б відкласти або доставити пізніше. Якщо ми домовимося з клієнтом про запрошення користувачів, функції MVP будуть випущені як обов'язкові варіанти в пріоритеті «1». Проте, завжди є багато вдосконалень, які необхідно реалізувати, але вони можуть бути пропущені в заявленому обсязі. Наприклад, у функції «Запрошення користувача» продукт повинен допомогти встановити нових користувачів. У пріоритеті «Must Have» команда розробить критичний сценарій створення та запрошення. Але також важливо надіслати відгук запрошуючому адміністратору про те, що новий користувач успішно ввійшов. Можна використовувати функцію без цього відгуку, але з цим повідомленням продукт, безумовно, краще і адміністратор буде знати, що все гаразд. Помилка продукту "Слід мати" - це те, що порушує сценарій, але є деякі розумні рішення, доступні для звичайного і нетехнічного користувача.Краще завжди виправляти ці помилки під час ітерації, але вони можуть бути обговорені близько терміну, тому що все ще можна випустити з ними. Можливо — 3 Ця категорія стосується поліпшень або дрібних візуальних дефектів, які роблять різницю в цілому і можуть підвищити загальне відчуття продукту, але вони не є критичними зараз або глибоко факультативними для сценарію. Було б приємно розробити ці речі, тільки якщо ризики пріоритетів "Мусить мати" або "Мусить мати" пом'якшені. Під час планування, команда продуктів повинна думати про "Може мати" елементи, як це: перший пріоритет повинен бути зроблений. Ми повинні прикладати максимальні зусилля, щоб доставити другий пріоритет. Якщо все йде добре, ми очікуємо розробити третій пріоритетний пункт, але якщо ми зазнали невдачі, це не повинно впливати на бізнес. У випадку функції "Запрошення користувача" третій пріоритет - це деякі додаткові поліпшення у формі запрошення користувача. Як третя пріоритетна функція, адміністратор може налаштувати автоматичні сповіщення, якщо користувач не ввійшов протягом наступних трьох днів. Адміністратор проекту може відправити це нагадування вручну, якщо вони помітять відсутність повідомлення про другий пріоритет, але було б приємно впровадити автоматичні нагадування спочатку. Пріоритет "Можна мати" як продуктивний помилка - це щось про рідкісні функції або візуальні помилки, які відтворюються в деяких незвичайних середовищах. Ці помилки можуть бути виправлені, якщо у нас немає незавершених функцій або продуктивних помилок інших категорій. Третій пріоритетний помилки можуть бути перенесені на наступну ітерацію без тривалих переговорів, тому що вони не блокують випуск продукту. Наприклад, більшість нашої клієнтської бази використовує веб-браузери на конкретному двигуні, і у нас є незначний дефект в непопулярному двигуні. Було б чудово виправити цей помилка, але якщо всі зайняті більш важливими завданнями, немає проблеми мати цю проблему в випуску. Не буде – 4 Корисна категорія, яка показує елементи, які, безумовно, не будуть випущені під час ітерації. Однак, важливо мати їх, якщо залишається деяка потужність. Команда продукту може спланувати ітерації та завдання сегменту та помилки як перший, другий і третій пріоритети. І трапляється, що завдання легше, ніж було заплановано. Розробники матимуть додатковий час, який можна використовувати для четвертого пріоритету. Ці елементи завжди розробляються в галузях і ніколи не мають наміру бути об'єднані в поточному ітерації, але це полегшує речі для наступного ітерації. Які типи завдань підходять як «не маю» відшкодування? Перш за все, існують технічні завдання заборгованості. Надзвичайно важливими можуть бути пріоритети «Must Have» або «Should Have», але регулярні поліпшення коду для підтримки кодової бази є чудовим прикладом четвертого пріоритету. Розробники мають можливість поліпшити код після бізнес-критичних завдань і використовувати ці поліпшення в наступних ітераціях. Якщо деякі зміни руйнуються і вимагають нетипового виконання QA, вдосконалення перед новими ітераціями також дає можливість своєчасно приготувати. Також корисно додати в якості пріоритету «Немає» деякі елементи, які будуть першим пріоритетом «Мусть мати» в наступній ітерації. Ми знаємо, що після базового запрошення користувача, ми повинні інтегрувати детальні налаштування дозволів користувача в цей сценарій, щоб спростити потік адміністратора. Ця функція буде MVP наступної ітерації. Якщо у нас є якісь можливості, це чудово почати розробляти його як четвертий пріоритет; це знизить ризики в майбутньому. Під час планування наступної ітерації, пріоритет цього пункту буде оновлений до «Мусть бути». Краще не мати помилок продукту четвертого пріоритету, тому що ця категорія показує, що помилка не буде виправлена під час ітерації, і це просто створить додатковий плутанину на дошці backlog. все ж, пріоритет може бути використаний для помилок, які вимагають архітектурних змін, які небезпечні для поточного ітерації, і їх випробування повинні бути заплановані в наступному. Використання пріоритетного підходу Загальний - це чітке розуміння значення пріоритетів. На початку цієї статті я зробив приклад індивідуального підходу до пріоритетів з чотирма категоріями, які ніхто не розумів, і команда повинна ввести п'ятий пріоритет для найважливіших завдань. Ці правила також служать бенчмарком для команди і допомагають продемонструвати проблеми в підході до планування команди. Наприклад, якщо команда не може розробити всі заплановані пункти першого пріоритету «Мусить мати», не кажучи вже про інші пріоритети, це показує глибокі проблеми в процесі: Вимоги до функцій не були настільки хорошими і ясними. Було допущено помилку при розкладі. Команда якось недооцінювала складність завдань. Хтось вирішив змінити думку під час ітерації. Команда повинна надати ретроспективу і з'ясувати джерело проблеми і знайти рішення для виправлення зламаного процесу розробки. У той же час стабільне завершення третього і четвертого пріоритетів теж не так добре. Це означає, що ми хороші в оцінці та управлінні ризиками, але це також показує, що команда досить розслаблена або недовантажена. Можливо, ми могли б планувати додаткові пункти пріоритетів «Мусть бути» або «Мусть бути». Процес розвитку вимагає балансу і деяких викликів, щоб тримати всіх членів команди гострими і шукати поліпшення. Недоліки підходу У вищезазначеному прикладі завдання були класифіковані за пріоритетом для однієї конкретної ітерації, але це не означає загальний пріоритет відповідно до бізнесу компанії. Завдання, які позначені як "Можливо" в поточній ітерації, можуть стати "Мені потрібно" в наступній, і ці зміни вимагають додаткового часу під час кожної сесії планування для менеджера ітерації. Більш того, підхід все ще має проблеми з послідовністю завдань в одній категорії. Якщо в ітерації є кілька елементів «Must Have», які з них слід розробити спочатку? Цю послідовність все ще слід обговорювати через планування ітерації та координувати через конкретне програмне забезпечення. Висновок Існує багато методів і підходів для пріоритетування. Однак, я вважаю, що підхід MoSCoW є одним з найпростіших, щоб почати з загальних поліпшень процесу розробки програмного забезпечення. Цей підхід більш підходить для продуктів ринку B2B і розробки продуктів з чітко сформульованими завданнями і баченням. Необхідно мати план для подальших ітерацій, щоб правильно використовувати цей підхід. У хаотичному і швидко мінливому середовищі цей підхід може погіршитися і створити так багато завдань з високим пріоритетом, що вплине на передбачуваність випуску. Така ж проблема може з'явитися без належного планування та процесів оцінки. Але, тим не менш, використання цього підходу допоможе визначити всі ці проблеми якомога швидше і запустити
