Методология и жизненный цикл ПО — итоги
Миграции в релизе, ETL, конфиги сред — Пакетная работа, ETL, конфигурации. Карта — о разделе.
Кратко — что стоит унести из раздела "Методология и жизненный цикл ПО". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Ситуации, когда процесс "на бумаге" расходится с реальностью — выбор Waterfall или Agile, споры о спринтах, ГОСТ и "Agile в названии". Определения для самопроверки — в чек-листе.
Вопрос. В компании "Scrum", а по факту — дедлайны без итераций и без Product Owner. Это Scrum?
Ответ. Нет — это ярлык без практик. Проверьте роли, инкременты, ретро и право менять приоритеты. Если их нет — честнее назвать процесс и чинить его, чем спорить о терминах. Подробнее — Agile, Scrum.
Вопрос. Заказчик требует полное ТЗ до старта, команда хочет Agile — можно совместить?
Ответ. Часто через гибрид: юридически фиксируют рамки и этапы, внутри — итерации и уточнение деталей. Главное — прописать, как оформляются изменения scope. Подробнее здесь — Методологии ГИС, Жизненный цикл ПО.
Вопрос. Waterfall "устарел" — его вообще где-то применяют?
Ответ. Да, где жёсткая регуляторика, фиксированный контракт и редкие релизы — медицина, авионика, часть госсектора. Проблема не в модели, а в несоответствии контексту. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Тестирование "в конце проекта" — все баги находят QA за две недели?
Ответ. Так не бывает: дефекты архитектуры и требований всплывают поздно и дорого. Даже в Waterfall ранние ревью и модульные тесты снижают риск; в Agile тесты встроены в каждый инкремент. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Спринт 2 недели, но половину "срываем" — укоротить до недели?
Ответ. Сначала найдите причину срыва: не готовый бэклог, внешние блокеры, переоценка capacity. Укорочение спринта без этого только ускорит хаос. Подробнее здесь — Жизненный цикл ПО, Scrum.
Вопрос. Velocity упал — руководство требует "вернуть цифры". Что ответить?
Ответ. Velocity — внутренняя мера команды, не KPI для наказания. Сравнивайте тренды и причины: новые люди, техдолг, изменившийся DoD. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Kanban "без спринтов" — значит, планирования нет?
Ответ. Планирование есть, но через поток и WIP-лимиты, а не через фиксированный timebox. Подходит поддержке и смешанному потоку инцидентов и фич. Подробнее здесь — Жизненный цикл ПО.
Вопрос. WIP-лимит 3, а менеджер просит "взять ещё две срочные" — нарушать?
Ответ. Лимит как раз для того, чтобы показать цену срочности: что остановить или кого освободить. Без trade-off WIP бессмысленен. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Definition of Done есть в Confluence, но в prod попадает без тестов — почему?
Ответ. DoD не enforced: нет чек-листа в PR, нет gate в CI/CD, нет последствий. Документ без проверки — декларация. Подробнее здесь — Жизненный цикл ПО.
Вопрос. "Готово" для разработчика и для заказчика — разные вещи. Как согласовать?
Ответ. Явный DoD + критерии приёмки на задачу и демо инкремента. "Merged в main" ≠ "можно показывать пользователю". Подробнее здесь — Жизненный цикл ПО.
Вопрос. DevOps поставили Jenkins — мы стали DevOps-командой?
Ответ. DevOps — это культура совместной ответственности за доставку и эксплуатацию, а не только пайплайн. Без обратной связи из production и автотестов CI/CD остаётся кнопкой деплоя. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Госзаказ: ТЗ на 300 страниц устарело через месяц — что делать legally?
Ответ. Оформляйте допсоглашение или протокол изменений по регламенту контракта; "тихие" доработки без бумаги — риск при приёмке и аудите. Подробнее здесь — Методологии ГИС.
Вопрос. Подрядчик делает Scrum, заказчик ждёт акт по ГОСТ в конце — где ломается?
Ответ. На стыке двух миров отчётности: нужен мост — промежуточные акты, протоколы инкрементов, согласованная матрица артефактов. Подробнее здесь — Методологии ГИС.
Вопрос. Ретроспектива превратилась в жалобы на заказчика — как вернуть пользу?
Ответ. Фокус на одном улучшении процесса, который команда контролирует, с владельцем и сроком. Внешние факторы — отдельный список для эскалации PM. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Big design up front vs "без архитектуры" — куда склоняться?
Ответ. Зависит от стоимости ошибки и стабильности домена. Банковское ядро требует контрактов заранее; MVP стартапа — эволюционного дизайна с тестами. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Техдолг не планируют в спринт — "потом". Когда "потом" наступит?
Ответ. Обычно в момент инцидента на проде или остановки найма. Здоровая практика — доля capacity (10–20%) или явные epic'и долга в бэклоге. Подробнее здесь — Жизненный цикл ПО.
Вопрос. CI/CD есть, но релиз раз в квартал — в чём противоречие?
Ответ. Инфраструктура готова к частым поставкам, но процесс приёмки, регресс или страх тормозят. Метрика "частота релизов" показывает реальную зрелость, а не наличие Jenkins. Подробнее здесь — Жизненный цикл ПО.
Вопрос. User stories без acceptance criteria — QA узнаёт ожидания в последний день.
Ответ. Задача не Ready, пока нет проверяемых критериев. DoR защищает команду от "мы имели в виду другое". Подробнее здесь — Жизненный цикл ПО.
Вопрос. Заказчик не ходит на review — инкременты "в вакууме".
Ответ. Без feedback loop Agile теряет смысл. Зафиксируйте делегата с правом решений или смените формат (запись demo, письменное OK). Подробнее здесь — Жизненный цикл ПО.
Вопрос. Jira с колонками "спринт 1, спринт 2" — это уже Scrum?
Ответ. Инструмент не создаёт методологию. Нужны роли, ритуалы, инкремент и адаптация плана. Иначе это Kanban-доска с недельными подписями. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Команда поддержки и команда фич в одном бэклоге — постоянные конфликты приоритетов.
Ответ. Разделите потоки или WIP, договоритесь о SLA на инциденты и резервируйте capacity на поддержку. Scrumban и два swimlane — типичное решение. Подробнее здесь — Жизненный цикл ПО.
Вопрос. "Мы Agile, документов не ведём" — заказчик на приёмке требует ПМИ.
Ответ. Agile не отменяет обязательства контракта. Wiki и stories дополняют формальный комплект, а не заменяют его в регулируемых проектах. Подробнее здесь — Методологии ГИС, Техническое письмо.
Вопрос. Верификация прошла, пользователи недовольны — методология виновата?
Ответ. Скорее провалилась валидация — строили по ТЗ, но не то, что нужно рынку. Нужны исследования, demo, метрики использования. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Новый разработчик: "какую методологию учить первой?"
Ответ. Сначала SDLC и словарь (фазы, инкремент, бэклог), затем то, что реально использует ваша команда. Универсального "лучшего" подхода нет — есть соответствие контексту. Подробнее здесь — Жизненный цикл ПО.
Вопрос. SAFe, LeSS, Nexus — нужно ли джуну это сейчас?
Ответ. Достаточно понимать, что это масштабирование Agile на много команд. Углубляться — когда попадёте в такой контур; базовый Scrum/Kanban важнее. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Проект провалился — ищут виноватого разработчика, а не процесс.
Ответ. Зрелый post-mortem смотрит на систему: требования, оценки, риски, коммуникации. Blame culture скрывает повторяющиеся сбои. Подробнее здесь — Жизненный цикл ПО, Команда и управление.
Ниже — формулировки, которые часто вводят в Google и Яндексе; короткий ответ и ссылка на материал раздела.
Вопрос. Жизненный цикл программного обеспечения (SDLC) — что это?
Ответ. Путь продукта от идеи до вывода из эксплуатации: требования, проектирование, разработка, тесты, внедрение, сопровождение. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Waterfall (водопад) в разработке ПО — что за модель?
Ответ. Последовательные фазы с формальными переходами; изменения дороги. Подходит при жёстком scope и регуляторике. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Agile и Waterfall — в чём разница?
Ответ. Waterfall планирует заранее; Agile итерациями уточняет требования и поставляет инкременты. Выбор — по стабильности требований и контракту. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Scrum — что это простыми словами?
Ответ. Фреймворк Agile: спринты 1–4 недели, роли (PO, SM, команда), инкремент и ретроспектива. Подробнее здесь — Жизненный цикл ПО, Scrum.
Вопрос. Kanban в IT — как работает?
Ответ. Визуальный поток задач с WIP-лимитами без обязательных спринтов. Удобен для поддержки и смешанного потока. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Сколько длится спринт в Scrum?
Ответ. Обычно 1–4 недели, фиксированная длина; за спринт — готовый инкремент. Подробнее здесь — Scrum.
Вопрос. Definition of Done (DoD) — что это?
Ответ. Согласованный чек-лист "задача/инкремент готов, когда…" (код, тесты, doc, деплой). Подробнее здесь — Жизненный цикл ПО.
Вопрос. Product backlog — что это?
Ответ. Приоритизированный список работ и требований продукта; ведёт Product Owner. Подробнее здесь — Жизненный цикл ПО.
Вопрос. DevOps — что это в разработке?
Ответ. Культура и практики совместной доставки и эксплуатации: CI/CD, мониторинг, обратная связь из production. Подробнее здесь — Жизненный цикл ПО.
Вопрос. CI/CD — что это простыми словами?
Ответ. Автосборка, тесты и деплой при изменении кода — практика доставки внутри DevOps, не отдельная "методология". Подробнее здесь — Жизненный цикл ПО.
Вопрос. User story — что это?
Ответ. Требование от лица пользователя с ценностью и критериями приёмки, а не технический таск. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Story points или человеко-часы — что выбрать?
Ответ. Points — для относительной оценки в Agile; часы — для контрактов и календарного плана. Часто используют оба на разных уровнях. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Water-Scrum-Fall — что за гибрид?
Ответ. Формальный контракт и приёмка как в Waterfall, внутри — Scrum-итерации. Типично для enterprise и госсектора. Подробнее здесь — Методологии ГИС.
Вопрос. Методология разработки государственных IT-систем — особенности?
Ответ. ТЗ как юридический акт, ГОСТ, поэтапная приёмка, ограничения на изменения без допсоглашения. Подробнее здесь — Методологии ГИС.
Вопрос. Инкремент в Agile — что означает?
Ответ. Часть продукта, потенциально готовая к поставке пользователю, а не "полуготовый код в ветке". Подробнее здесь — Жизненный цикл ПО.
Вопрос. WIP limit в Kanban — зачем ограничивать задачи в работе?
Ответ. Снижает многозадачность и ускоряет завершение started work. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Sprint retrospective — зачем нужна?
Ответ. Команда улучшает процесс, а не ищет виноватых: что оставить, что изменить. Подробнее здесь — Scrum.
Вопрос. Scrum Master — кто это и чем не PM?
Ответ. Scrum Master — фасилитатор процесса Scrum: снимает impediments, не распоряжается людьми как начальник и не владеет backlog. Подробнее здесь — Scrum.
Вопрос. Product Owner — какие обязанности?
Ответ. Ценность продукта, приоритет backlog, принятие инкремента. Представляет интересы заказчика/рынка. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Технический долг — что это в Agile?
Ответ. Накопленные упрощения и долги качества, замедляющие будущие изменения. Планируют в backlog, а не скрывают. Подробнее здесь — Жизненный цикл ПО.
Вопрос. Big design up front (BDUF) — когда оправдан?
Ответ. Когда стоимость ошибки архитектуры высока и требования стабильны (ядро, регуляторика). Подробнее здесь — Жизненный цикл ПО.
Вопрос. "Agile" в названии отдела, но процесс как Waterfall — что проверить?
Ответ. Пройдите чек-лист самопроверки: роли, инкременты, обратная связь, право менять приоритеты. Подробнее здесь — Итоги.
Что запомнить
Методологии разработки программного обеспечения — это стратегии управления неопределённостью. Выбор подхода зависит от стабильности требований, регуляторики и зрелости команды.
| Подход | Суть в одной фразе | Типичный контекст |
|---|---|---|
| Waterfall | Фазы последовательны, изменения формализованы | Регуляторика, фиксированный scope, ГОСТ |
| Agile | Ценность, сотрудничество, готовность к изменениям | Продукты с уточняющейся обратной связью |
| Scrum | Спринты, роли, инкремент каждые 1–4 недели | Команды с вовлечённым заказчиком |
| Kanban | Поток задач, WIP-лимиты, без обязательных спринтов | Поддержка, инциденты, смешанный поток |
| DevOps | Автоматизация доставки и обратная связь из production | Частые релизы, SaaS, зрелая инженерия |
На практике часто применяют гибриды (Water-Scrum-Fall): юридически фиксируют объём, внутри — итеративная разработка. Подробнее — в основной главе и в материале про ГИС.
Главный вывод: методология — это отношение к изменениям. Waterfall минимизирует их на бумаге; Agile встраивает их в процесс. Инструменты (Jira, "спринты" в названии) без практик не делают команду Agile — проверьте себя по чек-листу.
Куда идти дальше
Полный маршрут — на странице о разделе.
Проверьте себя: Чек-лист самопроверки.