Agile помер, хай живе... Agile

За останні кілька років гнучкі методології майже витіснили традиційні способи розробки – повністю за принципами Agile зараз працюють дві третини IT-компаній. Чи справдилися очікування, які виникають проблеми і куди все рухається? Пропонуємо аналіз існуючого російського і зарубіжного досвіду роботи з Agile і відповіді на ці питання.

Незважаючи на те, що Agile з'явився близько 20 років тому, більш-менш активно застосовувати його почали лише протягом останніх восьми років. Гнучкі принципи виникли як альтернатива традиційним методам розробки з метою зменшення витрат на виробництво, готового для відправки замовнику (potentially shippable software), за рахунок підвищення ефективності спільної роботи і клієнтоорієнтованості. Тобто набір принципів формувався під вирішення завдань бізнесу – для прискорення процесу розробки та досягнення максимального результату від команди без збільшення витрат на виробництво.


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

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

Традиційно метою Agile був перший етап розробки – написання коду. Наприкінці далеких 90-х саме цей етап розглядався як потребує поліпшення і серйозних змін. Тоді ж отримала популярність одна з найбільш поширених імплементацій Agile — Scrum. Справедливості заради варто відзначити, що Scrum вийшов у світ в 1986 році, за 15 років до того, як був адаптований для Agile в 2001 році.

Scrum приносить вибірку того, що потрібно писати, дозволяє відстежити процес розробки, виявити недостачі і суперечності на початкових етапах. Без технічного завдання програміст не знає, який саме продукт має вийти в результаті. Наприклад, якщо мова йде про Google або Facebook, то у розробників того або іншого сервісу питань не виникає. Вони роблять продукт для себе — самі є його завзятими користувачами і розуміють, що і як має виглядати і що потрібно зробити, щоб новий функціонал був зручним. Інша справа, наприклад, система білінгу. Програміст не знає того величезної кількості нюансів, які необхідно врахувати для коректної роботи сервісу регуляційних, так і маркетингових, як, наприклад, різні моделі розрахункових операцій.


Піонерами Agile були маленькі компанії, які не боялися застосовувати передові технології – їм нічого було втрачати ще! Зі зрозумілих причин написання коду в подібних організаціях становить основну частину процесу (процеси підготовки і запуску практично відсутні). Ефект був приголомшливий! Однак через кілька років застосування традиційного Agile у більш розвинених організаціях стали помічати, що проблеми, пов'язані із скороченням випуску на ринок нових продуктів, не зникли. Agile пересунув затор на наступний етап – на підготовку до випуску нового продукту. Тоді ж, у середині першого десятиліття 2000-х, поняття Agile було розширено і стало збірним, на відміну від початкового значення, орієнтованого тільки на перший етап розробки.

З метою підготовки написаного коду для потенційного випуску з'явився Continuous Delivery. Варто звернути увагу, що випуск не обов'язково відбувається відразу, а може бути затриманий, наприклад, для прив'язки до певної дати у відповідності з бізнес-цілями. Такий підхід дозволяє досягти злагодженої роботи команди, автоматизувати всі процеси і підвищити швидкість потенційної відправки коду в продакшен. Однак якість продукту гарантується тільки за рахунок автоматичних тестів, так як приймальні перевірки не справляються зі швидкістю постачання коду і часто використовуються як формальний етап. Звичайно, сьогодні такі автоматичні тести окремих компонент, написані часто самими розробниками, забезпечують правильне виконання коду. Але ні сама методологія, ні якісь існуючі сьогодні інструменти не забезпечують коректну роботу коду в більш складному середовищі – продакшені. Крім того, не факт, що код буде виконувати необхідні замовнику функції і вирішувати поставлені завдання.



Наприклад, у липні 2015 після чергового оновлення були зупинені торги на Нью-Йоркській фондовій біржі. Цей збій струсонув світову економіку, зокрема, знизив на 1% фондовий індекс США на весь день, а також загальмувала переговори Греції з її кредиторами на цілий тиждень! Ще один яскравий приклад – оновлення системи продажу авіаквитків в компанії «Дельта». Після випуску нового в продакшен інформація взагалі перестала надходити в диспетчерську службу. В результаті авіакомпанія скасувала всі рейси і понесла істотні фінансові та репутаційні втрати. Безсумнівно, що в обох випадках багато хто перевірки перед запуском були пройдені і, тим не менш, ще багато були б зроблені, якби займали менше ресурсів і часу.

Пробіл із забезпеченням якості коду сьогодні дуже актуальне і він буде поступово заповнюватися. За оцінками Gartner, в найближчі три роки принаймні 75% IT–корпорацій будуть змушені розвинути автоматичне тестування, інтегруюче бізнес-процеси. Певні надії на вирішення проблеми якості покладаються на такі технології і методології, як контейнери і BDD (behavior driven development) – Docker, Огірок та інші.

