Черепашки-ніндзя та методології розробки ПЗ: Бій за якість

Вступ

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

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

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

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

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

Цікавий факт:

Не тільки давні українці віднайшли методологію добробуту і залишили нащадкам у вигляді прислів’я. Аналогічні «спадки» можна зустріти в культурах багатьох інших народів: у британців: «Good work brings good rewards» (Гарна праця приносить гарну винагороду), у німців: «Wie die Arbeit, so der Lohn» (Яка робота, така і нагорода), в іспанців: «Haz las cosas bien, y te irá bien» (Роби речі добре і в тебе все буде добре), у французів: «Bien faire et laisser dire» (Добре робити й не зважати на те, що кажуть) та навіть у персів: «کار نیکو کن و نتیجه نیکو ببین» (Роби добру справу і побачиш добрий результат).

Однак, досить лінгвістичних цікавинок, у нас тут з рештою спільнота технічних спеціалістів, тому саме час переходити до основної теми цієї статті, мета створення якої – допомога як початківцями у здобутті нових знань, так і більш досвідченим колегам у відновленні старих. Тож, розпочинаймо!

Частина 1: Концепція методологій розробки та при чому тут черепашки-ніндзя

Процес розробки програмного забезпечення і раніше не був справою «на три копійки», а зараз, коли всі вже звикли до Big Data та Blockchain і штучним інтелектом нікого не вразиш, – тим паче. Тому до організації розробки нового продукту завжди ставляться відповідально та сумлінно: шукають інвесторів, визначають вимоги, наймають людей, рахують ризики, оформлюють відповідні документи та ще купа чого.

Як бачимо, роботи – хоч греблю гати, а ще спробуй усю ту тону процесів пам’ятати та контролювати, що взагалі здається неможливим. Але чи завжди під час реалізації проєкту на нас чекає такий «дурдом-сонечко», чи може є якісь best practices, що можуть суттєво полегшити життя? І ось тут на допомогу приходять методології розробки, які, звичайно, з’явились не одразу…

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

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

Річ у тім, що кожний продукт є унікальним: має певну мету, виконується певною командою, повинен бути виготовлений за певні строки, на нього виділено певний бюджет і так далі. Тобто не можна Chat-GPT робити так само як і Privat24: різні сфери, різні бюджети, різні команди, різні строки – все різне. І як же ж тепер бути? Невже забути про чудовий, зручний SDLC та «винаходити лісапед» під кожний проєкт?

Звісно, ні, просто SDLC треба трохи модифікувати: підкорегувати послідовність етапів, додати  зменшити кількість процесів або ролей у команді й таке інше, — так би мовити, зробити з «базової» версії «адаптовану». І ось ця «адаптована» версія і буде методологію розробки.

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

Цікавий факт:

Термін «методологія» був запозичений з інших галузей знань, зокрема наукових досліджень. Потрібно було знайти слово, яке б описувало формалізований набір правил і методів для розробки ПЗ. Тоді вчені запозичили слово ‘методологія’ з науки, де воно означає сукупність методів, принципів та підходів у певній галузі діяльності. Цей термін буквально означає «наука про методи».

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

Як ви вже могли помітити, титульне зображення та назва цього матеріалу мають чітке відсилання до однієї з найпопулярніших медіафраншиз 1990х-2000х років – TMNT (Teenage Mutant Ninja Turtles), тобто славетних черепашок-ніндзя. Мабуть, усі, а особливо діти 2000-х, чули цікаву історію про чотирьох підлітків черепашок-мутантів, яких шур-сенсей навчив японського бойового мистецтва, ніндзюцу. Але як ці спортивні представники фауни пов’язані із розробкою ПЗ

Так, можливо, з першого погляду спільні риси майже не помітні, але, якщо трохи «копнути»:

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

2) Обидва передбачають ключових осіб. У TMNT це — Леонардо, Донателло, Рафаель і Мікеланджело, а розробці – це бізнес-аналітики, архітектори, програмісти, тестувальники тощо.

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

4) Сюжетний успіх персонажів і розробка ПЗ залежить від командної роботи. Черепашки діють разом і доповнюють один одного, так само й успішне ПЗ вимагає злагодженої команди фахівців.

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

Цікавий факт:

