Я знаю, что владелец продукта должен написать историю пользователя в Scrum.

Пользовательская история описывает функцию для конечного пользователя.

Но кто описывает, что должно быть технически разработано и как это должно быть реализовано?

и где хранится эта информация относительно scrum?

Это действительно заинтересовало бы меня!

Я вижу большой недостаток знаний в нашей компании, когда разработчики начинают реализовывать историю, но они не знают, КАК ее реализовать!

Например, им приходится иметь дело с унаследованным COM-API и они не знают, как с ним работать, или они не обладают техническими навыками в WPF / WEB или чем-то еще.

Как скрам помогает людям начать с истории пользователя?

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

As a non-technical user, I need to have a simpler interface with the API

В то время как владелец продукта определяет, какие пользовательские истории имеют наивысший приоритет, программисты берут эти приоритеты и превращают их в список задач (так называемое отставание спринта). Именно здесь вы получаете представление о том, как вы собираетесь реализовывать вещи ... Журнал спринта может быть настолько техническим, насколько вам угодно. Здесь вы также узнаете, что «для создания более простого API нам придется реорганизовать этот сумасшедший COM API. Кто-нибудь знает, как его использовать?». Когда ответ - «Нет ада», вы начнете видеть, что область действия этой пользовательской истории может быть больше, чем кажется. Учитывая это, вы должны разбить пользовательскую историю на задачи:

• Документирование и понимание текущего API
• Разработка нового API
• Внедрить новый API
• Без разницы...

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

Краткий ответ

Команда разработчиков пишет технические вещи. Скрам помогает вам немного, но не сильно с технической поломкой, соотв. Начало работы с историей пользователя. Скрам - это почти что-мир-только . Техническая неисправность - How-World .

Разбивка, предоставляемая Scrum:

• История пользователя -> Критерии принятия

Разбивка, которую люди часто используют поверх этого:

• Epic -> Истории пользователей
• История пользователя -> Подзадачи
• Критерии приемки -> Приемочные испытания

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

Для получения дальнейших рекомендаций о том, как разбивать работу, обратите внимание на XP (Extreme Programming), Чистый код , Прагматическое программирование , Разработка программного обеспечения , CRC-карты , OOP / OOA / OOD , Шаблоны проектирования , Рефакторинг , Эффективная работа с устаревшим кодом , TDD ( Разработка через тестирование), BDD (разработка, ориентированная на поведение), ATDD (разработка через тестирование , основанное на приеме).

Длинный ответ

Как думает Scrum

Что-Мир и Как-Мир

Существует Что-World и How-World . Как вы правильно поняли, пользовательская история предназначена для пользователей , которые генерируют бизнес-ценность, то есть вторичную ценность в мире « что» . Scrum - это в основном только What-World. Это мало что говорит о How-World , в основном не более, чем «How-World - это ответственность Dev-Team».

История пользователя против задачи

Обычно элементы журнала невыполненных работ, относящиеся к How-World, называются не пользовательской историей, а технической задачей или подзадачей . Многие инструменты позволяют разбить Пользовательскую Историю из « Что-Мир» на подзадачи в « Как-Мир» .

Как Scrum помогает и где эта помощь заканчивается

Помощь Scrum для How-World заканчивается в нескольких моментах встречи по планированию спринта :

• [Встреча по планированию спринта] Команда обнаруживает неправильное понимание истории, если разные товарищи по команде придумывают разные оценки Story Point во время Planning Poker -> Discussion.
• [Определение готовности] Команда не принимает слишком большие пользовательские истории (слишком много очков истории). Практическое правило, которое можно найти во многих определениях готовности, гласит , что очки истории должны быть меньше половины скорости команды.
• [Определение готовности] Команда не принимает пользовательские истории без достаточного описания критериев принятия. Критерии приемки достаточны, если у команды достаточно уверенности в том, как начать писать приемочные тесты.

Несколько советов по уровню Scrum

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

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

И не делайте «(Архитектура | Дизайн | Реализация | Тестирование) функции X» в качестве пользовательских историй. Я рекомендую вам даже попытаться избежать этого в качестве подзадачи.

Если у меня есть Атомные пользовательские истории, и мне кажется, что они нуждаются в дальнейшей разбивке помимо критериев принятия, то для меня это означает, что что-то не работает на оптимальном уровне. Либо архитектура неправильная / слишком сложная, то есть техническая, а не бизнес-ориентированная. Или команда неопытная. Или оба. В любом случае потребуются действия для улучшения ситуации путем обучения и распространения знаний.

Вне Scrum

Скрам Мастер за Скрамом

Сегодня Scrum Master в основном понимается как управленческая роль , и это чушь собачья. Первоначально Scrum Master был, и я защищаю это, Технической ролью, а не управленческой ролью, как тренер в XP .

Слишком легко полагаться на Scrum и Scrum Master и, таким образом, попасть в огромный пробел, потому что Scrum почти ничего не говорит о How-World.

Вращающийся Скрам Мастер

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

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

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

Самоорганизующаяся команда

С точки зрения Scrum, команда должна выяснить себя, в идеале с помощью Scrum Master .

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

Приемочные испытания

Пользовательские истории имеют критерии принятия . Эти критерии приемки превращаются в приемочные испытания

Другие вещи

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

Надеюсь это поможет.

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

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

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

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

Вы можете пройти этот курс по SCRUM в Udemy бесплатно и узнать об отдельных аспектах процесса SCRUM - https://www.udemy.com/scrum-methodology/

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

Опять же, ПО решает, что строить, а команда решает, как реализовать эти истории.

Это не Agile проблема. Проблема заключается в том, что команде не хватает технических знаний, чтобы выполнить пользовательскую историю (гибкую) или требование (традиционное). Может ли Agile помочь в этой ситуации? Нет, если команда не была тщательно отобрана и никто в команде не обладает достаточным техническим опытом для выполнения своих задач. Да, если некоторые из членов команды обладают хорошими техническими знаниями, которые могут помочь другим членам команды в выполнении их задач. Потому что эта команда должна быть самоорганизующейся и знать свои сильные и слабые стороны.

пожалуйста, помните следующий Agile принцип.

«Лучшая архитектура, требования и проекты возникают из самоорганизующихся команд»

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