SDLC

SDLC (Software development lifecycle) - Життєвий цикл розробки програмного забезпечення⚑

Життєвий цикл ПЗ⚑

Всі речі (і не тільки) мають свій життєвий цикл, протягом якого змінюються, навчаються, розвиваються, вдосконалюються. Програмне забезпечення також має свій життєвий цикл – SDLC.

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

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

Фази SDLC

Планування системи Фаза планування – найбільш важливий і критичний крок у створенні успішної системи. На цьому етапі:
точно вирішується що саме потрібно зробити, розробити, які проблеми вирішити, які потреби закрити;
визначаються проблеми, цілі і ресурси (таких, як персонал і витрати);
вивчаються можливості альтернативних рішень шляхом зустрічей з клієнтами, постачальниками, консультантами та співробітниками;
вивчається, як зробити продукт краще, ніж у конкурентів. Після аналізу цих даних буде три варіанти: розробити нову систему, покращити існуючу або залишити систему як є. На цьому етапі надзвичайно важлива комунікація з замовником.
Аналіз системи Необхідно визначити і задокументувати вимоги кінцевого користувача системи – в чому його очікування і як їх здійснити. Крім того, для проекту робиться техніко-економічне обґрунтування, яке з'ясовує, чи є проект організаційно, економічно, соціально, технологічно здійсненним. Дуже важливо підтримувати хороший рівень комунікації з замовниками, щоб переконатися, що у вас є чітке бачення кінцевого продукту і його функцій. Адже скільки людей, стільки й думок, важливо дійти до спільного знаменника.
Дизайн системи Фаза дизайну настає після того, коли досягнуто хорошого розуміння вимог споживача і точно відомо, що саме треба втілити. Ця фаза визначає елементи системи, компоненти, рівень безпеки, модулі, архітектуру, різні інтерфейси і типи даних, якими оперує система. Дизайн системи в загальних рисах може бути зроблений ручкою на листку паперу – він визначає, як система буде виглядати і як функціонувати. Потім робиться розширений, детальний дизайн, з урахуванням всіх функціональних і технічних вимог, як логічно, так і фізично.
Розробка, впровадження і розгортання Ця фаза йде після повного розуміння системних вимог і специфікацій. Це і є власне процес розробки системи, коли її дизайн вже повністю завершено. В життєвому циклі розробки системи саме тут пишеться код, а також фаза впровадження може включати в себе конфігурацію і налаштування під певні вимоги і функції. На цій стадії система готова до установки у замовника, до запуску в робочий режим. Можливо, кінцевим користувачам буде потрібний тренінг, щоб вони освоїлися з системою і знали, як її використовувати. Фаза впровадження може бути дуже довгою – це залежить від складності системи.
Дослідна експлуатація та інтеграція Тут відбувається об'єднання різних компонентів і підсистем в єдину цілісну систему. В систему подаються різні вхідні дані і аналіз виходу, поведінки і функціонування. Тестування стає все важливішим для задоволення споживача, при цьому воно не вимагає знань коду, конфігурації обладнання чи дизайну. Тестування може виконуватися справжніми користувачами або спеціальною командою співробітників. Воно може бути систематичним і автоматизованим, з тим, щоб упевнитися, що актуальні результати роботи системи збігаються з передбаченими і бажаними
Підтримка системи На цій фазі здійснюється періодична технічна підтримка системи, щоб переконатися, що вона не застаріла. Сюди входить:
заміна старого обладнання і постійна оцінка продуктивності
здійснюються апдейти певних компонентів, щоб упевнитися, що система відповідає потрібним стандартам і новітнім технологіям, і не схильна до загроз безпеки.

Agile/Scrum⚑

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

Agile — це фреймворк управління проєктами, що включає такі принципи

Орієнтація на постачання цінності клієнту.
Гнучке реагування на зміни вимог навіть на пізніх етапах розробки.
Ітеративна розробка з короткими циклами (спринтами), які забезпечують швидке отримання результатів.
Постійна взаємодія з клієнтом для отримання зворотного зв’язку.
Самоорганізація та автономність команд.

Scrum — це один із найпоширеніших фреймворків Agile, який визначає конкретну структуру та ролі для виконання проєкту

