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

9

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

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

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

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

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

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

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

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

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

KutuluMike
источник
Что вы подразумеваете под "подходящим"?
Роберт Харви
Я имею в виду, что я не думаю, что команда должна тратить 25-30 минут на технический дизайн функции во время планирования спринта, но это только мое внутреннее чувство (то, что это заставляет наши встречи по планированию идти очень долго.)
KutuluMike
Ты прав, Майкл. Я только что подумал о чем-то еще, что я добавлю к своему ответу ниже. По сути, если вы планируете спринт без какого-либо бизнес-спонсора, то вы не знаете, как расставить приоритеты. Подробнее ниже.
Ян
1
У вас есть два варианта. Вы можете продлить продолжительность фазы проектирования, чтобы получить адекватные оценки, или вы можете жить в соответствии со своими собственными временными ограничениями и принимать дикие догадки. Вы также можете встроить время в спринты для проектирования (что вам в любом случае придется делать) и изменить свои оценки работы после завершения этапа проектирования.
Роберт Харви
Я полагаю, что часть «изменить ваши оценки работы» - это то, что является борьбой за нас; некоторые члены команды более настойчивы, чем другие, что мы не даем часовую оценку, если не знаем, что они правы. Я также надеюсь и ожидаю, что со временем нам станет лучше, но ясно, что «всем остальным» удается сделать это очень хорошо, поэтому я чувствую, что есть что-то очевидное, что я упускаю.
KutuluMike

Ответы:

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

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

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

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

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

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

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

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

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

Мэтью Флинн
источник
Это имеет смысл, но мы пытаемся следовать шаблону Scrum VS2010, полагая, что многие умные люди, которые знают, что они делают, придумали его. Если мы не оцениваем часы, как мы отслеживаем такие вещи, как оставшаяся работа над задачами или производим диаграмму выгорания?
KutuluMike
Вы не отслеживаете оставшуюся работу над задачами. Либо это сделано, либо нет. В начале спринта команда берет на себя обязательство подготовить определенное количество историй, основываясь на их приоритете, их сложности и наилучшем предположении команды о том, с какой сложностью они могут справиться. На собрании по планированию спринта они должны решить, какие задачи необходимы для завершения истории. Эти задачи составляют отставание спринта - вы можете просто сказать, что они составляют 1 балл за каждый спринт. По завершении каждого из них они могут быть отмечены как выполненные.
Мэтью Флинн
Не должно быть никакой связи между точками сложности в журнале работы продукта и точками задач в журнале работы Sprint. Вы ежедневно обновляете журнал спринта, отмечая задачи. Вы обновляете журнал незавершенного производства в конце спринта, когда демонстрируете, что законченные истории готовы.
Мэтью Флинн
Хм, тогда мы действительно делаем что-то не так. Я знаю, что есть несколько способов сделать Scrum, но это руководство, которое мы используем, в котором говорится, чтобы отслеживать оставшуюся работу над задачей: msdn.microsoft.com/en-us/library/ff731574.aspx . Разве это не правильно?
KutuluMike
3
Ahhhhh. Понимаю. Это не так как таковое, но, очевидно, это не особенно полезно для вас. Scrum Guide гласит: «По мере выполнения или завершения работы предполагаемая оставшаяся работа обновляется», поэтому шаблон MS имеет смысл. Как я уже сказал, это не очень полезная метрика - никто никогда не делает хорошую работу по оценке оставшейся работы для задачи, и вы тратите время, пытаясь это сделать. Сделайте ваши задачи маленькими и двоичными (0 = выполнено или 1 = нет), и вы получите оценку того, что сделано и что осталось, и вам не нужно об этом думать.
Мэтью Флинн
6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Джимбо
источник
3

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

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

Карл Билефельдт
источник
2

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

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

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

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

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

Ян
источник
Мы на самом деле добавляем мастера схватки (кто-то с опытом Скрама, нанятый, чтобы заполнить эту роль для нас), так что, надеюсь, это поможет; но мы все понимаем, что это проблема, с чем я борюсь, как это сделать лучше .
KutuluMike
Ну, вы определили проблему. Вы проектируете на встрече. На следующей встрече у вас, если вы обнаружите, что разрабатываете дизайн, остановитесь, скажите «Мы недостаточно знаем» или «Мы знаем достаточно». Если вы недостаточно знаете, отложите его до тех пор, пока у вас не будет больше информации (сеанс разработки вне совещания по планированию). Если у вас достаточно информации, запланируйте ее (или нет) и продолжайте.
Ян
Еще один комментарий, который я должен добавить. Будьте осторожны, когда нанимаете мастера схватки. При использовании всех гибких методов ключ должен быть гибким. Принять то, что работает, изменить то, что нет. Это огромное изменение для компаний, которым нравится документировать процедуры и планировать планы.
Ян
0

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

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

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

Дейв
источник