MSF Agile: риск против очков истории?
Я работаю над созданием начального набора пользовательских историй для нового проекта и впервые использую MSF Agile. У меня есть около 100 пользовательских историй, и я назначил их всем областям и итерациям, но следующий шаг для меня - это присвоение всех их значений Risk, Story Points и Stack Rank. Тем не менее, я обнаружил, что я назначаю почти зеркально противоположные значения для точек риска и сюжета, то есть все мои истории с 1-высоким риском - это 3 балла, а все мои истории с 3-низким риском - 1 сюжетные точки.
Документация MSDN определяет эти поля как таковые:
"Очки сюжета: субъективная единица измерения, которая отражает размер пользовательского рассказа. Если вы назначаете больше баллов пользовательскому рассказу, вы указываете, что для его реализации требуется больше работы".
"Риск: субъективная оценка относительной неопределенности вокруг успешного завершения пользовательского рассказа. Вы можете указать следующие значения: 1 - высокий, 2 - средний, 3 - низкий"
Я нахожу, что они идут рука об руку почти во всех ситуациях, с которыми я сталкивался. По вашему опыту, какие примеры историй с высоким риском стоят всего несколько баллов или истории с низким риском стоят много баллов?
Мне нужна помощь в рассуждении об этом по-разному. Как я должен думать об этом?
2 ответа
Так не должно быть.
Возможно реализовать большую часть истории без риска вообще. Риск не означает, что это займет много времени, но скорее всего, это займет намного больше времени, чем вы думаете.
Примером истории 1 риска 1 может быть набор графических интерфейсов, которые должны быть тщательно расположены и каждый из которых утвержден заказчиком. Вы знаете, что это займет много времени, но вы не ожидаете более одной или двух итераций на экран.
Пример истории 1, риск 3, может быть связан с веб-серверами, для которых, как вы думаете, вы знаете API. Вероятно, банально, потенциально раздражает (Что, если вам нужно подражать каким-нибудь неприятным cookie-файлам или что-то в этом роде - просто придумывать это, а не лично веб-разработчик).
История 1 риск 3 будут более редкими, потому что вы, вероятно, должны изучить их более глубоко и немного снизить риск, но в некоторых случаях к тому времени, когда вы это сделали, вы могли бы также реализовать его...
Просто чтобы прояснить это дальше для будущих читателей...
Очки истории - это оценки размера и сложности любой данной функции / пользовательской истории. Кроме того, эти значения являются относительными, то есть каков размер и сложность функции A по сравнению с функцией B. Это совершенно другое обсуждение, но "Гибкая оценка и планирование" Майка Кона будет хорошей отправной точкой.
Риск должен быть связан с вашей оценкой вероятности возникновения проблем с данной функцией.
Так, например, у вас может быть особенность, которая требует много "ослиной" работы... то есть много тяжелой работы, но не очень хитрой или вне области знаний. Это был бы пункт низкого риска.
Однако, если у вас есть то, что может показаться простой / небольшой функцией, скажем, добавление аутентификации на основе форм в ваше веб-приложение. Это может оказаться более рискованным, поскольку, возможно, потребуется решить большое количество проблем безопасности вокруг веб-приложения, или никто из команды не имеет никакого опыта в реализации аутентификации на основе форм и т. Д. Итак, что может показаться небольшим Функция добавления нового типа экрана входа в систему и аутентификации на бэк-энде может оказаться более хитрой. Риск того, что что-то пойдет не так или пропустит, выше.
Надеюсь, что это поможет прояснить разницу между историческими моментами и риском.