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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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