Scrum чи не-Scrum - який
підхід обрати?

Як гартувався Scrum: походження та застосування методології

Scrum — це авторська гнучка методологія розробки з нестандартним розподілом ролей в команді і унікальною організацією ітерацій. Scrum, як і інші agile методи управління проектами, сповідує командний підхід, короткі ітерації і безперервне поліпшення в процесі роботи. Ці принципи реалізуються через набір особливих ролей, правил, процесів та інструментів, завдяки яким команди виробляють продукт вдвічі швидше.

У скрам-командах ключові позиції займають
scrum-master і product owner,
ітерація починається плануванням,
на якому члени команди ​“грають”
в покер планування,
і завершується демо з ретроспективою.

Scrum методологія створена американцями Джеффом Сазерлендом, дослідником і бізнес-консультантом, і Кеном Швабером, практикуючим програмістом, в 1993 році. У 1995 році автори концепції офіційно представили її підходи на науковій конференції Асоціації обчислювальної техніки в Остіні, Техас.

Ідея співавторів Скраму була новою: і концепцію, і навіть назву вони перейняли з роботи японських дослідників в сфері управління Такеучі і Нонака ​“Розробка нового продукту. Нові правила гри “, опублікованій в 1986 році. Уже тоді японські виробники використовували підходи, які лягли в основу Скрам. А назва методології запозичена із словника гравців в регбі. Scrum, або сутичка, — елемент гри, який показує важливість командної роботи для перемоги на полі.

Застосування Скраму в IT і не тільки

Вперше Scrum був застосований в компаніях, які виробляють програмне забезпечення. Перший проект, яким керував Дж.Сазерленд ще до офіційної презентації скраму, — створення ПО для мережі банкоматів (1983 р.). Команди програмістів в IT компаніях і підрозділах досі залишаються головними споживачами Scrum. Однак автор методології наполягає, що скрам застосовується для вирішення будь-яких завдань, і наводить приклади використання скраму у виробництві, будівництві, освіті, політиці і навіть при вирішенні побутових завдань, на кшталт генерального прибирання або організації свята. 

І дійсно, за даними звіту Scrum Alliance за 2016 рік 21% проектів, виконаних за скрамом, не мали відношення до сфери IT. Подивіться, які підрозділи успішно використовують scrum:

Scrum VS Agile VS Waterfall

Скрам відноситься до групи гнучких методологій, або agile методологій. Agile — це не окрема методологія, а ціла філософія розробки ПО, її основні підходи зафіксовані в Manifesto for Agile Software Development в 2001 році . У маніфесті перераховані основні принципи agile — значимість команди, акцент на продукт, а не на документацію, прозорість процесів, постійне вдосконалення, швидкий результат.

Скрам — це один з фреймворків agile, формалізована методологія роботи над проектами. До аджайл методологій, крім скраму, відносяться й інші сучасні підходи. Альтернативою scrum можуть бути XP , Kanban , Lean , Crystal , Rapid application development , Scrumban і інші. Тобто скрам — це agile, але agile — не тільки скрам.

Уявіть, що agile — це християнство, а scrum — одне з його течій, наприклад, протестантизм. І хоча християни в цілому і протестанти зокрема сповідують одні й ті ж принципи, протестанти мають свої унікальні ритуали для прояву віри.

Відповідно, візуально відмінності і подібності між Scrum і Agile можна змалювати таку картину: 

* Артефакти в скрамі — це об’єкти, які створюються командою під час роботи над проектом. До них відносяться беклог продукту, беклог спринту та інкремент продукту, тобто працює шматок функціоналу, який команда демонструє в кінці спринту.

Гнучкі методики розробки протистоять каскадній моделі (каскад, водоспад, waterfall), якою в 90‑і роки користувалися практично всі команди розробників.

Суть каскадної моделі — поетапне виконання проекту, причому робота над кожним наступним етапом починається тільки після закінчення попереднього. Схематично каскадна модель виглядає так:

Але каскадний методологічний підхід не працював — команди провалювали терміни і вивалювалися з бюджету. Метод водоспаду не брав до уваги проблеми, що виникають, затримки і збої, мінливі вимоги замовника та навколишнього середовища. Потрібно було шукати альтернативу і міняти процес роботи — регулярно оглядатися назад, аналізувати виконану роботу і тут же усувати перешкоди і вносити зміни. Тому з’явилися гнучкі методології agile та її похідні .

Як працювати згідно скраму

Ролі в скрамі:

Скрам-команда

В основі скраму лежить команда або група — злагоджений організм професіоналів. Скрам-команди автономні, учасники самі вирішують, як виконувати задачі. Вони багатофункціональні — знань і навичок членів команди вистачає для вирішення задач.

