Постмодерн в IT разработке

О постмодерне написано много, особенно в политике, искусстве, общественной жизни. Посмотрим, как невидимая рука постмодернизма добралась до информационных технологий (ИТ / IT). С началом производства программных продуктов в промышленных масштабах лучшие умы отрасли задумались об оптимальных процессах производства: с одной стороны, производимые продукты разные, их выпуск нельзя поставить на классический конвейер, как автомобили или ноутбуки; с другой стороны, это и не штучное производство картин или скульптур. Плюс почти полное отсутствие физической составляющей, виртуальность продукта соблазняет задуматься о предсказуемом и стандартном процессе.

Водопадная или каскадная (Waterfall) модель разработки, как говорится, долго витала в воздухе, впервые описана Уильямом Ройсом (William W. Royce) в 1970 году. Суть водопада в выделении последовательных фаз жизненного цикла софта: анализ, проектирование, кодирование, тестирование, поставка, поддержка. Переход к следующей фазе происходит только после успешного завершения предыдущей. Для водопадного процесса важны продуманные и стабильные требования к началу проектирования. Если требования меняются, то изменение порождает обратный водопадик внутри водопада и замедляет процесс.

Методика Microsoft Solutions Framework (MSF) - впервые опубликована в 1994 году (тем самым) Microsoft'ом, по сути - водопадная разработка для большого продукта, с узкой специализацией ролей исполнителей и таблицей возможного совмещения ролей в одном сотруднике. Почти одновременно в 1996 году выходят монструозные PM BOK и COBIT, в первых версиях чисто водопадные, с кучей деталей.

Наконец, в 1997 году появляется Rational Unified Process (RUP) - водопадно-итеративная модель, с наложением фаз друг на друга, и возможностью выпуска продукта частями (итерациями). Создана группой блистательных товарищей, но в её основе объектная модель Ивара Якобсона (Ivar Jacobson), заслуженного учёного и мощного ИТ авторитета, также одного из авторов Unified Modelling Language (UML). RUP несколько лет казался процессной панацеей, был очень объёмен, но допускал настройки и упрощения. Проблема чистого водопада с неприятием изменений в требованиях решена итерациями, в ходе которых требования можно планово уточнять.

Подоспели и всевозможные стандарты. ISO засветилась выпуском нескольких процессных моделей специально для ИТ. Уотс Хамфри (Watts S. Humphrey) в конце 80х опубликовал исчерпывающий набор софтверных практик, который можно было уложить в любой жизненный цикл (процесс) разработки: анализ альтернативных решений (decision analysis and resolution), перекрёстное рецензирование (peer review), отслеживание требований(requirements traceability) и т.п. В 1997 году на основе этого набора Software Engineering Institute выпустил процессную модель, которая сейчас известна под именем Capability Maturity Model Integration (CMMI).

Впоследствии, всё это назовут классическими методологиями. Учебные материалы по таким методологиям начинались с утверждения, что ИТ отрасль молодая, много в ней неясного, но практический опыт есть, и по этому опыту собрали лучшие / проверенные практики и процессы, которые и предлагаем вашему вниманию.

В классической разработке было хорошим тоном делать измерения производительности и качества. Наиболее показательные индикаторы:

• Производительность разработки - Единицы функциональности, разрабатываемые за единицу времени. Функциональность можно измерить в единицах оценки (Functional points, Use case points) или в модифицированных логических строках кода (одно довольно точно переводится в другое).
• Качество продукта - Плотность дефектов, т.е. количество дефектов (поведений продукта не по требованиям, как правило, после передачи заказчику) в единице функциональности.

Зрелые ИТ компании не просто измеряли свои показатели, но и управляли ими статистически. То есть знали, какая ветка процесса приведёт к какому диапазону качества и производительности.

Можно упомянуть и другие достижения процессных классиков: Стивен Макконнел (Stephen McConnell) исчерпывающе описал методы оценки (estimation) программных продуктов и проектов. Панкаж Джалот (Pankaj Jalote) "на пальцах" показал, как внедрить большинство лучших практик CMMI (надо признать, что напрямую из первоисточника это понимали считанные единицы). Майкл Конрад (Michael Konrad) расписал, какие методы математической статистики и как применять для количественного управления процессом софтостроения.

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

