Насколько важны задачи в истории?

Недавно мы реализовали Scrum, и одна из вещей, которые мы часто задаем себе, - это гранулярность задач в истории.

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

Это приводит к большому числу задач, описывающих многие технические аспекты и небольшие действия, которые необходимо выполнить, например, создать DAO для компонента X для сохранения в базе данных. Я также читал книги Кена Швабера и Майка Бидла, Agile Software Development с Scrum, и я понял, что задачи должны действительно иметь такую гранулярность; в одной из глав они заявляют, что задачи должны длиться от 4 до 16 часов.

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

Итак, в идеале, насколько важны задачи в каждой истории?

Ответ 1

Швабер и Бидл говорят "примерно четыре-шестнадцать часов".

Верхняя граница полезна. Это заставляет команду планировать и помогает ежедневно видеть прогресс.

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

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

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

Ответ 2

Задачи, вероятно, должны занимать половину дня в день, возможно, до двух дней.

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

В моем последнем задании у нас было от 4 до 32 часов за задание. Мы обнаружили, что, когда мы оценивали задачи более чем на ~ 32 часа, это объяснялось тем, что мы не понимали, что и как делать задачу во время оценки.

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

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

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

Ответ 5

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

Ответ 6

Эта цифра за 4 часа звучит как хороший минимум для меня. Мне нравится думать о видимых результатах. У нас нет задачи на строку кода или ярлык на экране или по утилизированному утилитарному методу? Но когда мы добираемся до того, что кто-то может использовать, например, публичный класс, используемый кем-то другим, или набор полей на экране, которые позволяют какое-то полезное действие, тогда это звучит как отслеживаемая задача для меня.

Для меня главный вопрос: "Знаем ли мы, что мы закончили его?" с индивидуальными вспомогательными функциями есть неплохие шансы рефакторинга и изменения, но когда я говорю своему коллеге "Здесь, используйте это", он либо работает, либо нет. Полнота задачи может быть оценена.