Найповніший посібник із керування вимогами та відстеження

Скільки часу займає вимога?

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

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

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

Як визначити належну кількість часу та зусиль, необхідних для таких дій, як збір вимог? Не дивно, що дані з різних тестів не завжди збігаються між собою. Також спірно, чи схожі ці «звичайні» проекти на ваші власні. Щоб допомогти вам вирішити цю проблему, я адаптував деякі ідеї зі своєї книги «Докладніше про вимоги до програмного забезпечення» в цій статті – перевірте!

Галузеві контрольні показники

Щоб надати приклад потенційної корисності контрольних показників, будь ласка, зверніться до таблиці 1. Представлені дані вказують на середні галузеві показники для різних зусиль з виявлення вимог і створення прототипів щодо проектів, які мають розмір 10,000 XNUMX функціональних точок (приблизно один мільйон рядків коду), отримані з Каперс Джонс «Оцінки програмного забезпечення, контрольні показники та найкращі практики». Наскільки ці цифри стосуються вашого проекту?

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

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

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

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

Ваш власний досвід

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

Поряд з іншими елементами важливо враховувати життєвий цикл проекту. Не припускайте, що всі вимоги мають бути накопичені на початку, як у послідовному або каскадному підході (ілюстровано пунктирною лінією на малюнку 2). Замість того щоб мати чітку «фазу вимог», подумайте про низку реквізитів, які проходять через кожну стадію розробки. Оскільки наші специфікації системних вимог (SRS) розвиваються та починають з’являтися запити на зміни, ми повинні активно керувати базовими вимогами. Це постійний процес, який потребує постійної уваги.

Ітераційний та інкрементальний підходи

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

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

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

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

Виявлення вимог до планування

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

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

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

Не забудьте поділитися цим постом!