Як ми впроваджували SCRUM: сім місяців і працююча система

Страшний сон команди розробників — пірнути в незнайому предметну область, оцінити напівсиру ідею й дати тверду обіцянку вкластися у фіксований строк за фіксовані гроші. Насправді дати точну оцінку неточних вимог нереально. Ми пішли іншим шляхом і розповідаємо, як адаптували класичний SCRUM під реальний проєкт: гра в покер в офісі, викинутий функціонал, «брутальний редактор» для завуча, велетенські креслення на стінах, жива стрічка замість десятка месенджерів, а ще маркери, стікери й голосування крапками.

Навіщо SCRUM, коли вимоги неточні

Типовий шлях у проєктному менеджменті — скласти якнайдетальніше технічне завдання до початку розробки, а потім реалізувати весь функціонал одним великим шматком. Але такий «водоспадний» підхід несе інші ризики: замовник бачить перший результат аж наприкінці проєкту, і той результат може виявитися дуже далеким від реальних бізнес-цілей і потреб користувачів. Навіщо так ризикувати, якщо можна піти зовсім іншим шляхом?

Коли під час знайомства з проєктом є розуміння «ми знаємо, що ми цього не знаємо» і навіть «ми не знаємо, де межі того, чого ми не знаємо», виручає SCRUM.

Специфіка SCRUM може відлякати того, хто ніколи не працював із цим фреймворком: на старті ще невідома довжина шляху, який доведеться пройти, щоб отримати робочий проєкт, який задовольняє на 100%. Замовнику складно — він не може підготувати стратегічний план розвитку проєкту з достовірними датами релізів. Невідомість лякає, особливо коли оплачувати цей шлях треба вже зараз.

Але є й плюси: замовник на старті не мусить детально та скрупульозно описувати всі функції й особливості величезної майбутньої системи. А ще він може практично будь-якої миті змінити пріоритети й підлаштуватися під зовнішній конкурентний ринок.

SCRUM спирається на концепцію малих кроків: випускати версії робочого програмного забезпечення регулярно, якомога частіше й раніше. Кожна ітерація — це мікроетап розробки, який негайно перевіряється практикою. Це означає, що вже після першої ітерації замовник отримує цілком корисний, нехай і невеликий, але робочий функціонал, перевіряє його в справі й одразу дає зворотний зв'язок.

Важливі ключові рішення — яку наступну цінність дати бізнесу — команда ухвалює перед кожною новою ітерацією, постійно. У результаті система розвивається критично-оптимальним шляхом доти, доки не стане максимально відповідною бізнесу. Замовник тут є частиною команди: за успішність розробки відповідають і виконавець, і замовник. Вони — в одній команді, а не по різні боки столу.

Проєкт: автоматизована система для «Академії сучасної освіти А+»

Ми хочемо розповісти про наш шлях адаптації класичного SCRUM-фреймворку в роботі над автоматизованою системою управління для «Академії сучасної освіти А+». Це сучасний освітній центр у Києві, до якого входять школа, дитячий садок, центр раннього розвитку, музична, танцювальна та спортивна школи, художні студії й центр вивчення іноземних мов.

Як замовнику й виконавцю почати працювати за SCRUM

Щоб працювати в незнайомій парадигмі, замовнику іноді доводиться змінювати звичне мислення й опинитися в одному контексті з виконавцем. Тому перед розробкою системи для Академії ми організували спільний тренінг із командою Scrum Ukraine. Його головні цілі: познайомитися, вникнути в термінологію, відпрацювати всі методики в ігровій формі, змоделювати основні активності, зрозуміти, з чого почати, розподілити ролі й прописати обов'язки.

За три дні спільного тренінгу ми, використовуючи так званий helicopter view, сформували майбутню систему великими мазками й зафіксували це на часовій прямій у вигляді Project RoadMap.

Helicopter view — a general description or opinion of a situation, rather than a detailed oneВизначення терміна

Які висновки ми зробили після цього етапу

