Scrum — найпопулярніший Agile-фреймворк для розробників. Згідно з дослідженням, ним користуються близько 84% організацій у світі. Чи підходить він усім бізнесам? Scrum справді прискорює розробку або ж численні церемонії та додаткові ролі ускладнюють життя інженерів? Ця методологія працює лише цілісно чи може бути адаптована до вимог продуктових команд? Чи можна оцінювати його ефективність за кількістю релізів? Сергій Матчук, Product Lead команди Kismia в Quarks, партнерській компанії Genesis, спростував найпоширеніші міфи про Scrum та поділився, як адаптувати цей фреймворк до цілей продуктової команди.
МІФ №1
Scrum — цілісний фреймворк, який не працює при неповній імплементації всіх складових
Методологія Scrum першочергово націлена на організацію процесу розробки проєкту. Цей фреймворк дає команді можливість ефективно і планово релізити зміни у продакшн, і робити це швидко, але він не забезпечує позитивного впливу на продукт. Для ефективних результатів він має бути адаптований до цілей і специфіки бізнесу.
Складовими класичного Scrum є кросфункціональні команди, відповідні ролі, церемонії, артефакти та правила. Його автори наголошують, що усі компоненти методу не підлягають змінам та працюють лише цілісно. Тож як його тоді адаптувати?
Як це працює в Quarks
Quarks створює продукти та технології у сфері social discovery, серед яких флагманом є Kismia, міжнародна платформа для онлайн-знайомств. Щоби ефективно розвивати цей комплексний кросплатформенний продукт, команда Kismia експериментувала з інструментами та обрала окремі практики з базових складових фреймворку Scrum:
Створили три кросфункціональні команди, які відповідають за окремі платформи (iOS, Android та Web), є автономними та самостійними. До кожної команди входить два розробники та QA. Також у сервісному форматі з командою працює бекенд-інженер який закриває потреби всіх команд. У команді немає ролі продакт-овнера, але є роль продакт-менеджера який відповідає за розвиток платформи та взаємодію з командою інженерів і продуктовими спеціалістами, такими як дизайнер, продакт-аналітик. Окрім цього в Quarks є інші продуктові та технічні команди, з якими регулярно взаємодіє команда Kismia.
Застосували спринти — короткі ітерації тривалістю два тижні, протягом яких створюється готовий до релізу інкремент продукту. У кожної команди свій релізний цикл і процес. Як його організовувати визначає сама команда.
Організували єдиний продуктовий роудмап. У кожної кросфункціональної команди є свій беклог з точки зору платформи. В межах спринту ним керує сама команда розробки, беручи до уваги пріоритети від продуктового менеджера та продуктовий роудмап.
Визначили зрозумілу ціль — завдання, на якому команда фокусується протягом спринту. Альтернатива цілі спринту — запуск експериментів, про які домовляється команда розробки та продуктовий менеджер.
Водночас усі команди мають один контекст, бачення та єдиний вектор розвитку.
Попри те, що команда Kismia імплементувала не цілісний фреймворк «з коробки», а його окремі складові, такий підхід забезпечує ефективну роботу команди, системний цикл релізів та запуск експериментів на трьох платформах.
МІФ №2
Впровадження Scrum потребує збільшити кількість менеджерів
Канонічний Scrum передбачає, що до кросфункціональної команди обовʼязково має входити продакт-оунер та скрам-майстер.
Продакт-оунер відповідає за пріоритезацію завдань, які треба виконати протягом спринту, а також за цінність продукту, комунікацію зі стейкхолдерами, збір вимог та донесення до команди бачення кінцевого продукту.
Скрам-майстер слідкує за дотриманням практик та правил методології.
Як це працює в Quarks
Найважливіша концепція Scrum — ідея автономних та самоорганізованих команд. Фактично усі додаткові ролі, церемонії та артефакти створені саме для того, щоби зробити їх більш самостійними. Водночас команда розробки у продуктових компаніях зазвичай добре розуміє цілі та бізнес-контекст. Досвідчений спеціаліст може самостійно організувати процес розробки та взаємодію з QA чи іншими інженерами. Він добре розуміє бізнес-контекст, ціль та ролі в команді, тому йому не потрібен посередник, який водитиме його «за руку» та вирішуватиме усі питання. Залучаючи до команди таких сильних людей, Quarks змогли відмовитися від зайвих ролей — продакт-овнера та скрам-майстра.
У такому підході значно складніше наймати, адже до кандидата висувається більше вимог — комунікаційні навички, продуктове мислення тощо. Проте це працює ефективніше. Зокрема, можна уникати «менеджерських трикутників». Коли в одного інженера виникає питання до іншої команди, він не іде до свого менеджера, щоби той звернувся до іншого менеджера, а спрямовує свої питання одразу на колегу з технічної команди. Це більше розвиває спеціалістів, дає їм свободу та автономність.
Команда розробки максимально залучена до продуктового процесу, розуміє цілі, пріоритети, обмеження та залежності. Отримуючи всі відповіді на етапі планування та при формуванні продуктових вимог, вони самостійно планують скоуп спринту, запускають його, і рухаються протягом двох тижнів. Продуктовий менеджер керує беклогом і пріоритетами. Він відповідає за продуктову частину продукту, а саме за експерименти, що мають позитивний вплив на продукт, його цінність для користувача та бізнесу.
МІФ №3
Scrum передбачає забагато церемоній, які забирають більше часу ніж сама розробка
Зазвичай до церемоній Scrum входять: рефайнмент, планування спринту, дейлі-стендапи, спринт-ревʼю та ретроспектива.
Рефайнмент. Зустріч, на якій учасники опрацьовують беклог продукту та розбирають завдання.
Планування. Відбувається на початку кожного спринту для визначення цілі та завдань, які команда має виконати протягом наступного періоду.
Дейлі-стендапи. Щоденні короткі зустрічі, що відбуваються протягом спринту. Кожен член команди розповідає про свій прогрес, завдання і будь-які проблеми, які заважають роботі.
Спринт-ревʼю проводять у кінці кожного спринту. На ньому команда підбиває підсумки та презентує результати стейкхолдерам.
Ретроспектива. Зустріч для аналізу минулого спринту, виявлення проблем та можливостей покращити процеси. Проходять у кінці спринту.
Часто розробники скаржаться, що такі зустрічі проходять неефективно: обговорення можуть тривати годинами, що призводить до виснаження команди.
Як це працює в Quarks
Церемонії не мають відбуватися лише заради дотримання правил Scrum. Важливо берегти час команди, а не збирати усіх з будь-якої нагоди, щоби послухати менеджера. В Quarks усі зустрічі та церемонії мінімізовані за тривалістю та кількістю учасників. Наприклад, рефайнмент займає не 2 години, а 30-40 хвилин.
Команди розробки щодня проводять дейлі-стендапи, вони проходять без менеджерів. Основна зустріч, з якої починається підготовка до спринту — рефайнмент. На ній розробники розбирають плани на наступний спринт чи ітерацію, і впевнюються, що до завдань немає питань. Окремої зустрічі з планування, на яку збирають всю команду, не проводять. Після рефайнменту відповідальні за платформи дивляться оцінки завдань, сформований скоуп, пріоритети менеджерів та запускають спринти. Ретроспективи проводять періодично, щоби виявити проблеми у процесах на стику взаємодії. Команда самостійно вирішує, коли провести таку зустріч та може її пропустити, якщо ні в кого немає зауважень щодо ефективності роботи чи результатів спринту.
Щоби Scrum працював повноцінно, важливо мати хорошу технологічну базу — йдеться про CI/CD, пайплайни та внутрішні інструменти для підвищення ефективності та автоматизації. Якщо вони якісно налаштовані, частково зникає потреба у додаткових процесах, ролях та церемоніях.
МІФ №4
Система оцінки завдань у Scrum створена для посилення контролю над розробниками
Одна з практик Scrum — оцінка складності завдання під час планування спринту. Це допомагає команді розробників прогнозувати, скільки часу та ресурсів знадобиться для виконання конкретної роботи. Є чимало підходів, як оцінити завдання, один з яких — сторипоінти. Часто вони не виражені у конкретних годинах чи днях, а відображають відносну складність чи обсяг роботи порівняно з іншими завданнями.
У деяких компаніях за кількістю виконаних сторипоінтів оцінюють загальну ефективність команди. Вважається, коли число запланованих та виконаних завдань відрізняється, це свідчить про неякісне планування або проблеми у процесах.
Як це працює в Quarks
Кількість сторипоінтів не має бути інструментом контролю чи звітності перед продуктовим менеджером або іншими стейкхолдерами. Це інструмент, який допомагає команді правильно запланувати навантаження та підтримувати динаміку розробки. Якщо виникають проблеми з ефективністю в команді чи окремих людей, за сторипоінтами можна шукати проблеми у процесах. Проте щойно команда розробки в Quarks вийшла на певний рівень ефективності, це стало їхнім внутрішнім інструментом.
МІФ №5
Реліз — останній етап та спосіб вимірювання ефективності у Scrum
Вимірювання результату спринту — те, чого продуктовій команді не вистачає у Scrum. Традиційно останнім етапом та фінальною точкою в спринті вважається реліз.
Як це працює в Quarks
Натомість у продуктовій розробці це тільки початок процесу, адже в результаті релізу нового функціоналу чи змін команда збирає нову інформацію, інсайти, робить висновки, а потім вирішує, чи має цінність той функціонал, який зробила.
Експерименти та тестування гіпотез складають основу роботи продуктової команди. Водночас лише 30% ідей мають цінність для бізнесу і користувачів та залишаються в продукті назавжди. Тому командам точно не варто фокусуватися виключно на кількості та частоті релізів. Scrum допомагає системно випускати релізи, але він не впливає на те, скільки з них матимуть вплив на продукт та наскільки він буде успішним.
В Quarks ефективність того чи іншого процесу у команді оцінюють за:
динамікою релізу змін (Time to market);
якістю продукту з точки зору наявності дефектів чи проблем;
ефективністю змін та впливу на продукт;
задоволеністю команди: наскільки їй комфортно працювати в такому процесі.
МІФ №6
Scrum підходить усім командам
Scrum — найпопулярніший Agile-фреймворк, проте насправді він підходить далеко не всім командам. Наприклад, деяким сервісним компаніям завдання від замовника можуть приходити частіше ніж раз на спринт. Також Scrum не підійде тим командам, де є залежності в процесах та потреба додаткової взаємодії або комунікації. Ці проблеми вирішуються такими фреймворками, як Safe чи lEss, але вони додають ще більше церемоній та додаткових ролей. Scrum не буде ефективним в забюрократизованих компаніях, де команда не зможе бути повністю автономною, а чекатиме на погодження від стейкхолдерів.
Загалом, цей фреймворк може бути дієвим для багатьох проєктів, але важливо враховувати контекст та потреби. Якщо методологію неможливо адаптувати, варто розглянути інші підходи.
Як це працює в Quarks
Обираючи будь-який фреймворк, важливо, щоби не команда адаптувалася під нього, а навпаки: підібрати такі практики, з якими всім буде комфортно працювати та досягати цілей. Як і всі інші процеси, цю методологію треба регулярно переглядати та безперервно покращувати через зворотний фідбек команди.
Ключове завдання менеджера — зібрати сильну команду, надати їй весь необхідний контекст й інструменти для роботи та допомогти стати автономною. Якщо це вдалося, можна далі експериментувати з методологіями та обирати ті практики, які допоможуть команді бути ефективнішою.
Отже, варто памʼятати, що Scrum народився в 1990-х роках. Деякі з його концепцій просто неможливо імплементувати сьогодні. Наприклад, mobling programming — групове програмування, коли в команди є один монітор та одна клавіатура, які передаються по колу, а код пишеться колективно. Або ідея co-located-команд — коли усі мають сидіти за одним столом в одній кімнаті, щоби уникати зайвих листів та чатів та вирішувати усі питання одразу. Кожна команда має брати лише найкращі практики, які відповідають її поточним проблемам та цілям, та уникати сліпого впровадження церемоній та ролей заради дотримання правил.