В кого це працює?
На сьогоднішній момент принципи Agile імплементовані в більшості компаній, де це було можливо зробити без особливих ризиків для бізнесу. І всі, хто зміг вибудувати нові процеси, в цілому задоволені результатами, наприклад: Google, Zara, Ikea. Однак варто звернути увагу, що ці компанії діють за принципом «розділяй і володарюй» — тобто робота розділена на проекти, якими займаються відносно невеликі самостійні команди. Крім того, за Agile в цих компаніях працює в першу чергу бізнес-підрозділ (особливо це стосується Zara і Ikea), а не тільки відділ розробки. Вони змінили не тільки організацію процесу, але і бізнес, тому природним чином відповідають Agile-моделі.

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



Тобто в тих областях, де ціна помилки дуже висока, компанії поки побоюються щось міняти. Так, вони розуміють, що Waterfall себе зжив і, працюючи по-старому, можна в якийсь момент залишитися далеко позаду від конкурентів і все втратити. Вони б і раді перейти на нові методи роботи, але поки ризики набагато вище, ніж потенційна вигода від нововведень. Крім того, найчастіше необхідні великі інвестиції, щоб перевести бізнес на гнучкі методології і далеко не факт, що всі відразу запрацює добре. Це стосується в першу чергу тих компаній, де більшість бізнес-процесів побудовано на ПО, написаному десятки років тому на мовах програмування, не настільки модулярних, як Java, Scala, GO та ін

Але ті компанії, які намагалися впровадити Agile і не отримали очікуваних результатів, все більше і більше виявляють невдоволення. Їм обіцяли, що після імплементації гнучкої методології ККД збільшиться, а time-to-market і разом з ним витрати на виробництво зменшаться. Проте очікуваного ефекту не виникає, так як код виходить швидше і все більше і більше проблем з'являється на просунутих етапах розробки. ККД в деяких випадках підвищується, однак помітного скорочення витрат не відбувається. Але найчастіше трапляються відкати з продакшену, які б'ють по часу досягнення цілей, б'ють по time-to-market і коштують дуже дорого, так як виправлення багів в продакшені вимагає набагато більших витрат ресурсів розробників. Ціна помилки зростає не тільки з-за пізнього виявлення, але і з-за високої швидкості розробки. Цей ефект можна порівняти з турбулентністю у потоках, коли швидкість потоку перевищує максимально допустиму для даного середовища.

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

Як підвищити ефективність?
Хмари дуже активно розвивалися в останнє десятиліття і частково відкрили шлюзи для проведення тестування у великих масштабах. Однак проблема повністю не була вирішена – незважаючи на всі переваги, хмарні технології щодо дороги. Крім того, не завжди просто побудувати необхідні середовища перевірок cloud. Сьогодні, в середньому, кожному розробнику необхідно 10 середовищ — таким чином ціна середовища може зрівнятися з бюджетом оплати праці самого розробника.



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

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

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

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

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


Таким чином, щоб підвищити Agile-ефект, необхідно в першу чергу реалізувати дві умови:

1. Поява можливості для запуску бізнес-тестів без особливих витрат,
2. зсув інтегрального і бізнес-тестування як можна ближче до джерела змін.
І, звичайно ж, потрібні ефективні рішення для моніторингу якості роботи додатків в реальних умовах.

Коли настане «золотий вік» Agile?
З початку свого існування Agile перевтілився з набору принципів в асортимент методологій, процесів і навіть стандартів. Сьогодні поле діяльності цих методологій не обмежена командами розробників. Гнучкі процеси успішно впроваджуються практично у всі відділи IT і навіть бізнес керується стандартами Agile. Серед найбільш відомих можна відзначити Scrum, Scrumban, SAFe, ScaleAgile@Spotify, Continuous Delivery, Lean, Prince2 Agile і багато інші.

Незважаючи на багато фреймворки та методології, які в рамках Agile претендують на лідерство і заявляють про рішення всіх проблем і знятті всіх бар'єрів, якість залишається головним шлюзом перед беззаперечним перекладом на Agile всіх відділів та етапів розробки IT-корпорацій. Існування цього шлюзу є причиною недовіри до Agile і спробою виправдати збереження принципів каскадної моделі або Waterfall. Також відбуваються спроби змінити Agile за допомогою впровадження традиційних етапів тестування.

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



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

Вирішивши цю проблему, у наступні 5 років гнучкі методології відкриють собі шлях в решту корпорацій, які до тих пір не наважаться переводити розробку на більш сучасний, але ризикований лад.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.