• Спільний тренінг допомагає змінити мислення замовника й команди.
• Product RoadMap дозволяє візуалізувати високорівневий план розробки та приблизно розпланувати релізи. Важливо розуміти, що це «жива дорожня карта», яка змінюватиметься в міру відкриття нових деталей розробки.
• Домовленість про глобальні правила гри потрібна «на березі»: product owner після кожного спринту отримує цінність — робочу систему, яку слід одразу ж використовувати, а потім давати зворотний зв'язок.

Третій пункт обов'язковий, без нього нічого не запрацює. Бо надії на запуск після абстрактної повної готовності у фіналі призводять до розчарувань, причому з обох боків:

• З боку замовника: «Це те, що ми просили, але це не те, що нам потрібно».
• З боку виконавця: «Ми чітко робили те, що ви просили. А тепер ваші вимоги звучать для нас зовсім інакше. Ми згодні все переробити, але за ваш кошт. І взагалі змін так багато, що доопрацювання займе ще пів року».

Крок 1. Бізнес-аналіз, product backlog і user story

Розробку будь-якого проєкту ми починаємо з бізнес-аналізу: необхідно зрозуміти специфіку. У будь-якій компанії завжди багато процесів, і наше завдання в дослідженні — з'ясувати, як учасники системи взаємодіють між собою, перш ніж будувати систему. Після раунду проблемних інтерв'ю та обробки отриманої інформації ми отримали опис предметної області у вигляді прикладів використання.

Хоча SCRUM не вимагає наявності специфікації на розробку, те, що в нас був готовий опис предметної області, виявилося великим плюсом. Цей документ ліг в основу product backlog — бази для старту SCRUM.

Product backlog — список вимог, історій, функціоналів, упорядкованих за ступенем важливості. З такого списку все починається. При цьому всі вимоги описані зрозумілою для замовника мовою. Елементи цього списку — user story, «користувацькі історії». Наш product backlog налічував 203 історії, згруповані за сегментами для зручності.

Які висновки ми зробили після цього етапу

• Тривалість наших спринтів становитиме два тижні. Чому? Короткі спринти зручні: вони дозволяють команді бути максимально гнучкою — готовою часто коригувати плани. Короткий спринт означає короткий цикл зворотного зв'язку, а отже, часті релізи. Часті релізи = швидкі відгуки від клієнтів = менше часу на роботу в неправильному напрямку = швидке навчання й удосконалення.
• У довгих спринтів свої плюси — менше накладних витрат на кшталт планування спринту, демо тощо. Але ми обрали короткі, щоб бути гнучкими й менше ризикувати.

Крок 2. Планування спринту та перші цінності для бізнесу

Нашою першою цінністю для бізнесу став електронний журнал. Для більшості досвідчених розробників це видасться утопією: перед нами чистий аркуш, ще немає жодного довідника, користувацького інтерфейсу, системи авторизації, жодної бізнес-сутності — а ми зобов'язуємося надати одну з найскладніших функцій системи.

Для нас обов'язково було отримати дві речі: сформульовану ціль спринту й затверджений sprint backlog. Наш product owner завжди починав планування спринту з опису того, що треба зробити насамперед, — найзначущіших історій. Після цього команда оцінювала трудовитрати для всіх user story, починаючи з найважливішої. У процесі в команди виникало багато питань щодо того, як це має функціонувати.

Sprint planning — це дуже важлива SCRUM-активність. Усі усвідомлюють відповідальність за правильну оцінку, тому що:

• це дозволяє бізнесу зрозуміти, якого функціоналу він може очікувати наприкінці спринту, а команді — бути передбачуваною й перебувати «on the same page» із замовником;
• цінність наполовину реалізованої історії нульова, тому всі заплановані в межах одного спринту історії потрібно довести до кінця;
• будь-які зміни оцінки протягом спринту ігноруються.

Електронний журнал після першого спринту

Спрощення й допущення для першого спринту. У системі — два користувачі: викладач і батьки; один клас — 5«А»; справжній склад класу, внесений вручну напряму через SQL-запити; справжній розклад для 5«А», сформований так само напряму записом у таблиці.

