Основным принципом современных процессов развития является гибкое развитие . Эта методология разработки основана на использовании небольших пользовательских историй, чтобы определить, что система делает с точки зрения пользователя, а не с технической точки зрения. Пользователь заботится о том, является ли продукт быстрым, простым в использовании и решает ли его проблему. Их не волнует, следует ли она 3-уровневой архитектуре, имеет ли Mongo DB или использует Rails или Asp.net.
Storyboard That идеальная платформа для создания гибких пользовательских историй и разжигания разговоров в формате, который намного дешевле, чем стена текста.
В контексте пользовательских историй «эпическая» - это просто очень широкая история, которая позже будет разбита на множество конкретных пользовательских историй. Начиная с эпопеи, вы получаете единого взгляда высокого уровня. Эпическая история закрепляет проект сверху вниз, и если нет смысла создавать эпическую эпопею, вспомогательная работа также будет пустой тратой усилий.
В этой истории очень ясно, что такое долгосрочное видение и как должен выглядеть успех. Хорошая эпическая история должна включать в себя:
Особенно при разработке программного обеспечения важно иметь четкое представление о том, какими будут пользователи. Не каждый пользователь точно соответствует этому видению, и может быть несколько категорий пользователей, но эти отдельные видения нуждаются в формулировке. Думая о пользователях, вы в первую очередь защищаетесь от чрезмерного проектирования и чрезмерного усложнения, не позволяя новому продукту иметь что-то для всех и быть никому не полезным
После создания эпоса и определения пользователей можно составить более мелкие, более конкретные истории о конкретном пользовательском опыте. Рассказы ниже разбивают изложенное выше на два повествования: поиск заказа и повторный заказ товара.
Эти рассказы не содержат технической информации; Пользователям все равно, как достигаются результаты, пока они выполняют желаемые задачи. Точно так же UX изображен в общих чертах, чтобы избежать подавления инноваций или форсирования пути. В общем, истории должны быть:
Эти истории должны вызывать беседу и вопросы, такие как:
Совершенно разумно создавать много историй; на самом деле, это следует поощрять. Некоторые из этих историй никогда не будут использованы, но важно увидеть путь, который они выбрали. Этот сборник расскажет о дополнительных требованиях и повлияет на тестирование.
Истории должны провоцировать и информировать дискуссию о том, как программное обеспечение будет тестироваться и какие бизнес-правила должны быть четко определены. Например:
Storyboard That мощный инструмент для создания замечательных пользовательских историй, но он не предназначен для использования в качестве основы для управления проектами. Вот некоторые из наших любимых книг на эту тему.
Просто в месяц за пользователя!
/месяц
счет ежегодно
Ознакомьтесь с остальной частью наших статей и ресурсов для бизнеса!
