
- •Технологія програмування та створення програмних продуктів
- •(частина 2)
- •Візуальне моделювання на основі UML
- •MSF – Модель проектної групи (v. 3.1)
- •Анотація
- •1. Основи моделі проектної групи MSF
- •Основні принципи
- •Розподіл відповідальності при фіксації звітності
- •Наділення членів команди повноваженнями
- •Концентрація на бізнес-пріоритетах
- •Єдине бачення проекту
- •Прояв гнучкості і готовність до змін
- •Заохочення вільного спілкування
- •2. Ключові концепції
- •Команда соратників
- •Фокусування на потребах замовника
- •Націленість на кінцевий результат
- •Установка на відсутність дефектів
- •Прагнення до самовдосконалення
- •Зацікавлені команди працюють ефективно
- •3. Випробувані методики
- •Малі багатопрофільні проектні групи
- •Колективна робота
- •Загальна участь в проектуванні
- •4. Огляд моделі команди MSF
- •Задоволені замовники
- •Досягнення результату в рамках проектних обмежень
- •Створення продукту відповідно до специфікації
- •Схвалення випуску продукту лише після того, як всі дефекти виявлені і відлагоджені
- •Підвищення споживчої цінності продукту
- •Безпроблемне впровадження і супровід продукту
- •Ролеві кластери моделі проектної групи
- •I. Ролевий кластер "Управління продуктом"
- •Області компетенції
- •1. Планування продукту
- •2. Бізнес-віддача
- •3. Представлення інтересів замовника
- •4. Маркетинг
- •II. Ролевий кластер "Управління програмою"
- •Області компетенції
- •1. Управління проектом
- •2. Вироблення архітектури рішення
- •3. Контроль виробничого процесу
- •4. Адміністративні служби
- •III. Ролевий кластер "Розробка"
- •Області компетенції
- •1. Технологічне консультування
- •2. Проектування і здійснення реалізації
- •3. Розробка програмних рішень
- •4. Розробка інфраструктури
- •IV. Ролевий кластер "Тестування"
- •Області компетенцій
- •1. Планування тестів
- •2. Розробка тестів
- •3. Звітність про тести
- •V. Ролевий кластер "Задоволення споживача"_
- •Області компетенцій
- •1. Загальнодоступність
- •2. Інтернаціоналізація
- •3. Забезпечення технічної підтримки
- •4. Навчання користувачів
- •5. Зручність експлуатації (ергономіка)
- •6. Графічний дизайн
- •VI. Ролевий кластер "Управління випуском"
- •Області компетенції
- •1. Управління випуском
- •2. Інфраструктура
- •3. Супровід
- •4. Бізнес-процеси
- •Масштабування моделі проектної групи
- •Групи напрямів
- •Функціональні групи
- •Об'єднання ролей
- •Ескалація і підзвітність
- •Модель проектної групи немає організаційної структури
- •Зовнішня координація – на кому лежить відповідальність?
- •Висновок
- •MSF: Модель процесів
- •Анотація
- •Короткий огляд методології
- •Введення
- •Інші моделі процесів
- •Краще з двох світів
- •Базові принципи MSF
- •Єдине бачення проекту
- •Проявляйте гнучкість – будьте готові до змін
- •Концентруйтеся на бізнес - пріоритетах
- •Заохочуйте вільне спілкування
- •Ключові концепції моделі процесів MSF
- •Замовники
- •Зацікавлені сторони (учасники)
- •Що є рішення?
- •Створення базових версій
- •Рамки проекту
- •Управління компромісами
- •Трикутник компромісів
- •Матриця компромісів проекту
- •Характеристики моделі процесів MSF
- •Підхід, заснований на віхах
- •Характеристики підходу, заснованого на віхах
- •Головні і проміжні віхи
- •Віхи як точки синхронізації
- •Віхи як орієнтири виробничої відповідальності
- •Провідні ролі різних фаз
- •Аналіз пройдених віх
- •Ітеративний підхід
- •Характеристики ітеративного підходу
- •Випуск версій
- •Створення "живої" документації
- •Ранні базові версії, відкладені підсумкові версії
- •Щоденні білди
- •Управління конфігураціями проекту
- •Рекомендації для випуску версій рішення
- •Створюючи плани, передбачайте версіонування
- •Перш за все, поставляйте базову функціональність
- •Вибирайте пріоритети, враховуючи ризики
- •Здійснюйте часті ітерації розробки
- •Інституціюйте процедури контролю змін в проекті
- •Цілісний погляд на розробку і впровадження
- •Переваги інтегрованої моделі процесів
- •Зосередження на потребах підприємства
- •Покращена підтримка розробки веб-приложений
- •Покращена підтримка веб-сервісів
- •Поліпшення взаємодії з командою супроводу
- •Зауваження про використання інтегрованої моделі процесів
- •Тривалість фаз не однакова
- •Діяльність може виходити за межі однієї фази
- •Проекти, обмежені розробкою застосування або впровадженням інфраструктури
- •Фази і віхи моделі процесів MSF
- •Фаза вироблення концепції
- •Введення
- •Віха "Концепція затверджена"
- •Результати
- •Основні завдання проектної групи на фазі вироблення концепції
- •Проміжні віхи, що рекомендуються
- •Ядро проектної групи сформоване
- •Чорновий варіант концепції проекту складений
- •Фаза планування
- •Введення
- •Віха "Плани проекту затверджені"
- •Результати
- •Основні завдання проектної групи на фазі планування
- •Проміжні віхи, що рекомендуються
- •Верифікація технологій
- •Базова версія функціональної специфікації створена
- •Базова версія звідного плану проекту створена
- •Базова версія звідного календарного графіка проекту створена
- •Середовища розробки і тестування розгорнені
- •Фаза розробки
- •Введення
- •Віха "Розробка завершена"
- •Результати
- •Основні завдання проектної групи на фазі розробки
- •Проміжні віхи, що рекомендуються
- •Концепція підтверджена
- •Білд n завершений, білд n+1 завершений...
- •Фаза стабілізації
- •Введення
- •Віха "Готовність рішення затверджена"
- •Результати
- •Основні завдання проектної групи на фазі стабілізації
- •Проміжні віхи, що рекомендуються
- •Точка конвергенції
- •Точка досягнення нуля
- •Версії-кандидати
- •Контрольне тестування завершене
- •Тестування прийнятності для споживачів завершене
- •Пілотне впровадження завершене
- •Фаза впровадження
- •Введення
- •Віха "Впровадження завершене"
- •Результати
- •Основні завдання проектної групи на фазі впровадження
- •Проміжні віхи, що рекомендуються
- •Ключові компоненти розгорнені
- •Впровадження на місцях завершене
- •Упроваджене рішення стабілізоване
- •Методики моделі процесів MSF, що рекомендуються
- •Стимулювання винахідливості для розширення функціональності й обмеження ресурсів
- •Фіксування календарного графіка
- •Календарне планування на невизначене майбутнє
- •Використання паралельно працюючих компактних команд
- •Розбиття великих проектів на реальні частини
- •Отримання уроків з пройдених віх
- •Використання прототипіювання
- •Використання частих білдів і швидких тестів
- •Часті ітерації розробки і впровадження
- •Уникання розповзання рамок проекту
- •Оцінка з низу до верху
- •Інтеграція представлених проектною групою оцінок
- •Застосування A
- •Зміни в порівнянні з попередньою версією MSF
- •Висновок
- •Література
- •Анотація
- •Введення
- •Основні відомості про ризики
- •Базові принципи:
- •1. Гнучкість і постійна готовність до змін
- •2. Вільне спілкування
- •3. Отримання зі всього уроків
- •4. Розподіл відповідальності при фіксації звітності
- •Ключові концепції:
- •Найбільш ефективним є превентивне управління ризиками
- •2. Заохочення до виявлення ризиків
- •3. Постійна оцінка ризиків
- •4. Підтримка відкритого спілкування
- •5. Постійний аналіз ризиків
- •6. Кількість ризиків не характеризує реальне положення речей
- •Планування управління ризиками
- •Процес управління ризиками
- •Загальне уявлення
- •Етап 1. Виявлення ризиків
- •Введення
- •Початкові дані
- •Кроки по виявленню ризиків
- •Структурований підхід
- •Класифікація ризиків
- •Формулювання ризиків
- •Результати
- •Етап 1. Аналіз і пріоритезація ризиків
- •Введення
- •Мета
- •Початкові дані
- •Процес аналізу ризиків
- •Вірогідність ризику
- •Загроза ризику
- •Очікувана величина ризику
- •Додаткові кількісні методики
- •Результати
- •Головна таблиця ризиків
- •Інші методи проведення аналізу
- •Документ опису ризиків
- •Список головних ризиків
- •Деактивація ризиків
- •Планування ризиків_
- •Введення
- •Початкові дані
- •Заходи
- •Дослідження
- •Ухвалення
- •Уникнення
- •Перенесення
- •Запобігання
- •Пом'якшення наслідків (реагування)
- •Календарне планування
- •Результати
- •Діяльність по управлінню ризиками
- •Документування планів
- •Оновлення плану і календарного графіка проекту
- •Моніторинг ризиків_
- •Початкові дані
- •Заходи щодо моніторингу
- •Звітність про стан ризиків
- •Результати
- •Коректування ситуації_
- •Мета
- •Початкові дані
- •Дії з коректування ситуації
- •Результати
- •Витягання уроків з ризиків
- •Введення
- •Типи отримуваних уроків
- •Управління витяганням уроків
- •Контекстна класифікація ризиків
- •База знань про ризики
- •Досягнення зрілості в управлінні знаннями про ризики
- •Управління ризиками як складова частина життєвого циклу проекту_
- •Управління ризиками на підприємстві
- •Створення культури управління ризиками
- •Управління портфелем проектів_
- •Висновок
- •MSF: Дисципліна управління проектами
- •Анотація
- •Введення
- •Базові принципи MSF
- •Пр.1: Розподіл відповідальності при фіксації звітності
- •Пр.2: Наділення членів команди повноваженнями
- •Ключові концепції
- •1) Дисципліни MSF
- •2) Поняття управління проектом
- •3) Менеджмент проекту і менеджер проекту
- •4) Управління проектами і специфічні IT-процеси
- •Особливості управління проектами в MSF
- •Роль менеджера проекту покладається на кластер "Управління програмою"
- •Взаємодія "Управління програмою" з лідерами командних ролей
- •A. Функціональні групи
- •B. Групи напрямів
- •Масштабування функцій управління проектом
- •Обов'язки по управлінню проектами
- •Лідери груп
- •Кластер "Управління програмою"
- •Управління великими і складними проектами
- •Адміністративні служби проекту
- •Звітність перед замовником
- •Рекомендації проектним групам
- •Управління рамками проекту
- •Визначення рамок на етапі вироблення концепції
- •Рамки рішення і рамки проекту
- •Визначення рамок (scope definition)
- •Управління змінами рамок (scope change control)
- •Підготовка планів
- •Повторне використання документів
- •Плани проекту
- •Ієрархічна структура робіт
- •Відповідність між WBS, функц. специфікаціями і зведеним планом
- •Створення WBS
- •Рекомендації по декомпозиції роботи
- •Оцінка знизу вгору
- •Інтеграція представлених проектною групою оцінок
- •Формування реалістичних очікувань
- •Невизначеність і точність оцінок
- •Оцінюйте завдання нижнього рівня декомпозиції
- •Аналіз PERT
- •Рекомендації по складанню календарного графіка
- •1) Впорядкування завдань
- •2) Обмеження часу
- •3) Вибір пріоритетів, з врахуванням ризиків
- •Створення часових буферів
- •Висновок
- •MSF: Дисципліна "Управління підготовкою"
- •Анотація
- •Вступ
- •Базові принципи
- •Пр.1: Заохочення вільного спілкування
- •Пр.2: Інвестування в якість
- •Пр.2: Отримання уроків
- •Пр.3: Гнучкість та готовність до змін
- •Ключові концепції
- •1) Інвентаризація наявних знань
- •2) Прагнення до самовдосконалення
- •3) Підготовка повинна бути перманентним процесом
- •Випробувані методики
- •1) Планування підготовки
- •Оцінка і моніторинг професійного рівня і індивідуальних цілей
- •Відноситеся до пропусків в підготовці як до ризиків
- •Огляд процесу Управління підготовкою
- •1) Визначення:
- •2) Оцінювання:
- •3) Коригування:
- •4) Осмислення:
- •Превентивне Управління підготовкою
- •Підготовка впродовж життєвого циклу ІТ
- •Кроки процесу Управління підготовкою
- •Крок 1: Визначення
- •Скл. 1: Проектні сценарії
- •Скл. 2: Кваліфікаційні вимоги
- •Скл. 3: Професійні навики
- •Крок 2: Оцінювання
- •Оцінка знань, умінь, здібностей
- •Специфікація процесу оцінювання
- •Збір і обробка даних
- •Обробка результатів оцінювання
- •Аналіз невідповідностей
- •Створення планів навчання
- •Крок 3: Коригування
- •Навчання
- •Моніторинг прогресу
- •Крок 4: Осмислення
- •Аналіз результатів
- •Управління знаннями
- •Вимоги до професійних навиків проектних ролей
- •Створення планів підготовки
- •Висновок
належним чином впорядкувати проекти і передбачити своєчасне досягнення необхідного професійного рівня.
На фазі розробки (development phase) моделі EA-процесса IT-служба підприємства повинна забезпечити відповідність усіх проектних кроків бізнес-потребам підприємства. При цьому проектні групи повинні знаходитися на відповідному професійному рівні і мати можливість справитися з проектними завданнями і принести відчутну бізнес-віддачу.
Основна діяльність по управлінню підготовкою на фазі стабілізації (stabilizing phase) EA-процесса – забезпечення зворотного зв'язку. Окремі проекти дають можливість оцінити правильність припущень, зроблених на етапі планування архітектури підприємства, і побачити ефективність зроблених кроків. Виявлення цієї інформації і її використання в подальших циклах планування архітектури підприємства є основою установки на безперервне вдосконалення ("continuous improvement" mindset).
Необхідно завжди виділяти належний час на розвиток професійних навиків, що потрібні для роботи над проектами, і на аналіз отриманого досвіду. Навчання – це ітеративний процес. Тільки постійне самовдосконалення дозволяє організації отримати повну віддачу від впровадження процесу Управління підготовкою.
Кроки процесу Управління підготовкою
Крок 1: Визначення
Під час планування архітектури підприємства організація проводить узгодження своїх ITта бізнесцілей і формує єдине бачення (shared vision) свого майбутнього. Природно, частиною цього процесу є набуття знань і навиків, які потрібні співробітникам для здійснення проектів. Це 1-й крок процесу Управління підготовкою MSF. Він називається "Визначенням" і складається з виявлення і опису проектних сценаріїв, кваліфікаційних вимог до членів проектних груп і очікуваних від них професійних навиків, необхідних для успішного планування, створення і супроводу рішень. Залежно від посади, співробітникові можуть потрібно професійні навики, що задовольняють кваліфікаційним вимогам однієї або декількох груп.
Три складових, на яких фокусується етап "Визначення":
1.Проектні сценарії.
2.Кваліфікаційні вимоги.
3.Професійні навики.
Результати "Визначення" включають:
•Виявлені кваліфікаційні вимоги і бажані професійні навики.
•Відповідність кваліфікаційних вимог і професійних навиків майбутнім проектним сценаріям.
Скл. 1: Проектні сценарії
Термін "проектний сценарій" використовується для опису типових ситуацій, з якими стикаються EAабо ITпідрозділи, ініціюючи технологічні проекти. Сценарії розділяються на чотири категорії, що описуються нижче. Певною мірою вони співвідносяться з етапами розвитку, через які організація проходить в процесі розробки і супроводу продуктів і технологій.
•Перспективні проекти (High potential). До даної категорії відносяться ситуації, з якими стикається IT-підрозділ, плануючи впровадження, модернізацію і/або розробку якісно нового продукту, технології або послуги. Звичайно це дослідницькі проекти, що базуються на новітній технології, іноді доступній на момент початку проекту тільки в бета-версії.
142

