Процес «Управління релізами» — для постпроектной підтримки або розвитку продукту

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

Процес «управління релізами, один з стека процесів ITSM, якраз і пропонує рішення для формальної пріоритизації та угруповання запитів користувачів (запитів на зміни, інцидентів) загальні пакети доставки — «релізи».

У даній статті коротко розкриваються такі теми:

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

Застосовність процесу
Коли доцільно застосовувати процес, в доповнення до управління інцидентами та управління змінами? Зрозуміло, в кожному випадку різний набір критеріїв, але перелічені нижче сценарії — гарний привід задуматися про релізах:

  • Початковий період постпроектной підтримки: значну кількість змін, проблеми з приоритизацией, необхідність эффектично упрявлять очікуваннями замовника
  • Процес підтримки продукту: необхідність організувати процес, що оптимізує використання всіх наявних ресурсів у рамках існуючого бюджету.
  • Великий відсоток запитів на зміни зачіпають пересічні предметні області або призводять до технічних залежностям — необхідно групувати зміни з метою оптимізації робіт з розробки або тестування.
  • Процес безпосередньої доставки розроблених змін продукту на продуктив — «дорогий», з будь-якої точки зору: від координації, до безпосередніх витрат на розповсюдження змін.
Крім того, при певних умовах планування й організації етапів релізів — весь процес доставки можна максимально наблизити до методики Scrum (регулярна поставка змін, з найвищою цінністю для замовника), таким чином поступово переходячи до використання гнучких підходів в організаціях, не дуже схильних до цього.

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

1. Draft

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

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

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

Ресурси:
  • Аналітики (провідний аналітик)
  • Замовники
  • Менеджер релізу

2. Scope

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

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

Ресурси:
  • Аналітики
  • Замовники
  • Розробники (Тих лід)

3. Approval

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

Результат:
Сформовано фінальне зміст релізу.

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

Ресурси:
  • Замовники
  • Менеджер релізу

4. Work in progress

Активності:
Розробка і виправлення дефектів для всіх заявок, що увійшли в фінальне вміст релізів. Внутрішнє тестування і підготовка до приймальному тестування.

Результат:
Заявки, включені в зміст релізу — розроблені. Передача замовнику на приймальне тестування.

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

Ресурси:
  • Розробники
  • Аналітики

5. Testing

Активності:
Проведення приймального тестування замовником, виправлення виявлених помилок, проведення необхідних доробок (за погодженням)

Результат:
Вміст релізу протестовано, прийнято замовником, і готове до поширення.

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

Ресурси:
  • Замовники
  • Аналітики
  • Розробники

6. Deployment

Активності:
Пакет змін передається в експлуатацію. Публікація нової версії продукту продуктивної середовищі.

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

Ресурси:
  • Служба експлуатації

7. Closure

Активності:
Завершення робіт над пакетом змін: необхідні формальні кроки (документи, акти, рахунки ), обговорення всередині команди результатів релізу.

Результат:
Формальне завершення робіт. Поліпшення процесу.

Ресурси:
  • Менеджер релізу
Планування релізів
Як і будь-яку активність, релізи потрібно планувати. На щастя, управління релізами — це процес, і тому при плануванні можна розраховувати на те, що етапи, їх взаємозв'язок не змінюються. Однак для планування розкладу релізу необхідно принципово визначитися з підходом до доставки:

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

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

Планування релізів з фіксованою тривалістю

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

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

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

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

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

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

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

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

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

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

Календарне планування релізу

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

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

  • приблизне співвідношення між ресурсами аналітиків і розробників при роботі на одну задачу. Наприклад, «якщо аналітик витратив на вимоги 5 людино*днів, то витрати на розробку і тестування складуть приблизно 10 людино*днів».
  • аналогічно — співвідношення між аналізом вимог, і тривалістю приймальних випробувань
  • склад команди: кількість аналітиків, розробників, тестувальників.
Маючи інформацію про співвідношення витрат і складі команди — можна визначити співвідношення часів етапів. Хорошою базою для фіксації кінцевих тривалостей може служити фаза розробки (оскільки саме оцінка витрат на розробку є найбільш методологічно відпрацьованої) — від неї будуть вважатися тривалості всіх інших етапів.

Тривалість етапів «Розгортання» і «Closure» зазвичай встановлюється фіксованою, оскільки вони напряму не залежать від обсягу змін. Зрозуміло, якщо залежність у вашому випадку існує — вона повинна враховуватися.

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

У будь-якому випадку — використовуйте інструменти, призначені для календарного планування (як, наприклад, MS Project). Особливо це важливо при створенні календаря з пересічними під час релізами, оскільки потрібно буде ретельно контролювати завантаження ресурсів.

Одночасне виконання кількох релізів

Як видно з опису етапів релізу, на кожному з етапів залучені різні ресурси і профіль завантаження — не однорідний:

  • Аналітики — максимально завантажені на етапі Scope і Test, менш завантажені на етапах Draft і Work in progress. Під час Work in progress аналітики часто залучені в роботу з Розробниками, в разі необхідності пояснюючи вимоги.
  • Розробники — максимально завантажені в період Work in progress. В залежності від реалізації процесу, на цьому етапі ведеться робота за запитами на зміни, що увійшли в затверджене зміст релізу. При цьому в інший час можуть займатися виправленням дефектів, рефакторінгом коду, і іншими корисними справами.
  • Замовники — залучені в період збору вимог (Scope) і приймального тестування (Testing). В інші періоди — залучення замовника незначне.
