Стане SAFe галузевим стандартом в Enterprise Agile?

6 травня 2014 року Scaled Agile, Inc. був названий фіналістом 2014-го року у номінації Red Herring Top 100 в США. Ця новина стала цілком очікуваною для фахівців у Enterprise Agility і для консалтингових фірм, що надають послуги в організаційній трансформації компаній. Причина цього проста — потреби ринку серйозно змінилися.

Ряд глобальних компаній, таких, як ING, TomTom, T-Mobile і IBM вже давно проявляють інтерес до SAFe. Швейцарські компанії Swisscom, SwissPost, Kuoni і Credit Suisse також успішно впроваджують SAFe силами власних сертифікованих і зовнішніх консультантів.

Невирішена проблема

Однією з причин стрімкого поширення Scaled Agile Framework'a (SAFe) є фіаско, яке зазнали гнучкі підходи щодо управління розробкою ПЗ в очах програмних менеджерів і VP великих компаній. Незважаючи на умовне відповідність цінностям і принципам з Agile Software Development, більшість все ж прагнуло до передбачуваності строків поставки продукту і перевіреному підході, який можна «розгорнути» для R&D відділу у кілька сотень, а то і тисяч людей.

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

Уявіть на мить, що вам потрібно пов'язати між собою випуск портфоліо з більш ніж 20 продуктів, кожен з яких має 5-10 ключових stakeholder'ів, розробляється 4 різних країнах силами 7-10 команд. Завдання такого рівня змушує напружитися навіть дуже досвідчених CTO або VP по розробці.

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

SAFe лікнеп

Витонченість SAFe і його ключова перевага для великих компаній, полягає у виведенні простою і прозорою організаційної структури в парі з чіткою моделлю розподілу відповідальності. Обидві ідеї корінням йдуть в RUP (Дін Леффингвелл, автор SAFe, відповідав за розробку та комерціалізацію RUP в Rational Software).

Модель SAFe розбиває будь-яке підприємство на три рівня: портфеля, програми і команди, а модель управління SAFe представлена двома вертикалями:

1) вертикаль «контенту» (що компанія буде випускати) продукту, яку представляють команда менеджерів продукту, UX і Архітектори
2) вертикаль «поставки» (Яким чином компанія буде випускати продукт на ринок) в особі проектних і програмних менеджерів.

image

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

Самий сік криється у запуску Agile програм

Підприємства запускають програми для створення програмних продуктів, платформ або послуг. Таким чином, різні види проектних офісів (PMO) покликані підтримати виконання програм найбільш ефективним способом.

Підходи, начебто Scrum, принесли «важкі часи» для різного роду PMO. Класично, ініціативи від бізнесу, сформовані на рівні портфеля, знаходили своє вираження у вигляді проектів, для яких створюються окремі, тимчасові проектні команди. Безперервне створення проектів під потрібні чергової ініціативи від бізнесу відбувається при яскраво вираженій компонентній структурі організації (тобто команди, які відповідають за фічу, технологічний пласт, або компонент системи).
Scrum ж почав «вимагати» від керівників PMO домогтися крос-функціональності на рівні фіксованих команд, склад яких не змінюються протягом 6-12 місяців. Це і стало для багатьох компаній каменем спотикання в переході на Agile-рейки.

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

Уявіть собі групу, що складається з 5-7 чоловік: розробники, QAs і DevOps працюють над конкретними компонентами платформи (або представляють команду, що працює над окремими функціями програмного продукту: функціональні команди). Припустимо, платформа має ще 5-7 компонентних команд, які організовані подібним чином. Всі команди синхронно працюють, використовуючи 2-х тижневі спринти і цілком передбачувано постачають робочий функціонал після кожного спринту. Тепер, уявіть собі, що кожна ваша команда це «супермен». Якщо ви об'єднаєте всіх ваших «суперменів» в одну команду — ви отримаєте команду, яка охоплює всю платформу. А що, якщо ми запустимо Agile процес розробки для нашої “команди суперменів", але в більшому масштабі? Так як кожен «супермен» здійснює поставку кожні 2 тижні тривалість нашій ітерації (циклу) буде 2-3 місяців

Давайте призначимо менеджера продукту (ака супер Product Owner) і менеджера керуючого поставкою (ака супер Scrum Master) в нашу команду. Команда суперменів робить планування і бере на себе зобов'язання на початку ітерації, визначає і вирішує залежності між «суперменами». Щотижневі (або раз в два тижні) зустрічі (ака Scrum of Scrum) мають важливе значення для синхронізації «команди суперменів». В кінці 2-3 місячної ітерації, команди робить демонстрацію результатів роботи та виробляють ретроспективу для поліпшення своєї роботи у майбутньому. А тепер давайте знову повернемося назад і перетворимо індивідуальних «суперменів» в компонентні команди або команди працюють над окремою функцією. Таким не хитрим способом, ми тільки що створили шар програмного менеджменту в Agile стилі.

image

Гхм, пробачте, а що з архітектурою?

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

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

Беручи до уваги все вище сказане, SAFe пропонує концепцію, яка називається «Архітектурне русло» (Architecture runway). Насправді, в цьому підході немає ніякої магії — він заснований на простій логіці. Команда відповідальна за архітектуру, працює, принаймні, на один дво-тримісячних цикл попереду інших команд, створюючи архітектурний заділ для функціональних / компонентних команд, який дозволить ефективно розробляти бізнес функціонал під час наступних циклів.

image

Такий підхід пов'язує архітектурну команду з вертикаллю управління контентом і вирішує дилему, яка, здається, завжди існують на підприємствах: кому підпорядковується архітектурна команда: продуктовим менеджерам або менеджерам, відповідальним за поставку продукту?

Резюме
Стаття виявилася довшою, ніж ми від початку планували, тому завершуємо її коротким резюме з основних ідей по Scaled Agile Framework (SAFe):

  • чітке розділення двох вертикалей відповідальності (контент і постачання)
  • чіткий поділ рівня команд, рівня програм (спільні зусилля кількох команд) і рівня портфоліо (продукти / глобальні ініціативи, які випускають команди)
  • спільне планування командами програм в 2-3 місячні цикли
  • виділення архітектурного русла для опрацювання функціональності наперед.
Яких результатів чекати

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

Автори SAFe говорять про такі результати, посилаючись на своїх клієнтів:
  • Скорочення часу виходу продукту на ринок на 27 тижнів
  • Збільшення задоволеності клієнтів на 25 відсотків
  • Скорочення витрат на розробку продукту на 50 відсотків
Наш досвід більш скромний, і тим не менше, ряд клієнтів, шляхом впровадження принципів із SAFe підходу говорять про скорочення часу на випуск продукту на ринок до 20 відсотків, а також відзначають зрослу ступінь прозорості та керованості процесу, більше задоволення співробітників.

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

Джерело: Хабрахабр

0 коментарів

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