Руководство по управлению проектами в разных отраслях · ИТ, разработка ПО и цифровые технологии
Управление проектами разработки ПО: жизненный цикл, роли, методы, KPI
Управление проектами разработки ПО — это планирование, координация и поставка программных продуктов и функций: от исследования и требований через проектирование, разработку, тестирование и релиз до непрерывного улучшения. Поскольку ПО легко изменить, но трудно оценить, большинство команд разработки управляют работой короткими итерациями и измеряют прогресс работающим ПО, а не документами.
Главное
- Управление проектами разработки ПО строится на коротких итерациях, потому что требования меняются, а оценки неопределённы.
- Выбирайте Scrum, Kanban, DevOps или плановый подход исходя из характера работы, а не по привычке.
- Отслеживайте поставку с помощью метрик DORA и метрик потока, а успех — с помощью метрик результатов.
- Используйте трекеры задач разработчиков для работы на уровне кода и платформу, например Wrike, для кросс-функционального планирования.
Чем отличается управление проектами разработки ПО
- Требования меняются. Пользователи часто понимают, чего хотят, только увидев что-то работающее.
- Оценки неопределённы. Большая часть работы — это решение новых задач, поэтому команды прогнозируют диапазонами и по исторической пропускной способности, а не фиксированными датами.
- Поставка может быть непрерывной. Благодаря автоматизированному тестированию и развёртыванию команды могут выпускать релизы много раз в неделю.
- Технический долг. Упрощения, допущенные ради соблюдения срока, замедляют будущую работу, если их не погасить; см. технический долг в Scrum.
- Качество встраивается в процесс. Ревью кода, автоматизированные тесты и мониторинг заменяют масштабные фазы тестирования в конце проекта.
- Продукт и проект пересекаются. Многие команды разработки — это долгоживущие продуктовые команды, поэтому «проект» часто представляет собой релиз, набор функций или новый продукт.
Обзор того, как команды применяют ценности Agile в коде, см. в Agile-разработка ПО.
Жизненный цикл разработки ПО (SDLC)
| Фаза | Что происходит | Ключевые результаты |
|---|---|---|
| Исследование (discovery) | Понять пользователей, проблемы и цели; проверить идеи с помощью исследований и прототипов | Постановка проблемы, видение продукта, ранние прототипы |
| Планирование | Формировать содержание, приоритизировать бэклог, планировать релизы и мощности | Бэклог продукта, план релизов, дорожной карты |
| Дизайн | UX-дизайн, архитектура и технический подход | Дизайн-макеты, архитектурные решения, критерии приёмки |
| Разработка | Писать код небольшими инкрементами с ревью и автоматизированными тестами | Работающие, протестированные инкременты |
| Тестирование и обеспечение качества | Автоматизированное, исследовательское, нагрузочное тестирование и тестирование безопасности | Результаты тестов, устранённые дефекты |
| Релиз и развёртывание | Развёртывание в продуктивной среде, часто через непрерывная поставка конвейер | Выпущенная функция, примечания к релизу |
| Эксплуатация и улучшение | Мониторить, поддерживать пользователей, измерять результаты и возвращать полученные знания в бэклог | Метрики, инциденты, новые элементы бэклога |
В Agile-командах эти фазы происходят непрерывно внутри каждой итерации, а не один раз последовательно; см. жизненный цикл Agile-разработки.
Ключевые роли
| Роль | Основные обязанности |
|---|---|
| Владелец продукта / менеджер продукта | Отвечает за видение продукта и упорядочивает бэклог по ценности; см. Владелец продукта в Scrum |
| Руководитель разработки (engineering manager) | Руководит инженерами, наймом, развитием и практиками поставки |
| Техлид / архитектор | Отвечает за техническое направление и качество |
| Разработчики | Проектируют, разрабатывают и тестируют ПО |
| Инженеры по QA / тестированию | Стратегия тестирования, автоматизация и исследовательское тестирование |
| UX- и продуктовые дизайнеры | Пользовательские исследования и дизайн интерфейсов |
| Scrum-мастер или руководитель поставки | Фасилитирует процесс и устраняет препятствия; см. Роль Scrum-мастера |
| Технический руководитель проекта или программы | Координирует межкомандные зависимости, сроки и риски; см. технический руководитель проектов |
| DevOps / SRE | Конвейеры сборки, инфраструктура и надёжность |
Методологии для проектов разработки ПО
| Подход | Когда подходит | Примечания |
|---|---|---|
| Scrum | Продуктовые команды, создающие новые функции с регулярной обратной связью от заинтересованных сторон | Спринты фиксированной длины с планированием, обзором и ретроспективой |
| Kanban | Команды сопровождения, платформ и поддержки; непрерывный поток | WIP-лимиты и метрики потока вместо спринтов |
| Экстремальное программирование (XP) | Команды, которым нужна строгая инженерная дисциплина | Парное программирование, разработка через тестирование, непрерывная интеграция |
| DevOps | Команды, которые создают и эксплуатируют собственные сервисы | Автоматизирует поставку и разделяет ответственность за эксплуатацию |
| Waterfall или V-модель | Контракты с фиксированным содержанием и регулируемое или критичное для безопасности ПО | Формальные фазы, документация и верификация |
| Масштабированные фреймворки | Много команд над одним продуктом | См. SAFe и LeSS |
Сравните варианты в Agile или Waterfall и Kanban и Scrum.
Основные документы и шаблоны
| Документ | Назначение | Шаблон |
|---|---|---|
| Бэклог продукта | Упорядоченный список всего, что может понадобиться продукту | Шаблон бэклога продукта |
| Пользовательские истории | Требования, сформулированные с точки зрения пользователя | Шаблон пользовательской истории |
| План спринта | Цель спринта и выбранная работа | Шаблон планирования спринта |
| План релиза и дорожная карта | Что и когда выходит, на верхнем уровне | Шаблон плана релиза, шаблон дорожной карты продукта |
| Документ требований | Для работ с фиксированным содержанием или по договору | Шаблон документа бизнес-требований |
| Заметки ретроспективы | Улучшения, согласованные командой | Шаблон ретроспективы спринта |
| журнала RAID | Межкомандные риски и зависимости | Шаблон журнала RAID |
Наряду с ними ведите записи архитектурных решений и критерии готовности; см. критерии готовности.
KPI для управления проектами разработки ПО
| KPI | Что измеряет | Типичное применение |
|---|---|---|
| Частота развёртываний | Как часто код попадает в продуктивную среду | Способность к поставке (метрика DORA) |
| Время выполнения изменений | Время от коммита до продуктивной среды | Скорость потока (метрика DORA) |
| Доля неудачных изменений | Доля развёртываний, вызвавших сбой | Качество релизов (метрика DORA) |
| Время восстановления сервиса | Как быстро устраняются сбои | Устойчивость (метрика DORA) |
| Время цикла | Время от начала работы до готовности | Прогнозирование и выявление узких мест |
| Пропускная способность или скорости | Работа, выполненная за неделю или спринт | Прогнозирование релизов |
| Пропущенные дефекты | Ошибки, найденные после релиза | Эффективность тестирования |
| Метрики результатов | Внедрение, конверсия, удержание или успешность выполнения задач | Приносит ли ПО ценность |
См. Метрики и KPI в Agile .
Типичные трудности
- Фиксированные даты при фиксированном содержании. Фиксируйте дату и варьируйте содержание, прогнозируйте диапазонами на основе прошлой пропускной способности.
- Растущий технический долг. Резервируйте мощности в каждом спринте на рефакторинг и работу над платформой.
- Межкомандные зависимости. Отобразите их наглядно, согласуйте общие вехи и используйте Scrum of Scrums или аналогичную синхронизацию.
- Слишком много незавершённой работы. Применяйте WIP-лимиты и завершайте работу, прежде чем начинать новую.
- Измерение объёма работы, а не результатов. Привязывайте релизы к целям пользователей и бизнеса, а не только к стори-поинтам.
ПО для управления проектами разработки ПО
Командам разработки нужен трекер задач, связанный с репозиториями кода и конвейерами CI/CD, а также доски, бэклоги и отчёты по спринтам. Менеджерам продукта и поставки также нужны дорожные карты, представления межкомандных зависимостей и отчёты, понятные людям без инженерной подготовки.
Jira широко используется инженерными командами для отслеживания задач. Wrike — самый сильный универсальный вариант в нашем рейтинге инструментов когда работу над ПО нужно планировать вместе с маркетингом, поддержкой, дизайном и другими отделами, с Agile-досками и представлениями Ганта в одном месте. См. также программные инструменты для Scrum.
Бесплатные шаблоны по этой теме
Частые вопросы
Что такое управление проектами разработки ПО?
Управление проектами разработки ПО — это планирование, координация и поставка программных продуктов и функций от исследования через разработку, тестирование и релиз до непрерывного улучшения.
Какие фазы есть в управлении проектами разработки ПО?
Фазы SDLC: исследование, планирование, проектирование, разработка, тестирование, релиз, эксплуатация и улучшение — обычно повторяются короткими итерациями.
Какая методология лучше всего подходит для управления проектами разработки ПО?
Scrum подходит функциональным командам, Kanban — непрерывному потоку и поддержке, практики DevOps — командам, которые эксплуатируют собственные сервисы, а Waterfall или V-модель — работе с фиксированным содержанием или регулируемой работе.
Что такое метрики DORA в управлении проектами разработки ПО?
Четыре показателя поставки из программы DevOps Research and Assessment: частота развёртываний, время выполнения изменений, доля неудачных изменений и время восстановления сервиса.
Кто управляет проектом разработки ПО в Agile-команде?
Ответственность распределена: владелец продукта управляет приоритетами, команда сама планирует свою работу, Scrum-мастер фасилитирует, а технический руководитель проекта может координировать работу между командами.
Как выполнять оценку в управлении проектами разработки ПО?
Используйте относительные оценки, такие как стори-поинты или прогнозируйте по исторической пропускной способности и времени цикла, а даты выражайте диапазонами.
Какие документы используются в управлении проектами разработки ПО?
Бэклог продукта, пользовательские истории, планы спринтов, планы релизов, дорожные карты, критерии готовности, а для работ по договору — документ с требованиями.
Какое ПО используется для управления проектами разработки ПО?
Трекеры задач, такие как Jira, связанные с репозиториями кода, плюс платформа, например Wrike, когда работу над ПО нужно планировать вместе с другими отделами.
Как работать с техническим долгом в управлении проектами разработки ПО?
Сделайте его видимым в бэклоге, резервируйте мощности в каждой итерации для его погашения и включайте его в обсуждения планирования с владельцем продукта.
В чём разница между управлением проектами разработки ПО и управлением продуктом?
Управление продуктом решает, что создавать и зачем; управление проектами разработки ПО сосредоточено на том, как и когда это будет поставлено.
Какие навыки нужны для управления проектами разработки ПО?
Понимание процесса разработки, Agile-практики, управление рисками и зависимостями, коммуникация с техническими и бизнес-заинтересованными сторонами и прогнозирование на основе данных.