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