И вот часть ИТ сообщества провозгласила, что устала от процессной сложности и бюрократии, и в конце 90х годов выпустила Манифест гибкой (agile) разработки: Люди и взаимодействие важнее процессов и инструментов; Работающий продукт важнее полной документации; Сотрудничество с заказчиком важнее контракта; Готовность к изменениям важнее следования плану. Agile-манифест был подписан десятком специалистов, из них порядка четырёх до сих пор хорошо известны узкому кругу ИТ-шников: Алистер Кокбёрн (Alistair Cockburn) - писатель пользовательских историй (use cases, затем user stories); Мартин Фаулер (Martin Fowler) - в большей степени программист с популярным блогом, чем процессник; Кен Швабер (Ken Schwaber) и Джеф Сазерленд (Jeff Sutherland) - разработчики, пожалуй, самой популярной процессной модели на основе agile.

Манифест не то чтобы интуитивно понятный, но сложно критикуемый. Как и многие манифесты - за всё хорошее. Чудеса начались при появлении методологий, реализующих манифест. Вводились практики с недоказуемой полезностью - нашёл дефект - не документируй его, а почини; и церемонии более социально-религиозной направленности, нежели процессно-технической: ежедневные собрания на ногах (Daily stand-up meetings), совмещение обязанностей, только короткие итерации.

Ни один видный деятель классических ИТ-процессов "гибкий" манифест не подписал. Но и заметной критики от гуру-классиков никуда не просочилось. Как настоящие учёные, они, вероятно, восприняли очередное новшество с любопытством, типа "посмотрим на ваши результаты". Только Ивар Якобсон точно сформулировал, что agile - гораздо больше про социальную инженерию, чем про техническую; всё используемое им техническое придумано до него, но непонятно почему так скомбинировано.

Смотрим на популярные гибкие методологии: Скрам (Scrum) описан Джефом Сазерлендом в 2002 году. Команда выпускает продукт или его части короткими итерациями (sprints) одинаковой длины (например, 2 недели). Перед итерацией Владелец продукта (Product Owner) расставляет приоритеты и, руководствуясь оценками команды, планирует, что будет сделано за итерацию. Участники команды равноправны, но есть Скрам мастер (Scrum Master), который не начальник, но направляющий и смотрящий за процессом. Во время итерации каждый докладывает о достижениях и планах на ежедневном собрании, стоя на ногах, чтобы не занимать много времени. Во время итерации требования менять нельзя, но это не страшно, поскольку она короткая. В конце итерации демонстрация (Demo), на которой обсуждается и принимается результат с Владельцем продукта.

Другой популярный agile: KANBAN - именно в адаптации к ИТ выходит в 2004 году. Здесь задачи итерации вывешиваются на доску-таблицу и переходят из колонки в колонку по мере продвижения задачи. И третий заметный - Scaled Agile Framework (SAFe) - попытка адаптации гибкой разработки к большим организациям - публикуется в 2007 году. Последний, по сути, признал, что в большой организации просто Scrum of scrums не поможет, нужны более сложные надстройки.

Посмотрим на персоны "гибких" гуру: Джеф Сазерленд - бывший военный, и внешне и по поведению напоминает одиозного сенатора Джона МакКейна; Кен Швабер - выпускник академии торгового флота. Конечно, нельзя зацикливаться на происхождении и прочих внешних признаках, но что получается - на военного с торговцем сошло озарение, которое переплюнуло модели и научные обоснования от классических физиков и математиков, создававших софтверную отрасль? То ли помогла незамутнённость сознания, то ли невидимая рука постмодерна.

Учебные материалы по гибким методологиям обычно начинаются с критики классических методологий - которые сложны, косны и часто ведут к провалу. А теперь всё стало проще, понятнее и, как многие добавляют, веселее (в смысле fun).

Аргументы сторонников гибких и классических методологий, которые можно было услышать в локальных дискуссиях начала и середины 00х годов:

