Agile - пользовательская история определений
Я пишу небольшое приложение для бизнеса моего друга, и подумал, что воспользуюсь возможностью, чтобы освежить в себе курс по гибкому управлению проектами, который я провел в начале года.
Я (и я думаю, что моя текущая организация!) Всегда боролась со сбором требований в форме пользовательских историй, которые принимают форму:
Как [Тип пользователя] я хочу [функцию], чтобы [некоторая выгода]
Я всегда испытываю желание пропустить начало и конец, и просто оставить эту функцию - но тогда это просто превращает требования в старый!
Но я не хочу просто привести его в соответствие, чтобы я мог сказать "я делаю Agile".... например, если я знаю, что пользователю должен быть представлен список элементов, то причина самоочевидно, не так ли?
например
Как [менеджер магазина] я хочу [увидеть список товаров на складе], чтобы...?
Это нормальная практика, чтобы опустить [так что] оговорку?
6 ответов
Мы тоже пропускали это. И, оставив это, мы многое пропустили. Чтобы правильно понять функцию, а не просто делать все правильно, а делать правильно, важно знать, ПОЧЕМУ функция, и для этого следующим ключом является ВОЗ (роль) С точки зрения DDD, заинтересованная сторона. Заинтересованные стороны могут быть разными, всем, кого это волнует. От программистов и администраторов БД до всех типов пользователей.
Итак, сначала поймите, кто является заинтересованным лицом, затем вы знаете, 50% ПОЧЕМУ он заботится, потом выгода, и тогда уже почти очевидно, ЧТО нужно реализовать.
Старайтесь не просто писать "как пользователь". Уточнить. "как менеджер магазина" или даже "как руководитель смены, ответственной за закрытие дня", мне нужно.... так что....
Может быть, вы можете реализовать что-то другое, что даст той же заинтересованной стороне еще большую выгоду!!!
Попробуй, чтобы [ценность для бизнеса] как [пользователя] мне нужна [функция].
Цель состоит в том, чтобы сосредоточиться на ценности, которую обеспечивает функция. Это помогает вам думать в вертикальных срезах, что уменьшает чистые "технические задачи", которые не видны. Это непростой переход, но когда вы начинаете мыслить вертикально, вы действительно начинаете сокращать потери в своем процессе.
Другой способ - подумать о приемочных тестах, которые ваш клиент может написать, чтобы убедиться, что эта функция будет работать. Это быстрый переход к использованию чего-то вроде FitNesse для автоматизации этих тестов.
Нет, это на самом деле неочевидно - есть много причин, чтобы захотеть увидеть список, много вещей, которые вы можете захотеть с ним - отсканируйте его для получения некоторой информации, получите обзор, распечатайте его, скопируйте и вставьте в документ Word и т. д. И что именно это даст вам ценные советы по разумным деталям реализации - форматирование списка, точное содержание; или даже намек на то, что для удовлетворения этой потребности лучше использовать другую функцию. Не удивляйтесь, узнав, что причина на самом деле в том, что "я могу посчитать количество записей"...
Конечно, это может на самом деле не относится к вам. На самом деле моя точка зрения заключается в том, что есть причины, по которым люди придумали этот шаблон, а также причины, по которым многие опытные люди на самом деле его не используют. А когда вы новичок в практике, вы не в состоянии оценить все плюсы и минусы следования практике, поэтому я настоятельно рекомендую просто постараться внимательно следовать ей в течение некоторого времени. Вы можете быть удивлены полезностью этого - или нет, и в этом случае вы все же чему-то научились и можете бросить это с ясной лаконичностью...:)
Пользовательские истории - это еще один способ сказать, что вам нужно опросить своих пользователей, чтобы узнать, чего они хотят и какие проблемы они пытаются решить. Это сердце того, чтобы иметь это в гибкой разработке. Если форма не работает для вас, сделайте шаг назад и попробуйте другой подход, который кажется вам более естественным или более подходящим для ваших способностей писателя.
Короче говоря, не думайте, что вы должны быть в смирительной рубашке. Важно то, что вы следуете духу методологии.
В этом конкретном случае вы хотите получить список проблем, с которыми сталкивается пользователь, почему они являются проблемами, и что, по их мнению, поможет им.
Я думаю, что вы действительно должны попытаться определить причину, даже если она может показаться очевидной. Если вы не можете придумать причину, тогда зачем создавать эту функцию? Также причина может указывать на другие недостатки в дизайне, которые могут вызвать улучшения в других областях.
Я часто классифицирую свои истории по пользователю / персоне, к которым это относится в первую очередь, поэтому я не помещаю личность пользователя в название истории. Мои истории также больше, чем предполагают некоторые гибкие методологии. Обычно я начинаю с заголовка. Я использую это для целей планирования. Как только я приблизился к фактической работе над этой историей, я дополню ее некоторыми деталями - основной идеей, ограничениями, предположениями, связанными историями - чтобы собрать больше информации, которую я знаю об этом. Я также храню свои истории в вики, а не на карточках для заметок. Я понимаю компромисс - то есть я могу потратить слишком много времени на детали, прежде чем они мне понадобятся, но я могу легко собирать и делиться ими, как правило, с внешними клиентами.
Суть в том, что Agile - это философия, а не спецификация. Существуют конкретные реализации, которые могут (настоятельно) предполагать, что вы делаете вещи определенным образом, и могут не обсуждаться по некоторым пунктам. Например, трудно сказать, что вы делаете XP, если вы не создаете пару программ. В целом, однако, я бы сказал, что большинство agilists скажут, что вы должны делать то, что работает для вас, так, как они работают для вас - если они соответствуют общим принципам, вы все равно можете позвонить себя проворным Общие принципы включают такие вещи, как ранний выпуск / частый выпуск, модульное тестирование, короткие итерации, признание того, что изменения произойдут, задержка детального планирования до тех пор, пока вы не будете готовы к внедрению,...
Итог для меня: если истории работают для вас без пользователя и обоснования - до тех пор, пока вы понимаете, кто пользователь и почему он чего-то хочет, - делайте это как хотите. Просто не требуйте полной спецификации, прежде чем начать реализацию.