Читати книгу - "Scrum"

тривалість, меншу за місяць. Більшість людей сьогодні використовує одно- чи двотижневі спринти. Члени команди дивляться на верхню частину беклогу та прогнозують, скільки завдань із неї вони можуть виконати в цьому спринті. Якщо команда вже пройшла кілька спринтів, вони мають ураховувати кількість балів, які отримали за попередній спринт. Ця кількість відома як швидкість команди. Scrum-майстер та команда повинні намагатися кожного спринту збільшувати цю кількість. Це ще одна можливість для команди та власника продукту переконатись, що всі чітко розуміють значення цих пунктів плану для реалізації спільного бачення. Також під час цієї зустрічі всі мають узгодити мету спринту – чого вони хочуть ним досягти.

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

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

Іншим способом зробити все видимим є створити діаграму згоряння завдань. На одній її осі буде кількість балів, набраних командою за спринт, а на другій – кількість днів. Кожного дня Scrum-майстер підраховує кількість балів виконаних завдань і відзначає її на діаграмі згоряння. В ідеалі там має спостерігатись різке зниження кривої, що вестиме до нуля балів в останній день спринту. (Більше див. у розділі 7 «Щастя».)

8. Щоденний стендап. Це серце всього Scrum. Кожного дня, в один і той самий час, не більш ніж на п’ятнадцять хвилин, команда та Scrum-майстер збираються разом і відповідають на три питання:

• Що ви робили вчора, щоб допомогти команді завершити спринт?

• Що ви робитимете сьогодні, щоб допомогти команді завершити спринт?

• Чи є якісь перешкоди, що заважають вам чи команді досягти мети спринту?

І це все. На цьому зустріч закінчується. Якщо вона займає більш ніж п’ятнадцять хвилин, то ви робите щось не так. Насправді вона допомагає всім членам команди чітко розуміти перебіг спринту та стадії розв’язання його завдань. Чи всі завдання буде виконано вчасно? Чи є можливості допомогти іншим членам команди в подоланні перешкод? Завдання не розподіляються згори – команда є автономною й робить усе сама. Немає жодного детального звітування перед начальством. За усунення перешкод для прогресу команди чи якихось перепон відповідає Scrum-майстер. (Більше див. у розділі 4 «Час» та розділі 6 «Плануйте реальність, а не фантазію».)

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

Команда має демонструвати лише те, що відповідає визначенню готовності. Те, що цілком та повністю готове і може бути здане без жодної додаткової роботи. Це може бути не повністю завершений продукт, але точно повністю готова його характеристика. (Більше див. у розділі 4 «Час».)

10. Ретроспектива спринту. Спочатку члени команди показують, чого вони досягли протягом останнього спринту (що в них «Виконано» і може потенційно бути представлене клієнтам для відгуку). А потім вони сідають і думають, що пройшло добре, що могло пройти краще і що можна покращити в наступному спринті. Яке покращення робочого процесу вони як команда здатні запровадити просто зараз?

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

Наприкінці зустрічі команда та Scrum-майстер мають узгодити одне покращення процесу, яке вони впровадять у наступному спринті. Це покращення процесу, яке іноді називають кайдзен, слід внести в беклог наступного спринту разом із критеріями прийнятності. Так команда зможе легко бачити, чи дійсно вони впровадили покращення і який вплив це мало на швидкість. (Більше див. у розділі 7 «Щастя».)

11. Одразу починайте наступний спринт, ураховуючи досвід команди щодо перешкод та покращень процесу.

Подяки

Будь-який проект не є результатом роботи однієї людини. Це продукт команди, і ця книжка не виняток.

Перш за все, я б хотів подякувати моєму синові, Джей Джей Сазерленду. Саме він запропонував мені написали разом книжку про дійсно дивовижну подорож, у яку Scrum повів мене кілька років тому. Він хотів перепочити від десяти років біганини з однієї війни та катастрофи на іншу для Національного громадського радіо та вважав, що розповісти історію того, як Scrum виник, працює та змінює світ, буде не лише важливо, але й дуже цікаво. Хоча книга, яку ви тримаєте в руках, є моєю історією, це водночас продукт багатьох годин спільної праці, і на папір її переніс саме мій син.

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

Не так часто випадає можливість попрацювати зі справжнім майстром своєї справи, і мені надзвичайно пощастило з Ріком Горґаном із Crown Publishing Group. Завдяки його майстерності та ретельності будь-який текст одразу стає кращим. Він зробив його таким простим. Знімаю капелюха та щиро дякую.

Головний власник продукту Алекс Браун, Джо Джастіс та решта команди Scrum, Inc. ділилися зі мною важливими ідеями, своєю невичерпною енергією та величезним досвідом.

Я також хотів би подякувати:

Професорам Гіротаці Такеучі та Ікуджиро Нонаці, чия робота запалила ідею Scrum і які пізніше стали моїми добрими друзями.

Моєму товаришеві у створенні Scrum Кену Шваберу, чия сердита впертість допомогла сформувати цю систему та зробити її силою, якою вона є сьогодні.

Найбільша подяка моїй дружині Арлін. Вона була зі мною від самого початку і, як служителька унітаріанської універсалістської церкви, познайомила зі Scrum багатьох вірян. Вона зробила світ кращим, показавши нам, як задіяти Scrum по всій організації.

Під кінець я хочу подякувати сотням тисяч Scrum-майстрів, власників продукту