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

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


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

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

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

Застосовність процесу

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

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

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

Етапи процесу

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

1. Draft

Активності:

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

Результат:

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

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

Ресурси:

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

2. Scope

Активності:

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

Результат:

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

Ресурси:

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

3. Approval

Активності:

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

Результат:

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

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

Ресурси:

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

4. Work in progress

Активності:

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

Результат:

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

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

Ресурси:

  • Розробники
  • Аналітики

5. Testing

Активності:

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

Результат:

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

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

Ресурси:

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

6. Deployment

Активності:

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

Результат:

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

Ресурси:

  • Служба експлуатації

7. Closure

Активності:

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

Результат:

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

Ресурси:

  • Менеджер релізу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • приблизне співвідношення між ресурсами аналітиків і розробників при роботі на одне завдання. Наприклад, «якщо аналітик витратив на вимоги 5 осіб * днів, то витрати на розробку і тестування складуть приблизно 10 осіб * днів».
  • аналогічно - співвідношення між аналізом вимог, і тривалістю приймальних випробувань
  • склад команди: кількість аналітиків, розробників, тестувальників.

Маючи інформацію про співвідношення витрат і склад команди - можна визначити співвідношення часів етапів. Хорошою базою для фіксації кінцевих тривалостей може служити фаза розробки (оскільки якраз оцінка витрат на розробку є найбільш методологічно опрацьованою) - від неї будуть вважатися тривалості всіх інших етапів.

Тривалість етапів Deployment і 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) можуть мати меншу цінність для бізнесу, порівняно з необхідними змінами. Звідси - очевидне бажання розглядати завдання усунення дефектів (або надання додаткових сервісів) в загальному контексті планування вмісту релізу - робити те, що важливо.

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

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

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

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

Ув'язнення

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

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