Аргументы сторонников гибких (agile) методов	Ответ сторонников классических методов	Ответ на ответ от "гибких"	Ответ на ответ от "классиков"
Кросс-функциональные самоорганизующиеся команды, у каждого есть первичная роль (например, аналитик), но может исполнять ещё несколько ролей по необходимости (тестировщик, внедренец...)	Широкие специалисты дороги, плюс сложно быть хорошим спецом сразу в нескольких областях; ничего в мире не самоорганизуется.	Широкие специалисты автоматически воспитываются в слаженной команде, со спецами в смежных областях. А хорошие спецы с общей целью могут самоорганизоваться.	Но посмотрите на команды, построившие настоящий agile: там текучесть кадров выше, чем у классиков. Это результат воспитания и самоорганизации?
Выпуск продукта короткими итерациями в 2-3 недели, в конце каждой итерации имеем минимальный рабочий продукт или хотя бы его прототип.	Бывает объективно объёмный функционал, который выпускается долго. Классические измерения показывали, что оптимальная длина релиза "среднего продукта средней командой" располагается вокруг 3х месяцев.	Большой функционал можно выпускать частями. Жизнь ускоряется, бизнес не может планировать на 3 месяца вперёд и не может так долго ждать.	Выпуск частями чреват необоснованными переделками (rework). Есть заказчики, которые могут планировать и на год вперёд. Если заказчику нужна срочность, то не надо его обманывать, что срочно можно сделать также дёшево.
Решения принимаются в присутствии всей команды, документация не нужна.	Сложно собирать всю команду ежедневно, особенно если она большая. Большой проект, или проект с часто меняющимся составом участников просто развалится без документации.	Добивайтесь дисциплины пристуствия всех. Организуйте иерархию собраний для больших команд (Scrum of scrums). Устаревшая или формальная документация только мешает.	При полной дисциплине можно добиться и полного своевременного документирования. Иерархические собрания - вариант испорченного телефона.

В 2010х годах наступила ясность и тишина. Никто из сомневающихся ничего никому не доказал, но agile и его вариации шагают по планете. Бывшие "процессные" секции ИТ конференций переименовываются в секции "гибкой разработки", вместо процессных инженеров организации ищут agile коучей, крупные заказчики ИТ услуг без сопротивления согласились, что теперь сами отвечают за ИТ результат в лице Владельца продукта (Product Owner). Ведь Владелец продукта участвует в ежедневных встречах, и видит, как команда старается.

Столпы классиков, со временем, не то чтобы сдаются, но приспосабливаются. Публичный MSF полностью адаптировался к agile, но усилились слухи, что сама Microsoft этой публичной версией процесса не пользуется. В модель CMMI добавлены расширения (amplifications) о том, как внедрять некоторые практики для "гибких" процессов. Ивар Якобсон рекламирует свою новую процессную модель Essence, в основном, на примере Скрама (может, модель и хорошая, но кто на неё обратит внимание, если не сопроводить модным словом).

В гибкой разработке, дабы не тиражировать глобальную сложность, отказались и от классических измерений производительности и качества. Классики-скептики хотели посмотреть на наши результаты в традиционном формате? Их не будет! Новая модель не будет выпускать мусор, а значит каждая строчка кода значительно ценнее, их нельзя сравнивать с классикой. В лучшем случае, функциональность измеряется в Story points, которые определяет сама команда, а следовательно производительность, измеренная в этих единицах, не поддаётся сравнению и контролю даже внутри одной организации (между соседними командами).

В общем, признаки постмодерна детектед: ясность (пусть и шокирующая неверующих "изгоев"), тишина (отсутствие видимой дискуссии), ненависть к сомневающимся. Гибкие методологии, подобно тотальной толерантности к извращенцам и к творцам из говна вдруг, на глазах одного поколения, превратились в непреложную истину.

А что думают простые сотрудники ИТ-организаций, на которых строят разные процессы? Как правило, ничего. Если процесс мешает - негромко ворчат, если привыкли - то не замечают, на каком именно виде "прозы" они говорят. И это естественно. Сотрудник не в восторге от любого процесса. Среднестатистический рабочий сборки предпочёл бы слоняться по цеху и искать, к какому из агрегатов нужная деталь ещё не прикручена, чем стоять на конвейере, который указывает, куда и в каком темпе прикручивать. Хорошие процессы нужны организациям, а постмодерн позаботился о том, чтобы руководители организаций ИТ-заказчиков в ИТ-процессах не разбирались, но чётко слышали, что Скрам или Канбан - это круто.

Логичный вопрос, а что делать в хорошем будущем сверхмодерне, когда отклонения перестанут называть нормой - что, вернёмся к Водопаду? Конечно, нет, но вопрос непростой. Очевидно, необходимо снова признать объективные сложности и проблемы, и думать над их решениями, а не над балаганными упрощениями. И от "гибких" методов можно взять что-то полезное, но нужно найти общие объективные показатели результатов, которые позволят каждой методологии найти правильную нишу, а главное - двигаться дальше. Но кто спонсирует дорогостоящие поиски и движения, если невидимая рука постмодерна спонсирует то, что есть?