Мировая индустрия промышленной разработки ПО характеризуется прежде всего регулярным применением известных методологий программной инженерии, которая развивается сегодня довольно бессистемно. Согласно исследованию Forrester, по состоянию на третий квартал 2013 г. абсолютным лидером стала гибкая методология Scrum — её используют 90% опрошенных коллективов (допускались множественные ответы, так как в одной компании разные группы программистов могут применять разные подходы). Почти половина команд применяет классический “водопад” (над уничтожением которого столько лет фактически безуспешно трудились agile-манифестаторы), итеративную разработку (как правило, под этим красивым термином скрывается не слишком системный подход, когда целевые усилия для внедрения конкретной методологии не прикладываются), а также канбан и бережливый процесс (lean).

Для такого “зоопарка” подходов, практически всегда одновременно используемых в любой крупной организации, характерны известные классические проблемы. Например, в одном подразделении программисты могут трудиться достаточно успешно и “единообразно”, однако если разработчик перейдёт в соседний отдел, то с ходу включиться в чужой рабочий проект ему будет практически невозможно, даже если там применяется схожая методология. Как человеку понять, в каком состоянии проект и куда он движется, как быстро сформировать понимание того, что сделано и что сделать предстоит, как сразу и безболезненно встроиться в работу коллектива?

Показательный пример в этой связи привёл Ивар Якобсон, человек, отлично известный каждому разработчику. Это один из авторов языка моделирования UML, методологии RUP, технологии аспектно-ориентированного программирования и множества других полезных вещей. Ныне он возглавляет организацию Software Engineering Method and Theory (SEMAT), которая как раз и берётся разгребать эти методологические авгиевы конюшни.

Выступая на российской конференции по разработке ПО CEE-SECR ‘2013, Ивар Якобсон рассказал, как в Швеции три университета независимо друг от друга обучают разным методологиям разработки (Scrum, бережливое и экстремальное программирование). По окончании учёбы выпускники собираются вместе, например, в компании Ericsson, — но как же им теперь организоваться в одном проекте? В итоге менеджер говорит классическое “забудьте всё, чему вас учили в университете”, и программисты трудятся по старинке, в лучшем случае в режиме итеративной разработки. Красивые слова о команде команд, о системе систем и корпоративной культуре проектного управления — это демагогия, и тому много причин. Так, сегодня фактически исчезает практика чтения тематических книг и учебников — книги в современном мире, по словам Якобсона, не работают. Поэтому особо востребован подход, который, во-первых, не будет зависеть от конкретной применяемой методологии, а во-вторых, окажется интуитивно понятным каждому разработчику.

Именно такую амбициозную цель поставила перед собой структура SEMAT. Она объединила около полусотни “гуру”, которые работают над общей теорией программной инженерии, а всего в SEMAT входит две тысячи индивидуальных членов, двадцать учебных и академических структур и двадцать корпораций, включая IBM и Microsoft. И деятельность этой организации уже приносит практическую отдачу. Ивар рассказал несколько историй успеха — например, в английском подразделении Fujitsu совместно трудятся десятки команд программистов. С помощью SEMAT удалось выполнить обзор всех используемых методов, выделить набор общих практик и существенно их оптимизировать.

Что же такое SEMAT? Это не метод, он не конкурирует с agile-подходами или “водопадом”, а подкрепляет их, делает лучше и при этом позволяет быстро понять, в каком состоянии находится проект. В каждой организации применяются самые разные языки программирования, среды и методологии разработки, но без единой платформы SEMAT они будут существовать сами по себе, без взаимосвязей с единой проектной структурой.

В концепции SEMAT выделяют три момента.

1. Под всеми методологиями лежит единое ядро (это то, что в девелоперских проектах делается всегда и везде). Ядро — не метод, описанный в книге, а ежедневные практики, позволяющие измерять успех продвижения к цели. При этом ядро не “математично”, а представляет собой скорее экспертные суждения. Главный принцип его формирования таков: использовать только что, что нужно абсолютно всем. При этом, конечно, пользователи могут добавлять собственные проектные практики, которые описываются в терминологии ядра и таким образом становятся более понятными.

2. Так как разработчики документацию и книги практически не читают, им нужно предоставить интуитивно понятный графический синтаксис (символический визуальный язык). Эффект от него поразительный: например, полсотни страниц классического описания Scrum умещается в две страницы в синтаксисе SEMAT.

3. Ядро само по себе очень компактно, а основная работа с помощью SEMAT строится на так называемых “альфах”, практиках (то, что мы делаем и используем в рабочих процессах). В любом проекте всегда есть требования (не обязательно задокументированные — SEMAT этого не требует, достаточно, чтобы они “хранились” у специалиста в голове), всегда есть команда (пусть даже состоящая из одного человека), что подразумевает методы совместной работы (люди знают, как работать вместе, хотя это знание также не обязательно формализовать), и всегда есть акционеры/заказчики/инвесторы, с которыми надо взаимодействовать.

Для работы с “альфами”, позволяющими отслеживать прогресс проекта, применяются простые подходы: карточки, доски и т. п. Как они используются, можно узнать, например, на сайте проекта — там имеются специальные тренировочные игры. Измерение состояний проекта, не зависящих от применяемых методов и инструментов, выполняется с помощью специальных анкет. Понятие “анкета” в контексте SEMAT довольно условное, но более точного аналога пока не нашлось; не следует также путать данные анкеты с документами, они скорее средства получения объективных и наглядных критериев происходящих в проекте изменений. Таким образом, регулярно выполняя измерения по “альфам” (ключевым видам деятельности, присутствующим в любом проекте), мы всегда можем оценить и визуально представить прогресс продвижения проекта, легко понять его текущее состояние, сравнить с другими проектами, а также оценить производительность разных команд, методов и т. п. “Сегодня мы моделируем универсальный процесс разработки, — отметил Ивар Якобсон, — до нас предпринималось немало подобных попыток, но все они потерпели крах”. Пока деятельность SEMAT внушает оптимизм, но чтобы от новой теории программной инженерии появилась реальная отдача, надо выйти не на сто тысяч программистов, а на сто миллионов, чтобы они общались на едином проектом языке, понятном также и менеджеру, и заказчику.

Напомню, что официально работает русское отделение SEMAT, выполняется перевод “Основ SEMAT”. После выступления на конференции г-н Якобсон со товарищи пообщался с представителями российского отделения международной организации INCOSE по развитию системной инженерии, с которой SEMAT поддерживает регулярные отношения. По итогам встречи решено организовать трек по системной инженерии в рамках всего SEMAT.