3️SCRUM
Що таке Scrum?
Scrum – це методика гнучкого управління проектами, що допомагає командам структурувати роботу та керувати нею на основі набору цінностей, принципів та практик. Як спортивна команда готується до вирішальної гри (до речі, scrum — англ. «битва», елемент гри в регбі), так і команда співробітників компанії повинна отримувати уроки з набутого досвіду, освоювати принципи самоорганізації, працюючи над вирішенням проблеми, та аналізувати свої успіхи та провали, щоб постійно вдосконалюватись. Scrum сприяє цьому.
Методику Scrum найчастіше застосовують команди розробників додатків, але принципи та досвід її використання можна застосувати до командної роботи будь-якого роду. Це одна із причин такої популярності методики. Scrum часто представляють як платформу для управління проектами за методикою Agile. Учасники команди Scrum проводять збори, використовують спеціальні інструменти та беруть на себе особливі ролі, щоб організувати роботу та керувати нею.
Особливості Scrum
Отже, 4 особливості Скрам як методології:
робота над проектом розбивається на невеликі підзадачі;
команда з 5-7 осіб виконує кожну з них у фіксований термін (1-4 тижні);
протягом роботи над одним підзавданням проводиться 5 типів нарад;
отриманий результат роботи над кожним підзавданням має цінність для замовника.
Тепер докладніше про кожну з особливостей:
Sprint (Cпринт) — головна фішка SCRUM. Саме так називається кожне невелике підзавдання, з яких складається проект. Всі спринти повинні бути однаковими за тривалістю, найчастіше довжина одного — два тижні, рідше за місяць. А скільки саме, залежить від особливостей вашого проекту. Зазвичай, чим складніше завдання, тим спринт коротший, щоб швидше зрозуміти, скільки реально часу потрібно для досягнення більш масштабної мети, та не витрачати час розробці на те, що може не знадобитися.
Загалом спринт — це про конкретні задачі. Бракувало якоїсь функції? Додали. Щось не працювало? Полагодили. Завдяки йому зручно організовувати роботу та ще зручніше стежити за прогресом проекту загалом.
Артефакти. Красивим словом «Артефакти» в Scrum називають речі, що створюються під час розробки:
Беклог продукту (Product Backlog) — зона відповідальності власника продукту. Це список завдань або, як його називає Вікіпедія, "журнал побажань до проекту". Беклог — це не щось, що затвердили раз і назавжди, а гнучкий перелік функцій, покращень, виправлень тощо. У ньому вказуються актуальні задачі для команди та зазначаються ті, що вже виконані.
Беклог спринту (Sprint Backlog). Ще один беклог, але менший і конкретніший. Це список завдань на конкретний спринт, який формується на мітингу щодо його планування. Він теж може змінюватися, якщо команда зіткнулася зі складнощами, і потрібно зробити щось ще, крім того, що запланували. Але його мета, вона мета спринту, залишається незмінною.
Інкременти. Це саме той, отриманий результат роботи над кожним підзавданням, що має цінність для замовника. Інкрементом він називається тому, що його вже можна так чи інакше додати до решти проекту та подивитися, як він працює. Це не обов'язково має бути ціла нова функція, цілком можливо й удосконалення тієї, що вже є, або взагалі виправлення помилки. Але обов'язково те, що команда мала зробити протягом спринту. Загалом це очікуваний (найчастіше) результат, який показують власнику продукту, щоб він бачив, як йде робота над його проектом.
Наради
Scrum — штука циклічна, і цей цикл складається з повторення різних нарад, вони ж мітинги:
Project/Product backlog meeting. Власник продукту приходить на першу таку нараду з найголовнішим артефактом проекту — підготовленим списком завдань, які потрібно вирішити для запуску. Беклог — це сучасна версія технічного завдання, в якій можна й потрібно міняти будь-що, якщо щось змінилося на ринку або в уподобаннях користувачів. У ньому зібрані та відсортовані за пріоритетом усі робочі завдання (Story, Bug, Task та інше) та в нього ж вноситься інформація про хід виконання робіт: зробили завдання — поставили галочку. На цьому мітингу всі просто ознайомлюються з тим, над чим вони мають працювати в цілому, а ось на наступному починають обговорювати.
Sprint Planning. Планування самого спринту — обговорення найпріоритетнішого завдання командою та скрам-майстром. На цьому етапі вибираються історії з беклог, які потрібно зробити для виконання мети спринту. Наприкінці цієї наради всі учасники команди повинні чітко розуміти, що їм слід робити.
Daily Standup Meeting. Щодня всі учасники команди збираються в один і той же вибраний час, щоб розповісти, як у них справи. Із задачами за проектом. Кожен у двох реченнях описує, що він зробив учора та що робитиме сьогодні, а якщо зіткнувся з труднощами, то ще й про них — як вирішив чи як збирається вирішувати. Назва стендап буквально означає, що, якщо справа відбувається в офісі, то розробникам рекомендується спілкуватися стоячи. Щоб нікому не хотілося балакати довше, ніж треба. В умовах віддаленої роботи щоденні мітинги теж не затягуються — докладні обговорення проблем або ідей, що виникли, виносяться на окремі дзвони між зацікавленими учасниками, а решта відзвітували й пішли займатися своїми справами. Тому що Скрам — це про ефективність!
Sprint Review. Наприкінці спринту, коли все готово, інкремент показують власнику продукту, а також усім, кому це цікаво, якщо досвід може бути корисним колегам. Якщо все добре, то інкремент випускають на прод, а в беклог вносяться відповідні зміни. Дуже часто цей етап плавно перетікає до першого з наступного спринту.
Sprint Retrospective. Зустріч команди для обговорення робочих і супутніх моментів. Скрам-майстер проводить аналітику спринту, всі діляться думкою про те, як він пройшов, а також про учасників команди — хто молодець, а хто не дуже, а потім обговорюють, як працювати краще.
Діючі особи
У класичному Scrum існує 3 базові ролі:
Product owner (PO). Це ви як власник продукту, а найчастіше хтось із ваших співробітників, кого ви зробите відповідальним за спілкування з командою розробки. Та людина, яка створюватиме беклог проекту та доповнюватиме його, слухатиме наприкінці спринту, що ж там ця команда розробки зробила, а що ні, і що робитиме далі. PO не обов'язково повинен розумітися на технологіях розробки, але мусить бути спеціалістом у своїй галузі. Його робота — точно знати, що має робити готовий проект і кожна його частина, а також вникати в те, як розробляється.
Scrum master (SM). Скрам-майстер — проджект-менеджер на максималках. Його робота, з одного боку, допомагатиме продукт оунеру розібратися в нюансах роботи зі Скрам, а з іншого — організовувати роботу команди. Він відповідає і за пошук кадрів для команди, і за те, щоб у них були матеріально-технічні ресурси, і загалом за те, щоб усі товаришували та ефективно працювали. Планування та проведення всіх мітингів у спринті — теж робота SM.
Development team (DT). Команда розробників — +/- 5 спеціалістів, які займатимуться роботою над проектом. The Scrum Guide вимагає від них не тільки навичок для виконання завдань, але ще й бути спроможними самостійно організовувати робочі процеси, а також нести колективну відповідальність за досягнення мети спринту. Команд цих може бути будь-яка потрібна вашому проекту кількість, але вони повинні складатися з фахівців у певних технологіях і бути невеликими, щоб уникнути проблем із комунікацією. А комунікувати потрібно буде багато, інакше як навчитися самоорганізовуватися, працювати разом, брати відповідальність, аналізувати успіхи та невдачі та робити інші речі, що постулюються методологією Скрам? Загалом, для роботи в командах Scrum мало бути хорошим технічним фахівцем, потрібні ще й soft skills вищі за середні.
Last updated