Аннотация 2
ВВЕДЕНИЕ 5
1 Анализ текущего процесса разработки 7
1.1 Описание компании и программной продуктовой линейки 7
1.2 Участники процесса разработки 10
1.2.1 Проектный менеджер 13
1.2.2 Продуктовый менеджер 13
1.2.3 Команды разработки 13
1.2.4 Вспомогательные роли 14
1.3 Формализация процесса разработки 15
1.3.1 Взаимодействие участников процесса 15
1.3.2 Описание бэклога 17
1.3.3 Планирование спринта 19
1.3.4 Порядок формирования плана спринта 20
1.4 Управление требованиями 20
2 Выявление и анализ проблем и рисков процесса разработки 22
2.1 Анализ процессов с использованием метода альфа-покера 22
2.1.1 Модификация колоды для оценки 22
2.1.1.1 Альфа «Стейкхолдеры» 23
2.1.1.2 Альфа «Требования» 25
2.1.1.3 Альфа «Система» 29
2.1.1.4 Альфа «Команда» 32
2.1.1.5 Альфа «Работа» 35
2.1.2 Оценка состояния проекта 38
2.1.2.1 Альфа «Стейкхолдеры» 39
2.1.2.2 Альфа «Система» 41
2.1.2.3 Альфа «Команда» 42
2.2 Фиксация проблем 43
2.3 Фиксация рисков 44
2.4 Описание метрик для фиксации проблем и рисков 45
2.4.1 Метрики для фиксации проблем 46
2.4.1.1 Практика микроменеджмента со стороны руководства в
отношении команды разработки 46
2.4.1.2 Проблема однотипных задач и падения мотивации у
разработчиков 46
2.4.1.3 Неполнота и устаревание документации 47
2.4.1.4 Стейкхолдеры не сообщают оперативно об изменениях 47
2.4.2 Метрики для фиксации рисков 47
2.5 Состояние метрик перед началом модификаций 48
3 Разработка комплекса изменений для оптимизации процесса 52
3.1 Изменения для решения проблем 52
3.1.1 Практика микроменеджмента со стороны руководства в отношении
команды разработки: 52
3.1.2 Проблема однотипных задач и падения мотивации у разработчиков:.. 53
3.1.3 Неполнота и устаревание документации 54
3.1.4 Стейкхолдеры не сообщают оперативно об изменениях 55
3.2. Нивелирование рисков 55
3.2.1 Риски, связанные с архитектурой и платформой 55
3.2.2 Риски управления бэклогом 57
3.2.3 Риски процесса разработки 58
3.2.4 Риски выпуска и развертывания 60
3.2.5 Риски поддержки и сопровождения 62
3.2.6 Организационные и человеческие риски 63
4 Результаты модернизации 65
4.1 Метрики для фиксации проблем 65
4.1.1 Практика микроменеджмента со стороны руководства в отношении
команды разработки 65
4.1.2 Проблема однотипных задач и падения мотивации у разработчиков... 66
4.1.3 Неполнота и устаревание документации 67
4.1.4 Стейкхолдеры не сообщают оперативно об изменениях 68
4.2 Метрики для фиксации рисков 69
4.2.1 Сложность приоритизации требований из разных источников для
разных продуктов 69
4.1.2 Потеря фокуса и отсутствие четкой дорожной карты для
стратегического развития линейки 70
ЗАКЛЮЧЕНИЕ 71
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ 72
В условиях жесткой конкуренции и постоянно растущих требований к программным продуктам компаниям необходимо искать эффективные подходы к организации процессов разработки. Одним из решений, позволяющих повысить производительность, сократить время вывода продуктов на рынок и обеспечить высокое качество, является применение концепции программной продуктовой линейки в сочетании с гибкими методологиями разработки, такими как Scrum [1].
Программная продуктовая линейка представляет собой инженерный подход к созданию семейства схожих программных продуктов на основе единой программной платформы с вариативными компонентами. Вместо разработки каждого продукта отдельно используются повторно используемые активы платформы, настраиваемые под конкретные требования. Это позволяет сократить затраты, повысить качество и ускорить выпуск новых версий и конфигураций продуктов.
Scrum, в свою очередь, обеспечивает гибкость, прозрачность и возможность быстрой адаптации к изменениям в ходе разработки продуктовой линейки. Применение гибких методов разработки позволяет организовать работу команд в виде коротких итераций, регулярно выпускать рабочие версии продуктов и своевременно реагировать на обратную связь заказчиков и изменения требований.
Однако, сочетание разработки программной продуктовой линейки с методикой Scrum может обеспечить значительные преимущества, но как показывает практика, она также сопряжена с определенными проблемами и рисками.
Данная магистерская диссертация посвящена анализу и модернизации процесса разработки программной продуктовой линейки в компании, специализирующейся на создании веб-сайтов с каталогом игр.
Цель работы - провести реинжиниринг текущего процесса разработки программной продуктовой линейки в компании.
Для достижения поставленной цели были сформулированы следующие задачи:
1) Провести анализ текущего процесса разработки продуктовой линейки в компании;
2) Выявить проблемы, особенности процесса и связанные с ними риски, зафиксировать их с помощью метрик;
3) Проанализировать причины проблем и факторы рисков;
4) Разработать комплекс изменений для решения проблем, нивелирования рисков и оптимизации процесса;
5) Внедрить предложенные изменения и оценить их эффективность.
Анализ текущего процесса разработки компании выявил ряд ключевых проблем и рисков, связанных с процессом разработки компании. Благодаря разработке и внедрению комплекса изменений, нацеленных на решение выявленных проблем и снижение рисков, удалось добиться улучшения показателей эффективности процесса разработки.
Использование альфа-покера вместе с обратной связью сотрудников позволило структурировано и объективно оценить состояние проектов продуктовой линейки с учетом мнений всех вовлеченных сторон. Выявленные проблемные области и риски будут приняты во внимание при дальнейшей оптимизации процессов разработки.
Реинжиниринг процесса разработки программной продуктовой линейки был успешно проведен, и внедренные изменения продемонстрировали значительное улучшение производительности работы команд. Стейкхолдеры в целом довольны достигнутыми результатами, однако следует отметить, что не все проблемные области были полностью устранены. Несмотря на прогресс, сохраняется потенциал для дальнейшей оптимизации и повышения эффективности.
Для того чтобы добиться долгосрочного и постоянного улучшения показателей, предложенные решения и подходы необходимо внедрить и поддерживать в компании на постоянной основе. Мониторинг и анализ рисков, управление процессами и активное вовлечение всех заинтересованных сторон должны стать неотъемлемой частью культуры разработки программного обеспечения в организации.
В целом, поставленные задачи были успешно реализованы, а цель работы достигнута. Опыт, полученный в ходе данной работы, может быть использован для дальнейших улучшений в процессах разработки не только внутри исследуемой компании, но и могут служить примером для других организаций, с похожим типом разработки.
