Для початку. Scrum та Agile - у чому різниця? Якщо коротко, Agile – це філософія, сімейство гнучких підходів до розробки програмного забезпечення. Scrum – один із таких підходів. У нього є братик – Kanban. Він також підхід, що використовується в Agile.

Олена Трусковарозповідає:

Цього тижня я пройшла дводенний тренінг з Agile/Scrum (вимовляється «еджайл» та «скрам»). За гнучкими методологіями розробки програмного забезпечення написано багато хитромудрої і не дуже літератури, багато що я читала. Але тільки після дводенного занурення у тему в мене нарешті зібралося базове розуміння предмета, з якого я пишу цю нотатку.

Еджайл та скрам допомагають організувати процес роботи в команді так, щоб випускати цікавий користувачеві продукт регулярно та часто.

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

Принципи скраму можна застосувати до всього: наприклад, до роботи над творчим продуктом. Це, звичайно, не «канонічний еджайл», скрам-євангелісти скреготітимуть зубами, зате ваші процеси рухатимуться бадьоріше. Шашечки чи їхати?

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

Еджайл

(англ. agile - «швидкий, спритний, кмітливий»)

Гнучкість концепції:

Підставте свій вид діяльності замість слова "розробка" – і ці принципи стануть близькими та зрозумілими.

«Працюючий продукт - основний показник прогресу», «простота як мистецтво мінімізації зайвої роботи» і «люди та взаємодія важливіші за процеси та інструменти» - правда, звучить розумно?

Скрам

