Не так давно, я решил разобраться, какие же практики инженерии (не системной инженерии!) используются в моей компании в системах создания. Главная цель, получить какое то представление о том, какие практики есть, и на какой стадии развития находится каждая практика.
Все системы создания были поделены по принципу технологий / платформ электронной коммерции, которые используются для создания систем / вебсайтов интернет магазинов для клиентов. Чтобы упростить задачу, я решил выбрать подмножество практик, а именно, практики, которые используются непосредственно для альфы воплощения системы.
Честно говоря, это оказалось очень непростой задачей, так как понятие практик в моей компании не формализовано и говорить об этом с орг звеньями, даже если они находятся в орг ролях управляющих практиками, очень сложно. Вместо этого, я решил выбрать какой то более менее известный стандарт / подход, для описания таких практик, привести его в соответствие с тем, что происходит в системах создания, и уже двигаться оттуда. В качестве подхода для описания практик выбор пал на DevOps движение и то, как это описывает Google: DORA research program
Google описывает практики как орг возможности/capabilities, те терминология немного путанная, однако смысл в том, что для того, чтобы внедрять и поддерживать успешные системы, системе создания необходимо овладеть (возможности, те иметь саму возможность использовать практики в работах) практиками и начать применять их на практике (практики в непосредственно используемые в работах).
Все практики/capabilities объединены в группы и эти группы называются процессами, в нашем случае, мы понимаем, что речь идет о практиках - подпрактиках, отношение тип - подтип. Основных укрупненных практик 4: Technical capabilities (собственно и есть практики по изменению состояния альфы воплощения системы), Process Capabilities (здесь процесс - это практики управления работами), Measurement Capabilities, и Cultural Capabilities.
Так как за стандарт практик был выбран DevOps, то оказалось, он касается не только времени создания системы но и времени эксплуатации как те практики, которые используются системами поддержки целевой системы. Те уже не только системами создания.
Далее, управляющие практиками, провели аудит практик (решили проверить все практики/capabilities из DevOps, не только инженерные) в своих системах создания и оценили уровень maturity этих практик по 10 бальной шкале. Результат можно найти на скриншоте ниже:
Не все практики имеет смысл использовать у нас, соответственно такие практики были помечены как X.
Следующим шагом, будет выбрать наиболее критичные практики, в наиболее плачевном состоянии и разбить их на подпрактики, таким образом, поняв, над чем стоит работать и далее, создать roadmap развития практик в компании.
Кроме этого, я думаю, я бы посмотрел на практики управления жизненным циклом в целом и привел бы их описание к какому то стандарту компании.