User stories




В теме 16 ответов, и 9 участников, последнее обновление сделано пользователем Аватар (Snowball) Snowball 6 г, 9 мес. назад.

Показано 15 ответов - от 1 до 15 (всего 17)
  • Автор
    Сообщения
  • 15.08.2010 в 10:37 # 5093
    Аватар (Михаил Сорокин)
    Михаил Сорокин
    Подписчик
    Привет, коллеги.
    На 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
    И картинка как это выглядит.
    ——————
    ИМХО это вполне понятное описание и уже несколько итераций по таким вот описаниям уже завершились.

    Поделиться:

    Цитировать

    15.08.2010 в 13:02 # 5094
    У нас на проекте сейчас некое подобие скрама (со своими модификациями) и мы иногда используем нечто похожее, чтобы донести требования до команды. Но это в том случае, если не хватает аналитических ресурсов или поджимает время. Если же время позволяет, мы все-таки отдаем предпочтение более детальному специфицированию.
    Поделиться:

    Цитировать

    15.08.2010 в 19:19 # 5095
    Аватар (Михаил Сорокин)
    Михаил Сорокин
    Подписчик
    Понятно. Какой формат обычно у юзер стори? и насколько большой скоуп?
    Поделиться:

    Цитировать

    16.08.2010 в 23:18 # 5096
    Аватар (Михаил Сорокин)
    Михаил Сорокин
    Подписчик
    На торрентах скачал User Stories Applied. Вроде как хорошая книжка. Читаю. Если кому надо — обращайтесь.
    Поделиться:

    Цитировать

    17.08.2010 в 08:52 # 5097
    Аватар (Sergey.Shimansky)
    Sergey.Shimansky
    Подписчик
    То, что Вы написали в своем первом посте, мне напоминает не User Stories, а упрорщенный вариант описания Use Case.

    Как правило, User Storу имеет следущий формат:
    Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости]

    Поделиться:

    Цитировать

    17.08.2010 в 20:22 # 5098

    На торрентах скачал User Stories Applied. Вроде как хорошая книжка. Читаю. Если кому надо — обращайтесь.

    Брось мне мылом, я выложу в соответствующий раздел. Или залей сам в соответствующую ветку (:

    Поделиться:

    Цитировать

    26.08.2010 в 21:55 # 5099
    Аватар (Михаил Сорокин)
    Михаил Сорокин
    Подписчик
    26.08.2010 в 21:58 # 5100
    Аватар (Михаил Сорокин)
    Михаил Сорокин
    Подписчик
    Еще хотел бы продолжить по сторисам. У нас на проекте делается так: именуется юзер стори, дается ей краткое описание + обязательно мокап.
    Вопрос, как бы вы расписывали поведение юзера в соответствии с функционалом на мокапе?
    Поделиться:

    Цитировать

    26.08.2010 в 22:01 # 5101
    Аватар (Михаил Сорокин)
    Михаил Сорокин
    Подписчик

    То, что Вы написали в своем первом посте, мне напоминает не User Stories, а упрорщенный вариант описания Use Case.

    Как правило, User Storу имеет следущий формат:
    [i]Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости][/i]

    Согласен, этот шаблон всюду приводят. Но что делать если нужно уточнить детали?

    Поделиться:

    Цитировать

    27.08.2010 в 10:07 # 5102
    Вопрос, как бы вы расписывали поведение юзера в соответствии с функционалом на мокапе?

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

    Поделиться:

    Цитировать

    27.08.2010 в 11:47 # 5103
    Аватар (Виктория Бутич)
    Виктория Бутич
    Участник
    Знаете, я вот только что обратила внимание на эту тему и у меня есть несколько вопросов. Для начала коротко: я работала с 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.
    Но, конечно же, в каждой компании адаптируют методологии под себя, порой, до неузнаваемости.
    Поделиться:

    Цитировать

    27.08.2010 в 12:10 # 5104
    Аватар (Sergey.Shimansky)
    Sergey.Shimansky
    Подписчик

    [quote="Sergey.Shimansky"]То, что Вы написали в своем первом посте, мне напоминает не User Stories, а упрорщенный вариант описания Use Case.

    Как правило, User Storу имеет следущий формат:
    [i]Я, как [название бизнес-роли] хочу иметь возможность [описание возможности], потому что [мотивация необходимости][/i]

    Согласен, этот шаблон всюду приводят. Но что делать если нужно уточнить детали?[/quote]

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

    Поделиться:

    Цитировать

    27.08.2010 в 13:35 # 5105
    Аватар (Виктория Бутич)
    Виктория Бутич
    Участник

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

    Именно это и предлагают разработчики scrum. Всю историю исправлений, изменений и уточнений хранить нужно в ежедневно обновляемом документе-таблице. Формат его может быть выбран по вашему усмотрению, обычно его вести должен PM, ну а уточнения происходят при общении на ежедневных митингах — PM просто фиксирует в таблице то, о чем договорились члены команды. Это гораздо проще, чем перегружать User stories кучей информации. Идея самой этой штуки в том, чтобы за один взгляд на "карточку" c user story любой мог представить себе, что нужно реализовать, а не как нужно реализовать.

    Поделиться:

    Цитировать

    01.11.2010 в 10:38 # 5106
    Аватар (Елена Гунёва)
    Елена Гунёва
    Подписчик
    Всем привет

    Сейчас для оформления требований использую User Stories (формат As a <type of user>, I want <some goal> so that <some reason>). Скажите, пожалуйста, чем оформление нефункцианых требований отличается в этом случае?

    Поделиться:

    Цитировать

    01.11.2010 в 12:21 # 5107
    Аватар (Aliaksei Rudzko)
    Aliaksei Rudzko
    Подписчик
    Привет. Нефункциональные требования можно записать также (добавить к функциональным). Пример: "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? Они не годятся для документов такого уровня конкретизации.

    Поделиться:

    Цитировать

Показано 15 ответов - от 1 до 15 (всего 17)

Вы должны авторизироваться для ответа в этой теме.