За роки існування франшизи було створено чимало її різних інтерпретацій та версій персонажів у різних всесвітах:
– Класична версія черепашок з оригінальних коміксів та мультфільмів 1987-1996 років.
– Версія з реалістичним дизайном з фільмів з живими акторами 2007 та 2016 років.
– Версія 2012-2017 років з CGI-мультсеріалів студії Nickelodeon.
– Версія Netflix 2018 року з нового мультсеріалу Rise of the Teenage Mutant Ninja Turtles.
– Версії з ігор від Konami, Ubisoft та Activision, які часто мали власний унікальний дизайн.
– Версії з кросоверів, таких як з мультсеріалами чи фільмами про Бетмена, Месників та ін.
Таким чином, можна нарахувати як мінімум 6-7 популярних унікальних інтерпретацій черепах-ніндзя, а з усіма дрібними варіаціями їх число сягає кількох десятків.

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

Частина 2: Найпоширеніші методології та варіанти класифікації

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

З огляду на це, у більшості читачів може з’явитись цілком доречне питання: «Як тоді обрати потрібну методологію серед сотні можливих і не помилитись?». Одразу можу сказати, що все не так складно, як може здаватись. Річ у тім, що серед усієї сотні методологій лише 10-15 основних типів, а все решта – їх адаптації під певні види проєктів, тому для вірного вибору достатньо розуміти різницю між основними методологіями, пам’ятати про їх переваги й недоліки, а також враховувати специфіку проєкту.

Цікавий факт:

Хибно обрана методологія створення продукту критична не тільки в ІТ-галузі, а й в будь-якій іншій. У 2013 році студія Paramount анонсувала новий фільм про черепашок-ніндзя за участі Майкла Бея (режисер Трансформерів). Однак злитий в мережу сценарій викликав таку критику з боку фанатів через радикальні зміни в історії та характерах персонажів, що студія була змушена відмовитись від проєкту. Так відмова від ключових для продукту речей (в цьому випадку класичного сюжету) поставила хрест на амбітному проєкті та його зірковій команді.

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

Саме тому я пропоную розглянути найбільш популярні методології (їх ще називають моделями), обов’язково торкаючись переваг, недоліків та прикладів застосування кожної:

1. Waterfall (каскадна модель або «водоспад»)

Одна з найдавніших методологій для розробки ПЗ. Як може бути зрозуміло з назви, ця модель передбачає поступове переміщення по етапах життєвого циклу (наче вода по уступах водоспаду), але кожен наступний етап стартує тільки тоді, коли закінчено попередній.

Переваги:

• Просте управління розробкою за наявності чітко сформульованої документації
• Вартість і терміни відомі на початковому етапі
• Низька ймовірність помилок у невеликих проєктах
• Тестування можуть проводити люди з нижчою кваліфікацією (через гарну документацію)

Недоліки:

• Тестування відбувається на останніх етапах
• Що масштабніше проєкт, то більша ймовірність критичних помилок, виправлення яких потребуватиме значного збільшення бюджету
• Замовник бачить готовий продукт лише наприкінці розробки.
• Список вимог не можна скоригувати в будь-який момент

Таким чином, для невеликих проєктів з відносно малими термінами реалізації та грамотно складеної документації каскадна модель — найкращий вибір (наприклад, розробка електронної бібліотеки для освітнього закладу). Однак що проєкт більший, то більший ризик помилитися в якийсь момент і отримати на виході не те що потрібно.

2. V-Model (розробка через тестування)

Ця модель є модифікованою версією «водоспаду». V стоїть у назві від двох головних принципів цієї методології – validation і verification. Тут процеси відбуваються один за одним, проте на кожному етапі присутній елемент тестування, тобто продукт піддається ретельним перевіркам уже на початкових етапах.

Переваги:

• Тестування проходить на всіх етапах розробки
• Імовірність помилок зводиться до мінімуму

Недоліки:

• Потрібен високий рівень кваліфікації тестувальників та їхня висока зайнятість
• Якщо помилки все ж таки припустилися, то повернутися до попереднього етапу буде навіть дорожче, ніж на каскадній моделі

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

3. Incremental Model (інкрементна модель)

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

Переваги:

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

Недоліки:

• Вимоги до проєкту на кожному етапі мають бути чітко визначені та зрозумілі
• Необхідний хороший менеджмент
• Застосунок може вийти занадто “сирим” і не дожити до появи всіх функцій

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

4. RAD (Rapid Application Development або швидка розробка)

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

Переваги:

• Швидкі темпи розробки
• Економія ресурсів шляхом повторного використання компонентів
• Тісна взаємодія з замовником

Недоліки:

• Потребує кваліфікованої команди
• Ризик неправильного розуміння вимог
• Обмеження у масштабуванні та сумісності

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

5. Iterative model (ітеративна модель)

