Scrum - Джефф Сазерленд

Нарешті, треба подумати про мотивацію. Чому ця особа хоче цю річ? Як вона служитиме та радуватиме цього конкретного клієнта? І в певному розумінні це ключовий момент. Мотивація надає всьому навколо кольору.

Мій улюблений приклад походить з інтернетівського мему кількарічної давнини. Він являє собою зображення Жана-Люка Пікара, капітана американського зорельота Enterprise із фільму «Зоряний шлях», з підписом: «Як капітан зорельота, я б хотів, щоб бортовий журнал автоматично використовував сьогоднішню зоряну дату…» Якщо подумати, це має сенс. Вас не дивує, чому в далекому майбутньому капітан зорельота мусить вручну вводити дату, роблячи запис у журналі? «Капітанський журнал. Зоряна дата 4671.7. Планета Марс така гарна з орбіти…» Ми сьогодні не мусимо цього робити, коли пишемо блог. То чому мусить він?

Ключове питання без відповіді тут – навіщо. Навіщо йому така функція? Якій меті вона слугуватиме? Чи лише для дотримування часової послідовності записів? Чи для чогось серйознішого? Чи повинні ці журнали не містити виправлень задля зручності слідчих зоряного флоту? Дві дуже різні причини: одна бажана, друга необхідна. Команді потрібно визначити, чого він дійсно хоче. При цьому вони можуть придумати зовсім інший спосіб дати йому це, додавши важливішу інформацію, про яку капітан навіть не думав, але яка буде дійсно корисною.

Часто потреби різних дійових осіб різні. Уявіть собі, наприклад, користувацьку історію (побажання), середина та кінець якої звучать так: «…мені потрібен автомобіль, щоб їздити на роботу». Тепер, якщо почати це речення «Як мешканцеві передмістя…» або «Як фермерові з Південної Дакоти, де погані дороги…», ви маєте зовсім різні інтерпретації ідеального засобу пересування.

Отже, перед тим як розставляти пріоритети завдань для вашого бізнесу, треба визначити дійову особу, користувача, клієнта – людину, яка використовуватиме те, що ви збираєтесь створити. Треба знати, що вона любить, не любить, її мрії, розчарування та радості. А потім зрозуміти її мотивацію. Як вона аргументує своє бажання? Для чого їй авто? Що саме вона робитиме з капітанським журналом?

Це також вплине на вашу оцінку завдань. Потрібна проста функція календаря? Це легко. От незмінний часовий штамп для потреб правоохоронців – це вже буде складніше.

Створюйте короткі сюжети

Проте, пишучи ваші сюжети, треба слідкувати, щоб вони були достатньо короткими для їх реальної оцінки. Уявіть побажання стосовно сайту Amazon.com: «Як клієнт, я хочу мати найбільшу у світі онлайнову книгарню, де б можна було купити будь-яку книгу в будь-який час». Сьогодні такий опис, безумовно, відповідає Амазону, але він надто великий для роботи з ним. Його потрібно розбити на частини. Менші частини.

Зокрема, для онлайнової книгарні можна написати такі побажання:

«Як клієнт, я хочу мати змогу проглядати книжки за жанром, щоб легше знаходити мій улюблений різновид».

«Як клієнт, я хочу додавати книжку в кошик, щоб її можна було купити».

«Як менеджер книгарні, я хочу мати змогу відстежувати покупки клієнтів, щоб пропонувати їм конкретні книжки на основі куплених раніше».

На такі побажання й має орієнтуватися команда. Обговорення цілком може обертатися навколо їх виконання. Вони достатньо конкретні, щоб бути реалістичними, але не нав’язують, як їх слід виконувати. Пам’ятайте: команда вирішує, як буде виконуватись робота, але що буде виконуватись, вирішується діловою цінністю. Повне зібрання побажань щодо ідеї (у цьому випадку онлайн-книгарні) часто називається «епіком».

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

Тім Столл є одним із тих хлопців, чия кар’єра, як то кажуть, охоплює «широкий спектр подій», з основним спрямуванням на прискорення роботи команд. Він служив медиком у спецназі, пройшов Ірак та Афганістан; у ЦРУ та поліції мав справу із жорстокими злочинцями; а зараз працює Scrum-тренером. За його словами, він завжди був Scrum-тренером, навіть коли керував спецопераціями.

«У спецназі, – каже він, – ми не називаємо їх побажаннями чи сюжетами. Ми називаємо їх курсами дій. Але, по суті, це одне й те саме».

Ось одна з кількох історій, які Тім може розповісти публічно, про операцію спецназу – медичну місію до Лаосу. «Ми мали два епіки. Першим був курс медичної підготовки – навчання місцевих збройних сил тактичної медицини. Другий стосувався розмінування боєприпасів, що не розірвалися».

Як медик, Тім відповідав за перший епік. Він каже, що перш за все сів та визначив, що потрібно зробити і як скомпонувати окремі складники загального завдання. За його словами, він почав з ідей, що дуже легко вкладаються в систему Scrum.

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

Починаючи розписувати свої побажання, Тім розумів, що почати треба із цього, бо для надання першої допомоги його учням потрібно знати, де проходять які кістки. «Перш за все, я розкажу їм про довгі кістки, потім про короткі, тоді про зап’ястки, гомілки, сухожилки та зв’язки». Лише після закладення основ можна буде перейти до складання цих кісток, вправляння суглобів, очищення дихальних шляхів та зупинки кровотечі.

Закінчивши, він побачив, що потрібно для підтримки його навчальних цілей. Потрібен був скелет та роздавальні матеріали англійською й лаоською мовами. А потім він розбив усе на цикли, тобто спринти. «Два дні польоту до Лаосу. Тиждень на підготовку. Два шеститижневі цикли навчання. Ми мали підвищити рівень медичних знань наших учнів з базового до середнього. І ми зробили це».

Будьте готові, і все буде виконано

Розписуючи побажання, тобто складаючи перелік робіт, які треба виконати, важливо ставити перед собою два питання: «Чи готове завдання? І як ви знатимете, коли воно буде виконано?»

Візьмімо за приклад історію Тіма:

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

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

Незалежність. Завдання має бути реальним і виконуваним саме по собі. Воно має не залежати від іншого завдання.

Обговорюваність. Поки воно дійсно не виконане, його має бути можливо переписати. Має бути вбудований дозвіл змін.

Цінність. Завдання має бути дійсно цінним для клієнта, користувача чи зацікавленої особи.

Оцінюваність. У вас повинна бути можливість оцінити його розмір.

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