Ролі в Scrum:
- Scrum Master — забезпечує дотримання принципів Scrum, допомагає команді усувати перешкоди.
- Product Owner — відповідає за бачення продукту, пріоритети та зв'язок із зацікавленими сторонами.
- Scrum Team — крос-функціональна команда, яка виконує завдання.
Спринт:
- Обмежений часовий інтервал (зазвичай 1-4 тижні), у рамках якого команда виконує набір завдань із беклогу продукту.
Основні події в Scrum:
- Sprint Planning — планування роботи на спринт.
- Daily Stand-up — щоденні короткі зустрічі для синхронізації.
- Sprint Review — демонстрація результатів спринту.
- Sprint Retrospective — аналіз процесу та вдосконалення.
Agile/Scrum. Все что необходимо знать

Kanban⚑

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

Основні принципи Kanban

Візуалізація роботи: використовується Kanban-дошка, яка відображає всі завдання, їх статус і прогрес.
Обмеження роботи в процесі (WIP): визначається максимальна кількість завдань, які можуть виконуватись одночасно.
Фокус на потоці: аналізуються вузькі місця та затримки для їх усунення.
Прозорість і адаптивність: дозволяє швидко реагувати на зміни та зменшувати час виконання завдань.

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

To Do (Заплановано)
In Progress (У процесі)
Done (Виконано)

Яка різниця між Scrum і Kanban⚑

Scrum і Kanban — представники методологій сімейства Agile. Обидві вони вважаються гнучкими та ітеративними.

Більше 17 років тому лідери IT-розробки сформулювали маніфест Agile. Головне, що можна виділити з маніфесту

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

Основу Scrum складають короткі ітерації або спрінти, як правило, 2-3 тижневі. Перед початком спрінта команда сама формує список фіч на ітерацію, далі запускається спрінт.

Після закінчення спрінта виконані фічі завантажуються на продакшн, а невиконані — переносяться в інший спрінт. Як правило, фічі, які робляться під час спрінту, не змінюються: те, що було на початку спрінту — повинно бути зроблено будь-якою ціною до кінця спрінту.

Kanban дає більше гнучкості, якщо під гнучкістю розуміти частоту зміни пріоритетів. Вчора завантажили на прод нову фічу, а сьогодні отримали дані з передової і дізналися, що ось ця штука не працює так, як було задумано — люди не натискають кнопку "купити". UX перероблється, поступають нові вимоги. Ця задача піднімається вверх черги, програміст бере цю задачу "зверху", виконує її і, до вечора, fix вже на проді, конверсія в платежі зросла на 12%. Це перемога.

Основна різниця між Scrum і Канбан — в довжині ітерацій. В Scrum ітерації — 2 тижні, в Kanban завдання програмісту можна "підкидати" хоч щодня.

В Scrum завдання прийнято оцінювати в Story points або в годинах. Без оцінки не вийде сформувати спрінт: адже нам потрібно знати, встигнемо ми зробити завдання за 2 тижні. Через 2 тижні ми отримуємо цінну статистику — скільки годин або Story points команда змогла зробити за спрінт. Velocity — це продуктивність команди за один спрінт. Цей параметр дозволяє Scrum менеджеру передбачити, де команда буде через 2 тижні.

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

Отже, в Scrum наша ціль — закінчити спрінт, в Kanban — завдання.

Scrum — це автобус, який зупиняється лише на певних зупинках, де люди виходять групами. А Kanban — це маршрутка: захотів пасажир вийти, попросив водія і вийшов там, де йому потрібно.

Links

Scrum vs Kanban: в чем разница и что выбрать?

Waterfall⚑

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

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

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

Команди різних етапів між собою не комунікують, кожна команда відповідає чітко за свій етап.

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

Питання для тім-лідів: що Ви будете робити, якщо на проекті немає тестів і замовник не хоче витрачати на їх розробку час і гроші⚑

Апелювати до прибутковості для бізнесу замовника.

Що таке Code Debt і як з ним бути⚑

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

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

Виплачувати відсотки за техборгу легше, якщо почати думати про це на етапі створення продукту.

Робіть одноразові прототипи MVP і тільки підтверджені гіпотези включайте в роботу.
Створюйте архітектуру, яку буде легко змінити: мікросервіси, API з версіонуванням.
Відмовтеся від організації власних серверних на користь хмарних рішень. Наприклад, Microsoft Azure, AWS Amazon Cloud.
Встановіть в команді чіткий definition of done, включаючи в тому числі метрики якості. Дуже допомагає включити в DOD пункт, який виключає "прийняття" фічі, якщо є пов'язані з нею баги.
Для MVP добре проектувати систему так, щоб міграція користувачів з прототипів на стабільну частину була непомітною.

Компанії працюють з техборгом по-різному. Основних стратегій три.

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