Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
201 |
Этот пример показывает, что hump диаграму можно рисовать не только для практик в целом (например, архитектурная работа в RUP), но и для подпрактик (пример разбиения архитектурной работы на её подпрактики/tasks в MFESA).
Водопад и agile
Вид жизненного цикла
Жизненные циклы в плане распределения работ по разным практикам по времени бывают устроены очень по-разному. Об этом также и говорят по-разному:
●Виды жизненного цикла — мы будем использовать этот термин, если хочется непременно использовать термин “жизненный цикл”, чтобы подчеркнуть наличие стадий.
●Формы жизненного цикла
●Метод разработки (development method). Напомним: метод — это прежде всего набор необходимых для работы практик, метод может не закрывать полного жизненного цикла). Полный синоним — методология разработки (development methodology). Слово “разработка” обычно означает стадии жизненного цикла вплоть до эксплуатации.
●Процессы разработки (development process), в том числе процесс разработки программных средств (software process).
●Модель жизненного цикла (life cycle model) — но не путайте с рабочим продуктом-моделью (моделью в значении “упрощённое представление системы”)! Речь тут идёт просто об именовании варианта альфы определения жизненного цикла (т.е. использование слова “модель” как для указания моделей автомобилей: модель ВАЗ 2110, Ford Focus ST, или модели
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
202 |
фотоаппаратов: Nikon D3300, Sony SLT-A77 II, Olympus OM-D E-M10).
По большому счёту, это всё одно и то же: определение того, как будет устроена разработка (т.е. до стадии изготовление, иногда включая стадию изготовление) — какие практики, какие стадии (в том числе гейты), какие правила лежат в части выбора практик и распределения работы по стадиям.
Виды жизненного цикла, которые “на слуху” — это RUP (Rational Unified Processel), SCRUM, спиральная модель, и так далее: их сотни.
Стили разработки: водопад и agile
Условно в видах жизненного цикла (методах разработки) можно выделить два больших стиля:
●Водопад (cascade, но переводят “каскад” редко, хотя такой перевод и более правилен)
●Agile (на русский обычно не переводится, хотя иногда говорят о “гибких методах”)
К водопадным стилям относят такие, при которых отдельные практики выполняются последовательно, как вода проходит каскад — сначала разрабатываются требования, потом архитектура, потом проект, потом проходит изготовление, потом сборка и т.д. Все рабочие продукты стадий проходят hand over (передачу) на следующую стадию, и дальше не меняются, а используются для получения продуктов этой стадии.
Ключевая предпосылка “водопада” — это то, что практики совпадают со стадиями жизненного цикла. То есть “проектирование” — это и практика, и стадия жизненного цикла. “Тестирование” — это и практика, и название жизненного цикла.
Рисуют это примерно так (оригинальная статья Royce, Winston (1970), «Managing the Development of Large Software Systems» — http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_win ston_royce.pdf):
К сожалению, эта картинка показывает фантастическую ситуацию. В реальной жизни выполнение работ каждой практики-стадии вызывает необходимость обращения к уже прошедшим практикам (но их стадии-то прошли, и ресурсов на
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
203 |
них уже нет, и рабочие продукты уже считаются сданными!). Ужас в том, что возвращаться назад приходится часто не на одну стадию-практику-ступеньку, а сразу на несколько, в том числе бывает, что и с последней на первую!
Для борьбы с этим были придуманы альтернативные стили, самой популярным из которых был придуманный Barry Boehm стиль “спиральной” модели жизненного цикла — в которой говорилось, что разработка происходит “по спирали”, в которой одновременно выполняется цикл из нескольких практик, поэтому практики и стадии жизненного цикла оказались разъединены. Вот типичное изображение спиральнуой модели (http://mydotnetcoolfaqs.blogspot.ru/2011/04/software-development-life-cycle- sdlc.html — и по этой ссылке ещё некоторое количество древних моделей жизненного цикла):
Разными оттенками зелёного показаны стадии жизненного цикла (разработка концепции, разработка системы, усиление системы, сопровождение/обслуживание системы), а практики показаны как сектора на круге (liason тут — customer communications).
Проблема оставалась: практики предполагались последовательно выполняющиеся на каждом витке спирали, т.е. сохранялся “микроводопад”.
Потом было предложено огромное количество других моделей/видов жизненного цикла, пытающихся снять недостатки “водопада”, но в 2001 году группа программистов (software engineers) предложила Agile manifesto
(http://agilemanifesto.org/):
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
204 |
Официальный русский перевод (http://agilemanifesto.org/iso/ru/):
Agile-манифест разработки программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
После этого манифеста началась “религиозная война”: по сути, манифест полностью разделял стадии жизненного цикла и практики, а также предполагал “гибкость” в планировании работ — то есть объявлял отсутствие “водопада” в любых его проявлениях.
Появились сотни вариантов методов разработки, из которых сегодня для программной инженерии наиболее распространён SCRUM.
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
205 |
На практике оказалось, что следование принципам agile методов разработки и предлагаемым ими моделям жизненного цикла (чаще всего делящих жизненный цикл на стадии “релизов” с выделением мелких подстадий “итераций”) может приводить как к впечатляющим успехам, так и к впечатляющим провалам. Также оказалось, что и “водопад” в чистом виде никто не использует, поскольку “по документам” работа описывалась одним образом, а “в жизни” элементы agile использовались много больше. Много было и обычного непонимания. Так, “люди и взаимодействие важнее процессов и инструментов” — это вовсе не был призыв к луддитству и отказу от инструментов. Просто не было ещё инструментов, которые поддерживали agile-методы разработки. В итоге перестали использоваться как чисто гибкие методы (на их использование ещё и менеджеров было трудно уговаривать, потому как они не дают хорошо спланировать работу заранее и потом контролировать выполнение планов), так и “водопады” (ибо жёстко запланированные проекты часто получаются дороже и длятся дольше, чем было запланировано — планы обычно не включают неожиданностей типа уточнения требований близко к концу разработки или переделки архитектуры после проведения испытаний уже готового изделия).
В системной инженерии “железных” систем методы agile пока используются мало, ибо принято считать, что в существенной мере действует “водопадная” модель. Но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы те же практики, которые хорошо зарекомендовали себя при разработке программного обеспечения. Единственное что, так это временной лаг: модные в программной инженерии идеи попадают в системную инженерию с задержкой в примерно 10-15 лет. Как раз сейчас начинают говорить о том, что какие-то agile элементы в системной инженерии возможны. Но вот воплощение системы обычно проходит в стиле “водопада”: если хорошо проработан проект, и имеется большой опыт создания аналогичных систем, то неожиданностей и “возвратов назад” в проекте будет мало, сборка проходит в точном соответствии с планом, испытания проходят с первого раза.
Хороший пример того, как agile проникает в системную инженерию — это организация хода разработок в компании SpaceX (см. https://www.aiaa.org/uploadedFiles/Events/Conferences/2012_Conferences/2012- Complex-Aerospace-Systems-Exchange-Event/Detailed_Program/CASE2012_2- 4_Muratore_presentation.pdf). Главная там фраза — focus on tools not rules. А потом test rigorously and often.
Ещё один хороший пример — agile производство автомобиля: видеорассказ — http://www.youtube.com/watch?v=x8jdx-lf2Dw, описание автомобиля http://wikispeed.org/the-car/, eXtreme manufacturing — http://scrumlab.scruminc.com/articles.html/_/open/extreme-manufacturing-r93, test driven developing for hardware — http://wikispeed.org/2013/07/tdd-for-hardware/.
Главное там было — обеспечить высокую скорость изменений, и указывались примерно те же механизмы, что и в SpaceX (обмен информацией через сеть вместо традиционных control boards, даже была оговорка, что ещё лет пять назад это было бы невозможно по причине недоразвитости сетевых сервисов, а лет десять назад всех этих сервисов вообще не существовало).
Близко к agile примыкает lean systems engineering: http://www.lean-systems- engineering.org/downloads-products/lean-enablers-for-systems-engineering/downloads-