Як розповіді користувачів не можуть містити вимог (коли вони написані на картці) і все ще можуть бути реалізованими

Мені сказали: "Історії користувачів - це не вимоги, це лише нагадування про те, що хоче клієнт. Ви не можете ставити вимоги в рамках історії". Але візьмемо для прикладу, що клієнт хоче різну обробку для різних кредитних карт. Існують суворі вимоги, які повинні бути виконані та відомі, щоб можна було писати тестові приклади. Куди повинні відповідати вимоги, якщо не в історії користувача?

Як розробники можуть розвиватися з історії, якщо немає нижчих вимог? Як тестери можуть писати тестові справи (детальні) на основі історії користувача? Де такі вимоги, як обмеження БД, перевірка полів тощо, знаходяться поза історією користувача?

Ця відповідь буде зосереджена на тому, як працювати з Історіями користувачів та вимогами нижчого рівня. Я не буду обговорювати чесноти, або їх відсутність, Scrum або Agile. Я не буду говорити про гуру.

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

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

Однак це не означає, що ці дані не повинні записуватися ніде.

Коли розробники впроваджують Історії користувачів, вони повинні знати про деталі нижчого рівня, які типові користувачі не знають. Ця інформація може надходити від МСП, BA, власника продукту, вашого архітектора чи будь-якого іншого експерта чи технічно налаштованої людини.

Чи означає це, що дані про низький рівень мають бути записані в Історіях користувачів? Ні (і так).

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

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

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

Так, її BS. І Scrum - не спритний.

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

Agile - це спритність.

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

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

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

Просто не називайте це історією користувача, і всі будуть раді.

Я думаю, що відповідь полягає в тому, що ви можете записати це де завгодно.

Загалом, конкретні реалізації не включаються в історію користувача з кількох причин:

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

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

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

Які існують вимоги до програмного забезпечення?

Вимоги до бізнесу

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

Вимоги користувача

Це вимоги щодо Історії користувачів, які ви знайомі. Вони, як правило, можуть поміститися на клейкій ноті.

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

Функціональні або системні вимоги

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

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

Функціональні вимоги визначають ваше рішення, яке звучить як те, що ви описуєте, як розрив у вашому процесі.

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

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

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

Ваше запитання звучить дуже схоже на щось подібне

У мене є цей CarFactory, і мені потрібно, щоб він також робив велосипеди, але наш ТОВ "Гуру" каже, що мені не дозволяють цього робити. Що це за БС!?!

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

Я думаю, що мета цього підходу - не обмежувати розповіді користувачів, а запобігати поганим вимогам.

На мій досвід, користувачі, як правило, не здатні писати вимоги. Зазвичай розробники не в змозі написати вимоги. Чорт забирай, визнаймо це прямо: вимоги важко написати!

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

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

Приймайте власні рішення

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

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

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

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

TL; DR

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

Деталі специфікацій та впровадження найчастіше фіксуються в інших артефактах, таких як Сценарії прийняття-тестування (ATDD), Тестово-керована розробка (TDD), та сценарії та сценарії розвитку, керовані поведінкою (BDD). Ці конкретні артефакти не покладені на рамки Scrum, але вони, безумовно, дадуть вам хорошу відправну точку, якщо у вас ще немає інших ефективних засобів управління процесами.

Історії користувачів не є специфікаціями

Оригінальний плакат (ОП) задав наступне питання :

[A] Клієнт хоче різної обробки для різних кредитних карток, існують суворі вимоги, які повинні бути впроваджені та відомі, щоб можна було писати тестові випадки ... ДЕ МОЖЕ Я ВСТУПИТИ ЇЇ, АБО НЕ В ІСТОРІЇ?

Історія користувача - це функція, яка забезпечує цінність , надає певний контекст для керівництва розмовами про реалізацію та точку зору, пов’язану із споживачем цінності, який отримає користь від цінності, наданої функцією.

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

Робочий приклад

Прикладна історія користувача

Це простіше пояснити, якщо ви почнете з менш неоднозначного набору історій користувачів. Оскільки ОП не надала дію історію користувача, яка відповідає мнемоністичній INVEST , я вигадаю її заради прикладу. Розглянемо наступну історію:

Як користувач, який вважає за краще платити карткою Discover,
я хотів би здійснити покупки за допомогою картки Discover,
щоб я не обмежувався Visa, Mastercard або American Express.

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

Аналіз та реалізація

Фактична реалізація залежить від команди. Команді доведеться зробити аналіз, щоб визначити:

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

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

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

Дизайн, керований тестом та поведінка

Найкращий спосіб забезпечити обґрунтованість аналізу та реалізацію як розумної, так і сприятливої ​​- це використання практик TDD та BDD. Наприклад, враховуючи вищезгадану історію, команда повинна фіксувати заплановану реалізацію за допомогою артефактів, таких як:

• Особливості огірків із тестовими сценаріями.

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

• Тести RSpec, які підтверджують поведінку (не внутрішні деталі реалізації) нових функцій коду.

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

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

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

Я думаю, що одна причина, коли ваша команда перестає працювати, - це міграція з непридатної методології.

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

Але це не завжди працює. Часто це не працює. Причина? Тому що вимоги рідко узгоджуються з реальністю. Все змінюється. Звідси рух у напрямку Agile.

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

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