Змінитися або померти: біографія однієї методології ведення проектів.
На сьогодні Scrum вважається однією з найефективніших методологій управління проектами. Компанії, які зробили вибір на її користь, починають працювати набагато ефективніше – як стверджує Сазерленд, окремі команди підвищують свою продуктивність у 8 разів.
Передмова
Коли я починала читати цю книжку, я очікувала, що це буде “практичний посібник з упровадження Scrum” з безліччю сухої інформації, правил і варіантів розв’язання можливих проблем. Але книга не про те – це біографія методології Srum, про те, як вона з’явилася і як вона спрацювала в різних компаніях.
Звісно, про основні принципи, ролі учасників проєкту, щоденні мітинги буде розказано, але набагато важливіше, перш ніж впроваджувати щось у себе, розуміти історію, чому в Scrum сформувалися саме такі правила і принципи.
Іноді я бачу питання про деталі впровадження Scrum, наприклад:
А чи може власник продукту змінити набір завдань у спринті, якщо одне завдання стало непотрібним? А якщо когось з учасників команди немає – чи потрібно проводити мітинг?
Думаю, якщо ви прочитаєте цю книжку, то зрозумієте, що Scrum базується насамперед на здоровому глузді. Перед тим, як сліпо намагатися дотримуватися таких правил, як “більше ніяких змін після початку спринту”, зрозумійте, навіщо це правило існує.
А потім запитайте команду, чого вона більше хоче – зробити заплановане завдання у спринті, яке нікому не потрібне, бо ви дотримуєтесь правила “нічого не змінювати”, чи замінити завдання, але отримати на виході щось справді корисне? Думаю, відповідь очевидна.
Історія Scrum
Усе почалося задовго до маніфесту Agile. Як і багато чого в наш час, Agile маніфест і багато хто з методологій гнучкого розроблення з’явилися саме тоді, коли були потрібні, – коли багато проєктів, які велися за водоспадною моделлю, виходили з термінів і бюджету.
Розповідь про історію Scrum починається з далекого 1967 року, коли Джефф Сазерленд був льотчиком на службі у В’єтнамі й дотримувався правил “спостерігати, орієнтуватися, вирішувати, діяти”, які і сформували його майбутній підхід до роботи.
Подумайте самі – адже “спостерігати, орієнтуватися, вирішувати, діяти” – це і є Scrum. Ви спостерігаєте за реакцією замовника (чи зробили ви те, що було потрібно), орієнтуєтеся за ситуацією (дивитеся на список завдань), вирішуєте (формуєте беклог) і дієте (робите завдання).
Також у книзі є приклад із 1960 року, коли Сазерленд був кадетом останнього курсу військової академії США, і його призначили інструктувати роту, яка марширувала найгірше. Він став приклеювати на дошку стікери з невдачами й успіхами кадетів, щоб усі могли подивитися на свої дії з боку і виправити їх. Через кілька тижнів рота стала найкращою.
1983 року Сазерленда покликали керувати проєктом зі створення перших банківських терміналів, і, коли він прийшов туди, то усвідомив, що процеси в компанії настільки безнадійно зіпсовані, що простіше створити компанію всередині компанії та вибудувати все заново. Саме в цьому проєкті почали формуватися головні терміни Scrum – спринти, власник проєкту, беклог проєкту.
Перший справжній запуск Scrum було здійснено 1992 року в компанії Easel – саме тоді по-справжньому запрацювали спринти, і спочатку вони були щотижневими. Щоб зрозуміти, як зробити роботу команди кращою, Сазерленд зі співробітниками щодня дивилися ігри команди регбістів, які діяли настільки злагоджено, що мотивували їх постійно покращувати і свою роботу.
Сазерленда, як людину, що вміє підвищувати продуктивність компанії в короткі терміни до величезних цифр – від 400 до 800%, звали у величезну кількість безнадійних проєктів – як-от проєкт розроблення системи збирання й аналізу даних у ФБР, на яку витрачено мільйони доларів і, за їхнім зізнанням, яка змогла б уникнути трагедії 11 вересня, якби її було зроблено в той час.
Перше, з чого завжди починав Сазерленд – це зі слів про те, що діаграми Ганта, ніжно улюблені всіма менеджерами, не працюють. Якщо хтось не знає, то діаграма Ганта – це намальовані послідовні кроки виконання проєкту:
Проста діаграма Ганта
На початку проєкту ви все розпланували – у перші три місяці ви завершите аналітику, потім – розробку, потім – тестування і здачу проєкту. Насправді вимоги змінюватимуться в процесі розроблення, аналітику доведеться переписувати, відділ юристів, якого ви залучите наприкінці для затвердження якихось норм, не зможе виділити час на ваш проєкт, тому що не був у курсі того, що відбувається, а коли ви здасте продукт замовникові – виявиться, що він зовсім не це мав на увазі.
Якщо ви дивилися серіал “Дживс і Вустер”, там є знаменита фраза від Дживса – мені здається, вона підходить про діаграми Ганта:
Це всього лише моя думка, сер, але у вашому плані занадто багато непередбачуваного. Підприємство, для якого необхідна присутність чотирьох осіб в одному місці в один і той самий час, причому двоє з них не знають про це, приречене на провал.
Звісно, не всі компанії, які кликали Сазерленда, були насправді готові змінювати свій звичний уклад. Одна з таких компаній, BellSouth, працювала як годинник: вони збирали вимоги із замовника, працювали за водоспадною моделлю і точно в строк здавали проєкт.
Проблема була в тому, що в момент здачі проєкту замовник переставав хотіти той продукт, який описував на самому початку. Співробітники компанії не почули рекомендації змінити підхід на більш клієнтоорієнтований, отримали попередження “змінитеся – або помрете”, і не змінилися.
Хтось із вас чув назву BellSouth?
Висновок
Ми звикли думати, що всі гнучкі методології проєктів підходять тільки для IT-компаній. Але якщо подивитися трохи глибше, то вони підходять для багато чого іншого: для того, щоб одна з найгірших рот у Вест-Пойнті стала кращою, щоб спланувати весілля і ремонт будинку, щоб діти в одній з голландських шкіл підвищили успішність з хімії, щоб розробити звід законів однієї з країн і щоб підвищити рівень якості життя населення Уганди.
Прочитати книгу потрібно кожному, хто працює в IT-компанії або просто намагається навчитися краще організовувати свої справи. Навіть якщо ви не впровадите в себе нічого нового, ви зможете сказати, що ви справді розумієте, що Scrum – це не просто “мітинги щодня і ретро раз на тиждень”, а насамперед клієнтоорієнтована методологія, яка робить усе, щоб зробити саме те, що потрібно, не перевищивши бюджету і термінів.
А про основні терміни Scrum ви можете прочитати в книзі. Кожен розділ історією підводить до різних висновків, наприклад, чому мітинги не мають бути довшими за 15 хвилин, чому не вийде добре вести кілька проєктів одночасно, і чому командний гравець кращий, ніж геній-одинак. Наприкінці книжки є додаток “Впроваджуємо Scrum: з чого почати”, у якому є інструкції, тому не наводитиму його тут.
