Что такое SDLC: из чего состоит путь от идеи до работающего продукта

Когда человек учится программировать, у него складывается модель работы примерно такая: приходит задача → пишешь код → код работает → готово. Эта модель не то чтобы неверна, она просто описывает примерно пятнадцать процентов происходящего. Остальные восемьдесят пять — это то, откуда задача взялась, почему она сформулирована именно так, кто решил, что её надо делать сейчас, как код доедет до пользователя, кто узнает, что он сломался в три часа ночи, и кто будет чинить.

SDLC (Software Development Life Cycle, жизненный цикл разработки ПО) — это название для всей этой картины целиком. Не методология, не фреймворк, не набор ритуалов. Просто способ сказать: «вот полный путь от того момента, когда идеи ещё нет, до того момента, когда систему выключают».

Эта статья — карта. Дальше в треке каждая фаза разбирается отдельно и подробно; здесь задача другая — чтобы вы перестали видеть работу как «мне дали тикет» и начали видеть её как «я нахожусь вот в этой точке конвейера, до меня было вот это, после меня будет вот это».

Зачем вообще нужна отдельная концепция

Возьмём мысленный эксперимент. Один человек пишет утилиту для себя. Ему не нужен SDLC: требования у него в голове, тестирование — «запустил, работает», деплой — go build, поддержка — «сломается, починю».

Теперь добавим по одному фактору и посмотрим, что появляется.

• Второй разработчик. Появляется необходимость договариваться, как называть вещи и как сливать изменения. Рождается система контроля версий, соглашения о ветках, код-ревью.
• Пользователь, который не вы. Появляется необходимость понимать, чего он хочет, а он сам этого толком не знает. Рождается аналитика и работа с требованиями.
• Деньги, зависящие от работоспособности. Появляется цена простоя. Рождается тестирование, мониторинг, дежурства, процедуры отката.
• Год времени. Появляется код, который писали люди, уже уволившиеся. Рождается документация, архитектурные решения, технический долг как понятие.
• Регулятор или крупный клиент. Появляется требование доказать, что процесс контролируем. Рождаются формальные согласования, аудит, трассируемость требований.

SDLC — это не бюрократия, которую кто-то выдумал. Это накопленный ответ на вопрос «что ломается, когда людей и времени становится больше». Каждый скучный процесс, который вы встретите на работе, когда-то был чьим-то очень болезненным инцидентом.

Обратное тоже верно и об этом реже говорят: процесс, унаследованный от чужой боли, в вашем контексте может быть чистыми накладными расходами. Обязательное согласование архитектуры с комитетом имеет смысл, когда цена ошибки — миллионы и полгода. В команде из четырёх человек, которая ищет product-market fit, тот же комитет просто убьёт скорость. Умение отличать одно от другого — это и есть профессиональная зрелость, и к ней мы будем возвращаться весь трек.

Фазы: универсальный скелет

Названия фаз кочуют из книги в книгу с вариациями, но скелет везде один. Формальный канон закреплён в стандарте ISO/IEC/IEEE 12207 — это, по сути, словарь процессов жизненного цикла ПО. Читать его целиком не надо, но полезно знать, что он существует: когда энтерпрайз говорит «у нас процессы по 12207», речь именно о нём.

Три вещи, которые важнее самих названий.

Первое: фазы — это виды деятельности, а не отрезки календаря. Даже в самой гибкой команде кто-то формулирует, что делать (требования), кто-то решает, как это будет устроено (проектирование), кто-то проверяет (тестирование). Разница между моделями SDLC — не в том, какие фазы есть, а в том, насколько крупными порциями и как часто их проходят. В скраме вы проходите весь цикл за две недели на кусочек функциональности. В госконтракте — за полтора года на систему целиком. Деятельность одна и та же.

Второе: пунктирные стрелки важнее сплошных. Обратные связи — то, что отличает живой процесс от диаграммы в презентации. Реальный вопрос про любую команду не «какие у вас фазы», а «как быстро информация с правого края доходит до левого». Если пользователь месяц назад сказал, что фича бесполезна, а вы всё ещё её пилите — обратная связь порвана, и никакая методология это не лечит.

