Це — доповнений модифікований переклад https://stackify.com/what-is-sdlc/

Життєвий цикл розробки програмного забезпечення (SDLC, software development lifecycle) — це про те, як треба нормально робити програмні продукти, щоб було і дешевше, і якомога більш якісно, і вчасно.

Програміст не тільки повинен писати код, але й розуміти для чого все це робиться.
Зазвичай, мета — розробити продукт, щоб він приносив $$$ власникам бізнесу.

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

Загальний сенс SDLC — робити по черзі та не пропускати такі етапи:

  • Аналіз потреб
  • Планування
  • Дизайн (тут більше про опрацювання архітектури)
  • Розробка — тут нарешті пишуть код 😉
  • Тестування
  • Запуск (деплой)
  • …. отримуємо результат/дані, а отже нові проблеми/завдання, і повертаємось на початок.

SDLC має кілька підвидів, див. наприкінці статті.

Пробіжимося по життєвому циклу

Починаючи проєкт, команда намагається зрозуміти, абстрактно, чого не вистачає і що має з’явитися/помінятися. (оскільки ми говоримо про розробку ПЗ, то зазвичай користувачеві чогось не вистачає, і вирішенням його проблеми має стати програмний продукт — сайт, додаток, т.д.)

Потім потрібно розробити вимоги.

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

… от і все 🙂

Методологія SDLC допомагає уникнути дорогих помилок (в сенсі ресурсних та репутаційних втрат), типу ігнорування процедури отримання відгуків від клієнта та користувачів.

SDLC підтримує тестування та ітерування. Більше тестування – менше виправлянь, витрат часу/грошей/репутації.

Більш докладно по кожному етапу

Аналіз потреб — Requirement analysis

"Які проблеми збираємося вирішувати?" — необхідно витягнути вхідну інформацію від усіх зацікавлених сторін (стейкхолдерів), включаючи покупців, продавців, експертів та програмістів. Виясніть сильні та слабкі сторони того, що маємо зараз, щоб зрозуміти, що потрібно вилучити/змінити — це і буде метою.

