SlideShare uma empresa Scribd logo
1 de 52
Baixar para ler offline
Как внедрить ALM систему управления командами разработки ПО (Agile (Scrum))  и остаться довольным.   По мотивам презентаций А.Пушников, Экстремальные методы управления проектами. Движение к успеху в условиях неопределенности   http://www.pmi.ru/articles/files/20022077_Pushnikov.pdf Денис Миллер, Сравнение методологий  http: // agileguru.ru CPMP, Phd, MBA,  А.Заходяйченко С [email_address]
Содержание ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
ПРАКТИКА: Определение Ваших предпочтительных ролей в  Agile (Scrum)  команде
Особенности  IT  проектов,  ALM,  рамки применения различных методологий разработки ПО (Опыт)
Статистика  IT  проектов * *  PM Network, September  ( анализ 23000 проектов) Успешные проекты Провальные проекты 46 % 28 % 26 % Проекты, столкнувшиеся  с проблемами
Соответствие целей проектов стратегии компании * Проекты компании (РФ) %
Потенциал разрешения трудностей членами команды проекта Проекты компании (РФ) %
Как может развиваться  IT  проект
Взаимосвязь элементов проекта
Матрица компромиссов проекта
Резюме проекта (пример) Что хотим видеть   Параметр KPI Срок выполнения проекта 10 мес. Срок окупаемости кредита на разработку  24 мес. Срок окупаемости кредита на внедрение  3 года Стоимость проекта 3 235 884 руб. Оценочная стоимость 1 изделия 180 000 руб. Прибыль от продажи 1 изделия 40 000 руб. Ожидаемая сумма продаж 150 600 000руб./год Ожидаемая прибыль 20 600 000 руб./год
Проектное управление в современной организации ( ALM) Программы   развития Поддерживающие процессы Стратегический план развития организации. Миссия организации, смысл ее существования. Основной бизнес процесс ,[object Object],[object Object],2.  The Standard for Portfolio Management  ( PMI) Стандарт для управления портфелями 3.  The Standard for Program Management  ( PMI)  Стандарт для управления программами
Проблемы СНИЖЕНИЕ КАЧЕСТВА выполненных работ Конфликт целей СРЫВ СРОКОВ ПЕРЕРАСХОД запланированных средств НЕДОСТИЖЕНИЕ ЦЕЛИ ПРОЕКТА ( Scope) Невыполнение  условий контрактов Неопределенность (…),  Плохой контроль ???
Жизненный цикл проекта и продукта
План контрольных точек ( Milestone plan) Правильно выделенный комплекс вех составляет серию  естественных контрольных точек проекта . Достижение вехи подразумевает переход проекта из одного состояния в другое Время Фактическое выполнение проекта Планируемый сценарий выполнения проекта Цель проекта Срок завершения проекта Веха 1 Веха 2
Применение ALM системы управления командами разработки ПО (Agile (Scrum))
Сравнение границ применения методологий Agile* Каскадный Высокоформализованные Низкоформализованные Эволюционный ГОСТ 12207 ГОСТ 19 ГОСТ 24 ГОСТ 34 Rational Unified Process, MSF Agile
Семь «секретов» успеха на пути изменений
Ключевые участники проекта  (IPMA)
Как обосновать внедрение.  (Vision)
Семь «секретов» успеха на пути изменений  ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Product Owner:  Подбираем тип контракта в зависимости от уровня неопределености проекта
[object Object],[object Object],[object Object],[object Object],[object Object],Типы контрактов
Соответствие типа контракта - уровню неопределенности проекта
Особенности формирования  Product Baclog  и планирования итерации ( iteration planing )
Ожидания заказчика  Product Baclog   Усилия разработчиков могут сосредоточиться в неверном направлении, и конечная реализация, даже являясь технически правильной, не будет полностью соответствовать потребностям пользователя 1. Как было предложено организатором разработки 2. Как было описано в техническом задании   3. Как было спроектировано ведущим системным специалистом 4.  Как было реализовано программистами   5. Как было внедрено 6.  Что хотел пользователь
Основные процессы планирования ( PMBOK 2008 )   и  iteration planning Agile  ( Scrum) Результат  (продукт) Product baclog Спринт  ( Sprint ) Список фичей (сделаны, на текущую и последующие итерации) Фокус – фактор Ответственность  Product Owner
Цели должны быть  SMART! S  -  specific  -  Конкретная   ,[object Object],[object Object],[object Object],M  -  measurable  -  Измеряемая А  -  allocat ed  –  Распределяемый   achievable  –  Достижимая R  -  realistic  –  Реалистичная   relevant   –  Уместная T  -  temporary  –  В ременная   timed   –   Согласованная по времени
Анализ  Product Baclog   Преобразование целей проекта в материальные результаты поставки и требования Product Baclog Способ достижения результата  (процесс) ТРЕБОВАНИЯ ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Современные концепции управления  Product Baclog :   качество , Lean,  теории ограничений Внутренний дефект Годная продукция Внешний дефект Не требуемые свойства Требуемые свойства Внешний дефект Неудовлетворен-ные требования Дополнительные затраты Ценность   продукта для производителя Стоимость  продукта для производителя Ценность  продукта для потребителя Стоимость  продукта для потребителя
Иерархическая структура работ  Product Baclog   (ИСР,  WBS,  СДР) ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Разработка  Product Baclog   Используемые подходы Декомпозиция: Разделение сложного на меньшие, простые, более управляемые элементы Объединение : Группировка отдельных элементов, имеющих общие признаки или взаимосвязи Шаблоны : Ранее разработанные элементы  WBS  различной степени детализации
Особенности анализа трудоемкости на основе метода 3-х точек
Особенности построения идеальной команды  Agile (Scrum)   TEAM
Принципы «идеальной» проектной команды ,[object Object],[object Object],[object Object],[object Object],[object Object],T     Together     вместе E     Everyone     каждый A     Achieves     достигает M     More     большего   КОНЦЕПЦИЯ T.E.A.M.
Профиль специалиста Индивидуально-личностные характеристики Навыки  ( умение вести переговоры , знание языков программирования,  управленческие навыки и т.д. ) Компетенции Степень нацеленности на результат Тип личности (Майер-Бригс)  Роли, которые может выполнятьспециалист по Р. Белбин
Пример Матрица навыков. Технические навыки Маркетинг и продажи Производство Работа с клиентами  Финансы Управление персоналом Контроль качества Лидер НИР Ирина Павел Илья Евгений Александр Марина 4   2   1   5   6 2   3   5 4   5 3   1   2 5   6 7   5   9 Навык Член команды
Оптимальная команда: выполняемые в команде  Agile (Scrum)  роли   // По Р. Белбину Product Owner Генератор идей Оформитель ( shaper ) Рабочая пчелка Scrum Master Добытчик Критик Завершающий (completer)
ПРАКТИКА: Определение Ваших предпочтительных ролей в  Agile (Scrum)  команде .  Подведение итогов.
Отсутствие роли  Product Owner ,[object Object],[object Object],[object Object],[object Object]
Отсутствие роли  оформителя (координатора) ,[object Object],[object Object],[object Object],[object Object],[object Object]
Отсутствие роли  генератора идей ,[object Object],[object Object],[object Object],[object Object]
Отсутствие роли  критика ,[object Object],[object Object]
Отсутствие роли  рабочей пчелки ,[object Object],[object Object]
Отсутствие роли  S crum Master ,[object Object],[object Object],[object Object],[object Object],[object Object]
Отсутствие роли  исследователя (добытчика) ,[object Object],[object Object],[object Object],[object Object],[object Object]
Отсутствие роли  завершающего ,[object Object],[object Object],[object Object]
Конфликт ролей . ,[object Object],[object Object],[object Object],[object Object]
Матрица совместимости ролей   ( MSF ) +   Возможно ±   Нежелательно -   Нельзя Управление продуктом Управление программой Разработка Тестирование Удовлетворение потребителя Управление выпуском Управление выпуском Удовлетворение   потребителя Тестирование Разработка Управление программой Управление продуктом - - - - - - - - - - - - + + + + + + + + + + ± ± ± ± ± ± ± ±
Проблемы сплоченной команды Малое количество вариантов «Зацикливание» Непринятие новых рисков Отвергание новых действий Отказ от внешней экспертизы Предвзятость к собственной позиции Отвергание организационных активов Очень сплоченная команда Ошибки в проекте
BesTeamKP I ® – симулятор управления портфелем  IT  проектов  Agile (Scrum) .
Спасибо за внимание. Вопросы   CPMP, MBA, Phd  А.Заходяйченко С [email_address]

Mais conteúdo relacionado

Mais procurados

Опыт применения метода ATAM для оценки архитектуры
Опыт применения метода ATAM для оценки архитектурыОпыт применения метода ATAM для оценки архитектуры
Опыт применения метода ATAM для оценки архитектурыCUSTIS
 
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделятьОтветственность за качество в разных ИТ-проектах: в чем она и как ее разделять
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделятьCUSTIS
 
