Цитаты из книги «Scrum. Навчись робити вдвічі більше за менший час»

Найбільше Демінг відомий якраз своїм методом дій — циклом ПРПД (Планувати, Робити, Перевіряти, Діяти). Цей цикл можна застосувати до виробництва практично всього: автомобіля, відеогри чи навіть паперового літачка.

Планувати, Робити, Перевіряти, Діяти

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

10. Ретроспектива спринту. Спочатку члени команди показують, чого вони досягли протягом останнього спринту (що в них «Виконано» і може потенційно бути представлене клієнтам для відгуку). А потім вони сідають і думають, що пройшло добре, що могло пройти краще і що можна покращити в наступному спринті. Яке покращення робочого процесу вони як команда здатні запровадити просто зараз? Щоб бути ефективною, ця зустріч потребує певної емоційної зрілості та атмосфери довіри. Головне — пам’ятати, що ви не шукаєте когось винного, а розглядаєте можливі недоліки процесу. Чому це сталося саме так? Чому ми це пропустили? Що може зробити нас швидшими? Дуже важливо, щоб люди брали на себе відповідальність за свою роботу і її результати як команда та шукали рішення як команда. Водночас люди повинні мати мужність порушувати питання, які дійсно їх турбують, орієнтуючись на пошук рішення, а не звинувачення. А решта команди повинна мати зрілість слухати відгуки, сприймати їх та шукати розв’язання, а не займати оборонну позицію. Наприкінці зустрічі команда та Scrum-майстер мають узгодити одне покращення процесу, яке вони впровадять у наступному спринті. Це покращення процесу, яке іноді називають кайдзен, слід внести в беклог наступного спринту разом із критеріями прийнятності. Так команда зможе легко бачити, чи дійсно вони впровадили покращення і який вплив це мало на швидкість. (Більше див. у розділі 7 «Щастя».)

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

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

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

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

5. Удоскональте та оцініть беклог продукту. Важливо, щоб люди, які насправді виконуватимуть завдання із цього переліку, оцінювали, скільки зусиль їм на це знадобиться. Команда має дивитись на кожен пункт переліку завдань і бачити, чи дійсно його можна виконати. Чи достатньо для цього інформації? Чи не надто великий обсяг робіт для оцінки? Чи є визначення готовності — загальноприйняті стандарти, яких слід дотриматися, щоб перевести завдання в колонку «Виконано»? Чи створює це видиму цінність? Кожний пункт має бути готовим для показу, демонстрації, в ідеалі — потенційно готовим до передачі клієнтові. Не оцінюйте завдання в годинах, бо люди абсолютно не вміють цього робити. Оцінюйте за порівняльним розміром: малі, середні чи великі. Або, навіть краще, використовуйте послідовність Фібоначчі та оцінюйте кожний пункт у балах: 1, 2, 3, 5, 8, 13, 21 тощо. (Більше див. у розділі 6 «Плануйте реальність, а не фантазію».)

4. Складіть беклог продукту та розставте пріоритети. Це перелік усього, що потрібно створити чи виконати для перетворення бачення на реальність. Беклог існує та розвивається протягом усього життєвого циклу продукту — це його дорожня мапа. У будь-який момент часу беклог продукту є єдиним кінцевим орієнтиром «всього, що колись може зробити команда, у порядку пріоритетності». Існує лише один беклог продукту. Це означає, що власник продукту повинен приймати рішення щодо розставлення пріоритетів по всьому спектру. Власник продукту має консультуватися з усіма зацікавленими особами та командою, щоб чітко відображувати, що люди хочуть і що можна створити. (Більше див. у розділі 8 «Пріоритети».)