Бывает ли в Agile Scrum спринт переменной временной длинны. Везде написано что время ограничивается для гарантирования устройчивости. Может показаться что +/- несколько дней на устройчивость и не повлияют.
Здравствуйте, Hard_Club, Вы писали:
H_C>Бывает ли в Agile Scrum спринт переменной временной длинны. Везде написано что время ограничивается для гарантирования устройчивости. Может показаться что +/- несколько дней на устройчивость и не повлияют.
GIV>А смысл? Вся соль же в одинаковых спринтах.
Главная фишка скрама в расчете скорости команды, но для этого одинаковые спринты в общем-то не нужны. Идеальный скрам в вакууме не учитывает праздники, больничные и отпуска — его все равно нужно адаптировать к календарю команды и к ритму жизни компании. Важно только, чтобы реальная продолжительность спринта соответствовала запланированной.
Здравствуйте, Baudolino, Вы писали:
GIV>>А смысл? Вся соль же в одинаковых спринтах. B>Главная фишка скрама в расчете скорости команды, но для этого одинаковые спринты в общем-то не нужны. Идеальный скрам в вакууме не учитывает праздники, больничные и отпуска — его все равно нужно адаптировать к календарю команды и к ритму жизни компании. Важно только, чтобы реальная продолжительность спринта соответствовала запланированной.
Не, не. Плавали — знаем. Бегают потом менеджеры и впихивают в спинт побольше-побольше, надо, срочно. Лишная точка давления на команду, нафиг.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не главная.
По ссылке очень много философии и очень мало смысла. Scrum — не единственная agile методология, и в разделе ключевых идей было бы логично ожидать описание того, чем именно скрам отличается от того же канбана. Т.е. надо было бы объяснять, как задачу максимизации производительности команды решают спринты, почему демо должно быть итогом спринта и т.п. Но практически все, что там написано, применимо чуть ли не к любой другой agile методологии.
B>>, но для этого одинаковые спринты в общем-то не нужны. НС>Не нужны. Единица изменерения скорости в скраме — story point.
Спасибо, капитан! Только тут есть один нюанс: если брать классическое определение скорости как суммы story point завершенных задач, тогда одинаковые спринты нужны — иначе не получится использовать скорость для прогнозирования. Так что либо спринты одинаковые и скорость измеряется в стори поинтах, либо разные и PO в качестве метрики скорости смотрит на отношение story points/время.
B>> Идеальный скрам в вакууме не учитывает праздники, больничные и отпуска НС>Чего вдруг не учитывает? В календаре спринта забивается и вперед.
Больничные и внеплановые отгулы — в календарь спринта?
Здравствуйте, GarryIV, Вы писали:
GIV>Не, не. Плавали — знаем. Бегают потом менеджеры и впихивают в спринт побольше-побольше, надо, срочно. Лишная точка давления на команду, нафиг.
Менеджеры на скорость команды должны смотреть. Если у них не получается, то лучше освободить команду от точки давления в виде конца спринта и перейти на канбан (можно по-прежнему использовать спринты для фокусировки на определенных задачах, но не планировать их и делать демо по готовности, а не на их границах). Производительность от этого не изменится, уровень стресса снизится, да и бизнес будет счастливее, поскольку будет чаще видеть результат (если конечно поток задач хорошо сбалансирован между эпиками и небольшими визуальными фиксами).
Здравствуйте, Baudolino, Вы писали:
НС>>Не главная. B>По ссылке очень много философии и очень мало смысла.
Смысла там вполне достаточно. И подробно сказано чем скрам от других методологий отличается. Но да, твою теорию она не подтверждает. Потому ссылка плохая.
B> Scrum — не единственная agile методология, и в разделе ключевых идей было бы логично ожидать описание того, чем именно скрам отличается от того же канбана.
Канбан это просто набор методик, как спланировать и как трекать, его можно натянуть на что угодно и как угодно. Скрам, что характерно, канбаном пользуется по полной. Но добавляет свою специфику, о которой по ссылке прямо сказано.
B> Т.е. надо было бы объяснять, как задачу максимизации производительности команды решают спринты, почему демо должно быть итогом спринта и т.п.
Если тебе для описания ключевого отличия требуется залазить в такие подробности, это означает что сам ты ключевые моменты понимаешь плохо, и за деревьями не видишь леса.
B>Спасибо, капитан! Только тут есть один нюанс: если брать классическое определение скорости как суммы story point завершенных задач, тогда одинаковые спринты нужны
Не нужны. Считаются закрытые PBI, а не спринты. Спринты нужны не для измерения скорости, а для того чтобы корректировать планы в соответствии с меняющимися требованиями и уровнем понимания. Отсюда и привязка к спринтами планирований и ретроспектив. Burndown диаграммы же с story points прекрасно работают и без спринтов.
НС>>Чего вдруг не учитывает? В календаре спринта забивается и вперед. B>Больничные и внеплановые отгулы — в календарь спринта?
Да. Но я вижу что праздники и отпуска ты уже убрал из списочка.
Здравствуйте, GarryIV, Вы писали:
B>>Главная фишка скрама в расчете скорости команды, но для этого одинаковые спринты в общем-то не нужны. Идеальный скрам в вакууме не учитывает праздники, больничные и отпуска — его все равно нужно адаптировать к календарю команды и к ритму жизни компании. Важно только, чтобы реальная продолжительность спринта соответствовала запланированной. GIV>Не, не. Плавали — знаем. Бегают потом менеджеры и впихивают в спинт побольше-побольше, надо, срочно. Лишная точка давления на команду, нафиг.
При чем тут продолжительность спринта? Бизнес-задачи могут ставится только при его планировании. Если у вас потом менеджеры куда то бегают — у вас большие проблемы, и одинаковые спринты вас не спасут.
Здравствуйте, Hard_Club, Вы писали:
НС>>В каком смысле переменной? Если иногда на 1-2 дня подвигать — без проблем. А если постоянно менять длину — неудобно же. H_C>а почему собственно неудобно?
Потому что при фиксированной длине спринта у команды набивается рука в его планировании. А вот когда длина плавает — все становится сильно сложнее.
НС>Если тебе для описания ключевого отличия требуется залазить в такие подробности, это означает что сам ты ключевые моменты понимаешь плохо, и за деревьями не видишь леса.
Если ты хочешь что-то доказать, приводи аргументы здесь в тексте — мысли твои здесь никто не читает. Я в данный момент вижу перед собой собеседника, у которого понтов и наездов больше, чем собственных мыслей и суждений по теме. С чем конкретно споришь? Что считаешь правильным?
B>>Спасибо, капитан! Только тут есть один нюанс: если брать классическое определение скорости как суммы story point завершенных задач, тогда одинаковые спринты нужны. НС>Не нужны. Считаются закрытые PBI, а не спринты.
Спасибо, кэп, это было ловко — не согласиться и сказать ровно то же самое, что писал я выше. Давай ещё раз повторим, для закрепления: скорость спринта — сумма story points для задач (PBI), закрытых в этом спринте. Чтобы на основе значений скорости прогнозировать будущую производительность команды нужно, чтобы измерения производились на одинаковых отрезках рабочего времени: если скорость на предыдущих спринтах была 100, 109, 106, то на следующий спринт можно планировать 105 sp.
НС>Спринты нужны не для измерения скорости, а для того чтобы корректировать планы в соответствии с меняющимися требованиями и уровнем понимания. Отсюда и привязка к спринтами планирований и ретроспектив.
Для корректировки планов спринты не нужны. Планы прекрасно корректируются и в канбане, и в водопаде безо всяких спринтов. Вот только скрам как методология включает в себя постоянную переоценку производительности команды для более точного планирования, и для этого используется скорость команды, измеренная в предыдущих спринтах. Спринты нужны — в том числе — для измерения скорости, это один из основных компонентов методологии. "В том числе", потому что у спринта основная функция — упорядоченная коммуникация со стейкхолдерами и внутри команды. Не "корректировки планов", а именно коммуникация, точнее её ритм.
НС>Burndown диаграммы же с story points прекрасно работают и без спринтов.
Согласен. Главное выбрать подходящие интервалы времени и запланировать на них работу. Только при чем тут burndown?
НС>>>Чего вдруг не учитывает? В календаре спринта забивается и вперед. B>>Больничные и внеплановые отгулы — в календарь спринта? НС>Да.
Как и, самое главное, зачем? И вообще, с каких пор в скраме у спринтов есть календарь?
НС>Но я вижу что праздники и отпуска ты уже убрал из списочка.
Нет, конечно. Но, думаю, надо сначала разобраться с больничными.
НС>Канбан это просто набор методик, как спланировать и как трекать, его можно натянуть на что угодно и как угодно. Скрам, что характерно, канбаном пользуется по полной. Но добавляет свою специфику, о которой по ссылке прямо сказано.
Хочется воскликнуть чего все так сложно! На другом форуму читал что Канбан противопоставляется Скраму так как скрам митигирует риски связанные с Velocity, а Канбан с WiP. И соотвественно разные потоки тасков. А что появилось в Канбан и используется в Scrum? Доска как таковая?
НС>Не нужны. Считаются закрытые PBI, а не спринты. Спринты нужны не для измерения скорости, а для того чтобы корректировать планы в соответствии с меняющимися требованиями и уровнем понимания. Отсюда и привязка к спринтами планирований и ретроспектив. Burndown диаграммы же с story points прекрасно работают и без спринтов.
Ну опять таки на форуме читал что если будут разные спринты — то будет мало спатистики по конкретной длинне.
НС>>Спринты нужны не для измерения скорости, а для того чтобы корректировать планы в соответствии с меняющимися требованиями и уровнем понимания. Отсюда и привязка к спринтами планирований и ретроспектив. B>Для корректировки планов спринты не нужны. Планы прекрасно корректируются и в канбане, и в водопаде безо всяких спринтов. Вот только скрам как методология включает в себя постоянную переоценку производительности команды для более точного планирования, и для этого используется скорость команды, измеренная в предыдущих спринтах. Спринты нужны — в том числе — для измерения скорости, это один из основных компонентов методологии. "В том числе", потому что у спринта основная функция — упорядоченная коммуникация со стейкхолдерами и внутри команды. Не "корректировки планов", а именно коммуникация, точнее её ритм.
Как я понял ритм создает нужную зону комфорта для коммуникации (предполагая что ее должно быть много).
B>Согласен. Главное выбрать подходящие интервалы времени и запланировать на них работу. Только при чем тут burndown?
Просто нужны относительно короткие таски?
Здравствуйте, Hard_Club, Вы писали:
H_C>Тогда главное отличие скрама от канбана — четкая структура коммуникации?
Не только. Скрам вообще существенно больше ограничений накладывает. Ну а идеологически скрам больше направляет, а канбан контролирует факт. Т.е. канбан сильно более формален, идея там в том чтобы контролировать конкретные численные показатели. Скрам же больше акцентирует на правильной командной работе и взаимодействии команды со стейкхолдерами.
