¶ Блок 2 "Методологии управления проектами в разработке ПО"
¶ Зачем вообще нужны методологии
Методология — это набор договорённостей о том, как команда работает над проектом:
-
как планируются задачи,
-
как принимаются решения,
-
как отслеживается прогресс,
-
и как команда понимает, что результат достигнут.
В разработке программного обеспечения методологии нужны не ради терминов и процессов,
а чтобы работа была предсказуемой и управляемой.
¶ Какие проблемы решают методологии
Методологии помогают команде:
-
не утонуть в задачах
Когда задач много, без правил легко потерять фокус и делать не то, что действительно важно. -
понимать, что делать дальше
Всегда должно быть ясно:-
какая задача в работе,
-
что идёт следующей,
-
кто за что отвечает.
-
-
контролировать сроки и бюджет
Процессы позволяют заранее видеть риски и вовремя корректировать план. -
синхронизироваться с заказчиком
Методология задаёт точки контроля, где можно показать прогресс и обсудить изменения.
¶ Что происходит без методологии
Если договорённостей нет, проект часто скатывается в хаос:
-
задачи появляются спонтанно и «всё срочно»,
-
приоритеты меняются каждый день,
-
команда постоянно переключается,
-
сроки срываются,
-
участники выгорают,
-
заказчик разочарован результатом.
Даже сильная команда без понятного процесса работает нестабильно.
¶ Важно помнить
Методологии — не догма.
На практике редко используют «чистый» Scrum, Kanban или Waterfall.
Опытные менеджеры адаптируют подход под реальность проекта.
Самые распространённые гибриды:
-
Waterfall + Scrum — когда есть фиксированный план, но разработка идёт итерациями.
-
Scrum + Kanban (Scrumban) — когда есть спринты, но поток задач более гибкий.
Методология должна помогать команде, а не мешать ей.
¶ Проектный треугольник
Любой проект можно описать через три ключевых параметра:
-
сроки — когда результат должен быть готов,
-
бюджет — сколько ресурсов можно потратить,
-
объём работ (содержание) — что именно должно быть сделано.
Эти параметры образуют так называемый проектный треугольник.
¶ Как работает проектный треугольник
Все стороны треугольника взаимосвязаны.
Изменение одного параметра неизбежно влияет на два других.
Примеры:
-
Нужно сократить сроки
→ либо увеличивается бюджет (больше людей, переработки),
→ либо сокращается объём функциональности. -
Нужно уменьшить бюджет
→ либо растягиваются сроки,
→ либо уменьшается объём работ. -
Нужно добавить функциональность
→ либо требуется больше времени,
→ либо больший бюджет.
Невозможно изменить только одну сторону, не затронув остальные.
¶ Роль менеджера в работе с треугольником
Проект-менеджер отвечает за то, чтобы:
-
ожидания всех сторон были согласованы,
-
изменения не разрушали баланс проекта,
-
решения принимались осознанно, а не «по умолчанию».
Важно не просто сказать «да» на новое требование,
а объяснить какую цену это имеет в сроках и деньгах.
¶ Практический пример
Заказчик говорит:
«Давайте добавим ещё одну функцию, это же мелочь»
Менеджер должен ответить:
-
сколько времени это займёт,
-
как повлияет на релиз,
-
нужен ли дополнительный бюджет,
-
или от чего придётся отказаться.
Это и есть управление проектным треугольником на практике.
¶ Жизненный цикл разработки ПО (SDLC)
Прежде чем говорить о методологиях управления проектами, важно разобраться с SDLC — Software Development Life Cycle.
SDLC — это модель, которая описывает, через какие этапы проходит программный продукт
от идеи до эксплуатации и развития.
Практически все IT-проекты, независимо от выбранной методологии,
так или иначе проходят одни и те же шаги.
Разница лишь в том, в каком порядке и с какой степенью гибкости они выполняются.
¶ Основные этапы SDLC
¶ 1. Планирование
На этом этапе формируется общее понимание проекта.
Что происходит:
-
определяется цель продукта,
-
формулируется проблема, которую он решает,
-
собираются первичные требования,
-
оцениваются сроки, бюджет и ресурсы.
По сути, это:
-
брифинг,
-
предварительная оценка,
-
фиксация договорённостей с заказчиком.
Результат этапа — понимание, зачем нужен проект и стоит ли его начинать.
¶ 2. Анализ требований
Этап детализации и уточнения.
Что происходит:
-
требования переводятся из «хочу» в конкретные формулировки,
-
анализируются бизнес-процессы,
-
выявляются ограничения и риски,
-
формируется техническое задание или backlog.
Здесь важно задать вопросы:
-
кто будет пользоваться продуктом,
-
какие сценарии использования ключевые,
-
что является обязательным, а что — опциональным.
Ошибка на этом этапе почти всегда дорого стоит позже.
¶ 3. Проектирование
На этапе проектирования команда решает, как именно будет работать система.
Сюда входит:
-
проектирование архитектуры,
-
выбор технологий,
-
проектирование базы данных,
-
описание API,
-
разработка пользовательских сценариев и интерфейсов.
Чем сложнее проект, тем важнее этот этап.
Результат — понятный план реализации, по которому можно разрабатывать продукт.
¶ 4. Разработка
Непосредственное создание продукта.
Что происходит:
-
пишется код,
-
создаются базы данных,
-
реализуется бизнес-логика,
-
интегрируются внешние сервисы.
В современных проектах разработка почти всегда сопровождается:
-
код-ревью,
-
автотестами,
-
CI/CD.
¶ 5. Тестирование
Проверка того, что продукт работает так, как задумывалось.
На этом этапе:
-
проверяется соответствие требованиям,
-
находятся и исправляются ошибки,
-
выполняется регрессионное тестирование,
-
оценивается стабильность системы.
Тестирование — не отдельный «финальный» шаг, а постоянный процесс,
который начинается задолго до релиза.
¶ 6. Внедрение
Запуск продукта в рабочей среде.
Сюда входит:
-
развёртывание на продакшене,
-
настройка инфраструктуры,
-
миграция данных (если требуется),
-
выпуск релиза для пользователей.
Часто этап внедрения тесно связан с DevOps-процессами и CI/CD.
¶ 7. Сопровождение и развитие
После релиза работа не заканчивается.
На этом этапе:
-
устраняются баги,
-
анализируется поведение пользователей,
-
добавляется новый функционал,
-
улучшается производительность и стабильность.
Большинство продуктов живёт именно на этом этапе большую часть времени.
¶ Модели SDLC
Существует два базовых подхода к организации жизненного цикла.
¶ Каскадная модель (Waterfall)
Все этапы идут строго последовательно. Каждый следующий начинается только после полного завершения предыдущего.
Плюсы:
-
высокая предсказуемость,
-
понятные сроки и бюджет,
-
удобна для проектов с жёсткими требованиями.
Минусы:
-
почти невозможно вносить изменения по ходу проекта,
-
ошибки часто обнаруживаются слишком поздно.
¶ Итеративная модель (Scrum)
Разработка ведётся циклами (итерациями). В каждой итерации продукт улучшается и дополняется.
Плюсы:
-
гибкость,
-
быстрая реакция на изменения,
-
снижение рисков.
Минусы:
-
сложнее точно оценить сроки и бюджет,
-
возможны перерасходы ресурсов.
¶ Waterfall
Waterfall основан на каскадной модели SDLC.
Название говорит само за себя — этапы проекта «стекают» один за другим, как водопад.
Проект заранее разбивается на крупные этапы, и для каждого из них фиксируются:
-
объём работ,
-
сроки выполнения,
-
критерии приёмки результата.
Переход к следующему этапу возможен только после полного завершения предыдущего.
В классическом Waterfall возврат назад либо невозможен, либо крайне дорог.
¶ Ключевые особенности Waterfall
-
Фиксированные требования
Все требования определяются и утверждаются до начала разработки. -
Заранее согласованный бюджет
Стоимость проекта известна на старте и редко меняется. -
Жёсткие сроки
План строится на основе заранее определённых этапов. -
Большое внимание к документации
Документы играют ключевую роль: ТЗ, спецификации, акты приёмки.
¶ Как выглядит Waterfall на практике
Пример типового потока:
Планирование → Анализ → Проектирование → Разработка → Тестирование → Внедрение
Каждый этап закрывается формально:
-
согласованием документов,
-
подписанием результатов,
-
переходом к следующей фазе.
¶ Плюсы Waterfall
-
высокая предсказуемость,
-
понятные сроки и бюджет,
-
удобно работать с контрактами и регламентами,
-
хорошо подходит для формализованных проектов.
¶ Минусы Waterfall
-
изменения по ходу проекта почти невозможны,
-
ошибки в требованиях выявляются слишком поздно,
-
пользователь видит продукт только ближе к концу.
¶ Где Waterfall подходит лучше всего
-
государственные проекты,
-
промышленность и инфраструктура,
-
системы с жёсткими нормативными требованиями,
-
проекты, где требования известны заранее и редко меняются.
¶ Agile
Agile — это не конкретная методология, а подход к мышлению и организации работы.
В отличие от Waterfall, Agile допускает:
-
изменения требований на любом этапе,
-
постепенное развитие продукта,
-
постоянную обратную связь.
Работа ведётся короткими итерациями,
а продукт развивается шаг за шагом.
¶ Базовые принципы Agile
Agile опирается на ценности, сформулированные в Agile Manifesto:
-
люди и взаимодействие важнее процессов и инструментов,
-
работающий продукт важнее подробной документации,
-
сотрудничество с заказчиком важнее формальных договорённостей,
-
готовность к изменениям важнее следования плану.
Это не означает отказ от процессов, документации или планов —
они просто не должны мешать созданию ценности.
¶ Когда Agile особенно полезен
-
требования меняются по ходу проекта,
-
продукт развивается на основе обратной связи,
-
важна скорость вывода результата,
-
нет полной уверенности в конечном виде продукта.
¶ Scrum
Scrum — один из самых популярных фреймворков, реализующих идеи Agile.
Он хорошо подходит для проектов с:
-
высокой неопределённостью,
-
регулярными изменениями,
-
постоянной обратной связью от заказчика или пользователей.
В отличие от Agile как философии,
Scrum имеет чёткие роли, события и артефакты.
Если их не соблюдать — это уже не Scrum.
¶ Scrum-команда
Команда небольшая (до 10 человек), кроссфункциональная и самоорганизующаяся.
¶ Основные роли
-
Product Owner
Отвечает за видение продукта и приоритизацию бэклога.
Много взаимодействует с заказчиком и командой. -
Scrum Master
Помогает команде работать эффективно, устраняет препятствия, фасилитирует встречи. -
Команда разработки
Создаёт инкременты продукта каждый спринт.
¶ Артефакты Scrum
-
Product Backlog — список всех задач и идей по продукту.
-
Sprint Backlog — задачи, выбранные на текущий спринт.
-
Increment — готовый, работающий результат спринта.
¶ Принципы Scrum
Scrum основан на трёх ключевых принципах:
-
прозрачность — процесс и результаты видны всем участникам,
-
инспекция — регулярная проверка прогресса,
-
адаптация — корректировка плана и процесса по результатам проверки.
¶ События Scrum
-
Спринт
Фиксированный период работы (обычно 1–2 недели, максимум 4). -
Планирование спринта
Определение цели спринта и задач для её достижения. -
Daily Standup
Короткая ежедневная синхронизация команды. -
Sprint Review
Демонстрация результата спринта и сбор обратной связи. -
Sprint Retrospective
Анализ работы команды и поиск способов улучшения процесса. -
Refinement
Регулярное уточнение, декомпозиция и оценка задач бэклога.
¶ Планирование и оценка
В Scrum используются:
-
Story Points
Относительная оценка сложности задач. -
Velocity
Среднее количество Story Points, которое команда выполняет за спринт. -
Burndown Chart
График, показывающий оставшийся объём работы в спринте. -
Definition of Ready (DoR)
Критерии, по которым задача готова к взятию в спринт. -
Definition of Done (DoD) и Acceptance Criteria
Критерии, по которым задача считается завершённой и принятой.
¶ Когда выбирать Scrum, а когда Waterfall
Выбор методологии — это не вопрос «что моднее», а вопрос контекста проекта:
типа продукта, рисков, требований и зрелости команды.
¶ Когда подходит Scrum
Scrum стоит выбирать, если:
-
требования меняются по ходу проекта
На старте нет полного понимания, каким должен быть конечный продукт, и это нормально. -
важна регулярная обратная связь
Заказчик или пользователи готовы регулярно смотреть результат и давать фидбек. -
команда самостоятельная и достаточно опытная
Участники умеют планировать свою работу и брать ответственность за результат. -
продукт развивается итеративно
Ценность поставляется постепенно: сначала базовый функционал, затем улучшения.
Примеры проектов для Scrum:
-
веб-сервисы и SaaS-продукты,
-
мобильные приложения,
-
стартапы,
-
внутренние IT-системы компаний.
¶ Когда лучше выбрать Waterfall
Waterfall будет более уместен, если:
-
требования жёстко зафиксированы
Функциональность известна заранее и не должна меняться. -
высокая цена ошибки
Ошибки могут привести к серьёзным последствиям: финансовым, юридическим или техническим. -
нужен строгий контроль и формальная документация
Процесс должен быть максимально прозрачным и проверяемым. -
проект связан с регуляторными ограничениями
Требуются согласования, сертификация и соответствие стандартам.
Примеры проектов для Waterfall:
-
государственные системы,
-
банковское и страховое ПО,
-
промышленные и инфраструктурные решения,
-
системы, связанные с безопасностью.
¶ Важное ограничение Scrum
Scrum плохо подходит для проектов, где:
-
заказчик не готов регулярно участвовать в процессе,
-
команда неопытна и нуждается в жёстком управлении,
-
ошибки недопустимы.
В таких случаях гибкость Scrum превращается в источник рисков.
¶ Kanban
Kanban — это метод управления потоком задач с акцентом на визуализацию работы и баланс нагрузки.
В отличие от Scrum, Kanban:
-
не требует спринтов,
-
не вводит обязательных ролей и событий,
-
может внедряться постепенно.
¶ Как работает Kanban
Все задачи отображаются на доске и проходят через стадии выполнения, например:
Очередь → В работе → На проверке → Готово
Команда фокусируется не на том, чтобы начать больше задач, а на том, чтобы быстрее завершать начатые.
¶ Основные идеи Kanban
-
Визуализация процесса
Вся работа видна команде и стейкхолдерам. -
Ограничение количества задач в работе (WIP-лимиты)
Помогает избежать перегрузки и повышает качество. -
Управление потоком
Анализируется скорость прохождения задач и выявляются узкие места. -
Непрерывное улучшение
Процесс регулярно пересматривается и оптимизируется.
¶ Где Kanban особенно эффективен
-
поддержка и сопровождение продуктов,
-
команды с постоянным потоком задач,
-
проекты без чётко выраженных итераций,
-
как дополнение к Scrum
¶ Kanban и Scrum — это одно и то же?
Нет.
Scrum — строгий фреймворк с обязательными ролями и событиями.
Kanban — набор принципов и практик без жёстких рамок.
Именно поэтому Kanban часто используют вместе со Scrum, усиливая гибкость команды.