Вклад у статтю Аушри Густайнєне Відкриття #Agile способу виконання проектів SAP та статтю Діани Голд “Їдять слона на шматки” або Надання комплексного рішення SAP, будучи # Agile. Рішення SAP.
Урок 1 – Бізнес повинен мати спеціальну команду для управління змінами та консолідації вимог.
ТОЧКА НАВЧАННЯ: Ми розпочали свою базову розробку таким чином, що “ІТ задають питання на основі стандартної функціональності та різних сфер власники бізнесу надають детальні вимоги”. Результати семінарів показали, що різні вимоги зацікавлених сторін не відповідають. Стало очевидним, що хтось у бізнесі повинен взяти на себе відповідальність за вирівнювання, перш ніж перейти до ІТ.
ДІЯ: Після цього підтвердження ми створили віртуальну “Команду з питань бізнесу” у проекті та зосередили відповідальність E2E (з кінця в кінець) у цій команді.
Команда має дві основні сфери – розвиток та управління змінами.
Сторона доставки – Власники продуктів та бізнес-аналітики дотримуються гнучкої методології – готують бізнес-вимоги до майбутніх спринтів.
Змініть фокус управління на впровадження результатів розвитку в бізнес.
РЕЗУЛЬТАТ: Концентрована відповідальність в одній команді пришвидшує надання вимог ІТ-командам та підвищує якість бізнес-вимог. Вчитись одне в одного стало легше. Також ми централізували провідні ролі в управлінні змінами в одній команді та збільшили узгодженість їхніх дій. Вимоги почали надходити у форматі історії користувачів, включаючи критерії прийняття.
Урок 2 – Недостатньо узгодити вимоги, встановити мету, щоб скласти уявлення про те, як бізнес працюватиме в майбутньому, і відстежувати його.
ПУНКТ НАВЧАННЯ: після декількох випусків команди бізнесу та ІТ почали по-різному оцінювати прогрес у виконанні. Команди почали ділитися повідомленнями на кшталт “Бізнес змінює вимоги” або “ІТ не виконує узгодженого”. Пояснити обсяг і скласти план стало важче. Після RETRO ми побачили, що команди по-різному бачать кінцевий пункт призначення проекту.
ДІЯ: ми погодились мати бізнес-бачення високого рівня у форматі #backlog, щоб мати змогу вирівнювати та вимірювати прогрес. Тут ми почали використовувати деякі практики “ВОДОПАДУ”, щоб мати кращу участь та контроль.
Подальші дії, починаючи з рівня випуску, ми плануємо в Agile: розріжте на частини необхідну функціональність для випусків, визначивши пріоритети, підготуйте Історії користувачів та спільно з ІТ-командами плануйте спринт.
РЕЗУЛЬТАТ: порівняння результатів доставки з кінцевим пунктом призначення перед випусками дозволить виміряти відсутні функції та залишені прогалини. Бізнес вкладає більше часу на підготовку, але загалом ми стаємо швидшими в підготовці бізнес-архітектури та ІТ-рішень. Тож практики Водоспаду в поєднанні з Agile додали нам більше впевненості у проекті.
Урок 3 – легко втратити почуття власності зацікавлених сторін у бізнесі завдяки концентрованій компетентності в команді, що займається зміною бізнесу.
ТОЧКА НАВЧАННЯ: ми почали відчувати, що зацікавлені сторони у бізнесі хочуть зменшити свою участь у проекті та залишатись у позиції, що ділиться “функціональними мріями – баченням”. Водночас, займаючись звичайною справою, вони знаходились у водійському положенні. Ми зіткнулися з необхідністю посилення власності бізнес-контрагентів у проекті. Ми прагнули поінформувати їх про прогрес у програмі Спринти.
ДІЇ: Ми почали регулярно проводити сеанси аліментів «Рада з питань бізнесу». Його роль полягає у вирівнюванні архітектури бізнесу, змін, оцінці нових вимог, визначенні пріоритетів та вимогах, розділених на Випуски. Ескалації, плани дій, оцінка ризиків також є частиною цієї події. Власник продукту відповідає за запрошення необхідних зацікавлених сторін бізнесу на основі тем обговорення.
РЕЗУЛЬТАТ: Зацікавлені сторони бізнесу почали порівнювати свої щоденні дії з обсягом проекту та бізнес-баченням, намагаючись уникати прийняття рішень, які не відповідають архітектурі бізнесу. Вони також зацікавились Історіями користувачів та критеріями прийняття.
Урок 4 – кожен повинен знати про WoW команди, що займається зміною бізнесу, функції та обов’язки, якщо ви хочете забезпечити ефективність.
ПУНКТ НАВЧАННЯ: Деякі зацікавлені сторони в бізнесі почали звертатися за підтримкою безпосередньо до служб доставки ІТ, щоб планувати дорожні карти своїх областей. Вони хотіли навчитись користуватися рішенням, читати архітектурну документацію та підвищувати свою обізнаність.
ДІЯ: було досягнуто домовленості про виділення власника продукту (PO) від групи з питань бізнес-змін для кожної команди зацікавлених сторін у бізнесі. Роль замовлення полягає в тому, щоб ділитися спринтами та планами випусків, підготовленими історіями користувачів, узгоджувати необхідні зміни та залучати представників бізнесу до процесу управління змінами: навчати, розвивати компетентність суперкористувачів, рішення про передачу бізнесу.
РЕЗУЛЬТАТ: у нас зростає кількість користувачів бізнес-вечері, які знають, як використовувати рішення, навіть до офіційного його запуску. Зацікавлені сторони бізнесу підвищили якість своїх вимог і знають, хто є їх SPOC з будь-яких питань, пов’язаних із проектом, нові вимоги надходять до Власника продукту для оцінки.
Висновок
Поєднані методології управління проектами #Waterfall та #Agile та посилення управління зацікавленими сторонами допомагають нам підвищити якість команди бізнесу, а також позитивно впливають на мотивацію та продуктивність. Я продовжую співпрацювати зі своєю командою у цьому підході, і незабаром ми матимемо можливість побачити, наскільки швидко ми можемо бути разом із командами доставки. Все-таки це довгий шлях і вдосконалення того, що ми робимо, але ми вже бачимо гарний прогрес.
Тож відповідаючи на мій заголовок статті: “Чи повинен бізнес формувати своє бачення в # водоспад, а доставляти в # гнучкі?” – Я б сказав ТАК.
Я в хорошому становищі, маючи сильну команду та таких контрагентів, як Аусра Густайн’єне, Діана Голд та Сауліус Юскевічус.
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/should-business-set-its-vision-waterfall-deliver-agile-stundyte/.
Gintare Stundyte люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 