Чи дозволено "Технічні історії користувачів" в Scrum?

Чи дозволені технічні історії користувачів у Scrum? Якщо так, то який стандартний шаблон для написання технічних історій користувачів у Scrum? Це те саме As a <user> I want to do <task> so that I can <goal>??

Я читав у деяких блогах, що історія "розробник - це не є користувачем" , але також читала, що Scrum не наказує цим. Є кілька блогів, де вони ділиться історіями користувачів із системою як користувачем , як as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. То який із стандартних?

Наприклад, є такі історії користувачів, як:

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

Як користувач я хочу додати коментарі до фотографій, щоб я міг краще пояснити свій погляд

Тепер для обох цих історій користувача є великий технічний елемент - Збереження та отримання зображення

Тож чи можу я додати технічну історію під назвою "Механізм зберігання та вилучення зображень" із наступним описом?

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

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

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

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

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

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

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

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

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

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

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

У таких умовах можна визначити значні історії розробника. Це збільшує видимість, породжує довіру, а також заохочує розробників та менеджмент так само думати про цінність таких завдань для бізнесу та надавати їм пріоритет.

Зрештою, я пропоную вам спробувати. І, якщо вона не пропонує цінності, припиніть це робити.

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

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

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

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

Якщо є краща найкраща практика для цього, я все вухо.

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

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

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

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

Усі вищезазначені відповіді не посилаються на авторитетний вихідний документ для рамки Scrum: Посібник з Scrum .

Блокування продукту перераховує всі функції, функції, вимоги, удосконалення та виправлення, що є змінами, які слід внести до продукту в майбутніх випусках.

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

Термін історія користувача ніколи не відображається в Посібнику з Scrum, оскільки

це рамка, в рамках якої можна використовувати різні процеси та методи.

Використання історії користувача - лише одна з можливих методик запису PBI. Хоча звичайно бачити формат "Як, я хочу, так що", це може суперечити його первинному наміру . Цей проблемний формат також був вирішений на Agile 2017 .

Розуміння та використання вертикального нарізання буде корисним для зменшення розміру предметів "Блокування продукту". Розглянемо нарізку , що одного збереження і вилучення елемента в економії і отримати елемент s .