Вопросы о дистанционном обучении? Кликните сюда

Определение пользовательских историй и гибкой разработки

Основным принципом современных процессов развития является гибкое развитие . Эта методология разработки основана на использовании небольших пользовательских историй, чтобы определить, что система делает с точки зрения пользователя, а не с технической точки зрения. Пользователь заботится о том, является ли продукт быстрым, простым в использовании и решает ли его проблему. Их не волнует, следует ли она 3-уровневой архитектуре, имеет ли Mongo DB или использует Rails или Asp.net.

Пользовательские истории:

• Легко понять, и каждый может принять участие
• Работать итеративно; они могут и должны часто изменяться или дополняться
• Совместите разработчиков, пользователей и бизнес-специалистов с общими целями и ожиданиями
• Намного легче читать, чем документы на 400 страниц

Storyboard That идеальная платформа для создания гибких пользовательских историй и разжигания разговоров в формате, который намного дешевле, чем стена текста.

эпический

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

Обслуживание Клиентов Generic Epic

Настройте этот пример*

Больше опций

Начните мою бесплатную пробную версию

В этой истории очень ясно, что такое долгосрочное видение и как должен выглядеть успех. Хорошая эпическая история должна включать в себя:

• Настройка или контекст
• Актеры или пользователи
• Цели и задачи
• Мероприятия и события

Определение пользователей

Особенно при разработке программного обеспечения важно иметь четкое представление о том, какими будут пользователи. Не каждый пользователь точно соответствует этому видению, и может быть несколько категорий пользователей, но эти отдельные видения нуждаются в формулировке. Думая о пользователях, вы в первую очередь защищаетесь от чрезмерного проектирования и чрезмерного усложнения, не позволяя новому продукту иметь что-то для всех и быть никому не полезным

Пользователи Acme Corp.

Настройте этот пример*

Больше опций

Начните мою бесплатную пробную версию

Создание истории

После создания эпоса и определения пользователей можно составить более мелкие, более конкретные истории о конкретном пользовательском опыте. Рассказы ниже разбивают изложенное выше на два повествования: поиск заказа и повторный заказ товара.

Эти рассказы не содержат технической информации; Пользователям все равно, как достигаются результаты, пока они выполняют желаемые задачи. Точно так же UX изображен в общих чертах, чтобы избежать подавления инноваций или форсирования пути. В общем, истории должны быть:

• Маленький - до 10 дней работы
• Ценный - После завершения они должны доставить что-то полезное
• Estimable - возможность создать приблизительную оценку того, сколько усилий требуется

Поиск заказа

Acme Corp. - Поиск Заказа

Настройте этот пример*

Больше опций

Начните мою бесплатную пробную версию

Выполнение повторного заказа

Acme Corp. Заказ на Замену

Настройте этот пример*

Больше опций

Начните мою бесплатную пробную версию

Разговор и планирование для тестирования

Эти истории должны вызывать беседу и вопросы, такие как:

• Это правильные истории, чтобы соответствовать нашему эпосу?
• Какие еще истории должны быть созданы?
• Соответствуют ли эти истории тому, что мы знаем о наших пользователях?

Совершенно разумно создавать много историй; на самом деле, это следует поощрять. Некоторые из этих историй никогда не будут использованы, но важно увидеть путь, который они выбрали. Этот сборник расскажет о дополнительных требованиях и повлияет на тестирование.

Истории должны провоцировать и информировать дискуссию о том, как программное обеспечение будет тестироваться и какие бизнес-правила должны быть четко определены. Например:

• Как быстро должен быть поиск?
• Есть ли ограничения по времени для повторных заказов?
• Что должна делать система, если это второй повторный заказ? В-пятых?
• Какие тесты и дополнительные вопросы у вас будут?

Дальнейшее чтение

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

Купить User Stories Applied: For Agile Software Development на Amazon

Купить Agile in a Flash: Speed-Learning Agile Software Development by Jeff Langr на Amazon

Купить Understanding Comics: The Invisible Art by Scott McCloud на Amazon