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” характеризується визначенням деталей ще перед проектом, опором до зміни вимог під час виконання проекту, впровадженням усіх напрацювань операційної діяльності лише наприкінці проекту, відсутністю постійної співпраці з користувачем, який зазвичай невдоволений і зголошує багато дорогих змін, оскільки лише наприкінці проекту він може ознайомитися з рішенням. Все це призводить до постійних затримок у реалізації більшості проектів.

Продовження статті за посиланням: https://tot.com.ua/uk/agile-chi-ne-agile-chi-dorechne-tse-pitannya/