Истории пользователей для функциональных требований

Question

Поскольку мы небольшая компания, я работаю как менеджером проекта, так и разработчиком. Спецификации, которые я создаю для клиентов, содержат ряд элементов, используемых для описания и определения проекта, включая рассказы пользователей вместе с любыми другими элементами, которые, как мне кажется, необходимо включить для определения проекта (например, каркасы, пользовательские потоки, файлы Sitemap и т. Д.) Для клиента.

Если функциональная спецификация «описывает, как продукт будет работать полностью с точки зрения пользователя. Меня не волнует, как это реализовано. В нем рассказывается об особенностях ». Тогда кто-нибудь видит какие-либо проблемы с использованием User Stories для определения функциональной спецификации для веб-сайта? Кто-нибудь действительно выполняет функциональные спецификации таким образом?

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

Мне интересно узнать, что люди, которые занимаются проектным менеджментом, профессионально думают об этом.

Answer 1

Я не согласен с тем, что говорили еще несколько человек.

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

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

С точки зрения того, подходит ли он для крупных компаний, я не согласен. По моему опыту (и я делал проекты для Shell, American Express, нескольких многонациональных банков и других), они часто не более формальны, чем более мелкие компании, поэтому им будет хорошо рассказывать истории. Реальность заключается в том, что пользователь в крупной компании не лучше оборудован (или заинтересован) в чтении классов и диаграмм последовательности, чем в других местах.

Размер и сложность проекта могут потребовать более подробные требования, но это размер проекта, а не размер компании, который имеет значение, когда вы определяете, как вы документируете требования.

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

Answer 2

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

Будет ли этот подход работать для более крупных клиентов? Чтобы сделать валовое обобщение, нет. У них будет какая-то система, которая будет использовать для определения требований и, вероятно, ее не рассказы пользователей. Если вы придете с рассказами пользователей, вы будете отключены от текущей практики, с которой вам придется работать.

Я успешно использовал рассказы пользователей с более крупными организациями, но он предпринимает согласованные усилия, на которые обе стороны должны быть привержены.

Answer 3

Что вы описываете, это сценарии использования, которые определяют функции, это то, что требуется с точки зрения удобства использования, и именно то, что клиент будет понимать и соглашаться. Экранные макеты и диаграммы потоков определенно помогут как клиенту, так и разработчикам.

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

Мы также работаем в небольших командах (иногда один или два разработчика) и считаем, что приведенное выше все, что требуется в этом случае.

Крупные компании с гораздо более крупными командами могут использовать программное обеспечение моделирования, диаграммы UML и другие более подробные спецификации. В случае, когда вы являетесь основным разработчиком, вы все равно должны тратить время на разработку своего приложения, но если никто не собирается просматривать проекты и не настаивает на всех формальностях, ваше время лучше потратить на внедрение программного обеспечения.