Не Waterfall единым: топ неочевидных методов управления командой разработки

Расскажем о том, какие существуют неочевидные методы управления проектами в команде разработки в отрыве от известных Kanbanов и Scrumов

Обложка: Не Waterfall единым: топ неочевидных методов управления командой разработки

Многие знают, что Agile и Waterfall — два кита, на которых держится планета project-менеджеров. Но ими все не ограничивается. Существуют методы управления проектами, которые не только упрощают процесс взаимодействия внутри команды, но и выводят продукты на новый уровень. Рассмотрим их подробнее.

PRINCE2

PRINCE2 (Projects in Controlled Environments) — это методология управления проектами, разработанная в Великобритании в 1980-х годах (удивительно, что она до сих пор — британский стандарт). Предлагает структурированную схему ведения проектов различного масштаба и сложности. Основные принципы PRINCE2 заключаются в ориентации на бизнес-цели и поэтапное управление продуктом (stage-by-stage).

Ключевые ценности Prince2

Процесс разработки по PRINCE2

Процесс разработки по методологии PRINCE2 состоит из семи взаимосвязанных этапов. Далее на примере конкретного проекта рассмотрим каждый.

Наш проект: Разработка нового модуля для корпоративной системы управления ресурсами (ERP).

1. Создаем проектный устав (Project Initiation Documentation):

  • Цель проекта: Разработать новый модуль управления запасами для корпоративной ERP-системы.
  • Руководитель проекта: Александр Иванов, менеджер проектов.
  • Проектная группа: Ведущие разработчики, аналитик, тестировщик, представитель бизнес-подразделения.
  • Структура управления: Руководитель проекта, Проектный комитет, Группа пользователей.

2. Планируем (Project Planning):

  • Этапы проекта: Анализ требований, Проектирование, Разработка, Тестирование, Внедрение.
  • Сроки: 4 месяца.
  • Бюджет: 500 000 рублей.

3. Запускаем работу (Starting up a Project):

  • Проводим встречу по запуску проекта, знакомим команду с целями, ролями и ответственностью.
  • Обязательно подтверждаем готовность команды начинать работу.

4. Управляем этапами проекта (Controlling a Stage):

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

5. Управляем продуктами проекта (Managing Product Delivery):

  • Организуем командную работу по выполнению запланированных задач разработки.
  • Осуществляем контроль качества промежуточных продуктов (архитектурный дизайн, прототипы, исходный код).

6. Управляем границами проекта (Managing Stage Boundaries):

  • Проводим оценку достигнутых результатов и готовность к переходу на следующий этап.
  • Корректируем план проекта с учетом изменений, рисков и уроков предыдущих этапов.
  • Получаем одобрение Проектного комитета и переходим к следующему этапу.

7. Закрываем проект (Closing a Project):

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

Плюсы и минусы PRINCE2

Плюсы:

  • Фокусируется на достижении бизнес-выгод и оправдании инвестиций в проект.
  • Позволяет адаптировать методологию к специфике каждого проекта, что повышает её применимость в разных контекстах.
  • Определяет ключевые роли, такие как Спонсор, Менеджер проекта и Команда управления проектом. Спонсор проекта отвечает за достижение бизнес-целей, а менеджер — за оперативное управление.

Минусы:

  • Полное внедрение PRINCE2 требует значительных усилий по обучению персонала и перестройке организационных процессов. Компании, привыкшие к более гибким подходам, могут испытывать трудности при переходе на строгую методологию.
  • Из-за большого количества документации и отчётности PRINCE2 может кажется излишне бюрократичной.
  • Несмотря на возможность адаптации, модель всё же остаётся более жёсткой методологией по сравнению с Agile-подходами.
  • PRINCE2 часто требует интеграции с другими методиками (например, со Scrum для разработки).

Для каких IT-проектов подходит PRINCE2

PRINCE2 эффективен для крупных и сложных IT-проектов, где требуется высокий уровень контроля, управления рисками и формализованная отчетность. Примеры подходящих IT-проектов:

  • Внедрение ERP, CRM и других корпоративных систем.
  • Разработка критически важных информационных систем.
  • Крупные интеграционные и миграционные проекты.
  • Модернизация legacy-приложений и IT-инфраструктуры.
  • Реализация ИТ-инициатив в госсекторе и крупных корпорациях.

DSDM

DSDM (Dynamic Systems Development Method) — это гибкая методология управления проектами, которая была разработана в 1994 году группой независимых консультантов. В отличие от традиционных каскадных подходов DSDM ориентирован на быструю разработку и итеративное улучшение продукта. Важно, чтобы при разработке проекта конечные пользователи были вовлечены во все этапы (так можно внести правки еще на первых стадиях).

Принципы DSDM

Процесс разработки по DSDM

Процесс разработки заключается в итеративном (поэтапном и ориентированном на заказчика) и инкрементальном (последовательном) подходах к разработке. Ниже рассмотрим 7 этапов. 

Наш проект: Разработка нового веб-приложения для учёта и анализа продаж в компании

