63. Планування релізів.

Реліз – це варіант виробленого програмного виробу, надаваний для використання. План випуску релізів відображає вимоги до розробки в цілому в послідовність релізів,

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

Навіщо потрібний план випуску релізів? Найбільше суттєво в ньому те, що він розбиває всю сукупну роботу над проектом на групи, які реально піддаються керуванню.

Якщо не виділяти такі групи, то проект може зайти в глухий кут у зв'язку з лавиноподібним характером розвитку вимог. Наприклад, у ході аналізу прикладної

області на тому або іншому ітеративному витку може бути з'ясовано, що потрібні додаткові функції, яким у первісному плані не було приділене місце. Наявність

заздалегідь спланованих релізів може чітко вказати, до яких з них раціонально віднести ці функції. Випливає, однак, відзначити, що функції більш високих пріоритетів ( з погляду замовника) потрібно намагатися визначати до реалізації на більш ранні ітерації проекту. Таким чином, план релізів будуватися, виходячи із двох, можливо, суперечливих устремлінь:

· логіки поступального розвитку і

· важливості поступового надання засобів замовникові, якому план дає представлення про послідовність виконання вимог до продукту.

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

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

Із цього випливає, що план випуску релізів повинен складатися й затверджуватися якомога раніше. Фактично всі обов'язкові передпроектні роботи (складання документів

про концепції розвитку проекту й розподіл ресурсів, побудова план-графіка робіт) виходять із користувацької вистави процесу розробки як послідовності поставок — релізів

проектованого виробу. Зокрема, при складанні плану випуску релізів і його узгодженні з'ясовується, які розв'язки неприйнятні для компанії, для замовника. Якщо проблеми

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

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

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

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

3. Перерозподіл робіт – прискорення робіт за рахунок залучення до проекту

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

64. Управління ризиками.

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

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

Зокрема, результатом такого аналізу може стати відмова від проекту. З іншого боку, ризик невиконання проекту є однією із причин, через які замовлення на розробку може бути не отриманий. Причини можливого зриву робіт досить різноманітні, вони залежать від конкретних умов і не зводяться лише до технічних аспектів. Розроблювачі повинні враховувати такі особливості ведення проекту, як технічна політика керівництв фірми й замовника, їх компетентність, їх розрахунки на удачу, з одного боку, а з іншого — кредитоспроможність, репутацію тих, хто пропонує замовлення. Ризик невиконання проекту може бути зв'язаний і зі зміною ринкової кон'юнктури. Нарешті, є чисто внутрішні причини ризиків: збої у використовуваному оточенні (програмному й технічному), неточність пропонованих вимог, ненадійність підрядників та ін. і, можливо, кадрів (не можна виключати, що прийнятий на ключову роль працівник відмовиться від контракту в самий невідповідний момент). Щоб знизити вплив ризиків на розвиток проекту, менеджер повинен розробити спеціальний план, називаний далі планом керування ризиками. Зміст цього плану — ідентифікація ризиків для даного проекту й заходу, що знижують залежність проекту від ризиків. Подолання ризиків може здійснюватися на декількох рівнях:

1. Виключення ризику. Деякі ризиковані ситуації можуть бути виключені повністю. Наприклад, щоб звільнення працівника із ключовою роллю не дуже позначилося на продовженні розвитку проекту, доцільно із самого почала запропонувати для заняття цієї ролі двох людей порівнянної кваліфікації. На початку проекту їх дискусії корисні для вироблення об'єктивних розв'язків, а якщо один з них відмовиться від контракту, другий усе ще зможе продовжувати справа. Корисні дискусії — ця та жертва, яку в ряді випадків можлива для виключення ризику. На жаль, дублювання не може бути рекомендоване для виключення всіх ризикованих ситуацій. Окремий випадок виключення ризику — перемикання його із проекту на оточення. Приміром, якщо ринкова цінність створюваного виробу видасться сумнівної, для його розробки комфортніше домовитися із замовником про авансові платежі, тим самим, змусивши його самого вирішувати завдання подолання ризику і звільнивши від цього розробників (можливо, за рахунок

зниження оплати проекту). На жаль, ця стратегія є виключенням ризику тільки для розроблювачів, але не для проекту в цілому.

2. Зменшення ризику. Якщо ризик не може бути виключений, можна постаратися зменшити його поява на практиці. Продовжуючи приклад зі звільненням працівника, для зниження ймовірності цього слід угадати причини вчинку й постаратися створити для працівника більш комфортні умови (підвищити заробітну плату, створити пільги і т.п.). Потрібно, щоб подібні розв'язки робилися не у відповідь на заяву про звільнення, а заздалегідь. Це збереже певну стабільність у колективі, яка сама по собі є методом зменшення ризику. Інший приклад зменшення ризику – оголошення ( для замовника, керівництва й колективу) про перегляд вимог, коли стає зрозумілим, що графік

виконання робіт може бути зірваний. Як і в попередньому випадку, важливим моментом тут є попередження, тобто перегляд вимог не у відповідь на

порушення графіка, а в якості превентивного заходу.

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

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

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

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

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

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

забезпечення — засобу відкоту й архівування. Для всіх ризикованих ситуацій планом керування ризиками передбачаються заходи

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

відповідальності проекту, його важливості для компанії й замовника, з одного боку, а з іншого – від ступеня новизни проекту, опрацьованості технології його виконання.

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

подолання труднощів. Для менеджера при складанні плану найважливіше — не упустити всі можливі ризиковані ситуації.

Проект із великою часткою новацій є ризикованим підприємством завжди. Із цієї причини для нього план керування ризиками є обов'язковим і повинен бути максимально

деталізованим у частині обліку невірних розв'язків, помилок в оцінці ситуацій і т.п. Багато проектів залежать від навколишніх факторів у більшій мері, чому від

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

подолання ризикованої ситуації провести аналіз ситуації. Потрібно оцінити ефективність передбачених, виконаних і невиконаних заходів, зрозуміти, що могло б бути краще

організоване, перевірити якість попередніх оцінок. Досвід, отриманий при такому аналізі, застосовується безпосередньо: при перегляді плану. Це досить важливо, оскільки ситуації, подібні тієї, яка переборена, цілком імовірно можуть повторитися в ході подальшого розвитку проекту.

Нижче приводиться перелік (далеко неповний) ситуацій, яких повинен уникати менеджер, і які він повинен ураховувати, становлячи план керування ризиками:

· затримка початку проекту ніколи не компенсується; · якщо сітковий графік виконується з більшими порушеннями строків, важко очікувати створення гарного продукту;

· якщо користувацький інтерфейс не є інтуїтивно зрозумілим і перевищує рівень компетенції споживача виробу, продукт буде погано поширюватися;

· упущені можливості вимагають додаткових зусиль при них більш пізній реалізації й збільшують витрати;

· не протестований продукт знижує репутацію розроблювачів;

· не варто розраховувати на сталість користувацьких намірів, ніколи не можна знати, що хочеться користувачеві й чого насправді йому потрібно. Як наслідок, необхідно планувати час на переробку того, що на початку проекту видалося прийнятним.

ПОНЧИК