Написание пользовательских историй для внутренних технических задач [закрыто]

Question

Я пытаюсь управлять своими проектами немного лучше, поэтому я рассматриваю попытку применить некоторые (в конечном итоге все) функции схватка.

Глядя на истории пользователей в частности, высокоуровневый формат, по-видимому, является:

В качестве Пользователь Я могу Описание функции

или

Артефакт является Делать Что-то

Как бы я написал "Обновить базу данных"?

Это просто обновление базы данных?

Я думаю, что меня сбивают с толку, поскольку нет конкретного исполнителя / заказчика и что заказчиком является ИТ-отдел.

Answer 1

AS A [person/role]
I NEED TO [do something] 
SO THAT [provides business value]. 

Для вашего примера пользовательская история может выглядеть так:

AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.

Я добавил критерии приемки, потому что без них вы никогда не узнаете, когда работа будет завершена.Теперь у вас есть экономическое обоснование обновления базы данных.Эту историю можно разложить на историю, в которой ролью является ИТ-отдел или администратор базы данных, например:

AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db

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

Вот пара статей, в которых говорится о декомпозиции историй:

http://jpattonassociates.com/the_shrinking_story/

http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf

Answer 2

Scrum не является очень предписывающим, и существует ничего в Scrum, который заставляет вас использовать пользовательские истории для элементов бэклога продукта (PBI).Вы определенно можете использовать Scrum, не фиксируя требования/функции в виде пользовательских историй, пользовательские истории — лишь один из способов сделать это.На самом деле истории работают для многих команд, особенно для команд веб-разработчиков, но это не означает, что они работают во всех случаях и в каждом проекте (многие проекты являются веб-разработкой, но не все, как в вашем случае).Единого мнения по поводу использования историй нет.

Тем не менее, рекомендуемый шаблон для пользовательских историй на самом деле Как <роль>, я хочу выполнить <действие>, чтобы <преимущества>.Я не хочу быть придирчивым, но если вы решите использовать истории, я бы горячо предложил использовать их как есть, не удаляя ни одной части.Во-первых, используя роль помогите (один и тот же пользователь/человек может иметь несколько ролей) находить истории.Затем указав преимущества действительно важно раскрыть деловую ценность истории, чтобы правильно расставить приоритеты.Что касается ценности, вы должны думать о ней как о конечном пользователе/клиенте («надеть очки клиента«-Мэри Поппендик).На самом деле не всегда так легко выразить преимущества, но некоторые инструменты могут помочь, и я предпочитаю один из них. 5 почему (который используется для анализа первопричин).

В вашем случае это может привести к чему-то вроде:Как ИТ-отдел, я хочу, чтобы база данных была обновлена, чтобы пользователи могли воспользоваться новейшими функциями приложения и [работать лучше | иметь лучший пользовательский опыт] (хотя это не очень приятно, используйте 5 «почему»).

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

Answer 3

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

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

Пользовательские истории сформулированы таким образом, чтобы гарантировать, что любая работа каким-то образом принесет прямую пользу конечному пользователю.

Answer 4

Это выходит на передний план, почему пользовательские истории так хороши.

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

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

tl;dr Не делайте обновление просто ради этого.Убедитесь, что обновление приносит ощутимую пользу вашим клиентам.

Answer 5

Как правило, технические задачи в ПБ не одобряются, поскольку они очень редко напрямую обеспечить ценность бизнеса для клиента.Вот почему пользовательские истории так популярны: они заставляют вас задуматься о деловой ценности истории и о том, кому она доставляется.

Итак, почему вы обновляете базу данных?Можете ли вы определить ценность ее обновления для бизнеса и почему Владелец продукта должен согласиться позволить вам обновить базу данных вместо создания новых функций?

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

Не потому ли, что производитель базы данных отрезал от поддержки старую версию?В этом случае вы можете использовать обновление в качестве истории;что-то вроде: «Как руководитель отдела я хочу быть уверен, что у нас есть поддержка всего программного обеспечения, чтобы непрерывность бизнеса не подвергалась риску, если что-то пойдет не так».Хотя даже это напрягает.Как правило, такого рода причины на самом деле не являются частью проекта, если только проект не продолжается настолько долго, что системное программное обеспечение прекращает поддержку.

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

Это по какой-то чисто технической причине?Если вы не можете определить, какую пользу обновление принесет бизнесу, то зачем вам это делать?Почему Владелец Продукта выбрал его для Спринта?

Answer 6

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

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

OTOH, если проект более сложный, это может стать "тегом", вроде уведомления о публикации, которое должно быть прикреплено ко многим историям.Это означает, что вы должны включить это как "вспомогательную историю" во все истории, которые изменяют базу данных.Как вы можете видеть, эти "истории, охватывающие весь проект", немного сложно отследить с помощью гибких методов.

Answer 7

Истории об инфраструктуре не обязательно должны соответствовать установленному шаблону истории.Просто запишите, что нужно сделать, и соответственно оцените

Answer 8

Как насчет:

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

Вы могли бы даже сформулировать рефакторинг так:

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

1. Кому выгодно
2. Что ты хочешь делать
3. В чем преимущество

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