Я пытаюсь немного улучшить свои проекты, поэтому я пытаюсь применить некоторые (в конечном итоге все) функции scrum.
Глядя на пользовательские истории, в частности, формат высокого уровня выглядит следующим образом:
Как Пользователь я могу Описание функции
или
Артефакт - Выполнение чего-то
Как мне написать "Обновить базу данных"?
Это просто обновить базу данных?
Я думаю, что меня отбрасывают, поскольку нет конкретного актера/клиента и что клиент является ИТ-отделом.
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
Если вы добавите декомпозицию истории в свой блок инструментов, вы всегда начинаете с истории, в которой пользователь является реальной частью бизнеса, а "так, чтобы" приводило к реальной стоимости бизнеса. Затем разложите его на одну или несколько историй, в которых внутренние пользователи делают что-то "так, что" эти реальные пользователи получают преимущества, которые они просили.
Вот несколько статей, в которых говорится о разложении Story:
http://jpattonassociates.com/the_shrinking_story/
http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf
Scrum не очень предписывающий, и в Scrum есть nothing, который заставляет вас использовать Истории пользователей для ваших товаров (PBI). Вы можете определенно сделать Scrum без учета требований/функций как рассказов пользователей, рассказы пользователей - всего лишь один из способов сделать это. На самом деле, истории работают для многих команд, особенно для веб-разработчиков, но это не значит, что они работают во всех случаях и в каждом проекте (многие проекты - это веб-разработка, но не все, как в вашем случае). Консенсуса относительно использования историй нет.
Тем не менее, рекомендуемый шаблон для User Stories на самом деле Как <role> , я хочу <action> так что < выгоды > . Я не хочу быть придирчивым, но если вы решите использовать рассказы, я бы тепло предложил использовать его как есть, не удаляя какую-либо часть. Во-первых, использование роли помогает (один и тот же пользователь/человек может иметь несколько ролей) для поиска историй. Затем определение преимуществ действительно важно, чтобы показать ценность бизнеса в истории, чтобы правильно определить приоритеты. Что касается ценности, вы должны думать об этом как о конечных пользователях/клиентах ( "наденьте очки для клиентов" - Mary Poppendieck). На самом деле не всегда легко выразить свои преимущества, но некоторые инструменты могут помочь, и мой предпочтительный вариант - 5 whys (который используется для root анализ причин).
В вашем случае это может привести к чему-то вроде: Как ИТ-отдел, я хочу, чтобы база данных была обновлена, чтобы пользователи могли воспользоваться последними функциями приложения и [улучшить качество работы | ] (не очень удовлетворительно, но используйте 5 whys).
Но лично я не нахожу, что истории пользователей являются наилучшим средством для технических задач, даже если это явно возможно для их использования, и если у них есть свои сильные стороны. Теоретически, истории затрагивают суть, а не детали и должны быть поддержкой для обсуждения. Возможно, я ошибаюсь, но я не считаю, что технические задачи дают много возможностей для обсуждения и творчества. Итак, в зависимости от того, кто их прочтет, что я должен передать, я могу использовать их или нет. Другим вариантом может быть смешение историй с другим формализмом для ваших PBI. Как я уже сказал, дело не в использовании историй, а в том, чтобы иметь список приоритетных и оцененных элементов.
Обновление базы данных может быть одной из задач, связанных с реализацией другой истории, которая приносит прямое значение пользователю, например, я, поскольку пользователь может добавить новый foo в мою панель.
Если добавление foo в панель требует обновления базы данных за кулисами, вы должны включить эту работу в реализацию этой истории пользователя.
Истории пользователей сформулированы таким образом, чтобы гарантировать, что любая работа напрямую приносит пользу конечному пользователю.
Как правило, технические задачи в PB недоверчивы, потому что они очень редко напрямую предоставляют бизнес-ценность клиенту. Вот почему популярны User Stories, потому что они заставляют вас думать о бизнес-ценности истории и о том, кому она доставляется.
Итак, почему вы обновляете базу данных? Можете ли вы определить ценность бизнеса при его обновлении и почему владелец продукта соглашается разрешить вам обновлять базу данных вместо создания новых функций?
Это из-за новой функции, которая позволит сделать это или сделать что-то проще в вашем приложении? В этом случае это должен быть элемент PB, и обновление базы данных должно быть задачей в этой истории. Если у вас уже есть истории на PB, которые выиграют от обновления, тогда вы должны увеличить оценки для одной или нескольких из этих историй и добавить обновление в качестве технической задачи в историю.
Это потому, что поставщик базы данных отключает старую версию от поддержки? В этом случае вы могли бы обновить версию; что-то вроде: "Как менеджер отдела, я хочу быть уверенным, что мы поддерживаем все программное обеспечение, чтобы преемственность бизнеса не подвергалась риску, если что-то пошло не так". Тем не менее, это толкает его. Как правило, такая причина не является частью проекта, если проект не продолжается так долго, что системное программное обеспечение отключается от поддержки.
Это для производительности? Тогда рассказ должен быть о каком-то аспекте производительности приложения, которое необходимо улучшить, чтобы повысить ценность бизнеса. Что-то вроде: "Как CSR мне нужно получить информацию о клиентах в разумные сроки, чтобы клиенты по телефону остались довольны нашим сервисом". Затем обновление становится задачей под этой историей.
Это по какой-то совершенно технической причине? Если вы не можете определить, как обновление будет доставлять бизнес-ценность, то зачем вам это делать? Зачем владельцу продукта выбрать его для Sprint?
Это выходит на первый план, почему истории пользователей настолько велики.
Какая польза от обновления базы данных для конечного пользователя? Никто? Тогда не тратьте время и деньги на это. Потратьте это время и деньги на то, что даст ценность вашему конечному пользователю.
Если это так? Тогда подумайте об этом по-другому. Может быть, вы можете реализовать только новую функцию, когда у вас есть версия x вашего программного обеспечения базы данных? В зависимости от истории вы можете указать, что обновление базы данных необходимо для обеспечения этой функции.
tl; dr Не просто обновляйся ради него. Убедитесь, что обновление добавляет ощутимую ценность вашим клиентам.
Просто "Обновление базы данных" или "Когда установлена новая версия, должен быть способ миграции существующей базы данных". Если вы уже знаете более подробную информацию об этом шаге, включите их. Но история в основном существует, чтобы убедиться, что что-то не забыто; он не будет подробным.
Позже, когда вы начнете реализовывать эту историю, вы можете ее реализовать (в каких таблицах нам нужна одна или несколько резервных копий, есть ли сценарий возврата и т.д.).
OTOH, если проект более сложный, это может стать "тегом", например, уведомлением по почте, которое должно быть привязано ко многим рассказам. Это означает, что вы должны включить это как "сюжет" во все истории, которые меняют базу данных. Как вы можете видеть, эти "проектные истории" немного сложно отслеживать с помощью гибких методов.
Инфраструктурные истории не должны следовать установленному шаблону истории. Просто напишите, что нужно сделать и оцените соответственно.
Как насчет:
Как специалист по поддержке приложений, я хочу быть в последней версии базы данных, потому что он более надежный/более безопасный/любой.
Вы можете даже перефразировать так:
Как разработчик разработчиков, я хочу, чтобы все классы данных в одном модуле, чтобы я мог быстро добавлять новые приложения в приложение.
В идеале вы не хотите, чтобы все истории были разработчиками, но некоторые из них имеют смысл (заточение вашего топора вместо вырубки деревьев и всего этого).