home | login | register | DMCA | contacts | help | donate |      

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я


my bookshelf | genres | recommend | rating of books | rating of authors | reviews | new | форум | collections | читалки | авторам | add

реклама - advertisement



Додаток. Впровадження Scrum – із чого почати

Тепер, коли ви прочитали цю книжку, я розповім, як почати за допомогою Scrum будь-який проект, у двох словах. Наведений опис процесу доволі загальний, але для початку вам має бути цілком досить. Цю книжку було написано, щоб пояснити, чому з’явився Scrum. А додаток у скороченій формі розповість вам, як він працює.

1. Доберіть власника продукту. Це людина, яка володітиме баченням того, що ви збираєтесь зробити чи створити, чого досягти. Вона враховуватиме можливі ризики та винагороди, що можна виконати і до чого є пристрасть. (Більше див. у розділі 8 «Пріоритети».)

2. Доберіть команду. Це люди, які насправді виконуватимуть роботу. Команді потрібно мати всі вміння та навички, необхідні для того, щоб узяти бачення власника продукту й перетворити його на реальність. Команди мають бути невеликими: золоте правило – від 3 до 9 людей. (Більше див. у розділі 3 «Команди».)

3. Доберіть Scrum-майстра. Ця людина навчатиме решту команди принципів Scrum та допомагатиме їм позбуватися всього, що їх затримує. (Більше див. у розділі 5 «Марнування – це злочин».)

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

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

6. Проведіть планування спринту. Це перша зі Scrum-зустрічей. Команда, 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. Навчись робити вдвічі більше за менший час | Подяки