Определение пользовательских историй и гибкая разработка
Основным принципом современных процессов разработки является гибкая разработка . Эта методология разработки делает упор на использовании небольших пользовательских историй для определения того, что система делает с точки зрения пользователя, а не с технической точки зрения. Пользователь заботится о том, является ли продукт быстрым, простым в использовании и решает ли его проблему. Их не волнует, следует ли он за трехуровневой архитектурой, имеет ли базу данных Mongo или использует ли он Rails или Asp.net.
Истории пользователей:
- Легко понять, и каждый может принять участие
- Работайте итеративно; их можно и нужно часто менять или дополнять
- Ориентируйте разработчиков, пользователей и бизнес-специалистов на общие цели и ожидания.
- Намного легче читать, чем документы на 400 страницах
Storyboard That представляет собой идеальную платформу для создания гибких пользовательских историй и зажигания разговоров в формате, который гораздо менее утомителен, чем стена текста.
Эпос
В контексте пользовательских историй «эпопея» - это просто очень обширная история, которая позже будет разбита на множество конкретных пользовательских историй. Начиная с эпоса, у всех появляется единое видение высокого уровня. Эпическая история закрепляет проект сверху вниз, и если нет смысла строить эпопею, вспомогательная работа также будет пустой тратой усилий.
В этой истории очень ясно, каково долгосрочное видение и как должен выглядеть успех. Хорошая эпическая история должна включать:
- Настройка или контекст
- Актеры или пользователи
- Цели и задачи
- Мероприятия и события
Определение пользователей
Особенно при разработке программного обеспечения важно иметь хорошее представление о том, какими будут пользователи. Не каждый пользователь будет точно соответствовать этому видению, и может быть несколько категорий пользователей, но эти дискретные видения нуждаются в артикуляции. Думая о пользователях, прежде всего, защититесь от чрезмерной инженерии и чрезмерного усложнения, не позволяя новому продукту иметь что-то для всех и никому не быть полезным.
Создание истории
После создания эпика и определения пользователей можно создавать более мелкие и более конкретные истории о конкретном пользовательском опыте. Приведенные ниже истории разбивают изложенное выше на две части: поиск заказа и повторный заказ продукта.
Эти описания не содержат технической информации; пользователей не волнует, как будут достигнуты результаты, до тех пор, пока он выполняет желаемые задачи. Точно так же UX изображен в общем, чтобы избежать удушения инноваций или форсирования пути. В целом рассказы должны быть:
- Маленький - до 10 дней работы
- Ценный - после завершения они должны доставить что-то полезное.
- Приблизительно - может дать приблизительную оценку того, сколько усилий требуется.
Поиск заказа
Выполнение повторного заказа
Разговор и планирование тестирования
Эти истории должны побуждать к разговору и задавать вопросы, например:
- Подходят ли эти истории к нашему эпосу?
- Какие еще истории нужно создать?
- Соответствуют ли эти истории тому, что мы знаем о наших пользователях?
Совершенно разумно создавать много историй; фактически, это следует поощрять. Некоторые из этих историй никогда не будут использоваться, но важно видеть путь, который они проложили. Этот сборник рассказов избавит вас от дополнительных требований и проверки влияния.
Истории должны вызывать и информировать дискуссию о том, как программное обеспечение будет тестироваться и какие бизнес-правила необходимо четко определить. Например:
- Насколько быстрым должен быть поиск?
- Есть ли ограничение по времени для повторных заказов?
- Что делать системе, если это второй перезаказ? Пятый?
- Какие тесты и дополнительные вопросы у вас есть?
© 2024 - Clever Prototypes, LLC - Все права защищены.
StoryboardThat является товарным знаком Clever Prototypes , LLC и зарегистрирован в Бюро по патентам и товарным знакам США.