29. Наведіть схеми організації менеджменту проектів.

Поняття «менеджер проекту» не обов'язково співвідноситься з конкретною персоною, яка відповідає за управління виробництвом програмної системи в цілому. У невеликому проекті таке єдиноначальність найчастіше виправдано: воно дозволяє концентрувати всі нитки управління, виключає проблеми внутрішнього для проекту погодження суперечностей, забезпечує централізовану відповідальність за проект перед тими, хто зацікавлений у його виконанні. Однак у міру переходу до більш масштабних проектів менеджерські обов'язки стає неможливо концентрувати в одних руках. Зазвичай в таких випадках надходять відповідно до однієї з двох схем організації виробництва.

Перша схема - це утворення служби менеджера, що складається з його помічників, яким він може доручати різні завдання, звільняючи себе від рутини постійного контролю. Цей шлях, по суті, є лише паліативом.

Для ще більш складних проектів з'являється необхідність слідувати другою схемою, тобто утворювати групу менеджерів, відповідальних за різні розмежовані сфери проекту.

30. Функції, які виконуються розробниками програмного проекту.

Функції, які виконуються розробниками програмного проекту.

Розробник (Developer) - реалізує проектовані компоненти, розробляє специфічні класи і

методи, здійснює кодування і автономне тестування, створює програмний продукт. Це

широкий термін, який може підрозділятися на вужчі ролі (наприклад, розробник класів).

Залежно від складності проекту команда може включати різну кількість розробників;

31. Рольові кластери моделі проектної групи msf.

MSF засновано на постулаті про шість якісних цілей, досягнення яких визначає успішність проекту. Ці цілі зумовлюють модель проектної групи. У той час як за успіх проекту відповідальна вся команда, кожен з її рольових кластерів, що визначаються моделлю, асоційований з однією зі згаданих шести цілей і працює над її досягненням.

Шість рольових кластерів моделі проектної групи (рис. 11) - це "Управління продуктом" (product management), "Управління програмою" (program management), "Розробка" (development), "Тестування" (test), "Задоволення споживача" (user experience) і " Управління випуском "(release management). Вони відповідальні за різні області компетенції (functional areas) та пов'язані з ними цілі й завдання. Іноді рольові кластери називаються просто ролями. Але в будь-якому разі суть концепції залишається тією ж - побудувати основу виробничих відносин і пов'язану з нею модель команди такими, щоб вони були пристосованими (масштабованими) для задоволення потреб будь-якого проекту. Одна роль (або один кластер) може бути представлена однією або кількома співробітниками, в залежності від розміру проекту, його складності та професійних навичок, необхідних для реалізації всіх областей компетенції кластеру.

32. Принципи, які визначають регламент суміщення ролей.

33. Суміщення ролей.

В більшості випадків замовник і планувальник ресурсів є дійсно зовнішніми по

відношенню до проекту дійовими особами, а тому поєднання цих ролей з іншими - щось екзотичне. Змістовніше говорити про поєднання ролей в команді. В зв'язку з цим доречні рекомендації, засновані на досвіді успішного і невдалого менеджменту програмних проектів. Менеджер проекту по своєму призначенню є виділеним обличчям команди. Він концентрує в собі взаємодію із замовником і планувальником ресурсів, з одного боку, а з іншої - розподіляє роботи серед членів команди. Останнє означає, що він повинен мати повну інформацію про декомпозицію проекту. Як наслідок, поєднання його ролі з роллю архітектора проекту є дуже бажаним, а тому досить частим. Єдиною умовою для такого поєднання є вимога чітко знать, коли і чиї функції виконує ця дійова особа. Втім, це універсальна вимога для будь-якого поєднання ролей.

Цілком можливо продуктивне поєднання ролей керівника команди і архітектора - це дає відчутні результати, коли команда досить міцно пов'язана зі своїм керівником, наприклад, по попередніх роботах, але за умови не занадто високої складності завдань декомпозиції для цього проекту. Поєднання ролей керівника команди і менеджера допустимо, але лише тоді, коли усвідомлюється і враховується суперечність цільових установок цих ролей : керівник команди діє в умовах, які формуються менеджером. Вкрай небажане поєднання ролей керівника команди і проектувальника якої-небудь підсистеми. В цьому випадку у керівника можуть скластися переваги на користь "свого" компонента, і, як наслідок, можливий дисбаланс проекту в цілому на користь виділених його складових, який доведеться компенсувати додатковими зусиллями менеджера. З тих же причин не допускається поєднання ролей менеджера і розробника. Тут заборона жорсткіша, оскільки контрольні функції менеджера несумісні з виконавськими завданнями розробника. Навіть у тих випадках, коли у менеджера залишається вільний час після виконання своїх прямих обов'язків, йому не слід "допомагати" розробникам. Краще зайняти себе іншою справою, зокрема виступити в ролі розробника іншого проекту. В той же час, поєднання ролей різних розробників - звичайна справа для великих проектів. Воно є частиною розподілу робіт по виконавцях. Вирішують цю задачу спільно керівник команди і менеджер, коли основні архітектурні положення затверджені. Способи рішення залежать від того, як формується команда. Якщо розробка доручається готовій команді, то зростає роль керівника, а менеджер лише затверджує його пропозицію. Коли команда створюється для проекту, росте питома вага менеджерських функцій в підборі кадрів для робіт. Але у будь-якому випадку при поєднанні ролей різних розробників треба враховувати рівень кваліфікації працівників, їх переваги і інші індивідуальні особливості. Необхідно знати, що, виділяючи одній дійовій особі декілька робіт, слід прагнути до однорідності завдань, вказувати їх порівняльні пріоритети. Допустимі і інші поєднання ролей. Так, досить часто створення документації

розподіляється між усіма виконавцями проекту, а на керівника команди і менеджера покладається інтеграції документів. Для осяжних проектів функції бібліотекаря можна доручити одному з розробників, відповідно скоректувавши його індивідуальне завдання. Фахівцем з призначеного для користувача інтерфейсу цілком може бути, наприклад, менеджер, оскільки саме він здійснює контакти із замовником (у цій ситуації замовник або сам є користувачем, або виступає як представник користувача програмного виробу). Бажано, щоб ролі тестувальників доручалися незалежним фахівцям в предметній області, а не членам команди. Проте, і тут можливі варіанти поєднання. Зокрема, у багатьох випадках прийнятне так зване "перехресне" поєднання ролей розробників і тестувальників, коли розробники незалежних компонентів проекту тестують функціональність один одного.