Для скраму потрібна невелика команда: 7 ± 2 осіб. При більшій кількості людей учасники команди витрачають занадто багато ресурсів на комунікації. В середині 90‑х років Лоуренс Путнем проаналізував 491 команду розробників: всі вони створювали новий продукт і були різних розмірів. Дослідження показало, що великим командам (9−20 чоловік) потрібно в 4 рази більше часу і зусиль, щоб вирішити задачу, ніж нечисленним групам (3−7 чоловік).

Скрам-майстер

Власник продукту, Product Owner

Власник продукту — людина, яка відповідає за функціональність кінцевого продукту. Він складає список призначених для користувача історій (беклог проекту), і веде його по ходу проекту. Його зона відповідальності — що робити в рамках проекту і зв’язок із замовником.

Замовник

Замовник або клієнт — той, для кого робиться проект. Замовником може бути стороння особа або організація, або інсайдер. Наприклад, відділ продажу, який замовив девелоперам розробити CRM систему.

Регулярні скрам-збори і Worksection

Планування

Перші збори, які починає спринт. На ньому команда за допомогою скрам-майстра і власника продукту вибирають задачі з верхньої частини беклога, які вони встигнуть виконати.

Лише вибрані задачі вносяться в проект-спринт з дедлайном і виконавцем.

Щоденні збори на ходу

Всі учасники команди кожен день в один і той же час збираються, щоб оцінити хід роботи і обмінятися інформацією.

Для цього вони відповідають на три питання: 

1. що я робив вчора, щоб команда досягла мети?
2. що я буду робити сьогодні, щоб команда досягла мети?
3. що заважало мені виконувати роботу?

Збори тривають не довше 15 хвилин і проводяться стоячи.

Для цієї зустрічі кожен може подивитися свій Звіт за обраний день.

Демонстрація або огляд спринту

Проводиться, коли робота зі спринтом завершена. Це демонстрація замовнику і всім зацікавленим особам функціоналу, який команда створила за спринт. На цьому етапі замовник висловлює свою думку, вносить корективи, робить запит про додатковий функціонал і т.д.

Використовуються Звіти за відповідний проміжок часу, ​“клієнтський доступ” до проектів (видно прогрес, проте не видно внутрішню кухню), коментарі та емоції.

Ретроспектива

Це зібрання, на якому команда обговорює виконані за спринт задачі, ступінь їх виконання , проблеми, які потрібно вирішити. Співвідношення запланованих і виконаних задач визначає ефективність команди. На ретроспективі шукають способи вдосконалення.

Використовуються Звіти за відповідний проміжок часу по Людям, Відділам, Рахунки і Детальний.

Алгоритм. Що за чим робити?

1. Виберіть власника продукту, який чітко визначить, що має бути зроблено.

2. Сформуйте скрам-команду.

3. Призначте скрам-майстра.

4. Створіть беклог проекту у вигляді списку призначених для користувача історій. Включіть в нього всі задачі, які команда могла б зробити для проекту, і розставте їх по пріоритету. Уперед винесіть задачі, в яких міститься основна функціональність проекту і які принесуть дохід замовнику.

Беклог — це повний список робіт, які потрібно виконати.
Користувальницькі історії, User stories — це вимоги до функціональності продукту, озвучені від імені кінцевого споживача. Наприклад, я, як покупець інтернет-магазину, хочу шукати потрібний товар на сайті (оплачувати покупки карткою, зберігати товари в кошик і т.д.).

5. Оцініть задачі з беклога, використовуючи відносні величини, наприклад, розміри футболок або числа з послідовності Фібоначчі: 0, 1, 1, 2, 3, 5, 8, 13 і т.д. Оцінюйте задачі всією командою за допомогою покеру планування (planning poker): використовуйте колоду карт або додаток на смартфон.

Покер планування — спеціальна колода карт з числами Фібоначчі. Кожен член команди отримує свій комплект. Коли скрам-майстер озвучує задачу, члени команди одночасно кладуть на стіл карти з числами, які, на їхню думку, відповідають складності задачі. Якщо карти учасників розходяться на одну-дві одиниці, наприклад, 3 і 8, то задачі присвоюється складність, яка дорівнює середньому арифметичному цих чисел. Якщо розбіжність більше, то учасники, які викинули найменшу і найбільшу карти, пояснюють свої рішення. Після цього всі члени команди викладають карти заново. І так, поки всі не дійдуть згоди.

6. Проведіть планування спринту: виберіть задачі і розподіліть їх між виконавцями.

7. Заведіть скрам-дошку, поділіть її на три частини: потрібно зробити, в роботі, зроблено. Переміщайте стікери із задачами, щоб бачити динаміку роботи. Використовуйте реальну або віртуальну дошку.

