Методології проджект-менеджменту: Повний гайд для початківців
Scrum, Agile, Lean, Waterfall і як у них розібратись
Проєкти, на яких працює більше ніж троє людей, — приречені на хаос без правильної методології. Саме тому чи не в кожній вакансії пишуть «знання Agile/Scrum». Це мова, якою говорять команди.
Для світчерів це перепустка в IT, але от розібратися в нюансах айтішних методологій буває складно. Тому ця стаття — ваша шпаргалка. З нею стане легше зрозуміти різницю між методологіями та специфічні терміни, притаманні кожній з них.
Waterfall (Водоспад) — класика послідовності
Waterfall — це як будівництво будинку: спочатку фундамент, потім стіни, дах, оздоблення. Не можна почати з даху. Кожен етап завершується повністю, перш ніж почнеться наступний. Процес ділиться на 5 послідовних фаз:
- Аналіз — збираємо всі вимоги
- Дизайн — проєктуємо архітектуру та інтерфейси
- Розробка — пишемо код
- Тестування — шукаємо баги
- Впровадження — запускаємо продукт
Повернутися назад — дуже дорого. Якщо на етапі тестування виявили, що вимоги були неправильні, — доведеться переробляти все, починаючи з аналізу.
Коли використовувати
Waterfall ідеальний, коли вимоги зрозумілі на 100% і не зміняться, а таке буває рідко, принаймні в ІТ. Цей підхід більше підходить для інших сфер. Наприклад, у виготовленні медичного обладнання, де регулятори вимагають детальну документацію кожного етапу. Або у створенні софту для держсектору, адже всі вимоги прописані в тендері, а зміни = нові узгодження.
Втім, саме для ІТ недоліків у Waterfall вдосталь:
- Негнучкість. Клієнт побачить результат тільки в кінці, змінити щось = переробляти етапи.
- Пізнє виявлення помилок. Якщо на етапі аналізу щось пропустили, дізнаєтесь про це через місяці.
- Ризик невідповідності. Поки ви робили щось 6 місяців, ринок змінився — і продукт вже не актуальний.
А отже, є правило: Якщо є шанс, що вимоги зміняться, — Waterfall не ваш вибір.
Agile — філософія гнучкості
Важливо: Agile — це НЕ методологія, а підхід до роботи, філософія. Scrum, Kanban, XP — це методології, які реалізують Agile-принципи. Зʼявився він у 2001 році, коли 17 розробників зібралися на лижному курорті й написали Agile Manifesto — маніфест, який змінив підхід до роботи IT. Він передбачає декілька ключових цінностей.
- Люди важливіші за процеси — краще гарна команда з простими інструментами, ніж погана з ідеальними.
- Робочий продукт важливіший за документацію — краще показати прототип, ніж написати 100 сторінок специфікацій.
- Співпраця з клієнтом важливіша за контракт — домовляємося по ходу, а не судимося через пункт 3.14.
- Реакція на зміни важливіша за план — якщо ринок змінився, міняємо курс, а не йдемо за планом у прірву.
В Agile Manifesto є 12 ключових принципів. Знати всі — не те щоб обовʼязково. Але найактуальніші з них звучать так:
- Поставляти робочий софт кожні 2–4 тижні, а не через рік
- Зміни вітаються навіть на пізніх етапах розробки
- Бізнес і розробники працюють разом щодня
- Команда сама організовує свою роботу
- Регулярно рефлексуємо і покращуємо процес.
Ітеративний підхід
Ітерація — це короткий цикл розробки (зазвичай 1–4 тижні), після якого ви отримуєте робочу версію продукту. Таким чином, замість 6 місяців тиші в очікуванні повністю готового проєкту Agile ділить усе на фази:
- 2 тижні — базовий логін працює
- Ще 2 тижні — додали профіль користувача
- Ще 2 тижні — з'явилася стрічка новин
Суть цих маленьких кроків легко зрозуміти на прикладі. Уявімо, що ви замовили торт на весілля. Є два варіанти:
- Waterfall: Кондитер зникає на місяць. Приносить торт за день до весілля. Він фіолетовий, а ви хотіли білий. Переробити немає часу.
- Agile: Кондитер через тиждень показує ескіз. Ви вносите правки по декору, смаку. Через тиждень зʼявляється пробник крему. Ви знову ітеруєте над смаком, виглядом тощо. Так до весілля ви отримуєте ідеальний торт, адже самі коригували процес.
В Agile після кожної ітерації клієнт бачить, пробує, коментує. Не теоретично, а реально клацає кнопки. Так не втрачається звʼязок між очікуваннями й реалізацією та зʼявляється простір для правок.
Можна поспекулювати, що багато продуктів, якими ми користуємось щодня, просякнуті Agile-підходом.
До прикладу, Spotify чи не щотижня випускають оновлення на основі даних користувачів. Без Agile це було б майже неможливо реалізувати ефективно.
Instagram, наприклад, починався як Burbn (додаток для чекінів), але в процесі зрозуміли, що всі люблять тільки фото. Так завдяки ітераціям і тестам знайшли золоту середину і повністю переробили продукт.
Scrum — найпопулярніша реалізація Agile
Scrum — це конкретний фреймворк (каркас правил), який реалізує Agile-філософію на практиці. Якщо Agile пропагує гнучкість, то Scrum каже «ось як саме». Формується він навколо 3-х принципів:
- Прозорість. Всі бачать, хто що робить. Дошка з тасками відкрита, проблеми озвучуються вголос.
- Інспекція. Регулярно перевіряємо, що виходить, чи йдемо в правильному напрямку.
- Адаптація. Якщо щось не так, швидко міняємо підхід, а не чекаємо кінця проєкту.
Ролі в Scrum
Окрім класичних айтішних посад, у Scrum-орієнтованих колективах є унікальні ролі.
- Product Owner (PO). Він вирішує, що будуємо і в якому порядку. Веде Product Backlog (список усіх задач), спілкується з клієнтами, збирає вимоги та загалом каже «так» або «ні» на нові ідеї. Глобально він відповідає за те, щоб команда робила найцінніші речі першими.
- Scrum Master (фасилітатор). Що цікаво, це не бос і не проєктний менеджер. Він прибирає перешкоди, навчає команду працювати за Scrum, веде церемонії (планування, ретро) та захищає команду від зовнішніх відволікань.
Артефакти Scrum
- Product Backlog — загальний список бажань. Це весь список функцій, покращень, виправлень, які коли-небудь треба зробити.
- Sprint Backlog — план на поточний спринт. Це список завдань, які команда має зробити в цьому спринті. Важливо, що під час спринту PO не може додавати нові таски. Команда захищена від хаосу.
- Increment — робочий продукт. Це те, що готово і працює після спринту. Не «95% готово», а саме можна показати користувачам.
Події (Ceremonies) в Scrum
-
Sprint — основний цикл роботи. Триває близько 1–4 тижнів (найчастіше 2 тижні). Якщо він коротший — потрібне постійне планування, а якщо довший — втрачаємо гнучкість. Загалом є правило: Один спринт = одна ціль.
- Sprint Planning — планування спринту. Його зазвичай проводять у перший день спринту. PO показує найважливіше з топу беклогу, і команда вирішує, наскільки завдання можна реалізувати за спринт. Далі його розбивають на великі та маленькі таски.
- Daily Standup (Daily Scrum) — щоденна синхронізація. Відбувається щодня в один і той самий час і займає від 15 до 30 хвилин. Так команда синхронізується на тому, що зробили вчора, що робитиме сьогодні та які є блокери.
- Sprint Review — демо результатів. Відбувається в останній день спринту і триває 1–2 години. Команда показує готовий Increment, PO, а стейкхолдери дивляться, клацають, тестують і дають фідбек.
- Sprint Retrospective — що покращити. Відбувається після Review та закриває спринт. На ньому команда обговорює процес: що пішло добре, що погано, а що можна покращити.
Головне: Кожні 2 тижні команда доставляє цінність, а не працює у вакуумі місяцями. Клієнт бачить прогрес, команда отримує фідбек, продукт росте ітеративно.
Інші методології
Lean — мінімум витрат, максимум цінності
Ця методологія зародилася в Японії, на заводах виробництва автівок Toyota. Її суть у тому, щоби прибрати все, що не додає цінності клієнту. Lean пропагує усувати зайву документацію, надлишковий функціонал, зайві зустрічі/процеси тощо.
Lean часто використовують у стартапах з обмеженим бюджетом і в продуктових компаніях, які фокусуються на створенні MVP.
Extreme Programming (XP) — екстрим для розробників
Суть у тому, щоб довести Agile-практики до екстремуму. Якщо тестування корисне — тестуємо постійно. Якщо code review корисне — робимо його в реальному часі. В XP практикують:
- Парне програмування (Pair Programming). Двоє розробників за одним комп'ютером. Один пише код (driver), другий думає наперед і ловить помилки (navigator). Так вони міняються місцями кожні 15–30 хвилин.
- Test-Driven Development (TDD). Спочатку розробник пише тест (він падає, бо функції ще немає). Далі він пише мінімальний код, щоб тест пройшов, а за ним — рефакторинг, щоби покращити код.
- Continuous Integration (CI). Код зливається в основну гілку кілька разів на день. Автоматичні тести запускаються при кожному коміті. Якщо щось зламалося, про це відомо одразу.
XP найчастіше зустрічається в командах, де якість критична (фінтех, медтех). Альтернативно це корисна методологія для колективів, де багато junior-розробників, яких потрібно навчати.