User story № 1: викладач заходить у систему й виставляє оцінки з будь-якого предмета з розкладу класу за день. Система з однією простою, але вже робочою функцією. Уже на sprint demo викладач сказав, чим користуватися зручно, а чим — ні, щоб у наступних спринтах команда могла запланувати коригування й дати оновлений інструмент.

Яку реальну цінність дає: оцифрована успішність реального класу, актуальні оцінки, перспектива для автоматичної підготовки місячної, семестрової, квартальної звітності.

User story № 2: щотижневий звіт батькам про успішність на пошту.

Яку цінність додає: інформування батьків про поточну успішність; коментарі викладача до домашнього завдання; мінімальну, але реальну аналітику.

Після кількох спринтів я вирішив, що функціоналу для роботи викладачів з електронним журналом вистачає. Тому ми поставили розробку цього інструмента на паузу й змістили фокус на конструктор розкладу. Це нормально для SCRUM. До електронного журналу фокус розробки я повернув через десяток спринтів, і ми, частково викинувши спрощений функціонал, довели електронний журнал до стану, необхідного для аналізу річної успішності. Цей функціонал на той момент був нам потрібніший. Ми отримали достатню цінність і перемкнули активну розробку на пріоритетніші частини системи.Святослав, Product owner

Для довідки: щоб зафіксувати остаточну, ідеальну версію, нам доводилося повертатися до електронного журналу протягом кількох спринтів. Версію журналу, яку вже можна було показувати батькам, ми отримали після 12-го спринту.

Ще один яскравий приклад ітеративного підходу — конструктор розкладу

До цього розклад в Академії складали на склеєних аркушах ватману А1 вручну: малювали, виділяли кольоровими маркерами, склеювали. У завуча на це йшли тижні й місяці.

Перший конструктор розкладу замовник отримав через два місяці після старту проєкту. Це був «брутальний редактор» для дуже просунутого користувача. Але він дозволив нам увести розклад для всіх п'ятих класів і протестувати систему на справжньому живому розкладі. На доопрацювання до «візуального редактора» пішло три спринти. Фокус розробки кілька разів перемикався, але до початку навчального року замовник отримав повнофункціональний конструктор розкладу.

Які висновки ми зробили після цього етапу

• Кожен спринт повинен мати чітко сформульовану ціль.
• Спрощувати функціонал, а потім його розвивати — це нормально. Саме цим і хороший SCRUM: немає єдино правильного шляху в розробці продукту. Це не підручник із завданнями й правильними відповідями наприкінці. Завжди можна розглядати багато альтернативних варіантів і виконувати їх у різній послідовності. Якщо наприкінці спринту клієнт отримує закінчену цінність, з якою може працювати, тестувати, вводити нові дані, і це просуває вперед до глобального фінального завдання, — це правильний шлях.
• Основна філософія SCRUM: не гнатися за красивим кодом на старті, а сконцентруватися на тому, щоб дати замовнику робочий інструмент. Тому можна миритися з помилками під час роботи, але треба розуміти: найкращий засіб виявити ці помилки — перестати думати про ідеальний код на рівні архітектури й дизайну, а спершу дати бізнесу робочий прототип.
• Важливо під час обговорення вносити зміни в user story, а всі артефакти зберігати й прикріплювати до карток.

Оцінка в story points: SCRUM-покер

Команда завжди адекватно оцінить user story, якщо виконано умови: детально описано поведінку реального користувача, позначено межі використання й допущення, перелічено критерії приймання. Тобто команда розуміє, «що» потрібно зробити, і приблизно припускає «як». Формулювати критерії приймання та межі використання важливо тому, що це дає однакове розуміння обсягу робіт для історій як з боку product owner, так і з боку команди.

У SCRUM оцінка історій проходить не в годинах чи днях, а в story points. Це мікс складності, ризиків і зусиль, які команда має витратити, щоб виконати історію. Для кожної команди 1 story point — величина індивідуальна, емпірична, але кожен член команди її відчуває.

Зверніть увагу: послідовність значень на картках нелінійна. Наприклад, між 13 і 21 немає нічого. Чому так?

