Віха

Scrum на практиці

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

Як писати беклог

Елементи беклогу продукту часто записують як користувацькі історії (user stories, модуль 7): «Як гравець, я хочу одразу повторити рівень після програшу, щоб не повертатися в меню».

Добру історію перевіряють за абревіатурою INVEST. Її у 2003 році запропонував Білл Вейк. Історія має бути:

  • незалежною (Independent): її можна зробити без інших історій;
  • обговорюваною (Negotiable): деталі уточнюють разом, історія не є готовим технічним завданням;
  • цінною (Valuable): гравець чи бізнес отримає користь;
  • оцінюваною (Estimable): команда розуміє достатньо, щоб оцінити обсяг;
  • малою (Small): вміщується в один спринт;
  • перевірюваною (Testable): є критерії приймання.

Історія «Зробити онлайн-турніри» не проходить перевірку: вона завелика і її не можна оцінити. Її розбивають на менші: «Гравець бачить таблицю турніру», «Гравець отримує нагороду за перше місце» тощо.

Що робити першим

Власник продукту впорядковує беклог. Простий спосіб домовитися про пріоритети — метод MoSCoW. Його придумали в 1994 році для методу розробки DSDM. Усе ділять на чотири групи:

  • Must (обов'язково): без цього реліз не має сенсу. У грі: 20 рівнів, збереження прогресу.
  • Should (бажано): важливо, але можна відкласти. Таблиця рекордів.
  • Could (можна): приємно, якщо лишиться час. Нові скіни персонажа.
  • Won't (не цього разу): свідомо відкладено. Онлайн-турніри.

Група «Won't» важлива не менше за інші. Вона записує те, про що вже домовилися не робити, і знімає повторні суперечки.

Що обов'язково увійде в реліз, а що почекає.

  • 20 рівнів (40)
  • Збереження прогресу (8)
  • Навчання на першому рівні (5)
  • Покупки з підтвердженням дорослого (8)
  • Звук і музика (8)
  • Повтор рівня після програшу (5)
  • Таблиця рекордів (13)
  • Нові скіни персонажа (8)
  • Щоденні нагороди (8)
  • Онлайн-турніри (40)

Must: 69 поінтів з 100. Must вміщується, і Should (18) теж. Лишається 13 поінтів на Could.

До релізу лишилося чотири спринти по 25 поінтів, тобто 100. Must має вміститися повністю, Should — якщо лишиться місце. Перекладайте елементи між групами.

Як оцінюють задачі

Команда оцінює історії відносно, у сторі-поінтах (модуль 8). Найпоширеніший спосіб — покер планування (planning poker):

  1. Власник продукту читає історію.
  2. Кожен розробник одночасно показує картку з оцінкою: 1, 2, 3, 5, 8, 13, 20…
  3. Якщо оцінки сильно розійшлися, ті, хто дав найменшу і найбільшу, пояснюють чому.
  4. Голосують знову, доки оцінки не зблизяться.

Цінність покеру не в числі, а в розмові, яку він запускає. Коли тестувальник показує 13, а програміст 3, часто з'ясовується, що тестувальник знає про перевірку на десяти телефонах, а програміст про неї не подумав.

Чотири розробники оцінюють одну історію.

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

  • 3Програміст
  • 5Дизайнер
  • 13Тестувальник
  • 5Другий програміст

Оцінки розійшлися від 3 до 13. Програміст думав лише про кнопку «Ще раз». Тестувальник знає, що повтор треба перевірити на всіх 20 рівнях і трьох телефонах.

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

Як проходять події

Планування спринту.

  • Власник продукту пропонує ціль спринту.
  • Команда бере з верху беклогу стільки історій, скільки закриває за спринт. У студії це близько 25 поінтів (модуль 8).
  • Обрані історії розбивають на задачі на день-два.
  • Якщо ціль не вміщується, її змінюють. Розтягувати спринт не можна.

Щоденний скрам.

  • Розробники стоять перед дошкою і говорять про ціль спринту, а не звітують по черзі.
  • Корисне питання: «Що заважає нам досягти цілі?»
  • Деталі обговорюють після зустрічі ті, кого вони стосуються.

Огляд спринту.

  • Команда показує робочу гру, а не слайди.
  • Засновники і кілька гравців пробують нові рівні.
  • Відгуки одразу йдуть у беклог.

Ретроспектива. Найпростіший формат — «Почати, припинити, продовжити»:

  • що почати робити;
  • що припинити;
  • що продовжити.

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

Що робить скрам-майстер

Скрам-майстер не роздає задачі. Його тиждень виглядає так:

  • допомагає власнику продукту тримати беклог у порядку;
  • навчає команду Scrum;
  • прибирає перешкоди: домовляється про тестові телефони, захищає команду від термінових прохань посеред спринту;
  • стежить, щоб події не розросталися і давали результат.

Коли спринт скасовують

Скасувати спринт може лише власник продукту, і лише тоді, коли ціль спринту втратила сенс. Наприклад, засновники вирішили відмовитися від онлайн-турнірів, а весь спринт був про них. Готову роботу показують, решту повертають у беклог, і команда планує новий спринт.