В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
2. Страница 2
ДАНИЛ ДИНЦИС
ДОКТ. ТЕХН. НАУК,
PGMP, PMP, ITIL OSA, MOF CERTIFIED SPECIALIST
ОПЫТ В ИТ: 25 ЛЕТ
DINZIS@SPECIALIST.RU,
CONSULT@DINTSIS.ORG
WWW.DDINTSIS.COM
4. Страница 4 www.specialist.ru
Целевая аудитория
Руководители бизнеса
Руководители ИТ департаментов
Руководители компаний и департаментов разработки и
интеграции
PMO
Члены команд разработки
Члены команд сопровождения (ITIL)
5. Страница 5 www.specialist.ru
Что такое программный продукт
6. Страница 6 www.specialist.ru
Особенности программных продуктов
7. Страница 7 www.specialist.ru
Резюме требований к программному продукту
Обладает конечной ценностью для заказчика/потребителя
Должен динамично изменяться
Обеспечение преемственности, совместимости и поддержки
Мультинациональные/региональные
Высокая зависимость от внешних провайдеров (например,
Интернета)
8. Страница 8 www.specialist.ru
Модели планирования
9. Страница 9 www.specialist.ruД.Ю. Динцис. ITPM. Управление
содержанием
5-9
Управление содержанием IT-проектов
Водопадная (Waterfall) модель –
планирование от начала до конца проекта
Метод «водопада»
10. Страница 10 www.specialist.ruВ.В.Камалов. ITPM. Управление содержанием
Метод набегающей волны
Декомпозиция может быть невозможной
для результатов, которые будут
выполняться в будущем.
11. Страница 11 www.specialist.ru
Достоинства
иерархических методов планирования
Определение направления развития
Стратегическое архитектурное планирование
Понятные цели по срокам и финансированию
13. Страница 13 www.specialist.ru
Agile методология
ТЭО
• Бизнес-
требования
Анализ • Поиск решения,
сравнение вариантов
Проекти
рование
• Решение «на
бумаге»
Разра-
ботка • КОДИНГ
Докумен
тирован
ие
• описание
Тестиро
вание
• тесты
Обслу-
живание
14. Страница 14 www.specialist.ruДинцис Д.Ю. ITPM. Управление содержанием
Гибкие/адаптивные методики
• Инкрементное планирование с периодичностью от 1 дня до 1
месяца
• Вовлеченность представителя заказчика и пользователей в
команду на постоянной основе
• Малые (до 10 человек) самоорганизующиеся команды
• Крупные проекты могут включать адаптивные команды
• Каждый член команды работает только над одним проектом на
каждой итерации
• Каждая команда включает экспертов и специалистов общего
профиля.
15. Страница 15 www.specialist.ruВ.В.Камалов. ITPM. Управление содержанием
Необходимость
WBS
• точнее достигнет нужного результата
• позволяет зафиксировать набор работ – границы Проекта
• создает ощущение реальности достижения результата
• легче контролировать
• помогает планировать другие проекты
• основа для планирования ресурсов и бюджета
Детально расписанный проект
16. Страница 16 www.specialist.ruВ.В.Камалов. ITPM. Управление содержанием
гарантирует, что все результаты проекта идентифицированы и
детализированы так, что всем работам могут быть назначены
необходимые ресурсы
помогает
контролировать
ход выполнения
проекта
WBS
определяет все
результаты
проекта
17. Страница 17 www.specialist.ru
Время
Функциональность
Минимизация рисков неопределенности требований
Release 1
Release 2
Release 3
АДАПТИВНЫЕ МОДЕЛИ
18. Страница 18 www.specialist.ru
Недостатки адаптивного подхода
Накопление различных ошибок, допущенных на
предшествующих итерациях
Неопределенность объемов временных и ресурсных
затрат на выпуск продукта.
Сложности в стратегическом планировании
Зависимость от личностной мотивации на стороне и
заказчика, и исполнителя
19. Страница 19 www.specialist.ru
Все ключевые решения принимаются тогда, когда у
аналитиков и разработчиков нет полного понимания
системы.
Метод водопада не дает возможности быстрой адаптации
к изменениям, особенно на поздних стадиях жизненного
цикла ПО.
Конечный продукт может оказаться
невостребованным из-за неточного изложения требований
или их изменения за длительное время создания ПО.
Недостатки водопадного подхода
20. Страница 20 www.specialist.ru
Цикл адаптивной модели
21. Страница 21 www.specialist.ru
Цикл управления риском при адаптивном
планировании
22. Страница 22 www.specialist.ru
MSF: модель жизненного цикла разработки
Project plan
approved
Out of
Developm
ent
Release Readiness
Review
Deployment
Milestone
Vision approved
Build
23. Страница 23 www.specialist.ru
Методологии гибкой разработки программного
обеспечения: Итерация
План
Анализ
ДизайнРазработка
Тест
Scott Schultz “Rapid Iterative
Production Prototyping”, 1988
24. Страница 24 www.specialist.ruВ.В.Камалов. ITPM. Управление содержанием
Степень детализации WBS
Знаменуется получением одного или
нескольких результатов
Являются частью логической
последовательности, обеспечивающей
правильное определение продукта проекта
Окончание сопровождается анализом
результатов и текущего исполнения
ФАЗА
ПРОЕКТА
Work package
(Пакет работ)
Элемент низшего уровня иерархии
Неделимый объект WBS
Комплекс работ, сгруппированный по
заданным основаниям (критериям)
Декомпозиция
25. Страница 25 www.specialist.ruВ.В.Камалов., Динцис Д.Ю. ITPM. Управление
содержанием
Другие результаты, возникающие
на этапе разработки WBS
• Словарь иерархической
структуры работ
• Обновление описания
предметной области
• План управления
предметной областью
• Запрошенные изменения
• Базовый план
предметной области
30. Страница 31 www.specialist.ru
Развитие продукта. Регулярные улучшения
31. Страница 32 www.specialist.ru
Системные типы изменений
Категория
изменения
Что затрагивается Сложность Длительность Способ
реализации
Первая Модификация
существующих
рабочих процедур
Небольшая Быстрое
изменение
Адаптивный
Вторая Существенное
изменение
рабочих процедур
Средняя Средняя Адаптивный/
Проект/Прогр
амма
Третья Изменение
ценностей
компании
Очень
сложные
Длительные Портфель
32. Страница 33 www.specialist.ru
Нельзя рассматривать людей
исключительно как ресурс.
Людям нужно нечто большее, чем
просто список заданий.
Мотивация команды
33. Страница 34 www.specialist.ru
Варианты построения команды
Комбинирование виртуальных и локальных команд
Дорогостоящие эксперты и специалисты общего профиля
Баланс между выделенными и функциональными членами
команды
34. Страница 35 www.specialist.ru
Рекомендуемый метод передачи информации —
личный разговор (лицом к лицу)
35. Страница 36 www.specialist.ru
Инструменты взаимодействия команды
Парное программирование
Программирование, ведомое тестированием
Совместное размещение (colocation)
36. Страница 37 www.specialist.ru
Роль РМ-а
Лидерство
Контроль
37. Страница 38 www.specialist.ru
Инструмент совместной работы
на примере Slack