Комбинированное управление ИТ разработкой гибкими и...
Post on 13-Apr-2017
1.152 Views
Preview:
TRANSCRIPT
Комбинированное использование водопадных и гибких методик на примере софтверного продукта
Страница 2
ДАНИЛ ДИНЦИСДОКТ. ТЕХН. НАУК, PGMP, PMP, ITIL OSA, MOF CERTIFIED SPECIALISTОПЫТ В ИТ: 25 ЛЕТ
DINZIS@SPECIALIST.RU, CONSULT@DINTSIS.ORG
WWW.DDINTSIS.COM
Страница 3 www.specialist.ru
Источники
PMBOK® Guide 5 Edition PMBOK Extension for Software Projects ISO/IEC/IEEE/ГОСТ Р ИСО 12207, 15288 IEEE Standards (SWEBOK® 3) ITIL ®, MOF®
Страница 4 www.specialist.ru
Целевая аудитория
Руководители бизнеса Руководители ИТ департаментов Руководители компаний и департаментов разработки и
интеграции PMO Члены команд разработки Члены команд сопровождения (ITIL)
Страница 7 www.specialist.ru
Резюме требований к программному продукту
Обладает конечной ценностью для заказчика/потребителя Должен динамично изменяться Обеспечение преемственности, совместимости и поддержки Мультинациональные/региональные Высокая зависимость от внешних провайдеров (например,
Интернета)
Страница 9 www.specialist.ruД.Ю. Динцис. ITPM. Управление содержанием
5-9Управление содержанием IT-проектов
Водопадная (Waterfall) модель – планирование от начала до конца проекта
Метод «водопада»
Страница 10 www.specialist.ruВ.В.Камалов. ITPM. Управление содержанием
Метод набегающей волны
Декомпозиция может быть невозможной для результатов, которые будут выполняться в будущем.
Страница 11 www.specialist.ru
Достоинства иерархических методов планирования
Определение направления развития Стратегическое архитектурное планирование Понятные цели по срокам и финансированию
Страница 12 www.specialist.ruДинцис Д.Ю. ITPM. Управление содержанием
Гибкие/адаптивные методики
Страница 13 www.specialist.ru
Agile методология
ТЭО• Бизнес-
требования
Анализ • Поиск решения, сравнение вариантов
Проектирован
ие
• Решение «на бумаге»
Разра-ботка • КОДИНГ
Документирова
ние• описание
Тестирование
• тесты
Обслу-живани
е
Страница 14 www.specialist.ruДинцис Д.Ю. ITPM. Управление содержанием
Гибкие/адаптивные методики
• Инкрементное планирование с периодичностью от 1 дня до 1 месяца
• Вовлеченность представителя заказчика и пользователей в команду на постоянной основе
• Малые (до 10 человек) самоорганизующиеся команды• Крупные проекты могут включать адаптивные команды• Каждый член команды работает только над одним проектом на
каждой итерации• Каждая команда включает экспертов и специалистов общего
профиля.
Страница 15 www.specialist.ruВ.В.Камалов. ITPM. Управление содержанием
НеобходимостьWBS
• точнее достигнет нужного результата• позволяет зафиксировать набор работ – границы
Проекта• создает ощущение реальности достижения результата
• легче контролировать
• помогает планировать другие проекты• основа для планирования ресурсов и бюджета
Детально расписанный проект
Страница 16 www.specialist.ruВ.В.Камалов. ITPM. Управление содержанием
гарантирует, что все результаты проекта идентифицированы и детализированы так, что всем работам могут быть назначены
необходимые ресурсы
помогает контролировать ход выполнения
проекта
WBS
определяет все результаты
проекта
Страница 17 www.specialist.ru
Время
Фун
кцио
наль
ност
ь
Минимизация рисков неопределенности требований
Release 1
Release 2
Release 3
АДАПТИВНЫЕ МОДЕЛИ
Страница 18 www.specialist.ru
Недостатки адаптивного подхода
Накопление различных ошибок, допущенных на предшествующих итерациях Неопределенность объемов временных и ресурсных затрат на выпуск продукта.
Сложности в стратегическом планировании
Зависимость от личностной мотивации на стороне и заказчика, и исполнителя
Страница 19 www.specialist.ru
Все ключевые решения принимаются тогда, когда у аналитиков и разработчиков нет полного понимания системы.
Метод водопада не дает возможности быстрой адаптации к изменениям, особенно на поздних стадиях жизненного цикла ПО.
Конечный продукт может оказаться невостребованным из-за неточного изложения требований или их изменения за длительное время создания ПО.
Недостатки водопадного подхода
Страница 21 www.specialist.ru
Цикл управления риском при адаптивном планировании
Страница 22 www.specialist.ru
MSF: модель жизненного цикла разработки
Project plan approved
Out ofDevelopm
ent
Release Readiness Review
Deployment Milestone
Vision approved
Vision
Deploy
men
t
Build
Det
aile
d pl
anni
ngStabilize
Страница 23 www.specialist.ru
Методологии гибкой разработки программного обеспечения: Итерация
План
Анализ
ДизайнРазработка
Тест
Scott Schultz “Rapid Iterative Production Prototyping”, 1988
Страница 24 www.specialist.ruВ.В.Камалов. ITPM. Управление содержанием
Степень детализации WBS
Знаменуется получением одного или нескольких результатов
Являются частью логической последовательности, обеспечивающей правильное определение продукта проекта
Окончание сопровождается анализом результатов и текущего исполнения
ФАЗАПРОЕКТА
Work package (Пакет работ)
Элемент низшего уровня иерархии
Неделимый объект WBS
Комплекс работ, сгруппированный по заданным основаниям (критериям)
Декомпозиция
Страница 25 www.specialist.ruВ.В.Камалов., Динцис Д.Ю. ITPM. Управление содержанием
Другие результаты, возникающиена этапе разработки WBS
• Словарь иерархической структуры работ
• Обновление описания предметной области
• План управления предметной областью
• Запрошенные изменения• Базовый план
предметной области
Страница 28 www.specialist.ru
Инструмент управления (на примере Trello)
Глобальная доска
Доска пакетов (СКРАМ)
Доска исполнител
я
Страница 32 www.specialist.ru
Системные типы изменений
Категория изменения
Что затрагивается Сложность Длительность Способ реализации
Первая Модификация существующих рабочих процедур
Небольшая Быстрое изменение
Адаптивный
Вторая Существенное изменение рабочих процедур
Средняя Средняя Адаптивный/Проект/Программа
Третья Изменение ценностей компании
Очень сложные
Длительные Портфель
Страница 33 www.specialist.ru
Нельзя рассматривать людей исключительно как ресурс.
Людям нужно нечто большее, чем просто список заданий.
Мотивация команды
Страница 34 www.specialist.ru
Варианты построения команды
Комбинирование виртуальных и локальных команд Дорогостоящие эксперты и специалисты общего профиля Баланс между выделенными и функциональными членами
команды
Страница 35 www.specialist.ru
Рекомендуемый метод передачи информации — личный разговор (лицом к лицу)
Страница 36 www.specialist.ru
Инструменты взаимодействия команды
Парное программирование
Программирование, ведомое тестированием Совместное размещение (colocation)
Страница 38 www.specialist.ru
Инструмент совместной работына примере Slack
Страница 41 www.specialist.ru
Вопросы и контакты
dinzis@specialist.ru consult@dintsis.org www.ddintsis.com https://www.facebook.com/IPDanilDintsis http://www.specialist.ru/section/project-management
top related