Мне удобнее описывать требования техническими терминами. Так можно ли не использовать пользовательские истории в Scrum? Будет ли это по-прежнему Agile?
Конечно вы можете! Scrum не предписывает, какое конкретное представление требований вы должны использовать. В Scrum Guide вообще нет такого термина, как «пользовательская история». Руководство по Scrum вместо этого использует « Элемент невыполненной работы по продукту ».
Руководство по Scrum накладывает три ограничения на четко определенный (или «уточненный» в терминологии Scrum) PBI:
Таким образом, теоретически PBI может быть любым видом представления требований.
Основная причина, по которой используется User Story: она больше ориентирована на клиента .
Но если вы являетесь владельцем продукта и у вас нет проблем с общением с заинтересованными сторонами, вы можете свободно работать с таким представлением требований, какое хотите.
Наконец, цитата из Scrum Primer :
Элементы Бэклога Продукта формулируются любым ясным и устойчивым способом. Вопреки распространенному заблуждению, Бэклог Продукта не содержит «пользовательских историй»; он просто содержит элементы. Эти элементы могут быть выражены в виде пользовательских историй, вариантов использования или любого другого подхода к требованиям, который группа считает полезным. Но каким бы ни был подход, большинство товаров должно быть направлено на создание ценности для клиентов.
Таким образом, если ваши заинтересованные стороны не возражают, проблем не возникнет, даже если вы будете использовать требования «стиля SRS» (например, фразы «система должна...»).
Наличие пользовательской истории играет центральную роль в формировании скрам-команды. Технически я бы сказал, что вы не «устраиваете схватку». Тем не менее, это может быть Agile, если это работает для вашей команды и вашего клиента...
Решение о том, использовать ли пользовательские истории или нет, не должно основываться на удобстве для вас, оно должно основываться на том, что нужно команде для достижения успеха и что необходимо сделать, чтобы клиент получил приращение качественного продукта в конце периода. итерация.
Если команда может достаточно нестандартно мыслить (и понимать бизнес-ценность рабочего элемента, который вы документируете), чтобы решить и создать что-то для клиента в итерации без формальной пользовательской истории... тогда действуйте. Если вы пишете детали реализации для своей команды, а они чувствуют себя «обезьянами кода», то вы лишаете цели использования Scrum и даете команде возможность предоставлять дополнительную ценность для клиента.
Технически нет, в соответствии с принципом 1-го Agile-манифеста [«Наш наивысший приоритет — удовлетворить клиента за счет своевременной и непрерывной поставки ценного программного обеспечения».] [1], поскольку технические требования объясняют только детали реализации, развертывания, обслуживания, а не деловую ценность, которую они привносят в продукт.
В соответствии с тем, о чем вы говорите, необходимы только технические требования, это либо самоочевидная конкретная задача, либо эти требования не являются чисто техническими и по-прежнему содержат объяснение цели, которой они служат, т . Е. Ценность для бизнеса . Поскольку ценность для бизнеса заключается в прибыли, которую Пользователь получает от использования этого Продукта и этой Функции, а не чего-либо еще (например, Пользователь может сэкономить/заработать деньги, обожать пользовательский интерфейс или получить набор функций, удовлетворяющий его первостепенные потребности, когда никакие другие приложения не могут этого сделать, и т.д.).
Интересный вопрос. Жаль, что раньше не видел - заставляет вспомнить, что бизнес-ценность сочетается и функциональная, и техническая, а разделение функциональных требований и технических требований придумано только для удобства и простоты.
Юэн
Станислав Башкирцев