Воркшопи з виявлення вимог до IT-проектами: як і навіщо їх проводити?

image

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

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

Які тут можуть виникнути труднощі?

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

Що робити?

З усього розмаїття технік по збору вимог варто виділити одну, яка націлена на вирішення подібних проблем (проблем масштабних проектів з безліччю зацікавлених осіб і конфліктуючих вимог), — це воркшоп по збору вимог, про нього ми і хочемо вам розповісти.

Читати далі →

Оцінка тестового покриття на проекті

Найкращий спосіб оцінити, чи добре ми протестували продукт – проаналізувати пропущені дефекти. Ті, з якими зіткнулися наші користувачі, імплементатори, бізнес. За ним можна багато оцінити: що ми перевірили недостатньо ретельно, яким областях продукту варто приділити більше уваги, який взагалі відсоток пропусків і яка динаміка його змін. З цієї метрикою (мабуть, найпоширенішою в тестуванні) все добре, але… Коли ми випустили продукт, і дізналися про пропущені помилки, може бути вже занадто пізно: на «хабре» про нас з'явилася гнівна стаття, конкуренти швидко поширюють критику, клієнти втратили до нас довіру, керівництво незадоволено.

Щоб такого не відбувалося, ми зазвичай заздалегідь, до релізу, намагаємося оцінювати якість тестування: наскільки добре і ми ретельно перевіряємо продукт? Яким областях не вистачає уваги, де основні ризики, якийсь прогрес? І щоб відповісти на всі ці запитання, ми оцінюємо тестове покриття.
Читати далі →

Довгобуд в розробці: про проблеми управління вимогами

Чим загрожує довгобуд у розробці і з якими труднощами доведеться зіткнутися на цьому шляху? Як бізнес-аналітик компанії, яка 15 років займається розробкою і підтримкою одного продукту (СЕД), я вирішила поділитися своїми думками та прикладами з практики. Проблематика управління вимогами в будь-яких програмних продуктах з тривалим періодом реалізації – актуальне питання для аналітиків, керівників проектів і власників продуктів. І, можливо, для безпосередніх партнерів та замовників Docsvision, які очікують виходу нових версій і зацікавлених у появі нової функціональності.



Читати далі →

Приклад написання функціональних вимог до Enterprise-системі

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

Метою розробки було створення з нуля облікової системи для однієї з великих російських компаній. Система була покликана замінити поточну, написану наприкінці 90-х. У результаті були реалізовані платформа і один з бізнес-модулів. В реалізованої частини було близько 120 об'єктів, 180 таблиць, близько 30 друкованих форм.

Хочу обмовитися, що підхід, описаний нижче, не універсальний для написання будь-якого ПЗ. Він підходить для систем рівня підприємства, які будуються на основі об'єктно-орієнтованого підходу: облікових, CRM, ERP-систем, систем документообігу і т. п.

Вся документація на наш програмний продукт складалася з наступних розділів:
  • Загальна частина
    • Перелік термінів та визначень,
    • Опис бізнес-ролей
  • Вимоги
    • Бізнес-вимоги
    • Загальні сценарії
    • Сценарії

    • Алгоритми і перевірки
    • Системні вимоги
    • Нефункціональні вимоги
    • Вимоги до інтеграції
    • Вимоги до інтерфейсу
  • Реалізація
  • Тестування
  • Посібники
  • Управління

Читати далі →

Starban. Гнучка методологія розробки, гейміфікація і ще багато модних слів

Оскільки пост некороткий і навіть недоречні картинки не роблять його читання легше, то давайте насамперед позначимо цільову аудиторію.
  • Ви розробник, керівник групи розробки, менеджер проекту або його еквівалент.
  • Над проектом працює більше одного програміста, бажано — більше трьох.
  • Ви пробували всі ці скрамы і эджайлы, відчули їх принадність, але є певні нарікання до догматичного сприйняття методології. Можливо, у вас ніхто не займається постановкою процесів зовсім і завдання просто «накидаються».
  • Команда втомилася (від проекту, від стресу, ...) і незабаром всіх чекають батоги і пряники.


Добре, є методологія, яка вигадана командою програмістів «для себе», але яку, на нашу думку, буде цікаво спробувати й іншим. Всередині команди відтворюється невелика економічна модель ринкових відносин, а пріоритети регулюються за допомогою курсу внутрішньокомандній валюти.
Читати далі →

Рівні зрілості процесу управління вимогами

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

Працюючи над статтею про ролі вимог у процесі розробки програмного забезпечення я виявив шкалу рівнів зрілості процесу управління вимогами (requirements management maturity), запропоновану в 2003 році одним з фахівців по роботі з вимогами Rational Software Джимом Хьюманном (Jim Heumann).

Хочу поділитися з читачами habrahabr даної класифікації.

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

Нижче наведена шкала рівнів зрілості процесу управління вимогами, побудована за аналогією з моделлю CMMI. Ці моделі ніяк не пов'язані між собою, але мають деякий перетин. Так, досягнення рівня 5 (Інтеграція вимог) зрілості процесу управління вимогами дозволить отримати як мінімум рівень 3 (Процеси визначені на рівні всієї організації) за моделлю CMMI. Однак це не є прямим наслідком, так як досягнення високого рівня зрілості в одному процесі не гарантує загального підвищення зрілості організації в цілому.

Читати далі →