Нещодавно, зайшовши на роботу до дружини, я побачив у неї на поличці яскраво-червону книгу з цікавим заголовком “Scrum. Навчитись робити вдвічі більше за менший час” (Scrum: The Art of Doing Twice the Work in Half the Time). Правду кажучи, я вже зустрічався зі Scrum’ом та бачив його у дії. Більше того, деякі моменти мені навіть вдалося втілити у своїй адміністративній діяльності. Тому, недовго думаючи, я прихопив цю книгу із собою, адже її автор саме той, хто створив метод Scrum. Звісно, “створив” — це умовна категорія, оскільки Джефф Сазерленд є більше популяризатором та формалізатором методу: у 1993 році він помітив цей гнучкий підхід, який вже досить давно використовували японці, після чого систематизував та адаптував його для індустрії створення программного забезпечення (а згодом і для інших галузей). Про це автор детально розповідає у другому розділі книги.
Зміст цього допису:
- Хто такий Джефф Сазерленд?
- Про витоки Scrum’у
- Походження слова “scrum”
- Тест Дурамбе
- Оптимальний розмір Scrum-команди
- Scrum-майстер
- Досягнення надзвичайності
- Спринти
- Стендапи (щоденні зустрічі)
- Марнування
- Дельфійський метод
- Планувальний покер
- Оцінювання готовності завдання
- Щастя
- Прозорість та Scrum-дошка
- Нульова толерантність до нечемності
- Небезпека “щасливої бульбашки”
- Беклог та пріоритети
- Власник продукту
- Безкоштовні зміни
- З чого почати перший спринт
- eduScrum
- Висновок
Одразу зауважу, що книга мені сподобалась, тому я вирішив зробити про неї окремий допис, щоб з часом було легко згадати її ключові моменти. Можливо, комусь ця своєрідна рецензія буде також корисною:
Варто почати з такої показової цитати:
«Тоді я був просто молодим пілотом реактивного літака … Повернувшись із війни у В’єтнамі я здобув ступінь магістра статистики в Стенфорді, проводячи весь свій вільний час у лабораторії штучного інтелекту. Після цього я став викладачем математики в Академії військово-повітряних сил та вступив до аспірантури з біометрики в Медичній школі Університету Колорадо.» (стор. 39)
Джефф Сазерленд має докторський ступінь. У своїй дисертації, аналізуючи онкологічну статистику, він досліджував, що відбувається у нормальній клітині, від чого вона стає раковою. Це дало йому краще розуміння теорії систем:
«Саме визначенню правил переходу складної адаптивної системи з одного стану в інший та перетворення наступного стану на позитивний замість негативного я й присвятив майже десять наступних років свого життя.» (стор. 40)
За 20+ років досвіду впровадження Scrum Джефф Сазерленд побував:
«…генеральним директором, технічним директором чи головним інженером десятка компаній, від дрібних стартапів з кількома людьми в одній кімнатці до великих підприємств із представництвами, розкиданими по всій планеті. А вже консультантом та тренером я працював іще в кількох сотнях різних фірм.» (стор. 21)
Крім того, автор є консультантом бостонської венчурної компанії OpenView Venture Partners, а також засновником тренінгово-консалтингової компанії Scrum Inc., яка згідно з Crunchbase “…is the world’s leading authority on Scrum, the most widely used Agile management framework.”.
До речі, компанією Scrum Inc. зараз керує його син JJ Sutherland, про котрого він пише у підрозділі “Scrum під час революцій” (стор. 65-69), коли Джей Джей разом з командою журналістів Національного громадського радіо (NPR) за допомогою Scrum готував репортажі з Єгипту під час революції 2011 року.
Фундаментом для Scrum’у стала стаття двох японських викладачів економіки Гіротаки Такеучі та Ікуджиро Нонаки “Розробка нового продукту. Нові правила гри” [“The New New Product Development Game”], опублікована у 1986 році у Harvard Business Review, яку Джефф Сазерленд помітив у 1993 році та про яку пише на стор. 47:
«Такеучі та Нонака вивчали команди кількох найбільш продуктивних та інноваційних компаній світу: Honda, Fuji-Xerox, 3M, Hewlett-Packard та інших. Вони стверджували, що старий спосіб розробки продукту, заданий фазовою системою планування програм NASA, — каскадна модель — дефектний у своїй основі.»
Джефф Сазерленд тоді почав працювати у IT-компанії Easel віце-президентом з об’єктних технологій і вирішив випробувати новий метод. Про результат він пише на стор. 48:
«Ми здали готовий продукт вчасно, ще до закінчення шести місяців, не перевищивши бюджет і з меншою кількістю помилок, ніж у будь-якому попередньому замовленні.»
Далі автор задається питанням, звідки ж японці взяли ідею гнучкого підходу до організації виробництва, та зазначає, що “за іронією долі, вони [японці] багато чого навчилися в одного американця — Вільяма Едвардса Демінга”, який працював на генерала Дуґласа Мак-Артура та після Другої світової війни впроваджував ці ідеї в окупованій американцями Японії. Джефф Сазерленд наводить на стор. 50 цитату з виступу Демінга перед керівниками японських підприємств про необхідність прагнення до покращення якості та однорідності продукції. Автор зазначає, що саме Демінг був ідеологом прагнення японців до безперервного покращення.
Термін “Scrum” фактично ввели автори згаданої вище статті, які спирались на певні тактичні дії гравців у регбі. Знайшовши “The New New Product Development Game”, я помітив, що самі автори використовували назву “rugby approach”, але один з ключових заголовків носить назву “Moving the Scrum Downfield” (хоча це і єдина згадка слова “Scrum” у статті). Ось що про це пише Джефф Сазерленд:
«Японські викладачі [Такеучі та Нонака] порівнювали робочий процес із грою в регбі й казали, що найкращі команди діють так, немов гуртуються задля досягнення спільної мети, що й називається Scrum: “…м’яч пасується всередині команди, яка рухається полем як єдине ціле”.» (стор. 48)
А якщо ми звернемось до Oxford Dictionaries, то побачимо таке визначення слова “scrum”:
«Rugby: An ordered formation of players, used to restart play, in which the forwards of a team form up with arms interlocked and heads down, and push forward against a similar group from the opposing side. The ball is thrown into the scrum and the players try to gain possession of it by kicking it backwards towards their own side.»
Говорячи про команди, Джефф Сазерленд розповідає про успішну компанію Salesforce.com, у якій працює близько двохсот Scrum-команд. За гнучку інфраструктуру релізів там відповідає Нікола Дурамбе, котра і керує цими командами. Ось що про неї пише автор:
«У будь-якій команді вона шукає різноманіття — вмінь та навичок, мислення і досвіду. Вона прагне, щоб команди були неегоїстичними й автономними, але також намагається зробити їх багатофункціональними. Їй потрібні люди здатні разом виконати весь проект повністю.» (стор. 71)
Мені сподобався тест Дурамбе на правильність шляху команди, про який автор пише далі. Він полягає у запитанні спеціаліста: “У якій ви команді?” Якщо той у відповідь називає продукт/проект, над яким він працює, тоді все добре, але якщо він називає спеціальність, тоді є проблема, і Дурамбе береться за її вирішення.
5. Оптимальний розмір Scrum-команди
Далі Джефф Сазерленд досить переконливо обґрунтовує оптимальний розмір команди, спираючись на різноманітні дослідження (стор. 76-79). Дуже раджу почитати (особливо тим, хто створює команди більше 9 людей). Наведу лише одну цитату:
«Командна динаміка добре працює лише в малих командах. Згідно з класичною формулою, на високому рівні функціонують семеро людей плюс-мінус двоє (хоча я бачив команди навіть із трьох). Як не дивно, але досвід показує, що, якщо у вашій команді більше ніж дев’ятеро людей, їхня швидкість насправді знижується.» (стор. 76)
Роль Scrum-майстра автор визначає у однойменному підрозділі (стор. 79-81), де зазначає, що завданням Scrum-майстра є:
«…вести команду до безперервного покращення, регулярно шукаючи відповідь на питання: “Як нам виконувати свою роботу ще краще?”» (стор. 80)
Scrum-майстер повинен забезпечувати всі зустрічі, стежити за прозорістю та допомагати команді виявляти та усувати перешкоди, які заважають їй працювати і збільшувати швидкість виконання завдань.
На стор. 98 Джефф Сазерленд також наводить три запитання, які Scrum-майстер повинен задавати кожному члену команди на щоденних зустрічах (стендапах):
1. Що ви робили вчора, щоб допомогти команді завершити спринт?
2. Що ви робитимете сьогодні, щоб допомогти команді завершити спринт?
3. Які перешкоди стоять на шляху команди?
У кінці третього розділу “Команди” автор розповідає про головні передумови для досягнення надзвичайної ефективності роботи Scrum-команди, коли всі працюють із магічною злагодженістю, перевершуючи самих себе:
«Уся суть у створенні правильної структури з правильними стимулами та наданні людям свободи, поваги й повноважень діяти самостійно. Надзвичайність не можна спустити згори — вона має прийти знизу.» (стор. 87-88)
І тут я пропоную всім, хто вже використовує Scrum (або думає, що його використовує) запитати себе: “А чи маю я достатньо свободи, поваги та повноважень діяти самостійно?” Якщо відповідь буде негативною щодо будь-якого пункту, то, впевнений, що Джефф Сазерленд здивується, якщо ви називаєте свій підхід Scrum’ом 🙂 . Мій управлінський та науково-педагогічний досвід підказує, що багато людей, на жаль, люблять хапатись за модні назви та формальні ознаки, не витрачаючи час на вивчення фундаментальних речей. Це ніби сприймати східні бойові мистецтва лише як спосіб натовкти комусь пику, ігноруючи філософські та культурні аспекти.
Ще один важливий момент для успішності Scrum-команди — автор радить не шукати винних (стор. 83), а заохочувати позитивну поведінку, зосереджуючи увагу на спільній роботі та досягненні результату.
«Не звинувачуйте. Не шукайте поганих людей, шукайте погані системи — ті, що стимулюють неправильну поведінку та винагороджують погану роботу.» (стор. 89)
Також Джефф Сазерленд наголошує, що:
«Команда повинна мати всі потрібні вміння та навички для виконання проекту.» (стор. 88-89)
І ще одна цитата, але вже з наступного розділу “Час”:
«Команда має прагнути стати видатною.» (стор. 101)
У четвертому розділі автор вводить поняття “спринту”. Він рекомендує розбити всю роботу (проект) “на завдання, які можна виконати протягом регулярних, чітких, коротких періодів — в ідеалі від одного до чотирьох тижнів” (стор. 105). Ці періоди він і називає спринтами, оскільки “ця назва асоціюється з інтенсивною роботою” (стор. 94).
На початку кожного спринту команда повинна відповідно до пріоритету (реальної цінності) вибрати завдання, які повинна виконати (беклог спринту). Причому під “виконати” мається на увазі — завершити повністю, тобто створити “щось придатне для використання” (стор. 105), щоб це можна було продемонструвати замовнику та отримати від нього зворотній зв’язок. До речі, це і є ключовою відмінністю гнучкого підходу до розробки у порівнянні з традиційною каскадною моделлю, яка базується на діаграмах Ґантта, винайдених ще у 1910 році (подробиці на стор. 16-17), коли замовник міг побачити проект через місяці чи навіть роки (або не побачити взагалі). Джефф Сазерленд добре володіє storytelling’ом, наводячи цікаві кейси, наприклад, історію розробки системи “Вартовий” для ФБР, коли Scrum дозволив за 1,5 роки зробити те, на що каскадна модель не спромоглася за майже 10 років (причому на порядок дешевше).
Два важливих уточнення щодо спринтів (стор. 96):
- вони повинні мати визначену тривалість:
«Не можна робити однотижневий спринт, а потім тритижневий.»
- під час спринту не можна змінювати його беклог:
«…як тільки команда береться за виконання роботи, завдання блокуються. Ніхто за межами команди не може вже нічого додати до переліку.»
9. Стендапи (щоденні зустрічі)
Окрім зустрічей для аналізу та планування спринтів, у Scrum є ще один тип “мітингів”. Це щоденні зустрічі, які Джефф Сазерленд назвав стендапами, оскільки він наполягає, щоб вони відбувались стоячи. На думку автора, це дозволяє не затягувати час та забезпечити активну участь кожного в обговоренні (стор. 101).
Два важливих нюанси:
- Зустріч проводиться в один і той самий час кожного дня, і присутність на ній є обов’язковою для всіх.
«Якщо раптом присутня була не вся команда, обговорення просто не відбувалось.» (стор. 100)
- Зустріч не повинна тривати більше 15 хвилин.
«Якщо вона [зустріч] займає більше ніж п’ятнадцять хвилин, то ви робите щось не так.» (стор. 98)
Під час стендапу Scrum-майстер, який відповідає за процес, ставить кожному члену команди три запитання, які я вже цитував вище, але продублюю тут для зручності:
1. Що ви робили вчора, щоб допомогти команді завершити спринт?
2. Що ви робитимете сьогодні, щоб допомогти команді завершити спринт?
3. Які перешкоди стоять на шляху команди?
Тобто відповіді на ці запитання допомагають зрозуміти “перебіг спринту та стадії розв’язання його завдань”:
«Чи будуть усі завдання виконані вчасно? Чи є можливість допомогти іншим членам команди в подоланні перешкод?» (стор. 98)
Автор також наголошує на проблемі, що
«…люди часто схильні перетворювати щоденний стендап просто на індивідуальне звітування. “Я зробив це… зроблю те…” — а тепер наступний… Оптимальний підхід нагадує радше коротку нараду гравців в американський футбол перед початком матчу. Ресивер каже: “У мене проблема з лінійним захисником”, — на що нападник-блокер відповідає: “Я подбаю про це. Лінію буде відкрито.”» (стор. 101)
Впродовж стендапу команда повинна швидко узгодити свій шлях до перемоги, тобто до успішного завершення спринту.
У п’ятому розділі “Марнування — це злочин” Джефф Сазерленд акцентує увагу на декількох важливих моментах:
- Одна справа за раз. У цьому підрозділі автор звертає увагу, що чим більше одночасних проектів виконує людина, тим більше вона втрачає часу через так зване “перемикання контексту”:
«…якщо ви маєте п’ять проектів, то аж 75 відсотків вашої роботи йде в нікуди — три чверті вашого дня спускається в унітаз.» (подробиці у таблиці на стор. 114)
- Зроблене наполовину — не зроблене взагалі:
«Невиконані завдання та незадіяні продукти є двома сторонами однієї проблеми: витрати зусиль без жодного позитивного результату. Не робіть так.» (стор. 121)
- Робіть усе правильно з першого разу. Джефф Сазерленд на цікавих кейсах доводить необхідність виправляти помилки одразу, не відкладаючи на потім.
«Якщо взятися за помилку в день її появи, на виправлення піде якась година. Якщо ж через три тижні — це буде вже двадцять чотири години.» (стор. 124)
- Понаднормова праця збільшує обсяг роботи. Тут автор наголошує на необхідності повноцінного відпочинку від роботи та розповідає про небезпеки понаднормової роботи і цікаве явище “виснаження еґо”, як різновид виснаження, коли “ви не почуваєтесь утомленими фізично, але ваша здатність приймати правильні рішення знижується”.
«Elon Musk said on Monday via Twitter that people need to work from around 80 to over 100 hours per week to “change the world.”» (Business Insider; джерело фото).
«Чому так відбувається: якщо працювати менше, виконуєш більше? На перший погляд здається, що в цьому немає логіки. Скотт [засновник OpenView Venture Partners] каже, що люди, які працюють забагато годин, починають робити помилки, а це, як ми вже бачили, дійсно може віднімати більше зусиль на виправлення, ніж на створення нового продукту. Перевтомлені співробітники стають менш уважними й починають відволікати інших. Дуже скоро вони вже приймають неправильні рішення.» (стор. 129)
- Будьте розсудливі. Про три типи марнування за класифікацією Таїчі Оно:
1) “абсурдність” — цілі, які ви ставите перед командою, повинні буди амбітні, але реальні;
2) “необґрунтовані очікування” — “команда, яка залежить від регулярних героїчних дій для дотримання своїх дедлайнів, не працює так, як це має бути” (стор. 132);
3) “перевантаження” — “сюди належать обтяжлива політика компанії, що заважає роботі; непотрібна бюрократія, коли люди змушені заповнювати форми заради форм; пустопорожні зустрічі, що висмоктують час і не приносять жодної користі” (стор. 133).
У шостому розділі “Плануйте реальність, а не фантазію” автор наголошує, що коли команда аналізує нові завдання, потрібно пам’ятати про такі моменти:
- потрібно оцінювати не час, а роботу, і робити це уважно, оскільки люди, як правило, дуже погано виконують таке оцінювання;
- варто працювати не з абсолютними, а з відносними оцінками (у книзі наводиться цікавий приклад — “собакометр”, коли щось оцінюється розмірами різних порід собак, але далі автор радить використовувати не його, а трохи змінену послідовність Фібоначчі);
- великі завдання варто розбивати на менші частини;
- потрібно грамотно розставляти пріоритети (спочатку потрібно робити те, що принесе проекту найбільшу цінність).
У підрозділі “Дельфійський оракул” автор розповідає про однойменний метод оцінювання. Відповідно до цього методу:
- Кожен експерт надає незалежну анонімну оцінку об’єкту оцінювання з відповідною аргументацією.
- Далі всім експертам надають аргументацію та оцінки інших експертів, але знову ж таки — анонімно, “без жодних ознак, за якими можна було б визначити автора”.
- Потім оцінювання повторюється, поки діапазон оцінок не зменшиться до прийнятного розміру.
Зауважу, що анонімність необхідна для уникнення “ефекту стадності” та “ефекту ореолу”, про які детально можна почитати у книзі на стор. 153-155.
Але попри те, що
«…перевагою дельфійського методу є те, що він збирає широке розмаїття думок, намагається максимально виключити необ’єктивність і за допомогою поінформованих, але анонімних тверджень звужує думки до загальноприйнятої оцінки…» (стор. 157)
цей метод задовгий, тобто таке оцінювання, наприклад, може тривати дні і навіть тижні замість бажаних годин.
Тому Джефф Сазерленд рекомендує виконувати оцінювання роботи, необхідної для виконання окремих завдань проекту, за допомогою так званого “планувального покеру”:
«Ідея тут проста. Усім гравцям дають по колоді карт, на яких зображені оці цікаві числа з послідовності Фібоначчі: 1, 3, 5, 8, 13 і т.д. Кожне завдання, що потребує оцінки, по черзі викладається на стіл. Тоді всі витягають карту, яка, на їхню думку, відображує правильну кількість зусиль, і кладуть її на стіл цифрою донизу. Після цього всі одночасно відкривають свої карти. Якщо різниця значень не перевищує двох карт (скажімо, п’ятірка, дві вісімки та тринадцятка), то команда просто виводить середнє арифметичне (у цьому випадку 6,6 [напевно, мова йде про 8,5]), переходячи до наступного завдання … Якщо ж різниця перевищує три карти, ті, хто поклав карту з найбільшим та найменшим числами, пояснюють, чому вони так вважають. А потім всі проходять ще один раунд планувального покеру.» (стор. 157-158)
13. Оцінювання готовності завдання
У тому ж шостому розділі Джефф Сазерленд наводить 6 критеріїв для оцінювання готовності елементів беклогу, які створив Білл Вейк, “глибокий мислитель у сфері розробки програмного забезпечення” (стор. 165-166):
Незалежність. Завдання має бути реальним і виконуваним саме по собі. Воно має не залежати від іншого завдання.
Обговорюваність. Поки воно дійсно не виконане, його має бути можливо переписати. Має бути вбудований дозвіл змін.
Цінність. Завдання має бути дійсно цінним для клієнта, користувача чи зацікавленої особи.
Оцінюваність. У вас повинна бути можливість оцінити його розмір.
Стислість. Завдання має бути достатньо коротким, щоб його можна було легко оцінити та спланувати. Якщо воно завелике, перепишіть його чи розбийте на менші.
Контрольованість. Завдання повинне мати тест, який буде показником його готовності. Він складається перед розписуванням завдання.
У сьомому розділі “Щастя” Джефф Сазерленд звертає увагу на те, що відчуття щастя та успіх людини взаємопов’язані, причому:
«Дослідження за дослідженнями показують, що щастя передує важливим результатам та показникам процвітання.» (стор. 179)
Тому наприкінці кожного спринту він радить кожному члену команди задати такі запитання (стор. 181-182):
- Як ви почуваєтесь щодо своєї ролі в компанії за шкалою від 1 до 5?
- Як ви почуваєтесь щодо компанії в цілому за тією самою шкалою?
- Чому ви так вважаєте?
- Яка одна річ могла б зробити вас щасливішими в наступному спринті?
У цьому розділі автор використовує японське слово “кайдзен”, яке інтерпретує як “безперервне покращення”. І вказані вище чотири запитання повинні допомогти команді через обговорення дійти до кайдзену, тобто знайти відповідь на запитання:
«Що невеличке можна зробити просто зараз, щоб покращити вашу роботу?» (стор. 180)
Крім того, у сьомому розділі Джефф Сазерленд багато говорить про важливість прозорості.
«Ідея полягає в тому, що має не бути жодних інтриг, прихованих мотивів, нічого за лаштунками. Надто часто в компанії буває насправді неясно, хто над чим працює чи як щоденна діяльність кожного працівника наближає спільні цілі.» (стор. 184)
І важливу роль у прозорості грає так звана Scrum-дошка, обліплена стікерами, на якій в будь-який момент кожен може побачити, що команді ще потрібно виконати, що виконується і що виконано, тобто усі знають, як просувається спринт.
16. Нульова толерантність до нечемності
Тут просто наведу цитату:
«Менеджери також повинні мати нульову толерантність до нечемності та ніколи не дозволяти працівникам отруювати корпоративну культуру образами чи неповагою.» (стор. 193)
17. Небезпека “щасливої бульбашки”
На стор. 192-197 Джефф Сазерленд також застерігає від небезпеки, коли гордість команди від злагодженої та продуктивної роботи перетворюється на самовдоволеність. Команда починає вважати, що досягла такого покращення, після якого вже немає до чого прагнути. Це автор називає “щасливою бульбашкою”, яку потрібно одразу виявити та “лопнути”. І тут важливу роль має зіграти саме Scrum-майстер, котрий має вчасно побачити відсутність позитивного зростання та винести цю проблему на розгляд команди.
У восьмому розділі “Пріоритети” автор приділяє окрему увагу беклогу проекту, який “може бути завдовжки в сотні пунктів або містити лише кілька речей, з якими слід розібратися передусім” (стор. 206). І тут він радить передусім знайти відповідь на запитання:
«Які пункти мають найбільший бізнесовий вплив, найважливіші для клієнта, можуть принести найбільше грошей та найлегші для виконання?» (стор. 207)
Джефф Сазерленд під час визначення пріоритетів завдань беклогу пропонує керуватись принципом Парето (він сам принцип не згадує, але фактично так і є), а саме: “80 відсотків цінності закладені в 20 відсотках характеристик” (стор. 207). І тут автор вбачає необхідність у тому, кого він називає власником продукту.
Джефф Сазерленд визначає роль власника продукту (Product Owner) так:
«Власник продукту вирішує, якою має бути робота. Він чи вона розпоряджається беклогом — переліком завдань і, найважливіше, пріоритетністю їх виконання.» (стор. 208)
А на стор. 210 можна прочитати таке роз’яснення:
«Після кожного спринту власник продукту має передавати команді відгуки споживачів. Він повинен проводити половину свого часу за розмовами з людьми, які купують продукт (дізнаючись їхні думки про найсвіжіший реліз та його цінність для них), а другу половину — з командою, розробляючи беклог (показуючи їм, що клієнт цінує, а вони ні).» (стор. 210)
До речі, з деяких дискусій я зрозумів, що існує певна плутанина між позиціями Product Manager та Product Owner, тому раджу прочитати статтю “Product Manager vs Product Owner”, у якій Melissa Perri звертає увагу на деякі важливі практичні аспекти.
Що ж стосується Джеффа Сазерленда, то він звів головні характеристики власника продукту до чотирьох (стор. 211-213):
По-перше, власник продукту має розбиратись у своїй сфері діяльності…
По-друге, власник продукту повинен мати повноваження для прийняття рішень…
По-третє, власник продукту має бути доступним для команди, пояснюючи, що саме треба виконати і чому…
По-четверте, власник продукту має бути відповідальним за цінність…
Наприкінці розділу “Пріоритети” автор наголошує, що власник продукту є лідером, а не босом, тобто:
«Власник продукту задає, що потрібно виконати та чому. Як команда досягатиме цього та хто саме — справа команди.» (стор. 235)
У цьому ж восьмому розділі Джефф Сазерленд звертає увагу на те, що одним з основних джерел перевищення бюджету проекту є вартість внесення змін (стор. 226-227). Тому далі він пропонує ідею так званих “безкоштовних змін”, суть якої полягає у внесенні змін у Scrum-беклог без збільшення загальної вартості проекту. Це забезпечується за рахунок викидання з беклогу рівноцінних за обсягом роботи низькопріоритетних завдань (стор. 228).
21. З чого почати перший спринт
На стор. 233 наведено цікавий алгоритм швидкого впровадження Scrum, адресований власнику продукту:
«Перший крок — це скласти перелік завдань та дібрати команду. Подумайте про своє бачення продукту і почніть записувати речі, які вам потрібно зробити для його реалізації. Не потрібно писати все одразу — достатньо переліку завдань (беклогу) на тиждень. І поки члени команди проводитимуть свої щоденні зустрічі стоячи та виконуватимуть перший спринт, ви зможете підготувати достатній беклог для зайнятості команди протягом наступних двох спринтів … Потім, як власник продукту, складіть так звану дорожню мапу вірогідного розвитку подій…» (стор. 235)
Тут автор, на мою думку, іде трохи врозріз з попередніми своїми вимогами та побажаннями, оскільки без аналізу всього “епіку” [повного зібрання побажань щодо ідеї — стор. 164] буде важко розставити пріоритети, визначити тривалість спринтів тощо. До того ж, десь загубився планувальний покер. Проте, імовірно, Джефф Сазерленд свідомо спрощує початкові дії, наголошуючи далі, що “важливо почати”, “просто почніть”.
«Не треба присвячувати багато часу плануванню, рефлексії, медитаціям, програмним заявам чи п’ятирічним проекціям. Залиште це все конкурентам, яких ви обійдете.» (стор. 234)
В останньому розділі “Змінюйте світ” автор наводить ще декілька цікавих кейсів використання Scrum’у в освіті, у соціальних проектах, у державному управлінні тощо. Мені особливо сподобався підхід до вивчення хімії в одній зі шкіл Нідерландів. Цей підхід вчитель Віллі Вейнандс назвав eduScrum — фактично, це є одним із підходів до організації проектного навчання, за яким, я впевнений, майбутнє.
«…клас Вейнандса не схожий на навчальний кабінет. Жодних тобі столів рядами перед учителем. Вони розставлені так, щоб групи із чотирьох учнів могли бачити одне одного.» (стор. 240)
«Стоячи перед своїми Scrum-дошками (“флопс”, як вони називають їх нідерландською), учні планують, що вони збираються вивчити на конкретному уроці. Вони переносять стікери з обраними завдання з беклогу “Всі завдання” до колонки “Виконати” й беруться до роботи.» (стор. 241)
Виникає запитання: “А що ж тоді робити вчителю?”:
«Вейнандс лише походжає по класу, дивлячись на Scrum-дошку та діаграму згоряння [графік, який вказує на кількість роботи, що залишилась, та поступово наближається до нуля з кожним виконаним завданням/спринтом]. Час від часу він указує учням на помилку, швидко пояснює складний момент чи навмання бере якесь завдання з колонки “Виконано” та швидко опитує всіх учнів про нього, стежачи, щоб усі розуміли цю тему. Якщо тема зрозуміла не до кінця, він повертає її назад до колонки “Виконати”. Умовою готовності є те, що матеріал має бути зрозумілим усьому класу.» (стор. 241)
Книга Джеффа Сазерленда мене приємно здивувала. Я помітив, що подібні книжки-бестселери часто страждають на одну серйозну ваду: на сотнях сторінок може “розжовуватись” те, що можна вмістити на декількох аркушах 🙂 . Ця книжка набагато інформативніша. Навіть у цьому досить великому матеріалі мені не вдалося охопити всі нюанси, про які розповідає автор. До того ж, у ній наведено багато цікавих кейсів, якими Джефф Сазерленд обґрунтовує положення свого підходу. Однозначно рекомендую до прочитання.
P.S. Перепрошую за лонгрід, сам не очікував, що вийде такий довгий матеріал. Дякую за те, що дочитали! 🙂 Спеціально для вас — бонус 🙂 (натрапив, шукаючи ілюстрації для цього матеріалу):
1. Тайцзіцюань-стендап 🙂
2. Судячи з того, чим все закінчилось, вони явно щось робили не так 🙂 Дартам Вейдерам: можливо, не варто довіряти клонам проектування “Зірки Смерті” 🙂
Бажаю успіхів! 🙂