Модуль 2: Лекция 9-10. Обзор методологий, фреймворков
Модуль 2: Лекция 9-10.  Обзор методологий, фреймворковМодуль 2: Лекция 9-10.  Обзор методологий, фреймворков
Модуль 2: Лекция 9-10. Обзор методологий, фреймворковYana Brodetski
 
Методики ITSM для карьеры ИТ специалиста
Методики ITSM для карьеры ИТ специалистаМетодики ITSM для карьеры ИТ специалиста
Методики ITSM для карьеры ИТ специалистаDanil Dintsis, Ph. D., PgMP
 
Менеджер продукта: где границы роли?
Менеджер продукта: где границы роли?Менеджер продукта: где границы роли?
Менеджер продукта: где границы роли?Yury Kupriyanov
 
Управление ИТ-проектами на основе PRINCE2®
Управление ИТ-проектами на основе PRINCE2®Управление ИТ-проектами на основе PRINCE2®
Управление ИТ-проектами на основе PRINCE2®Cleverics
 
Как организовать портфель проектов и сервисов в стартап-компании и вывести ег...
Как организовать портфель проектов и сервисов в стартап-компании и вывести ег...Как организовать портфель проектов и сервисов в стартап-компании и вывести ег...
Как организовать портфель проектов и сервисов в стартап-компании и вывести ег...Danil Dintsis, Ph. D., PgMP
 
Управление проектами в соответствии со стандартами PMI (PMBoK)
Управление проектами в соответствии со стандартами PMI (PMBoK)Управление проектами в соответствии со стандартами PMI (PMBoK)
Управление проектами в соответствии со стандартами PMI (PMBoK)Vladimir Melnikov
 
Вебинар: ИТ-проекты глазами Заказчика
Вебинар: ИТ-проекты глазами ЗаказчикаВебинар: ИТ-проекты глазами Заказчика
Вебинар: ИТ-проекты глазами ЗаказчикаАлександр Кольцов
 
портфель проектов как сформировать
портфель проектов   как сформироватьпортфель проектов   как сформировать
портфель проектов как сформироватьЕвгений Пикулев
 
Слайдкаст. Управление рисками, Q and A. Stratoplan.ru. Клуб ИТ Менеджеров
Слайдкаст. Управление рисками, Q and A. Stratoplan.ru. Клуб ИТ МенеджеровСлайдкаст. Управление рисками, Q and A. Stratoplan.ru. Клуб ИТ Менеджеров
Слайдкаст. Управление рисками, Q and A. Stratoplan.ru. Клуб ИТ МенеджеровSergiy Povolyashko
 
от каждого по потребностям, каждому — по Agile
от каждого по потребностям, каждому — по Agileот каждого по потребностям, каждому — по Agile
от каждого по потребностям, каждому — по AgileAlexey Deryushkin
 
PRINCE2® - лучшая практика управления проектами. В. Полковников
PRINCE2® - лучшая практика управления проектами. В. ПолковниковPRINCE2® - лучшая практика управления проектами. В. Полковников
PRINCE2® - лучшая практика управления проектами. В. ПолковниковProjectPractice2013
 
Собираем кубик Рубика
Собираем кубик РубикаСобираем кубик Рубика
Собираем кубик РубикаCEE-SEC(R)
 
Методы и модели формирования портфеля проектов
Методы и модели формирования портфеля проектовМетоды и модели формирования портфеля проектов
Методы и модели формирования портфеля проектовДмитрий Гергерт
 
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаМодуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
 

Mais procurados (20)

Менеджер ИТ продукта
Менеджер ИТ продуктаМенеджер ИТ продукта
Менеджер ИТ продукта
 
Опыт применения метода ATAM для оценки архитектуры
Опыт применения метода ATAM для оценки архитектурыОпыт применения метода ATAM для оценки архитектуры
Опыт применения метода ATAM для оценки архитектуры
 
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделятьОтветственность за качество в разных ИТ-проектах: в чем она и как ее разделять
Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять
 
Модуль 2: Лекция 9-10. Обзор методологий, фреймворков
Модуль 2: Лекция 9-10.  Обзор методологий, фреймворковМодуль 2: Лекция 9-10.  Обзор методологий, фреймворков
Модуль 2: Лекция 9-10. Обзор методологий, фреймворков
 
Методики ITSM для карьеры ИТ специалиста
Методики ITSM для карьеры ИТ специалистаМетодики ITSM для карьеры ИТ специалиста
Методики ITSM для карьеры ИТ специалиста
 
Менеджер продукта: где границы роли?
Менеджер продукта: где границы роли?Менеджер продукта: где границы роли?
Менеджер продукта: где границы роли?
 
Управление ИТ-проектами на основе PRINCE2®
Управление ИТ-проектами на основе PRINCE2®Управление ИТ-проектами на основе PRINCE2®
Управление ИТ-проектами на основе PRINCE2®
 
Как организовать портфель проектов и сервисов в стартап-компании и вывести ег...
Как организовать портфель проектов и сервисов в стартап-компании и вывести ег...Как организовать портфель проектов и сервисов в стартап-компании и вывести ег...
Как организовать портфель проектов и сервисов в стартап-компании и вывести ег...
 
Управление проектами в соответствии со стандартами PMI (PMBoK)
Управление проектами в соответствии со стандартами PMI (PMBoK)Управление проектами в соответствии со стандартами PMI (PMBoK)
Управление проектами в соответствии со стандартами PMI (PMBoK)
 
Что делает Скрам Мастер на проекте
Что делает Скрам Мастер на проектеЧто делает Скрам Мастер на проекте
Что делает Скрам Мастер на проекте
 
Вебинар: ИТ-проекты глазами Заказчика
Вебинар: ИТ-проекты глазами ЗаказчикаВебинар: ИТ-проекты глазами Заказчика
Вебинар: ИТ-проекты глазами Заказчика
 
портфель проектов как сформировать
портфель проектов   как сформироватьпортфель проектов   как сформировать
портфель проектов как сформировать
 
Lection 1 2_pm
Lection 1 2_pmLection 1 2_pm
Lection 1 2_pm
 
Слайдкаст. Управление рисками, Q and A. Stratoplan.ru. Клуб ИТ Менеджеров
Слайдкаст. Управление рисками, Q and A. Stratoplan.ru. Клуб ИТ МенеджеровСлайдкаст. Управление рисками, Q and A. Stratoplan.ru. Клуб ИТ Менеджеров
Слайдкаст. Управление рисками, Q and A. Stratoplan.ru. Клуб ИТ Менеджеров
 
PM competencies model and PM-HR interaction
PM competencies model and PM-HR interactionPM competencies model and PM-HR interaction
PM competencies model and PM-HR interaction
 
от каждого по потребностям, каждому — по Agile
от каждого по потребностям, каждому — по Agileот каждого по потребностям, каждому — по Agile
от каждого по потребностям, каждому — по Agile
 
PRINCE2® - лучшая практика управления проектами. В. Полковников
PRINCE2® - лучшая практика управления проектами. В. ПолковниковPRINCE2® - лучшая практика управления проектами. В. Полковников
PRINCE2® - лучшая практика управления проектами. В. Полковников
 
Собираем кубик Рубика
Собираем кубик РубикаСобираем кубик Рубика
Собираем кубик Рубика
 
Методы и модели формирования портфеля проектов
Методы и модели формирования портфеля проектовМетоды и модели формирования портфеля проектов
Методы и модели формирования портфеля проектов
 
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаМодуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
 

Semelhante a Как внедрить ALM/ Упр. командами разработки по (agile (scrum))

Андрій Мандріка “Ефективний Product owner 2018. Хто він? І чи є майбутнє у ці...
Андрій Мандріка “Ефективний Product owner 2018. Хто він? І чи є майбутнє у ці...Андрій Мандріка “Ефективний Product owner 2018. Хто він? І чи є майбутнє у ці...
Андрій Мандріка “Ефективний Product owner 2018. Хто він? І чи є майбутнє у ці...Lviv Startup Club
 
Слайдкаст. Stratoplan Kharkov. Методологический паззл.
Слайдкаст. Stratoplan Kharkov. Методологический паззл.Слайдкаст. Stratoplan Kharkov. Методологический паззл.
Слайдкаст. Stratoplan Kharkov. Методологический паззл.Sergiy Povolyashko
 
ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1
ЛАФ7  Гибкий бизнес и принципы постановки задачи  v1 1ЛАФ7  Гибкий бизнес и принципы постановки задачи  v1 1
ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1Dmitry Bezuglyy
 
Проектная команда: состав, роли, коммуникации
Проектная команда: состав, роли, коммуникацииПроектная команда: состав, роли, коммуникации
Проектная команда: состав, роли, коммуникацииDaria Veldina
 
Redistributable intro To Scrum, Russian
Redistributable intro To Scrum, RussianRedistributable intro To Scrum, Russian
Redistributable intro To Scrum, RussianAlexey Krivitsky
 
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Dakiry
 