•Стратегічні проекти (Strategic). Виникнення сценаріїв цієї категорії найймовірніше при використанні нових технологій, продуктів або послуг, що вже лідирують на ринку і здатних провести стратегічні зміни в бізнес - процесах підприємства, принципово змінивши його архітектуру.
•Критичні експлуатаційні сценарії (Key operational). Сценарії цієї категорії виникають при експлуатації нового продукту, технології або сервісу спільно з системами і програмним забезпеченням попередніх поколінь (legacy systems). Такі ситуації типові сьогодні для багатьох підприємств, часткова автоматизація життєво важливих (business-critical) бізнес - процесів яких була здійснена в минулому столітті.
•Сценарії супроводу (Support). Сценарії цієї категорії виникають в ситуаціях, коли необхідно розширити можливості вже існуючого продукту для задоволення вимог середовища замовника (customer’s environment). Звичайне таке розширення хоча і представляє цінність, але не є критичним для бізнесу (not business-critical). Ці ситуації часто приводять до необхідності інтеграції з рішеннями, заснованими на застарілих технологіях.
Рисунок 33. Категорії IT-сценаріїв, взаємозв'язані з типовими фазами, типами навчання і управління знаннями при розробці і супроводі продуктів і технологій
Систематизація IT-проектів в рамках архітектури підприємства за типом їх сценаріїв дає можливість планувати підготовку відповідно до унікальних особливостей кожного проекту. Різні сценарії вимагають різних підходів до отримання ресурсів і навиків, що потрібні для конкретного проекту. Визначаючи спочатку проектний сценарій, можна виявити відповідні йому кваліфікаційні вимоги і професійні навики. Диференціація типів сценаріїв допомагає вирішити, чи в проекті слід використовувати субпідрядників або консультантів чи ні.
Наприклад, реалізація проекту по розгортанню інфраструктури для ПП, що знаходиться у стадії бета - розробки, вимагає принципово іншого підходу до формування в команді необхідної сукупності навиків, ніж проект по інтеграції зрілої високотехнологічної системи з деяким застарілим (успадкованим з минулого), але критичним для підприємства ПЗ. Кадрове забезпечення "перспективного проекту" може вимагати залучення консультантів, спеціально навчених виробником нової технології, тоді як для інших проектів робота з підготовки включає навчання і сертифікацію постійних співробітників підприємства.
Нижче стисло підсумовуються існуючі категорії сценаріїв і підходи до формування в них необхідного рівня підготовки.
1) Перспективні проекти. Потрібний високий рівень "гнучкості" (agility), здатність досліджувати і оцінювати нові технології і можливість залучення на короткий термін фахівців високої кваліфікації.
143
2)Стратегічні проекти. Потрібна наявність постійного персоналу з глибоким досвідом в розробці архітектури рішень і розумінням шляхів ефективного використання широкого спектру технологій для потреб бізнесу.
3)Критичні експлуатаційні сценарії. Велике значення має якість технічних знань і процесів, так само як і наявність глибокого досвіду у використовуваних технологіях. Зазвичай кваліфікаційні потреби таких проектів покриваються за рахунок залучення субпідрядників або створенням могутнього професійного потенціалу всередині організації.
4)Сценарії супроводу. Витрати на отримання результату стають принциповими, і через це організація може вирішити використовувати зовнішніх фахівців (особливо для роботи із застарілими технологіями).
Після того, як всі проекти і їх сценарії специфіковані, виявляються існуючі кваліфікаційні вимоги і необхідні професійні навики.
Скл. 2: Кваліфікаційні вимоги
У контексті дисципліни Управління підготовкою MSF, відповідність кваліфікаційним вимогам означає наявність знань і умінь, необхідних для виконання певного IT-сценарію. Ці вимоги зазвичай описують набір завдань, з якими в даному сценарії повинні справитись фахівець, а також цілі, які він повинен бути здатний досягти.
Кваліфікаційні вимоги можуть розглядатися як сукупність очікуваних знань, умінь і продуктивності праці.
Знання. Інформація, якою повинен володіти індивідуум для кваліфікованого виконання роботи.
Уміння. Набір освоєних дій і прийомів, що визначають кваліфікацію.
Продуктивність праці. Міра очікуваної віддачі від застосування професійних знань і умінь індивідуума в рамках його робочої ролі.
Скл. 3: Професійні навики
Професійні навики – це міра здібностей до виконання певної роботи або до задоволення кваліфікаційним вимогам даного сценарію. Професійні навики відповідають завданням, які індивідуум здатний виконати на певному рівні.
Професійні навики визначаються в процесі оцінювання (іноді – само оцінювання) індивідуума, що дає відправну точку для аналізу відповідності кваліфікаційним вимогам даного сценарію.
Згідно дисципліні Управління підготовкою MSF, для створення плану навчання потрібно визначити поточний і бажаний рівні підготовки, які описуються з погляду заданого проектного сценарію і його кваліфікаційних вимог. При цьому може бути використана як самооцінка, так і атестаційне тестування. Як тільки виявлені і документовані наявна і бажана ситуації, існуючі прогалини в підготовці можуть вважатись визначеними. Після цього починається розробка плану навчання, який повинен допомогти досягти бажаного професійного рівня.
Наступна таблиця показує приклад шкали вимірювання професійних навиків, яка може використовуватися при проведенні оцінювання.
Оцінка |
Просте |
Опис |
|
навиків |
визначення |
||
|
|||
0 |
Кваліфікація |
– |
|
|
відсутня |
|
|
|
|
|
|
1 |
Знайомий(а) |
Знайомство: навики в зачатковому стані, обмежені знання. Відсутня |
|
|
|
здатність самостійної роботи в даній області. |
|
|
|
|
|
2 |
Середній рівень |
Робочі знання: хороше розуміння потрібних в даній області навиків, |
|
|
|
уміння застосувати їх з певною ефективністю. Здатність |
|
|
|
функціонувати в даній області достатньо самостійно, проте |
|
|
|
144 |