Виммельбух, 2, перетяжка
Виммельбух, 2, перетяжка
Виммельбух, 2, перетяжка

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

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

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

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

PRINCE2

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

Не Waterfall единым: топ неочевидных методов управления командой разработки 1
Ключевые ценности 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 ориентирован на быструю разработку и итеративное улучшение продукта. Важно, чтобы при разработке проекта конечные пользователи были вовлечены во все этапы (так можно внести правки еще на первых стадиях).

Не Waterfall единым: топ неочевидных методов управления командой разработки 2
Принципы 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 фокусируется на простоте, практичности и быстром получении результатов. Она предлагает базовый набор принципов, практик и процессов, которые можно легко адаптировать под конкретные нужды команды.

Не Waterfall единым: топ неочевидных методов управления командой разработки 3
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-х годах. Важно помнить, что она уделяет особое внимание анализу и управлению рискам.

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

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

Процесс создания 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-продукты.

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

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

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

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

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

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

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

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

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

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

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

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

5. Релиз:

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

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

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

Плюсы:

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

Минусы:

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

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

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

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