1. Щоб не з'являлося хибне відчуття точності. Якщо історія оцінюється приблизно у 17 story points, немає сенсу обговорювати, має вона бути 15, чи 18, чи 21. Усе, що нам потрібно знати, — історію складно оцінити. Тому ми призначаємо їй орієнтовну оцінку 21.
2. Щоб не переоцінити власні можливості. Людям властиво перебільшувати свої сили, а шкала не дає сильно помилитися з оцінкою часу й ресурсів. Скажімо, команда зійшлася на думці, що на одну із задач достатньо 6 story points. Але якщо немає впевненості, що вистачить і 5, краще обрати 8. Це дозволяє встановлювати реальні строки, у які команда точно вкладеться.
3. Щоб почався діалог. Шкала допомагає учасникам поділитися своїм баченням реалізації історії, озвучити ризики й дійти консенсусу.

Дуже важливо: оцінку має дати кожен учасник команди. Чому?

• Для аргументованої оцінки кожен учасник повинен чудово розуміти, у чому суть цієї історії. Отримуючи оцінку від кожного члена команди, ми переконуємося, що всі в курсі, про що йдеться. Це збільшує ймовірність взаємодопомоги під час спринту. І головне — найважливіші питання щодо цієї історії спливуть якомога раніше.
• Різнобічне бачення проблеми призводить до сильного розкиду оцінок. Такі розбіжності краще виявляти й обговорювати якомога раніше. Після обговорення — повторна оцінка, голосування. Зазвичай пари циклів оцінювання вистачає, щоб прояснити основні моменти й створити спільне розуміння.

Яскравий кейс: «Жива стрічка»

У системі управління школою виникає багато подій різного ступеня значущості. Наприклад, учень отримав оцінку; сталася заміна, і замість математики буде біологія з іншим учителем; з учнем стався прикрий інцидент, і батьків треба негайно поінформувати; викладач написав важливий коментар до домашнього завдання.

Надсилати ці дані стандартними методами в месенджери чи на пошту незручно для користувачів, та й узагалі — це вчорашній день. До того ж повідомлення можуть стосуватися кількох людей одразу: викладачеві потрібно повідомити батькам, що учень вийшов із території школи під час уроку. У початковому документі ці правила зібрано на десяти сторінках.

Коли ми обговорювали серед розробників, у скільки оцінюємо обсяг робіт за історією «Жива стрічка», кожен висловився, скільки story points знадобиться. З'ясувалося, що в нас великі розбіжності в поглядах, і ми звернули увагу на крайні думки: чому хтось оцінив у 50, а його колега впевнений у 5 story points. Так одразу ми виявили невиявлені вимоги, які помітив обережніший розробник. Плюс розкрилися глобальні задачі, пов'язані з персоналізацією. Це прекрасний приклад того, як команда може передбачити труднощі.

Які висновки ми зробили щодо методики оцінки

• Так, це нормально, щоб оцінку технічної історії дали також QA та UX-дизайнер.
• На перших спринтах команда опирається емпіричним story points, бо звичніше й «простіше» оцінювати трудовитрати в годинах і днях. Поки ми обкатували цю систему оцінки, іноді сильно помилялися, але потім дуже точно визначали обсяг задач у story points.
• До 2–3-го спринту команда чітко розуміє, скільки це — 1 story point.

Крок 3. Щоденний SCRUM і крос-функційна команда

Щоденний SCRUM-meeting, або stand-up, та й увесь SCRUM — це історія про ефективні комунікації, які допомагають економити час і зусилля команди. Це не просто «зустрічі» й «розмови». Вони не забирають час, який можна було б витратити на роботу, а допомагають оптимізувати зусилля. Один із принципів SCRUM так і звучить: «Люди та взаємодія важливіші за процеси й інструменти».

Кожен учасник команди коротко повідомляє, згідно зі спеціально розробленим checklist, що зробив, з якими проблемами зіткнувся, що робитиме далі. Людина не залишається сам на сам із проблемою, їй швидко допомагають розв'язати її найефективнішим способом. Так інженер не витрачає час на безуспішні спроби, після яких, можливо, доведеться переробляти з нуля, і тим самим економить ресурси всієї команди.

