.png)
У цій статті ми розповімо про поняття життєвого циклу програмного забезпечення, його моделі, а також про основні принципи та методології розробки програмного забезпечення. Розуміння різних варіантів організації розробки допоможе вам краще керувати ресурсами та проектом.
У програмного забезпечення, як у живої істоти є свій життєвий цикл. Життєвий цикл ПЗ - стадії, що проходить програмний продукт від появи ідеї до її реалізації в коді, імплементації у бізнес і подальшої підтримки. Моделі життєвого циклу багато в чому зумовлюють і методології розробки ПЗ.
Зазвичай до етапів життєвого циклу відносять:
Але це не повний перелік.
Існує деяка варіативність у проходженні етапів ЖЦ під час розробки та впровадження продукту на ринок. Для кожного продукту це відбувається по-своєму, але щоб цим якось керувати були сформульовані моделі життєвого циклу ПО - спрощене й узагальнене уявлення про те, як розвивається продукт. У реальності життя продукту не відповідає моделі.
Давайте посмотрим на них подробнее и разберемся что в них общего, а что отличается.
Серед моделей життєвого циклу програмного забезпечення найбільш відомі такі:
Давайте подивимося на них докладніше і розберемося, що в них спільного, а що відмінного.
За великим рахунком всі моделі можна розділити на дві великі групи: послідовні та ітераційні моделі.
Основна суть моделі Waterfall у тому, що етапи залежать один від одного і наступний починається, коли завершений попередній, утворюючи таким чином поступальний (каскадний) рух уперед.
Паралелізм етапів у каскадній моделі, хоч і обмежений, але можливий для абсолютно незалежних між собою робіт. При цьому інтеграція паралельних частин все одно відбувається на якомусь наступному етапі, а не в рамках одного.
Команди різних етапів між собою не комунікують, кожна команда відповідає чітко за свій етап.
Недоліками цієї моделі є отримання результату по проходженню всіх етапів і складність виявлення помилок. Повертатися назад важко. Не зрозуміло що повертати: якщо стався збій на якомусь етапі, його наслідки видно тільки в кінці.
Для замовників дана модель виглядає лінійно і з боку досить просто: за завершеним етапом проектування слідує програмування, а потім тестування - і так крок за кроком поки не буде досягнута фінальна точка і мета, заради якої ведеться розробка.
Дана модель зрозуміло і чисто вкладається в документи, наприклад в договори і роадмапи при наявності чітко визначених контрольних точок. У будь-який момент можна легко зрозуміти чи була пройдена та чи інша точка контролю чи ні, і чи дотримані терміни. З цих причин довготривалі і особливо великі проекти, розраховані на десятиліття і залучення великої кількості організацій-учасників, керуються переважно waterfall.
Однак уявлення про простоту каскадної моделі є ілюзорним. Воно з'являється через обмежене бачення клієнтом всього процесу, адже дана модель не має на увазі залучення замовника в деталі процесів розробки і демонструє зрозумілий і кінцевий результат роботи тільки на контрольних точках і в кінці проекту.
У реальності каскадну модель не можна назвати простою, на практиці нею складно керувати. Внесення замовником значних змін під час процесу розробки по waterfall або спрацьовування серйозних, не передбачених проектом ризиків несуть руйнівний характер для всього процесу - модель доводиться перебудовувати, графіки перепланувати.
.png "Каскадна модель ЖЦ")
Ітераційна модель передбачає розбиття проекту на частини (етапи, ітерації) і проходження етапів життєвого циклу на кожному з них. Кожен етап є закінченим сам по собі, сукупність етапів формує кінцевий результат.
Пояснимо розбиття на етапи на побутовому прикладі. Припустимо, нам потрібен стіл у вітальню.
На кожній ітерації ми працювали з одним і тим же продуктом і в кінці кожної ітерації отримували результат, яким можна користуватися (звісно з певними обмеженнями).
З кожним етапом розробка наближається до кінцевого бажаного результату або уточнюються вимоги до результату по ходу розробки, і відповідно в будь-який момент поточна ітерація може виявитися останньою або черговою на шляху до завершення.
Даний підхід дозволяє боротися з невизначеністю, знімаючи її етап за етапом, і перевіряти правильність технічного, маркетингового або будь-якого іншого рішення на ранніх стадіях.
Використання ітераційної моделі знижує ризики глобального провалу і розтрати всього бюджету, отримання несинхронізованих очікувань і помилкового розуміння процесів як клієнтом, так і кожним учасником команди розробки. Воно також дає можливість завершення розробки в кінці будь-якої ітерації (в каскадної моделі ви повинні перш за завершити всі етапи).
Ітераційна модель наприклад застосовувалася при розробці системи дистанційного навчання проекту Джерело. Детальніше про розробку чату Джерело можна почитати тут.
Спіральна й інкрементна моделі є видами ітераційної моделі життєвого циклу.
Що ж таке спіральна модель?
Усі етапи життєвого циклу при спіральної моделі йдуть витками, на кожному з яких відбуваються проектування, кодування, дизайн, тестування і т. д. Такий процес відображає суть назви: піднімаючись, проходиться один виток (цикл) спіралі для досягнення кінцевого результату. Причому не обов'язково, що один і той же набір процесів буде повторяться від витка до витка. Але результати кожного з витків ведуть до головної мети.
Тепер поговоримо про інкрементну модель.
Принцип, що лежить в основі інкрементной моделі, має на увазі розширення можливостей, добудовування модулів і функцій програми. Буквальний переклад слова інкремент: «збільшення на один». Це «збільшення на один» застосовується в тому числі для позначення версій продукту.
Якщо в каскадній моделі по суті є двома стани продукту: «нічого» і «готовий продукт», то з появою ітераційних моделей стало застосовуватися версіонування продукту. Кожна ітерація позначається цифрою: 1,2,3 і відповідно продукт після кожної ітерації має версію з відповідним номером: v.1, v.2, v.3. Числами після слова версія позначають масштабні зміни в ядро продукту.
А коли одна з версій експлуатується, наступна, з огляду на недоліки попередньої, тільки планується або вже розробляється, а поліпшення замовнику і користувачеві хочеться доставити прямо зараз, тоді з'являються мінорні версії. Туди потрапляють зміни, що не впливають на ядро розробки і представлені як під-версії 1.1,1.2,1.3 або релізи 1.1.1, 1.1.2 і т.п.
У сукупності такі поетапні релізи призводять до повноцінної версії 2.0.
Почнемо з Agile.
Agile - набір принципів гнучкої розробки (всього їх 12) та ідей. Основні ідеї Agile:
Один з принципів - взаємодія - має на увазі, що замовник взаємодіє з командою, команда з замовником - усі між собою. Це дозволяє обмінюватися досвідом між учасниками команди і клієнтом і кожному з них впливати на прийняття рішень. За рахунок такого підходу знижуються ризики втрати часу і грошей і підвищується здатність команди вирішувати складні нестандартні завдання з високим ступенем невизначеності.
Однак взаємодії всіх і з усіма можуть вилитися у хаос, що впливає на всі сфери розробки. Тому використовуючи Agile потрібно розуміти обмеження: команди повинні бути невеликі, учасники повинні бути компетентні та мотивовані, ітерації короткі з максимально зрозумілими цілями, встановлені чіткі обмеження за часом і кінцевий результат повинен бути очевидним.
Agile чудово справляється з невизначеністю, зумовлюючи майбутнє на більш короткий період. Правило таке: чим вища невизначеність - тим коротша ітерація, причому її тривалість може бути навіть у рамках 24 годин, як і відбувається на хакатоні. На початку кожної ітерації неминуче виконується контроль, ретроспектива, оцінка та аналіз результатів, планування наступної ітерації.
У внутрішньому плануванні та у продуктовій розробці без цього принципу й елементів Agile не обійтися.
Тепер поговоримо про Lean.
Ідея підходу Lean полягає в тому, що ми ощадливо ставимося до ресурсів (у тому числі часу) і вирішуємо завдання найпростішим способом. Наприклад: ми не робимо весь продукт, щоб зрозуміти, що він нікому не потрібен - ми робимо лендінг і форму підписки і даємо на нього рекламу, щоб перевірити, що цей продукт викликає інтерес клієнтів і прийняти усвідомлене рішення про необхідність розробки.
Коли доходить до розробки продукту, або робиться якесь поліпшення, виробниче або інженерне, ми спочатку робимо його MVP (minimum viable product). Термін MVP зараз широко поширений і застосовується повсюдно, але він народився саме з Lean підходу. MVP - така версія продукту, що виконує свою головну функцію і при цьому її не відхиляють клієнти і визнають її корисність. Звичайно, її можна покращувати і покращувати, але загалом продукт на стадії MVP повинен бути корисним, зрозумілим клієнтові і таким, щоб можна було прийняти рішення про його подальших поліпшень або визнати експеримент невдалим і тестувати нову гіпотезу, витративши при цьому якомога менше ресурсів.
Загалом Lean підхід орієнтується на тестування потреб і цінностей і потрапляння в очікування ринку мінімальними засобами. Lean-підхід не про "технічні" проблеми і їхні рішення інженерними засобами, а про підприємницькому підході до вирішення завдань. Lean передбачає, що команда шукає найпростіше рішення для досягнення результату: технічно, організаційно і т.п., спрощуючи все, що не є дійсно важливим.
У спрощенні сила і головна "пастка" Lean: прагнення все спростити іноді призводить до ситуацій, в яких продукт спрощують настільки, що губляться дійсно важливі функції і продукт по суті виявляється непотрібним, оскільки не несе цінності користувачеві.
Наостанок про Lean хочеться додати: часто, коли говорять про Lean, кажуть, що "Lean — про те, щоб замість сервісу зробити лендінг із формою контактів". Ні, це не Lean. Таке тестування не суперечить Lean, але Lean-методологія пропонує набагато більше прийомів, ніж цей, і варта детального вивчення.
Нижче наведено короткий огляд основних гнучких методологій розробки з описом їхньої суті. Огляд не претендує на повноту, але дає загальне уявлення, що взагалі існує.
Scrum методологія ґрунтується на понятті спринту (sprint), протягом якого виконується робота над продуктом. Перед початком кожного спринту проводиться планування (Sprint Planning), на якому проводиться оцінка вмісту списку завдань із розвитку продукту (Product Backlog) і формування беклога на спринт (Sprint Backlog), у рамках яких і діє команда. Для спринту завжди існують обмеження по часу, зазвичай від тижня до місяця. Життя продукту таким чином розбита на рівні по тривалості спринти.
За Kanban методологією проект ділиться на етапи, що візуалізуються у вигляді канбан-дошки. Етапи, це наприклад: планування, розробка, тестування, реліз і т.п. Завдання у вигляді "карток" переміщуються з етапу на етап. Нові завдання можна додавати у будь-який час. Завдання закривається не по закінченню конкретного часу, а по зміні статусу на "завершено". Kanban — методологія з концепції "ощадливого виробництва".
RUP (Rational Unified Process) - розробка продукту за даним методом складається з чотирьох фаз (початкова стадія, уточнення, побудова, впровадження), кожна з яких включає в себе одну або декілька ітерацій. RUP величезна методологія, котру важко описати одним абзацом тексту, але методи, рекомендовані RUP засновані на статистиці комерційно успішних проектів.
DSDM (Dynamic Systems Development Model) - методологія, що демонструє набір принципів, визначених типів ролей і технік.
Принципи спрямовані на головну мету - здати готовий проект вчасно і вкластися у бюджет, з можливістю регулювати вимоги під час розробки. DSDM належить до гнучких методологій розробки програмного забезпечення, а також розробок, що не входять у сферу інформаційних технологій.
RAD (Rapid Application Development) - методологія швидкої розробки додатків, що передбачає застосування інструментальних засобів візуального моделювання (прототипування) і розробки. RAD передбачає невеликі команди розробки, терміни до 4 місяців й активне залучення замовника з ранніх етапів. Дана методологія спирається на вимоги, але також існує можливість їхніх змін під час розробки системи. Такий підхід дозволяє скоротити витрати і звести час розробки до мінімуму.
XP (Extreme Programming) - методологія, орієнтована на постійну зміну вимог до продукт, пропонує 12 підходів для досягнення ефективних результатів у подібних умовах. Серед них:
Незважаючи на безліч досліджень, думка про ефективність методик, принципів і методологій часто ґрунтується на особистому досвіді, емоційному відгуку і компетенціях менеджера, який їх застосовував. І не завжди вподобана з опису модель буде найкращою для реалізації саме вашого проекту. Тому, чим більше ви знаєте методологій і підходів, тим вище ваша здатність керувати проектами, комбінуючи кращі практики.
Хочете поговорити про те, як найкраще побудувати управління вашим проектом? Пишіть!