Третье: фаза «вывод из эксплуатации» существует, и её почти никогда не планируют. Отсюда системы, которые нельзя выключить, потому что никто не знает, кто ими пользуется, и легаси, живущее втрое дольше проектного срока.

Почему поздние ошибки такие дорогие

Главный экономический факт про SDLC: цена исправления ошибки растёт по мере продвижения вправо, и растёт нелинейно.

Идея восходит к Барри Бёму (Software Engineering Economics, 1981) и с тех пор бесконечно цитируется, часто безответственно — с точными коэффициентами, которых в реальности никто не измерял в вашем проекте. Относитесь к числам как к порядкам величин, а не к константам. Механизм при этом абсолютно реален и его стоит понимать не как «цифру из книжки», а как следствие:

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

Дорого не «исправить», дорого — размотать всё, что выросло поверх.

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

Есть и вторая, зеркальная ошибка: пытаться выяснить всё до конца. Часть неопределённости снимается только кодом. Опыт — это калибровка того, что дешевле уточнить разговором, а что дешевле проверить прототипом за час.

Модели: как одни и те же фазы раскладывают по времени

Разберём главные развилки честно — без «водопад плохой, agile хороший».

Водопад

Проходим все фазы последовательно, каждую доводим до конца, фиксируем результат документом и переходим дальше.

Когда работает: требования действительно известны и не изменятся, цена ошибки в проде запредельна, а сдача результата контрактно привязана к документам. Прошивка кардиостимулятора, бортовое ПО, госсистема с ТЗ по ГОСТ — вполне разумные кандидаты.

Когда не работает: когда требования неизвестны. А в продуктовой разработке они почти всегда неизвестны, потому что заказчик не знает, чего хочет, пока не увидит. Водопад в такой ситуации даёт классический провал: полтора года работы, идеально соответствующей ТЗ, и продукт, который никому не нужен, потому что ТЗ писали по представлениям позапрошлого года.

Любопытная деталь: оригинальная статья Уинстона Ройса 1970 года, из которой вырос «водопад», приводит эту схему как пример того, что не работает, и дальше предлагает итерации и прототипирование. Индустрия скопировала первую картинку и проигнорировала текст.

V-модель

Тот же водопад, но каждому уровню проектирования сопоставлен уровень проверки: системным требованиям — приёмочные тесты, архитектуре — интеграционные, детальному дизайну — юнит-тесты. Ценность в том, что тест-дизайн начинается одновременно с проектированием, а не «потом». Это, кстати, живая идея и вне V-модели: если вы не можете сформулировать, как проверите, что задача сделана, — вы ещё не понимаете задачу.

Итеративные и Agile-подходы

Полный цикл прогоняется на маленьком куске функциональности за короткий срок. Скрам, канбан и прочее — конкретные способы это организовать; подробно они разобраны в треке Управление проектами и Kanban и поток, дублировать не буду.

Что важно понять здесь: итерации не делают разработку быстрее. Суммарной работы столько же или больше — на каждый цикл накладываются расходы на релиз, регресс, планирование. Выигрыш в другом: вы узнаёте о своей ошибке через две недели, а не через год. Это ставка на снижение риска, а не на скорость.

И оборотная сторона, которую в статьях про agile упоминают редко: короткие итерации требуют дешёвого релиза. Если выкатка стоит команде трёх дней ручной работы и согласования с четырьмя отделами, двухнедельные спринты превратятся в фикцию — код будет копиться в ветке release и уезжать раз в квартал, а «спринты» останутся ритуалом на планёрке. Это очень частая картина в компаниях, которые «перешли на agile», не тронув инженерную часть. Настоящая последовательность обратная: сначала автоматизируют путь кода в прод, потом сокращают цикл. Про это — трек DevOps, особенно CI и стратегии релиза.

Что вы увидите в реальной компании

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

Это не признак незрелости. Это нормальное состояние: разные части организации живут в разном темпе, и SDLC — компромисс между ними. Обзорное сравнение моделей есть в материале Модели разработки и Подходы и методологии.

Жизнь одной задачи: что происходит с тикетом