Крос-функційність: команда готова виконувати будь-які задачі із запуску продукту

Формуючи команду, ми добирали T-спеціалістів, які розуміються на багатьох областях і щонайменше в одній є експертами. Завдяки такій універсальності всі інженери знають систему достатньо добре. Досвід кожного цінний для пошуку найефективнішого рішення: в одної людини може не виявитися потрібного для конкретної задачі досвіду, але з великою ймовірністю він буде в її колег. Те саме з боку замовника — одна людина може не знати якихось деталей, а їх знає інша.

Щоб моя команда стала ще більш самоорганізованою, я оформлювала кожен спринт за чітко заданим шаблоном: номер, ціль спринту, sprint backlog з оцінкою для кожної історії, склад команди, строки, час щоденних зібрань, організаційні події. Усе це так розкладено по поличках для того, щоб, рухаючись планомірно, крок за кроком, до кінця спринту гарантовано підготувати закінчену цінність для замовника. Щоб він був задоволений і негайно почав використовувати її в бізнесі.Майя Сокольська, Scrum Master

Які висновки ми вважаємо важливими для етапу sprint running

• Команда стане самоорганізованою, автономною, самомотивованою та надпродуктивною, якщо протягом спринту ніхто не втручатиметься в її роботу.
• Потрібно змістити акценти й розуміти, що щоденний SCRUM необхідний для комунікації, а не для адміністрування.
• Кожен наступний спринт має враховувати досвід попередніх.

Кроки 4 і 5. Демо результатів і ретроспектива

Як ми проводили демонстрацію результатів

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

Тут знову на передній план виходить ціль спринту. На наших демо часто були присутні спеціально запрошені вчителі та завучі, які не були на плануванні. Вони знали про продукт лише в загальних рисах. Ми завжди вітали, щоб після кожної продемонстрованої історії замовники самі спробували щось зробити в системі. Тоді кінцевий користувач перевіряє кожен пункт критерію приймання. Він каже, що влаштовує, а що ні, які аспекти можна покращити. І так — за кожною user story, яку було заплановано на цей спринт.

Які висновки ми зробили щодо методики демонстрації результатів

• Обов'язковий склад для демо: product owner, scrum master, представники замовника, кінцеві користувачі, які працюватимуть з інструментом, і команда.
• Перед кожною демонстрацією потрібно зачитувати відповідну користувацьку історію, щоб увести всіх у контекст.
• Корисно проводити демонстрацію на продуктовій системі з реальними даними й реальними користувачами, які вже працюють у системі. Такий підхід можливий, коли система перебуває у стадії альфа-тестування.
• Важливо не витрачати багато часу на підготовку демо: ми ніколи не створювали ефектну презентацію, а концентрувалися лише на демонстрації реально працюючого коду й отриманні зворотного зв'язку.
• Не потрібно показувати купу виправлень дрібних багів та елементарних фіч. Можна згадати про них, але демонструвати не варто, бо це забирає багато часу й знижує увагу до важливіших історій.

Як ми адаптували й проводили retrospective

Для нас ретроспектива — це важливий захід одразу ж після sprint demo. Ретроспективи корисні, особливо коли щось іде не так. Без них може виявитися, що команда наступає на ті самі граблі знову й знову.

Найчастіші граблі — це коли реальна продуктивність команди сильно відрізняється від прогнозованої. Реальна продуктивність розраховується на підставі початкової оцінки кожної історії. І коли в середині спринту ми розуміємо, що історія, оцінена в 5 story points, робиться стільки ж, скільки зазвичай займає задача на 13 story points, і далека від завершення, а якщо це ще й блокувальна історія — інші не можуть бути розпочаті через неготовність проблемної. Коли цілі спринту під загрозою, ретроспектива неминуча.

Наші ретроспективи мають абсолютно чітку структуру та цілі. Команда збирається разом, Scrum Master зачитує sprint backlog, просить висловитися кожного члена команди й оцінити з його точки зору підсумки спринту. Кожен каже, що вдалося зробити добре, що пішло не так і — головне — чому. Що продовжувати робити, а від чого відмовитися. При цьому його ніхто не перебиває. Свої висновки, записані на стікері, він розміщує в одній із колонок:

