'

Стратегический менеджмент при разработке программного обеспечения

Понравилась презентация – покажи это...





Слайд 0

Стратегический менеджмент при разработке программного обеспечения Михаил Елашкин Elashkin Research


Слайд 1

Программные проекты: как это часто бывает


Слайд 2

Проблемы разработки Масштабы решаемых бизнес-задач (значимость ИТ для бизнеса) Сложность современных прикладных систем Архитектурная Технологическая Прикладная (бизнес-функциональность) Качество создаваемых приложений и его оценка Скорость реализации проектов (продуктивность) Изменяющиеся требования/приоритеты Взаимодействие между всеми “сторонами” ИТ-проектов Между конечными пользователями и “айтишниками” Между бизнес-аналитиками и разработчиками Между разработчиками и тестировщиками ...


Слайд 3

“Хаос” ИТ-проектов (2004) http://www.standishgroup.com


Слайд 4


Слайд 5

Часто дела идут не по плану. Как узнать, что правильно, а что нет? Moment of crisis! route to planned goal (1969 lunar landing) route to better goal (“Titanic” movie) getting lost planned route to planned goal route to worse goal (ship Wasa) http://Alistair.Cockburn.us


Слайд 6

Top 10 причин успешности проектов 1. User Involvement 2. Executive Management Support 3. Clear Business Objectives 4. Experienced Project Manager 5. Minimizing Scope and Requirements 6. Iterative and Agile Process 7. Skilled Resources 8. Formal Methodology 9. Financial Management 10. Standard Tools and Infrastructure


Слайд 7

Какие бывают ИТ-проекты Создание новых систем Интеграция существующих систем Настройка и адаптация “готовых” систем


Слайд 8

Какие бывают ИТ-проекты Создание новых систем Интеграция существующих систем Настройка и адаптация “готовых” систем Является ли поддержка и эксплуатация системы самостоятельным проектом?


Слайд 9

Рамки проектов (constraints) Содержание/функциональность (scope) Сроки (schedule) Качество (quality) Бюджет (budget)


Слайд 10

Конфликты/компромиссы/риски в рамках проектов Подрядчик (ИТ) Приоритеты (priorities) Время (time) Продуктивность Стоимость (cost) Заказчик (бизнес) Содержание (scope) Сроки (schedule) Качество (qaulity) Бюджет (budget) Риски (risks) Компромиссы (compromise)


Слайд 11

Роль ограничений в проектах Источник: APM PMBOK (Project Management Body Of Knowledge)


Слайд 12

Потребности заказчика Соответствие ожиданиям Функциональные требования Удобство использования Качество Производительность Гарантированность достижения результата Бюджет Сроки Ресурсы Сохранение инвестиций Интеграция существующих приложений Использование существующей культуры и навыков


Слайд 13

Инструменты подрядчика Сохранение инвестиций Интеграция и повторное использование компонентов существующих систем Использование полученных навыков Эволюция вместо революции Модульное наращивание функциональности Прозрачность интеграции <существующих и новых> систем Унификация как инструмент снижения издержек Форматов обмена информацией Инструментальных средств и связующего ПО Повышение эффективности Улучшение процесса(-ов) разработки ПО


Слайд 14

Роль проектного менеджера: находить поддержку, мотивировать команду и блокировать проблемы Sponsor(s) Visibility Decisions $ Interruptions X PM developers Communication Amicability Priorities Focus time Skills development Motivation Reflection http://Alistair.Cockburn.us


Слайд 15

Управление проектами


Слайд 16

Проект Проект временное предприятие для создания уникального продукта или услуги Управление проектом (project management) приложение знаний, умений/навыков (skills), инструментов и техник/практик к проектной деятельности (activities) для удовлетворения требований к результату проекта http://www.pmi.org


Слайд 17

Дисциплина управления проектами


Слайд 18

Дисциплина управления проектами


Слайд 19

Дисциплина управления проектами


Слайд 20

Процесс Процесс определяет: Кто? Что? Когда (в какой последовательности) делает для достижения определенной цели


Слайд 21

