В теме 16 ответов, и 9 участников, последнее обновление сделано пользователем 
Snowball 14 г назад.
-
Сообщения
-
Привет, коллеги.
На agile проектах для оформления требований используются user stories. Используете ли вы US в своей практике?
Вот как я сейчас оформляю US.
Пример.
—————-
The pencil tool allows drawing a free-form line shape. The pencil tool is used the following way:
1. The user clicks the icon on the palette.
2. The icon remains pressed and user draws a free form line in the editor:
a. User can click in any point of the editor and holding the mouse down, drag the cursor to draw a line.
b. User releases the mouse to finish drawing.
3. The user switches back to normal cursor by pressing the button on the palette.
This use case requires an extra icon on the palette — , which will switch the cursor to normal state.Each line is an individual object with all corresponding operation applicable, like copy, cut, paste, drag around the editor.
Mockup
И картинка как это выглядит.
——————
ИМХО это вполне понятное описание и уже несколько итераций по таким вот описаниям уже завершились.У нас на проекте сейчас некое подобие скрама (со своими модификациями) и мы иногда используем нечто похожее, чтобы донести требования до команды. Но это в том случае, если не хватает аналитических ресурсов или поджимает время. Если же время позволяет, мы все-таки отдаем предпочтение более детальному специфицированию.Понятно. Какой формат обычно у юзер стори? и насколько большой скоуп?На торрентах скачал User Stories Applied. Вроде как хорошая книжка. Читаю. Если кому надо — обращайтесь.То, что Вы написали в своем первом посте, мне напоминает не User Stories, а упрорщенный вариант описания Use Case.Как правило, User Storу имеет следущий формат:
Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости]На торрентах скачал User Stories Applied. Вроде как хорошая книжка. Читаю. Если кому надо — обращайтесь.
Брось мне мылом, я выложу в соответствующий раздел. Или залей сам в соответствующую ветку (:
Юра, выложил тут http://analyst.by/forum/tolko-dlya-chlenov/to-chto-est-u-nasЕще хотел бы продолжить по сторисам. У нас на проекте делается так: именуется юзер стори, дается ей краткое описание + обязательно мокап.
Вопрос, как бы вы расписывали поведение юзера в соответствии с функционалом на мокапе?То, что Вы написали в своем первом посте, мне напоминает не User Stories, а упрорщенный вариант описания Use Case.
Как правило, User Storу имеет следущий формат:
[i]Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости][/i]Согласен, этот шаблон всюду приводят. Но что делать если нужно уточнить детали?
Вопрос, как бы вы расписывали поведение юзера в соответствии с функционалом на мокапе?
Ну опять же, все зависит от желаемой степени детализации. Если бы позволяло время, я бы расписал все до единого свойства каждого контрола
Но я так понимаю, что юзер сториз пишутся не от избытка аналитического времени, поэтому, как вариант, на мокапе пометить избранные контролы, допустим, кружочками с нумерацией (критерий — если вы лично считаете, что о данном поведении стоит написать), а где-нибудь вне мокапа уже по этим сноскам расписывать то, что вы хотите.Знаете, я вот только что обратила внимание на эту тему и у меня есть несколько вопросов. Для начала коротко: я работала с agile, а именно scrum, достаточное время, к тому же проходила серьезный профессиональный тренинг по scrum в Калифорнии.
Нам рассказывали и показывали, что из себя должны представлять user stories, чтобы соответствовать самой концепции scum. Craftsman, ни в коему случае не хочу сказать, что вы делаете что-то плохо или не верно, просто это не совсем agile. Вот то, что описал Sergey.Shimansky, существенно ближе к истине.
Чем, собственно, удобны технологии agile: минимум документации, максимум вовлеченности в проект всех его участников, включая заказчика, и минимум менеджмента.
Поэтому User stories в классическом виде выглядят так, как описал Sergey.Shimansky или еще проще. Что-то типа "Хочу, чтобы имелась функция "карандаш", которая будет рисовать линии свободной формы". Все. Дальше, на ежедневынх scum meetings детали оговариваются между прогером и заказчиком в режиме реального времени.
А то, что описано у вас, Craftsman, в качестве user story — это, фактически, test requirement/use case, это уже работа QA.
Но, конечно же, в каждой компании адаптируют методологии под себя, порой, до неузнаваемости.[quote="Sergey.Shimansky"]То, что Вы написали в своем первом посте, мне напоминает не User Stories, а упрорщенный вариант описания Use Case.
Как правило, User Storу имеет следущий формат:
[i]Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости][/i]Согласен, этот шаблон всюду приводят. Но что делать если нужно уточнить детали?[/quote]
Если есть доска, то уточняйте на ней в любой форме. Можно и в виде вашего текстового описания, но хранить его, как уточнение к юзер-стори, а не подменять им юзер стори.
Если разработка ведется в сжатые сроки с минимумом документации, советую также завести эксельку со столбцами — юзер_стори/вопрос /ответ. Поддерживайте её в актуальном состоянии — вопрос задает разработчик, отвечает аналитик. По ней сможете получить актуальное видение, что из себя должен представлять функционал.Если есть доска, то уточняйте на ней в любой форме. Можно и в виде вашего текстового описания, но хранить его, как уточнение к юзер-стори, а не подменять им юзер стори.
Если разработка ведется в сжатые сроки с минимумом документации, советую также завести эксельку со столбцами — юзер_стори/вопрос /ответ. Поддерживайте её в актуальном состоянии — вопрос задает разработчик, отвечает аналитик. По ней сможете получить актуальное видение, что из себя должен представлять функционал.Именно это и предлагают разработчики scrum. Всю историю исправлений, изменений и уточнений хранить нужно в ежедневно обновляемом документе-таблице. Формат его может быть выбран по вашему усмотрению, обычно его вести должен PM, ну а уточнения происходят при общении на ежедневных митингах — PM просто фиксирует в таблице то, о чем договорились члены команды. Это гораздо проще, чем перегружать User stories кучей информации. Идея самой этой штуки в том, чтобы за один взгляд на "карточку" c user story любой мог представить себе, что нужно реализовать, а не как нужно реализовать.
Всем приветСейчас для оформления требований использую User Stories (формат As a <type of user>, I want <some goal> so that <some reason>). Скажите, пожалуйста, чем оформление нефункцианых требований отличается в этом случае?
Привет. Нефункциональные требования можно записать также (добавить к функциональным). Пример: "As a User, I want lists loaded faster than 2 minutes" ("As a Receptionist, I want to see Patients list in no longer than 2 minutes after I have clicked "Patients" button").Я надеюсь, вы не составляете SRS из User Stories? Они не годятся для документов такого уровня конкретизации.
Вы должны авторизироваться для ответа в этой теме.