Introduction into Agile webinar presentation by Roman Moroz
Introduction into Agile webinar presentation by Roman MorozIntroduction into Agile webinar presentation by Roman Moroz
Introduction into Agile webinar presentation by Roman MorozReturn on Intelligence
 
Ad 2009 - agile в кризис
Ad 2009 - agile в кризисAd 2009 - agile в кризис
Ad 2009 - agile в кризисAlexey Korsun
 
Agile на Смертельном Марше
Agile на Смертельном МаршеAgile на Смертельном Марше
Agile на Смертельном МаршеNikita Filippov
 
Международная и российская практика проектного управления
Международная и российская практика проектного управленияМеждународная и российская практика проектного управления
Международная и российская практика проектного управленияПавел Шестопалов
 
Проект внедрения КИС
Проект внедрения КИСПроект внедрения КИС
Проект внедрения КИСSergey Timofeev
 
Гибкие методологии разработки: максимальный результат для бизнеса с минимальн...
Гибкие методологии разработки: максимальный результат для бизнеса с минимальн...Гибкие методологии разработки: максимальный результат для бизнеса с минимальн...
Гибкие методологии разработки: максимальный результат для бизнеса с минимальн...Alexey Tigarev
 
Agile/Scrum методологии разработки программного обеспечения
Agile/Scrum методологии разработки программного обеспеченияAgile/Scrum методологии разработки программного обеспечения
Agile/Scrum методологии разработки программного обеспеченияjazzteam
 
Инструменты гибкого управления: Agile / Kanban / Scrum
Инструменты гибкого управления: Agile / Kanban / ScrumИнструменты гибкого управления: Agile / Kanban / Scrum
Инструменты гибкого управления: Agile / Kanban / ScrumDenis Tuchin
 

Semelhante a Как внедрить ALM/ Упр. командами разработки по (agile (scrum)) (20)

Scrum framework
Scrum frameworkScrum framework
Scrum framework
 
Введение в Scrum
Введение в ScrumВведение в Scrum
Введение в Scrum
 
Scrum execution
Scrum executionScrum execution
Scrum execution
 
Андрій Мандріка “Ефективний Product owner 2018. Хто він? І чи є майбутнє у ці...
Андрій Мандріка “Ефективний Product owner 2018. Хто він? І чи є майбутнє у ці...Андрій Мандріка “Ефективний Product owner 2018. Хто він? І чи є майбутнє у ці...
Андрій Мандріка “Ефективний Product owner 2018. Хто він? І чи є майбутнє у ці...
 
Слайдкаст. Stratoplan Kharkov. Методологический паззл.
Слайдкаст. Stratoplan Kharkov. Методологический паззл.Слайдкаст. Stratoplan Kharkov. Методологический паззл.
Слайдкаст. Stratoplan Kharkov. Методологический паззл.
 
ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1
ЛАФ7  Гибкий бизнес и принципы постановки задачи  v1 1ЛАФ7  Гибкий бизнес и принципы постановки задачи  v1 1
ЛАФ7 Гибкий бизнес и принципы постановки задачи v1 1
 
It-tuning itsm_pm
It-tuning itsm_pmIt-tuning itsm_pm
It-tuning itsm_pm
 
Проектная команда: состав, роли, коммуникации
Проектная команда: состав, роли, коммуникацииПроектная команда: состав, роли, коммуникации
Проектная команда: состав, роли, коммуникации
 
Redistributable intro To Scrum, Russian
Redistributable intro To Scrum, RussianRedistributable intro To Scrum, Russian
Redistributable intro To Scrum, Russian
 
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
 
Introduction into Agile webinar presentation by Roman Moroz
Introduction into Agile webinar presentation by Roman MorozIntroduction into Agile webinar presentation by Roman Moroz
Introduction into Agile webinar presentation by Roman Moroz
 
AgilePlanning
AgilePlanningAgilePlanning
AgilePlanning
 
Ad 2009 - agile в кризис
Ad 2009 - agile в кризисAd 2009 - agile в кризис
Ad 2009 - agile в кризис
 
Agile на Смертельном Марше
Agile на Смертельном МаршеAgile на Смертельном Марше
Agile на Смертельном Марше
 
Мария Романова. Необходимо ли вашей компании системное управление проектами?
Мария Романова. Необходимо ли вашей компании системное управление проектами? Мария Романова. Необходимо ли вашей компании системное управление проектами?
Мария Романова. Необходимо ли вашей компании системное управление проектами?
 
Международная и российская практика проектного управления
Международная и российская практика проектного управленияМеждународная и российская практика проектного управления
Международная и российская практика проектного управления
 
Проект внедрения КИС
Проект внедрения КИСПроект внедрения КИС
Проект внедрения КИС
 
Гибкие методологии разработки: максимальный результат для бизнеса с минимальн...
Гибкие методологии разработки: максимальный результат для бизнеса с минимальн...Гибкие методологии разработки: максимальный результат для бизнеса с минимальн...
Гибкие методологии разработки: максимальный результат для бизнеса с минимальн...
 
Agile/Scrum методологии разработки программного обеспечения
Agile/Scrum методологии разработки программного обеспеченияAgile/Scrum методологии разработки программного обеспечения
Agile/Scrum методологии разработки программного обеспечения
 
Инструменты гибкого управления: Agile / Kanban / Scrum
Инструменты гибкого управления: Agile / Kanban / ScrumИнструменты гибкого управления: Agile / Kanban / Scrum
Инструменты гибкого управления: Agile / Kanban / Scrum
 

Как внедрить ALM/ Упр. командами разработки по (agile (scrum))

  • 1. Как внедрить ALM систему управления командами разработки ПО (Agile (Scrum)) и остаться довольным.  По мотивам презентаций А.Пушников, Экстремальные методы управления проектами. Движение к успеху в условиях неопределенности http://www.pmi.ru/articles/files/20022077_Pushnikov.pdf Денис Миллер, Сравнение методологий http: // agileguru.ru CPMP, Phd, MBA, А.Заходяйченко С [email_address]
  • 2.
  • 3. ПРАКТИКА: Определение Ваших предпочтительных ролей в Agile (Scrum) команде
  • 4. Особенности IT проектов, ALM, рамки применения различных методологий разработки ПО (Опыт)
  • 5. Статистика IT проектов * * PM Network, September ( анализ 23000 проектов) Успешные проекты Провальные проекты 46 % 28 % 26 % Проекты, столкнувшиеся с проблемами
  • 6. Соответствие целей проектов стратегии компании * Проекты компании (РФ) %
  • 7. Потенциал разрешения трудностей членами команды проекта Проекты компании (РФ) %
  • 11. Резюме проекта (пример) Что хотим видеть  Параметр KPI Срок выполнения проекта 10 мес. Срок окупаемости кредита на разработку 24 мес. Срок окупаемости кредита на внедрение 3 года Стоимость проекта 3 235 884 руб. Оценочная стоимость 1 изделия 180 000 руб. Прибыль от продажи 1 изделия 40 000 руб. Ожидаемая сумма продаж 150 600 000руб./год Ожидаемая прибыль 20 600 000 руб./год
  • 12.
  • 13. Проблемы СНИЖЕНИЕ КАЧЕСТВА выполненных работ Конфликт целей СРЫВ СРОКОВ ПЕРЕРАСХОД запланированных средств НЕДОСТИЖЕНИЕ ЦЕЛИ ПРОЕКТА ( Scope) Невыполнение условий контрактов Неопределенность (…), Плохой контроль ???
  • 15. План контрольных точек ( Milestone plan) Правильно выделенный комплекс вех составляет серию естественных контрольных точек проекта . Достижение вехи подразумевает переход проекта из одного состояния в другое Время Фактическое выполнение проекта Планируемый сценарий выполнения проекта Цель проекта Срок завершения проекта Веха 1 Веха 2
  • 16. Применение ALM системы управления командами разработки ПО (Agile (Scrum))
  • 17. Сравнение границ применения методологий Agile* Каскадный Высокоформализованные Низкоформализованные Эволюционный ГОСТ 12207 ГОСТ 19 ГОСТ 24 ГОСТ 34 Rational Unified Process, MSF Agile
  • 18. Семь «секретов» успеха на пути изменений
  • 21.
  • 22. Product Owner: Подбираем тип контракта в зависимости от уровня неопределености проекта
  • 23.
  • 24. Соответствие типа контракта - уровню неопределенности проекта
  • 25. Особенности формирования Product Baclog и планирования итерации ( iteration planing )
  • 26. Ожидания заказчика Product Baclog Усилия разработчиков могут сосредоточиться в неверном направлении, и конечная реализация, даже являясь технически правильной, не будет полностью соответствовать потребностям пользователя 1. Как было предложено организатором разработки 2. Как было описано в техническом задании 3. Как было спроектировано ведущим системным специалистом 4. Как было реализовано программистами 5. Как было внедрено 6. Что хотел пользователь
  • 27. Основные процессы планирования ( PMBOK 2008 ) и iteration planning Agile ( Scrum) Результат (продукт) Product baclog Спринт ( Sprint ) Список фичей (сделаны, на текущую и последующие итерации) Фокус – фактор Ответственность Product Owner
  • 28.
  • 29.
  • 30. Современные концепции управления Product Baclog : качество , Lean, теории ограничений Внутренний дефект Годная продукция Внешний дефект Не требуемые свойства Требуемые свойства Внешний дефект Неудовлетворен-ные требования Дополнительные затраты Ценность продукта для производителя Стоимость продукта для производителя Ценность продукта для потребителя Стоимость продукта для потребителя
  • 31.
  • 32. Разработка Product Baclog Используемые подходы Декомпозиция: Разделение сложного на меньшие, простые, более управляемые элементы Объединение : Группировка отдельных элементов, имеющих общие признаки или взаимосвязи Шаблоны : Ранее разработанные элементы WBS различной степени детализации
  • 33. Особенности анализа трудоемкости на основе метода 3-х точек
  • 35.
  • 36. Профиль специалиста Индивидуально-личностные характеристики Навыки ( умение вести переговоры , знание языков программирования, управленческие навыки и т.д. ) Компетенции Степень нацеленности на результат Тип личности (Майер-Бригс) Роли, которые может выполнятьспециалист по Р. Белбин
  • 37. Пример Матрица навыков. Технические навыки Маркетинг и продажи Производство Работа с клиентами Финансы Управление персоналом Контроль качества Лидер НИР Ирина Павел Илья Евгений Александр Марина 4 2 1 5 6 2 3 5 4 5 3 1 2 5 6 7 5 9 Навык Член команды
  • 38. Оптимальная команда: выполняемые в команде Agile (Scrum) роли  // По Р. Белбину Product Owner Генератор идей Оформитель ( shaper ) Рабочая пчелка Scrum Master Добытчик Критик Завершающий (completer)
  • 39. ПРАКТИКА: Определение Ваших предпочтительных ролей в Agile (Scrum) команде . Подведение итогов.
  • 40.
  • 41.
  • 42.
  • 43.
  • 44.
  • 45.
  • 46.
  • 47.
  • 48.
  • 49. Матрица совместимости ролей ( MSF ) + Возможно ± Нежелательно - Нельзя Управление продуктом Управление программой Разработка Тестирование Удовлетворение потребителя Управление выпуском Управление выпуском Удовлетворение потребителя Тестирование Разработка Управление программой Управление продуктом - - - - - - - - - - - - + + + + + + + + + + ± ± ± ± ± ± ± ±
  • 50. Проблемы сплоченной команды Малое количество вариантов «Зацикливание» Непринятие новых рисков Отвергание новых действий Отказ от внешней экспертизы Предвзятость к собственной позиции Отвергание организационных активов Очень сплоченная команда Ошибки в проекте
  • 51. BesTeamKP I ® – симулятор управления портфелем IT проектов Agile (Scrum) .
  • 52. Спасибо за внимание. Вопросы  CPMP, MBA, Phd А.Заходяйченко С [email_address]

