Agile — определения пользовательских историй [закрыто]

Question

Я пишу небольшое приложение для бизнеса моего друга и решил воспользоваться возможностью, чтобы освежить в памяти обучение по гибкому управлению проектами, которое я прошел в начале года.

Я (и, думаю, моя нынешняя организация!) всегда сталкивался с проблемой сбора требований в форме пользовательских историй, которые принимают форму:

Как [Тип пользователя] мне нужна [функция], чтобы [некоторая выгода]

Я всегда Возникает соблазн пропустить начало и конец и просто оставить эту функцию - но тогда это просто становится сбором требований по-старому!

Но я не хочу просто привести его в соответствие, чтобы я мог сказать: «Я использую Agile»....например, если я знаю, что пользователю должен быть представлен список элементов, то причина очевидна, не так ли?

например

Как [менеджер магазина] я хочу [видеть список товаров на складе], чтобы...?

Является ли нормальной практикой исключение пункта [так что]?

Answer 1

Мы тоже раньше это пропускали.И, оставив это без внимания, мы многое упустили.Чтобы правильно понять эту функцию и не просто сделать то, что правильно, но и делайте правильное, что является ключом к тому, чтобы знать, почему эта функция, и для этого следующий ключ - кто (роль) в терминах DDD, заинтересованные стороны.Заинтересованные стороны могут быть разные, все кому небезразлично.От программистов и администраторов БД до всех типов пользователей.

Итак, сначала поймите, кто является заинтересованной стороной, потом вы знаете 50% ПОЧЕМУ его волнует, затем выгоду, а потом уже почти очевидно, ЧТО реализовывать.

Постарайтесь не просто писать «как пользователь».Указать."как заведующий магазином", или даже "как начальник смены, ответственной за закрытие дня", мне нужно....чтобы....

Возможно, вы сможете реализовать что-то другое, что принесет той же заинтересованной стороне еще большую выгоду!!!

Answer 2

Попробуйте, чтобы достичь [Бизнес-ценности] Как [Пользователю] мне нужна [Функция].

Цель состоит в том, чтобы сосредоточиться на ценности, которую обеспечивает эта функция.Это помогает вам мыслить вертикальными срезами, что сокращает чисто «технические задачи», которые не видны.Это нелегкий переход, но когда вы начнете мыслить вертикально, вы действительно сможете сократить потери в своем процессе.

Другой способ — подумать о приемочных тестах, которые ваш клиент мог бы написать, чтобы убедиться, что функция работает.Это короткий прыжок, чтобы затем использовать что-то вроде Фитнессе автоматизировать эти тесты.

Answer 3

Нет, на самом деле это не очевидно — есть много причин, по которым вам нужно просмотреть список, и много чего вы можете с ним сделать — отсканировать его, чтобы получить некоторую информацию, получить обзор, распечатать, скопировать и вставить в файл. текстовый документ и т. д.И что именно это даст вам ценные подсказки о разумных деталях реализации - форматирование списка, точное содержание;или даже намек на то, что другая функция могла бы лучше удовлетворить эту потребность.Не удивляйтесь, узнав, что причина на самом деле в том, «чтобы я мог посчитать количество записей»…

Конечно, на самом деле это может к вам не относиться.На самом деле я хочу сказать, что есть причины, по которым люди придумали этот шаблон, а также есть причины, по которым многие опытные люди на самом деле его не используют.А когда вы новичок в этой практике, вы не в состоянии оценить все плюсы и минусы ее применения, поэтому я настоятельно рекомендую просто попытаться внимательно следовать ей в течение некоторого времени.Вы можете быть удивлены его полезностью - или нет, и в этом случае вы все равно чему-то научились и можете изложить это в четком кратком изложении...:)

Answer 4

Пользовательские истории — это еще один способ сказать, что вам нужно взять интервью у своих пользователей, чтобы узнать, чего они хотят и какие проблемы пытаются решить.В основе этого лежит гибкая разработка.Если эта форма вам не подходит, сделайте шаг назад и попробуйте другой подход, который кажется вам более естественным или лучше соответствует вашим писательским способностям.

Короче говоря, не думайте, что вам обязательно нужно быть в смирительной рубашке.Важно то, что вы следуете духу методологии.

В данном конкретном случае вы хотите получить список проблем, с которыми сталкивается пользователь, почему они являются проблемами и что, по их мнению, ему поможет.

Answer 5

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

Answer 6

Я часто классифицирую свои истории по пользователю/персонажу, к которому они в первую очередь относятся, поэтому я не указываю личность пользователя в заголовок истории.Мои истории также больше, чем предполагают некоторые гибкие методологии.Обычно я начинаю с названия.Я использую его для планирования.Как только я приближаюсь к работе над этой историей, я конкретизирую ее некоторыми деталями — основную идею, ограничения, предположения, связанные истории — так, чтобы ухватить больше информации, которую я знаю о ней.Я также храню свои истории в вики, а не на карточках.Я понимаю компромисс — т. е. я могу потратить слишком много времени на детали, прежде чем они мне понадобятся, но я могу легко собрать их и поделиться ими, как правило, с клиентами за пределами офиса.

Суть для меня в том, что Agile — это философия, а не спецификация.Существуют определенные реализации, которые могут (настоятельно) предполагать, что вы делаете что-то определенным образом, и по некоторым пунктам могут быть не подлежат обсуждению.Например, трудно сказать, что вы занимаетесь XP, если вы не выполняете парную программу.В целом, однако, я бы сказал, что большинство аджилистов скажут, что вы должны делать те вещи, которые работают на вас, так, как они работают на вас - пока они согласуются с общими принципами, вы все равно можете называть их сам проворный.Общие принципы включают в себя такие вещи, как ранний выпуск/частый выпуск, модульное тестирование, короткие итерации, признание того, что изменения произойдут, отсрочка детального планирования до тех пор, пока вы не будете готовы к реализации...

Итог для меня:Если истории работают на вас без пользователя и обоснования (пока вы понимаете, кто этот пользователь и почему он чего-то хочет), делайте это так, как хотите.Только не требуйте полной спецификации перед началом реализации.