МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛНИЙ ТРАНСПОРТНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ТРАНСПОРТНИХ ТА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ
КАФЕДРА ІНФОРМАЦІЙНИХ СИСТЕМ ТА ТЕХНОЛОГІЙ
Реферат на тему:
«Визначення вимог в Agile проектах»
Виконав:
студент групи ПР-4-2
Микитюк Д.А
Перевірила:
Сілантьєва Ю.А
Київ
2020
ЗМІСТ
ВСТУП.....................................................................................................................3
РОЗДІЛ 1. УЗГОДЖЕННЯ ВИМОГ У ПРОЕКТАХ ГНУЧКОЇ РОЗРОБКИ........................................ ........................................ ............................4
РОЗДІЛ 2. ВИЗНАЧЕННЯ ВИМОГ В AGILE ПРОЕКТАХ.........................5
РОЗДІЛ 3. УПРАВЛІННЯ ВИМОГАМИ В ПРОЕКТАХ ГНУЧКОЇ РОЗРОБКИ........................................ ........................................ ...........................8
ВИСНОВОК..................... ..................... ..................... ..................... ..................11
ВСТУП
Гнучка́ розро́бка програ́много забезпе́чення — клас методологій розробки програмного забезпечення, що базується на ітеративній розробці, в якій вимоги та розв'язки еволюціонують через співпрацю між багатофункціональними командами здатними до самоорганізації. Гнучка розробка — засіб для підвищення продуктивності розробників програмного забезпечення.
Більшість гнучких методологій націлені на мінімізацію ризиків, шляхом зведення розробки до серії коротких циклів, що мають назву ітерацій, які зазвичай тривають один-два тижні. Кожна ітерація сама по собі виглядає як програмний проект в мініатюрі, і включає всі завдання, необхідні для видачі мінімального приросту за функціональністю: планування, аналіз вимог, проектування, кодування, тестування і документування. Хоча окрема ітерація, як правило, недостатня для випуску нової версії продукту, мається на увазі те, що гнучкий програмний проект готовий до випуску наприкінці кожної ітерації. Після закінчення кожної ітерації, команда виконує переоцінку пріоритетів розробки.
Agile акцентує увагу на безпосередньому спілкуванні «віч-на-віч». Більшість agile команд розташовані в одному офісі, його іноді називають bullpen. Як мінімум вона включає і «замовників» (замовники, які визначають продукт, також це можуть бути менеджери продукту, бізнес аналітики або клієнти). Офіс може також включати тестувальників, дизайнерів інтерфейсу, технічних авторів і менеджерів.
Основною метрикою agile методів є робочий продукт. Віддаючи перевагу безпосередньому спілкуванню, agile-методи зменшують обсяг письмової документації в порівнянні з іншими методами. Це привело до критики цих методів як недисциплінованих.
РОЗДІЛ 1. УЗГОДЖЕННЯ ВИМОГ У ПРОЕКТАХ ГНУЧКОЇ РОЗРОБКИ
У проектах гнучкої розробки (agile) немає формальної операції візування. В таких проектах вимоги зазвичай зберігаються у вигляді користувальницьких історій в резерві (backlog) продукту. Власник продукту і команда погоджують, які історії будуть реалізовуватися в наступній ітерації, в процесі наради з планування. Набір історій вибирається на основі пріоритетів і швидкості роботи (продуктивності) команди. Після визначення і узгодження набору містяться в ітерації історії заморожуються. Нові потрібні зміни плануються тільки на майбутні ітерації.
У проектах гнучкої розробки ніхто не намагається отримати схвалення заінтересованої особи відразу на весь набір вимог. В таких проектах повний набір функціональності визначається з часом, хоча концепція і інші бізнес-вимоги повинні бути визначені з самого початку. У проектах гнучкої розробки власник продукту публічно приймає або відкидає вимоги на ітерацію, які представляють собою набір історій і пов'язаних критеріїв прийняття і приймальних тестів. Кінцеве «підписання» полягає у прийманні працюючого і протестованого ПО, отриманого на даній ітерації. Гнучкість говорить нам покладатися на зміни», але сама концепція зміни існує тільки в зв'язці з точкою відліку. Навіть у команді, де її члени тісно спілкуються один з одним, у людей можуть бути різні інтерпретації поточних планів і стану. Пропозицію про зміну, перед створений на розгляд однією людиною, інший може порахувати вже узгодженим. Однак якщо процедуру візування вважати як спрощений церемоніал визнання, що «ми знаходимося на такому і такому етапі», то це нормально. Таке твердження не означає, що завтра ми не можемо бути в іншому місці, але як мінімум це забезпечує порозуміння і спільну точку відліку».
РОЗДІЛ 2. ВИЗНАЧЕННЯ ВИМОГ В AGILE ПРОЕКТАХ
У проектах гнучкої розробки (agile) застосовується ряд способів визначення вимог, які відрізняються від інших методів розробки. У проектах гнучкої розробки команда може почати специфікацію, записавши достатньо інформації по кожній користувальницької історії, щоб зацікавлені особи отримали загальне уявлення, про що історія, і змогли визначити пріоритети історій один щодо одного. Це також дозволяє команді почати планувати призначення історій на конкретні ітерації. Команда може збирати пов'язані історії в «мінімально придатний для просування на ринку функцію, яку потрібно реалізувати цілком до випуску продукту, щоб клієнт міг отримати від неї користь. Користувальницькі історії накопичуються і пріоритизується в резерві продукту (product backlog), який змінюється протягом всього проекту. Великі історії, які охоплюють значну функціональність і які не можна реалізувати в одній ітерації, розбиваються на більш дрібні, які призначаються конкретним ітераціям.
Користувальницькі історії можна записувати на чомусь простому, наприклад на картках каталогу, а не в традиційному документі. Одні команди гнучкої розробки зберігають свої історії у засобі керування історіями, інші після їх реалізації не зберігають. Коли команда приступає до чергової ітерації, кожна історія, призначена на цю ітерацію, уточняється і наповнюється деталями в процесі обговорення між власником продукту, людьми, що виконують роль бізнес-аналітика, аналітиками, тестерами і користувачами. Тобто специфікація передбачає поступове уточнення подробиць на правильному етапі проекту, що є гарною практикою в будь-якому проекті. Зазвичай ці подробиці відповідають тому, що ми називали функціональними вимогами специфікації вимог до ПЗ. Однак у проектах гнучкої розробки ці подробиці часто представляються у формі приймальних тестів, що описують, як система повинна вести себе при правильній реалізації історії. Тести історії проводяться під час ітерації, в якій реалізується ця історія, і в майбутніх ітераціях в рамках регресійного тестування. Як і в будь-яких інших тестах, в них повинні виконуватися виняткові умови, а також очікувану поведінку. Ці приймальні тести можуть записуватися на картках або реєструватися більш постійній формі, наприклад засобі тестування.
Тести потрібно автоматизувати, щоб забезпечити швидке і повне регресійне тестування. Якщо команда вирішить відмовитися від вихідних користувальницьких історій, тоді приймальними тестами може бути постійна документація вимог, якщо вони зберігаються в спеціалізованому засобі. Аналогічно нефункціональні вимоги можуть записуватися на картках, але не як користувальницькі історії, а як обмеження (Cohn, 2004).Альтернативний варіант — вказувати нефункціональні вимоги, що відносяться до певної користувача історії, у формі критеріїв приймання як демонстрацію досягнення певного атрибута якості. Наприклад, тести безпеки можуть демонструвати, що тільки певним користувачам дозволений доступ до функціональності, описаної у відповідній користувача історії, а іншим користувачам доступ закритий.
Команді гнучкої розробки не забороняється застосовувати інші методи представлення знань про вимоги, такі як моделі аналізу або словник даних. Вони повинні вибрати метод подання, який звичний і доречний в їх культурі і проект. Вибір належних форм специфікації вимог до ПО — виняткова прерогатива команди проекту. Згадайте головну мету розробки вимог — зібрати однозначне розуміння вимог, якість яких досить, щоб приступити до розробки наступної частини продукту і продовжити роботу при прийнятному рівні ризику. «Належний рівень
формальності і подробиці документа вимог залежить від багатьох факторів, в числі яких:
• обсяг оперативного неформального вербального та візуального спілкування між клієнтами і розробниками, який необхідний для отримання подробиць, необхідних для правильної реалізації кожного користувача вимоги;
• межа, до якого неформальні методи спілкування можуть забезпечити ефективну синхронізацію у часі і просторі всередині команди;
• межа, до якої представляє цінність або необхідність збереження знань про вимоги для майбутніх поліпшень, реінжинірингу програми, перевірки, аудиту, перевірки на відповідність нормативам, сертифікації продукту або згідно з умовами контракту;
• межа, до якої приймальні тести можуть ефективно замінювати опису очікуваних можливостей і поведінки системи;
• межа, до якої людська пам'ять може замінити письмове подання. Незалежно від типу створюваного командою продукту, використовуваної методики розробки або використовуваних бізнес-аналітиком прийомів виявлення вимог, ефективна специфікація вимог життєво важлива для успіху. Існує багато шляхів досягнення цієї мети. Просто пам'ятайте, що якщо не визначити високоякісні вимоги, отриманий в результаті продукт буде представляти собою коробку з сюрпризами — ви ніколи не будете знати, що від нього можна очікувати.
РОЗДІЛ 3. УПРАВЛІННЯ ВИМОГАМИ В ПРОЕКТАХ ГНУЧКОЇ РОЗРОБКИ
У проектах гнучкої розробки (agile) робота із змінами ведеться шляхом
побудови продукту в рамках серії ітерацій і управління динамічним резервом (backlog) продукту, тобто роботи, яку потрібно виконати. Як описано в розділі 2, зацікавлені особи погоджують історії, які повинні реалізовуватися в кожній ітерації. Нові історії, приєднані під час ітерації, пріоритизизуєтся в сукупності з резервом проекту і призначаються на майбутні ітерації. Нові історії можуть витіснити низько пріоритетні історії, якщо команда не хоче змінювати графік випуску. Як і у всіх інших проектах, завдання завжди полягає у роботі над найбільш пріоритетними історіями, щоб максимально швидко В деяких командах, особливо у великих або розподілених, використовується засіб управління проектом гнучкої розробки для відстеження стану ітерації і призначених на неї історій. Історії та відповідні їм приймальні критерії та тести можна розмістити у резерві продукту або засобі управління користувацькими історіями.
• In backlog (В резерві) (історія поки що не призначено на конкретну ітерацію);
• Defined (Визначена) (подробиці історії обговорені і зрозумілі, і на-
писані приймальні тести);
• In Progress (Розробка) (історія в процесі реалізації);
• Completed (Завершено) (історія повністю реалізована);
• Accepted (Прийнята) (пройдені приймальні тести);
• Blocked (Блокована) (розробник не може продовжити розробку, поки не будуть вирішені інші питання). У проектах гнучкої розробки просування проекту відслідковується з по - міццю графіка згоряння завдань (Cohn, 2004; Cohn, 2005). У команді загальний обсяг роботи, яку треба виконати в проекті, часто вимірюють у балах історій, які визначаються в процесі аналізу користувальницьких історій у резерві продукту (Cohn, 2005; Leffingwell, 2011). Таким чином, загальна кількість балів історій пропорційне зусиллям, які команда повинна витратити на реалізацію цих вимог. Конкретні користувача історії призначаються на ітерації на основі їх пріоритетів та розміру балах. Минула або середня швидкість розробки визначать кількість балів історій, які команда зможе реалізувати ітерації або в конкретний календарний термін. Залишаються в кінці ітерації бали історій в резерві відзначаються на графіку. Ця загальна цифра змінюється по мірі завершення роботи, кращого розуміння та переоцінки поточних історій, додавання нових історій і видалення завершеної роботи з резерву. Таким чином, графік згоряння завдань показує загальний обсяг роботи залишається на певний момент часу, а не відстежує кількість і стан окремих функціональних вимог або функцій (розмір яких може бути різним).
Управління вимогами життєво необхідно незалежно від типу життєвого циклу проекту — будь то водоспадна модель або модель гнучкої розробки. Управління вимогами допомагає переконатися, що зусилля, витрачені на розробку вимог, не витрачені даремно. Ефективне управління вимогами може зменшити невірні очікування: зацікавлені особи будуть проінформовані про поточний стан вимог в ході процесу розробки. Це дозволяє розуміти, куди рухається проект, як йдуть справи і коли проект прибуде в кінцеву точку. Управління змінами в проектах гнучкої розробки Сама структура проектів гнучкої розробки передбачає і навіть вітає зміни меж проекту. Один з 12 принципів гнучкої розробки ЗА говорить: «Приймайте мінливі вимоги, навіть на пізніх стадіях розробки. Процеси ставлять зміни на службу підвищення конкурентних переваг клієнта»» Цей принцип визнає ту реальність, що зміни вимог неминучі, необхідні і часто цінні. Прийняття змін допомагає досягати мінливі бізнес-цілі і враховувати обмеження людського планування і прогнозування людиною. У проектах гнучкої розробки змінами управляють, підтримуючи динамічний резерв (backlog) залишилася роботи (див. рис. 28-9). Під «роботою» маються на увазі ще не реалізовані власні історії, не усунені дефекти, не внесені у бізнес-процеси зміни, не розроблені курси навчання і маса інших дій, присутніх у будь-якому проекті розробки ПО. В кожній ітерації реалізується ряд пріоритетних завдань з резерву. Коли заінтересовані особи просять виконання додаткової роботи, ці завдання надходять у резерв і пріоритизується разом з вже наявними завданнями. Пріоритети завдань, не призначених на конкретні ітерації, можуть змінюватися, і ці завдання в будь якій момент можуть видалятися з резерву.
Нова високо пріоритетна користувацька історія, призначена на наступну ітерацію, може витіснити менш пріоритетну такого ж розміру, раніше призначену на цю ітерацію. Ретельне управління обсягом кожній ітерації гарантує її виконання вчасно і з високою якістю.
ВИСНОВОК
Agile модель є дуже ефективною моделлю управління проектами тому, що вона: задовольняє клієнтів, завчасно і постійно поставляючи ПО, дозволяє змінювати вимоги до кінцевого продукту протягом усього циклу його розробки, постачає робоче ПО якомога частіше, підтримує співробітництво між розробниками і замовником протягом усього циклу розробки, підтримує і мотивує всіх, хто залучений в проект, забезпечує безпосередню взаємодію між розробниками, вимірює прогрес тільки за допомогою робочого ПО, підтримує безперервний темп роботи, приділяє увагу дизайну і технічних деталей, намагається зробити робочий процес максимально простим, а ПО - простим і зрозумілим, дозволяє членам команди самостійно приймати рішення, постійно адаптується до мінливого середовища.