1. Предисловие (Preproject):

  • Определяем бизнес-требования к новому веб-приложению.
  • Формируем кросс-функциональную команду проекта, включающую бизнес-представителей, разработчиков, тестировщиков и аналитиков.
  • Утверждаем сроки, бюджет и приоритеты для реализации проекта.

2. Исследование (Feasibility Study):

  • Проводим анализ технической реализуемости проекта.
  • Определяем ограничения и допущения, которые могут повлиять на проект.
  • Предварительно планируем высокоуровневый функционал системы.

3. Анализ бизнес-требований (Business Study):

  • Определяем ключевые пользовательские истории и приоритеты их реализации.
  • Согласуем критерии приёмки для каждой пользовательской истории.

4. Функциональное моделирование (Functional Model Iteration):

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

5. Разработка (Design and Build Iteration):

  • Команда разработчиков реализует наиболее приоритетные пользовательские истории.
  • Регулярно проводим демонстрации промежуточных результатов.
  • Параллельно выполняем тестирование и отладку разработанных компонентов.

6. Внедрение (Implementation):

  • Подготавливаем рабочую версию веб-приложения.
  • Проводим обучение пользователей, организуем поддержку и сопровождение.
  • Оцениваем достигнутые результаты и степень соответствия бизнес-требованиям.

7. Пост-проектная оценка (Evaluation):

  • Анализируем извлечённые уроки и рекомендации по улучшению процессов.
  • Определяем дальнейшие шаги по развитию и совершенствованию системы.
  • Готовим финальный отчёт о реализации проекта.

Плюсы и минусы DSDM

Плюсы:

  • Модель фокусируется на быстром прототипировании и ранней реализации ключевого функционала продукта. Часто команды используют DSDM для создания MVP и его последующего итеративного улучшения.
  • Метод предполагает тесное сотрудничество с конечными пользователями на всех этапах, что повышает качество и соответствие их потребностям.
  • DSDM позволяет быстро реагировать на изменяющиеся требования и условия за счёт итеративного подхода.
  • Подход предполагает регулярный анализ процессов и поощряет постоянное совершенствование.

Минусы:

  • Высокий темп разработки и правок в DSDM могут создавать ощущение «хаоса» и непредсказуемости.
  • Модель полагается на активное участие конечных пользователей, что не всегда легко обеспечить.
  • Применение DSDM в крупных, распределенных проектах требует дополнительных усилий по координации.

Для каких IT-проектов подходит DSDM

DSDM идеально подходит для IT-проектов с высокой неопределенностью требований, быстро меняющимися условиями и необходимостью регулярно предоставлять работающий продукт. Примеры таких проектов:

  • Разработка новых программных продуктов и мобильных приложений.
  • Внедрение гибких информационных систем (CRM, ERP).
  • Создание прототипов и MVP для валидации идей.
  • Интеграционные и модернизационные IT-проекты.
  • Разработка веб-сайтов и веб-приложений.

P3 Express (легче, чем P3M)

P3 Express (Principles, Practices, and Processes for Project Management) — это упрощенная и гибкая методология, разработанная специально для небольших, ограниченных по времени и бюджету команд.

В отличие от более сложных и формализованных подходов, таких как PMBOK или PRINCE2, P3 Express фокусируется на простоте, практичности и быстром получении результатов. Она предлагает базовый набор принципов, практик и процессов, которые можно легко адаптировать под конкретные нужды команды.

P3 Express наглядно

Процесс разработки по P3 Express

Процесс разработки IT-проекта по методу P3 Express заключается в гибком подходе, ориентированном на быстрое получение результата. Вместо длительной фазы проектирования, используются интенсивные циклы разработки и итеративной доработки. Основное внимание уделяется быстрой реализации базовых функций, а не детальной проработке полного функционала.

Наш проект: Разработка нового модуля для управления складскими запасами в корпоративной ERP-системе.

1. Инициация проекта (Initiate):

  • Определяем цель проекта
  • Разрабатываем краткий устав проекта, определяем основные ограничения и допущения.

2. Планирование (Plan):

  • Совместно с заказчиком составляем минимальный набор пользовательских историй для первой версии модуля.
  • Определяем сроки, бюджет и ресурсы, необходимые для реализации проекта.
  • Разрабатываем простой план управления рисками и коммуникациями.

3. Реализация (Deliver):

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

4. Контроль (Monitor):

  • Отслеживаем ключевые показатели проекта: прогресс реализации, использование ресурсов и риски.
  • Вносим необходимые корректировки в план или состав команды при возникновении отклонений.

5. Завершение (Close):

  • После реализации всех запланированных пользовательских историй проводим итоговое тестирование модуля.
  • Успешно развертываем модуль в production-среде и передаем в эксплуатацию заказчику.

Плюсы и минусы P3 Express

Плюсы:

  • P3 Express предлагает более упрощенный и практико-ориентированный подход по сравнению с полноценной P3M. P3 Express использует ключевые концепции P3M, но с меньшим количеством обязательных процессов и документации.
  • За счет меньшей сложности и формализации модель проще и быстрее внедрять в крупные проекты. Компания может начать с пилотного запуска в одном из подразделений, а затем распространить на всю компанию.
  • Более простая и гибкая природа методологии подразумевает меньшие затраты на внедрение и обучение персонала.

