SCRUM вариация с ежедневными целями?

Question

На работе мы вроде следуем SCRUM, но в начале каждой недели мы планируем своего рода спринт на каждый день.

Например, регулярная неделя будет планироваться так:

День 1

• История 1
• Story 2

День 2

• Story 3

День 3

• Story 4
• Story 5
• Story 6

... так далее.

Мы используем Pivotal tracker и отмечаем каждый ежедневный спринт релизом, а затем продолжаем регулярный цикл Start - Deliver - Accept или Reject.

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

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

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

Answer 1

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

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

1. Кто делает ежедневный план?
2. Кто дает оценку каждой истории?
3. Кто определяет зависимость между историями?

По моему опыту, недельный спринт в порядке, но ежедневный план не нужен. Ежедневная встреча на высшем уровне уже является «совещанием по ежедневному планированию» для команды Scrum. На этом собрании члены команды тянут задачи и составляют свой собственный план, который является разумным. Вы можете ожидать, что каждое задание (или «история» в вашем случае) должно быть завершено в течение одного дня, но на самом деле этого очень трудно достичь. Даже для простой задачи «смены кода» могут возникнуть некоторые комментарии к обзору, которые предполагают гораздо большее изменение, чем сама задача. Таким образом, ежедневная цель может быть еще сложнее достичь, чем еженедельная цель или спринт.

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

Так что мое предложение: легко справиться с ежедневной целью и больше сосредоточиться на цели спринта.

Answer 2

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

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

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

Один пункт отметить, вы говорите:

, но мы стараемся, чтобы наши обязательства перед максимальным для того, чтобы идти в как можно быстрее

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

Надеюсь, что это поможет.

Answer 3

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