Розробка інформаційних ресурсів, Екстремальне програмування (Product vision)

Productvision

У гнучкій методології кожен проект треба розпочинати з концепції продукту (Product vision), який задає напрям і керівництва scrum-команди. Головна мета цього документу – донести до усіх зацікавлених у проекті сторін (Product Owner, Scrum-мастер, команда, керівництво, клієнтів та інших) цілі проекту. Як пише один з засновників методології, Кен Швабер: "Мінімальний план, необхідний для запуску scrum-проекту являє собою концепцію та product backlog. Концепція описує, чому проект здійснюється і те, що бажано отримати по завершенні".

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

1) Хто буде купувати цей продукт? Хто є цільовим споживачем?

2) На які потреби клієнтів націлений продукт?

3) Які атрибути продукту мають вирішальне значення для задоволення зазначених потреб і, отже, для успіху цього продукту?

4) Яким чином продукт можна порівнювати з існуючими продуктами? Які унікальні характеристики має продукт для успішного продажу?

5) Яким є цільовий терміни, бюджет для розробки та запуску продукту?

Відповіді на ці п'ять питань дозволяють вирішити, коли і яким чином проект повинен розвиватися.

Стаття о Product vision: http://tim.com.ua/2012/11/product-vision-the-tool-for-product-owner/.

Product backlog

Також на початку роботи над проектом на підставі зібраних функціональних вимог на стороні замовника складають документ product backlog, до складу якого входять пріоритезовані історії користувача (user story).

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

Складаються вони легко, у них є шаблон:

«Як <роль>, я хочу <ціль/бажання>».

Наприклад: «Як "Адміністратор" я можу редагувати модель складання рейтингів підрозділів».

Головне в їх створюванні кратність. Одне бажання = Одна історія.

Кожна історія користувача має мати прив'язаний до неї хоча б один тест прийняття, який дозволяє розробнику вияснити чи історія користувача виконана, і також дозволяє замовнику перевірити це.

Acceptance test

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

Виконання приймальних тестів – це процес перевірки того, що історія була розроблена саме так, як цього чекав замовник.

Під час розробки приймальних тестів використовувалася наступна структура:

- номер користувацької історії (ID);

- зміст історії;

- таблиця з переліком назв, url та макетів сторінок веб-додатку, що задіяні у цій історії;

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

З повагою ІЦ "KURSOVIKS"!