Таким чином, очікуваним кроком щодо оптимізації завантаження ресурсів — паралельне виконання двох (або більше) релізів, спланованих так, щоб ресурси постійно переключатися між однаковими етапами наступних проектів. Тобто, наприклад, аналітик, завершивши стадію аналізу для релізу R1, переключався на стадію аналізу релізу R2. Аналогічно — для розробників і замовників.

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

У разі, якщо ви будуєте процес управління релізами з паралельними етапами — календарний план релізу повинен враховувати перекриття і завантаження ресурсів. Цілком можливо, що якісне розклад паралельно виконуваних релізів буде накладати додаткові вимоги на склад команди — так щоб загальна «вироблення» Аналітиків і Розробників з урахуванням тривалості етапів були рівні.

Визначення вмісту поставки при фіксованій тривалості релізу

Подивимося, з чого складається очікуваний об'єм вмісту релізу.

Фаза аналізу вимог
Обсяг заявок на зміни, які можуть бути проаналізовані до рамках етапу «Scope» представляють максимальну невизначеність. Дійсно — поки аналітик не почне аналізувати заявку, не зрозуміє про що йде мова, сказати скільки займе повний аналіз дуже складно. Звичайно, попередній аналіз заявок на стадії «Draft» допоможе дати першу оцінку, але її можна використовувати для розподілу замовлень між аналітиками — залежно від їх спеціалізації та досвіду. Крім того, необхідно враховувати, що аналітик залучений в приймальне тестування — так що, аналізом вимог і передачею в розробку навантаження на аналітика в рамках релізу не закінчується.

Таким чином, перша оцінка вмісту релізу може бути дано в термінах «кількість заявок на аналітика в реліз». Найбільш песимістична оцінка «1 заявка на зміну на аналітика в реліз» — з неї і варто починати. Після того, як статистика «продуктивності» аналітиків набрана — оцінка вмісту стане більш точною.

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

Може статися, що підготовка специфікацій займає більше покладеного часу і не вкладається в рамки стадії «Scope» — тоді запит на зміну автоматично «вибуває» з вмісту поточного релізу.

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

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

Фіксація вмісту проекту
Оцінка витрат на розробку, доступні ресурси Розробників, доступність Замовника для участі в приймальному тестуванні — все це визначає фінальне зміст релізу.

Отже, без урахування перенесення готових запитів з попередніх релізів — об'єм вмісту релізу обмежений зверху кількістю проаналізованих заявок (визначається ресурсами Аналітиків). Обмеження по ресурсах Розробників можуть додатково скорочувати обсяг релізу.

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

Перемикання контексту при паралельних релізах
При плануванні паралельних релізів виникає ситуація, коли всі ресурси — Аналітики, Замовники та Розробники повинні «перемикатися» між релізами. Зокрема, сценарії перемикання наступні:

  • Аналітик закінчив аналіз (стадія «Scope») для релізу R1 і переключився на збір аналіз для наступного релізу R2. Йому доведеться переключиться назад в контекст релізу R1 для підтримки приймального тестування.
  • Аналогічний шаблон перемикань — у Замовника, особливо, якщо його запити на зміни йдуть в наступних релізах.
  • У розробників перемикання контексту виражено менше — тільки у випадку, якщо потрібно перемикатися між новою розробкою і старими дефектами.
«Перемикання контексту — це погано». Дійсно, це призводить до зниження ефективності, втраті фокуса на завданні, і може призвести до затримки на ключових етапах процесу.

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

Ресурсні конфлікти при порушенні календаря релізу
Оскільки релізи плануються «один за одним» або взагалі «паралельно» — будь-яка затримка будь-якого етапу, і, відповідно, не звільнення ресурсів зазвичай впливає як на поточний, так і не наступний реліз через дефіцит ресурсів.

Виходячи з конструкції етапів релізу і переходу між ними — найбільший негативний ефект має затримка етапів розробки і тестування. Фази аналізу («Draft», «Scope», «Approval») мають можливість знизити вміст релізу за рахунок перенесення незакінчених заявок на наступний реліз — і це сприймається замовником, звичайно, легше, ніж перенесення після затвердження змісту релізу.

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

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

Реалізація «великих» завдань
Досить часто в ході аналізу з'ясовується, що обсяг завдання не поміщається в часові рамки етапу «Work in progress» — необхідний обсяг не виходить розробити і доставити в рамках одного релізу.

Якщо збільшити ресурси Розробників не представляється можливим, залишається два можливих шляхів вирішення цієї проблеми:

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

Однак, цілком можливо, другий варіант може бути більш доцільним з точки зору завантаження ресурсів Розробників.

Усунення дефектів у контексті релізів
Обробка інцидентів та усунення дефектів, очевидно, займають ресурси команди (в більшій мірі — Розробників, але іноді і Аналітиків). Крім того, нерідко усунення некритичних дефектів, що мають відомі способи обходу (workarounds) можуть мати меншу цінність для бізнесу, порівняно з необхідними змінами. Звідси — очевидне бажання розглядати завдання усунення дефектів (або надання додаткових сервісів) в загальному контексті планування змісту релізу — робити те, що важливо.

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

У будь-якому випадку, необхідно враховувати наявність дефектів при оцінці наявних ресурсів, які можна виділити на вміст релізів.

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

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

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.