Соответствует ли оценка времени обещанию в Scrum?

Если оценка не является обещанием, то как владелец продукта, как я могу реализовать свои проекты, не зная, сколько времени это займет?

Работает ли команда Scrum более эффективно, если мы рассматриваем оценки времени как обещание?

Сколько исследований (подготовка, попытка понять проблему) в истории достаточно, чтобы дать правильную оценку?

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

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

В ответ на ваш вопрос «как владелец продукта , как я могу поставить свои проекты вне времени в качестве эталона?», Ответ в том , что вы можете и должны иметь время в качестве ссылки (т.е. вы будете выпускать на определенную дату). То, что у вас нет , это точный объем, который будет в доставке.

Обратите внимание, что то, что я сказал, относится ко всем методологиям, которые вы используете для развития. Разница между Scrum и другими методологиями (такими как Waterfall) заключается в том, что в Scrum этот факт признается и учитывается. То, что вы будете делать в качестве ПО, - это расставить приоритеты в своей сфере деятельности и убедиться, что команда в любой данный момент:

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

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

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

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

Что касается количества необходимых исследований - здесь действует закон убывающей отдачи. Если вы рассказываете свои истории достаточно мало, то небольшое исследование должно дать вам достаточно точную оценку. Если вы ошиблись, вы внесете поправки в следующем спринте, и оценки будут лучше. В среднем за 3-4 спринта у вас должно быть хорошее представление о том, сколько объема может быть доставлено к крайнему сроку (или сколько времени потребуется, чтобы завершить объем).

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

Стадия, на которой вы берете на себя обязательства по доставке, - это когда вы принимаете истории из бэклога продукта в Sprint. Вы обещаете доставить эти истории в спринте.

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

Когда команда сделает достаточно оценки, они будут лучше.

Вы также можете посмотреть на ...

Чистый кодер (книга) - в этой книге есть глава под названием «Язык обязательств», а также глава об оценке, которая действительно бросается в глаза.

Канбан - Канбан - это более гибкий стиль разработки - существуют также комбинации Scrum и Kanban, называемые «Scrumban», которые основаны на обеих идеях.

Нет.

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

Таким образом, скорость позволяет узнать, сколько ваша команда может произвести в следующем спринте, если предположить, что они используют один и тот же метод оценки, а команда стабильна и т. Д.

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

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

Мы с нетерпением ждем Agile. Обязательства не повышают ценность организационного планирования, чем прогнозы.

Настоятельно рекомендую Agile Оценка и планирование Майка Кона

Если оценка не является обещанием, то как владелец продукта, как я могу реализовать свои проекты, не зная, сколько времени это займет?

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

Работает ли команда Scrum более эффективно, если мы рассматриваем оценки времени как обещание?

Нет. Это приводит к оценкам мешков с песком и превращает графики скорости / выгорания в бесполезные данные - что мешает команде улучшаться.

Сколько исследований (подготовка, попытка понять проблему) в истории достаточно, чтобы дать правильную оценку?

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

Лично я не думаю, что есть большая выгода, пытаясь получить очень точные оценки. То, что я пытаюсь сделать, это убедиться, что оценки достаточно точны, то есть я не пропустил что-то, что может привести к тому, что история отклонится от своей оценки на порядок. (См. Следующий пункт).

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

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

Если оценка не является обещанием, то как владелец продукта, как я могу реализовать свои проекты, не зная, сколько времени это займет?

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

Самый распространенный способ определения проекта - перечислить его характеристики. Как правило, проект завершается, когда все функции были реализованы. Но что, если, работая над проектом, вы понимаете, что 5 функций, определенных в начале, не понадобятся, но есть 7 функций, о которых люди думали в течение первых 6 месяцев, которые действительно должны быть включены? Что это делает с вопросом, сколько времени это займет?

Еще один фактор заключается в том, что то, что вы узнаете, изменит ваше понимание того, как реализовать определенные функции, и по мере приближения к реализации каждой функции ваши оценки будут меняться. Лично я не стал бы ставить числовые оценки для всего, что не приближается к горизонту реализации - возможно, используя описательные оценки, такие как «крошечный», «маленький», «средний», «большой» и «огромный» или «эпический». Тогда вы не подразумеваете точность, превышающую ту, которую вы способны оценить.

По правде говоря, «Сколько времени это займет?», Не несет ответственности больше, чем «Что это будет, когда это будет сделано?». Бухгалтеры и традиционные бизнесмены ненавидят это, поэтому в некоторых организациях очень трудно отойти от Водопада.

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

Так что нет, оценка не обещание. Это оценка. «Обещание» - это обязательство, которое команда берет на себя, чтобы завершить определенное количество функций или историй в конкретном спринте.

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