У моїй попередній статті я почав дискусію навколо погано розвинутих звичок у команді scrum, які зрештою призведуть (рано чи пізно) до невдачі. У цій статті я хотів би розширити цю тему ще раз і зосередитися зараз на функціональних процесах всередині команди.
Це так само важливо, як і технічна досконалість команди. Навіть якщо люди всередині суперкваліфіковані для роботи, яку вони збираються виконати, все одно є сфери, які можуть зруйнувати їхні зусилля для досягнення досконалості. І це буде не стільки їх провина, скільки пряма відповідальність за рішення щодо управління проектом і їхню здатність обслуговувати команду за допомогою процесів, які відповідають меті, щоб підтримувати команду з чіткими намірами та передбачуваною діяльністю.
Сильно відокремлена команда з різними навичками
Уявіть собі, що команда має кваліфікованих розробників, абсолютно незалежних і здатних виконати свої обіцянки та надати узгоджений вміст спринту якраз вчасно до кінця спринту. Навіть за такого ідеального сценарію (що в будь-якому випадку малоймовірно), команда матиме проблеми з виконанням (постійно зростаючих) невиконаних завдань, якщо навички суворо розділені між членами команди.
Кілька прикладів
- Команда має 1 або 2 інженерів DevOps, здатних вносити будь-які зміни в автоматизовані конвеєри або піклуватися про послуги всередині платформи, але решта команди не має жодного поняття про такі речі. Тоді обговорення цих історій на церемоніях зіткнень, як-от уточнення, призведе до марної втрати часу для більшості команди через зависання наради без будь-якої участі, і навпаки – розробника DevOps не цікавитимуть інші історії, орієнтовані на функціональність, і час на зустріч також буде здебільшого витрачено.
- Для всієї команди є єдиний експерт з баз даних. Залежно від складності та використання рішень для обробки даних у системі, яку розробляє команда, ця особа може бути постійно перевантажена історіями, які вони не мають шансів завершити досить швидко, особливо з урахуванням їхніх пріоритетів. Що ще гірше, іншим історіям також доведеться почекати, оскільки вони залежать від джерела даних, наданого історіями бази даних.
- Коли певний продукт здебільшого орієнтований на бекенд-розробку, на всякий випадок є єдиний інтерфейсний розробник (оскільки час від часу все одно потрібні невеликі зміни навіть у програмі інтерфейсу користувача). У цьому випадку, знову ж таки, більшість церемоній сутичок є марною тратою часу для цього члена команди, оскільки їхні знання обмежуються лише початковою частиною, і ніщо інше не має значення.
Де це завершується
У будь-якому з наведених вище випадків результатом є те, що люди або витрачають свій час, або, навпаки, вони не можуть наздогнати відставання від попиту. Вони блокують решту команди від початку роботи над наступними історіями, або фактично знижують загальну ефективність команди scrum, оскільки надто багато часу не використовується під час спринту.
У команді, однак, ще є така кількість розробників. Ззовні не видно (навіть не хочеться викривати), що люди всередині команди не можуть сприймати деякі історії лише тому, що вони надто орієнтовані на певний набір навичок. Таким чином, вони не можуть допомогти іншим членам команди з історіями, навіть якщо їхні можливості дозволяють це, і пріоритети для історій також сприятимуть цьому.
Власнику продукту навіть важко скласти якийсь значущий вміст спринту для команди, оскільки власник продукту завжди повинен враховувати, скільки людей може працювати над кожною окремою історією та чи більше схожих історій залучаються до спринту одночасно , зрештою можливості команди переповнені, навіть якщо насправді є люди, які могли б працювати над цими історіями, але вони не мають навичок, щоб почати з ними.
Вирішення дилеми
Це дилема, яку потрібно вирішити, і керівники проектів повинні знати, який шлях вибрати. Зокрема, вибір між:
- Наявність багатьох повноцінних розробників, здатних працювати над більш широким вмістом, але не дуже експертів у багатьох темах. Таким чином, вони можуть пройти вшир, але не вглиб. Тоді доставка може проходити швидко, але якість може погіршитися.
- Наявність спеціалізованих експертів для кожної технології, але потім погодження з обмеженнями та активніша робота над кращим вмістом для друку. Тоді люди зможуть занурюватися в глибину і створювати чудові історії, але до них потрібно буде підходити послідовно, а отже, на їх створення потрібно більше часу.
Слабкий власник продукту
Це не обов’язково «проблема процесу» за визначенням, але я ставлюся до неї так лише тому, що створення надійних історій можна розуміти як процес, який команда повинна хотіти мати надійним і сумісним з командою розробників.
Те, що я маю на увазі під слабким, має на увазі не властивість людини знати, а скоріше здатність власника продукту подавати команді історії, які розробники можуть зрозуміти і які мають певний сенс з точки зору дорожньої карти продукту. Обидва вони дуже важливі для успішної команди Scrum.
Якщо в історіях бракує деталей, щоб розробники могли чітко зрозуміти мету, функціональну цінність або технічні очікування, то в основному можуть статися два сценарії:
- Розробники створять щось відмінне від того, що насправді хотів власник продукту. Це навіть важко вловити під час самого спринту, тому що здебільшого власник продукту не мав можливості відстежувати хід історій на такому детальному рівні, і здебільшого PO просто очікує, що це станеться (чарівним чином).
- Розробники витрачатимуть надто багато часу на роз’яснення історій та їх обговорення знову й знову, замість того, щоб почати їх створювати. Це передбачає багато додаткових дзвінків, повторних домовленостей і відкладення роботи на пізню фазу спринту. Він досягає точки, коли початкові оцінки для історій більше не можна вважати точними, і історії неможливо закрити в межах спринту та переходять у наступні спринти. У гіршому випадку ситуація повторюється в наступних спринтах.
Час для саморефлексії
Зазвичай це важко визнати, але власник продукту повинен знайти час, щоб поміркувати, переглянути створені невиконані історії та, зрештою, порівняти це з баченням дорожньої карти продукту, якщо між цими двома все ще є якийсь розумний зв’язок – якщо є якась дорожня карта зовсім. Якщо ні, це перше, що потрібно вирішити. Іноді рішення полягає в тому, щоб визнати, що власник продукту занадто далекий від команди і занадто далеко від власної мети.
У такому випадку потрібно розв’язати частину команди власника продукту. Якщо нічого іншого, залучення до команди надійного бізнес-аналітика, орієнтованого більше на контент команди, а не на бізнес-контент (для цього в даному випадку у нас уже є власник продукту), може бути прийнятним варіантом, навіть за ціною зросли загальні витрати бригади.
Процеси тестування без фіксованого терміну
Що робити, якщо тестування не відповідає конкретному розкладу під час спринту?
На перший погляд це може виглядати як щось хороше, чого ми хочемо для гнучкої/scrum-команди. Гнучкість завжди вітається і добре звучить, коли представлена назовні.
Мій досвід показує, що результатом цієї свободи є більше хаосу, ніж гнучкості. Це не означає, що вирішенням цієї проблеми має бути створення «водоспадів у спринті» з виділеними фазами тестування, які слідують відразу після завершення розробки. Це аж ніяк не правильний підхід у даному випадку. Ви можете прочитати більше про це в моїх публікаціях про стратегію тестування scrum і життєвий цикл гнучкого тестування.
Ми все ще можемо дозволити певну гнучкість і вибрати графік тестування, оскільки він найбільше підходить для поточної команди розробників і даних властивостей продукту, який команда надає. Є, однак, дві основні цілі, які повинні бути досягнуті цим вибором:
Якщо ці умови будуть дотримані, команда природним чином адаптується до процесу підгонки, і незаплановані тривалі дії з тестування не вплинуть на графік доставки.
Зрештою, найбільше значення має надійний і передбачуваний випуск спринту, що підводить мене до останнього пункту цього блогу.
Невизначений процес випуску
Тепер це настільки очевидна річ для кожної scrum-команди. Проте, як не дивно, це також зазвичай один із найбільш недооцінених процесів.
Дуже часто команда scrum просто каже, що реліз буде після кожного спринту, але це не підтверджено надійним процесом. Що відбувається тоді, насправді, багато хаотичних, непередбачуваних дій виникне під час випуску. Раптом усі люди зайняті «задачами випуску», і ніхто не може зосередитися на продовженні розробки нових історій спринту. Показники спринту вимкнено, а випуск виглядає як випадкова, непередбачувана дія з точки зору третьої особи (зазвичай клієнта).
Люди настільки зосереджені на відставанні, вмісті спринту, розробці, тестуванні та, нарешті, демонстрації результатів, що вони забувають, що як тільки вони закінчать усе це, наступний спринт уже триває, і вони вже втрачають час.
Шукаю вдалий час для звільнення
Отже, коли саме команда має здійснити фактичний випуск у виробництво? Єдина важлива річ, яка має значення в кінці.
Відповідь на це запитання знаходиться в процесі, припускаючи, що у вас є. В залежності від:
- складність контенту, який створює команда під час спринтів,
- тривалість спринту,
- кількість уражених компонентів у системі
- кількість людей, які використовують зміни та запитують їх,
повторний процес випуску повинен бути встановлений і дотримуватись надалі. Точні правила процесу знову можуть бути гнучкими у визначенні. Але, як і у випадку з тестуванням, зробити його міцною звичкою, передбачуваною та запланованою на конкретні дні в майбутньому, це те, на що можна покладатися та посилатися.
Вибір на вибір
Можливими формами такого процесу можуть бути будь-які з наступного або інші:
- Завершіть тестування функцій поточного спринту під час наступного спринту та випустіть вміст наприкінці цього спринту (після завершення тестування). Це означає, що в кожному випуску не буде вмісту з останнього спринту, але він міститиме історії з 2 попередніх спринтів.
- Останній спринт перед випуском завжди присвячений тестуванню вмісту двох попередніх спринтів.
- Це не означає, що розвиток під час «тестового спринту» буде зупинено; у ньому лише сказано, що вміст, розроблений у цьому тестовому спринті, ще не буде включено до наступного випуску.
- Якщо вже є достатня кількість автоматизованих тестових дій, намагайтеся випускати після закінчення кожного спринту. Тоді це має бути дуже суворий процес із відданими людьми, які зосереджуються на цих кількох днях на 100%. Це не повинно вплинути на решту команди розробників.
- Ви також можете вибрати випуск раз на місяць або раз на N місяців, головним чином, якщо це буде добре з точки зору кінцевих користувачів. Це збільшить зусилля на стороні тестування для кожного спринту (оскільки вміст буде більшим для кожного випуску). Але з іншого боку, це означатиме меншу кількість повторюваних дій з часом, що в цьому випадку може принести користь команді. Як наслідок, це може дозволити команді створювати більше нових функцій між випусками, незважаючи на те, що функції фактично виходитимуть у виробництво з меншою швидкістю.
Але, як уже було сказано кілька разів раніше, не так важливо, який із цих процесів буде обрано. Набагато важливіше, наскільки добре команда потім дотримуватиметься цього процесу і зробить це важкою звичкою.
Ви також можете прочитати цей посібник щодо процесу та практики керування випусками.