Схватка:Технические элементы в отставании, которым управляет нетехнический заказчик?[закрыто]

Question

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

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

Answer 1

Я добился успеха с помощью подхода с двойным отставанием:

1. Невыполненная работа по продукту принадлежит владельцу продукта.Он содержит элементы (функции) уровня истории, которые оцениваются командой, а затем расставляются владельцем продукта по приоритетам.Этот процесс оценки разбивает истории на более мелкие задачи.

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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