• добре;
• могло бути й краще;
• треба фіксити.

Після того як команда закінчить мозковий штурм щодо всіх проблемних стікерів, я проводжу «точкове голосування»: кожен член команди має три голоси — три крапки маркером на стікерах. Він може віддати всі свої голоси одразу одній проблемі, а може розподілити інакше. На підставі цього командного голосування ми обираємо 2–3 покращення, на яких фокусуємося в наступному спринті. А на початку наступної ретроспективи перевіримо, що в нас вийшло. Така собі «перевірка домашки».Павло Камишов, Agile Coach

Приклад наших покращень за результатами однієї з ретроспектив

• Коли розробник робить front-end і ми починаємо його впроваджувати, необхідно, щоб дизайнери були доступні на 100%.
• Обговорити з product owner включення методологічних годин.
• З ергономіки важливо отримувати максимальну документацію.
• Не варто накопичувати технічний борг. Погодити з product owner виділення 10% на технічні історії.
• Має бути спеціаліст, який розв'язуватиме технічні питання в міру їх виникнення.
• Перед кожним sprint planning обов'язково проводити sprint grooming.

Так, SCRUM вимагає активної, залученої роботи всіх учасників команди. На активності — grooming, planning, щоденний SCRUM — у нас ішло близько 12% оплачуваного часу. Це своєрідна ціна за прозорість, передбачуваність і зниження ризиків.

Один тиждень роботи може заощадити одну годину планування.Павло Камишов, Agile Coach of Scrum Ukraine

12% — багато, але воно того варте: у класичному «водоспаді» ціна використання методології — це окрема роль проєктного менеджера. У середньому в нашому сегменті ринку на менеджмент витрачається близько 15% від вартості розробки.

Які висновки ми зробили щодо методики проведення ретроспектив

• Для нас ретроспектива є другим за значущістю заходом у SCRUM після планування спринту.
• Висловлюється кожен член команди, щоб усі перебували в одному інфополі.
• Кожна зміна має свою ціну. Необхідно домовлятися з product owner про включення в sprint backlog технічних історій і методологічних годин.
• Методологічні години оплачує замовник.

Крок 6. Product backlog refinement, або grooming

Багато колег, знайомих зі специфікою IT, засумніваються: як під час планування спринту команді може бути все настільки ясно, що вона готова давати оцінку всім user story? Так, дійсно, без підготовки такої злагодженості не вийде.

Для того щоб це працювало, існує спеціальна SCRUM-активність: product backlog refinement. Для її проведення необхідно попросити product owner дати горизонт планування — окреслити, які історії можуть бути кандидатами на найближчий спринт. Якщо серед них виявляться історії, що потребують поглибленого вивчення або спеціальних компетенцій, яких немає в команди, призначається зібрання — grooming, або pre-planning.

Наш product owner був дуже компетентним, тому ми завжди мали достатній горизонт бачення, як система розвиватиметься, і регулярно проводили refinement. Адже прозорість — один з основоположних принципів SCRUM.

Які висновки ми зробили щодо методики проведення refinement

• Це важливий захід, який дозволяє прояснити, чого ми не знаємо і яких компетенцій нам бракує. Так, одного разу було вирішено залучити стороннього розробника-консультанта у специфічних питаннях, досвіду розв'язання яких у нас на той момент ще не було.
• Ці обговорення проходили в нас дуже ефективно: ми розглядали безліч альтернатив і варіантів, що дозволяло тримати проблему в голові, і до sprint planning найскладніша історія вже була «розкладена по поличках».
• Складні, здавалося б, нерозв'язні проблеми знаходять зрозумілі рішення. Іноді достатньо просто купити бібліотеку, ніж вести розробку складної ділянки самостійно.

Experience shows that 10% is a sensible average of the overall time incurred on a Sprint to spend on Product Backlog refinement.Verheyen, Gunther. Scrum — A Pocket Guide