Абстракции становятся понятными на уровне, где вы реально живёте, — на уровне карточки в Jira, YouTrack или Linear.

Несколько наблюдений о том, как это выглядит в жизни, а не на схеме.

Статус In Progress — самый лживый статус в трекере. Он означает и «активно пишу код», и «взял три дня назад, потом отвлекли на инцидент, вернусь завтра». Именно поэтому опытные команды смотрят не на статусы, а на время в статусах: сколько задача провисела в ревью, сколько в блокировке. Метрика lead time (от появления задачи до прода) и cycle time (от начала работы до прода) говорят о процессе больше, чем любая ретроспектива. Про них — DORA и инженерные метрики.

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

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

Часть задач должна умирать в бэклоге. Бэклог, из которого ничего не выкидывают, — это не план, а свалка. Отклонённая задача — здоровый исход.

Жизнь бага: отдельный цикл со своими правилами

Баг проходит другой путь, чем фича, и путать их — источник постоянных конфликтов между разработкой и тестированием.

Что тут стоит знать заранее:

• Приоритет и серьёзность — разные вещи. Severity (насколько страшно технически) ставит тестировщик, priority (когда чиним) — продукт или лид. Падение сервиса для одного клиента из тысячи может быть critical по severity и low по priority. Спор «это же критикал!» обычно возникает от смешения этих двух шкал.
• Deferred — легитимный статус. Часть багов чинить дороже, чем терпеть. Взрослая команда умеет это честно решать и записывать, а не делать вид, что починит «когда-нибудь».
• Cannot reproduce без запроса деталей — плохая практика. Правильный ответ — не закрыть, а вернуть с конкретным вопросом: версия, окружение, шаги, логи, время события.
• Reopened в большом количестве — сигнал о процессе, а не о людях. Обычно означает, что чинят симптом, не разобравшись с причиной, или что нет окружения, где баг воспроизводится.

Кто с кем разговаривает: одна фича от начала до конца

Схема фаз ничего не говорит о самом важном — о людях. Вот та же история, но как последовательность взаимодействий.

Важные оговорки к этой картинке.

Ролей может не быть. В команде из пяти человек аналитик, тестировщик и девопс — это те же разработчики в разных шляпах. Отсутствие роли не означает отсутствие деятельности: если нет тестировщика, тестирование никуда не делось, оно просто ваше. Джуны часто трактуют «у нас нет QA» как «у нас не тестируют» — и приносят в прод очевидные регрессы. Кто есть кто, разбираем в статье Роли и команды.

Стрелка DEV --> SA с вопросом — самая недооценённая на схеме. В любой реальной постановке есть дырки: не описано поведение при пустом значении, при отсутствии прав, при повторной отправке. Разработчик, который эти дырки находит и задаёт вопрос до реализации, ценится сильно выше того, кто «просто быстро кодит». Это, если угодно, короткий ответ на вопрос, за что платят сеньорам.

Последняя стрелка замыкает цикл. SDLC — это петля, а не отрезок. Релиз — не финиш, а точка, где начинают поступать настоящие данные.

Релизный цикл на календаре

Абстрактные «две недели» удобно посмотреть в разрезе дней — так становится видно, почему во вторник перед релизом никто не хочет вливать большую рискованную ветку.

Что здесь видно и чего нет в теории:

• Фазы перекрываются. Тестирование начинается, когда разработка ещё идёт. Никто не ждёт, пока последняя задача будет готова.
• Заморозка кода (code freeze) — реальное ограничение. За день-два до релиза в основную ветку пускают только критичные правки. Задача, доделанная за час до заморозки, скорее всего, уедет в следующий релиз — и это правильно, потому что нетестированный код в релизной сборке дороже, чем неделя ожидания.
• После релиза стоит окно наблюдения. Релиз без наблюдения за метриками — это не релиз, а надежда.
• Ретроспектива в конце — единственная точка, где процесс меняет сам себя. Если её нет или она превращается в формальность, любые проблемы из этого списка будут воспроизводиться бесконечно.

Заметьте: этот график — уже жёсткая версия. Команды с настроенным CI/CD и фича-флагами катят по несколько раз в день, и понятие «релизный цикл» у них растворяется. Это не значит, что фазы исчезли — они просто стали крошечными и непрерывными.

