Чи може Scrum використовувати технічні характеристики в Блоку продукту, а не розповіді користувачів?

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

У цьому можна виправдати технічні завдання, а не розповіді користувачів. Наші відставання мають всі види технічних завдань, такі як:

• Перепишіть клас DB з MySQL на PostgreSQL.
• Впровадити системний журнал.
• Перезапишіть кеш об’єктів.

Речі, які з'являються під час референдуму, включають, що потрібні тривалі "дослідницькі завдання", але вони ніколи не виконуються. Також члени команди стверджують в середині спринту, що потрібно додати незаплановані завдання.

Як майстер Scrum повинен вирішити це? Чи може бути, що для подібного проекту Scrum НЕ йде?

TL; DR

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

Різні проблеми з вашим процесом

Здається, ваш Scrum зламаний найрізноманітнішими способами, зокрема:

1. У ваших специфікаціях відсутня чітка точка зору або пропозиція про значення.
2. Ваші затримки не прив’язані до цілей спринту.
3. Процес догляду за затримкою або взагалі відсутній, або не вдається створити сюжетні шипи для Блокування продукту.
4. Процес планування спринту недостатньо розкладає елементи Блоку продукту на елементи Блоку спринту.
5. Ваша команда не належним чином враховує невизначеність щодо предметів відставання у своїх оцінках планування спринту.
6. Ваша команда не поважає основ таймбоксу чи цілісності спринту.

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

Чому спритні програмісти сприймають історії користувачів

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

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

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

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

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

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

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

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

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

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

Це має для мене 100% сенс. Ви створюєте відставання, яке розповідає історії користувача вашої продукції, а хто є користувачем? Технічний керівник. Таким чином, такі предмети, як:

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

І те, що ви доставляєте своєму клієнту (технічному менеджеру), - це система лісозаготівлі.

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

Як майстер Scrum, ви, можливо, захочете розглянути довші спринти через характер роботи. Це дасть вам трохи більше буфера для "дослідницьких" завдань. Однак я думаю, що вам потрібно переконатися, що завдання створюють певний робочий продукт / доказ поняття в коді. Чого ви очікуєте зробити програміста? Попросіть їх отримати щось для роботи та скористайтеся цією інформацією, щоб визначити, чи відповідає A: це робить те, що ми хочемо B: він працює краще C: Скільки часу знадобиться, щоб отримати швидкість і почати розуміння, скільки часу це буде взяти, щоб щось зробити.

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

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

Деякі з наведених нижче стратегій можуть допомогти,

1. Так, ви можете мати відставання за допомогою Технічних історій .

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

2. Для дослідницьких (дослідницьких) завдань Використовуйте колосок

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