Я очень привык к пользовательским историям для функций, управляемых конечным пользователем. Но если начинать проект с нуля, имеет ли смысл относиться к владельцам бизнеса как к пользователям и так же определять их потребности? Некоторые примеры
As a Business Owner
I want regular database backups
So that we can maintain business continuity
As a Business Owner
I want end-user analytics
So that we can know how our platform is being used
As a Business Owner
I want end-user authentication
So that only registered users have access
Подобные вещи, очевидно, являются функциями, которые должна создавать команда разработчиков/разработчиков, но на самом деле они не ориентированы на конечных пользователей в традиционном смысле, который я думаю о пользовательских историях. Мысли?
Термин «пользователь» в пользовательских историях часто лучше понимается как действующее лицо или роль в сценарии использования или даже просто как потребитель ценности . Основная цель иметь четко определенную роль в пользовательской истории — сформулировать историю таким образом, чтобы ограничить масштаб. Второстепенная цель — убедиться, что пользовательская история рассматривается как заполнитель для совместной работы, а не как суррогатная спецификация. С идентифицированным потребителем истории команде становится намного легче узнать, с кем поговорить о деталях реализации или критериях приемлемости.
Короче говоря, с чисто прагматической точки зрения в ваших историях нет ничего плохого. Однако они могут быть лучше, если вы используете «пользователя» в формате истории для улучшения контекста и совместной работы.
Хотя ваши истории, скорее всего, и так полезны, вы можете улучшить их, улучшив структуру и создав возможности для совместной работы. Давайте посмотрим на пример.
Используя цели, изложенные выше, вы можете переписать свой первый рассказ следующим образом:
Как администратор базы данных,
я хочу, чтобы база данных могла быть восстановлена в течение 4 часов
, чтобы мы могли достичь наших целей по обеспечению непрерывности бизнеса.
Эта история, вероятно, будет лучше оригинала, потому что:
Другие ваши истории также выиграют от подобной обработки. Определенно стоит потратить немного больше времени на то, чтобы найти нужных соавторов для основной истории, а также на достаточный контекст, чтобы убедиться, что команда создает правильную вещь .
Если есть несколько ролей или улучшений функций, и одна история не охватывает (или, возможно, не может) их все, вам часто лучше выбрать базовый вариант использования, а затем повторить его. Вот что такое итеративная разработка! Если вы используете пользовательские истории, вы в любом случае должны улучшать свои функции итеративно , постепенно и эмпирически . Применяя интерактивный подход, вы можете сосредоточиться на выполнении функций точно в срок и с «достаточно хорошим» уровнем качества, а не пытаться разработать сложное решение с большими усилиями по предварительному планированию, которые обычно чрезмерно ограничивают пространство решений бесполезно.
Когда все сделано правильно, пользовательские истории — это не просто другой способ описания старомодных спецификаций. Они представляют другую парадигму, основанную на сотрудничестве и эмпирическом контроле, и требуют принципиально иного подхода к проблемной области.
Используйте пользовательские истории в качестве начала разговора и стенографические заметки для поддержки совместной работы. Не пишите подробные истории о вещах, которые в данный момент не входят в область (YAGNI), но потратьте время на декомпозицию и определение действительно важных вещей во время уточнения невыполненной работы и планирования спринта. Когда данная функция, наконец, станет частью целостной Цели Спринта, станет гораздо более очевидным, имеете ли вы право на то, кто и что в ваших историях, и это, в свою очередь, станет лучшим руководством для Команды Разработки, когда они будут работать. о том , как это реализовать во время текущего Спринта!
Добро пожаловать в ПМ.
Один из самых влиятельных людей в этом мире (управления проектами), Майк Кон, написал об этом статью еще в 2015 году, которую вы обязательно должны прочитать, под названием Not Everything Need to Be a User Story: Using FDD Features . Некоторые из его статей использовались, чтобы дать хорошие ответы на вопросы в этом сообществе, и это также подходит вам.
В названии статьи упоминается авторское решение для таких случаев, когда пользователь находится слишком далеко — Feature-Driven Development (FDD) .
Как пишет автор
Функция FDD записывается в следующем формате:
[action] the [result] [by|for|of|to] a(n) [object]В качестве примеров рассмотрим следующие:
- Оцените цену закрытия акции
- Генерация уникального идентификатора транзакции
- Изменить текст, отображаемый в киоске
- Объединить данные для повторяющихся транзакций
У вас уже есть несколько отличных ответов, но я просто хочу кое-что добавить. Вы говорите, что ваши истории:
на самом деле не ориентированы на конечного пользователя в традиционном смысле
Я не уверен, что это относится ко всем историям, которые вы перечисляете.
Например:
Как владелец бизнеса, я хочу регулярно делать резервные копии базы данных, чтобы мы могли поддерживать непрерывность бизнеса.
Да, это важно для владельца бизнеса, но это связано с тем, какое влияние это окажет на конечных пользователей.
Вы можете переписать его как-то так:
Как конечный пользователь, я хочу быть уверен, что мои данные защищены, чтобы я не потерял доступ к продукту и не должен был повторно вводить свои данные.
Аналогично для:
Как владелец бизнеса я хочу аутентификацию конечного пользователя, чтобы только зарегистрированные пользователи имели доступ
Вашим конечным пользователям также нужен безопасный сервис. Возможно, это можно было бы переписать как:
Как конечный пользователь, я хочу быть уверен, что моя учетная запись защищена, чтобы никто другой не мог получить доступ к моей информации или внести несанкционированные изменения.
Пользовательские истории — это инструмент для понимания и удовлетворения потребностей пользователей. Я мог бы изменить это последнее, чтобы сказать: «Как платный пользователь, я хочу, чтобы мои логины были защищены, чтобы с меня не взимали плату за несанкционированное использование моей учетной записи».
Существуют и другие механизмы, такие как определение готовности, для таких вопросов качества, как доступность, тестирование и т. д.
Кроме того, Scrum не требует использования пользовательских историй, поэтому, если вы хотите добавить возможность восстановления (на чем я бы сосредоточился по сравнению с самим резервным копированием), вам не нужно использовать пользовательскую историю, чтобы добавить это в бэклог.
пользователь 253751