Минусы:

  • P3 Express может не предоставлять весь спектр возможностей, доступных в полноценной P3M.
  • Выборочное внедрение элементов подхода может привести к тому, что некоторые аспекты управления проектами будут упущены.
  • Для эффективного использования P3 Express компании все равно придётся адаптировать методологию под свои нужды.

Для каких IT-проектов подходит P3 Express

P3 Express подойдет для небольших и быстрых IT-проектов с ограниченным бюджетом и сжатыми сроками, где нужна гибкость и минимум формальностей. Примеры таких проектов:

  • Разработка MVP.
  • Внедрение/настройка небольших информационных систем.
  • Миграция или интеграция IT-систем.
  • Проекты по улучшению/оптимизации IT-процессов.
  • Создание прототипов и экспериментальных решений.

Spiral

Спиральная модель (Spiral Model) — это итеративная методология разработки программного обеспечения, созданная Барри Боэмом в 1980-х годах. Важно помнить, что она уделяет особое внимание анализу и управлению рискам.

Жизненный цикл Спиральной модели

Процесс разработки по Спиральной модели

Процесс создания IT-проекта по методу Spiral основан на итеративном и инкрементальном подходе с акцентом на анализ рисков. Весь жизненный цикл разработки представлен в виде спиралей, где каждая означает определенный этап.

Наш проект: Разработка мобильного приложения для заказа такси.

1-й виток спирали: Анализ рисков

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

2-й виток спирали: Определение требований

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

3-й виток спирали: Разработка прототипа

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

4-й виток спирали: Планирование и разработка (здесь можно внедрить и другие методики по типу Scrum)

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

5-й виток спирали: Оценка и принятие

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

Плюсы и минусы Спиральной модели

Плюсы:

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

Минусы:

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

Для каких IT-проектов подходит спиральная модель

Спиральная модель наиболее эффективна для крупных, сложных и рискованных IT-проектов, требующих тщательного планирования и контроля:

  • Разработка критически важных информационных систем.
  • Внедрение корпоративных приложений (ERP, CRM).
  • Создание программных продуктов с высокой степенью инноваций и ориентацией на пользовательский опыт.
  • Модернизация и интеграция устаревших IT-систем.
  • Разработка встроенных систем и программного обеспечения.

Extreme Programming (XP)

Extreme Programming (XP) — это методология гибкой разработки программного обеспечения, созданная в 1990-х годах программистом Кентом Берком. Примечательно, что она вбирает лучшие практики Agile (здесь и поэтапная быстрая разработка через временные итерации, как в Scrum, и визуализация процесса, как в Kanban) и ориентирована только на digital-продукты.

Процесс разработки по XP

В основе XP лежит идея постоянного общения между командой разработчиков и заказчиком. Вместо классической «водопадной» модели, где требования собираются раз и навсегда, XP предполагает итеративный процесс.

Наш проект: приложение для заказа еды от сети ресторанов.

1. Планируем релиз:

  • Совместно с заказчиком (владельцем ресторана) определяем основные функции приложения: возможность оформления заказа, просмотр меню, отслеживание статуса заказа, оплата.
  • Формируем план работ на 3 итерации по 2 недели каждая.
  • Определяем метрики: количество новых пользователей, средняя сумма заказа, время доставки.

2. Проводим итерации:

  • В начале первой итерации уточняем задачи по реализации базовых функций приложения: страница меню, корзина, оформление заказа.
  • Задачи распределяем между разработчиками, дизайнером и тестировщиком.
  • Согласовываем сроки и ответственных за каждую задачу.

3. Разработка:

  • Для каждой задачи сначала создаем автоматизированные тесты.
  • Код пишем с небольшими приращениями, с регулярным парным программированием и рефакторингом.
  • После завершения каждой задачи запускаем тесты для проверки качества.

4. Интегрируем:

  • Несколько раз в день интегрируем код в единую систему.
  • Автоматизированные тесты запускаем после каждой интеграции.
  • По мере реализации ключевых функций проводим приёмочное тестирование с участием заказчика.

5. Релиз:

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

6. Проводим ретроспективу

Плюсы и минусы XP

Плюсы:

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

Минусы:

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

Для каких IT-проектов подходит XP

Метод подходит в первую очередь для разработки небольших и средних по размеру программных продуктов, которые требуют частых изменений и обновлений:

  • Интерактивные веб-сайты
  • Интернет-магазины
  • Веб-приложения с регулярными обновлениями
  • Приложения для смартфонов и планшетов
  • Мобильные игры
  • Системы управления взаимоотношениями с клиентами (CRM)
  • Прототипы и MVP
Выбор конкретной методологии, безусловно, зависит от команды. Но сегодня совсем не обязательно обращаться лишь к проверенным техникам — важно расширять горизонт планирования своих IT-продуктов.
Рекомендуем