Может ли Scrum использовать технические спецификации в журнале продуктов, а не в пользовательских историях?

В компании, в которой я сейчас работаю, мы начали делать Scrum-проекты. Было не так сложно убедить менеджеров перейти от водопада к Scrum. Мы делаем проект, в котором мы перестраиваем нашу платформу с нуля. Таким образом, (большинство) функциональность известна, и большинство улучшений являются скорее техническими.

В этом может быть оправдано наличие технических задач, а не пользовательских историй. Наше отставание имеет все виды технических задач, таких как:

• Переписать класс БД из MySQL в PostgreSQL.
• Внедрить систему ведения журнала.
• Переписать объектный кеш.

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

Как Scrum Master должен справиться с этим? Может ли быть так, что для такого проекта Scrum НЕ подходит?

TL; DR

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

Различные проблемы с вашим процессом

Ваш Скрам, кажется, сломан различными способами, включая:

1. В ваших спецификациях отсутствует четкая точка зрения или ценностное предложение.
2. Ваши позиции в бэклоге не привязаны к целям спринта.
3. Ваш процесс устранения отставания либо полностью отсутствует, либо не может создать всплески истории для журнала невыполненных работ.
4. В процессе планирования Sprint не выполняется адекватная декомпозиция элементов журнала невыполненных работ продуктов в элементы журнала незавершенного производства.
5. Ваша команда неправильно учитывает неопределенность в отношении элементов невыполненных работ в своих оценках планирования спринта.
6. Ваша команда не соблюдает основы тайм-бокса или целостности спринта.

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

Почему проворные программисты принимают истории пользователей

Технические спецификации - принципиально сломанный способ сообщить о требованиях. Требования, которые не привязаны с точки зрения, не дают никаких полезных рекомендаций для разработчиков. Используя ваши опубликованные примеры:

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

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

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

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

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

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

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

Scrum говорит, что вам лучше иметь продукт для вашего клиента. Тем не менее, дело здесь в том, что он не определяет доставляемый продукт и клиента .

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

Это имеет 100% смысл для меня. Вы создаете задел, который рассказывает истории пользователей ваших продуктов, и кто является пользователем? Технический менеджер. Таким образом, такие предметы, как:

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

А то, что вы предоставляете своему клиенту (техническому менеджеру), представляет собой систему регистрации.

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

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

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

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

Некоторые из приведенных ниже стратегий могут помочь,

1. Да, вы можете иметь отставание с техническими историями .

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

2. Для исследовательских (исследовательских) задач используйте Spike

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