2. План
1. Робоче планування.
2. Принципи кількісного управління.
3. Завершення проекту.

3. Управління - це "розчленування”,
аналіз, визначення послідовності
дій, конкретна реалізація.
1.Робоче планування

4. Елементарна робота, як правило, являє
собою окрему функціональну вимогу
до програмного продукту чи запит на
зміну, над яким послідовно працюють:
–бізнес-аналітик;
–проектувальник;
–розробник;
–тестувальник;
–документаліст;
Трудомісткість елементарної роботи
кожного з виконавців повинна бути від 4
до 20 люд. * рік.

5. Для робочого планування доцільно
використовувати систему управління завданнями
або «баг трекінга» (“bugtracking” – система
відслідковування помилок), оскільки вона
дозволяє задавати послідовність переходів
завдання від виконавця до виконавця, керувати
пріоритетами робіт і адекватно відстежувати їх
статус:
–аналіз;
–проектування;
–кодування;
–тестування;
–документування.

6. В залежності від рівня
професіоналізму і зрілості команди
проекту розподіл робіт може
здійснюватися або директивно з
жорсткою постановкою терміну і
контролем виконання кожного
завдання, або ці повноваження
делегуються виконавцям.

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

8. Обговорюються, як правило, лише
три запитання:
• Загрози і проблеми ;
• Аналіз результатів за тиждень;
• Уточнення пріоритетів завдань на
новий тиждень.

9. На етапі тестування може бути виявлена ​​
помилка проектування і вся робота
почнеться заново. Рекомендація -
використовувати правило «50/100».
Якщо робота по завданню розпочата, то
слід враховувати її, як виконану на 50%.
А 100% повчає тільки протестована і
документована робота.

10. 2.Принципи кількісного управління
Для кожного планового значення повинні бути
визначені три області критичності відхилень:
• Допустимі відхилення. Передбачається, що
ніяких керуючих впливів не потрібно.
• Критичні відхилення. Потрібен ретельний
аналіз причин відхилення і при необхідності
застосування коригувальних дій.
• Неприпустимі відхилення. Потрібно
терміновий аналіз причин відхилення та
обов’язкове застосування коригувальних дій.

11. Вимірювання необхідно
проводити регулярно.
Мета – виявити причини
наступаючих або можливих
критичних і неприпустимих
відхилень.

12. Оскільки головне завдання менеджера
утримати проект в межах «залізного»
трикутника, то, в першу чергу, необхідно
аналізувати відхилення проекту по термінах
і витратам.

13. Суть методу оцінки проекту по освоєному
обсягом полягає в наступному. Спочатку
оцінюється відхилення від графіка SV (Shedule
Variance) в грошових одиницях:
SV = EV – PV, де
EV (Earned Value) – освоєний обсяг.
PV (Planned Value) – плановий обсяг.

14. Якщо ми випереджаємо графік, то це не
обов’язково означає що проект йде
успішно. Добре це чи погано залежить від
значення іншого показника методу
освоєного обсягу: CV (Cost Variance) –
відхилення за витратами, яке оцінюється за
формулою:
CV = EV – AC, де
EV (Earned Value) – освоєний обсяг.
AC(Actual Cost) – фактичні витрати.

15. Від’ємне значення відхилення за витратами
означає, що ми перевищили бюджет, що, в
загальному випадку, не дуже добре. Але
якщо термін завершення проекту для нас має
вищий пріоритет, і наші прогнозовані витрати
по завершенню проекту не перевищують
планових з урахуванням управлінського
резерву (рисунок 1), то в цьому випадку
можна вважати, що проект виконується
успішно.

16. Рисунок 1 – Оцінка і прогноз показників за
методом освоєного обсягу

17. Відхилення від бюджету і за термінами в
абсолютних грошових одиницях недостатньо для
характеристики проектів різних масштабів.
Наочніші відносні показники: індекс виконання
термінів SPI (Schedule Performance Index)
SPI = EV / PV
і індекс виконання вартості CPI (Cost Performance
Index)
CPI = EV / AC,
які характеризують проект незалежно від його
розміру. Якщо значення обох індексів більше 1, то
це свідчить про благополучний стан в проекті.

18. В управлінні програмним проектом
доцільно застосовувати ще такі
вимірні показники:
• показник прогресу проекту
• стабільність проекту
• середня продуктивність

19. Ще одна група кількісних показників, які слід спостерігати в
ході реалізації проекту, характеризує якість програмного
продукту:
- Дефектність продукту – кількість виявлених дефектів на
одиницю об’єму продукту (наприклад, KSLOC).
- Частка не усунених дефектів – відношення кількості
незакритих максимально критичних і критичних дефектів
до кількості виявлених невідповідностей.
- Середні витрати на супровід – середні трудовитрати на
виправлення одного дефекту. Високе значення цього
показника може свідчити про неякісну архітектуру
програмного продукту.
- Документованість коду – визначає відсоток рядків
вихідного коду з коментару по відношенню до загальної
кількості рядків.

20. Головна мета цієї фази - перевірити і передати
замовникові результат проекту. Для цього
необхідно виконати приймально-здавальні
роботи у відповідності з процедурою приймання,
яка має бути визначена заздалегідь на самій
ранній стадії проекту.
Результати проекту повинні бути передані у
впровадження або супроводження, або
належним чином законсервовані для подальшого
використання. Не повинно залишатися
«завислих» робіт за проектом.
3.Фаза завершення проекту

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

22. Підсумковий звіт повинен містити таку
інформацію:
Підсумки проекту:
- Досягнення цілей проекту
- Додаткові корисні результати
- Фактичні терміни
- Фактичні витрати
- Обгрунтування відхилення від цілей
- Відхилення результатів від вимог

23. Уроки проекту:
- Проблеми проекту та способи їх вирішення
- Матеріали програмні компоненти для
подальшого використання
- Пропозиції щодо зміни технологій або
стандартів компанії
На фазі завершення бажано реалізувати і
план мотивації учасників проектної
команди.

24. Кінець