У Scrum ви повинні розділити відсталі на функціональні та технічні відставання чи ні?

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

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

Який найкращий підхід? Один відставання чи два?

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

Я хотів би додати свій голос тим, хто рекомендує одне відставання за продукт. Створення іншого відставання є раціональною відповіддю, але насправді просто уникає основної проблеми: Чому Власник продукту не надасть пріоритет технічним елементам над елементами? Вам слід зосередитись на вирішенні цього, а не працювати над цим. Наприклад, ви можете використовувати техніку 5 Whys , щоб спробувати дістати до низу речей.

Може бути багато причин, чому ПО не надає пріоритетних технічних проблем. Наприклад, можливо, технічна команда не пояснює довгострокову вартість (у $$$) невлаштування технічної заборгованості. Можливо, це щось інше повністю. Є хороший шанс, що справа стосується питання зв’язку, і довгострокове рішення полягає в тому, щоб попрацювати над цим і вирішити - усунути перешкоди.

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

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

Те, що ви пропонуєте, схоже на те, що ви також можете запропонувати окремий «дефект», розділивши його на 3.

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

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

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

Я погоджуюся з усіма відповідями вище. У запалі комерційної реальності, ПО продовжуватиме надавати пріоритет функціональним сюжетам над технічними. Часто до розчарування команди. Команда повинна утримуватися від технічних сюжетів без будь-якої цінності користувача (хто піклується про оптимізацію, якщо швидкість не є проблемою?) І навчитися бачити певні інші технічні завдання, як маються на увазі функціональні історії. Велике значення також відіграє "визначення зробленого". Решта функціональних історій надходять у відставання для ПО, щоб визначити пріоритет.

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

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

Я згоден з MelR. Якщо є щось, що є "технічним", нам потрібно розібратися, чому ми це робимо - або навіть які коротко- та довгострокові причини та наслідки (для користувача) ?.

Я бачив багато відставань, де так звані "технічні завдання" можна легко записати діловим значенням.

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

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

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

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

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

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

Я не бачу проблеми створювати за допомогою PO завдання, де ІТ-команда є користувачем. Якщо завдання може бути зрозуміле з ПЗ і може бути оцінене з точки зору ділової цінності, то так, у вас є спосіб створити різновид технічних історій. Ви просто використовуєте систему.