З IT-сфери до малопередбачуваних проектів
Підхід до управління проектами під назвою Scrum (у перекладі з англійської — «битва») вперше згадали у 1986 році у статті журналу Harvard Business Review Хіротака Такеучі та Ікуджіро Нонака. Японці зазначили, що проекти, над якими працюють невеликі команди зі спеціалістів різного профілю, зазвичай досягають найкращих результатів. Вони пояснили це «підходом регбі», використавши спортивний термін Scrum (штовханина, бій навколо м’яча у грі, завдяки якій він залишається у полі). Чітко сформулювали і задокументували методологію Scrum американські інженери-програмісти Кен Швабер і Джефф Сазерленд.
Scrum набув найбільшої популярності в технологічному секторі, де невеликі згуртовані команди створюють складне програмне забезпечення. Але його, на думку авторів цієї книги, легко адаптувати до інших галузей. Наприклад, інструменти скраму можна використовувати для вдосконалення мишоловки, управління маркетингом у компанії з виробництва собачого корму або для спільної роботи над книгою, як це зробили Кріс Сімс та Хілларі Джонсон. Вони написали 54-сторінкову інструкцію з скраму на основі їх опублікованого роком раніше 184-сторінкового бестселера The Elements of Scrum («Елементи скраму»), який використовується зараз у вишах США як навчальний посібник.
«Ця крихітна книга — лише факти, мем — є введенням у ряд рушійних елементів скраму: ролі, артефакти та заходи спринту», — так описали автори свою останню на сьогоднішній день спільну письменницьку працю.
Робота в спринтах дозволяє Scrum-командам отримувати більше зворотного зв’язку – від членів команди, бізнес-замовників та користувачів (клієнтів) – і з її допомогою швидше навчатися. Те, що команда дізнається, працюючи в одному спринті, допомагає планувати наступний спринт. У скрамі це називається “перевіркою та адаптацією” (одна з мантр Scrum), але можна називати це “безперервним поліпшенням”, як радять автори, оскільки скрам-команда постійно фокусується на поліпшенні продукту та процесу.
Щоб скрам працював, повинні дотримуватися:
• перевірка та адаптація;
• прозорість.
За допомогою скраму скоротили витрати, збільшили швидкість і якість роботи команд багато впливових організацій світу, серед яких навіть ФБР. Якщо велика держструктура змогла кардинально покращити свій метод діяльності, то зможете і ви.
Цінності, принципи Agile та елементи Scrum
Щоб краще розуміти суть Scrum, Кріс Сімс та Хілларі Джонсон рекомендують прочитати повний текст Agile-маніфесту, підписаного 2001 року у США представниками різних гнучких методологій. Цей документ містить 4 цінності та 12 принципів (на сайті agilemanifesto.org вони представлені 68 мовами).
Цінності Agile:
1. Люди та взаємодія важливіші за процеси та інструменти.
2. Працюючий продукт важливіший за вичерпну документацію.
3. Співпраця із замовником важливіша за узгодження умов контракту.
4. Готовність до змін важливіша за проходження початкового плану.
Принципи Agile:
1. Найвищим пріоритетом є задоволення потреб замовника завдяки регулярній та ранній поставці цінного програмного забезпечення.
2. Зміна вимог вітається і на пізніх стадіях розробки. Agile процеси дозволяють використовувати зміни для забезпечення замовнику
конкурентної переваги.
3. Працюючий продукт слід випускати якнайчастіше, з періодичністю від кількох тижнів до кількох місяців.
4. Протягом усього проекту розробники та представники бізнесу мають щоденно працювати разом.
5. Над проектом мають працювати мотивовані професіонали. Щоб роботу було зроблено, створіть умови, забезпечте підтримку та повністю довіртеся співробітникам.
6. Безпосереднє спілкування — найпрактичніший та найефективніший спосіб обміну інформацією як із самою командою, так і всередині команди.
7. Діючий продукт – основний показник прогресу.
8. Інвестори, розробники та користувачі повинні мати можливість підтримувати постійний ритм безкінечно. Agile допомагає налагодити такий сталий процес розробки.
9. Постійна увага до технічної досконалості та якості проектування підвищує гнучкість проекту.
10. Простота – мистецтво мінімізації зайвої роботи – вкрай необхідна.
11. Найкращі вимоги, архітектурні та технічні рішення народжуються у команд, що самоорганізуються.
12. Команда повинна систематично аналізувати можливі способи покращення ефективності та відповідно коригувати стиль своєї роботи.
Елементи Scrum можна подати у вигляді схеми:
Ролі
Скрам розпізнає лише три різні ролі:
• власник продукту (product owner);
• скрам-майстер (scrum master);
• Член команди (team member).
Скрам-команда складається з одного власника продукту, одного скрам-майстра та кількох членів команди зі створення продукту. Власник продукту та скрам-майстер взаємно доповнюють один одного: перший сприяє покращенню продукту, другий – процесу. Члени команди зосереджуються на результатах. Згідно з загальноприйнятим правилом, у команді має бути від п’яти до дев’яти осіб. У меншої кількості людей може не вистачити різноманітних навичок, а у більшої можуть виникнути проблеми з продуктивністю через надмірні витрати на соціальні комунікації.
Власник продукту
Відповідає за якнайшвидше повернення інвестицій бізнес-замовників у заробітну плату команди, оренду офісів, комп’ютери, програмне забезпечення тощо. Він збільшує показник ROI або, простіше кажучи, максимізує прибуток за допомогою таких способів:
• Спрямовує команду до найціннішої роботи (а не менш цінної), розставляючи пріоритети в белогу продукту. Ніхто, крім нього, немає права давати команді розробки продукту будь-які завдання чи змінювати порядок виконання.
• Переконується, що члени команди повністю розуміють вимоги. Інакше вони витрачатимуть час створення непотрібних речей.
Найчастіше власник продукту додає вимоги в беклог продукту у вигляді історій користувача. Наприклад, «Як я хочу , щоб » або «Як я хочу , щоб ». Така форма зрозуміла всім – розробникам, замовникам, клієнтам.
Для користувача книжкового інтернет-магазину та його співробітника user stories можуть виглядати так: «Як споживач я хочу шукати книги за жанрами, щоб швидше знайти ті, що мені, напевно, сподобаються», «Як представник замовника — інтернет-магазину — я хочу відстежувати покупки клієнтів щоб знати, які книги їм запропонувати».
Крім того, власник продукту для кожної історії користувача формулює критерії приймання (acceptance criteria) — достатні для задоволення користувачів умови. Висловлюючись повсякденною мовою, у піцерії критеріями приймання служила б піца замовленого клієнтом розміру та складу інгредієнтів.
Кожна завершена історія користувача повинна поступово підвищити цінність продукту. У цьому випадку також говорять про його новий приріст.
Функції власника продукту:
• утримує бачення продукту протягом кількох спринтів;
• представляє інтереси бізнес-замовників та клієнтів (кінцевих користувачів);
• розставляє пріоритети в белог продукту, замовляючи в першу чергу найважливіші елементи (користувацькі історії);
• створює критерії приймання історій;
• доступний для відповіді на запитання членів команди.
Скрам-майстер
Керує процесом за правилами Scrum (він або вже має досвід успішного застосування скраму, або пройшов для цього спеціальне навчання). Якщо скрам-команда ще не сформована, він підбирає потрібних фахівців. А потім допомагає власнику продукту проводити заходи з науки. Зокрема, слідкує, щоб стендап проходив стоячи, а не сидячи, не тривав більше 15 хвилин і в ньому брала участь лише скрам-команда (без зацікавлених осіб, які у цьому випадку можуть лише спостерігати, не втручаючись).
Якщо результат роботи команди – продукт, то результат роботи скрам-майстра – високоефективна команда . Він, як тренер, спрямовує її до вищих рівнів згуртованості, самоорганізації та продуктивності. Як експерт з Scrum він допомагає команді вчитися, застосовувати скрам та пов’язані з ним аджайл-методи. При виникненні перешкод (про які стає відомо під час тих же стендапів), що заважають членам команди виконувати роботу, він допомагає їх усунути. При цьому, незважаючи на відмінності у знаннях та обов’язках, він нарівні з членами команди, а не їхній бос.
Функції скрам-майстра:
• тренер; • експерт та консультант з питань скраму;
• усунення організаційних бар’єрів;
• куратор проекту.
Член команди
Члени високоефективних команд створення продукту дуже тісно співпрацюють один з одним і самоорганізуються. Вони самі вирішують, які інструменти та методи використовуватимуть і хто над якими завданнями попрацює.
Теоретично виконавці — вищі авторитети у цьому, як краще зробити свою роботу. Тому члени команди самі прогнозують терміни виконання завдань .
В ідеалі у команді фахівців у кожного мають бути свої унікальні навички. Місія кожного учасника команди – допомогти випустити потенційно готовий продукт у кожному спринті. Найкращі способи зробити це — зробити свій внесок у роботу у своїй спеціалізованій галузі або, коли це необхідно, працювати за межами своєї спеціалізації, щоб найкращим чином перенести власні історії з «в процесі» до «виконано». Тобто члени команди зосереджуються не так на процесі роботи, але в результатах. Якщо у ваших співробітників справа по-іншому, їм варто змінити спосіб мислення.
Функції члена команди:
• відповідає за завершення історій користувача для поступового збільшення вартості продукту;
• самоорганізується, щоб виконати всю необхідну роботу;
• прогнозує терміни виконання завдань та володіє ними;
• знає, як зробити свою роботу, і уникає думок на кшталт «це не входить до моїх обов’язків».
Артефакти
Артефакти – це інструменти, які практики скраму використовують, щоб досягти прозорості процесу. Кріс Сімс і Хілларі Джонсон відносять до них:
• беглог продукту (product backlog);
• беклог спринту (sprint backlog);
• діаграму згоряння завдань (burn chart);
• Дошку завдань (task board);
• критерії готовності (Definition of done).
Беклог продукту
Це список бажаних результатів, що включає все, що може бути корисним для створення продукту: нові функції, виправлення помилок, зміни в документації і т. п . Розробники називають ці компоненти списку «елементами бэклога» або «історіями користувача». Останній термін нагадує, що вони створюють продукти задоволення потреб користувачів.
Список історій користувача впорядкований так, що найважливіша історія (та, яку команда повинна зробити в першу чергу) знаходиться вгорі списку. Прямо під нею історія, яку команда має зробити пізніше, і т. д. Історії у верхній частині беклога повинні бути невеликими і добре зрозумілими всій команді, а в нижній частині вони можуть бути більшими і менш зрозумілими, оскільки мине час, перш ніж команда над ними попрацює.
Кожна користувальницька історія в белог продукту повинна містити таку інформацію:
• для яких користувачів вона буде корисною (для кого вона);
• короткий опис бажаної функціональності (що потрібно створити);
• причина, з якої ця історія є цінною (чому ми повинні це робити);
• Оцінка того, скільки часу займе робота над історією;
• критерії приймання, які допоможуть дізнатися, коли буде реалізована історія.
Беклог спринту
Список справ команди для спринту. На відміну від беклог продукту, він має кінцевий термін служби, рівний довжині поточного спринту. Беклог спринту включає: історії, які команда зобов’язалася завершити за цей спринт, і пов’язані з ними завдання. Історії — майбутні результати спринту, на які чекають бізнес-замовники та користувачі продукту (клієнти). Їх можна як одиниці цінності продукту, а завдання — як одиниці роботи. Щоб завершити історію, потрібно виконати завдання. Кожна історія зазвичай потребує багато завдань. При цьому над історією працює команда, а над завданням одна людина.
Діаграма згоряння завдань
Показує, який обсяг роботи зробила команда за певний період часу і що ще потрібно зробити. На горизонтальній осі X розташовується час, що вимірюється в спринтах, але в вертикальної осі Y — кількість завдань. Очікується, що лінія роботи з часом знижуватиметься в міру її виконання командою. Але іноді обсяг роботи раптово змінюється, коли додаються нові завдання чи видаляються старі. Ці події відображаються у вигляді вертикальної лінії: вона рухається вгору, коли додають завдання, або вниз, коли якусь частину роботи викреслюють з плану.
Дошка завдань
Коли завдання команди видно всім присутнім у кімнаті, не треба турбуватися про те, що якісь із них будуть забуті. Найпростіша дошка завдань складається з трьох стовпців: що потрібно зробити (to do), робиться (doing) і готове (done). Завдання переміщаються по всіх стовпцях, забезпечуючи наочність того, які вже виконані, які перебувають у процесі виконання, які ще не розпочато. Це допомагає команді бачити їхню поточну ситуацію та адаптуватися при необхідності, а також бачити прогрес команди зацікавленим сторонам — ініціаторам проекту (бізнес-замовникам) та користувачам (клієнтам).
Критерії готовності
Критерії готовності — це узгоджений командою з власником продукту список дій для завершення історії користувача або необхідні для задоволення клієнтів умови.
Наприклад, у піцерії це означає, що піца запечена, нарізана та подана на стіл.
Поєднання критеріїв приймання (їх можна порівняти зі змістом, «начинкою пирога») з критеріями готовності (формою) у результаті дає правильний продукт, зроблений правильним способом. Коли команда закінчує роботу над історією користувача, може виникнути плутанина, що саме означає слово «готово».
Програміст може вважати роботу виконаною, коли написано код, тестувальник — коли приріст продукту протестовано, оператор — коли той завантажений на сервер, а бізнесмен коли готовий до використання і його можна продавати клієнтам. Через різницю розуміння можуть виникнути неприємності, якщо замовник раптом запитає, чому команда все ще працює над історією, яку, як сказав програміст, було завершено два тижні тому.
Щоб уникнути непорозумінь, команди розробників створюють свої власні критерії готовності користувальницької історії. Вони разом вирішують, які завдання мають бути зроблені для завершення історії, та становлять контрольний список.
Пункти контрольного списку можуть включати: написання нового програмного коду, модульне тестування, регресійне тестування, написання документації, підпис документа власником продукту тощо.
Автори книги рекомендують роздрукувати критерії готовності та повісити їх поряд із дошкою завдань. Коли члени команди вирішать, що настав кінець історії, вони зберуться разом і підтвердять готовність кожного пункту списку. Тільки після цього скрам-команда оголосить історію завершеної.
Заходи
Основний ритм скраму – це спринт (його також називають циклом або ітерацією) – фіксований період часу, протягом якого команда “відкушує” невеликі шматочки проекту, перш ніж “проковтнути” інші. Чим коротший спринт, тим частіше:
• команда демонструє потенційний приріст продукту;
• отримує зворотний зв’язок, важливий для перевірки та адаптації;
• приносить користь бізнесу, надаючи замовникам свободу вибору, коли та що випускати.
В останньому випадку виникає два окремі питання:
1) Для команди – чи готовий продукт до постачання? Тобто чи достатньо високої якості продукту, щоб бізнес міг його використовувати? Чи всі поточні історії завершені?
2) Для бізнесу — чи має сенс постачати те, що є зараз? Чи достатньо додаткової вартості, щоб вивести поточний продукт на ринок?
Спринт включає п’ять зустрічей (їх називають також зборами, нарадами, подіями, заходами або церемоніями):
1) планування спринту (sprint planning);
2) щоденний скрам (daily scrum), він же стендап (stand up);
3) час історій (story time), він же грумінг (grooming);
4) огляд спринту (sprint review);
5) ретроспектива (retrospective).
Якщо ви розглядаєте збори як форму повторюваних стресових травм, автори рекомендують називати їх церемоніями, як це роблять багато прихильників скраму.
Більшість першоджерел Scrum припускали спринт тривалістю на місяць — тоді такий цикл видавався дуже коротким. На момент написання книги скрам-команди вже працювали у двотижневих спринтах, і багато хто починав працювати у тижневих. Тому в наведеній нижче таблиці вказано тривалість зустрічей для команди, яка виконує тижневий спринт, — це відправна точка, на яку варто орієнтуватися.
Планування спринту
Планування спринту знаменує собою його початок. Зазвичай ця зустріч складається із двох частин. Мета першої – доручити команді користувальницькі історії, мета другої – розподілити завдання.
Перша частина: «Що ми робитимемо?». У першій частині зустрічі власник продукту в порядку пріоритету, одну за одною, представляє власні історії, які він хотів би, щоб команда завершила під час майбутнього спринту. Група обговорює критерії прийняття першої історії з власником продукту, щоб переконатися, що правильно їх розуміє, і вирішує, чи зможе завершити її до кінця спринту. Цей процес повторюється з кожною історією доти, доки команда не відчує, що більше не зможе за вказаний час виконати якусь роботу. Зверніть увагу на поділ повноважень: власник продукту вирішує, які історії будуть розглядатися, але члени команди, які виконують фактичну роботу, самі вирішують, скільки історій вони можуть взяти на себе.
Друга частина: “Як ми це зробимо?”. У другій частині наради щодо планування спринту команда закочує рукави і починає розбивати вибрані історії на завдання.
Приклад завдань: отримати додаткові відомості від користувачів, розробити новий екран, додати нові стовпці до бази даних, провести тестування нової функції методом «чорної скриньки», написати текст довідки з продукту, запустити скрипти.
Під час цієї половини зустрічі власник продукту відповідає на запитання, а члени команди можуть скоригувати список історій, якщо зрозуміли, що взяли на себе багато чи мало історій.
Результатом наради щодо планування спринту стає беклог спринту — список усіх зафіксованих історій із пов’язаними з ними завданнями.
До завершення спринту власник продукту зобов’язаний за необхідності щось радити з продукту, узгоджувати обсяг історій і запитувати додаткові, якщо команда не попросить більше. Для тижня розробки автори рекомендують від однієї години до двох годин планування спринту.
Щоденний скрам
Щоденний скрам, іноді званий стендап мітингом або скорочено просто стендапом:
1) Регулярний. Більшість команд вважають за краще проводити цю зустріч на початку робочого дня. Ви можете вибрати інший час відповідно до переваг вашої команди.
2) Короткий. Сенс у тому, щоб відбити полювання до моралі та дискурсів, що «ведуть у пекло». Щоденний скрам завжди має проводитися не більше 15 хвилин.
3) Цілеспрямований. Кожен учасник швидко ділиться тим:
• які завдання виконав з моменту останнього щоденного скраму; • які завдання очікує виконати до наступного щоденного скраму;
• які перешкоди його гальмують.
Мета цієї зустрічі – перевірити та адаптувати роботу команди, щоб успішно завершити історії. Перевірка відбувається на зборах, а адаптація може бути після. Це означає, що команді не потрібно вирішувати проблеми на зборах: досить просто їх виявити та вирішити, хто ними займеться.
Час історій
На цій зустрічі команда оцінює обсяг майбутніх історій в белог продукту (тобто передбачає, скільки часу знадобиться для завершення певної історії) і розбиває великі з них на дрібніші. Оскільки кожна історія в белог продукту повинна включати список критеріїв приймання, на цій нараді група також уточнює їх у власника продукту, щоб знати, коли історії повинні бути реалізовані, як задумано. Зверніть увагу, що тут йдеться не про історії поточного спринту – вони тепер у белогу спринту.
Команда повинна розбивати великі історії на дрібніші, щоб вони просувалися вгору за списком беклог продукту. Маленькі історії легші у розумінні, та їх простіше закінчити за короткий період часу. На відміну від маленьких історій, великі, що знаходяться нижче в белог, визначені менш чітко.
Хоча власник продукту може виконувати більшу частину цієї роботи самостійно, час історій або грумінг (product backlog grooming) – це шанс отримати допомогу від усієї команди. На момент написання цієї книги час історій не був офіційним зібранням Scrum. Кріс Сімс і Хілларі Джонсон припускають, що це відбудеться в майбутньому, оскільки всі відомі ним високопродуктивні скрам-команди наводять лад у беклозі продукту під час цієї зустрічі. Автори рекомендують займатися цим щотижня по годині незалежно від тривалості вашого спринту.
Огляд спринту
Огляд спринту – це його публічне закінчення: на цю зустріч запрошуються усі зацікавлені особи. Це шанс для команди продемонструвати свої здобутки — готові історії, а також незавершені (які вона обіцяла завершити до кінця спринту, але не завершила), а для зацікавлених осіб побачити, як продукт поступово покращується. Під час огляду спринту власник продукту та члени команди отримують від замовників та користувачів зворотний зв’язок, який допоможе перевірити та адаптувати продукт.
На цій зустрічі рішення не ухвалюються. Рішення, чи закінчені історії, мають бути прийняті до цієї зустрічі, а що робити під час наступного спринту — на заході щодо планування спринту.
Автори рекомендують “оглядати” спринт протягом 30-60 хвилин на тиждень розробки. Тобто, якщо у вас двотижневий спринт, збори можуть зайняти від однієї години до двох. Після того, як ви проробите це кілька разів, ви дізнаєтеся, як довго ваша команда повинна перевіряти та адаптувати.
Ретроспектива
Під час ретроспективи наприкінці кожного спринту члени команди згадують, що вони дізналися за період спринту і як це можна застосувати. На відміну від традиційного «розбору польотів», мета ретроспективи не генерувати довгий список речей, які пройшли добре та погано, а визначити одну-дві стратегічні зміни, які слід зробити у наступному спринті, щоб покращити процес роботи.
Проведення ретроспективи є особливо важливим після ненормального (аварійного) завершення спринту, оскільки це допомагає команді вчитися на власному досвіді. Адже іноді відбувається щось, що позбавляє спринт законної сили — бізнес продано, замовника випередив конкурент або на ринок вийшла технологія, яка виявилася кращою за ту, над якою працювала скрам-команда.
«Незважаючи на назву (abnormal sprint termination), ні Арнольд Шварценеггер, ні Джеймс Кемерон не повинні втручатися. Якщо власник продукту змушений припинити спринт достроково, команда має відмовитись від будь-яких змін, внесених під час спринту, щоб уникнути проблем, пов’язаних із неповною роботою».
На щастя, подібне трапляється досить рідко та загалом нетипово. Тому щотижня розробки автори рекомендують від однієї до двох годин ретроспективи.
На старт, увага, спринт!
10 найкращих думок
1. Розумінню суті Scrum та ефективному використанню його інструментів сприяють цінності Agile : важливі люди та взаємодія, працюючий продукт, співпраця із замовником та готовність до змін.
2. Головне в скрамі – безперервне поліпшення продукту та процесу.
3. Скрам надає безліч можливостей отримувати зворотний зв’язок від бізнес-замовника, команди та ринку – і з її допомогою вдосконалюватись. Досвід — найкращий вчитель: виконуючи роботу в одному спринті, ви дізнаєтеся про те, що допомагає планувати наступний.
4. Основні елементи скраму – це ролі, артефакти та заходи.
5. У скрам-команді ролі розподіляються так: власник продукту, скрам-майстер і член команди. Четвертої ролі не дано, як і скорочення їх до двох.
6. Артефакти скраму роблять прозорими зусилля команди. Кріс Сімс і Хілларі Джонсон відносять до артефактів беклог продукту, беклог спринту, діаграму згоряння задач, дошку завдань та критерії готовності.
7. Основний ритм скраму – період спринту , що триває від одного тижня до місяця. Чим коротший спринт, тим частіше команда надає потенційний приріст продукту і в замовника більше вибору, коли і що постачати користувачам чи клієнтам.
8. Заходи спринту включають планування спринту, щоденний скрам, час історій, огляд спринту і ретроспективу.
9. Мета ретроспективи – виявити одну-дві стратегічні зміни , які потрібно зробити у наступному спринті, щоб покращити процес. У разі аварійного завершення спринту це особливо важливо.
10. Автори книги рекомендують командам працювати в однотижневих спринтах , приділяючи від однієї до двох годин на планування спринту, не більше 15 хвилин на щоденні стендапи, одну годину на час історій, від 30 до 60 хвилин на огляд спринту та від однієї до двох годин на ретроспективу.