Планування версій і ітерацій
Планування у XP базується на наступних основних поняттях: продуктивність, пріоритети, вартість версії, складання плану версій, складання плану ітерацій.
Продуктивність або швидкодія команди базується на оцінках пунктів історії. Проте необхідно враховувати, що пункти представляють ідеальні оцінки, крім того істотну роль має досвід команди в оцінюванні (для команд початківців можлива значна похибка).
Ключову роль у призначенні пріоритетів грає, безумовно, замовник. Проте і розробник має право голосу при відборі історій, які повинні потрапити у версію (питання архітектури, ключової функціональності і т.п.)
Вартість версії визначається, базуючись на продуктивності, пріоритетах і термінах.
План версій дає замовникові початкове розуміння вартості проекту. Ця оцінка передбачає можливість відмови від проекту на початковій його стадії, якщо терміни і (чи) ціна є неприйнятними.
У разі, якщо план версій прийнятий, складається план ітерацій, що відбиває кроки (ітерації), які необхідно виконати, щоб досягти необхідної функціональності продукту.
Аналіз вимог і управління ризиками
Ризик у реалізації програмних проектів – це потенційна проблема, яка має суттєву вірогідність негативно вплинути на успішність проекту, наприклад, на своєчасну його здачу, задоволення бюджетних обмежень, якість продукту, ефективність роботи команди тощо.
Управління ризиком - комплекс заходів з виявлення, оцінки, запобігання і контролю ризиків проекту.
Як пише К.Вігерс [5], «Якщо щось погане вже сталося з вашим проектом, то це – проблема, а не ризик. Управління ризиком означає роботу з потенційною небезпекою до того, як вона перейде у кризову фазу». Менеджери проектів повинні виявляти ризик і управляти їм, починаючи з чинників, пов'язаних з вимогами, у співпраці з представниками замовника.
Стратегії і роботи з управління ризиком
Управління ризиком включає дії, показані на рис. 12.1. [5].
Рис. 12.1. Дії з управління ризиком
Роботи з оцінювання ризику (risk assessment) розпочинаються з визначення потенційних небезпек для проекту. У якості методики виявлення може бути рекомендована методика мозкового штурму. Гарною підмогою для цього етапу робіт є наявна у розробника класифікація ризиків.
Так, усі ризики прийнято поділяти на прямі (ті, на які розробник може так чи інакше впливати) і непрямі (незалежні від розробника)[6].
М. Фаулер [7] запропонував розділити усі ризики на чотири категорії:
ризики, пов'язані з вимогами;
технологічні ризики;
ризики, пов'язані з кваліфікацією персоналу;
політичні ризики.
Поширені чинники ризику, пов'язані з вимогами, включають невірне розуміння вимог, недостатнє залучення користувачів, неточності або зміни у масштабах і цілях проекту, нестабільні вимоги. Детальний аналіз цих видів ризиків можна знайти у [5], гл. 23.
Аналіз ризику зводиться до дослідження і опису потенційних наслідків конкретних чинників ризику для проекту, а також вірогідності їх прояву.
Визначення пріоритетів складається з пошуку відповідей на два питання: наскільки вірогідний прояв ризику в проекті; наскільки руйнівні можуть бути наслідки його прояву.
Виявлені ризики записують у спеціальний документ - risk list.
Існують три основні стратегії поведінки відносно ризиків:
Запобігання ризику, передача ризику, прийняття ризику.
Запобігання ризику (risk avoidance) - це процес реорганізації проекту так, щоб ризик не зміг на нього вплинути. Наприклад, відмовитися від провідних інструментів, що тільки-но з'явилися, на користь перевірених, не включати до плану ті функції, які вимагають вивчення нових технологій.
Передача ризику - перерозподіл робіт проекту таким чином, щоб хтось інший (замовник, партнер тощо) відповідав за роботу з ним.
Прийняття ризику зобов'язує розробника «піклуватися» про нього. Заходи з контролю ризику (risk control) передбачають планування, дозвіл і моніторинг.
Планування управління ризиком має на меті створення плану дій для кожного окремого чинника, включаючи методи пом'якшення, плани на випадок непередбачених обставин, відповідальних осіб і терміни виконання. Мета дій з пом'якшення дії ризику — або не дозволити ризику стати проблемою, або зменшити його шкідливу дію.
Деякі ризики можуть бути здолані у процесі роботи над проектом, вони видаляються зі переліку ризиків, інші - навпаки, виявлені в ході виконання проекту і додані до цього документа.
Моніторинг ризиків необхідний для спостереження за ризиками з risk list, відстеження їхнього просування аж до розв’язання, опрацювання їхніх пріоритетів тощо.
Література до теми:
Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению–М.: ИД "Вильямс", 2002
Кратчен Ф. Введение в Rational Unified Process
Астелс Дэвид, Миллер Гранвилл, Новак М.Практическое руководство по экстремальному программированию. Пер. с англ. - М.: ИД "Вильямс", 2002. - 320 с.
Бек К. Экстремальное программирование – СПб.: Питер, 2002. - 224 с
Вигерс К. Разработка требований к программному обеспечению. Пер, с англ. - М.:ИТД "Русская Редакция", 2004. -576с.
Л.Новиков. Введение в Rational Unified Process http://www.interface.ru/rational/interface/151199/rup/main.htm
Фаулер М, Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. Пер. с англ. - М.:Мир, 1999. – 191 с.