НОУ ІНТУІТ, Лекція, Гнучкі (agile) методи розробки

"Гнучкі" (agile) методи розробки ПЗ з'явилися як альтернатива формальним і "важкоатлетним" методологіям, на кшталт CMM і RUP. Талановиті програмісти не бажають перетворення розробки ПЗ на рутину, хочуть мати максимум свобод і обіцяють високу ефективність. З іншого боку, практика показує, що "важковагові" методології у значній кількості випадків неефективні. Основними положеннями гнучких методів, закріплених у Agile Manifesto у 2007 році є наступне 1 Не треба розуміти ці положення Agile Manifesto буквально так, що будь-яка гнучка методологія їм точно задовольняє. Agile Manifesto лише оконтурює деякий простір, позначає певне явище. Окремі частини цього явища – конкретні гнучкі методології можуть мати різну специфіку, можуть бути прикордонними об'єктами. :

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

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

Extreme Programming

Найвідомішим гнучким методом є Extreme Programming (відома скорочена назва XP). Він був створений талановитим фахівцем у галузі програмної інженерії Кентом Беком у результаті його роботи у 1996-1999 роках над системою контролю платежів компанії "Крайслер".

Модель процесу по XPвиглядає як часта послідовність випусків (releases) продукту, настільки часті, як це можливо. Але при цьому обов'язково щоб у випуск входила нова цілікова функціональність. Нижче наведено основні принципи організації процесу по XP.

Більш практичним "гнучким" методом розробки є Scrum.

Загальний опис. Метод Scrum дозволяє гнучко розробляти проекти невеликими командами (7 чоловік плюс/мінус 2) у ситуації вимог, що змінюються. При цьому процес розробки ітеративний і надає більшу свободу команді. Крім того, метод дуже простий – легко вивчається та застосовується на практиці. Його схема зображено на рис. 11.1.

Спочатку створюються вимоги до всього продукту. Потім їх вибираються найактуальніші і створюється план наступну ітерацію. Протягом ітерації плани не змінюються (цим досягається відносна стабільність розробки), а сама ітерація триває 2-4 тижні. Вона закінчується створенням працездатної версії продукту (робочий продукт), яку можна пред'явити замовнику, запустити та продемонструвати, хай і з мінімальними функціональними можливостями. Після цього результати обговорюються та коригуються вимоги до продукту. Це зручно робити, маючи після кожної ітерації продукт, який можна якось використовувати, показувати і обговорювати. Далі відбувається планування нової ітерації, і все повторюється.

Усередині ітерації проектом повністю займається команда. Вона є плоскою, ніяких ролей не визначає Scrum. Синхронізація з менеджментом та замовником відбувається після закінчення ітерації. Ітерація може бути перервана лише у особливих випадках.

Ролі. У Scrum є лише три види ролей.

Власник продукту(Product Owner ) – це менеджер проекту,який представляє у проекті інтереси замовника. До його обов'язків входить розробка початкових вимог до продукту (Product Backlog), своєчасна їх зміна, призначення пріоритетів, дат поставки та ін. Важливо, що він не бере участі у виконанні самої ітерації.

Scrum-майстра(Scrum Master) забезпечує максимальну працездатність та продуктивну роботу команди – як виконання Scrum-процесу, так і вирішення господарських та адміністративних завдань. Зокрема, його завданням є захист команди від усіх впливів ззовні під час ітерації.

Scrum-команда(Scrum Team) - група, що складається з п'яти-дев'яти самостійних, ініціативних програмістів. Першим завданням команди є постановка для ітерації реально досяжних та пріоритетних для проекту в цілому завдань (на основі Project Backlog та за активної участі власника продукту та Scrum-майстра). Другим завданням є виконання цього завдання будь-що, у відведені терміни та із заявленою якістю. Важливо, що команда сама бере участь у постановці завдання і сама її виконує. Тут поєднується свобода і відповідальність, подібно до того, як це організовано в MSF. Тут же "просвічує" дисципліна зобов'язань.

Практики. У Scrum визначено такі практики.

Sprint Planning Meeting. Проводиться спочатку кожного Sprint. Спочатку Produсt Owner, Scrum-майстер, команда, а також представники замовника тощо зацікавлені особи визначають, які вимоги з Project Backlog найбільш пріоритетні і їх слід реалізовувати в рамках даного Sprint. Формується Sprint Backlog. Далі Scrum-майстер і Scrum-команда визначають те, як саме будуть досягнуті певні цілі з Sprint Backlog. Для кожного елемента Sprint Backlogвизначається список завдань та оцінюється їх трудомісткість.

Daily Scrum Meeting– п'ятнадцятихвилинна щоденна нарада, метою якої є досягнення розуміння того, що відбулося з часу попередньої наради, скоригувати робочий план відповідно до реалій сьогоднішнього дня та позначити шляхи вирішення існуючих проблем. Кожен учасник Scrum-команди відповідає на три питання: що я зробив з часу попередньої зустрічі, мої проблеми, що я робитиму до наступної зустрічі? У цій нараді може брати участь будь-яка зацікавлена особа, але лише учасники Scrum-команди мають право приймати рішення. Правило обґрунтоване тим, що вони зобов'язували реалізувати мету ітерації, і тільки це дає впевненість у тому, що її буде досягнуто. На них лежить відповідальність за їхні власні слова, і якщо хтось з боку втручається і приймає рішення за них, то він знімає відповідальність за результат з учасників команди. Такі зустрічі підтримують дисципліну зобов'язань у Scrum-команді, сприяють утриманню фокусу з метою ітерації, допомагають вирішувати проблеми "в зародку". Зазвичай такі наради проводяться стоячи протягом 15-20 хвилин.

Sprint Review Meeting. Проводиться наприкінці кожного Sprint. Спочатку Scrum-команда демонструє Product Owner зроблену протягом Sprint роботу, а той у свою чергу веде цю частину мітингу і може запросити до участі всіх зацікавлених представників замовника. Product Owner визначає, які вимоги з Sprint Backlog були виконані, та обговорює з командою та замовниками, як краще розставити пріоритети у Sprint Backlog для наступної ітерації. У другій частині мітингу проводиться аналіз спринту, який веде Scrum-майстер. Scrum-команда аналізує в останньому Sprintпозитивні та негативні моменти спільної роботи, робить висновки та приймає важливі для подальшої роботи рішення. Scrum-команда також шукає шляхи для підвищення ефективності подальшої роботи. Потім цикл повторюється.