8. Не забувайте про щоденні збори.

9. В кінці спринту проведіть демонстрацію.

10. Зберіться на ретроспективу, обговоріть, як поліпшити роботу, які перешкоди усунути. Це може бути непрацююча кавоварка, комп’ютер, що гальмує, некомфортна температура повітря, запальність колеги, недобросовісний підрядник. Коли команда починає працювати по скраму, вирішуються проблеми, які місяцями відкладалися в довгий ящик.

11. Починайте наступний спринт з планування (пункт 6).

Що почитати, щоб краще розібратися в скрамі

Скрам Гайд. Вичерпне керівництво по скраму: Правила гри.

(Кен Швабер, Джефф Сазерленд)

Керівництво по застосуванню скрама: описує ролі, заходи, артефакти скрам, і правила їх використання. Гайд складений і підтримується співавторами скрам-методології.

Скрам. Революційний метод управління проектами

(Джефф Сазерленд)

Бестселер співавтора scrum розкриває історію створення та основні принципи методики. Автор наводить приголомшливі приклади скраму в дії. Читати обов’язково, щоб загорітись тут же впровадити скрам в роботу і життя.

Управління продуктом в Scrum. Agile-методи для вашого бізнесу

(Роман Піхлер)

Істотна частина книги присвячена власнику продукту: його функціям, якостям, помилкам. Автор докладно розглядає процес створення продукту по скрам-методології, починаючи продумуванням концепції майбутнього продукту і закінчуючи створенням звітів.

Scrum і XP: нотатки з передової 

(Хенрік Кніберг)

Книга-кейс про практичне застосування сучасних підходів agile — скрам і екстремального програмування — в конкретній команді. Безліч прикладів, інструментів, скрам-методів в дії, без води і теорії.

Agile-маніфест розробки програмного забезпечення

Складається з декількох рядків, в яких закладені основні принципи розробки по гнучкими методологіями.

Переваги та недоліки Scrum в ІТ

Скрам — відмінна методологія: високоефективна, прозора, мотивуюча. Це win-win підхід, від якого виграє і команда, і замовник.

1. Прозорість. У команді відкритий обмін інформацією, знаннями, проблемами, кожен відчуває себе причетним до спільної мети. Замовник завжди в курсі процесу робіт, вносить правки, отримує достовірну інформацію про терміни здачі.
2. Автономність команд. Члени команди самі вирішують, як працювати над проектом, свобода дій і відповідальність мотивують. Замовник передає вимоги команді безпосередньо, без зіпсованого телефону.
3. Мотивація результатом. Концепція скрам дозволяє кожному члену групи бачити свої і загальні досягнення щодня. Замовник отримує приріст функціональності з кожною итерацією.
4. Мінімізація ринкових ризиків. Команда оперативно реагує на зміну вимог до проекту і не робить зайву роботу. Замовник отримує те, що хоче, і що затребуване на ринку.
5. Мінімізація фінансових ризиків. На усунення багів і додавання функціоналу витрачається мало часу і коштів, все вкладаються в бюджет.

Але скрам — формалізована методологія, і для деяких проектів застосовувати її НЕ так просто.

Ось явні недоліки скраму:

• не підходить для проектів з туманними вимогами до кінцевого продукту, тому що замовник може нарощувати функціонал до нескінченності;
• складно навчитися правильно розставляти пріоритети і оцінювати задачі;
• успіх проекту занадто залежить від скрам-майстра;
• скрам складно використовувати в великих проектах, доводиться масштабувати методологію і вводити збори ​“scrum of scrums”. У таких мітингах беруть участь представники кількох скрам-команд, що працює над пов’язаними продуктами.

В нашому проекті відразу намагалися практикувати дворівневий скрам: глобальний і на рівні підрозділів (sales, маркетинг, фінанси і т.д.). Спочатку керівники відділів визначали задачі на глобальному плануванні, потім вони спускалися на рівень відділу. У нас виходило погано — кінцевий результат був занадто розмитий.

• високоефективні команди розслабляються і перестають удосконалюватися. Індикатор наявності проблеми — зниження динаміки продуктивності спринтів. Скрам-майстер повинен донести серйозність проблеми до команди. Якщо команда не виходить із глухого кута самостійно, втручається керівництво: наймаються нові співробітники, проводиться ротація кадрів. 

Scrum-компанії

За даними звіту Scrumalliance 70% IT-компаній використовують скрам. Серед них такі гіганти як Google, Amazon, Salesforce​.com, Microsoft, Adobe.

Salesforce​.com

Американська компанія , провідний розробник CRM систем для бізнесу. Її продуктами користується 150 тис. Компаній. Багато років використовує гнучкі методологічні підходи на чолі зі скрамом, створивши на його основі унікальний гібрид з декількох фреймворків agile.