Фейли: три моменти, де ми б підстелили соломки

Так, ми відверто в захваті від розробки за методологією SCRUM, але це не означає, що все проходило гладко. Ось три моменти, де ми підстелили б соломки, якби знали заздалегідь, що піде саме так.

1. Робота за звичними схемами. На одній із ретроспектив ми детально проаналізували причину аномального відхилення «реальної продуктивності» команди в усіх історіях за участю дизайнерів. Реальна продуктивність зазвичай розраховується за формулою: прогнозована продуктивність / фактична продуктивність. Ми виявили, що дизайнери за звичкою організувалися у знайомий їм послідовний waterfall. Як результат: задачі виконувалися послідовно, розробники витрачали час на почергове включення на різних етапах із затримками, викликаними необхідністю доводити до кінця вже розпочаті задачі. Висновок: мабуть, найболючіша для нас історія, яка принесла найбільше шкоди й була виявлена не одразу. Потрібно регулярно перевіряти, чи всі учасники команди перемкнулися на роботу за новими стандартами.
2. Зайва робота над непотрібним функціоналом. На другому спринті product owner піддався думці одного із завучів, який вважав, що «журнал куратора» — украй важливий функціонал. Ми взяли цю історію у спринт і витратили на неї зусилля. Чому це помилка: цей інструмент можна було тестувати тільки на пізніх етапах, бо йому потрібні були накопичені дані, яких на той момент не було. Як результат: його не перевіряли, не використовували, не розвивали. Потрібні функції було розв'язано інакше й зовсім не так, як думав той завуч, — зовсім через інші інструменти. Висновок: беріть у роботу тільки те, чим одразу ж почнуть користуватися.
3. Орієнтація на просунутих користувачів. На одному з етапів ми взяли в роботу історію з «редактором замін», у розробці якої брав участь учитель — дуже досвідчений користувач комп'ютерів. У підсумку ми отримали чудовий інструмент, але його не могли використовувати звичайні вчителі школи, які не були настільки просунутими. Висновок: підтверджувати історію на regular customers.

Загальні висновки й результат

Висновок № 1. Про гнучкість: SCRUM дозволяє бути ефективною командою

Результати кожного спринту залежать від вхідних задач, ефективності, скоординованості, відповідальності команди та якісного зворотного зв'язку. Вхідні дані дає product owner. Він же відповідає за контекст, у якому використовуватиметься функціонал, за якість формулювання вимог, забезпечує достатню глибину деталізації.

SCRUM вимагає від команди завершення цілком відчутного відрізка роботи, що дозволяє отримати цінність — інструмент, який можна надати користувачеві наприкінці кожної ітерації. Це допомагає бачити рішення в роботі й на початкових етапах розуміти, що потрібно змінити, щоб просунутися далі.

Висновок № 2. Про максимально ефективне використання ресурсів

SCRUM — форма організації роботи, вигідна і замовнику, і виконавцю. Робота ітераціями дозволяє вже на ранніх стадіях розуміти, що йде не так, а отже — вчасно вносити корективи. Підготовка до кожного спринту й специфіка його організації допомагають щоразу робити тільки те, що потрібно замовнику, і не йти вбік. І це дає колосальну ефективність витрачених ресурсів, часу та зусиль. Замовник уже на початкових етапах отримує працюючу ділянку системи: після перших спринтів бере зроблений функціонал у роботу й тестує його в справі.

SCRUM — коли обидві сторони застраховані від ризиків

Зникає бар'єр, по різні боки якого в класичному проєктному менеджменті перебувають виконавець і замовник. У принципі зникають позиції «замовник» і «виконавець», залишається команда. І немає умов для можливої конфронтації.

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

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

А замовник отримав чудовий продукт: набір інструментів для сучасної школи, здатний швидко трансформувати її у школу майбутнього.

Матеріали та література, які нам допомогли

• Software Estimation: Demystifying the Black Art (Developer Best Practices)
• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• Agile Retrospectives: Making Good Teams Great
• Verheyen, Gunther. Scrum — A Pocket Guide