(англ. scrum - штовханина у боротьбі за м'ячик у регбі)

Тут варто нагадати, що це моя особиста та суб'єктивна думка на скрам. Тут я міркую про застосування елементів скраму як у творчих проектах, далеких від IT, так і в індивідуальній роботі (скажімо, над блогом). Багато точних деталей для цього доведеться прогаяти; я намагаюся зберегти простоту тексту та не перегодувати читача термінологією.

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

Зазвичай скрам відбувається там, де є якийсь продукт, що має цінність для користувачів та замовників, і потрібно якнайшвидше на шляху до мети розуміти, чи в тому напрямку ми зараз біжимо - чи треба коригувати курс. Формат скраму дозволяє випускати чергову версію частіше, регулярно отримувати зворотний зв'язок та швидко доопрацьовувати продукт, а також покращувати процес роботи.

Якщо ви працюєте в команді, скрам наказує всім учасникам процесу прагнути до взаємозамінності, до здатності «підхопити» завдання, якщо сусід захворів, до обміну навичками та колективної відповідальності за продукт. Індивідуалізму у скрамі мало. Рішення приймаються колективно (за суворими принципами), ніхто не може натиснути та змусити вибрати інше рішення, якщо команда впевнена, що зупинилася на правильному.

Мати таку впевненість у скрамі не страшно, оскільки кожен марш-кидок триває рівно один спринт (чіткий відрізок часу, зазвичай, від одного до чотирьох тижнів). Після того, як спринт закінчився, настає момент аналізу: а як ми його пройшли? Що можна було б зробити ще краще наступного разу?

Тому навіть якщо ми всі впевнено побігли в неправильному напрямку, у нас буде наприкінці спринту можливість його скоригувати і полагодити те, що нас спрямовує не туди. Команда в скрамі самоорганізується і самоналаштовується.

Команда в скрамі

Стандартний розмір скрам-команди - 7 плюс-мінус 2 особи. Тобто, від п'яти до дев'яти. Буває скрам-масштабування: можна з 25 команд створити систему роботи над гігантським завданням. Але основна одиниця скраму – команда.

У кожній команді є:

• учасники (у разі IT – розробники, хто ці сім осіб у вас – вирішите самі)
• продукт оунер (product owner, власник продукту). Його роль: розуміти ринок і користувача, формулювати завдання мовою бізнесу та користувачів, пам'ятати усвідомлення того, в якому напрямку повинні розвиватися цінність і користь, вигадувати і відбирати завдання для розвитку продукту. Щось на кшталт керівника продукту (не команди).
• скрам майстер (scrum master, скрам-євангеліст). Його роль: стежити за процесом, спостерігати за внутрішнім життям команди, мотивувати людей, усувати перешкоди. Щось на кшталт тренера.
  Навколо команди є користувачі та стейк-холери (stakeholders, замовники). До цих людей продакт оунер ходить радитись.

Пристрій спринт

Робота в скрамі складається зі спринтів. Усі спринти влаштовані однаково. Передбачається, що з кожним наступним спринтом команда стає все зігранішою та ефективнішою. У скрамі вчишся на своїх помилках, але швидко – кожен спринт аналізуєш, що саме накоїв і як хочеш це виправити.

Продакт оунера має список ідей від бізнесу для ощасливлення користувачів. Він називається "продакт беклог" (product backlog, список продуктових ідей). У ньому ідеї відсортовані за важливістю та значущістю.

У кожному спринті є спринт белог (sprint backlog, список завдань на спринт) - відсортований список ідей, які команда вирішила зробити за найближчий спринт. Сенс скраму в тому, що команда сама оцінює складність кожного завдання та вирішує, які завдання увійдуть до чергового спринту.

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

На початку свого життя команда завжди погано планує. Це є об'єктивна реальність. Але вона веде статистику того, що їй вдається зробити за спринт, і згодом планує дедалі точніше. Їй допомагає підсумкова зустріч спринту – ретроспектива. На ній можна обговорити слабкі моменти спринту, що йде, і придумати способи робити по-іншому.

Зазвичай у спринт влазить 5 плюс-мінус 2 ідеї. Якщо ідеї надто великі, команда їх дробить так, щоб у кожному спринті можна було щось маленьке, та показати.

У скрамі ідеї називаються користувач-сториз (user stories, історії про користувачів) і формулюються так: «Я як (роль?) хочу (що?) для того, щоб (навіщо?)». Таким чином, команда бачить не тільки функціональність, але й сенс її створення, причому для конкретної ролі: користувач, замовник, покупець.

Результатом спринту є щось, що можна показати. Показує роботу команда на демо наприкінці спринту.

На мій погляд, скрам-процес схожий на роботу над колективним блогом. Такий процес допоміг би дотриматися регулярності, звести докупи експертизу авторів і не набирати стільки, що не встигнеш зробити.

Структура спринту

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

Щодня є стендап-мітинг (stand up meeting, нарада стоячи) на 15 хвилин. Робити його стоячи важливо: якщо хтось забовтається, решта красномовно переминатиметься з ноги на ногу і чухатиме вухо. Можна використовувати якийсь предмет, щоб говорив одночасно один учасник, і передавати його по колу.

Кожен учасник стендапу по черзі відповідає на три запитання:

• що я зробив учора
• що я зроблю сьогодні
• що мене гальмує

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

Взагалі підтримкою всіх цих чітких правил поведінки повинен займатися скрам-майстер. Це зазвичай ідеологи технології, які вірять у неї та готові вибудовувати процес для максимальної ефективності проведеного разом часу. Без скрам-майстра процеси виродяться в мінімально можливі, тому що людина лінива і економічна.

Наприкінці спринту відбувається демо (demo, демонстрація) з показом того, що вдалося створити протягом спринту, спринт-рев'ю (sprint review, огляд спринту) з переглядом продакт-беклогу та розмовами про те, ЩО ми робимо, а також ретроспектива (retro ) - що ми робили не найкраще весь спринт і хочемо поліпшити далі - про те, ЯК ми це робимо.

«Якби я мав вісім годин для того, щоб зрубати дерево, я б шість годин витратив на заточення сокири». (приписується лісорубу та президенту Аврааму Лінкольну)

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

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

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

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

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

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

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

Scrum VS Agile VS Waterfall

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

Скрам - це один із фреймворків agile, формалізована методологія роботи над проектами До аджайлу методологій, крім скраму, належать й інші сучасні підходи. Альтернативою scrum можуть бути , Scrumban та інші. Тобто скрам – це agile, але agile – не лише скрам.

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

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

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

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

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

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

Як працювати по скраму

Ролі в скрамі

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

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

Для скраму потрібна невелика команда: 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 і т.д. Оцінюйте завдання всією командою за допомогою планування покеру: використовуйте колоду карт або додаток на смартфон.

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

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

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

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

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

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

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

Скрам Гайд. Вичерпне посібник із Скраму: Правила Ігри / Кен Швабер, Джефф Сазерленд

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

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

Управління продуктом у 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.

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

Spotify

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

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

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

Проект «Вартовий» для ФБР

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

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

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

Програми

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

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

Worksection зараз допрацьовує та тестує перед впровадженням (на жовтень 2017) фішки для scrum: діаграми згоряння завдань та беклог – суто скрамівські інструменти. Можливо буде іпланування покеру.Наш консультант у цій справі,

Останнім часом мене часто запитують, що таке Scrum, люди, які мають дуже віддалене ставлення до ІТ. У зв'язку з цим я вирішила пояснити простими словами, що означає Scrum. Так що панове Scrum-послідовники не судіть мене суворо.

Scrum (Скрам) - це не абревіатура, цей термін взятий з регбі, який позначає бій навколо м'яча.

Сам термін Scrum, я визначила б так — це методологія управління проектами, яка побудована на принципах тайм-менеджмету. Основною її особливістю є залучення до процесу всіх учасників, причому у кожного учасника є своя певна роль. Суть у тому, що не лише команда працює над розв'язанням задачі, але всі ті, кому цікаве розв'язання задачі, не просто поставили її та розслабилися, а постійно «працюють» із командою, і ця робота не означає лише постійний контроль.

Основні терміни, що використовуються в методології:

Власник продукту (Product owner) — людина, яка має безпосередній інтерес у якісному кінцевому продукті, вона розуміє, як цей продукт має виглядати/працювати. Ця людина не працює в команді, вона працює на стороні замовника/клієнта (це може бути як інша компанія, так і інший відділ), але ця людина працює з командою. І це та людина, яка розставляє пріоритети для завдань.

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

Scrum-команда - Це команда, яка приймає всі принципи Scrum і готова з ними працювати.

Спринт - Відрізок часу, який береться для виконання певного (обмеженого) списку завдань. Рекомендується брати 2-4 тижні (тривалість визначається командою один раз).

Беклог (backlog) - Це список усіх робіт. Можна сказати, що це щоденник загального користування 🙂

Розрізняють 2 види беклогів: Product-Белог і спринт-Белог.

Product-белог - Це повний список усіх робіт, при реалізації яких ми отримаємо кінцевий продукт.

Спринт-белог — це список робіт, який визначила команда та погодила з Власником продукту на найближчий звітний період (спринт). Завдання в спринт-бэклог беруться з product-бэклога.

Планування спринту - Це нарада, на якій присутні всі (команда, Scrum-майстер, Власник продукту). Протягом цієї наради Власник продукту визначає пріоритети завдань, які він хотів би побачити виконаними після спринту. Команда оцінює за часом, скільки з бажаного можуть виконати. У результаті виходить список завдань, який може змінюватися протягом спринту і до кінця спринту може бути повністю виконаний.

Спробую пояснити все це на прикладі роботи PR-агентства, як це могло б виглядати, якби вони працювали по Scrum.

Компанія клієнт «Ікс» хоче провести через 2 місяці масштабний захід для своїх партнерів та журналістів. Послуги щодо організації такого заходу компанія «Ікс» замовила у агентства «Зет». Компанію «Ікс» представляє PR-менеджер, який відповідає за організацію заходу клієнта. У термінології Scrum - ця людина називається Власник продукту. З боку агенції за організацію заходу відповідає account-менеджер ( Scrum-майстер), у підпорядкуванні якого перебуває команда ( Scrum-команда). На спільній нараді ( планування спринту) компанія та агентство вирішують, що вони будуть звітувати-планувати кожні 2 тижні ( довжина спринту). На перші 2 тижні вони запланували перелік завдань ( спринт-беклог), однак команда оцінила, що не всі з цього списку вони встигнуть виконати. Тоді PR-менеджер (він же Власник продукту), каже які з цього списку завдань пріоритетніші на найближчі 2 тижні, після чого команда береться за виконання завдань. Єдине, що тут має бути враховано, що на момент планування першого спринту має бути спланований весь список завдань на 2 місяці ( product-белог), щоб не вийшло так, що на момент проведення заходу щось не виконано.

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

Scrum простою мовою

"З усіх труднощів, з якими зіткнулися НАСА, відправляючи людину на Місяць, управління було напевно найскладнішим завданням"

- Роджер Лауніс, історик НАСА

У людства за всю історію накопичився значний список успішно реалізованих складних проектів. Від будівництва Пірамід у Гізі до відправлення людини на Місяць, найсміливіші людські починання вимагали злагодженої роботи тисяч людей. А це має на увазі складну систему управління проектами.

І хоча лише одиниці з нас зіштовхнуться із завданнями такого масштабу, більшість читачів цього блогу так чи інакше стикаються з проектним управлінням. За оцінками PMI до 2020 року з'являться – а багатьом іншим професіоналам найчастіше доводиться керувати міні-проектами хоча б на особистому рівні.

Говорячи простими словами, Управління проектами – це управління та організація всього, що потрібно для досягнення мети – вчасно та в рамках бюджету, звичайно ж. Будь до розробка нового програмного забезпечення, проведення маркетингової компанії або висадка людини на Марс – проектне управління дозволяє досягти успіху.

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

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

У цій статті ми розглянемо:

• Класичний проектний менеджмент
• Agile
• Scrum
• Lean
• Kanban
• SixSigma
• PRINCE2

І перш ніж розглядати конкретні методи, відповімо на очевидне питання – «А навіщо взагалі потрібні системи та методи управління проектами?»- Розглянемо, природно, коротко, історію управління проектами та визначимо базові терміни проектного управління.

Чому "управління проектами"?

Імена Ніла Армстронга та Базза Олдріна назавжди увійдуть в історію як символи одного з найбільших досягнень людства – висадження людини на Місяць. Однак основний внесок у цю подію зробили 400 000 співробітників НАСА та 20 000 компаній та університетів, які працювали разом над місією «Аполлон».

У 1961 році Джон Кеннеді поставив завдання висадити людину на супутнику Землі і повернути її назад - при тому, що на той момент НАСА відправляли людину в космос лише на 15 хвилин. Така амбітна мета потребувала неймовірної кількості ресурсів, кооперації, інновацій та планування.

Як говориться в книзі НАСА Managing the Moon Program, основна проблема полягала не в тому, що робити?", а в тому, « як зробити стільки за такий короткий термін?За словами доктора Макса Фагета (Dr. Max Faget), голови інжинірингу в Космічному центрі імені Ліндона Джонсона (The Lyndon B. Johnson Space Center, JSC), тоді в НАСА не уявляли, як укласти всі необхідні дії у 10 років. А тому першим кроком стало "розбити проект на керовані етапи".

Потім важливо було прискорити виконання кожної окремої фази та переконатися, що команди та компанії, що працюють на кожній фазі, ефективно взаємодіють одна з одною та вчасно постачають результати. Це завдання було покладено на доктора Джорджа Мюллера (George E. Muller), який керував кожною частиною проекту «Аполлон», від Білого Дому до постачальника найдрібнішої деталі. Щоб контролювати проект було легше, він вирішив розбити проект на 5 областей: "Контроль Програми", "Системна Інженерія", "Тестування", "Надійність та Якість" та "Льотна експлуатація". Схема керування програмою Аполлон представлена ​​на Малюнок 1.

Ця система з 5 етапів – названих «Етапами GEM» на честь ініціалів доктора Мюллера – була розроблена «заради фокусування на тестуванні продукту, та на його розробці з урахуванням того, що його тестуватимуть», як зазначає сам Мюллер. «Контроль Програми» визначав, що потрібно зробити, керував бюджетом та вимогами, а також керував взаємозв'язками елементів програми. Область «Системна інженерія» відповідала за розробку нових пристроїв та вузлів, «Тестування» за те, що ці нові елементи працюють, «Надійність та Якість» перевіряли розроблені елементи на відповідність вимогам та стандартам, а «Літна експлуатація» відповідала за те, що ці вузли працюватимуть під час польоту.

Багато хто спочатку віднеслися до методу, запропонованого Мюллером, зі скептицизмом, але врешті-решт йому вдалося переконати членів програми в необхідності дотримання цього алгоритму. Ця система показала свою ефективність – проект було завершено успішно, і, можна навіть сказати, тріумфально, з випередженням заявлених термінів. Це стало можливим лише завдяки розбиттю масштабного проекту на керовані, повторювані етапи, що дозволило працювати безлічі окремих компаній та фахівців в єдиному ритмі. Так проектне управління довело свою ефективність у Космічній гонці.

Коротка історія проектного управління

Проектне управління не було винайдено НАСА та доктором Мюллером. Єгипетські піраміди та Велика Китайська стіна є продуктами проектного управління з доісторичних епох. На жаль, документальних свідчень про те, як проходила реалізація та управління цими проектами не збереглося, і нинішнє проектне управління відірвано від знань минулих століть.

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

Однак, якщо Ви - шеф-кухар, і готуєте не одну страву, а кілька, наприклад, салат (приготування якого складається з 3 етапів) і десерт (який потрібно тільки подати), то Вам знадобиться інструмент, що дозволяє відстежувати тимчасові витрати на кожен з елементів та час, коли вони мають бути готові. І тут на допомогу приходить один із перших сучасних інструментів проектного управління: Діаграма Гантта, представлена ​​на Малюнок 2.

Винайдена незалежно проролем Адамекі (Korol Adamecki) та Генрі Л. Ганттом (Genry L. Gantt) на початку XX ст., діаграма Гантта показує розклад проекту ґрунтуючись на датах закінчення та завершення завдань. До неї вносяться завдання, їх тривалість і взаємозв'язок, а потім вираховується критичний шлях - найдовший ланцюжок взаємопов'язаних завдань, що визначають тривалість проекту. Взаємозв'язки між початком та закінченням різних завдань дуже важливі – ви ж не можете подати гостям суп, доки ви його не зварили, чи не так?

Так ось, типовий проект дуже схожий на проект приготування та подачі вечері, тільки в ньому набагато більше завдань, взаємозв'язків, дедлайнів та видів ресурсів. Проектам із жорсткими дедлайнами діаграма Гантта допомагає вирішити, коли краще розпочинати ті чи інші завдання, щоб скоротити час реалізації. А для проектів із сильними ресурсними обмеженнями, діаграма Гантта надає можливість побудувати схему у формі ланцюжка подій процесів (event-driven process chain) для планування ресурсів.

Різним проектам потрібний різний рівень контролю. Наприклад, якщо ви публікуєте серію статей у , то жорсткі дедлайни не такі важливі. Набагато важливіше чіткий процес, у якого є можливість скласти структуру кожної статті, зробити малюнок кожної їх, отримати зворотний зв'язок, внести правки, закінчити статтю, віднімати і опублікувати. Замість управління часом та ресурсами, ви керуєте процесом.

Для таких проектів краще підходять гнучкі методи управління проектами Agile та пов'язані з ним підходи, такі як Lean, Kanban та інші. Є й методи, що дозволяють керувати як робочим потоком, і часом, і ресурсами – 6 Сигм і Scrum.

Популярні системи управління проектами

За історію проектного управління було створено безліч різних методів управління проектами під практично будь-які потреби. Навіть якщо Ви не збираєтеся відправляти людину на Місяць і не маєте аналогічної кількості ресурсів, Ви все одно знайдете відповідний для себе інструмент. Головне зрозуміти, що найважливіше для Вашого проекту – дедлайни, ресурси, дотримання процесу, або одразу кілька факторів – а потім вибрати метод управління проектом, орієнтований на досягнення цього показника.

Перш ніж розпочати розгляд найпопулярніших методів, визначимо деякі ключові терміни.

Базові терміни проектного управління

Agile:Гнучкий ітеративно-інкрементальний підхід до управління проектами та продуктами, орієнтований на динамічне формування вимог та забезпечення їх реалізації в результаті постійної взаємодії всередині робочих груп, що самоорганізуються, що складаються з фахівців різного профілю. Існує безліч методів, що базуються на ідеях Agile, найпопулярніші з яких – Scrum та Kanban.

Критичний шлях:Безперервна послідовність робіт і подій від початкової до кінцевої події, що вимагає найбільшого часу на її виконання.

Подієвий ланцюжок процесів (EPC-діаграма):діаграма, що відображає послідовність реалізації робіт проектів ґрунтуючись на доступності та завантаженості ресурсів

Резерв часу:Час, на який може бути відкладено початок роботи без впливу на загальну тривалість проекту. Таким чином, у робіт на критичному шляху резерв дорівнюватиме нулю.

Віха (контрольна точка,milestone):Ключова подія, що означає, наприклад, кінець етапу. На діаграмі Гантта позначається завданням із нульовою тривалістю.

Менеджер проекту (керівник проекту,projectmanager,PM ): Керівник команди проекту, відповідальний за управління проектом (планування, реалізацію та закриття проекту).

Ресурси:Елементи, необхідні реалізації проекту. Ресурсами є час, обладнання, матеріали, співробітники та інше.

Спринт (Sprint):Ітерація (робочий цикл) в Scrum, що триває від тижня до місяця, у ході якої створюється робоча версія продукту чи його елемент, що становить цінність замовника.

«Класичне» чи «традиційне» проектне управління:Найбільш поширений метод управління проектами, заснований на так званому «водопадному» (Waterfall) або каскадному циклі, при якому завдання передається послідовно по етапах, що нагадують потік.

Класичне проектне управління

Найбільш очевидний спосіб зробити свій проект більш керованим – це розбити його виконання на послідовні етапи. Саме на такій лінійній структурі базується традиційне проектне управління. У цьому сенсі воно нагадує комп'ютерну гру – не можна перейти на наступний рівень, не завершивши попередній. Схема робочого процесу наведена на Малюнок 3.

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

Зазвичай виділяють 5 етапів класичного проектного управління, але можна додавати і додаткові етапи, якщо цього вимагає проект.

5 етапів традиційного менеджменту:

Етап 1. Ініціація.Керівник проекту та команда визначають вимоги до проекту. На даному етапі часто проводяться наради та «мозкові штурми», на яких визначається що ж повинен являти собою продукт проекту.

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

Етап 3. Розробка.Ця стадія реалізується задля всіх проектів — зазвичай вона є частиною фази планування. У фазі розробки, характерної для технологічних проектів, визначається конфігурація майбутнього проекту та/або продукту та технічні способи його досягнення. Наприклад, у ІТ-проектах на даному етапі вибирається мова програмування. ( У вітчизняній практиці ця фаза зазвичай не виділяється, а термін «розробка» не використовується – прим. пров.)

Етап 4. Реалізація та тестування.На цій фазі відбувається власне основна робота щодо проекту – написання коду, зведення будівлі тощо. Наслідуючи розроблені плани починає створюватися зміст проекту, визначений раніше, проводиться контроль за обраними метриками. У другій частині цієї фази відбувається тестування продукту, він перевіряється на відповідність вимогам Замовника та зацікавлених сторін. У частині тестування виявляються та виправляються недоліки продукту.

Етап 5. Моніторинг та завершення проекту.Залежно від проекту дана фаза може складатися з простої передачі Замовнику результатів проекту або ж з тривалого процесу взаємодії з клієнтами щодо покращення проекту та підвищення їх задоволеності та підтримки результатів проекту. Останнє відноситься до проектів у галузі клієнтського сервісу та програмного забезпечення.

Те, що описано вище – база, де будуються різні методи управління проектами. Різним проектам потрібні різні фази реалізації – деяким достатньо трьох фаз, іншим набагато більше. Іноді використовується так званий «ітеративний водоспад», в якому кожен етап є певним підпроектом, під час якого завдання реалізуються за фіксованими ітераціями. Але суть залишається одна - проект розбитий на етапи, які виконуються в певній послідовності.

Завдяки тому, що класичний проектний менеджмент суворо прив'язаний до виконання завдань, як правило, заздалегідь визначеному на етапі планування, для реалізації проектів у рамках цього підходу відмінно підходять інструменти календарно-мережевого планування. Найпоширенішим інструментом календарно-мережевого планування є згадана раніше діаграма Гантта. Існує безліч інструментів для її побудови – від простих таблиць на кшталт Excel та Smartsheet до професійних програмних пакетів на кшталт Microsoft Project та Primavera.

Сильні сторони класичного проектного менеджменту

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

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

Слабкі сторони класичного проектного менеджменту

Основна слабка сторона класичного проектного менеджменту – нетолерантність змін. Керівництво компанії Toyota, знамениту створенням таких систем як Lean та Kanban, часто критикують за те, що вони застосовують класичний підхід у розробці софту для своєї компанії, причому саме за нестачу гнучкості.

Оплот класичного підходу зараз - будівельні та інженерні проекти, в яких зміст проекту залишається практично незмінним протягом усього проекту. Але якщо у Вашому проекті ресурси і час не є ключовими обмеженнями, а зміст проекту зазнає змін – можливо, вам варто придивитися до інших систем управління проектами.

Agile

Як уже говорилося раніше – не всі проекти можуть бути структуровані таким чином, щоб бути реалізованими за класичним проектним підходом. Повертаючись до нашого прикладу з шеф-кухарем: приготування однієї страви ідеально лягає на «водопадний» підхід, а ось вчасно приготувати і подати вечерю з чотирьох страв практично неможливо, якщо доведеться щоразу чекати закінчення приготування однієї страви, щоб приступити до приготування іншої.

І тут у гру вступає Agile – сімейство гнучких ітеративно-інкрементальних методів управління проектами і продуктами. Згідно з цим підходом, проект розбивається не на послідовні фази, а на маленькі підпроекти, які потім «збираються» у готовий продукт. Схема роботи наведена на Малюнок 5.

Таким чином, ініціація та верхньорівневе планування проводяться для всього проекту, а наступні етапи: розробка, тестування та інші проводяться для кожного міні-проекту окремо. Це дозволяє передавати результати цих міні-проектів, так звані інкременти, швидше, а приступаючи до нового підпроекту (ітарації) до нього можна внести зміни без великих витрат і впливу на інші частини проекту.

Незважаючи на те, що Agile увійшов у моду відносно недавно, ідея ітеративної розробки не нова (про історію появиAgile можна прочитати - Прим.пер.).Свою нинішню назву сімейство гнучких методологій отримало у 2001 р. з публікації Маніфесту Agile (Agile Manifesto), який закріпив основні цінності та принципи гнучкої розробки програмного забезпечення, в основі яких – командна робота та адаптація, навіть «любов» до змін.

Сам собою Agile – не спосіб управління проектами. Це скоріше набір ідей та принципів того, як потрібно реалізовувати проекти. Вже на основі цих принципів та кращих практик були розроблені окремі гнучкі методи або, як їх іноді називають, фреймворки (frameworks): Scrum, Kanban, Crystal та багато інших. Ці методи можуть досить сильно відрізнятися один від одного, але вони слідують тим самим принципам.

Сильні сторониAgile

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

Один із принципів Agile: «Реакція на зміни важливіша за дотримання плану». Саме швидка та відносно безболісна реакція на зміни є причиною того, що багато великих компаній прагнуть зробити свої процеси гнучкішими. Крім того, Agile чудово підходить для проектів з «відкритим кінцем» - наприклад, запуску сервісу чи блогу.

Вотчина Agile – розробка нових інноваційних продуктів. У проектах з розробки таких продуктів висока частка невизначеності, а інформація про продукт розкривається протягом проекту. У таких умовах реалізовувати проект з «водоспаду» стає неможливо – немає інформації для планування.

Слабкі сторониAgile

На відміну від PRINCE2 та PMBOK Agile – не є ні методологією, ні стандартом. Agile – це набір принципів та цінностей. Слабка сторона полягає в тому, що кожній команді доведеться самостійно складати свою систему управління, керуючись принципами Agile. Це непростий і тривалий процес, який вимагатиме змін усієї організації, починаючи процедурами та закінчуючи базовими цінностями. Це тернистий шлях і не всім організаціям він під силу.

Цей шлях вимагатиме від лідера змін не лише знань та завзятості, а й серйозних адміністративних ресурсів, а також витрат. На щастя, є готові набори практик, які полегшують Agile-трансформацію організації. До таких наборів відносяться фреймворк Scrum, метод Kanban та багато інших – Crystal, LeSS, SAFe, Nexus.

Scrum

Гнучкий фреймворк, створений у 1986 році, вважається найбільш структурованим із сімейства Agile. Створений у 1986 році, він поєднує в собі елементи класичного процесу та ідеї гнучкого підходу до управління проектами. У результаті вийшло дуже збалансоване поєднання гнучкості та структурованості.

Наслідуючи завіти Agile, Scrum розбиває проект на частини, які відразу можуть бути використані Замовником для отримання цінності, які називаються заділами продуктів (product backlog). І незважаючи на те, що «заділ продукту» — досить вірний переклад і використовується у професійній літературі, у російській практиці найчастіше використовується просто «беклог». Потім ці частини пріоретизуються Власником продукту – представником Замовника у команді. Найважливіші «шматочки» першими відбираються до виконання у Спринті – так називаються ітерації в Scrum, що тривають від 2 до 4 тижнів. Наприкінці Спринта Замовнику представляється робочий інкремент продукту – ті найважливіші «шматочки», які можна використовувати. Наприклад, сайт із частиною функціоналу чи програма, яка вже працює, нехай і частково. Після цього команда проекту розпочинає наступного Спринту. Тривалість у Спринта фіксована, але команда вибирає її самостійно на початку проекту, виходячи із проекту та власної продуктивності.

Щоб переконатися, що проект відповідає вимогам Замовника, які мають властивість змінюватися з часом, перед початком кожного Спринту відбувається переоцінка ще не виконаного змісту проекту та внесення змін до нього. У цьому процесі беруть участь усі – команда проекту, Scrum Майстер (Scrum Master, лідер команди проекту) та Власник продукту. І відповідальність за цей процес лежить на всіх.

Як мовилося раніше, Власник продукту є представником Замовника у проекті, або уособлює всіх клієнтів майбутнього проекту, якщо Замовника немає. Для цього він повинен досконало знати їхні потреби та спосіб мислення, а також розбиратися в продукті та технології його виготовлення. Scrum Майстер покликаний допомогти учасникам проекту краще зрозуміти та прийняти цінності, принципи та норми практики Scrum. Він лідер та посередник між зовнішнім світом та командою. Його завдання – стежити, щоб ніхто не заважав команді самостійно та комфортно працювати над поставленими завданнями. Команда відповідає за те, щоб наприкінці спринту всі необхідні завдання були зроблені, а поставки – виконані.

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

Багатьом Scrum може здатися складним для впровадження – новий процес, нові ролі, багато делегування та нова організаційна структура. Але це гнучкий і при цьому структурований підхід до реалізації проектів, який на відміну від розмитих і загальних принципів Agile не дозволить роботі піти не в те русло.

Сильні сторониScrum

Scrum був розроблений для проектів, які потребують «швидких перемог» у поєднанні з толерантністю до змін. Крім того, цей фреймворк підходить для ситуацій, коли не всі члени команди мають достатній досвід у тій сфері, в якій реалізується проект – постійні комунікації між членами команд дозволяють брак досвіду або кваліфікації одних співробітників за рахунок інформації та допомоги від колег.

Онлайн телеканал Netflix є чудовим прикладом швидких поставок результатів. Сайт ресурсу оновлюється кожні два тижні завдяки Scrum, який не просто дозволяє працювати з високою швидкістю, але й акумулює досвід користувача і дає можливість виявити найголовніше для клієнтів.

Під час кожної ітерації розробники додають і тестують нові функції сайту та прибирають ті, якими не користувалися клієнти. За словами команди Netflix, основна перевага Scrum у тому, що він дозволяє "швидко помилятися". Замість того, щоб довго і з великими витратами готувати великий реліз, поставки раз на два тижні Scrum мають невеликий розмір. Їх легко відстежувати і якщо щось йде не так, швидко виправляти.

Слабкі сторониScrum

Scrum дуже вимогливий до команди проекту. Вона має бути невеликою (5-9 осіб) і кросфункціональною – тобто члени команди повинні мати більш ніж одну компетенцію, необхідну для реалізації проекту. Наприклад розробник ПЗ повинен мати знання у тестуванні та бізнес-аналітиці. Робиться це для того, щоб частина команди не «вимагала» на різних етапах проекту, а також для того, щоб співробітники могли допомагати та підміняти один одного.

Крім того, члени команди мають бути «командними гравцями», активно брати на себе відповідальність та вміти самоорганізовуватись. Підібрати таку зрілу команду дуже непросто!

Scrum підходить не для всіх команд і організацій ще й тому, що пропонований процес може не підійти для розробки конкретного продукту - наприклад, промислового верстата або будівлі.

Lean

Agile каже нам, що потрібно розбивати на невеликі керовані пакети робіт, але нічого не говорить про те, як керувати розробкою цього пакета. Scrum пропонує нам свої процеси та процедури. Lean ж, своєю чергою, додає до принципів Agile схему потоку операцій (workflow) у тому, щоб кожна з ітерацій виконувалася однаково якісно.

У Lean, як і в Scrum, робота розбивається на невеликі пакети поставки, які реалізуються окремо і незалежно. Але в Lean для розробки кожного пакета поставки існує потік операцій з етапами, подібними до тих, які були створені для проекту Аполлон. Як і в класичному проектному менеджменті, це можуть бути етапи планування, розробки, виробництва, тестування та постачання – або будь-які інші необхідні для якісної реалізації проектів етапи.

Етапи Lean та їх гнучкість дозволяють бути впевненими у тому, що кожна частина проекту реалізується так, як потрібно. У Lean не прописані чіткі межі етапів, як у Scrum прописані обмеження Спринтів. Крім того, на відміну від класичного проектного менеджменту, Lean дозволяє паралельно виконувати кілька завдань на різних етапах, що підвищує гнучкість та збільшує швидкість виконання проектів.

Як і Agile, Lean це скоріше концепція, спосіб мислення, ніж щось висічене у камені. Використовуючи ідеї Lean Ви можете самостійно створити систему, яка б задовольняла вашим вимогам в управлінні проектами.

Сильні сторониLean

Якщо Вам подобаються ідеї Agile, але проект вимагає дуже рівної якості та чіткого виконання, Lean надає набір інструментів для того, щоб задовольнити ці вимоги. Lean поєднує гнучкість і структурованість, як Scrum, але в трохи іншому ключі.

Слабкі сторониLean

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

А ще, на відміну від Scrum, Lean не пропонує чіткого робочого процесу для реалізації «шматків» проекту, що сприяє розтягуванню термінів проекту. Ця проблема може бути вирішена за допомогою ефективного керівництва та чітких комунікацій – головне пам'ятати про це.

Kanban

Lean виглядає трохи абстрактним сам собою, але в комбінації з Kanban його стає набагато простіше використовувати для побудови власної системи управління проектами. Створений інженером компанії Toyota Тайічі Оно (Taiichi Ono) у 1953 році, Kanban дуже схожий на схему промислового виробництва. На вході до цього процесу потрапляє шматочок металу, але в виході виходить готова деталь. Також і Kanban, інкремент продукту передається вперед з етапу на етап, а в кінці виходить готовий до поставки елемент.

Крім того, творець Kanban надихався супермаркетами, а саме їх принципом - "тримай на полицях тільки те, що потрібно клієнту". А тому Kanban дозволяється залишити незакінчену задачу на одному з етапів, якщо її пріоритет змінився і є інші термінові завдання. Невідредагована стаття для блогу, підвішена без дати публікації або частина коду функції, яку можливо не включатимуть у продукт – все це нормально для роботи з Kanban.

Kanban набагато менш строгий, ніж Scrum - він не обмежує час спринтів, немає ролей, за винятком власника продукту. Kanban навіть дозволяє члену команди вести кілька завдань одночасно, що не дозволяє Scrum. Також ніяк не регламентовані зустрічі щодо статусу проекту – можна робити це як Вам зручно, а можна не робити взагалі.

Для роботи з Kanban необхідно визначити етапи потоку операцій (workflow). У Kanban вони зображуються як стовпці, а завдання позначають спеціальні картки. Картка переміщається по етапах, подібно до деталі на заводі, що переходить від верстата до верстата, і на кожному етапі відсоток завершення стає вищим. На виході ми отримуємо готовий до постачання замовнику елемент продукту. Дошка зі стовпцями та картками може бути як справжньою, так і електронною – навіть тут Kanban не накладає жодних обмежень на користувачів.

Ваша власна система Kanban може бути настільки гнучкою, наскільки Ви самі того забажаєте - адже багато в чому Kanban є візуалізацією ідеї Agile. Але Kanban має 4 стовпи, на яких тримається вся система:

1. Картки:Для кожного завдання створюється індивідуальна картка, до якої заноситься вся необхідна інформація про завдання. Таким чином, вся потрібна інформація про завдання завжди під рукою.
2. Обмеження кількості завдань на етапі:Кількість карток одному етапі суворо регламентовано. Завдяки цьому відразу стає видно, коли в потоці операцій виникає затор, який оперативно усувається.
3. Безперервний потік:Завдання з беклогу потрапляють у потік у порядку пріоритету. Таким чином, робота ніколи не припиняється.
4. Постійне покращення («кайзен» (kaizen)):Концепція постійного поліпшення виникла Японії наприкінці ХХ століття. Її суть у постійному аналізі виробничого процесу та пошуку шляхів підвищення продуктивності.

Сильні сторониKanban

Як і Scrum, Kanban добре підходить для досить згуртованих команди з гарною комунікацією. Але на відміну від Scrum, у Kanban немає встановлених чітких дедлайнів, що добре підходить для замотивованих та досвідчених команд.

При правильному налаштуванні та управлінні, Kanban може принести велику користь команді проекту. Точний розрахунок навантаження на команду, правильне розміщення обмежень і концентрація на постійному поліпшенні - все це дозволяє Kanban серйозно економити ресурси і вкладати в дедлайни і бюджет. І все це у поєднанні з гнучкістю.

Слабкі сторониKanban

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

6 сигм (Six Sigma)

Компанія Motorola, поряд з Toyota, також зробила внесок у розвиток світового проектного управління. Інженер цієї компанії Bill Smith створив концепцію 6 сигм у 1986 році. Це більш структурована версія Lean ніж Kanban, до якої додано більше планування для економії ресурсів, підвищення якості, а також зниження кількості шлюбу та проблем.

Кінцева мета проекту – задоволення замовника якістю продукту, якого можна досягти за допомогою безперервного процесу покращення всіх аспектів проекту, що базується на ретельному аналізі показників. У концепції 6 сигма приділяється окрема увага усунення проблем, що виникають.

Для цього було запропоновано процес із 5 кроків, відомих як DMEDI:

• Визначення (Define):Перший етап дуже нагадує ранні етапи інших систем проектного управління. На ньому визначається зміст проекту, збирається інформація про передумови проекту, ставляться цілі.
• Вимірювання (Measure): 6 сигм орієнтована на збір та аналіз кількісних даних про проект. На цьому етапі відбуваються визначається, які показники визначатимуть успіх проекту та які дані потрібно збирати та аналізувати.
• Дослідження (Explore):На стадії дослідження менеджер проекту вирішує, яким чином команда може досягти поставлених цілей і виконати всі вимоги в строк і в рамках бюджету. На даному етапі дуже важливе нестандартне мислення керівника проектів при вирішенні проблем, що виникли.
• Розробка (Develop):На даному етапі реалізуються плани та рішення, прийняті на попередніх етапах. Важливо розуміти, що на даному етапі необхідний детальний план, в якому описані всі дії, необхідні досягнення поставлених цілей. Також на цьому етапі вимірюється прогрес проекту.
• Контроль (Control):Ключовий етап у методології 6 сигм. Його основне завдання – довгострокове покращення процесів реалізації проектів. Даний етап вимагає ретельного документування викладених уроків, аналізу зібраних даних та застосування отриманих знань як у проектах, так у всій компанії загалом.

6 сигм дуже схожа на Kanban, тільки із встановленими етапами реалізації завдань – плануванням, визначенням цілей та тестуванням якості. Найімовірніше, зустрічей команди при застосуванні 6 сигм буде значно більше, ніж при Kanban, але процес реалізації проектів більш структурований і команді складніше збитися з шляху. І, як і Kanban, 6 сигм можна відносно легко адаптувати до потреб конкретної компанії чи команди. Жорсткою вимогою є лише ретельний вимір та контроль показників проекту на етапах реалізації – без цього неможливе постійне довгострокове покращення процесів реалізації проекту.

Сильні сторони 6 сигм

Концепція 6 сигм надає чітку схему для реалізації проектів та постійного поліпшення процесів. Визначаючи цілі, потім ретельно аналізуючи їх та переглядаючи ви отримуєте кількісні дані для глибшого розуміння проекту та прийняття більш якісних рішень. І хоча збір, аналіз даних та витяг уроків можуть зайняти певний час, це дозволить покращити та оптимізувати процеси реалізації проекту та заощадити таким чином ресурси в майбутньому.

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

Слабкі сторони 6 сигм

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

Крім того, основний лейтмотив 6 сигм: "Все завжди можна зробити ще краще". Це може демотивувати співробітників, які не відчувають задоволення від виконаної роботи. Крім того, якщо проект одиничний і компанія не планує в майбутньому реалізовувати подібні проекти, всі витрати на аналіз та витяг уроків можуть виявитися марними.

PRINCE2

НАСА – не єдина державна організація, яка зробила внесок у розвиток проектного управління. Британський уряд давно оцінив ефективність проектного управління, і в 1989 році була створена британська методологія PRINCE2. Назва походить від акроніму « PR ojects IN C ontrolled E nvironments version 2 », що перекладається як «Проекти у контрольованому середовищі версія 2». На відміну від гнучких методів PRINCE2 не використовує ітеративний підхід до проекту. Якщо порівнювати PRINCE2 іншими продуктами, його можна порівняти з гібридом класичного підходу до проектного управління та концентрації на якості з 6 сигм.

Методологія PRINCE2 на відміну від, наприклад, склепіння знань PMBOK не містить:

• Спеціалізованих аспектів управління проектом, наприклад, галузевих;
• Конкретних практик та інструментів управління проектами, таких як діаграма Гантта, WBS тощо.

PRINCE2 концентрується на управлінських сторонах проекту, виражених у 7 принципах, 7 процесах та 7 темах проекту.

• 7 принципів визначають загальні правила управління проектами з PRINCE2, визначають базу методології;
• 7 процесів визначають кроки просування проектного циклу;
• 7 тем – аспекти, за якими проводиться контроль для досягнення успіху проекту.

На початку проекту PRINCE2 пропонує нам визначити 3 основні аспекти проекту:

• Бізнес-аспект (Чи принесе цей проект зиск?)
• Споживчий аспект (Який потрібен продукт, що ми робитимемо?)
• Ресурсний аспект (Чи достатньо у нас всього, щоб досягти мети?)

У PRINCE2 більш чітко визначена структура команди проекту, ніж більшість підходів до проектного управління. Це пов'язано з тим, що PRINCE2 орієнтований на масштабні державні проекти та великі організації.

Згідно з PRINCE2 у кожного члена команди є своя чітка роль у кожному з 7 процесів:

• Початок проекту (Starting upa project): У результаті процесу призначається менеджер проекту та визначаються загальні вимоги до характеристик продукту. Менеджер проекту, чиє основне завдання – увага до деталей, звітує перед Керівним комітетом проекту, який відповідає за загальне керівництво проектом. Саме Керуючий комітет стежить за тим, щоб проект не збився з курсу, і він повністю відповідає за успіх проекту.
• Ініціація проекту (Initiationa project): У ході цього процесу менеджер проекту складає «Документацію щодо ініціації проекту», в якій міститься план проекту на стадії. Стадії можуть тривати різну кількість часу, але, як і в класичному підході, вони випливають строго один за одним.
• Керівництво проектом (Directing a project): Цей процес надає можливість Керівному комітету нести спільну відповідальність за успіх проекту, не занурюючись у деталі, що знаходяться у межах повноважень менеджера проекту.
• Контроль стадії (Controlling a stage): При реалізації проекту, навіть за ідеальних умов, будуть вноситись певні зміни. Процес «Контроль стадії» реалізує одне із принципів PRINCE2 – принцип управління винятків. В обов'язки менеджера проекту входить відстежувати в ході виконання стадії відхилення від планових параметрів проекту за термінами, змістом, бюджетом та ін. шляхи виходу із ситуації.
• Управління виробництвом товару (Managing Product Delivery):Процес управління виробництвом продукту є взаємодія менеджера проекту та менеджера команди зі створення однієї з продуктів проекту. До обов'язків менеджера проекту у процесі входить делегування повноважень зі створення продукту менеджеру команди і приймання створеного продукту.
• Управління межами стадії (Managing a stage boundary): У ході цього процесу менеджер проекту надає Управлінню Комітету всю необхідну інформацію для оцінки результатів пройденої стадії та прийняття рішення про перехід на наступну стадію.
• Завершення проекту (Closinga project): Одна з відмінностей PRINCE2 в тому, що завершення проекту не виділяється в окремий етап або стадію, як у класичному підході, а виконується в рамках фінальної стадії створення продукту. Мета процесу – підтвердити, що продукт проекту прийнято, чи проект більше не може принести нічого корисного.

PRINCE2 може бути адаптований для проектів будь-якого масштабу та будь-якої предметної області. Методологія пропонує конкретні рекомендації щодо зміни життєвого циклу проекту, рольової моделі та набору обов'язкових документів відповідно до потреб проекту.

Сильні сторони PRINCE2

• Адаптованість до особливостей організації;
• Наявність чіткого опису ролей та розподілу відповідальності;
• Акцент на продуктах проекту;
• Певні рівні управління;
• Фокус на економічній доцільності;
• Послідовність проектної роботи;
• Акцент на фіксації досвіду та постійному вдосконаленні.

Слабкі сторони PRINCE2

• Відсутність галузевих практик;
• Відсутність конкретних інструментів для роботи у проекті.

Найкраща система управління проектами … для Вас!

Управління проектами – це наука, але наука не найточніша. У цій галузі немає непорушних основ та універсальних рішень. Якщо вам вдасться знайти метод, що ідеально підходить вашому проекту – вважайте, що вам пощастило, адже більшості менш щасливих керівників доводиться докладати зусиль для створення та налаштування власних систем управління проектами. Ці системи можуть бути складені з елементів існуючих систем або навіть створені з нуля, як у випадку з місією «Аполлон». Головне використовуйте щось, що дасть вам хоч якусь структуру і дозволить не забути, що головне для вашого проекту.

« Цинізм є реакцією нашої свідомості на почуття відчаю.».
Джефф Сазерленд

Наскільки сильна альтернатива PM?

Діючи як топ-менеджер і проект-менеджер, я зіткнувся з поняттям Scrum як такою собі екзотичною альтернативою класичному project management. Чи захотілося розібратися, в чому ідеологічні та технологічні особливості даного підходу, і в чому, власне, революція методу? Прочитав кілька монографій. Чесно скажу, після першого знайомства особливої ​​глибини не розгледів. Методологія Скрам видалася дещо ангажованою та неконкретною.

При другому, більш ґрунтовному розгляді методу Скрам стали усвідомлюватися риси, які, на мій погляд, все-таки заслуговують на пильну увагу ділової спільноти. Звісно ж, що цей метод цікавий як для комерційно-виробничої сфери, але й інших інститутів нашого суспільства. Метод застосовний при проектуванні моделей освіти, НДДКР, державного та муніципального будівництва. Однак, як для будь-якого нового, важливо:

• виключити абсолютизацію та рецептурну бездоганність розглянутої технології;
• усвідомлювати, що метод Скрам ідеологічно сирий і може просто «не лягти на наш грунт» з його укладами та традиціями;
• бачити конфліктогенні точки, які несе у собі даний метод;
• розуміти, що метод Скрам вимагає прозорої ідеології держави та бізнесу щодо «правил гри» з персоналом, який бере участь у розвитку.

Чи сучасна парадигма управління проектами, міжнародні та національні стандарти (ANSI PMbok Guide, PM ICB IPMA, НТК) продуктом, який використовують споживачі: держава, її інститути, бізнес? Так звичайно. Які проблемні зони існують у сучасній проектній практиці, яка базується на робочій методології? Їх кілька, але основних дві: невиконання проектних термінів та перевищення бюджету проекту.

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

Ця властивість проектів особливо гостро проявляється у галузях, потребують інноваційного підходу. Метод Скрам (Scrum) здатний суттєво пом'якшити ці проблеми. На початку 2000-х років він став результатом праці двох новаторів Д. Сазерленда і К. Швабера (США). У своїй розробці автори методу використовували елементи теорії Х. Такеучі та І. Нонака, а також ідеї системи компанії Тойота (Тайїті Воно). І як революційний метод управління проектами модель Скрам вже отримала визнання у західних країнах, причому на сьогоднішній день практика його застосування не обмежена лише бізнесом.

Термінологія методу

Автори методу небезпідставно розкритикували класичну модель календарного планування проектів, що застосовується вже близько 100 років на основі підходу Г. Гантта. Дійсно, нічого не можна протиставити твердженню, що наочна діаграма Ганта, по суті, є одноразовою у використанні. Мало того, що робота над нею займає багато часу, практично відразу після початку проектних робіт каскадна модель в більшості випадків виявляється марною.

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

1. Власник продукту. Ця фігура відповідає за те, щоб командна робота дала результат, який приносить компанії прибуток (вигоди). Він повинен чудово розбиратися в суті продукту, можливостях команди та пріоритетах ринку.
2. Скрам-майстер. Метафорично це дуже цікава роль. "Лідер-слуга", "капітан команди", "тренер-коуч". Його головне завдання – вести команду шляхом безперервного вдосконалення, усуваючи перешкоди та причини перешкод.
3. Дошка Скрам. Звичайна офісна дошка, розділена на частини: «Белог», «в роботу», «в роботі», «на розгляд», «зроблено!». По ній переміщаються стікери, що наклеюються, із завданнями.
4. Збори Скрам. Підсумкові збори після завершення спринту.
5. Спринт. Тимчасовий період від 1 до 4 тижнів, що встановлює робочий ритм діяльності команди Скрам зі створення нової функціональності.
6. Наради на ходу чи щоденний Scrum. Короткі збори команди проекту для відповіді на запитання скрам-майстра про результати, плани на день та поточні перешкоди.
7. Беклог (баклог). Список поточних вимог до створення функціональності продукту проекту.
8. Діаграма вигоряння завдань. Діаграма, що показує кількість зробленої роботи, що залишилася в рамках поставленого завдання.
9. Послідовність Фібоначчі. Математична закономірність, властива природі нашого Всесвіту, коли діє особливий порядок чисел. Справжня послідовність добре застосовується для альтернативної оцінки тривалості виконання робіт проекту завдяки використанню так званого «покера планування». Нижче представлена ​​візуальна модель числової послідовності.
10. Сюхарі (Shu Ha Ri). Сюхарі – одна з концепцій японських бойових практик (наприклад, айкідо), яка увійшла до принципів методу Скрам як метафора можливості поетапного (ітераційного) досягнення досконалості команди проекту.
11. OODA. Принцип методу Скрам із циклічної реалізації: спостерігати, орієнтуватися, вирішувати, діяти.

Модель послідовності Фібоначчі

Базова модель методу Скрам. Джерело: Асхат Уразбаєв. Короткий огляд методології Скрам

Короткий опис процесу

Методологія Скрам хіба що занурює тканину реалізації проектної завдання досить жорсткий ритм циклічних спринтів. На відміну від стандартної проектної діяльності, у методиці вихідним посилом для планування є завдання (хоча завдання проекту не скасовується), а історії та факти, які допомагають зрозуміти цінності та потреби користувача, клієнта проектного продукту. Необхідно зрозуміти спонукальні мотиви, які викликають його потребу у продукті.

У класиці проектної діяльності подібна робота виконується на етапі розробки статуту проекту, але там вона значно формальніша. Тут же формуються деякі користувальницькі історії, лаконічні та зручні для подальшої фрагментації. Зверніть увагу, при традиційній декомпозиції проектних завдань відбувається їхнє граничне закріплення у форму сухої однозначності. У методі Скрам, навпаки, відбувається розкріпачення – щоб історії створили ціннісний образ проектного продукту.

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

1. Заповнення ролей команди Скрам.
2. Формування артефактів Скрам.
3. Реалізація активності.
4. Відтворення циклу Скрам.

Візуальна модель процесу методу Скрам

Склад ролей у методі Скрам простий: власник продукту, скрам-майстер та команда. У цьому порядку й виробляється вибір людей зазначені ролі. Найбільш близький до класичної ролі проект-менеджера власник продукту, він відповідає за формування та регулярну зміну беклогу продукту. Після формування беклогу команда проекту розпочинає планування майбутнього спринту. При цьому активно використовується «покер планування» як інструмент об'єктивніший і зважений, заснований на дельфійському методі та послідовності Фібоначчі. Таким чином формується локальний беклог на майбутній цикл нового спринту.

Під артефактами Scrum у методі розуміються: беклоги продукту та спринту, продукт проекту з новою функціональністю. Кожен спринт має на меті створення нової функціональності продукту, нехай незначного просування, але яке стане очевидним і може бути пред'явлене замовнику проекту та іншим заінтересованим сторонам. У внутрішньому середовищі циклу спринту команда діє автономно, що супроводжується «нарадами на бігу» та переміщеннями стікерів на дошці Скрам. Приклад зовнішнього вигляду дошки показано нижче.

Приклад дошки Скрам

Склад атрибутів дошки Скрам може відбивати специфічні особливості підходу компанії до проектування. Додатково можуть бути включені діаграми вигоряння завдань, декларація мети спринту тощо. Після завершення спринту проводяться два проектні заходи: оглядова нарада зі спринту та ретроспективні збори. Виходом оглядової наради є продукт проекту із зміненою чи повністю готовою функціональністю. Після ретроспективного аналізу виник список необхідних покращень у роботі команди Скрам. Цикл замикається, беклог продукту коригується. З нього «підтягуються» нові завдання та процес запускається знову.

Коментарі щодо заповнення ролей

Однією з монографій, з якими мені вдалося познайомитися, стала книга Д. Сазерленда, в якій Скрам презентується не інакше як революційний метод управління проектами. Праця рясніє масою прикладів з особистого досвіду автора, успішних проектних рішень та гучних імен. Емоційне забарвлення аргументації діє вражаюче. Загалом традиційний для північно-американської методологічної школи підхід. Незважаючи на трохи заплутану логіку, розібратися у методі проектування неважко. Хороша підмога є у Додатку. Перші три кроки технології цілком резонно присвячені ролям у команді Scrum.

Крок 1 алгоритму методології

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

• семантично грамотне трансформування ролі проект-менеджера у власника продукту, що з позиції NLP точно програмує лідера на результат проектної задачі;
• ранжування списку завдань (беклогу) проекту з цінностей (для клієнта) та ризиків;
• гнучкість у прийнятті зміни цінності товару для замовника проекту;
• бальна оцінка завдань та можливість заміни проектних завдань у ході перерозподілу пріоритетів та зупинки спринту.

Крок 2 алгоритму методології

Найбільш цінне методологічне посилення кроку 2, як на мене, – «звинувачувати безглуздо». "Золотий стандарт" чисельності команди Скрам також приймається без заперечень. Для певного типу культури команди проекту, наприклад, адхократичної або, в іншій класифікації, партиципативної, я цілком погоджуюсь із принципом автономності команди Скрам. Всі інші тези кроку 2 універсальні та ідентичні до класичного проектного підходу.

Крок 3 алгоритму методології

Перші вісім метафор наступного кроку Scrum цілком можуть розглядатися як правила ведення бізнесу або будь-якого іншого виду діяльності, включаючи проектну. Мимоволі запитуєш: а чому в реаліях проектної практики такого не вдається побачити? Вважаю, для відповіді на нього слід уточнити ще кілька моментів.

1. Якщо "лідер - не бос", а скрам-майстер - "гравець тренер", тоді хто управляє командою Скрам? Самоврядування, як на мене, не вкладається в концепцію проектного управління.
2. Виникає питання мотивації власника продукту проекту, скрам-майстра та команди Скрам. У методиці описано принцип відкритості інформації, включаючи доступ до фінансових даних проекту. Ідея непогана, але, враховуючи Макіавеллівську позицію, присутню в багатьох російських компаніях, така можливість серед керівників, напевно, матиме багато противників.

Питання формування артефактів

Наступні чотири кроки алгоритму методу Скрам присвячені формуванню та роботі з артефактами моделі. Під ними ми розумітимемо інформаційно-матеріальні об'єкти, які є відправною точкою для певного етапу активності, дій, що призводять до проміжного або остаточного результату проекту. Крок створення беклог продукту примітний своїми особливостями.

Головна з них полягає в тому, що цей перелік вимог Скрам не розглядається як щось разово знайдене та непорушне. Беклог продукту піддається динамічному переосмислення щоразу після закінчення спринту. І це дуже цінно, як на мене. Можу сказати із власної практики, що такого механізму не вистачає у класичній моделі проектного управління.

Крок 4 алгоритму методології Скрам

П'ятий крок алгоритму Scrum не менш цікавий. Цілком не хочеться занурюватися в містичні аспекти чисел. Але у нас з вами є рядове прагматичне завдання: найкраще скласти прогноз тривалості виконання робіт проекту, використовуючи найоб'єктивнішу експертну оцінку. На жаль, «ворожіння на кавовій гущі» з проставлення годинника в MS Project – немає нічого сумнішого і виснажливішого навіть із залученням знаючих експертів. Можу з упевненістю заявити, що кращого методу, ніж «покер планування», я в проектній практиці не зустрічав. Метод широко відомий, тож загострювати на ньому увагу не будемо. Зауважу лише, що поєднання методу Дельфі та послідовності Фібоначчі дає разючі результати.

Приклад пас'янсу методу «Покер планування»

Причин у тому, щоб розглядати метод Скрам не як тюнінг сучасної доктрини PM, бо як революційний метод управління проектами кілька. Одна з них – це відношення до опису роботи з виконання проектного завдання з позиції історій, що протилежне процесуальному підходу Д. Чампі та М. Хаммера. Люди справді мислять образами. З одного боку, важко погодитись з тим, що можна не боятися втратити однозначність трактування результату роботи. З іншого боку, якщо відволіктися від задачного тиску і поглянути питання з позиції справжньої орієнтації на клієнта проекту, «м'які» історії можуть дати більше отримання потрібних результатів завдань.

Крок 5 алгоритму методології Скрам

Розглядаючи кроки 5 і 6, механізми розрахунку динаміки продуктивності, беклог спринту, термінів закінчення проекту та можливості прискорення, не викликають сумнівів. Все досить очевидно. Труднощі в розумінні виникають щодо одного питання: як після кожного спринту домагатися наочного збільшення функціональності продукту? Щодо проектів розробки програмних продуктів таке цілком можливо. А як бути, наприклад, при реалізації проекту впровадження системи бюджетування методом Скрам, де багато етапів підготовчої роботи, на яких видимого приросту функціональності не відбувається? Звісно ж, що у цю частину методу потрібно додаткове занурення.

Крок 6 алгоритму методології Скрам

Питання активних дій у процесі

Третім процесуальним блоком методу Скраму є реалізація активностей. Під активностями ми розуміємо дії власника продукту, скрам-майстра та всієї команди Скрам для досягнення локальних результатів поточного спринту чи проекту загалом. Сьомий крок проектного процесу викликає неоднозначне ставлення. З одного боку, йдеться про цілком робочі інструменти колективної роботи, які забезпечують високий рівень гласності, комунікаційної наповненості, наочності. Йдеться про застосування дошки Скрам, стікерів, діаграм вигоряння завдань. З іншого боку, не тільки мені, а й багатьом російським управлінцям досить важко сприймати категорію щастя як елемент управлінської технології. Цьому питанню я далі присвятю цілий розділ статті.

Крок 7 алгоритму методології Скрам

Однією з явних знахідок методу Скрам я вважаю техніку щоденних нарад на ходу. Дуже лаконічний та дієвий засіб взаємодії та мотивації команди проекту всередині спринту. Великий спортсмен XX століття Мохаммед Алі надавав великого значення регулярному ритуалу для успіху в будь-якій справі. Щоденна нарада Скрам покликана бути тим потужним регулярним ритуалом, який підживлює консолідацію команди на короткий ривок. Коучингова підтримка, єдиний територіальний простір, відсутність поділу за «чинами та званнями» – все це працює на те, щоб команда Скрам діяла з прискоренням проектної реалізації.

Крок 8 алгоритму методології Скрам

На кроці 9 алгоритму методу Скрам проявляється те, що турбує та знову повертає до формулювання завдань на спринт. Протягом багатьох років мені доводилося виховувати у собі переконаність у тому, що задачний контекст проектного управління передбачає однозначність формулювання результату в розумінні «досягнуто – не досягнуто». При цьому немає значення, який результат розглядається: завдання верхнього рівня або декомпозованої. У будь-якому випадку постановник проектної задачі та відповідальний ресурс мають бути позбавлені можливості маніпулювати неконкретністю формулювання.

Крок 9 алгоритму методології Скрам

Цикл спринту завершується десятим кроком, у якому проводиться колегіальний ретроспективний аналіз закінченого спринту. Знову включається коучинговий режим взаємодії з командою Скрам під час оцінки ходу роботи над завданнями, пошуку покращень. Для російської ментальності завжди притаманні оціночні судження з негативним забарвленням невдалих результатів та зривів. При цьому завжди має бути позначений «стрілочник» – член команди проекту, з вини якого виникли втрати. Тим ціннішими є принципи примату системної помилки над діями учасників процесу Скрам як суб'єктів проектної активності та відмови від персоніфікації провини.

Крок 10 алгоритму методології

Скрам як код антицинізму

Мені імпонує представлена ​​у підзаголовку метафора. Вона належить Джеффу Сазерленду, і в ній відчувається глибоке переживання цинізму як значної вади сучасного бізнесу. У цілому нині позиція автора методу Скрам, безумовно, щира. Це підкуповує. І, в принципі, дуже непогано, що Сазерленд вводить в управлінський контекст компонент щастя. Подібне робиться так американською. Разом з тим, хотілося б розібратися, чому слово «щастя», і все, що з ним пов'язане в революційній проектній доктрині, що розглядається, викликає внутрішній дискомфорт. Чи це суб'єктивно-особистісне сприйняття, чи це певний загальний культурологічний погляд на запропонований підхід?

Ми з вами, швидше за все, пам'ятаємо, що відбувалося в Росії наприкінці 90-х – на початку 2000-х років. У країну буквально ринули «новоявлені нувориші» з усіх куточків світу, і в основному зі США, які ведуть мовлення «правди» про особисту та корпоративну успішність. Треба чесно сказати, що подібні «одкровення» не пройшли безвісти, багато бізнесменів взяли на озброєння ключові аспекти теорій управління, що привезли із Заходу. Я спеціально не називаю тренінгові курси, авторські теорії та імениті школи. Хто з ними стикався, зрозуміють.

70 років Радянської влади сильно змінили внутрішню культуру людей, але генетичний код російської людини не було втрачено остаточно, оскільки формувався століттями. Проте, коли відкрилися найширші можливості комунікацій та ділових відносин, у бізнесменів та управлінців природні фільтри виявилися зірваними. І багато ідей виявилися прийнятими як аксіоми, при цьому принципи елементарної мудрості застосовані не були. Це витрати міжчасу, що зараз завершується.

Відбувається швидке протверезіння і на рівні держави, і на рівні ділових людей. І вони починають розуміти, що деякі рішення, способи ведення бізнесу, побудови відносин з персоналом не просто корисні, вони служили ворожим і руйнівним цілям, що призводять до ломки нашої національної культури, у тому числі культурі господарювання. Я наведу один єдиний приклад протиставлення двох ідеологем: "Поділяй і володарюй!" і «Купецьке слово дорожче за договір!».

Ось цей протверезіння і є причиною дуже обережного ставлення до нав'язування ресурсу щастя як засобу управління. У російській традиції з його багатовіковою общинністю, православним та ісламським корінням «щастя» відноситься до високодуховних, чеснотних категорій. Воно не може не розглядатися комплексно з позиції морального аспекту, з погляду психологічного стану, з ракурсів інтелектуального осмислення, фізичного та душевного піднесення.

Сказане вище анітрохи не применшує переваг розглянутого у статті методу Скрам. Якщо прибрати вуаль абсолютизації, недомовленості та деякої патетичності, це цілком робочий для проектування інструмент. Нове завжди непросто пробиває собі дорогу. Спочатку це високі ідеї, потім це поодинокі приклади нарешті настає період масового прийняття. Звісно ж, майбутнє за гібридними алгоритмами ведення проектної діяльності та гнучкою варіабельністю застосування традиційних і революційних підходів.