Agile чи не agile – чи доречне це питання?

Agile

Здається, що питання у заголовку щодо “agile” (гнучких) методів, які використовуються в управлінні проектами, спричинить  здивування, а можливо навіть протести вже на початку. Адже якщо не “Agile”, то що? Зрештою, “agile” вже названо сенсаційним засобом вирішення всіх проблем управління проектами і протиставлено традиційним підходам, що базуються на так званому „waterfall”.

Вважається, що “традиційні” методики, такі як PRINCE2, дуже важкі і їх неможливо використовувати в організації, тому від них треба відмовитися. На противагу способу „agile”, який, загальноприйнято вважати таким, що  може бути впроваджений в організацію без особливих зусиль, і який повинен призвести до ефективного виконання проектів. Останнім часом з’являється чимало голосів на зустрічах, лекціях, в Інтернет-виданнях та в пресі, які, за принципом аргументів ad ignorantum, заохочують використовувати „agile” і лише „agile”. Треба визнати, що ці обіцянки про легкі успіхи захоплюють багатьох, в тому числі фахівців ІТ, для яких важливим є покращення співпраці з “бізнесом”.

Не декларуючи a priori свого ентузіазму, я застосую принцип Amicus Plato, sed magis amica veritas (який постулює, що незалежно від обставин треба говорити правду). Для вирішення дилеми, що зазначена у назві потрібно відповісти на кілька допоміжних питань:

  • Що таке „agile”?
  • Де ми можемо використовувати „agile”?
  • Чи існують методи, що базуються виключно на  „waterfall”?
  • Чи доречим є питання внесене у назву?

Що таке „agile”?

Немає єдиного формального визначення „agile”. Такого визначення не створили навіть спеціалісти, які стикалися з проблемами у “традиційних” проектах, пробували застосовувати нові “гнучкі” підходи і зустрілися кільканадцять років тому, аби обмінятися досвідом і сформулювати знаменитий “Agile Manifesto”, який розпочав справжню революцію „agile”.

Дехто вважає, щоби бути „agile” (“гнучким”) достатньо використовувати такі цінні методики, як щоденні зустрічі команди (англ. Daily stand-ups), записування вимог у вигляді так званих історій користувача (англ. User Stories), встановлення пріоритету вимог та оцінка робочого навантаження за допомогою карт „Planning Poker”.

Проте, я підтримаю ті твердження, які визнають вищезазначені методи лише допоміжними. Agile – це також трохи інший стан мислення (англ. mindset). Характерними особливостями управління в стилі „agile” є:

  •  Прозорість (англ. transparency) – загальне бачення діяльності команди, її план дій та досягнутий прогрес
  • Перевірка та адаптація (англ. inspection and adaptation) – що означає часте проведення оглядів способу роботи, засвоєння уроків та негайне внесення покращень для подальшої роботи, а також передача команді важливих пропозицій щодо вдосконалення робочого процесу (наприклад, вдосконалення методології управління проектами в організації)
  • Тісна співпраця з клієнтом (англ. close work with a customer) – це означає, що ми створюємо одну команду, до складу якої входять як учасники зі сфери бізнесу, так і з технічної сфери, які мають співпрацювати для досягнення спільної мети. Це означає, що в проектах “agile” не може бути так званих ІТ-команд, відгороджених муром від бізнес-користувачів або відділеної команди зі сторони зовнішнього виконавця.
  • Рішення щодо деталей відкладаються якомога довше (англ. decisions about detail deferred as late as possible) – це означає, що до детальних вимог приходимо у процесі розробки проекту, і не очікуємо, що хтось зможе надати нам список деталей вже на початку роботи
  • Робота виконана вчасно (англ. delivery on time) – це означає відсутність згоди на відтермінування кінця роботи, яка повинна бути виконана вчасно. Можливо, ми відмовимося від менш важливих вимог, щоб забезпечити ті, які мають найбільше значення для бізнесу, але завжди вчасно
  • Часті оперативні втручання (англ. frequent deployments) – це означає, що ми плануємо роботу так, аби за можливістю частина варіантів почала працювати якомога швидше, а не тільки як повне рішення в кінці. Це дає швидку вигоду з проекту та можливість використання відгуків користувачів про проміжні рішення в подальшій роботі
  • Остаточне рішення відповідає потребам бізнесу (англ. final solution actually meets business need) – це однозначно визначає, що всі проекти є бізнесом, фінансуються та вирішуються бізнесом. Не повинно існувати проектів, які повністю реалізуються в межах технічних відділів, які підтримують бізнес (наприклад, проекти відділів ІТ), що зосереджуються виключно на продуктах та технічних аспектах, поминаючи інші продукти, необхідні для ведення бізнесу.

“Agile” – це стиль управління, який призначений дати відповіді на проблеми, що спостерігаються в традиційному підході званому „waterfall”. „Waterfall” характеризується визначенням деталей ще перед проектом, опором до зміни вимог під час виконання проекту, впровадженням усіх напрацювань операційної діяльності лише наприкінці проекту, відсутністю постійної співпраці з користувачем, який зазвичай невдоволений і зголошує багато дорогих змін, оскільки лише наприкінці проекту він може ознайомитися з рішенням. Все це призводить до постійних затримок у реалізації більшості проектів.

На малюнку нижче порівнюються ці два стилі: „agile” і „waterfall”.

agile or waterfall

Де ми можемо використовувати „agile”?

