Ассоциация Предприятий Промышленной Автоматизации Украины

Let’s be Agile – звіт з круглого столу АППАУ, ч.1

Обговорення теми: «Agile – як кращі практики в розробці програмного забезпечення та управлінні проектами» викликало чималий інтерес представників ринків ІТ та промислових АСУ.

Аудиторія в 30 чоловік була представлена всіма категоріями гравців, - найбільше було інтеграторів, що й зрозуміло, виходячи з заявленої теми.  Зустріч вийшла насиченою та цікавою, - тому з урахуванням інтересів тих, хто не зміг приїхати - звіт про неї ми робимо в двох публікаціях. В цій ми представимо спікерів, а в наступній – поговоримо про саму дискусію та висновки.

Agile – як відповідь на виклики ринку

Автор цих рядків у вступному слові підкреслив, що потреба в Agile – не що інше, як пошук нових методів та підходів, які можуть краще відповідати на виклики розвитку ринків промислових АСУ. Ключовими проблемними питаннями на сьогодні бачаться:

  • Повільна реакція та адаптація гравців ринку на глобальні виклики розвитку промислових АСУ в Україні – як  краща окупність систем, ріст показників безпеки та експлуатаційної готовності, збільшення вкладу в енергоефективність та покращення ефективності в управлінні підприємствами
  • Низький рівень уніфікації програмного забезпечення, відсутність загальноприйнятих стандартів чи кращих практик в цій області, що необхідно, перш за все, для кращої взаємодії з замовниками, завдань експлуатації та легшої інтеграції під-систем АСУ між собою
  • Слабка інтеграція та наростання розривів з ІТ-технологіями та методами.

Сергій Батюк, технічний директор «Клінкманн-Україна» описав портрет типового Системного інтегратора і наголосив, що питань до технічних компетенцій наших інтеграторів немає. А от щодо методів управління проектами та розробки ПЗ – питань чимало. Інтегратори АСУ ТП перебувають в умовах, коли середовище замовника не стабільне, технічне завдання ніколи не буде на 100% без змін і при цьому реалізація потрібна «на вчора»м Сергій Георгійович вірно відмітив, що це є «родова ознака проектів АСУ ТП». Так буде завжди. Відповідно рішення багатьох проблем з якістю, термінами та бюджетом лежать не в площині «гарний чи поганий замовник», а в площині власних методів та підходів до управління проектами. 

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

Appau-33

Доповіді експертів з ІТ

Олена Прихнич, - співзасновник та бізнес-тренер агентства Е5, що спеціалізується в консалтингу по методам SCRUM, розповіла про принципи та переваги стилю Agile для розробки програмного забезпечення. Зокрема, Олена розкрила деякі так звані «артефакти» (особливості) SCRUM для розробників – як «спрінти», беклог продукту, скрам майстер, ретроспектива, тощо.  Метод SCRUM – один з багатьох методів Agile, але який домінує з великим відривом в розробках програмного забезпечення. Головні переваги для бізнесу – це швидкість отримання результату, швидка адаптація до змін, кращий контроль якості процесу розробки – через розуміння стану на кожен момент. Згідно статистики, кількість успішних розробок методами SCRUM в рази вища в порівнянні з класичним методом розробки «водопаду».

Appau-4

Євгеній Антонов, - бізнес-аналітик компанії JBS розповів про власний кейс розробки ПЗ в масштабному проекті з міжнародною компанією. Євгеній доповнив попереднього доповідача, підкресливши, що ітераційні методи по своєму визначення краще підходять до мінливого проектного середовища – вони мають інтегровані можливості по ранньому та кращому зворотньому зв’язку, упередженню критичних помилок та ризиків, і відповідно  демонструють кращу реакцію та коротший час розробки. Найбільш цікавим в доповіді Євгена був слайд про підхід до розробки в згаданому кейсі (див. рис)

підхід_до_рішення_JBS   

