Олена Кравченко працює у сфері управління проєктами 14 років. Вона керувала відділом продуктової розробки у lifecell Ukraine. Управляла проєктами повного циклу веб- та мобільної розробки в Peppermint Int та ADV Group, де клієнтами були Kyivstar, Unilever, PepsiCo, Ferrero, Mary Kay та Danone.
Зараз Олена працює Program Manager у DXC Luxoft. Нам вона розповіла, у чому специфіка роботи з Scrum та в яких проєктах краще вибрати інший підхід.
Які проєкти варто реалізовувати за Scrum, а які — ні
Scrum — фреймворк, який підходить для роботи над проєктами з високим ступенем невизначеності.
Scrum буде корисним, коли ми точно не знаємо:
- якою має бути фінальна версія нашого продукту
- що сподобається користувачам і яким функціоналом вони будуть користуватися
- що потрібно ринку
- з яким функціоналом вийдуть конкуренти і коли
Scrum чудово підійде для продуктів, з якими ви працюєте вперше, для стартапів, які мають ідею і розуміння, як і куди рухатися, але невідомо, чи правильні всі припущення. Рух короткими ітераціями, збір та аналіз зворотного зв'язку, адаптація до нових вступних дозволять знизити ризики та підвищити передбачуваність поставок.
Після кожної ітерації у вас є корисний функціонал, ви показуєте його стейкхолдерам, отримуєте зворотний зв'язок та враховуєте його під час наступної ітерації.
Завдяки цьому не витрачайте багато часу на розробку функціоналу, який не відповідатиме реальним потребам ринку. І навіть якщо помилитеся, то ціна прорахунку буде невеликою.
Обійтися без Scrum і використовувати каскадний спосіб розробки можна, якщо ви створюєте шаблонний продукт, який робили вже багато разів. Наприклад, типовий інтернет-магазин.
Тут ви добре знаєте свій сегмент та очікування клієнтів, розумієте, як саме будуть використовувати ваш продукт. Тому створюєте шаблонні магазини зі стандартним набором фіч — найкращу версію продукту, відточену роками.
У чому полягає робота зі Scrum
Перш ніж проводити мітинги та наповнювати беклог, переконайтеся, що в майбутній роботі команда спиратиметься на «стовпи» та принципи Scrum:
- Прозорість — роботу, яка виконується, видно всім стейкхолдерам. Процес також має бути відомий та зрозумілий кожному. Прозорість дає можливість для інспекції.
- Інспекція — регулярна перевірка артефактів, уточнення, чи у правильному напрямку ми рухаємось.
- Адаптація — зміна курсу на основі зворотного зв'язку, отриманого в процесі інспекції.
Scrum-процес — емпіричний, ви навчаєтесь на власному досвіді. Розробляєте невелику частину функціоналу і відразу ж віддаєте його користувачам. Отримуєте зворотний зв'язок і враховуєте його надалі.
Scrum Team дотримується таких цінностей:
- сміливість — відкрито говорити про складнощі та пропонувати ідеї, як їх можна подолати
- фокус — концентруватися на максимально можливому прогресі
- відданість — команда віддана своїм цілям та підтримці один одного
- повага — до колег, продукту, замовника та кінцевого користувача
- відкритість — не боятися говорити про те, що важливо
Ці цінності — «протокол» поведінки та ухвалення рішень Scrum Team. Без орієнтира на них команда не зможе працювати з фреймворком ефективно. Це буде набір зустрічей без очікуваного результату.
Чому? Якщо в колективі немає поваги, відкритості, фокусу та сміливості, щоби робити нове, то загубиться прозорість у взаємодії, команда не вчитиметься на власному досвіді. В підсумку ви рухатиметеся ітераціями «наосліп», не інспектуючи і не адаптуючись. А це суперечить суті Scrum.
Як планувати спринти
«В Agile немає планування» — один із найпоширеніших міфів. Насправді воно є, і його багато. Але на відміну від традиційних підходів, ви плануєте ітеративно протягом усього життєвого циклу продукту, адаптуючи пріоритети після кожної ітерації. Такий підхід дозволяє швидко реагувати на зміни та займатися саме тим, що принесе цінність.
Sprint Planning — подія, в рамках якої команда планує, яку роботу потрібно виконати у найближчому спринті. Для цього беклог продукту необхідно впорядкувати за пріоритетністю.
Учасники обговорюють найважливіші елементи беклогу та його значення для цілі продукту (Product Goal). А саме:
- Яку цінність принесе цей спринт?
- Що може бути готове у цьому спринті?
- Як буде виконано обрані завдання?
Подія Sprint Planning ініціює спринт, і ця зустріч обмежена за часом. Для спринту тривалістю 1 місяць планування займає до 8 годин, для коротших зазвичай потрібно менше часу.
Як вимірювати результати роботи команди
Основна метрика для вимірювання швидкості роботи команди — velocity. Вона дозволяє будувати прогнози щодо обсягу завдань у беклозі та планувати релізи.
Завдання оцінюються в сторі-поінтах — це абстрактна одиниця вимірювання кількості зусиль, які потрібно докласти команді для виконання завдання з беклогу. Є різні техніки для оцінки, наприклад Planning Poker, і ми навчимося використовувати їх на курсі.
Виміряти можна будь-що. Але потрібно знати, навіщо ви це робите і що зробите з даними. Наприклад, можна заміряти час «застою» завдань у беклозі, нерівномірне завантаження розробників, співвідношення кількості фактично завершених тасків до всіх інших. На основі цього зробити висновки про ощадливість процесу та покращити його.
Як розподіляються ролі у команді
У Scrum Team є три ролі: Product Owner, Scrum Master та Developers. При цьому в проєкті можуть бути менеджери, архітектори, аналітики та інші фахівці, які взаємодіють зі Scrum Team, але не є її частиною.
Product Owner відповідає за місію та візію продукту, його цінність, набір функціоналу, а також виведення на ринки. Він знає, як зробити продукт затребуваним і постійно його розвиває.
Scrum Master — найбільш багатогранна роль. Він відповідає за використання Scrum у команді, а також за ефективність Scrum Team. Scrum Master — фасилітатор, лідер, ментор, коуч. Є поширена думка, що бути скрам-майстром — просто: проводиш «дейлі», ретроспективи та замовляєш піцу для команди. Але це не так: потрібно мати лідерські якості, розбиратися в процесі розробки продукту, стати джерелом знань про Agile, вміти та хотіти мотивувати, спрямовувати, навчати.
Developers — люди, які відповідають за створення частини інкременту спринту. Певний набір навичок залежить від вимог продукту. Основна зона відповідальності Developers — формування беклогу для спринту (Sprint Backlog), прагнення якості, взаємна підтримка, відповідальність за загальний результат, щоденна інспекція та адаптація для досягнення Sprint Goal.
Працювати над проєктами всередині компанії чи на аутсорсі — яка різниця
Головна відмінність — у доступності інформації про продукт, плани клієнта та у швидкості зворотного зв'язку. На аутсорсі замовник часто недоступний, до нього складно достукатися. Або він не дає команді повної інформації про продукт.
Це може вплинути на мотивацію та ефективність Scrum Team. Але перевага аутсорсу — можливість попрацювати з різними клієнтами та на різних ринках. Це дозволяє отримати більший, різноманітний досвід, прокачати навичку інспекції та адаптації до небес.
Яких помилок найчастіше припускаються при роботі зі Scrum
#1. Не спираються на принципи та цінності Agile, ігнорують принципи Scrum — працюють лише з процесною частиною фреймворку. Наприклад, коли в команді немає відкритості й колеги неохоче діляться інформацією, тоді у кожного накопичується свій суб'єктивний досвід.
#2. Не проводять ретроспективи — один із найважливіших івентів за Scrum. Це зустріч, де команда обговорює, як пройшов спринт. На ретроспективі ми можемо відсвяткувати успіхи, відкрито та конструктивно обговорити невдачі, разом знайти рішення, обмінятися ідеями щодо покращення чого завгодно, окреслити проблеми та визначити подальші кроки.
Тут ми можемо перевірити, якого прогресу досягли з попередньої ретроспективи, які намічені поліпшення вдалося реалізувати. Якщо ігнорувати ці зустрічі, ми втратимо можливість планувати підвищення якості та ефективності.
#3. Не аналізують та не фіксують кроки для покращення на наступних спринтах, які визначили на ретроспективі.
#4. Не дбають про те, щоб вся команда розділяла бачення продукту — навіщо він створюється і в чому його суть.
Бажаєте отримувати дайджест статей?