Назва походить від англійського слова «iteration», що перекладається як «повторення, ітерація». Ця модель якраз і базується на повторюваних циклах розробки. Кожен цикл проходить усі фази: від аналізу до тестування та виправлення помилок. Результатом ітерації є робоча версія програмного продукту з базовим набором функцій, а на наступних циклах ця версія вдосконалюється. Така побудова процесу дозволяє гнучко реагувати на зміну вимог, вчасно виправляти помилки та демонструвати замовнику проміжні результати.

Переваги ітераційної моделі:

• Можливість раннього тестування та виправлення помилок
• Гнучкість та адаптивність до змін
• Простіший контроль якості робочого продукту
• Регулярний зворотний зв’язок від клієнтів

Недоліки:

• Складно оцінити час та вартість всього проєкту
• Потребує кваліфікованої команди
• Частіші випуски оновлень для клієнтів

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

6. Prototype model (прототипування)

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

Переваги:

• Рання перевірка концепції та дизайну системи
• Залучення користувачів на ранніх стадіях
• Скорочення ризиків та невизначеності вимог

Недоліки:

• Витрати часу та ресурсів на «тимчасовий» продукт
• Ризик надмірного захоплення прототипом
• Труднощі масштабування на великі проєкти

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

7. Spiral model (спіральна модель)

В основі цієї методології лежить розподіл проєкту на окремі цикли-спіралі, кожна з яких складається з чотирьох фаз:

1. Ідентифікація цілей, альтернатив рішень
2. Оцінка варіантів, аналіз ризиків
3. Розробка та тестування прототипів
4. Планування наступного циклу

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

Переваги:

• Управління ризиками
• Гнучкість
• Постійний прототип для перевірки

Недоліки:

• Тривалий розвиток
• Складне прогнозування термінів та вартості

Отож, ця модель ефективна для великих проєктів в умовах високої невизначеності, де критично управляти ризиками ітеративно. Наприклад, розробка складної корпоративної системи обліку.

8. FDD (Feature-Driven Development або модель орієнтована на функціональність)

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

Переваги:

• Масштабованість
• Прогнозованість
• Врахування змін вимог протягом розробки

Недоліки:

• Вимагає досвіду від команди
• Не підходить для невеликих простих завдань

Отож, FDD доцільно застосовувати у великих проєктах зі складною бізнес-логікою та ймовірними змінами специфікацій. Наприклад, розробка онлайн-банку.

9. RUP (Rational Unified Process model або модель уніфікованого процесу розробки)

Методологія, створена компанією Rational Software, – це ітераційний інкрементний підхід, що включає елементи моделювання, управління вимогами, архітектурного проєктування тощо. Особливості RUP: сувора регламентація процесів, фаз та артефактів розробки за допомогою шаблонів і документації.

Переваги:

• Дисциплінованість
• Керованість
• Можливість масштабування проєктів

Недоліки:

• Значні витрати на підготовку документації
• Потребує досвідчених фахівців
• Не годиться для невеликих і швидких проєктів

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

10. XP (Extreme Programming або модель екстремального програмування)

Назва пов’язана з екстремальними умовами розробки — обмежені строки, відсутність чітких вимог, високі ризики. Модель базується на ітеративній розробці з короткими циклами, фокусом на програмний код та тісною взаємодією в команді та з замовником. Особливості XP: парне програмування, безперервне тестування, щоденні зустрічі, спільне розміщення фахівців тощо.

Переваги:

• Швидкість релізів
• Гнучкість
• Низька кількість дефектів
• Економія на документації

Недоліки:

• Потребує професіоналів у команді
• Складно масштабувати на великі проєкти
• Бракує документації для подальшої підтримки

Таким чином, XP ідеально підходить для невеликих та середніх за масштабом проєктів з жорсткими термінами та мінливими вимогами. Наприклад, стартап, що потребує швидкого розгортання системи та отримання зворотного зв’язку від користувачів.

11. DSDM (Dynamic Systems Development Method або модель гнучкої розробки динамічних систем)

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

Переваги:

• Швидкість розробки
• Передбачуваність результатів
• Задоволення бізнес-потреб

Недоліки:

• Обмеження у масштабуванні
• Висока залежність від команди

Тож, DSDM підходить для невеликих і середніх бізнес-орієнтованих проєктів з жорсткими термінами. Наприклад, створення системи управління ланцюжком постачання.

12. Scrum

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

Основа Scrum – самоорганізовані перехресні команди (5-9 осіб), що складаються зі скрам-майстра (координатор), власника продукту (представляє інтереси бізнесу) та команди розробки. Така кросфункціональна взаємодія дозволяє ефективно працювати над проєктом в умовах жорстких часових обмежень конкретного спринту.