Детальніше про аналіз потреб
(здавалось би, яке це має відношення до програміста?…

Три великих питання

  1. Які потреби у користувачів?
  2. Як краще задовольнити ці потреби?
  3. Як покращити технічну продуктивність?

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

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

Питання юзерам:

  • Чого ти хочеш досягти за допомогою продукту? — критичне питання, щоб розуміти причини важливості продукту для користувача
  • Який твій улюблений аспект? — щоб сфокусуватися на найважливішому
  • Який менш улюблений аспект? — Будь готовий слухати
  • Яких хочеш покращень? — Корисно, але користувачі не завжди знають чого хочуть
  • Наскільки порадиш продукт друзям/колегам? — потужний метод для отримання NPS — розуміння реального вдоволення користувачів та знаходження фанатів. Бали 9-10 означають що юзери є “промоутером”, всім про товар розповідають. 7-8 пасивні, навряд чи щось кажуть. 1-6 — незадоволені і можуть навіть відмовляти інших від продукту. Не забувайте ставити питання “Чому?” щоб розуміти контекст оцінки

Питання розробникам:

  • Які найпопулярніші запити на фічі? — якщо якась фіча запитується частіше, ніж інша, значить, вона потрібніша.
  • Які зараз баги? — Чи були серйозні рішення? Чи можна щось змінити, щоб якихось категорій помилок поменшало?
  • Чи є можливість порефакторити? — Перша версія продукту завжди всередині виглядає жахливо. Все може працювати, але це не триватиме вічно. Гугліть “технічний обов’язок”. Тож треба вкладати сили у шліфування та переписування коду і навіть процесів.
  • Які фічі принесуть найбільшу користь? — Фіч завжди багато, треба виставляти пріоритети.

Питання менеджерам:

  • Які бізнес-мети ми збираємося досягти цим продуктом? — з точки зору бізнесу будь-який продукт пов’язаний з високорівневою бізнес-метою: гроші, нові клієнти, утримання поточних клієнтів тощо.

Запитання до людей, що продають:

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

Питання експертам індустрії:

  • Що буде трендовим наступного року? — для високорівневих стратегій
  • Чи є зараз в індустрії якісь незайняті ніші? — рідкісна цінна інформація

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

Джуніор програмісти тут не беруть участі, але все ж важливо розуміти для вирішення яких потреб якої аудиторії роблять продукт.

Планування — Planning

"Чого ми хочемо" — Команда визначає ціну та ресурси, необхідні для задоволення потреб, які стали відомі завдяки попередньому крокові. Також прораховуються ризики та розробляються субплани для зменшення ризиків.

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

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

Дизайн

"Як ми отримаємо те чого хочемо?" — специфікації з попереднього кроку перетворюємо на план розробки (design plan, Design specification). Потім усі сторони вивчають план, дають відгуки та поради. Важливо мати такий план, щоб зібрати більше вступних даних від усіх, у цей же документ. Фейл на цьому кроці обернеться великими витратами або, можливо, навіть колапсом проєкту.

Розробка — Development

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

Наприклад, визначте стиль іменування змінних та структури директорій. Це допоможе видавати організований та цілісний код, який простіше розуміти та тестувати. Справжні гайдлайни – звичайно не про такі прості речі.

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

Щоб розробка йшла чітко, використовують будь-які системи управління завданнями типу Jira/redmine/Trello (ось приклад дошки). Розробникам зрозуміло що робити, менеджери контролюють процес.

У більш-менш організованих команд весь код осідає в GIT (що це?), а фічі та багофікси від розробників поєднуються через pull(merge) requests (читайте про них перші пару розділів тут). До речі, Ш++ має окремий мінікурс з гіту.

Тестування

"Ми отримали те, що хотіли" — тут ми тестуємо на предмет недоліків і дефектів. Виправляємо їх, доки продукт не стане відповідати оригінальним специфікаціям.

Грубо кажучи, ми хочемо домогтися, щоб код відповідав вимогам які до нього висуваються.

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

Іноді програмісти вважають, що їх завдання писати код, а не тестувати його. З такими людьми важко працювати.

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

Іноді старші менеджери самі тестують продукт, не довіряючи решті, і тоді розробники можуть отримати по голові, тому що недовіра може бути обґрунтованою.

Деплой (Запуск, розгортання) — Deployment

"Тим, що ми зробили, повинні почати користуватись" — треба запустити розроблений продукт, щоб реальні користувачі почали користуватися. Зазвичай це встановлення на серверах, або в kubernetes кластерах (не гугліть), або заливка аплікухи в app store. Для того, щоб розгортати інфраструктури, існують навіть спеціальні проєкти типу terraform (тут описуються всі ресурси, від серверів до доменних імен, і тераформ це все підіймає в хмарах автоматично і пов’язує один з одним)

Багато організацій також вибирають поетапний деплой — спочатку розгортають продукт в тестових середовищах, але де можна його повністю випробувати з користувальницької точки зору (testing / staging середовище).

Добре, коли будь-який розробник отримує можливість легко розгорнути частину інфраструктури у себе на машині. Зараз дуже люблять docker для цього. Не “шарити” в докері для веброзробника (бекендщика) — це означає бути нездатним до більш-менш організованої/дорослої розробки в команді.

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

Додатково — підтримка розробленого продукту

"Давайте доводити продукт якомога ближче до того вигляду, якого ми реально хочемо" — продукт стикається з реальним світом, знаходяться баги та з’являються запити на фічі. Деякі команди вважають за краще робити продукт у режимі: зроблю все як домовилися, ти (замовник) схвалиш, і тоді віддаю код/документацію/доступи і бувай-бувай 🖖. В інших випадках домовляються про те, що розробник не зникне і підтримуватиме продукт. Навіть години наперед резервують і оплачують, щоб у розробників був час.

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

Приклади/типи SDLC

Основні:

  • Waterfall (водоспад) — найстаріша та найпряміша модель. Закінчуємо одну фазу і починаємо наступну. Кожна фаза має “мініплан” та впадає в іншу. Проблема в тому, що дрібні деталі можуть затримувати весь процес. Всі лаються на waterfall.
  • Agile (читається Еджайл) — розбиває продукт на цикли та доставляє продукт швидко. На кожному циклі щось релізиться (release, реліз кінцевого продукту), збираються відгуки, які впливають на наступні версії продукту. Можливий мінус — залежність від фідбека користувача може призвести до того, що продукт піде не в тому напрямі.
    ☝️ Весь світ за Agile, соромно не знати, що таке Agile.
  • Big Bang (Великий вибух) — модель з високими ризиками, коли всі ресурси кидаються на розробку, без аналізу потреб. Добре для маленьких команд.
    … 😈 тому що ми хочемо, блін, код писати, а не ось це все!

Ще трохи для теоретиків:

  • Iterative — ця модель наполягає на швидких циклах. Швидко та дешево створюємо версії, швидко тестуємо, швидко виправляємо та постійно робимо все кращі і кращі версії продукту. Такі темпи можуть швидко з’їсти ресурси, якщо не слідкувати за цим.
  • V-Shaped (в-формі-літери-V) — схожий на Waterfall, але тестування відбувається в кінці кожного кроку. Проблема знову ж таки у можливості виникнення блокувань.
  • Spiral (Спіральна модель) — найгнучкіша з усіх, схожа на ітеративну модель. Йде через планування-дизайн-розробку-тестування знову і знову, з поступовими поліпшеннями на кожному витку.

Ось ще одна рандомна стаття на цю тему, там згадується важливе слово “Scrum”.

Переваги SDLC

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

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

SDLC буде працювати якщо дотримуватися тому що було описано 🙂
та всіх етапів.
(цікаво, як часто дотримуються всіх етапів?)

Підсумки

Розумні люди зрозуміли, що якщо хочеш зробити норм продукт, то треба підходити до розробки ґрунтовно, поступово і прислухаючись до всіх учасників на всіх етапах, а не одразу кодити, і не відразу все кодити, і не відразу ідеально кодити.

Якщо програміст/менеджер не сприймає ці етапи і не спілкується такою мовою, то його орієнтованість на загальний для всіх результат — сумнівна.