*KPA “Область компетенции” <Knowledge/Key> <Process/Practice> Area описывает знания и практики в виде группы взаимосвязанных процессов, необходимых для решения определенного комплекса задач


Слайд 22

Жизненный цикл проектов (life cycle)


Слайд 23

Процессы


Слайд 24

Процессы и фазы проекта


Слайд 25

Правильная команда


Слайд 26


Слайд 27

Когда применять методики управления проектами?


Слайд 28

Эффективность коммуникаций


Слайд 29

Каскадная модель (водопад)


Слайд 30

Инкрементальная модель


Слайд 31

Эволюционная модель


Слайд 32

Варианты моделей процессов ЖЦ


Слайд 33

Факторы выбора


Слайд 34

Различная степень формализации планирования “Хакеры” XP Источник: Barry Boehm, © Center for Software Engineering, University of Southern California; (адаптировано) Максимально детализированный план Процесс на основе плана Процесс управляемый рисками Адаптивный процесс


Слайд 35

Различная степень формализации планирования “Хакеры” XP Источник: Barry Boehm, © Center for Software Engineering, University of Southern California; (адаптировано) Максимально детализированный план Процесс на основе плана Процесс управляемый рисками Адаптивный процесс Детализация планирования Степень формализации


Слайд 36

Различие в подходах к процессам


Слайд 37

The Problem: Project Results are Poor Source: THE STANDISH GROUP 2003


Слайд 38

Rework Costs are High Even for Successful Projects! Application development organizations typically spend about 40% of their development effort on rework


Слайд 39

Poor Requirements is the Principal Cause Distribution of Defects Source: James Martin Requirements 56% Code 7% Other 10% Design 27% Distribution of Effort to Repair Defects Requirements 82% Other 4% Design 13% Source: Dean Leffingwell


Слайд 40

Риски в области ПО (Software Risks)


Слайд 41

Возможные атрибуты рисков Категория риска Описание риска Признак(и) появления проблемы Близость риска (ожидаемое время наступления проблемы) План предотвращения риска Статус риска … Подверженность риску = вероятность * воздействие RE = L2 (Risk Exposure = Likelihood * Loss = Probability * Impact)


Слайд 42

Образ мыслей MSFv4 MSF – это не просто набор рекомендаций, MSF – это образ мыслей! MSF стремится к созданию культуры, которая помогает успешно выполнять проекты Образ мыслей – это набор ценностей, которые определяют, как мы интерпретируем ситуации и реагируем на них Образ мыслей помогает членам команды принимать решения, приоритезировать работу, представлять свои роли в команде и взаимодействовать с другими участниками проекта


Слайд 43

Основные принципы MSFv4 Взаимодействие с партнерами Поощрение открытого общения Общее видение проекта Качество – это ежедневная работа каждого сотрудника Оставайтесь гибкими, адаптируйтесь к изменениям Внедрение проекта должно стать привычкой Постоянная демонстрация прогресса для заказчика


Слайд 44

Состав MSFv4 Рекомендованные процессы создания ИТ-проектов Структура итераций Определение рабочих элементов, создаваемых в ИТ-проектах Стандартные рабочие элементы и критерии их создания/завершения Роли членов команды / Группы безопасности Шаблоны документов (Excel, Word) Шаблоны Microsoft Project Отчеты Портал проекта / Шаблон сайта SharePoint


Слайд 45

Скорость или предсказуемость? MSF Agile “Эволюция и адаптация” Идеально для условий конкуренции Опора на людей Планируй по мере продвижения MSF Formal “Планирование и оптимизация” Идеально для устойчивых условий Опора на процессы Планируй заранее


Слайд 46

Потоки работ в MSF Agile Формулировка целей и задач проекта Создание сценариев Создание требований по качеству обслуживания Планирование итераций Создание архитектуры решения Реализация задачи по разработке Построение продукта Тестирование сценария Тестирования требования по качеству обслуживания Исправление ошибок Закрытие ошибок Выпуск продукта Управление проектом


Слайд 47

The End.


×

HTML:





Ссылка: