Scrum: Технические вопросы в отставании, которые управляются нетехническим ПО?

Должны ли технические элементы, такие как "Модернизация от версии с v1 до v2" или "Увеличение производительности запуска" или "Модуль входа в систему Refactor для снижения сложности кода", относятся к отставанию продукта, и если да, то каким образом должен быть обладатель нетехнического продукта для определения приоритетов в сравнении с другими более функциональными элементами отставания?

Должно ли быть отдельное отставание для технических материалов? Должна ли быть совместная роль РО с двумя лицами, которые могли бы отнести приоритет функциональным и техническим материалам в отставании продукта?

Ответ 1

У меня был успех с двойным отставанием:

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

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

Ответ 2

Обычно в 'vanilla' SCRUM технические задачи, о которых вы упомянули, не станут отдельными историями.

Мне нетехническое ПО не следует рассматривать такие истории, как "Обновление сервера". Это не бизнес-история, она не видна конечному пользователю, поэтому трудно определить приоритеты, если она сформулирована таким образом. Приоритеты должны быть назначены в соответствии с деловой стоимостью работы. "Модернизация" не означает многого. "Разрешение одновременных подключений", "Сокращение времени простоя" или даже "повышение скорости команды" может обеспечить гораздо более ценную информацию для нетехнического человека. Если вы не можете найти нетехническое описание, задайте себе вопрос о необходимости обновления:)

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

Я бы предложил сделать "обновления" в качестве всплеска с "улучшением производительности" и "повторным фактором", являющимся задачами для соответствующей бизнес-истории.

P.S. Вы можете найти хорошую дискуссию по этой теме (в основном в третьей части этого) в превосходной книге Майка Кон, названной " Пользовательские истории, используемые: для разработки Agile Software".

Ответ 3

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

Я действительно думаю, что есть внутренние истории, связанные со скоростью/возможностями команды, которым иногда удобнее управлять, назначая некоторую способность разработчикам, особенно когда Владелец Продукта не заинтересован в расстановке приоритетов или управлении этими историями. Например. назначить 10% -ную емкость для тестирования отставания в автоматизации (устаревшей регрессии), установки сервера CI и т.д.

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