Amazon

Застосовує гнучкі методики з 1999 року, і до 2004 року кілька команд розробників вже використовували скрам. До 2009 більшу частину розробників цілеспрямовано перевели на скрам.

Spotify

Цифровий музичний сервіс, який успішно конкурує з гігантами Google, Apple і Amazon. Своєю конкурентною перевагою Spotify вважає максимальне використання можливостей скрам. Керівництво компанії наймає найкращих скрам-коучів на роль скрам-майстрів. Робота ведеться маленькими автономними командами, до яких відносяться як до стартапів.

Microsoft

Застосовує скрам з 2008 р, 4 тис. розробників в сотнях команд по 10 – 12 осіб працюють за методологією скрам, випускаючи новий продукт кожні три тижні. Корпорації вдалося успішно масштабувати скрам під свої розміри.

Цікаві Scrum-проекти

eduScrum

Те, що скрам використовується не тільки в IT сфері, демонструє проект eduScrum  — ініціатива вчителя хімії в школі нідерландського містечка Алфен-ан-ден-Рейн. За підтримки ділової спільноти в Голландії був створений фонд eduScrum, який навчає вчителів використовувати скрам на уроках. Школярі, що працюють в скрам-командах, вчаться краще і з більшим задоволенням, ніж однолітки.

Проект «Страж» для ФБР

Впровадження скрам-методології врятувало від краху багатомільйонний проект американського уряду — єдину базу даних «Страж» для ФБР. «Страж» був другою спробою розробити єдину інформаційну систему для ФБР. Перша провалилася, не пропрацювавши і дня.

«Страж» почав створюватися в 2005 році згідно каскадної моделі. На проект було виділено 4 роки і 450 млн дол. На початку п’ятого року компанія-підрядник виконала половину робіт і витратила 95% бюджету. За оцінками експертів їй би треба було ще 350 млн. І 6 – 8 років для завершення проекту.

Коли на початку 2010 року каскадну модель змінила робота в скрам-командах, продуктивність розробників збільшилася втричі, і 2 липня 2012 року «Стражем» користувалися співробітники ФБР у всіх штатах.

Програми

Робота над скрам-проектами ведеться в спеціальних додатках і програмах. Багатофункціональний інтерфейс дозволяє стежити за ходом роботи по проекту з різних ракурсів.

Worksection

Простий інтуїтивно зрозумілий сервіс для роботи над проектами та вирішення різних завдань бізнесу.

Worksection зараз допрацьовує і тестує перед впровадженням (на жовтень 2017) фішки для scrum: діаграми згоряння задач та беклог — чисто ​“скрамовські” інструменти. Можливо буде і покер планування. Наш консультант в цій справі, Віталій Цимбалюк , надає перевагу своїй колоді для скрам-покеру — з Бетменом.

Вже зараз в Worksection можна:

• Вести задачі та підзадачі в проектах, контролювати динаміку їх виконання. 
• Вносити витрачений час і гроші, спостерігати витрати щодо запланованих до бюджету прямо в системі.
• Беклог продукту і беклоги спринтів створювати як окремі проекти, між якими можна переміщати задачі.
• Учасники команди спілкуються по задачам прямо в Worksection —  вся інформація, зауваження і прогрес наглядні. Є коментарі та емоції, мітки, пріоритети і статуси задач.
• Плюс кілька форматів звітності — за термінами, за навантаженням і людьми, за типовими проектами, по грошах, — дозволяє зробити якісну ретроспективу.
• Бути постійно на зв’язку з командою, завдяки мобільній версії.

Scrumdo

Чисто ​“скрамовский” сервіс з плануванням ітерацій, покером, картками завдань. В іншому стандартний пакет функцій зі звітами, діаграмами і гістограмами.

Вердикт

Scrum — це комбінація філософії agile підходів до управління проектами та унікальних ролей і процесів, які можна транслювати на будь-яку сферу діяльності.

Скрам можна спрощувати або ускладнювати, комбінувати з іншими підходами і масштабувати, адаптувати під потреби бізнесу. У різних командах не знайти ідентичного скраму.

Саме команда визначає успіх скраму — він просто не буде працювати там, де люди не хочуть стати кращими. Мотивація вже закладена всередину скраму, а за підтримки керівництва скрам-команди збільшують продуктивність в кілька разів.

Скрам одночасно простий і складний, потрібно бути готовим, що вийде не відразу. Головне — не зупинятися, пробувати знову, вчитися по книгах або проходити тренінги, використовувати додатки, щоб стежити за ходом роботи і ефективністю команди.

Книги для статті надані kniga​.biz​.ua