Методології ведення проєктів в ІТ компаніях

Agile vs. Waterfall: битва гнучкості та передбачуваності

Уявіть собі будівництво будинку.

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

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

Розглянемо на прикладі. Уявіть, що на етапі внутрішнього оздоблення ви розумієте, що хочете змінити розташування стін. У моделі Waterfall це буде дуже складно і дорого, оскільки попередні етапи вже завершені. Тепер потрібно відмовитися від частини вже проробленої роботи і якось викручуватися з ситуації, щоб задовольнити замовника.

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

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

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

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

Так, як не можна сказати, що викрутка краще молотка (або навпаки), не правильно говорити, що Agile краще Waterfall. Просто вони підходять для різних задач. У випадку передбачуваності і чіткого планування PM обирає Waterfall, а ось коли рамки бюджету і часу гнучкі, а результат буде адаптуватися під вимоги ринку з плином часу - перевага надається Agile.

Своєю концепцією, Agile надихнув проєктних спеціалістів на створення похідних фреймворків, таких як Scrum і Kanban. Розберемося з ними детальніше.

Scrum для новачків: як запустити першу команду

Scrum – це одна з найпопулярніших Agile-методологій. Уявіть собі спортивну команду (наприклад, команду з регбі - звідки й назва "Scrum"), де кожен гравець має свою роль, а всі разом вони рухаються до спільної мети невеликими, інтенсивними "спринтами" (зазвичай 1-4 тижні). Так як і в будь-якій спортивній грі, є свої правила, ритуали і обов’язки. 

Розберемося детальніше з основними елементами Scrum.

Спринти (Sprints): короткі часові проміжки (ітерації), протягом яких команда розробляє певну частину продукту. Зазвичай вони тривають від 1 до 4 тижнів, але рекомендовано не змінювати тривалість спринту протягом роботи, щоб не збивати темп учасників проєктної команди.

Команда Scrum (Scrum Team):

• Власник продукту (Product Owner): відповідає за визначення цілей проєкту та пріоритезацію завдань. Він як капітан команди, який знає, куди потрібно рухатися.
• Скрам-майстер (Scrum Master): допомагає команді працювати ефективно, усуває перешкоди та слідкує за дотриманням принципів Scrum. Він як тренер, який підтримує команду.
• Команда розробки (Development Team): група фахівців, які безпосередньо займаються розробкою продукту. Це гравці на полі, які і поставляють кінцевий результат.

Скрам-події (Scrum Events): регулярні зустрічі, які допомагають команді координувати свою роботу:

• Планування спринту (Sprint Planning): на початку спринту вся команда визначає, які завдання будуть виконані в рамках цієї ітерації.
• Щоденний скрам (Daily Scrum): коротка (до 15 хвилин) щоденна зустріч, де кожен член команди розповідає, що він зробив вчора, що планує робити сьогодні та які перешкоди у нього є.
• Огляд спринту (Sprint Review): наприкінці спринту команда демонструє замовнику розроблений функціонал та отримує зворотний зв'язок про результати поставки.
• Ретроспектива спринту (Sprint Retrospective): зустріч, на якій команда обговорює, що пройшло добре під час спринту, що можна покращити та як це зробити в наступному спринті.

Артефакти Scrum (Scrum Artifacts): інструменти, які допомагають керувати роботою та зробити процес розробки легшим і контрольованим:

• Беклог продукту (Product Backlog): упорядкований список усіх завдань та вимог до продукту.
• Беклог спринту (Sprint Backlog): набір завдань, які команда планує виконати протягом поточного спринту і поставити їх у якості результату.
• Інкремент (Increment): готова частина продукту, розроблена протягом спринту (результати, які будуть демонструватися замовнику).

З правилами розібралися. А як же виглядає типовий робочий процес команди, яка наслідує принципи фреймворку Scrum?

