Зокрема, для онлайнової книгарні можна написати такі побажання:
«Як клієнт, я хочу мати змогу проглядати книжки за жанром, щоб легше знаходити мій улюблений різновид».
«Як клієнт, я хочу додавати книжку в кошик, щоб її можна було купити».
«Як менеджер книгарні, я хочу мати змогу відстежувати покупки клієнтів, щоб пропонувати їм конкретні книжки на основі куплених раніше».
На такі побажання й має орієнтуватися команда. Обговорення цілком може обертатися навколо їх виконання. Вони достатньо конкретні, щоб бути реалістичними, але не нав’язують, як їх слід виконувати. Пам’ятайте: команда вирішує, як буде виконуватись робота, але що буде виконуватись, вирішується діловою цінністю. Повне зібрання побажань щодо ідеї (у цьому випадку онлайн-книгарні) часто називається «епіком».
Це користувацький сюжет, надто довгий для роботи з ним цілком, який містить у собі ряд коротших сюжетів, що складаються в єдину ідею.
Тім Столл є одним із тих хлопців, чия кар’єра, як то кажуть, охоплює «широкий спектр подій», з основним спрямуванням на прискорення роботи команд. Він служив медиком у спецназі, пройшов Ірак та Афганістан; у ЦРУ та поліції мав справу із жорстокими злочинцями; а зараз працює Scrum-тренером. За його словами, він завжди був Scrum-тренером, навіть коли керував спецопераціями.
«У спецназі, – каже він, – ми не називаємо їх побажаннями чи сюжетами. Ми називаємо їх курсами дій. Але, по суті, це одне й те саме».
Ось одна з кількох історій, які Тім може розповісти публічно, про операцію спецназу – медичну місію до Лаосу. «Ми мали два епіки. Першим був курс медичної підготовки – навчання місцевих збройних сил тактичної медицини. Другий стосувався розмінування боєприпасів, що не розірвалися».
Як медик, Тім відповідав за перший епік. Він каже, що перш за все сів та визначив, що потрібно зробити і як скомпонувати окремі складники загального завдання. За його словами, він почав з ідей, що дуже легко вкладаються в систему Scrum.
«Як медик сил спеціального призначення, я повинен навчити моїх учнів основ анатомії, щоб вони краще розуміли будову людського організму».
Починаючи розписувати свої побажання, Тім розумів, що почати треба із цього, бо для надання першої допомоги його учням потрібно знати, де проходять які кістки. «Перш за все, я розкажу їм про довгі кістки, потім про короткі, тоді про зап’ястки, гомілки, сухожилки та зв’язки». Лише після закладення основ можна буде перейти до складання цих кісток, вправляння суглобів, очищення дихальних шляхів та зупинки кровотечі.
Закінчивши, він побачив, що потрібно для підтримки його навчальних цілей. Потрібен був скелет та роздавальні матеріали англійською й лаоською мовами. А потім він розбив усе на цикли, тобто спринти. «Два дні польоту до Лаосу. Тиждень на підготовку. Два шеститижневі цикли навчання. Ми мали підвищити рівень медичних знань наших учнів з базового до середнього. І ми зробили це».
Будьте готові, і все буде виконано
Розписуючи побажання, тобто складаючи перелік робіт, які треба виконати, важливо ставити перед собою два питання: «Чи готове завдання? І як ви знатимете, коли воно буде виконано?»
Візьмімо за приклад історію Тіма:
Як медик сил спеціального призначення, я повинен навчити моїх учнів основ анатомії, щоб вони краще розуміли будову людського організму.
Є одна схема, яку я завжди використовую для визначення готовності елементів беклогу. Створив її Білл Вейк, глибокий мислитель у сфері розробки програмного забезпечення. Білл стверджує, що для готовності будь-яке завдання має відповідати таким критеріям:
Незалежність. Завдання має бути реальним і виконуваним саме по собі. Воно має не залежати від іншого завдання.
Обговорюваність. Поки воно дійсно не виконане, його має бути можливо переписати. Має бути вбудований дозвіл змін.
Цінність. Завдання має бути дійсно цінним для клієнта, користувача чи зацікавленої особи.
Оцінюваність. У вас повинна бути можливість оцінити його розмір.
Стислість. Завдання має бути достатньо коротким, щоб його можна було легко оцінити та спланувати. Якщо воно завелике, перепишіть його чи розбийте на менші.
Контрольованість. Завдання повинне мати тест, який буде показником його готовності. Він складається перед розписуванням завдання.
Отже, завдання Тіма є незалежним: він може виконати його без необхідності враховувати, скажімо, пальне гвинтокрила, потрібне для доправлення учнів до місця навчання. Його завдання обговорюване: навчання анатомії – це те, що він вважає за потрібне, але якщо він прибуде туди й виявить, що учні вже мають ці знання чи частину цих знань, то може змінити свій підхід. Воно цінне: учні отримають практичні та прикладні знання про людський організм. Завдання стисле: він навчатиме основ анатомії, а не хірургічних операцій. І воно контрольоване: він знає інформацію, яку хоче донести, і може перевірити, чи дійсно його учні засвоїли цю інформацію.
Для кожного завдання, за яке ми беремося, має бути «визначення підготованості» (тобто: чи відповідає воно вищенаведеним критеріям?), а також «визначення готовності» (тобто: яких умов має бути дотримано, які тести пройдено, щоб назвати його виконаним?). На прикладі реальних проектів ми бачимо, що, якщо завдання дійсно готове, команда подвоїть швидкість його виконання. А якщо воно дійсно виконане наприкінці спринту, команда може подвоїти швидкість знову. Це є одним із трюків, потрібних для виконання вдвічі більшої роботи за половину часу.
Планування спринту
У Scrum цей вид планування проводиться абсолютно для кожного спринту під час спеціальної зустрічі. Усі збираються разом, розглядають перелік завдань, які потрібно виконати, і кажуть: «Гаразд, чого ми можемо досягти в цьому спринті? Чи готові ці завдання? Чи можливо виконати їх до кінця цього циклу? Чи зможемо ми потім продемонструвати їх клієнтові, показавши реальну цінність?» Ключем до відповіді на ці питання є лише те, наскільки швидко команда просувається вперед.
Знайте вашу швидкість
Ми можемо нарешті почати відповідати на питання про те, коли буде виконано проект, бо тепер знаємо, як вимірювати справжню роботу команди. Ми маємо всі ці побажання (користувацькі сюжети) – речі, які потрібно зробити. І ми оцінили їх – це тягне на вісім, те на три і т. д. Після цього починаємо наш перший спринт. Скажімо, тривалістю в тиждень. Наприкінці цього тижня ми підраховуємо всі завдання, які виконали, підсумовуємо бали їхніх оцінок, і ці цифри повідомляють нам, наскільки швидко команда просувається вперед, її швидкість. Знаючи ж швидкість, можна подивитися, скільки побажань ще залишилось і на скільки балів вони. І тоді ви знатимете, коли все буде виконано.
Крім того, знаючи свою швидкість, ви можете визначити найважливішу річ у Scrum: що заважає вам просуватися швидше? Що не дає вам прискоритись? У попередньому розділі я говорив про марнування, про речі, які вас затримуватимуть. Тепер же час побачити, чи дійсно ви позбуваєтесь марнування.
Повернімося до компанії Medco, з якої почали цей розділ. Після оцінки всієї роботи я зібрав вище керівництво, відповідальне за проект. Там були кілька віце-президентів, які очолювали цілі служби компанії, навіть старший віце-президент.
Ми сиділи в конференц-залі, і цей старший віце-президент хотів почути відповідь лише на одне питання.
– Чи впораєтесь ви до обіцяної президентом дати? – спитав він, ляснувши долонею по столу.
– Не знаю, – чесно відповів я. – Але ми впораємось раніше за змінену дату, яку запропонували ваші люди, або ви зможете забрати свої гроші назад.
– Цього недостатньо! Чи дотримаєтесь ви вихідних строків?