План

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

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

1.Робоче планування

Елементарна робота, як правило, являє собою окрему функціональну вимогу до програмного продукту чи запит на зміну, над яким послідовно працюють:

–бізнес-аналітик; –проектувальник; –розробник; –тестувальник; –документаліст;

Трудомісткість елементарної роботи кожного з виконавців повинна бути від 4 до 20 люд. * рік.

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

–документування.

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

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

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

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

2.Принципи кількісного управління

Для кожного планового значення повинні бути визначені три області критичності відхилень:

• Допустимі відхилення. Передбачається, що ніяких керуючих впливів не потрібно.

• Критичні відхилення. Потрібен ретельний аналіз причин відхилення і при необхідності застосування коригувальних дій.

• Неприпустимі відхилення. Потрібно терміновий аналіз причин відхилення та обов’язкове застосування коригувальних дій.

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

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

Суть методу оцінки проекту по освоєному обсягом полягає в наступному. Спочатку оцінюється відхилення від графіка SV (Shedule Variance) в грошових одиницях:

SV = EV – PV, де EV (Earned Value) – освоєний обсяг. PV (Planned Value) – плановий обсяг.

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

CV = EV – AC, деEV (Earned Value) – освоєний обсяг.AC(Actual Cost) – фактичні витрати.

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

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

Відхилення від бюджету і за термінами в абсолютних грошових одиницях недостатньо для характеристики проектів різних масштабів. Наочніші відносні показники: індекс виконання термінів SPI (Schedule Performance Index)

SPI = EV / PVі індекс виконання вартості CPI (Cost Performance Index)

CPI = EV / AC,які характеризують проект незалежно від його розміру. Якщо значення обох індексів більше 1, то це свідчить про благополучний стан в проекті.

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

• показник прогресу проекту • стабільність проекту • середня продуктивність

Ще одна група кількісних показників, які слід спостерігати в ході реалізації проекту, характеризує якість програмного продукту:

- Дефектність продукту – кількість виявлених дефектів на одиницю об’єму продукту (наприклад, KSLOC).

- Частка не усунених дефектів – відношення кількості незакритих максимально критичних і критичних дефектів до кількості виявлених невідповідностей.

- Середні витрати на супровід – середні трудовитрати на виправлення одного дефекту. Високе значення цього показника може свідчити про неякісну архітектуру програмного продукту.

- Документованість коду – визначає відсоток рядків вихідного коду з коментару по відношенню до загальної кількості рядків.

Головна мета цієї фази - перевірити і передати замовникові результат проекту. Для цього необхідно виконати приймально-здавальні роботи у відповідності з процедурою приймання, яка має бути визначена заздалегідь на самій ранній стадії проекту.

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

3.Фаза завершення проекту

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

Підсумковий звіт повинен містити таку інформацію:

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

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

план мотивації учасників проектної команди.

Кінець