Notas do Editor

  1. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Краткое содержание : Основные стандарты управления проектами ; Понятие проекта ; Виды проектов по внедрению ИС ; Управление проектами как дисциплина ; Системы управления проектами. Из этой темы Вы узнаете: Международные стандарты по управлению проектами; Виды сертификации в области управления проектами; Основные понятия о проекте; Окружение проекта; Стандарты и нормативы при управлении проектами; Классификацию проектов Отличия ИТ-проектов от проектов в других отраслях; Развитие образования в области управления проектами; Система управления проектами; Программное обеспечение для управления проектами.
  2. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» На чем базируется изложение материала темы? Изложение материала темы базируется на требованиях к структуре и составу процедур управления, изложенных в стандартах Института Управления Проектами США (PMI, PMBoK 2004) и соответствует требованиям Российской Ассоциации Управления Проектами (Совнет, НТК 2001 - Национальные требования к компетенции специалистов по управлению проектами). На семействе стандартов ИСО 9000, которые были разработаны для того, чтобы помочь организациям всех видов и размеров внедрять и обеспечивать функционирование эффективных систем менеджмента качества: ГОСТ Р ИСО 9000-2001 описывает основные положения систем менеджмента качества и устанавливает терминологию для систем менеджмента качества; ГОСТ Р ИСО 9001-2001 определяет требования к системам менеджмента качества для тех случаев, когда организации необходимо продемонстрировать свою способность предоставлять продукцию, отвечающую требованиям потребителей и установленным к ней обязательным требованиям, и направлен на повышение удовлетворенности потребителей; ГОСТ Р ИСО 9004-2001 содержит рекомендации, рассматривающие как результативность, так и эффективность системы менеджмента качества. Целью этого стандарта является улучшение деятельности организации и удовлетворенность потребителей и других заинтересованных сторон. Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ 1 -
  3. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 -
  4. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок : __________________________ _______________ ________________________________ _________________________________________ _________ _____ ______ ____________ ___________________________________________________________ ______________ ______________________________________________________ __ _____ ____________ _________________________________________ _______________ _________________ ______________________________________________________ ____________ _____ __ _________________________________________ _______________ _____________________________________________________________________________ _____________ ___________________________________________________________ ______________ _________________________________________ _______________ _____________________________________________________________________________ _____________ ___________________________________________________________ ______________ _________________________________________ _______________ _____________________________________________________________________________ _____________ ___________________________________________________________ ______________
  5. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Возможный вариант развития проекта По статистике, не все проекты завершаются успешно. Приходилось ли вам участвовать в проекте, когда энтузиазм сменялся разочарованием и завершался «награждением тех, кто не участвовал»? Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Тема №1 Пререквизиты проекта и начальный этап проекта
  6. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Три важнейших фактора проекта Любой проект характеризуется тремя важнейшими факторами: Временем Стоимостью Масштабом Эти факторы удобно иллюстрировать в виде сторон так называемого проектного треугольника. Каждая из сторон имеет следующий смысл: Сторона треугольника «Время» определяется длительностью выполняемых в проекте задач. Сторона треугольника «Стоимость» определяется стоимостью используемых в проекте ресурсов: персонала, оборудования и материалов. Сторона треугольника «Масштаб» зависит от рамок и размера проекта, а также от того, какие назначения сделал менеджер проекта. Чем рациональнее он распределит нагрузку ресурсов, тем больших результатов ему удастся добиться в проекте, и, стало быть, тем шире будет область охвата проекта. Таким образом, три стороны треугольника взаимосвязаны, потому что при внесении изменения в один из этих элементов меняются два других. Задача менеджера проекта добиться первоначального равновесия сторон проектного треугольника: уложиться в сроки, выполнить проект в рамках выделенного бюджета и получить результаты, которые удовлетворяют требованиям заказчика. Для заметок : __________________________________________________________________________ __________________________________________________________________________ Тема №1 Пререквизиты проекта и начальный этап проекта
  7. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для демонстрации результатов проведенных исследований и расчетов в области организационно-экономической целесообразности выполнения проекта следует показать в графической форме: сетевой график выполнения проекта; ленточный график выполнения проекта (диаграмма Ганта); график потребности в трудовых ресурсах; структуру затрат на выполнение проекта в виде круговой диаграммы; числовые параметры, характеризующие экономическую целесообразность выполнения проекта.
  8. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Матрица компромиссов проекта – это простое и удобное средство для принятия решений Матрица помогает расставить приоритеты, обсудить их с заказчиком. С помощью матрицы определяют какой из трех факторов проекта: время, стоимость или масштаб – нужно сдерживать, какой нужно усилить, а с каким нужно согласиться. Столбцы матрицы имеют следующий смысл: Зафиксировать Изменить Пересчитать и принять В строках матрицы отображаются время, стоимость, масштаб. Менеджер проекта вместе с заказчиком решают, что нужно сделать с каждым из трех факторов, и матрица облегчает достижение соглашения по спорным вопросам. Зафиксировать. Матрица помогает обозначить проектное ограничение, воздействие на которое практически невозможно в столбце «Зафиксировать». Смысл ограничения ресурсов ясен. Ограничение по срокам означает, что дату окончания проекта невозможно перенести. Ограничение по масштабу – это стратегия выпуска продукта или услуги с набором базовых характеристик. Изменить. В столбце «Изменить» отображается элемент, который требует наилучшего значения в конце проекта. Например, оптимизация ресурсов – это минимальное их использование, оптимизация времени – это успешное завершение проекта в короткий срок, а оптимизация масштаба – это выпуск продукта или оказание услуги с наибольшим набором возможностей. Пересчитать и принять. Когда одна переменная зафиксирована, а вторая оптимизируется, то значение третьей переменной определяется значениями первых двух. Тема №1 Пререквизиты проекта и начальный этап проекта
  9. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Давайте теперь посмотрим, как у нас нагромождаются проблемы Несвоевременная отчётность – это отчётность, которую вы предоставляете заказчику или своему руководителю. Это также отчётность, которую вам предоставляют сотрудники вашей команды. Несвоевременная отчётность может повлечь за собой несвоевременное обнаружение проблем в проекте. Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Тема №1 Пререквизиты проекта и начальный этап проекта
  10. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 2 - Ключевые участники проекта Поскольку проект считается успешным, когда он отвечает ожиданием ключевых участников, то в любом проекте важно определить, кто является ключевыми участниками проекта и как они могут и будут влиять на него. Чтобы определить круг ключевых участников проекта, менеджер проекта должен ответить на вопросы: Чьи интересы будут затронуты по ходу или результатам проекта? Какие функции или бизнес-процессы изменятся в результате выполнения проекта? Кто выделяет ресурсы для проекта (люди, помещение, рабочее время, инструменты, деньги)? Кто будет исполнять работы по проекту? Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  11. Обзор методологии MSF
  12. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Основным результатом определения предметной области является документ , содержащий описание предметной области, которое позволяет определить цели проекта, требования к организации работ, сроки и стоимость, границы проекта и т.д. Описание предметной области позволяет определить: Цели проекта: измеримые результаты, их характеристики Требования к организации работ: условия, стандарты, обязательства Сроки и стоимость Границы проекта Критерии приемки результата Ограничения и допущения Контрольные события Изначально сформулированные риски Участники проекта  Возможно, таких документов будет несколько: на этапе инициации и на этапе планирования. На этапе инициации описание предметной области содержит требования, необходимые для принятия решения о начале проекта.  Обычно это самые существенные требования. Он может называться: Концепция продукта или услуги Концептуальные требования Техническое задание [ГОСТ 34.602-89 ] Вполне допустимо, что как общие, так и детальные требования будут описаны одним документом, который создается постепенно, в несколько этапов.  Не следует углубляться в излишние детали до принятия решения о начале проекта. После определения и подтверждения требований можно приступать к детализации утвержденной части проекта.
  13. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 9 - Основные различия Определение требований к проекту: в ИТ-отрасли, в отличие от других, часты ситуации, когда требования к проекту чётко не определены. Это может быть связано с большим количеством заинтересованных лиц проекта, неясностью целей заказчика. Как правило, именно инициатор или заказчик проекта до конца не знает, чего он ждёт от конкретного ИТ-проекта. Нередко возникновение сложностей при завершении проектов, когда руководство компании выставляет дополнительные условия и требования при закрытии. Порой бывает очень трудно убедить высшее руководство компании в необходимости инвестиции в ИТ. Статистика такова, что более половины всех проектов остаются незавершёнными при отсутствии должной поддержки со стороны высшего руководства. При затягивании проектов (например, внедрении ERP ) возможны случаи, когда внедряемые технологии морально устаревают, и результатом внедрения становится старт нового проекта – уже по модернизации. Что касается самого внедрения продукта, то руководители ИТ-проектов сталкиваются с противодействием пользователей. При разработке продуктов ИТ критически важно учитывать мнение конечных пользователей. Ну и, конечно же, изменения в процессе реализации ИТ-проекта могут свести на нет все усилия проектной команды. А потому при реализации ИТ-проектов, особенно крупных, критически важно формализовать процедуру внесения изменений. Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Тема №9 Особенности организации и управления крупными ИТ проектами
  14. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Тема №1 Пререквизиты проекта и начальный этап проекта
  15. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Жизненный цикл продукта и жизненный цикл проекта Как известно, проекты состоят из процессов. Процессы – это серии действий, которые ведут к получению результата. Нужно различать две категории процессов: Процессы управления продуктом Продукт – это результат, это то, что создается, или услуга, которая будет оказана. Процессы управления проектом Проект – это работа, которую нужно выполнить, для того чтобы создать продукт или услугу. Эти две группы процессов могут перекрываться и интерактивно взаимодействовать в ходе проекта. Например, масштаб проекта не может быть определен, если нет понимания того, как создавать продукт. Слова «жизненный цикл» относятся и к продукту, и к проекту. Взаимосвязь жизненного цикла проекта с жизненным циклом продукта сильно зависит от отрасли. Например, проект, целью которого является разработка нового вида персонального компьютера для рынка. Этот проект – лишь одна фаза жизненного цикла продукта. Обычно в результате проекта получают один вид продукта. Например, целью большого проекта является внедрение EPM решения (Enterprise Project Management – Система для корпоративного управления проектами) в рамках всей организации. Внедренное решение – это один большой продукт, в который могут входить другие, более мелкие компоненты: внедрение в рамках пилотной зоны, в рамках отдельного департамента, в рамках всей организации. Каждый из компонентов может включать другие, более мелкие компоненты. Тема №1 Пререквизиты проекта и начальный этап проекта
  16. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Качество продукции с точки зрения производителя и потребителя Взгляды на качество продукции со стороны производителя и потребителя разные. Они по-разному измеряют ценность и стоимость продукции. Производители, как правило, измеряют величину ценности своей продукции на основе затрат на производство. Для производителя цена и ценность продукции имеют одно и то же значение. Потребитель отождествляет как ценность только лишь ту часть свойств продукции, которая соответствует его потребностям и ожиданиям (требуемые свойства) Часть стоимости продукции может не представлять ни какой ценности для потребителя. Более тонкий аспект относится к ощущению потребителя, когда он чувствует, что платит больше, чем надлежит за полученный им набор технических характеристик. Фактический набор потребительских свойств продукции может не содержать некоторой специфической характеристики, необходимой потребителю. В этом случае, потребитель должен будет приложить дополнительные усилия (время и затраты) для того, чтобы получить в итоге желаемый результат. Для производителя соотношение ценности и стоимости всегда кажется более выигрышным, чем для потребителя. Возможны 4 стратегии повышения качества:  ценность  , стоимость  (повышение ценности больше повышения стоимости);  ценность  , стоимость  const (повышается ценность без увеличения стоимости);  ценность  const , стоимость  (снижается стоимость без увеличения ценности);  ценность  , стоимость  (снижение стоимости больше снижения ценности). Реализовать выбранную Руководством стратегию повышения удовлетворенности потребителя можно только при сокращении затрат на контроль и исправление дефектов и несоответствий. Эти затраты сокращаются только при наличии механизма предотвращения дефектов. А это, в свою очередь, возможно только при создании СМК
  17. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Поскольку управление проектом — это конечное действие, группа процессов инициации начинает эти циклы, а группа завершающих процессов закрывает их. Интеграционная природа управления проектами требует, чтобы группа процессов мониторинга и управления взаимодействовала с каждым аспектом других групп процессов. Группа завершающих процессов, к которым и относится закрытие проекта, формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению. В группу завершающих процессов входят процессы, используемые для формального завершения всех операций проекта или фазы проекта, передачи завершенного продукта другим лицам или закрытия остановленного проекта. Когда эта группа процессов выполнена, она подтверждает, что во всех группах процессов должным образом совершены определенные процессы для закрытия проекта или фазы проекта, и формально устанавливает, что проект или фаза проекта окончены. Для заметок: ____________________________________________________________________________________________________________________________ _ ____________________________________________________________________________________________________________________________________________________________ _______________ ________________________________________________________________________________________________________________________________________________________________________________________________________________ ______________ ____________________________________________________________________________________________________________________________________________________
  18. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок : ______________________________________________________________________ ____ _______________________________________________________________________ ___ _______________________________________________________________________ ___ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _______________________________________________________________________ ___ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _________________________________________ _____ ____________________________ _________________________________________ _____ ____________________________ _____________________________________________________________________ _____ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _________________________________________ _____ ____________________________ _________________________________________ _____ ____________________________ _____________________________________________________________________ _____ 3 -
  19. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)». В настоящее время существует множество моделей жизненного цикла ИС, но три из них – фундаментальные. Этими фундаментальными моделями жизненного цикла являются: Каскадная Инкрементная Эволюционная Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла. При этом конкретную модель жизненного цикла следует выбирать так, чтобы процессы, работы и задачи из ГОСТ Р ИСО/МЭК 12207 были связаны между собой и определены их взаимосвязи с предшествующими процессами, работами (видами деятельности) и задачами (заданиями). В настоящем учебном пособии описаны три фундаментальные модели жизненного цикла с присущими им недостатками (аргументами против их применения) и преимуществами (выгодами). Эти недостатки и преимущества должны быть учтены при выборе модели жизненного цикла для проекта. Каскадная модель жизненного цикла по существу реализует принцип однократного выполнения каждого из следующих видов деятельности в их естественных границах: Установление потребностей пользователя Определение требований Проектирование системы Изготовление системы Испытание Корректировка Поставка или использование 3 -
  20. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Инкрементная модель жизненного цикла, называемая также запланированным усовершенствованием продукта, начинается с выдачи набора требований и реализует разработку последовательности конструкций. Первая конструкция содержит часть требований, в последующую конструкцию добавляют дополнительные требования и так далее до тех пор, пока не будет закончено создание системы. Для каждой конструкции выполняют необходимые процессы, работы и задачи. Например, анализ требований и создание архитектуры могут быть выполнены сразу, в то время как разработку технического проекта программного средства, его программирование и тестирование, сборку программных средств и их квалификационные испытания выполняют при создании каждой из последующих конструкций. В данной модели при разработке каждой конструкции работы и задачи процесса разработки выполняют последовательно или частично параллельно с перекрытием. При частично одновременной разработке последовательных конструкций работы и задачи процесса разработки могут быть выполнены параллельно для ряда конструкций. Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки. Преимущества инкрементной модели : Однократное представление всех возможностей (характеристик) системы Необходимость только единственной фазы перехода от старой системы к новой Необходимость изначального использования характеристик системы Пригодность для использования промежуточного продукта Естественное разделение системы на наращиваемые компоненты (инкременты) 3 -
  21. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» В эволюционной модели жизненного цикла систему также разрабатывают в виде отдельных конструкций, но в отличие от инкрементной модели требования изначально не могут быть полностью осознаны и установлены. В данной модели требования устанавливают частично и уточняют в каждой последующей конструкции . При таком методе для каждой конструкции работы и задачи процесса разработки выполняют последовательно или параллельно с частичным перекрытием. Работы и задачи процесса разработки обычно выполняют многократно в той же последовательности для всех конструкций. Процессы сопровождения и эксплуатации могут быть реализованы параллельно с процессом разработки. Процессы заказа и поставки, а также вспомогательные и организационные процессы обычно выполняют параллельно с процессом разработки. Данной модели присущи следующие недостатки, которые необходимо учитывать при оценке возможности ее применения: Все возможности системы предопределены изначально Ограниченные возможности долговременного привлечения ресурсов (средств или персонала) Преимущества использования данной модели: Изначальное определение возможностей системы Пригодность для использования промежуточного продукта Естественное разделение системы на наращиваемые компоненты (инкременты) Привлечение персонала и средств по мере необходимости Необходимая обратная связь с пользователем для полного понимания требований Упрощение надзора за изменением технологии 3 -
  22. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Основные технологические процессы – целенаправленная, логически выстроенная совокупность функций, направленных на последовательную смену состояний продукта во времени и классифицированных специальным образом. Вспомогательные процессы – совокупность процессов направленных на поддержание основных процессов. Для заметок : __________________________________________________________________________ __________________________________________________________________________ _________________________________________________________________________________________________________________________________________________ _______________________________________________________________________________________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ _________________________________________________________________________________________________________________________________________________ _______________________________________________________________________________________________________________________________________________________ _________________________________________________________________________________________________________________________________________________ ___ 3 -
  23. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок : ______________________________________________________________________ ____ _______________________________________________________________________ ___ _______________________________________________________________________ ___ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _______________________________________________________________________ ___ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _________________________________________ _____ ____________________________ _________________________________________ _____ ____________________________ _____________________________________________________________________ _____ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _________________________________________ _____ ____________________________ _________________________________________ _____ ____________________________ _____________________________________________________________________ _____ 3 -
  24. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок : ______________________________________________________________________ ____ _______________________________________________________________________ ___ _______________________________________________________________________ ___ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _______________________________________________________________________ ___ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _______________________________________________________________________ ___ ______________________________________________________________________ ____ _______________________________________________________________________ ___ _______________________________________________________________________ ___ ______________________________________________________________________ ____ _______________________________________________________________________ ___ ______________________________________________________________________ ____ 3 -
  25. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Кривая распределения вероятности для трех проектов Поскольку предметная область проекта А определена наилучшим образом, вероятность проведения реалистичного стоимостного анализа для этого проекта высокая. Для проектов В и С эта вероятность намного ниже, так как проекты имеют существенный уровень неопределенности. Тип контракта и риски Каждому из описанных типов контрактов присущ различный уровень риска и неопределенности. Схема на слайде характеризует зависимость распределения риска от типа контракта. Другими словами, выбор механизма осуществления платежей зависит от степени неопределенности проекта и уровня его риска. Таким образом, существенной разницей между всеми типами контрактов является способ реагирования на риски проекта и их оплата, осуществляемая либо по плановой цене, либо по фактической стоимости. В контрактах, основанных на цене (фиксированная цена, цена за единицу), осуществляемые платежи покрывают все затраты, издержки и прибыль. При этом подрядчик включает в цену контракта все дополнительные расходы, связанные с возникновением в проекте рисковых событий. В контрактах, основанных на стоимости, осуществляется возмещение фактической стоимости выполнения работ плюс дополнительное вознаграждение, выплачиваемое в качестве прибыли подрядчика. Фактически в контрактах подобного типа все риски проекта оплачивает заказчик. Заказчику необходимо отслеживать прогресс проекта и детально фиксировать все его расходы, которые часто являются предметом споров и разногласий между заказчиком и подрядчиком проекта. Итак, пропорция распределения риска между сторонами проекта зависит от наличия возможности у подрядчика или заказчика эффективно планировать и управлять ходом выполнения работ и вносить изменения в план проекта. Выбор типа контракта также зависит от уровня неопределенности проекта. Чем ниже неопределенность проекта, тем выше вероятность проведения качественного стоимостного анализа, результаты которого влияют на выбор типа контракта.
  26. 1 - Типы контрактов Существует несколько типов контрактов. Тип применяемого контракта определяется степенью неопределенности проекта. На стадии заключения контракта заказчик стремится максимально переложить риск проекта на подрядчика с целью достижения более экономичного и эффективного выполнения работ проекта. В интересах подрядчика же минимизировать риск проекта с целью увеличения размера потенциальной прибыли. В зависимости от типа, набор обязательных атрибутов контракта может меняться. Однако для контрактов, в соответствии с которыми осуществляется реализация проекта, выделяют два обязательных условия заключения: юридическая грамотность документа и условия осуществления платежей. В основе классификации контрактов лежит механизм осуществления платежей. Порядок выплат во многом зависит от того, насколько определены работы проекта и степени их детализации. Если существует возможность полного описания работ проекта, определения их стоимости, расписания и исполнения без перерывов и задержек, то приемлемым будет использование контракта с фиксированной ценой. В случае высокой неопределенности, не позволяющей точно составить расписание проекта и повышающей общий уровень рисков, чаще всего применяются контракты «цена плюс», подразумевающие возмещение превышения стоимости. В соответствии с PMI категории контрактов подразделяются на типы (на слайде). Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  27. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 -
  28. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Целеполагание уточняется в ходе выполнения группы процессов по управлению предметной областью проекта В эту группу входят процессы, необходимые для того, чтобы убедиться, что в проект включены все и только требующиеся для достижения целей проекта работы.  Это определение и контроль того, что включено и что не включено в проект, а именно: Отличительные черты и функции продукта или услуги проекта Работы, которые необходимо выполнить для получения продукта с требуемыми отличительными чертами и функциями Условия, которые необходимо соблюдать при выполнении работ проекта Процессы управления предметной областью включают: Планирование предметной области – определение методологии, ответственных лиц, типовых шаблонов, инструментов и методов, используемых в рамках проекта для управления предметной областью. Определение предметной области – определение работ проекта (требований к цели, к организации работ, общих требований к проекту, определение заинтересованных лиц). Разработку WBS – детализацию и структурирование работ проекта для упрощения контроля работ, оценки и распределения ответственности. Для заметок : _______________ _________ __________________________________________________ _______________ _________ __________________________________________________ _______________ _________ __________________________________________________
  29. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Определив основные, существенно влияющие на сроки и стоимость проекта требования, менеджер может уточнять подробности в процессе выполнения проекта . На этапе инициации может не потребоваться детального описания всех параметров результата. Следует отметить, что требования могут предъявляться не только к результатам проекта, но и к самому процессу выполнения работ. Сюда могут входить: Требования к соблюдению стандартов качества ( ISO и т.п.), экологических, санитарных норм Требования к персоналу (квалификация, опыт), оборудованию, инструментам и материалам Конечные сроки и стоимость работ Анализ проекта (продукта) включает в себя такие методы, как: ИСР, системный анализ, системный инжиниринг, анализ стоимости и функциональный анализ. Анализ продукта – один из важнейших элементов процесса определения предметной области, направленный на преобразования пожеланий заказчика в измеримые результаты. Требования к проекту могут быть описаны как с точки зрения потребностей – «что нужно», так и с точки зрения исключений – «чего не нужно». Это позволит исключить из проекта часть требований, которые может предъявить заказчик (например, по опыту аналогичных проектов). Определяя требования к результатам проекта, менеджер должен изучить, какие еще стороны могут повлиять на них и учесть их замечания. Для заметок : _____________ _________ ____________________ __ ______________________________ _______________ _________ ___________________________________________ __ _____ _______________ _________ ___________________________________________ __ _____ _______________ _________ ___________________________________________ __ _____
  30. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Что такое иерархическая структура работ? ИСР обеспечивает выявление работ, необходимых для достижения целей проекта. При таком подходе проект определяется как совокупность иерархически взаимосвязанных, ориентированных на результат элементов (работ). Разбиение проекта на более мелкие составляющие необходимо для: Повышения точности оценок затрат, сроков и потребности в ресурсах Определения и фиксации исходного плана для организации контроля выполнения Упрощения распределения ответственности Получения прозрачной и контролируемой отчетности Максимальной эффективности можно добиться, привлекая к этому процессу других членов команды и используя так называемый метод «мозгового штурма». Различные уровни иерархической структуры работ содержат работы различного уровня детализации.  Для структуризации используются различные системы кодов.
  31. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» При построении WBS менеджеру следует решить, насколько детально и подробно структурировать работы: какие из них разделять на максимальное число простых работ, а какие оставить на укрупненном уровне детализации . Зачастую менеджер принимает решение о прекращении дальнейшей детализации, основываясь на собственном опыте. Существуют критерии, на которые следует обратить внимание при принятии решения о дальнейшей детализации работ: Возможность оценки параметров работы  Если длительность, стоимость или другие важные параметры работы с трудом поддаются оценке, стоит разделить работу на составляющие, каждую из которых оценить отдельно .  Вероятно, какой-либо параметр работы не удается точно оценить в силу неопределенности. В этом случае можно попробовать выделить ту часть работы, которую можно оценить, и ту, которая является неопределенной. Возможность контроля выполнения работы  Если работа имеет несколько промежуточных результатов, не нужно усложнять ее контроль, а следует разделить ее на этапы, каждый из которых приводит к определенному результату.  Возможно, работа состоит из нескольких одновременно выполняемых процессов или функций, контролируемых различным образом. В этом случае ее также следует разделить на составляющие .  Если работа слишком длительна, то следует разделить ее на этапы и попытаться найти промежуточные результаты для более точного контроля работы. Возможность назначения ответственных  Если за работу отвечает не один человек, а несколько, то, как показывает практика, она может вообще не выполняться.  В случае возникновения так называемой «множественной ответственности» необходимо разделить работу на составляющие, разграничив круг ответственности каждого из участников.
  32. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Выделяя промежуточные результаты в ходе проекта, менеджер может анализировать отклонения от промежуточных контрольных точек, а не отклонение от конечной цели. Это позволит более точно и регулярно оценивать состояние работ и своевременно проводить корректирующие мероприятия. Для заметок _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________
  33. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Оценка длительности работ – процесс анализа информации о работах проекта и определения их продолжительности, который может производиться на основании существующих нормативов. Правильность оценки длительности работы во многом зависит от точности и полноты исходных данных. Результатом является длительность, выраженная либо в рабочих, либо в календарных периодах. Экспертные оценки – оценки длительности выполнения работ, разрабатываемые экспертами.  Отсутствие возможности получить экспертные оценки увеличивает неопределенность и риски проекта. Однако эксперты зачастую не знают всех особенностей проекта и используемых ресурсов, поэтому экспертная оценка потребует корректировки. Оценки по аналогам – оценки, использующие фактические значения длительностей аналогичных работ в предыдущих проектах.  Метод часто используется для оценки длительности проекта при недостатке информации о его специфических особенностях. Оценки по аналогам достаточно надежны, если: Работы-аналоги сходны с рассматриваемыми по сути, а не только по внешним атрибутам Люди, проводящие оценку, обладают необходимым опытом Параметрическая оценка – оценка длительности, получаемая на базе объема выполняемых работ и производительности назначенных ресурсов  Н апример, определенное количество квадратных метров стен, которые необходимо покрасить, делится на производительность маляра, и получается количество часов, необходимое для покраски.
  34. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Подходы для вычисления трудозатрат: определение трудоемкости на основе анализа трудоемкости известного образца (для небольших проектов, в которых трудно выделить отдельные этапы). вычисление трудоемкости на основе экспертных оценок (в тех случаях, когда сведений об аналоге проектируемого изделия нет или когда содержание проекта носит комплексный характер, например при разработке программно-технического комплекса). Затраты труда на внедрение нового решения зависят от времени на осуществление опытной эксплуатации, которое согласовывается с заказчиком и обычно составляет один ме­сяц, или 22 чел.-дня. При 8-часовом рабочем дне этап внедре­ния может потребовать 176 чел.-ч.. Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  35. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  36. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  37. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для вычисления объема трудозатрат всех составляющих, их следует соотнести с объемом трудозатрат, необходимых непосредственно для разработки нового изделия (этапа), например написания текста программы. Сначала следует определить трудозатраты на алгоритмизацию задачи. Это можно определить, используя коэффициент затрат на алгоритмизацию па, равный отношению трудоем­кости разработки алгоритма к трудоемкости его реализации при разработке изделия (программирование). Значение коэффициента па лежит в интервале от 0,1 до 0,5. Обычно его выбирают равным 0,3. Коэффициент затрат на проведение тестирования отражает отношение затрат труда на тестирование программы к затратам труда на ее разработку и может достигать значения 50%. Обычно его выбирают на уровне 0,3. Коэффициент коррекции программы при ее разработке отражает увеличение объема работ при внесении изменений в алгоритм или непосредственно в изделие (в текст программы) по результатам уточнения постановки и описания задачи, из­менения состава и структуры входной и выводимой инфор­мации, а также в процессе улучшения качества изделия без изменения ее алгоритмов. На практике, например при разработке программы, в происходит переработка 5—40% программы. Коэффициент коррекции программы выбирают на уровне 0,3. Коэффициент затрат на написание документации отражает отношение затрат труда на создание сопроводительной документации к затратам труда на разработку изделия. Его значение может достигать 0,75. Для небольших программ коэффициент затрат на написание сопро­водительной документации может составить 0,35. Зная экспертные значения трудозатрат на выполнение соответствующего этапа, можно определить затраты труда на проектирование основного содержания нового продукта.
  38. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  39. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для заметок: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  40. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Оценка длительности может также проводиться по трем точкам. Если получить точную детерминированную оценку длительности не удается, то производится оценка по трем точкам. Оценивается наиболее вероятная длительность работы ( ), а также наименьшая и наибольшая длительности. Вторые две оценки называют оптимистической (О) и пессимистической (П) . Анализ резервов - дополнительный интервал времени, называемый резервом или буфером , который может быть добавлен к длительности работы или к длительности проекта в целом для минимизации рисков при составлении расписания. Резерв может быть вычислен как определенный процент от длительности или как фиксированный интервал времени. В дальнейшем, по ходу получения дополнительных сведений о работе, он может быть уменьшен или аннулирован. Допущенный резерв должен быть оговорен в документации по работе. Факторы, влияющие на длительность работ Менеджеру следует внести корректировки в длительности, полученные в результате экспертной, параметрической или оценки по аналогам.  Эти методы основываются на опыте предыдущих проектов и не учитывают особенности планируемого проекта, в частности, специфику его ресурсов. Болезни персонала, поломка и обслуживание техники, обучение.  Подобные факторы могут быть предсказаны статистически или же являться результатом наступления рисков. Неполный рабочий день.  Если заранее известно, что работа будет проводиться лишь часть стандартного рабочего дня, длительность работы, соответственно, увеличивается. Взаимовлияние ресурсов может быть связано с физическими помехами (несколько кранов на стройке мешают друг другу), с невозможностью согласованной работы (люди не успевают обмениваться информацией, делают общую работу по-разному и т.п.), а также с конфликтами в коллективе.
  41. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 -
  42. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Методология и практика тестирования ПО Вопросы тестирования следует рассматривать в контексте всего жизненного цикла ПО, начиная от разработки ТЗ и заканчивая сопровождением приложений. Как известно, тестирование – это процедура обнаружения дефектов (ошибок) ПО до его промышленного использования. Очевидно, что трудоемкость такой работы связана с количеством самих ошибок, в связи с чем надо четко выделить основные причины их появления: неудовлетворительное организационное, методическое и техническое обеспечение всего процесса разработки сжатые сроки исполнения проекта сложность проекта, большое число требований и их изменений по ходу работы недостаточная квалификация разработчиков Тестирование является лишь составляющей частью отладки – процесса доводки ПО после его написания до эксплуатационного состояния. Процесс этот включает две основные процедуры: обнаружение ошибок (тестирование) и поиск и устранение их причин. Однако, даже учитывая все возможные взаимосвязи этих работ, нужно подчеркнуть, что тестирование является достаточно автономным, независимым этапом жизненного цикла ПО. При этом стоит подчеркнуть, что повышение качества разработки (которое обратно пропорционально количеству ошибок в приложении) напрямую снижает затраты на устранение ошибок, но на объем тестирования влияет совсем не так сильно: его нужно проводить в любом случае и желательно "по полной программе". Понятно также, что организация и методика тестирования в значительной степени зависят от целевого назначения разработки: коробочный продукт, заказной проект или внутрифирменный. И тут стоит еще раз обратить внимание на то, что прошедшие семинары были адресованы в первую очередь разработчикам ИТ-подразделений заказчиков. Объяснение этому простое: во-первых, объем разработок, выполняемых в таких компаниях и в специализированных ИТ-фирмах по крайней мере соизмерим; во-вторых, в силу ряда причин задачи тестирования при выполнении внутрифирменных проектов достаточно специфичны и очень актуальны. Говоря об особенностях процедур тестирования в ИТ-подразделениях, наверное, надо выделить три основных, весьма противоречивых аспекта. Проведение качественного тестирования требует наличия специалистов и инструментов соответствующего профиля. ИТ-подразделениям держать собственные группы тестировщиков просто невыгодно.
  43. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Основные понятия дисциплины «Тестирование» RUP : Объективная оценка – оценка ПО на основе определенных критериев (воспринимаемое качество, соответствие стандартам, выявление дефектов и т.п.). Сводная оценка результатов тестирования – объективная оценка выпуска с точки зрения согласованной миссии. План тестирования – определяет миссию и конкретные цели тестирования для каждой итерации. Список идей тестов – неформальный список, создаваемый в ходе обдумывания различных ситуаций, которое может показать необходимость создания тестов. Комплект тестов – группа, взаимосвязанных тестов, которые, будучи выполненные вместе, дают оценку общей деятельности проблемы. Тестовые сценарии – пошаговые инструкции по выполнению теста. Прецеденты тестирования – связывают тестовую задачу с тестируемой процедурой. Дефект – запрос на изменение, вызывающий внесение исправлений в последующем выпуске или итерации. Модель рабочей нагрузки – модель, характеризующая типичные и исключительные нагрузочные условия, которые должна выдерживать система. Тестовый цикл – период выполнения тестовой задачи и оценка результатов тестов. Дополнительные обязанности специалиста по тестированию: составление плана обеспечения качества участие в рецензировании требований и проектной модели участие в работе группы контроля за изменениями в целях проведения обзора дефектов и решения дальнейшей их судьбы 3 -
  44. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Для преодоления перечисленных проблем была предложена итеративная модель . Она предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально. С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental) . Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта). Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователь (заказчик) получает только результат финальной итерации как полную версию системы. С другой стороны, итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Разные идеологи вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада. Поскольку в идеале на каждом шаге мы имеем работающую систему, итеративная модель имеет следующие преимущества: можно очень рано начать тестирование пользователями можно принять стратегию разработки в соответствии с бюджетом, полностью защищающую от перерасхода времени или средств (в частности, за счет сокращения второстепенной функциональности)  Таким образом, значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. В свою очередь, снижение неопределенности позволяет уменьшить риски.
  45. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Оценка эффективности процесса 1. Обобщенная оценка эффективности процесса СМК за рассматриваемый период осуществляется на основе показателя, характеризующего его т. н. коэффициентом полезного действия, рассчитываемого по формуле: З ПР к – затраты на полезные работы в рамках К -ого процесса, руб. З ВР к – затраты на вспомогательные (операции) работы в рамках К -ого процесса, руб. З НР к – затраты на ненужные работы в рамках К -ого процесса , руб. З НО к – затраты (издержки), обусловленные несоответствиями процесса, руб. Эффективность отдельных операций (видов работ), осуществляемых в рамках анализируемого процесса, оценивается аналогично. 2. По итогам оценки эффективности анализируемых процессов определяются процессы СМК, требующие улучшения, и составляется их перечень. Для заметок: __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________
  46. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 -
  47. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Роли в проектной команде Один из наиболее известных подходов к распределению ролей в проектной команде был предложен доктором Белбином (Великобритания). В соответствии с его методикой, в каждой команде, которая стремится быть эффективной в своей работе, должны выполняться восемь ролей вне зависимости от численности команды. Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  48. Обзор методологии MSF
  49. Обзор методологии MSF
  50. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Первый шаг в процессе подбора персонала – определение стратегий развития проекта и человеческих ресурсов в рамках этой стратегии. Соответствие ценностей и взглядов сотрудника ценностям компании и команды – очень важно. Учет этих факторов на этапе планирования команды:  позволяет предотвратить конфликты; помогает мотивировать сотрудников. Последовательность 1. Работа, которую предстоит выполнять сотруднику. 2. Специфика стиля руководства и внутрифирменных взаимодействий. Специфика команды (совместимость людей), личность руководителя. Правила составления: Каждая компетенция формулируется предельно конкретно. В профиле должны быть четко расставлены приоритеты. Каждая компетенция в профиле должна иметь свой «измеритель». Для заметок : __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________
  51. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» На этапе набора команды проекта возможна разработка документа – матрица навыков членов команды. Исходными данными для подбора персонала являются: план управления обеспечением проекта персоналом; организационная структура с распределением ролей и ответственности; активы организационного процесса - существующие в организации правила и процедуры подбора персонала, описание возможностей сотрудников, включающее предыдущий опыт работы, личные интересы, личностные характеристики, доступность в требуемое проектом время. В качестве методов и средств подбора персонала проекта используются: предварительные назначения; переговоры руководителя проекта с функциональными менеджерами и руководителями других проектов по согласованию выделения и назначения сотрудников для работы в данном проекте; Это делается, например, когда проект является результатом победы в конкурсе, и участие определенных сотрудников было заранее оговорено в конкурсном предложении. привлечение персонала со стороны, в случае, если внутри организации отсутствуют специалисты с необходимыми знаниями и навыками. Результатами этапа подбора персонала являются: назначение персонала проекта на работу в нем (на основе полной или частичной занятости); список персонала проекта, включающий всех членов проектной команды и основных лиц, заинтересованных в результатах проекта. Список может быть формальным или неформальным, подробным или не очень в зависимости от обстоятельств, существующих в проекте.
  52. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Проектные стратегии и компетентности менеджера проектов: комплексное управление проектами (продолжение) В комплексном управлении проектами подобную декомпозицию использовать нельзя, поскольку невозможно установить содержание проектов: даже если в целом его можно определить, любая декомпозиция будет недействительной из-за постоянно происходящих изменений. Вместо декомпозиции на базовые элементы и последующего восстановления с помощью поэтапной интеграции в комплексном управлении проектами используется подход системного мышления, в котором множество представлений составляют целостную картину проекта. Комплексное управление проектами использует традиционное УП для реализации краткосрочных проектов, содержание которых характеризуется определенностью. Для проектов с неопределенным содержанием используются волновое планирование и Governance Contracting , а также методика накопления знаний с «двойным циклом обучения» для периодического обновления структуры проекта. ( Governance Contracting — специальная технология контрактинга, разработанная доктором Дэвидом Добкинсом в 1989-2002 гг.). Цепочка компетентностей комплексного управления проектами была создана на основе архетипов как традиционного, так и комплексного управления проектами. С одной стороны цепочки находится простейшая форма традиционного управления проектами: компетентности ограничены девятью функциональными областями. С другой стороны цепочки находится комплексное управление проектами с его девятью представлениями и парадигмой неопределенности. При продвижении вдоль цепочки компетентностей от традиционного управления проектами к комплексному список компетентностей растет: комплексное управление проектами включает все компетентности традиционного (рисунок на слайде). Между традиционным и комплексным управлением проектами находится переходная область, где пересекаются и накладываются друг на друга две философии. В этой точке становятся очевидными различия между дисциплинами. Тема №9 Особенности организации и управления крупными ИТ проектами 9 -
  53. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» Ирвин Джанис пришел к выводу, что когда проектная команда становится слишком сплоченной и имеет общие ожидания и нормы, в процессе принятия решений возникают семь изъянов: Малое количество вариантов Соображения команды ограничиваются малым количеством вариантов, возможности за пределами этого ряда отвергаются с ходу и совсем не рассматриваются. «Зацикливание» Первоначальные цели, которые должны были быть достигнуты в результате определенных действий, не пересматриваются и не оспариваются. Непринятие новых рисков Вновь обнаруженные риски не принимаются во внимание, чтобы поставить под сомнение изначально выбранный курс действий. Отвергание новых действий Действия, отвергнутые проектной командой с самого начала, не рассматриваются вновь в свете новой информации. Отказ от внешней экспертизы Не привлекаются опыт и знания внешних экспертов. Предвзятость собственной позиции Когда обнаруживается новая информация, команда проекта отдает предпочтения тем сведениям, которые поддерживают ее первоначальные гипотезы, и игнорирует противоречащую им информацию. Отвергание активов организационного процесса Команда не думает о том, как бюрократическая инерция или сопротивление организации могут помешать воплощению в жизнь выбранной командой линии ведения проекта.
  54. ДСУП ОАО «ЛАНИТ - Консалтинг», 2008 1 - «Особенности управления IT проектами» 1 - Какие организации устанавливают стандарты в области управления проектами? (выберите все правильные ответы) PMBOK IPMA PMO PMA Проекты могут быть: (выберите все правильные ответы) Социальные Экономические Организационные Другие В отношении истории развития управления проектами за рубежом можно отметить, что: (выберите все правильные ответы) Как самостоятельная дисциплина управление проектами развивается с глубокой древности Программа "Поларис" (US Navy) была одной из первых, где была опробована система сетевого планирования Управление риском всегда было самостоятельной дисциплиной в сфере управления проектами