Насколько гранулированными должны быть задачи в истории?
Недавно мы внедрили Scrum, и одна из вещей, которые нас часто удивляют, это гранулярность задач в истории.
Несколько человек в нашей компании утверждают, что в идеале эти задачи должны быть очень мелкозернистыми, то есть каждая маленькая часть, которая вносит свой вклад в создание истории, должна представлять собой задачу. Они утверждают, что это позволяет отслеживать, как мы выступаем в текущем спринте.
Это приводит к большому количеству задач, детализирующих многие технические аспекты, и небольших действий, которые необходимо выполнить, таких как создание DAO для компонента X для сохранения в базе данных. Я также читал книгу Кена Швабера и Майка Бидла "Гибкая разработка программного обеспечения со Scrum", и я понял, что задачи должны иметь такую степень детализации; в одной из глав они утверждают, что выполнение задач может занять от 4 до 16 часов.
Однако я заметил, что с такими небольшими задачами мы часто склонны переусердствовать, а когда наше решение отличается от того, что мы ранее установили на наших совещаниях по планированию, нам нужно создать много новых задач или заменить старые. Члены команды также воздерживаются от необходимости отслеживать все, что они делают в спринте, и создавать новые задачи, поскольку это означает, что нам придется увеличивать общее количество задач в нашей таблице выгрузок, но необязательно добавлять задачу, которая агрегирует значение.
Итак, в идеале, насколько гранулированными должны быть задачи внутри каждой истории?
6 ответов
Швабер и Бидл говорят "примерно четыре-шестнадцать часов".
Верхняя граница полезна. Это заставляет команду планировать и помогает ежедневно видеть прогресс.
Нижняя граница является полезной целью для большинства задач, чтобы избежать хрупкости и затрат на завышение спецификации. Тем не менее, иногда команда может найти более короткие задачи полезными при планировании, и может включать их. Не должно быть обязательной нижней границы.
Например, одна из наших текущих историй включает в себя задачу отправить что-то другой команде - задачу, которая займет 0 часов, но одну мы хотим не забыть завершить.
Количество заданий в вашей таблице выгорания не имеет значения. Это оставшееся время имеет значение. Команда должна смело менять задачи во время спринта, как отмечают Швабер и Бидл.
Задачи, вероятно, должны занимать от половины дня до дня, иногда даже до двух дней.
Думайте об этом следующим образом: на более макроуровне короткие итерации способствуют гибкости, быстро создавая небольшие суммы и позволяя менять планы по мере изменения потребностей бизнеса. На более микроуровне то же самое верно для задач. Так же, как вы не хотите тратить 3 месяца на одну итерацию, вы не хотите тратить неделю на одну задачу.
Ежедневные встречи в режиме ожидания могут дать вам понять, что размер вашего задания слишком велик. Если члены команды часто отвечают "Что вы делали вчера?" и "Что ты будешь делать сегодня?" с тем же ответом, который они дали накануне, ваши задачи, вероятно, не достаточно малы.
Примером этого может быть, если член команды регулярно отвечает: "Я работал над BigComplexFeatureObject сегодня и буду работать над ним завтра" более одного дня подряд, и это подсказка, что ваши задачи могут быть слишком большими. Надеемся, что большинство дней член команды сообщит о завершении одной задачи и собирается начать другую.
Короткие задания, 4-16 часов, как говорили другие, также дают сотрудникам по интересам и команде хорошую информацию о ходе проекта. И они не дают членам команды идти по "кроличьим тропам" и тратить много усилий на работу, которая может не понадобиться, если бизнес-желания изменятся.
Приятно иметь много мелких задач в том, что они потенциально дают возможность ПО лучше расставить приоритеты и оптимизировать поставленную стоимость. Вы будете удивлены, сколько "важных" частей больших задач могут быть отложены или устранены, если они являются их собственной маленькой задачей.
На моем последнем задании у нас было от 4 до 32 часов на одно задание. Мы обнаружили, что, когда мы оценивали задачи более чем на 32 часа, это было из-за того, что мы не понимали, что и как выполнять задачу во время оценки.
В результате фактическое время выполнения этих задач значительно отличалось от меньшего. Мы также часто "застревали" в этих задачах, выбирали неверный путь или неправильно понимали требования.
Позже мы узнали, что, если оценивать задачи так долго, это был сигнал, чтобы попытаться разбить их еще больше. Если это было невозможно, мы отклонили задачу и отправили ее для дальнейшего расследования.
редактировать
Это также дает хорошее чувство для выполнения задач, по крайней мере, пару раз в неделю.
Это также дает довольно быструю обратную связь, когда что-то идет не так, как запланировано. Если кто-то не выполнил 8-часовое задание в течение двух дней, мы обсуждали, застрял ли человек в какой-то части, есть ли у кого-то еще какие-то идеи о том, как продвигаться вперед или с самого начала оценка была просто неверной.
Как правило, хорошим критерием является то, что задача - это то, что вы делаете в данный день. Это идеально, что означает, что это редко. Но это хорошо вписывается в ту оценку 4-16 часов (некоторые занимают полдня, некоторые занимают два дня и т. Д.), Которую вы дали. Конечно, я не думаю, что когда-либо проводил целый непрерывный день за одним заданием. По крайней мере, вы должны прерваться на встречу схватки. (На предыдущей работе день кодирования считался 6 часами для учета накладных расходов.)
Я могу понять искушение руководства хотеть планировать каждую детальную деталь. Таким образом, они могут микроуправлять каждым его аспектом. Но на практике это просто не работает. Они могут также подумать, что затем они могут использовать описания задач, чтобы каким-то образом генерировать подробную документацию о программном обеспечении, по сути, пропуская ее как фактическую задачу. Опять же, не работает в реальности.
Гибкая разработка требует небольших рабочих элементов, но слишком далеко заходит, что полностью разрушает цель. Это в конечном итоге становится проблемой слишком большого предварительного планирования и необходимости вносить тонны дополнительного перепланирования каждый раз, когда что-то меняется. В этот момент он больше не маневренный, это просто серия небольших водопадов.
Эта четырехчасовая цифра звучит для меня как хороший минимум. Мне нравится думать с точки зрения видимых результатов. У нас нет задачи на строку кода, или метку на экране, или на метод рефакторинга? Но когда мы получаем что-то, что может использовать кто-то другой, например, открытый класс, используемый кем-то другим, или набор полей на экране, которые допускают некоторые полезные действия, тогда для меня это звучит как отслеживаемая задача.
Для меня ключевой вопрос: "Мы знаем, что закончили?" с отдельными вспомогательными функциями есть довольно хорошие шансы на рефакторинг и изменение, но когда я говорю своему коллеге "Вот, используйте это", это либо работает, либо нет. Завершенность задания можно оценить.
Я не думаю, что есть универсальный ответ на этот вопрос, который подходит для любой ситуации. Я думаю, что вы должны попробовать то, что предлагают ваши коллеги, и после первого или двух спринтов вы оцените и посмотрите, нужно ли настроить процесс, чтобы учесть все потребности и пожелания.