определение и реализация требований к ИТ продукту
Post on 15-Apr-2017
1.224 Views
Preview:
TRANSCRIPT
Управление ИТ разработкой: определение и реализация требований к ИТ продукту
Страница 2
DANIL DINTSISДОКТ. ТЕХН. НАУК ПО СИСТЕМНОМУ АНАЛИЗУ, PGMP, PMP, ITIL OSA,, SOA, MOF CERTIFIED SPECIALIST
CONSULT@DINTSIS.ORGWWW.DDINTSIS.COM
Страница 3 www.specialist.ru
Sources
Agile Manifesto Менеджер ИТ Продукта. Профессиональный стандарт РФ PMBOK Extension for Software Projects ISO/IEC/IEEE/ГОСТ Р ИСО 12207, 15288 IEEE Standards (SWEBOK® 3) ITIL ®, MOF®
Страница 4 www.specialist.ru
Что такое ИТ продукт:
Бизнес решение Обслуживаемое
Способное к развитию
Страница 5 www.specialist.ru
Специфика ИТ продуктов
Широкая аудитория
Виртуальные команды
Внешние зависимости
Мотивированные разработчики
Продвинутые пользователи
Страница 6 www.specialist.ru
Довольный клиент
Основной критерий успешности продукта
Страница 7 www.specialist.ru
Как этого добиться Регулярное взаимодействие с клиентом Открытые коммуникации в команде Инициативная команда (не только Product manager) Готовность к изменениям Процессный подход
Страница 9 www.specialist.ru
Чем важен сбор требований
Понять требования к продукту Избежать недопонимания с заказчиком Избежать излишней работы Создать полезный продукт
Страница 10 www.specialist.ru
Определение состава заинтересованных сторон
Заказчик (-и) Представители пользовательских групп Команда проекта
Страница 11 www.specialist.ru
Способы сбора требований
Матрица заинтересованных сторон Пользовательские истории Варианты использования
Страница 12 www.specialist.ru
Матрица заинтересованных сторон и их требований
ИМЯ Position Роль Контакты Требования Ожидания Влияние Отношение
ФИО или название
Должность Роль в проекте
Обязательные требования с точки
зрения стейкхолдера
Пожелания, «хотелки»
Степень влияния на
проект
Отношение к проекту
(положительное/негативное)
Страница 13 www.specialist.ru
Стратегия управления заинтересованными сторонами
Имя Влияние Оценка воздействия
Стратегии взаимодействия
Страница 14 www.specialist.ru
Пользовательские истории (user stories)
Достоинства– Истории короткие. Они представляют
маленькие кусочки деловой ценности, которые можно реализовать в период от дней до нескольких недель.
– Позволяют разработчикам и клиентам обсуждать требования на протяжении всей жизни проекта
– Нуждаются в очень небольшом обслуживании
– Рассматриваются только в момент использования
– Поддерживают близкий контакт с клиентом
– Позволяют разбить проект на небольшие этапы
– Подходят для проектов, где требования изменчивы или плохо поняты.
– Облегчают оценку заданий
Недостатки– Без определенных приемочных
испытаний, они являются открытыми для различных интерпретаций, что усложняет их использование как основу для соглашения
– Они требуют близкого контакта с клиентом на протяжении всего проекта, что в некоторых случаях может быть сложно либо приводить к накладным затратам
– Они могут плохо масштабироваться на больших проектах
– Они полагаются на компетентность разработчиков
– Они используются для начала дискуссии. К сожалению, они могут не фиксировать окончание дискуссии и таким образом не в состоянии служить надежным методом документации системы.
Страница 15 www.specialist.ru
Тесная работа всей команды с
Заказчиками ПользователямиДруг с другом
Страница 16 www.specialist.ru
Пример пользовательской истории
Как руководитель портфеляКоторый должен мониторить достижение целей
Я хочу видеть общую картину по продуктам
Так чтобы они были показаны во взаимосвязи
(с) habrahabr.ru (https://habrahabr.ru/company/friifond/blog/284032/ )
Страница 20 www.specialist.ru
Диаграмма вариантов использования. Задачи
• Чётко отделить систему от её окружения;• Определить действующих лиц (акторов), их взаимодействие с
системой и ожидаемый функционал системы;• Определить в глоссарии предметной области понятия,
относящиеся к детальному описанию функционала системы (то есть, прецедентов)
Страница 21 www.specialist.ru
Управление требованиями в жизненном цикле проекта
Страница 22 www.specialist.ru
Жизненный цикл одной итерации
Plan
Analyze
DesignDevelop
Test
© Scott Schultz “Rapid Iterative Production Prototyping”, 1988
Страница 25 www.specialist.ru
ВОДОПАДНОЕ ПЛАНИРОВАНИЕ
Его предпочитают заказчики и руководство
Страница 26 www.specialist.ru
НАБЕГАЮЩАЯ ВОЛНА
Поэтапное планирование, хорошо подходит для длительных проектов или проектов с высокой зависимостью между этапами
Страница 27 www.specialist.ru
Преимущества моделей «водопад» и «набегающая волна»
Четкий план проекта от начала и до конца этапа или даже всего проекта
Возможности комплексного архитектурного планирования Четко определенные границы проекта
Страница 28 www.specialist.ru
Ключевые решения принимаются на ранних этапах.
Сложно адаптироваться к изменениям
Длительная разработка может привести к невостребованности продукта вследствие изменения условий
Недостатки и ограничения иерархических моделей
Страница 30 www.specialist.ru
Time
Func
tiona
lity
Release 1
Release 2
Release 3
МИНИМИЗИРУЕМ РИСКИ ПОЭТАПНО
Страница 31 www.specialist.ru
MSF модель
Одобрен план проекта
Выпуск из разработки
Релиз готов
Веха Выпуска
Одобрена концепция
Vision
Deploy
men
t
Build
Det
aile
d pl
anni
ngStabilize
Страница 32 www.specialist.ru
Этапность каждого релизаUser story
Analyze
Projectize
Develop (Code)
Document
Test and Validate
Operate
Страница 33 www.specialist.ru
• Короткое инкрементальное планирование• Интеграция пользователей и разработчиков в постоянное
взаимодействие• Небольшие самоорганизующиеся команды• Крупные проекты разбиваются на несколько небольших
модулей• Каждая команда в каждый момент времени работает над одним
проектом/подпроектом• В команде должны быть узкие специалисты и широкого
профиля
Основные принципы адаптивных моделей
Страница 34 www.specialist.ru
Ограничения и риски адаптивных моделей
Накапливание багов от итерации к итерации Неопределенность с итоговыми характеристиками проекта
Сложности стратегического планирования
Сильно зависит от мотивированности и вовлеченности пользователей, разработчиков и заказчика
Страница 35 www.specialist.ru
Комбинирование управления рисками по иерархической и адаптивной моделям
Страница 36 www.specialist.ru
Доски (СКРАМ-борд) (на примереTrello)
Общая доска
Доска пакета(SCRUM)
Доски разработчико
в
Страница 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 www.specialist.ru
Общение с заказчиками и пользователямиЛицом к лицу
Страница 41 www.specialist.ru
Contacts
dinzis@specialist.ru consult@Dintsis.org www.specialist.ru www.ddintsis.com
top related