3. Страница 3 www.specialist.ru
Sources
Agile Manifesto
Менеджер ИТ Продукта. Профессиональный стандарт РФ
PMBOK Extension for Software Projects
ISO/IEC/IEEE/ГОСТ Р ИСО 12207, 15288
IEEE Standards (SWEBOK® 3)
ITIL ®, MOF®
4. Страница 4 www.specialist.ru
Что такое ИТ продукт:
Бизнес решение Обслуживаемое
Способное к развитию
5. Страница 5 www.specialist.ru
Специфика ИТ продуктов
Широкая
аудитория
Виртуальные
команды
Внешние
зависимости
Мотивированные
разработчики
Продвинутые
пользователи
7. Страница 7 www.specialist.ru
Как этого добиться
Регулярное взаимодействие с клиентом
Открытые коммуникации в команде
Инициативная команда (не только Product manager)
Готовность к изменениям
Процессный подход
9. Страница 9 www.specialist.ru
Чем важен сбор требований
Понять требования к продукту
Избежать недопонимания с заказчиком
Избежать излишней работы
Создать полезный продукт
10. Страница 10 www.specialist.ru
Определение состава заинтересованных сторон
Заказчик (-и)
Представители пользовательских групп
Команда проекта
11. Страница 11 www.specialist.ru
Способы сбора требований
Матрица заинтересованных сторон
Пользовательские истории
Варианты использования
12. Страница 12 www.specialist.ru
Матрица заинтересованных сторон и их
требований
ИМЯ Position Роль Контакты Требования Ожидания Влияние Отношение
ФИО или
название
Должность Роль в
проекте
Обязательные
требования с точки
зрения
стейкхолдера
Пожелания,
«хотелки»
Степень
влияния на
проект
Отношение к
проекту
(положительное/нег
ативное)
13. Страница 13 www.specialist.ru
Стратегия управления заинтересованными сторонами
Имя Влияние Оценка
воздействия
Стратегии
взаимодействия
14. Страница 14 www.specialist.ru
Пользовательские истории (user stories)
Достоинства
– Истории короткие. Они
представляют маленькие кусочки
деловой ценности, которые можно
реализовать в период от дней до
нескольких недель.
– Позволяют разработчикам и
клиентам обсуждать требования на
протяжении всей жизни проекта
– Нуждаются в очень небольшом
обслуживании
– Рассматриваются только в момент
использования
– Поддерживают близкий контакт с
клиентом
– Позволяют разбить проект на
небольшие этапы
– Подходят для проектов, где
требования изменчивы или плохо
поняты.
– Облегчают оценку заданий
Недостатки
– Без определенных приемочных
испытаний, они являются
открытыми для различных
интерпретаций, что усложняет их
использование как основу для
соглашения
– Они требуют близкого контакта с
клиентом на протяжении всего
проекта, что в некоторых случаях
может быть сложно либо
приводить к накладным затратам
– Они могут плохо
масштабироваться на больших
проектах
– Они полагаются на
компетентность разработчиков
– Они используются для начала
дискуссии. К сожалению, они могут
не фиксировать окончание
дискуссии и таким образом не в
состоянии служить надежным
методом документации системы.
15. Страница 15 www.specialist.ru
Тесная работа всей команды с
Заказчиками
Пользователями
Друг с другом
16. Страница 16 www.specialist.ru
Пример пользовательской истории
Как руководитель портфеля
Который должен мониторить достижение целей
Я хочу видеть общую картину по продуктам
Так чтобы они были показаны во взаимосвязи
(с) habrahabr.ru (https://habrahabr.ru/company/friifond/blog/284032/ )
18. Страница 18 www.specialist.ru
Анализ и сведение пользовательских историй
19. Страница 19 www.specialist.ru
Варианты использования (use cases)
20. Страница 20 www.specialist.ru
Диаграмма вариантов использования. Задачи
• Чётко отделить систему от её окружения;
• Определить действующих лиц (акторов), их взаимодействие с
системой и ожидаемый функционал системы;
• Определить в глоссарии предметной области понятия,
относящиеся к детальному описанию функционала системы
(то есть, прецедентов)
21. Страница 21 www.specialist.ru
Управление требованиями в жизненном цикле
проекта
25. Страница 25 www.specialist.ru
ВОДОПАДНОЕ ПЛАНИРОВАНИЕ
Его предпочитают заказчики и руководство
26. Страница 26 www.specialist.ru
НАБЕГАЮЩАЯ ВОЛНА
Поэтапное планирование, хорошо подходит
для длительных проектов или проектов с
высокой зависимостью между этапами
27. Страница 27 www.specialist.ru
Преимущества моделей «водопад» и
«набегающая волна»
Четкий план проекта от начала и до конца этапа или даже
всего проекта
Возможности комплексного архитектурного планирования
Четко определенные границы проекта
28. Страница 28 www.specialist.ru
Ключевые решения принимаются на ранних этапах.
Сложно адаптироваться к изменениям
Длительная разработка может привести к
невостребованности продукта вследствие изменения
условий
Недостатки и ограничения
иерархических моделей
31. Страница 31 www.specialist.ru
MSF модель
Одобрен
план
проекта
Выпуск из
разработки
Релиз готов
Веха
Выпуска
Одобрена
концепция
Build
32. Страница 32 www.specialist.ru
Этапность каждого релиза
User
story
Analyze
Projectize
Develop
(Code)
Document
Test and
Validate
Operate
33. Страница 33 www.specialist.ru
• Короткое инкрементальное планирование
• Интеграция пользователей и разработчиков в постоянное
взаимодействие
• Небольшие самоорганизующиеся команды
• Крупные проекты разбиваются на несколько небольших
модулей
• Каждая команда в каждый момент времени работает над одним
проектом/подпроектом
• В команде должны быть узкие специалисты и широкого
профиля
Основные принципы адаптивных моделей
34. Страница 34 www.specialist.ru
Ограничения и риски адаптивных
моделей
Накапливание багов от итерации к итерации
Неопределенность с итоговыми характеристиками
проекта
Сложности стратегического планирования
Сильно зависит от мотивированности и вовлеченности
пользователей, разработчиков и заказчика
35. Страница 35 www.specialist.ru
Комбинирование управления рисками по
иерархической и адаптивной моделям
36. Страница 36 www.specialist.ru
Доски (СКРАМ-борд) (на примереTrello)
Общая доска
Доска пакета
(SCRUM)
Доски
разработчиков
37. Страница 37 www.specialist.ru
Developers are not only a “resourse”!
People need more than tasks!
WIIFM – What In It For Me
Team motivation.
Implementing best from Agile
38. Страница 38 www.specialist.ru
Общение с заказчиками и пользователями
Лицом к лицу
39. Страница 39 www.specialist.ru
Product. Version 1.0
40. Страница 40 www.specialist.ru
Развитие продукта. Регулярные улучшения