Проблемы с жизненным циклом 1.0
Но не успело новое (по сравнению с жизненным циклом как сменой состояний целевой системы) понятие жизненного цикла (как поделённых на стадии работ создателей) прижиться, как начались проблемы.
Первая проблема понимания жизненного цикла как последовательности крупных работ проекта: в реальных проектах по созданию систем массово начала вырождаться стадийность. Сначала в agile[1] (гибких) подходах к разработке софта появились не тематические по видам работ «стадии», а безымянные «итерации» какой-то фиксированной длины --- и на этих итерациях было очень трудно отследить, какая же там преимущественная тематика работ. По факту там в каждой итерации и замышляли кусочек системы, и разрабатывали её, и делали, и испытывали, и эксплуатировали, и вроде как понятно было, что всё это нужно обсуждать, но вот идея «стадия как время ведения однотипных работ, а потом другая стадия как время ведения однотипных работ другого типа» не выжила. Эпоха «водопада» как «последовательного прохождения стадий жизненного цикла» кончилась даже до появления полноценной идеи «непрерывного развития», в которой множество линейных жизненных циклов и системы в целом, и её фич замыкались в изначальное «квазибиологическое» кольцо/цикл. Квазибиологическое кольцо --- это всё-таки техно-эволюция, а не дарвиновская биологическая эволюция, мутации не случайны, наследственный материал не реплицируется вместе с системой.
Затем в строительных проектах появилась параллельная инженерия (concurrent engineering), в которой намеренно в параллель/одновременно выполнялись работы, ранее считавшиеся строго разнесёнными по разным последовательным «тематическим» стадиям жизненного цикла: одновременно велось и проектирование, и изготовление системы, а какие-то неполные версии системы ещё и начинали эксплуатировать (например, крыло недостроенного здания).
Тем самым в начале нулевых годов 21 века возникли вопросы к идее о том, что работы на стадиях жизненного цикла ведутся с каким-то определённым состоянием целевой системы. Система разными своими частями находилась в разных состояниях, а все виды работ велись одновременно над разными частями системы: если корабль красили, то не как раньше --- сначала зачищали всю поверхность, потом всю её грунтовали, потом всю красили, всю сушили. Нет, чаще всего сначала зачищали кусочек, потом его грунтовали, и одновременно начинали зачищать следующий кусочек, потом первый кусочек красили, второй грунтовали, а третий начинали зачищать --- и «сначала» и «потом» оказывалось сугубо локальным для кусочка, а не глобальным для всей целевой системы. Стадии «зачистки», «грунтовки», «покраски», «просушки» оказывались перекрывающимися во времени/параллельными/concurrent, то есть они перестали быть последовательными стадиями, группировкой последовательности работ!
С одной стороны, последовательность работ была всем очевидна (красить нельзя без грунтовки, грунтовать без очистки), а с другой стороны --- нельзя было сказать, что «вот система в целом очищена, а теперь загрунтована, а теперь покрашена». Время для системы в целом при описании последовательности видов работ (это уже обсуждаем не ресурсы, а содержание! Функциональное рассмотрение, а не конструктивное!) оказалось логическим/функциональным/содержательным, а не физическим. Сами работы физичны, а вот виды этих работ в части их содержания оказались чем-то другим, содержание работ и их «логическую» последовательность/взаимосвязь нужно было обсуждать другим способом.
Разговор о «стадийности» жизненного цикла всё больше и больше становился условным, а не сущностным/содержательным. Работы и ресурсы обсуждать было продуктивно (операционный менеджмент!), а вот стадийность работ --- уже нет. И поэтому понятие жизненного цикла как набора стадий как «укрупнённых работ похожей направленности» стало не очень удобным в использовании.
Вот типичная картинка объяснения перехода к параллельной инженерии (и на ней хорошо видно, что сроки всех работ по созданию системы при этом существенно сокращаются)[2]:
Вторая проблема понимания жизненного цикла как последовательности крупных «тематических» работ: интерфейсы между работами обсуждались с точки зрения потока работ, операционного менеджмента, доступности ресурсов в проектном управлении. Результаты предыдущих работ/output становятся доступны для следующих в цепочке потока работ/input. Это было очень удобно, когда речь шла о точном ответе на вопросы стадии «как сделать работы»: «когда и кем будет выполняться работа, когда она будет закончена?». Но когда обсуждались функциональные вопросы (как вообще этот набор работ создаёт систему? Почему эти работы, а не другие?), как лучше в части технологии (а не как быстрее, то есть инженерный вопрос, а не менеджерский) выполнить работы, то понятий не хватало. Нужно было обсуждение того, как и зачем менять содержательно набор работ, а не оптимизировать время запуска каждой предварительно известной откуда-то работы или оптимизировать ресурсное снабжение каждой предопределённой кем-то работы --- информации категорически не хватало: нужна была информация о видах работ, назначении работ и их содержании, а не о самих работах и их ресурсах безотносительно их содержания.