Хочете краще організовувати роботу команди, швидше запускати продукти та уникати хаосу в дедлайнах?
Agile і Scrum для керівника проєкту – основи гнучких методологій, інструкція з ведення беклогу і спринтів, контроль процесів і організація роботи.
У цій статті ми поговоримо про те, що таке Agile та Scrum, а також з’ясуємо, в чому полягають їхні основні відмінності. Agile забезпечує адаптивність до змін, тоді як Scrum допомагає ефективно керувати проєктами за допомогою коротких циклів – спринтів.
Agile і Scrum для управління проєктами
Agile – це підхід до управління проєктами, що акцентує увагу на гнучкості, співпраці та швидкій адаптації до змін. Scrum, у свою чергу, є однією з найпоширеніших методологій, що базуються на принципах Agile, і використовується для управління командами та розробки продуктів. Основою Scrum є ітеративний та інкрементальний підхід до роботи.
Хоч Scrum і належить до Agile-підходу, між ними існують ключові відмінності. Agile – це загальний підхід до управління проєктами, тоді як Scrum – конкретна методологія в межах цього підходу. Agile ґрунтується на принципах і цінностях, тоді як Scrum пропонує чітко визначені ролі, артефакти та процеси.
Agile є більш гнучким і може включати різні підходи, зокрема Kanban або Lean. Scrum натомість має фіксовану структуру і правила. Якщо Agile робить акцент на здатності адаптуватися до змін, то Scrum – на поетапній розробці продукту з використанням коротких повторюваних циклів.
Впровадження гнучких методологій
Є два підходи до розробки великих проєктів. Класичний, або каскадний – це механіка, в якій заздалегідь готується величезне технічне завдання, враховуються всі дрібниці, передбачаються ризики і витрати. І тільки потім починається розробка. У digital такий метод працює неефективно – коли команда розробляє великий проєкт, неможливо спрогнозувати всі ризики і проблеми.
Несподіванки з’являються не тільки через бізнес-процеси, тут працює і людський фактор. Наприклад, представники замовника можуть навмисно затягувати впровадження ПЗ, переслідуючи особисті цілі.
Збір вимог на етапі аналітики теж не дає стовідсоткової точності – замовники не розкажуть вам усе відразу. Плюс зараз ПЗ вимагає миттєвої реакції на відгуки користувачів – підхід із довгою ретельною підготовкою не працює.
Управління проєктами в стилі Agile і Scrum – інший підхід. В основі – ітерації, невеликі завдання з мінімумом функцій. Можна розробити основні функції, запустити ПЗ і поступово доповнювати його.
Плюси методології:
- Немає потреби складати довге ТЗ – замість цього формується гнучкий список завдань на основі бажань клієнта.
- Бюджет гнучкий – якщо гроші закінчилися, замовник однаково отримає працюючий проєкт, нехай і з меншою кількістю функцій.
- Менше бюрократії – немає потреби узгоджувати одразу всю документацію за проєктом, достатньо отримати схвалення керівника з одного питання. Розробка інших завдань у цей час не припиняється.
Agile – це підхід до розробки великого проєкту. Філософія, яка дає змогу створювати продукт із постійно мінливими вимогами.
Почніть із беклогу
Scrum – це метод управління проєктами, він входить до філософії Agile. Ключова відмінність від класичної, водоспадної схеми створення ПЗ помітна одразу – для початку розробки не потрібне технічне завдання.
Замість проєктного завдання використовується беклог – список функцій, вимог до системи, бажань замовника. У Scrum вони сортуються за пріоритетом. Це живий документ, додавайте в нього нові завдання під час роботи.
Лайфхак: зверніть увагу на стовпець “Пріоритет” на прикладі. Використовуйте не звичний список 1, 2, 3, 4. Спробуйте чотиризначні цифри – так ви зможете просто додати рядок між ними і виставити відповідний пріоритет. Наприклад, між 1 000 і 2 000 напишіть 1 050.
Не потрібно опрацьовувати і продумувати повністю всі функції відразу. Усі «хотілки» і те, що з’являється в процесі, додаються в беклог. Вирішуйте, що робити відразу, а що варто відкласти на наступну версію.
Впроваджуйте спринти
Scrum створювався насамперед для гнучкості та прискорення розробки. Для цього з’явилася механіка спринтів – весь процес ділиться на відрізки, зазвичай від одного до чотирьох тижнів.
Як це працює? Команда забирає з беклогу частину завдань. Кожне розбивається на максимально дрібні тікети. Тепер потрібно оцінити час на завдання, і ось тут проявляється особливість Scrum.
Річ у тім, що люди погано рахують процеси в абсолютних величинах. Складно сказати, скільки годин що займе. Тому в Scrum використовується відносна оцінка.
За основу береться проста функція, яку всі оцінюють однаково – наприклад, зрозуміло, що її зроблять за годину. Решта тікетів обчислюються так – «це ми робитимемо разів у п’ять довше за часом».
Зробіть список версій продукту – від ПЗ з мінімумом функцій до повністю реалізованого. Вкажіть до кожної версії прогноз за терміном виконання.
Ключова ідея – доти, доки команда не забрала завдання на спринт, їх можна нескінченно видозмінювати в беклозі. У розробку йде узгоджена частина. Кожен спринт – це невеликий реліз, наприкінці якого команда показує працюючу функцію ПЗ.
Ролі в команді
В ідеальному світі на ключові ролі в scrum-команді призначаються люди, вирощені на проєкті. Така людина знатиме процеси зсередини, краще орієнтуватиметься в оцінках і зрозуміліше ставитиме завдання.
Product Owner
Сполучна ланка між командою розробки та користувачами. Ця людина збирає загальну концепцію продукту з думок замовників та інших зацікавлених у випуску ПЗ людей. Вона формує завдання і розставляє пріоритети.
Scrum Master
Член команди розробки, який відповідає за виконання щоденних процедур і за дотримання інтересів команди. Ця людина фіксує дедлайни і початок спринту, додає оцінки, звітує перед зацікавленими особами про етапи проєкту. Ростіть scrum-майстра всередині команди.
Команда розробки
Люди, які безпосередньо створюють і тестують код.
До розробників є кілька вимог:
- Щонайменше одна людина в команді має розуміти код, який написали інші. Той, хто краще за всіх розбирається в темі проєкту, стає куратором.
- Усі спільно володіють кодом, розуміють, як працює продукт.
- Команда стабільна і постійна.
- Аналітики, дизайнери – опціонально, достатньо запрошувати на окремі тікети.
- Scrum на віддаленій роботі можливий, але доведеться працювати над ефектом присутності.
У такого принципу формування команди є мінус – складно замінити людину, яка несподівано випала. Але швидкість розробки на практиці все одно вища, ніж у інших підходів.
Контролюйте процеси
Діаграма згоряння – це наочна демонстрація того, як команда «перетравлює» всі завдання проєкту. Червона лінія – план. Синя – те, що робить команда. Діаграма оновлюється щодня. Ви одразу бачите, коли є відхилення від плану: можна спокійно «крутити гайки» або змінювати пріоритети в беклозі.
Контролюйте роботу команди за допомогою двох scrum-показників:
- Focus Factor – коефіцієнт, який показує, скільки завдання мало виконуватися за планом, а скільки вийшло в підсумку. Так оцінюється «концентрація» команди над проєктом.
- Velocity – продуктивність. Допоможе спрогнозувати кількість завдань, які команда зможе взяти в наступному спринті – залежно від кількості готових тікетів у минулому. Velocity = Focus Factor * Оцінка нових завдань.
Організуйте роботу команди
У Scrum від співробітників вимагається мінімальна звітність. Щодня людина має відповісти на три запитання:
- Що зроблено вчора?
- Що буде зроблено сьогодні?
- Які є проблеми і перешкоди для виконання завдань?
Завдання керівника – з’ясувати й усунути труднощі, які заважають розробнику досягти прогнозованого результату. Для співробітників це три-п’ять хвилин – відповіли на запитання, поставили оцінки, розбіглися працювати далі. Ніяких рішень або дискусій.
Наприкінці кожного спринту проводиться ретроспектива. Команда зустрічається, озвучує думку, що у відрізку було добре, що погано. Запитайте у співробітників ідеї – що допоможе їм працювати швидше й ефективніше, що виправить проблеми. Запишіть їх в окремий план – забирайте туди тільки ті ідеї, які можливо зробити за наступний спринт.
Усі ідеї мають бути вимірними – наприклад, «Хлопці, давайте додамо серверів». Пропозиція просто працювати краще – не ідея.
На наступній ретроспективі обговоріть ідеї з плану, відсортуйте їх за категоріями «погано» і «добре». Повторіть процес – виходить ретроспектива на ретроспективу.
Формуйте організацію процесу поступово. Розбивайте день – наприклад, шість годин люди працюють за спринтами, дві години залишаються на термінові та випадкові моменти. Якщо все піде без несподіванок, нічого страшного, продовжуйте спринт, зробіть більше тікетів.
Перший спринт команда завжди «факапить», бо надто оптимістично дивиться на дедлайни і завдання. Другий – бере дуже мало завдань і робить більше. Третій – знову погана оцінка, але вже трішки краще. Потім усе вирівнюється. Це робочий процес.
Демонструйте проєкт
Не затягуйте з першою версією продукту. Демонстрацію краще проводити після кожного спринту – нехай навіть реліз не піде до користувачів. Не накопичуйте всередині команди багато функцій – покажіть їх зацікавленим особам і отримайте зворотний зв’язок. Після – одразу змініть беклог.
У цьому основна перевага Scrum – гнучко змінювати список завдань під час розробки, не робити зайвого і не отримувати тисячі правок після завершення проєкту, як у каскадній методології розробки.
Інструменти для контролю
Працювати за системою можна навіть на папері. Чудово підходить і таблиця в Google Docs. Створіть свою робочу область вручну або спробуйте спеціальні сервіси:
- Trello – підходить для маленьких проєктів, швидко і зручно.
- Scrumban – є різні дошки, вкладені завдання і підзадачі. Зручно для середніх і маленьких проєктів.
- Jira – є версійність, зручно для великих і довгих завдань. Підтримує масу типів розробки. Спробуйте, вона вам сподобається.
Чек-лист для старту
Цей короткий чек-лист допоможе вам упорядкувати процеси та уникнути плутанини на старті:
- Навчитися вести беклог і розставляти пріоритети.
- Проводити спринти.
- Формувати стабільну і постійну команду, вирішувати труднощі, ростити всередині групи scrum-майстра.
- Контролювати роботу за допомогою діаграми згоряння проєкту.
- Організувати роботу – щодня цікавитися справами команди, проводити ретроспективу і закладати час на тікет із запасом.
- Після кожного спринту демонструвати проєкт.
- Вивчити інструменти та знайти найзручніший.
Тепер ви знаєте основи Agile і Scrum і можете почати впроваджувати їх у реальні проєкти. Але для ефективної роботи з командою цього мало – потрібно вміти робити це осмислено, знати тонкощі методологій і не губитися в складних моментах.
Висновок
Agile і Scrum допомагають зробити управління проєктами більш гнучким, прозорим і ефективним. Завдяки регулярним ітераціям, постійному зворотному зв’язку та пріоритезації задач команда може швидко адаптуватися до змін.
Правильне впровадження цих методик дозволяє підвищити якість продукту, краще планувати ресурси та своєчасно досягати цілей.
