Эта статья про историю SDLC — System (Software) Development Life Cycle. Он принадлежит далёкому прошлому, но на него тем не менее продолжают ссылаться на конференциях и пытаются использовать.

Итак, в далеком 1981 году менеджеры задумались о регламенте для ведения ИТ-проектов, ведь софта требовалось всё больше, его разработка перестала быть частью научных исследований, а становилась частью развития бизнеса и даже развития государства. А это значит, что необходима методика, на которую, если что-то пошло не так, можно кивнуть «мы всё делали правильно». Если кто не знает, то основное назначение именно в этом, а вовсе не в том, чтобы успешно делать проекты.

Менеджеры посмотрели, что пишут специалисты, увидели водопад Ройса (1970) — простую и понятную схему. И наплевать, что сам Ройс в сопровождающей статье писал, что так работать не будет.

Только чего-то на этой схеме не хватает важного. О! Нужно же планирование проекта. Ну так давайте вставим его в самом начале. А ещё там какие-то Requirements (требования). Это что, мы, заказчики, думать должны? Надо заменить этот шаг на анализ, пусть специалисты сами думают. И ещё выкинуть проверку (Verification), ведь это намёк на то, что в проекте могли сделать что-то негодное. Так не бывает, проекты всегда должны быть успешны! И получился SDLC (System / Software Development Life Cycle) из методологии SAADМ (Structured Systems Analysis and Design Method).

Смотрим на эту схему внимательно и видим методику работы для Ивана-дурака. Сначала царь-менеджер потребует «пойди туда, не знаю куда, принеси то, не знаю что, и чтобы за месяц управился». А разработчик это должен выполнить, а не то «мой меч — твоя голова с плеч». В смысле уволим али денег не заплатим, мы нынче гуманные. Ну а потом линейную схему ещё в цикл закрутили: понятно, что надо же вечно получать контракты, а не один раз. Тем более что Ройс тоже что-то там такое про итерации писал.

Всё это, конечно, иронический рассказ, но, по-моему, он хорошо вскрывает смысл. Иначе лично я не могу объяснить, почему планирование поставили ещё до прояснения задачи. Как сделать план по разработке непонятной системы? А ещё схема SDLC отличается тем, что в содержании нет никакой software, и это тоже в стиле мышления менеджеров MBA, ведущем начало в английском подходе XIX века: джентльмен может руководить чем угодно, ему не надо разбираться в содержании. Кстати, этот подход до сих пор действует при назначении британского кабинета министров.

Вы можете возразить, что и в новых методах, таких как Scrum, планирование — тоже начале спринта. Однако там, во-первых, есть Product Backlog, пункты которого описывают, что именно надлежит сделать, а во-вторых, есть отдельный процесс подготовки (Product Backlog Refinement), в ходе которого пункты уточняются до такой степени, чтобы по ним можно было получить реалистичную оценку. В первых версиях scrum guide этот процесс назывался Product Backlog Grooming и по-русски часто употребляют именно этот термин, а в английской версии его заменили из-за сленгового значения.

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

Что же использовать вместо этой схемы? Я обычно использую V-модель. Она, конечно, тоже не новая, 1992 год. Но она гораздо более содержательная, в ней есть несколько важных смыслов, отсутствующих в SDLC.

1. Начинается всё с Concept of Operations — представлений о том, как люди будут работать с использованием софта. Правда, это уже получается постановка задачи, которой предшествует формулировка проблемы, которую с помощью софта хотелось бы решить. Поэтому я в левой ветке часто добавляю Needs and Opportunities, описание проблем бизнеса и требуемых возможностей.

2. Она раскрывает обратный путь создания софта к его интеграции в бизнес-процесс, жизнь людей (Maintenance). На этом пути тоже есть несколько этапов, на которых выявляется пригодность созданного. Эти проверки могут закончиться неудачно и потребовать повторения цикла, и это ситуация реальной жизни, а не идеальной картины.

3. Схема показывает постепенный переход от языка бизнеса к реализации ИТ-системы, который сопровождается сменой объекта и используемого языка, а затем возвращение назад на уровень бизнеса. Между левой и правой ветвями этого пути есть соответствие.

И дальше на этой схеме можно говорить о том, как мы проходим этот путь, какие выделяем этапы, что считаем важным, а что ситуативным. Например, требования. В одних проектах они являются контрактом между заказчиком и исполнителем и их нельзя игнорировать, а в других — лишь временный промежуточный этап между пониманием устройства и потребностей бизнеса и проектированием модели софта, который решит имеющиеся проблемы.

Отмечу, кстати, что фиксация контракта через требования работает плохо, это было признано уже более 20 лет назад, но старые методологии живучи, SDLC тому пример, и такая форма контракта продолжает использоваться. Впрочем, это предмет отдельного рассмотрения. У меня много материалов об этом, например, в докладах «Почему проектный подход не работает в IT» на Teamlead-2022 и «Требования или модели — как писать постановки» на AnalystDays-2023. А я на этом завершаю статью.