1. Визначте Власника Продукту: знайдіть людину, яка розуміє потреби замовника та може приймати рішення щодо пріоритетів. Це важливий етап, адже саме тут і визначається капітан команди.
2. Знайдіть Скрам-майстра: оберіть людину, яка буде допомагати команді впроваджувати Scrum та усувати перешкоди. Ця людина має добре знати події, ритуали Scrum та направляти інших для комфортної роботи всієї команди.
3. Сформуйте Команду Розробки: зберіть фахівців з необхідними навичками для виконання завдань.
4. Створіть Беклог Продукту: разом із Власником Продукту складіть список усіх бажаних функцій та завдань. 
5. Заплануйте перший Спринт: оберіть невелику кількість завдань з беклогу продукту для першого спринту. Врахуйте тривалість спринту та кількість учасників, щоб тверезо оцінити свої сили та не перенавантажити команду задачами.
6. Проводьте щоденні Скрами: організовуйте короткі щоденні зустрічі для координації роботи. Вони допоможуть далі краще аналізувати та планувати проєктні задачі.
7. Проводьте Огляди та Ретроспективи Спринтів: регулярно демонструйте результати та обговорюйте покращення.

Здається, правил не мало, але розпочавши працювати на проєкті по Scrum, вже після першої ітерації робочий процес буде зрозумілим і комфортним 🙂

‍

Що таке Kanban і як його впровадити у проєкт

Kanban (Канбан) у перекладі з японської означає "картка" або "візуальна дошка". Уявіть собі дошку, розділену на кілька стовпців, що відображають різні стадії виконання завдання (наприклад, "Потрібно зробити", "В роботі", "На перевірці", "Готово"). Кожне завдання представлене окремою карткою, яка переміщується між стовпцями в міру виконання. PM, BA, розробники бачать і список задач, і статус виконання кожної задачі… Зручно, правда?

Kanban, як і інші підходи, які ми розібрали вище має свої правила та ритуали. Давайте розберемося в них.

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

• Візуалізація робочого процесу: дошка робить процес виконання задач прозорим та дозволяє швидко знаходити потенційні "вузькі місця", де в нас пригальмовується робота.
• Обмеження незавершеної роботи (WIP - Work in Progress): встановлення лімітів на кількість завдань, які можуть перебувати на кожному етапі (статусі). Це допомагає команді зосередитися на завершенні розпочатої задачі і доводити справи до кінця, а не переключатися на нові справи.
• Управління потоком (workflow): фокус на плавному та безперебійному проходженні завдань через усі етапи. Команда сама визначає фази, через які проходить задача та відповідальних на кожній з них.
• Постійне покращення: регулярний аналіз робочого процесу, блокерів та змін у вимогах дозволяють підлаштувати “правила гри” під конкретний проєкт і зробити життя команди комфортним.

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

• Візуалізуйте свій робочий процес: створіть дошку з колонками, що відображають етапи вашої роботи. Часто, для цього використовуються системи управління проєктами, наприклад Trello.
• Обмежте незавершену роботу (WIP): визначте розумні ліміти для кожного етапу, знаючи обмеження по ресурсам вашого проєкту (як людським, так і технічним).
• Зробіть правила процесу явними: зафіксуйте правила переміщення карток між колонками і відповідальних за кожний етап.
• Впровадьте в роботу: перенесіть проєктні задачі виходячи з їхнього поточного статусу на дошку Kanban та почніть роботу.
• Регулярно аналізуйте та покращуйте процес: проводьте зустрічі для обговорення ефективності та пошуку шляхів покращення.

Kanban часто використовується як самостійна методологія або як доповнення до інших підходів, таких як Scrum. Він особливо корисний для проєктів з постійним потоком завдань, так званим конвеєром. З поміж всіх інших методологій, саме Kanban вважається найбільш гнучкою моделлю через можливість відразу реагувати на зміни (без необхідності чекати завершення спринту як в Scrum).

Розуміння цих методологій є важливим для кожного, хто працює в ІТ, будь то PM, BA або розробник. Вибір правильного підходу залежить від специфіки проєкту, вимог замовника та особливостей команди. Agile та Waterfall представляють два основні філософські напрямки: гнучкість проти передбачуваності. Agile, у свою чергу, включає такі популярні фреймворки, як Scrum, що робить акцент на ітеративних спринтах та командній взаємодії, та Kanban, який фокусується на візуалізації потоку роботи та обмеженні незавершених завдань. Сподіваємося, ця стаття допомогла вам розібратися в основних концепціях і надихнула на подальше вивчення цієї захопливої сфери!

‍