Как это выглядит в коде и конфигах

Значительная часть современного SDLC не описана в документах, а закодирована в репозитории. Это принципиальный сдвиг: процесс, который живёт в конфиге, исполняется всегда, а процесс, который живёт в вики, исполняется, когда о нём вспомнили.

Пример: политика ветвления и качества, выраженная пайплайном.

# .github/workflows/ci.yml — процесс, зафиксированный в коде
name: CI
on:
  pull_request:
    branches: [main]

jobs:
  quality-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Фаза "разработка": статические проверки до запуска кода
      - name: Линтер и форматирование
        run: make lint

      # Фаза "тестирование", нижний уровень пирамиды
      - name: Юнит-тесты с порогом покрытия
        run: make test-unit COVERAGE_MIN=70

      # Проверка контрактов: ломаем ли мы потребителей нашего API
      - name: Контрактные тесты
        run: make test-contract

      # Безопасность: известные уязвимости в зависимостях
      - name: Аудит зависимостей
        run: make audit

      # Проверка миграций: применяются ли они на копии боевой схемы
      - name: Прогон миграций БД
        run: make migrate-check

Каждый шаг здесь — это чья-то фаза жизненного цикла, ставшая автоматической. Пять минут машинного времени вместо получаса ручной проверки и человеческого «вроде посмотрел».

Второй пример — Definition of Done, критерий «задача действительно сделана». Живёт обычно в вики или шаблоне тикета, и это единственный документ трекера, который стоит выучить наизусть в первую неделю:

## Definition of Done
- [ ] Код соответствует критериям приёмки из тикета
- [ ] Покрыт тестами: happy path + значимые крайние случаи
- [ ] Пройдено ревью минимум одним человеком, замечания закрыты
- [ ] CI зелёный, включая линтер и контрактные тесты
- [ ] Миграции обратимы, откат проверен на стенде
- [ ] Логи и метрики добавлены для нового поведения
- [ ] Фича закрыта флагом, если релиз рискованный
- [ ] Документация или changelog обновлены
- [ ] Проверено на препроде тестировщиком или автором

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

Где здесь вы и что реально ждут от разработчика

Полезная и слегка отрезвляющая мысль: написание кода — самая маленькая по времени часть вашей работы и самая заменяемая. Ценность разработчика в команде складывается из другого:

• Понимание, зачем задача. Тот, кто знает цель, замечает, что решение из тикета не достигает цели, и говорит об этом до того, как потрачен месяц.
• Умение работать с неопределённостью. Постановки всегда неполны. Вопрос — рабочий инструмент, а не признак слабости.
• Предсказуемость. «Сделаю к среде» и сделал к среде — ценнее, чем «сделаю за день» и сделал за четыре. Планирование команды строится на ваших оценках; сорванная оценка сдвигает не только вас.
• Ответственность за код после релиза. Разработчик, который смотрит на метрики своей фичи на следующий день, — редкость и большой актив.
• Умение оставить систему в состоянии, пригодном для следующего. Ваш код будет читать человек, у которого нет вашего контекста. Часто этот человек — вы через полгода.

Именно это, а не количество известных фреймворков, отличает грейды. Разбираемся детально в статье Грейды, а как это конвертируется в деньги — в Зарплата и своя цена.

Что ломается на практике: честный список

Ни в одной книге про SDLC этого нет, а встречается это везде.

Фаза требований пропущена, потому что «и так понятно». Задача формулируется как решение, а не как проблема: «добавить кнопку экспорта» вместо «бухгалтеру нужны данные в Excel раз в месяц». Разработчик делает кнопку, бухгалтер продолжает копировать вручную, потому что ему нужен был другой формат. Симптом — тикеты, в которых нет ни слова о том, зачем.

Проектирование делается в голове одного человека и никуда не записывается. Работает, пока этот человек здесь. Через полгода после его ухода команда археологически восстанавливает замысел по коду.

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

