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

Аgile vs другие - джаз всегда живее… И продуктивнее?

Методология Agile (гибких подходов) - управленческий метод, который широко применяется

 в разработке новых продуктов, программного обеспечения, новых проектов и даже в таких дисциплинах как маркетинг.

Agile - это альтернатива или дополнение таким методам как: Водопад, Проектное управление, V-диаграмма, широко применяемых в АСУ ТП. Александр Пупена- один из самых активных наших членов, - нашел великолепный документ, детально и популярно разъясняющий все эти вещи (см дискуссия в нашей группе на facebook). Это работа - материалы учебного курса TechInvestLab «Системное инженерное мышление»

Публикуем отрывок по поводу Agile - одного из самих популярных методов на рынках ИТ, в том числе и в Украине.

*************

Agile по отношению к другим (жестким) методам - это джаз по отношению к симфоническому оркестру

Если посмотреть на то, что происходит в менеджменте и инженерии, то тренд к "джазовой" организации деятельности несомненен. Все движение agile ("гибкости") -- это именно в ту сторону, и все остальные примеры инноваций (например, переход от акцента на administration / management к leadership) именно в эту сторону. Метафора, при которой все главные решения принимаются одним лицом, которое всеми "дирижирует" опасна, потенциально создаёт угрозу появления в проекте "бутылочного горлышка", существенно замедляющего принятие инженерных решений, эта метафора не соответствует духу времени. Системные инженеры специализируются до инженеров по требованиям, инженеров-архитекторов, инженеров по испытаниям, инженеров по безопасности и т.д. И далее целая команда таких людей не столько командует остальными инженерами (как по факту командует дирижер музыкантами оркестра, сам ни на чем не играя), сколько организует их взаимодействие, выполняя свой кусок инженерной работы. 

Нужна другая метафора, джазовая - хотя она может оставаться и музыкальной. Так, в джазе есть звукооператор (producer, хотя это слово в России значит совсем другое) -- он из записанных разными музыкантами отдельных треков делает окончательную запись. Но он не предписывает, какую музыку играть музыкантам. Или руководитель джазового ансамбля, который выбирает, какую мелодию будут играть - но он не командует, кому когда и что играть, и не выдает точные ноты… Это все об Agile.

Agile - манифест разработки программного обеспечения  

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: 

  • Люди и взаимодействие важнее процессов и инструментов 
  • Работающий продукт важнее исчерпывающей документации 
  • Сотрудничество с заказчиком важнее согласования условий контракта 
  • Готовность к изменениям важнее следования первоначальному плану 

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. 

*********

Появление и развитие Agile

После этого манифеста началась "религиозная война": по сути, манифест полностью разделял стадии жизненного цикла и практики, а также предполагал "гибкость" в планировании работ -- то есть объявлял отсутствие "водопада" в любых его проявлениях. 

Появились сотни вариантов методов разработки, из которых сегодня для программной инженерии наиболее распространён SCRUM. 

На практике оказалось, что следование принципам agile методов разработки и предлагаемым ими моделям жизненного цикла (чаще всего делящих жизненный цикл на стадии "релизов" с выделением мелких подстадий "итераций") может приводить как к впечатляющим успехам, так и к впечатляющим провалам. Также оказалось, что и "водопад" в чистом виде никто не использует, поскольку "по документам" работа описывалась одним образом, а "в жизни" элементы agile использовались много больше. Много было и обычного непонимания. Так, "люди и взаимодействие важнее процессов и инструментов" -- это вовсе не был призыв к луддитству и отказу от инструментов. Просто не было ещё инструментов, которые поддерживали agile-методы разработки. В итоге перестали использоваться как чисто гибкие методы (на их использование ещё и менеджеров было трудно уговаривать, потому как они не дают хорошо спланировать работу заранее и потом контролировать выполнение планов), так и "водопады" (ибо жестко запланированные проекты часто получаются дороже и длятся дольше, чем было запланировано -- планы обычно не включают неожиданностей типа уточнения требований близко к концу разработки или переделки архитектуры после проведения испытаний уже готового изделия). 

В системной инженерии "железных" систем методы agile пока используются мало, ибо принято считать, что в существенной мере действует "водопадная" модель. Но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы те же практики, которые хорошо зарекомендовали себя при разработке программного обеспечения. Единственное что, так это временной лаг: модные в программной инженерии идеи попадают в системную инженерию с задержкой в примерно 10-15 лет. Как раз сейчас начинают говорить о том, что какие-то agile элементы в системной инженерии возможны. Но вот воплощение системы обычно проходит в стиле "водопада": если хорошо проработан проект, и имеется большой опыт создания аналогичных систем, то неожиданностей и "возвратов назад" в проекте будет мало, сборка проходит в точном соответствии с планом, испытания проходят с первого раза. 

************

От АППАУ: интересно, кто нибудь из промышленных АСУ ТП-ков это использует? И представляет ли тема Agile / SCRUM интерес для наших Системных интеграторов? - мы легко можем организовать мероприятие на эту тему с нашими ИТ-компаниями… Пишите нам.

 

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