Переваги:

• Висока швидкість розробки та регулярне оновлення продукту
• Можливість швидко реагувати на зміну вимог
• Підвищена мотивація та продуктивність команди
• Частий зворотний зв’язок та оцінка прогресу з боку зацікавлених осіб

Недолік:

• необхідна спеціально підготовлена команда
• не працює на невеликих та простих проєктах

Таким чином, Scrum широко та успішно застосовується по всьому світу як ефективна гнучка модель для розробки складних програмних систем середнього та великого масштабу. Гарним прикладом застосування є розробка комп’ютерних ігор, зокрема MMO чи RPG жанрів.

Отже, ми розглянули 12 найвідоміших методологій розробки ПЗ, розуміння яких неодмінно стане у приході як новачкам, так і більш досвідченим фахівцям. Але у деяких допитливих читачів може з’явитись питання: «А ми щось про Agile чули, може це 13-та методологія, яку ти випадкового загубив?».

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

Основні ідеї Agile:

• Люди й взаємодія важливіші за процеси та інструменти
• Справний продукт важливіший за вичерпну документацію
• Співпраця із замовником важливіше узгодження умов контракту
• Готовність до змін важливіше проходження попереднім планом

Стосовно ж моделей, що відносяться до Agile, то про RAD, RUP, XP, DSDM та Scrum ми вже поговорили, а ось про славнозвісний Kanban ще не встигли.

Насправді ж, Kanban – не методологія розробки, а методологія управління, яка може бути застосована в різних галузях, а не тільки в галузі розробки програмного забезпечення, але вона так сталося, що вона «осіла» у нас.

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

Переваги:

• Візуалізація поточного статусу завдань
• Обмеження багатозадачності, фокус на завершенні розпочатого
• Гнучке реагування на зміни та вдосконалення процесів

Недоліки:

• Потребує самоорганізованих команд
• Не дає чітких рекомендацій щодо організації робіт

Отже, Kanban – є простим та дієвим підходом для управління та постійного вдосконалення будь-яких ітеративних процесів, у тому числі в IT-проєктах.

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

За порядком виконання етапів:

• Послідовні (один за одним): каскадна
• Ітераційні (повторювані цикли): ітераційна, спіральна, RUP, XP
• Інкрементні (новий функціонал на кожному етапі): DSDM
• Еволюційні (початок з прототипів): прототипування

За ступенем гнучкості:

• Жорсткі (як почали, так і закінчимо): каскадна
• Гнучкі (адаптація під зміни): FDD, XP

За фокусом:

• Орієнтовані на процес (зосереджені на послідовності фаз): V-model
• Орієнтовані на продукт(зосереджені на вдосконаленні продукту): XP, RUP

Підсумки

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

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

У першій частині мова спочатку йшла про те, як люди спочатку дійшли до SDLC (роботи — хоч греблю гати, фахівці-першоходи, методи «наукового тику» та «спроб і помилок»), а потім вже і до методологій розробки («базова» і «адаптована» версії). Далі розглянули визначення методології (сукупність процедур, правил, рекомендацій та засобів, що визначають послідовність дій при створенні продукту) та спробували оцінити поточну кількість (близько 100). На завершення розібрали спільні риси між франшизою TMNT та методологіями (сталість етапів та дієвих осіб, послідовність, командна робота, підхід до будь-якого клієнта).

Другу частину почали з обґрунтування важливості вірного вибору методології та визначення зони відповідальності за цей процес (це справа керівника проєкту, але і нам треба розумітися на цьому). Далі розглянули питання механізму вибору (специфіка продукту та переваги/недоліки методологій), для повного розкриття якого перейшли до розгляду найпопулярніших моделей розробки (Waterfall, V-Model, Incremental Model, RAD, Iterative model, Prototype model, Spiral model, FDD, RUP, XP, DSDM, Scrum). Також трохи поговорили про Agile (ціла філософія), його ідеї (люди важливіші за процеси; продукт важливіший за документацію; співпраця важливіше контракту; готовність до змін важливіше проходження плану) та з’ясували, до чого тут Kanban (методологія управління через дошку). Наприкінці частини запропонували можливі класифікації методологій (за порядком виконання етапів, за ступенем гнучкості, за фокусом).

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

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

Тож, бажаю шановним читачам правильно застосовувати не тільки методології та контент, а навіть різноманітні інструменти, бо інакше завжди щось буде іти не за планом!