Проте, коли ми приймемо прийняті раніше характеристики стилю „agile”, представленого раніше, ми зрозуміємо, що застосування „agile” набагато ширше, ніж проект або команда, і завжди в повному зв’язку з бізнесом. Ось карта управління P3 (англ. P3 governance) для кожної організації: малої, середньої, великої або такої ж великої як вся країна. P3 означає пакет, програми та проекти.Багато хто вважає, що „agile” застосовується лише для проектів або управління командою у проекті. Дехто вважає, що метод „agile” можливий лише для проектів, пов’язаних з розробкою програмного забезпечення.

Кожна організація реалізує свою стратегію, використовуючи традиційну діяльність (ang. business as usual), званий по-іншому рутинною (звичайною) або операційною діяльністю, де досягаються прибутки. Це саме традиційне ведення бізнесу  потребує змін, метою яких є адаптація до мінливої стратегії, надолуження чи випередження конкурентів, будь-які вдосконалення. Ось чому в організації ми маємо ініціативи змін, які постають у вигляді програм і проектів, разом створюючи запланований пакет ініціатив. Проекти можуть бути незалежними або включеними в програми. Однак організація кожного проекту може включати в себе одну або декілька команд, які надають спеціалізовані продукти (наприклад, ІТ, маркетинг тощо). Управління командою, проектом, програмою та пакетом є сферою порядку кожної організації.

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

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

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

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

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

Читач може здивуватись, побачивши тут наявність посібників визнаних так званими “традиційними” та „waterfall”, такі як MoP (Management of Portfolio), MSP (Managing Successful Programmes) та PRINCE2 (Projects in Controlled Environments), порівняними з методологіями „agile”.

Однак, коли ми приймаємо раніше описане розуміння „agile” як стилю управління, ми погодимось, що визначення трохи більш старих підходів, як „waterfall”, просто неправильне. Особливості управління в стилі „waterfall” не вбудовані в жодну методологію. Кожна з них може використовуватися в спосіб і як  „waterfall”, так і „agile”. Наприклад, ніщо не перешкоджає в тому, щоб використовуючи класичні PRINCE2 або PMBOK як основи підходу до управління проектами, доповнювати їх гнучкими елементами. Для PRINCE2 розроблено спеціальний посібник, як використовувати цей метод способом „agile”  (так званий PRINCE2 Agile).

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

Запрошуємо на тренінг AgilePM®&AgileBA® Foundation https://tot.com.ua/product/agilepm-and-agileba-foundation/

Чи доречним є питання винесене у назву?

Якщо читач погоджується з більшістю висловлених тез, то питання про те, чи використовувати „agile” чи не використовувати „agile”, скоріше не буде правильно поставленим питанням.

Конструктивна дилема Керівника проекту та команди – “Які елементи цього проекту та нашої роботи можуть бути „agile”?”, “Наскільки ми повинні бути „agile” у цьому проекті та роботі?”, а не про те, чи використовувати гнучкість взагалі.

Роздуми про ступінь застосування гнучкості є постійною складовою адаптації кожної методології, як “традиційної” (наприклад, PRINCE2), так і більш „agile” (наприклад, AgilePM) до середовища даного проекту, що є обов’язком керівника проекту. Не завжди всі аспекти проекту можуть бути „agile”. Іноді деякі аспекти просто повинні залишатися “традиційними”.

Наприклад, підходи „agile” пропонують, де це виправдано, часто переносити навіть частину створюваного рішення до операційної діяльності. Це може бути корисним для програмного забезпечення, але чи це буде корисним при побудові ракети на Місяць? Неможливо запустити частину ракети, потім іншу частину і т. д. Проте, будуючи окремі ракетні частини, ми можемо часто виконувати тести, робити презентації серед об’єднаної команди, яка співпрацює між собою і яка намагається завершити кожен елемент роботи вчасно, застосовує пріоритети та ефективно реагує на необхідні зміни.

Саме тому підхід „waterfall” не завжди є недоцільним. Можна навіть ризикнути ствердити, що метод, пристосований до конкретного проекту, являє собою сукупність елементів „agile” та „waterfall”.

Отже, пора підбити підсумки:

  • “Agile” – стиль управління, який можна використовувати на всіх рівнях управління організації.
  • В підходах „agile” існує величезна сила і цінність для організації.
  • Протиставлення „agile” з традиційними методологіями проектів, такими як PRINCE2, є абсолютно невиправданим.
  • “Agile” не реалізує себе сам, оскільки він повинен бути офіційно прийнятий та впроваджений в організації.
  • “Agile” на будь-якому рівні управління може ефективно функціонувати лише у зв’язку та гармонії з вищим рівнем управління.
  • Кожна методологія управління проектами не може бути застосовувана механічно, але адаптована до кожного проекту з питанням про те, що і на скільки може бути „agile” у цьому проекті.

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

Тому нехай „agile” буде обдуманим. Нехай дискусії про „agile” на всіх рівнях управління супроводжуються ентузіазмом, але завжди з певною конструктивною відстороненістю.

 Кшиштоф Малус

Провідний тренер та консультант OMEC (www.omec.eu) у сфері побудови пакетів, програм та проектів (P3O). Більше десяти років він керує проектами  в компаніях з телекомунікацій, ІТ та медіа галузі, а також в державному управлінні. Акредитований тренер PRINCE2®, AgilePM®, MSP® та P3O®, сертифікований менеджер проектів та програм. Перекладач польської версії посібника P3O® – Офіси пакетів, програм та проектів.

Залишити відповідь

X