Власне, мова про проект, але в якому домінують всі ознаки Agile/SCRUM. В основі розробки – багато ітераційних циклів (спринтів), які в свою чергу розбиваються на 6 етапів. Тут є класичні етапи проектного управління – як Ініціація та Планування, де SOW - Statement of Work, - це той же Статут. Але є й інші – наприклад, з’являється Візія проекту, що включає в себе високорівневий дизайн, а також описання умов (загального контексту) бізнесу. Цікава також кінцівка – у вигляді запуску в експлуатацію, також включенні фази підтримки. Євген також підкреслив, що Agile в даному кейсі "продавав і сам себе". Тобто, спочатку замовник не був готовий до роботи по цій технології і даний формат, - не більш ніж гнучка, гібридна модель різних методів управління.  Також через складність завдань та вимоги замовника довелось розширити набір регламентних документів. В цьому проекті регламенти включають 8 головних типів документів, - певний мікс методів SCRUM, класичного проектного та продуктового менеджменту. 

Appau-26

Олександр Жебряков, - консультант датського агентства Ciklum Consulting був переконливий в своєму головному меседжі: «Agile – це не просто метод чи набір методів, це – філософія бізнесу». Ключовим в Agile є значний ріст ефективності роботи крос-функціональних команд через кращі комунікації, залучення та відповідальність. В цьому Agile кращий від класичних методів проектного управління, адже методі крос-функціональної командної роботи відомі й там. До вже зазначених принципів   Agile, що прозвучали в попередньому виступі, Олександр додав таку річ як потоки цінностей (values stream). А його приклади «про муки прожект менеджера», якому весь час не вистачає або ресурсу, або-та повноважень та впливу – здались релевантними до нашої аудиторії.

Автор цього звіту представив підходи Agile Project Management від Terrasoft (на жаль, представники компанії не змогли виступити). Terrasoft вдало інтегрує елементи Agile в класичний формат прожект менеджменту (на рис. нижче номерами вказані головні відмінності від класичного проектного управління). В самій розробці продуктів (Execution) є спринти, беклог, ретроспектива, демо, а трудовитрати обліковуються в story points. На етапі Ініціації з’являється така цікава річ як Дорожня карта проекту, на етапі планування (Elaboration) – Концепція (дуже близько до Візії в кейсі JBS), цікаво виглядає новий етап «Перехід до експлуатації» (Transition) ну і власне сама «Експлуатація» має речі, яких часом дуже бракує в АСУ ТП – «вивчені уроки» та «активацію підтримки проектного рішення». 

формат_Terrasoft

Принаймі, наші опитування кінця 2014 р. не виявили якихось практик в управлінні досвідом клієнта серед гравців ринку АСУ ТП. В Terrasoft орієнтація на розвиток та управління досвідом інтегрована на рівні декількох практик. Крім вказаних елементів цікаво виглядають зміни структури управління проектом. Замість класичного прожект менеджера, команду очолює CSE – Customer Success Executive. В його відповідальності не 1 проект, а цілий пул проектів – це дає додаткові можливості в маневруванні ресурсами та автономність в вирішенні цих питань. Друга відмінність від класичного ПМ - його бачення переходить з рамок життєвого циклу проекту – на життєвий цикл клієнта. Тобто, CSE зацікавлений не просто в хороших результатах окремо взятого одного проекту – в його інтересах отримання нових і нових проектів від даного замовника. Звіт про  недавню конференцію Terrasoft, де згадуються і про практики Agile – див. тут

 Appau-36

Богдан Дучак з юридичної компанії Juscutum завершив представлення Agile висвітленням питань в юридичній площині. Це теж очевидна ознака зрілості Agile на ринку ІТ – як інакше можна інтерпретувати те, що механізми Agile прописуються в контрактах. Богдан вірно вказав на головне протиріччя багатьох класичних договорів – штрафи за недотримання ТЗ та результатів проекту, в той час як ці ТЗ та результати будуть на 100% змінюватись по ходу проекту. Досвід та практики Juscutum передбачають справді гнучкі підходи до регулювання конфліктних ситуацій, де одним з самих дієвих механізмів є (не тільки) фіксація «входу та виходу», - але й – а) фіксація механізмів роз рулювання конфліктних ситуацій, б) фіксація найбільш ефективних механізмів розробок та робіт проекту в тих аспектах, де залучається замовник.

Не зважаючи на короткий час виступів (кожен виступав не більше 20 хв), слухачі отримали масу цікавої інформації – і питань для дискусії накопичилось чимало. 

Про саму дискусію – продовження в наступній статті.

                                                                                                  ген директор АППАУ, Юрчак О.В.

 

Комментарии: