Как мы можем предоставить действительные оценки времени при планировании спринта, не делая «слишком много» дизайна?

Моя команда набирает скорость со Scrum, но большинство из нас более знакомы с негибкими или «псевдо» гибкими методологиями. Самым большим препятствием для нас является проведение эффективного совещания по планированию спринта, на котором мы разбиваем наши позиции в заданиях и оцениваем часы. (Я использую терминологию из шаблона Scrum VS2010; извиняюсь, если где-то использую неправильное слово.)

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

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

Существуют ли какие-либо практические привычки / приемы / и т.д. для принятия решения о том, сколько времени займет функция, не зная, как вы планируете ее реализовать? Если наши оценки времени существенно изменятся после того, как проектирование будет завершено, как мы можем должным образом планировать наше отставание Sprint заблаговременно?

РЕДАКТИРОВАТЬ:

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

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

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

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

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

2. Подумайте об использовании планирования покера , то есть очков / единиц «усилий», а не человеко-дней для оценки задач. Также постарайтесь разбить истории как можно больше. Чем длиннее / сложнее история, тем менее вероятно, что ваша оценка будет точной.

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

4. Поговорите о том, как оценки сметались в ретроспективе в конце спринта. Особенно, если бы были те, которые были удивительно далеки. Узнала ли команда что-нибудь из того, как прошла история, и как она ожидала? Скрам мастер должен сосредоточиться на действенных изменениях, которые могут быть внесены в ваш процесс проектирования / оценки.

Я думаю, проблема в том, что вы пытаетесь оценить время. Не.

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

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

Я настоятельно рекомендую Прикладные пользовательские истории Майка Кона .

Я знаю, что ваш вопрос именно о том, чтобы избежать дизайна при планировании. Но это своего рода проблема XY .

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

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

Автоматизированные критерии приемки

Наши истории указаны по количеству критериев автоматического принятия . Это означает, что если бы мы написали автоматизированные тесты, чтобы подтвердить, что история закончена, что бы они были?

Например, «Когда пользователь нажимает кнопку« Play »на iPad под управлением iOS 6+, начинается воспроизведение видео». Это может быть трудно на самом деле автоматизировать этот тест, но это критерий приемлемости (AC) истории и вносит свой вклад в одно очко.

Мы используем шкалу Фибоначчи, и мы всегда округляемся. Поэтому, если у истории есть четыре автоматических критерия приемлемости, это история из пяти пунктов.

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

Предварительная стрижка

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

Grooming приносит опыт команды, чтобы вынести на подготовленные истории, выискивая неуказанные требования, разбивая истории, и т. Д.

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

Ограничение незавершенного производства

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

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

Как только история переходит из отставания в незавершенное производство, мы характеризуем ее как находящуюся в одном из нескольких состояний:

• В ожидании - работа в команде невозможна, потому что мы ждем какой-то дополнительной команды
• В разработке - работа над достижением критериев приемлемости
• Требуется проверка - мы считаем, что встретили AC, ожидая, пока кто-то еще подтвердит
• В тесте - история оценивается по AC, ошибки исправляются
• Готов к развертыванию - при следующей доступной возможности, он будет запущен

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

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

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

Здесь можно сделать две вещи.

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

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

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

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

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

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

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