Релиз — героическое событие. Ночь, вся команда на связи, чек-лист на двадцать пунктов, откат — «ну, попробуем из бэкапа». Каждый релиз страшный → релизят реже → в каждом релизе больше изменений → ещё страшнее. Разрывается это только автоматизацией и уменьшением порций, а не увеличением осторожности.

Эксплуатация отделена от разработки стеной. «Мы написали, дальше не наше». Обратная связь о том, как код ведёт себя в реальности, до авторов не доходит — и они годами повторяют те же ошибки, искренне не зная об этом.

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

Процесс скопирован без контекста. «В Спотифае так» — не аргумент. Команда из шести человек внедряет трёхуровневую систему согласования архитектуры и удивляется, почему стало медленнее.

Метрики превращаются в цель. Начали мерить количество закрытых задач — задачи мельчают; количество строк — код пухнет; покрытие тестами — появляются тесты без ассертов. Классический закон Гудхарта: мера, ставшая целью, перестаёт быть мерой.

Энтерпрайз и стартап: один цикл, разные настройки

Ни один из полюсов не «правильнее» — они оптимизированы под разную цену ошибки. Подробно — в статьях Энтерпрайз изнутри и Стартап изнутри, здесь только суть на уровне цикла.

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

Мини-чеклист: как разобраться в SDLC на новом месте

Работает на первой неделе на любой позиции. Не читайте вики — она устарела; спрашивайте людей.

1. Откуда берутся задачи? Кто может положить мне задачу, кто решает приоритет, что происходит, если задачу принёс кто-то мимо процесса.
2. Что такое «готово»? Есть ли Definition of Done, обязательно ли ревью, кто может смержить в основную ветку.
3. Как код попадает в прод? Сколько шагов, сколько времени, кто нажимает кнопку, как выглядит откат. Попросите провести вас по одному релизу целиком.
4. Что происходит, когда ломается? Есть ли дежурства, куда приходят алерты, кто их разбирает ночью, пишут ли постмортемы.
5. Где живёт правда о системе? Схемы, ADR, диаграммы — или всё в голове у Пети.
6. Как меняется сам процесс? Есть ли ретро, доходит ли что-то до реальных изменений.

Ответы на эти шесть вопросов дают о компании больше, чем любое собеседование, — и, кстати, эти же вопросы отлично работают на собеседовании, когда вам говорят «а теперь вы спрашивайте». Про это — в статье Как проходить собеседования.

Итог

• SDLC — это не методология, а карта полного пути: от появления проблемы до вывода системы из эксплуатации.
• Фазы — виды деятельности, а не отрезки календаря. Они есть всегда, даже когда не названы.
• Модели различаются размером порции и частотой прохождения цикла. Водопад, V-модель, итерации — инструменты под разную цену ошибки, а не стадии прогресса человечества.
• Цена исправления растёт вправо нелинейно, поэтому вопрос, заданный вовремя, — самая выгодная операция в цикле.
• Обратные связи важнее фаз: живой процесс определяется тем, как быстро информация с правого края возвращается на левый.
• Реальность всегда грязнее схемы, и это нормально. Ненормально — когда никто не замечает, что грязно.

Что почитать

• ISO/IEC/IEEE 12207 — канонический словарь процессов жизненного цикла ПО.
• Winston Royce, Managing the Development of Large Software Systems (1970) — та самая статья про водопад, которую стоит прочитать целиком.
• Agile Manifesto — четыре строчки, из которых выросла индустрия ритуалов. Есть русский перевод.
• Jez Humble, David Farley, Continuous Delivery (2010) — про то, как релиз перестаёт быть событием.
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (2018) и открытые отчёты DORA — эмпирические данные о том, какие практики реально коррелируют с результатом.
• martinfowler.com — раздел про delivery и continuous integration, лучший бесплатный источник по инженерным практикам.
• Google SRE Book, sre.google/books — про правую часть цикла: эксплуатацию, дежурства, постмортемы.

Что дальше

Мы прошли карту целиком. Теперь спускаемся в первую фазу и разбираемся, откуда на самом деле берутся задачи в трекере, кто их формулирует и почему постановка «сделай кнопку» — это уже проваленный этап анализа.

Требования и аналитика: откуда вообще берутся задачи в трекере