ПО скажу иди с командой решай. если считаешь что нужно пойдем я помогу договорится :D

Ок, ПО к тебе пришел с тем же самым :)

Если от этого меняется цель спринта, то отменяем спринт же)

чо тут такого что мы 2х разрабов всего переключим

цель спринта? слышали про такое?)

Это такая надстройка над скрамом для управления проектом, в котором у исполнителей скрам

Ключевой вопрос - что именно плохо для вас в этом процессе? Не просто "что неправильно", а что вам мешает.

Как правило, цель спринта у нас типа "эти две фичи - в релиз". Наверное, я вообще не понимаю, зачем спринту цель, потому что не понимаю, как она может нам помочь.

и начинается :D скорее всего когда с командой PO поговорит окажется что оно таки до след недели оно потерпит. поэтому в особо токсичных компаниях проще PO сразу послать :D

Лучше все-таки поговорить), даже с PO в токсичных компаниях

Жуткая надстройка

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

Всем Скрам ✌️, берегите себя 😁

Как правило, разработка и тестирование целевых задач укладывается в 4-6 дней. Потом начмна бардак, с которым не понятно, что делать 😔

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

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

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

Почему? Она же совсем менеджерская, сам скрам не аффектит.

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

Игорь, ты точно понимаешь, что такое цель спринта?:)

Она некоторые рамки зажимает и вынуждает определенным образом измерять velocity

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

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

То есть, если к середине спринта мы выполняем цель, то проблема может быть в том, что мы ставим себе недостаточно сложные цели?

То есть, если к середине спринта мы выполняем цель, то проблема может быть в том, что мы ставим себе недостаточно сложные цели?

А про то, что разработчики в середине спринта отвлекаются - попробуйте брать в спринт чуть больше, но контролировать, чтобы фичи шли последовательно: сначала команда целиком заканчивает одну и потом переключается на следующую.

если не закончены тогда идем доделывать :D

если цель достигнули и по DoD все задачи которые сделали проходят. то надо заканчивать спринт и проводить планирование

Даже если длина спринта плавает на +/- три дня (почти на треть)?

Даже если длина спринта плавает на +/- три дня (почти на треть)?

Но тогда не останется времени порефакторить после демо.

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

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

ну всмысле плавает? вы опытным путем осознаете сколько команда сможет сделать через 1-2 спринта.

у меня вопрос - а у вас вообще есть DoD?

Можешь уточнить? RS, имхо, из ограничений, задает только необходимость использовать один метод измерения velocity на протяжении всего спринта.

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

Для фич у нас довольно подробные критерии. Для рефакторинга - нет, не бывает.

какие критерии? в DoD - пришется все что должно быть сделано по задаче чтобы она была готова. готова = ее можно релизить на прод.

Нам не доверяет продакт. То, что выполнено, нужно обязательно показать, и через раз продуктовая команда пользуется демо, чтобы заказать ещё какие-то доработки. Да, понятно

Нам не доверяет продакт. То, что выполнено, нужно обязательно показать, и через раз продуктовая команда пользуется демо, чтобы заказать ещё какие-то доработки. Да, понятно

Может быть всей команде стоит вместе прочитать скрамгайд и обсудить какие шаги вы можете вместе сделать чтобы что-то улучшить?

Может быть всей команде стоит вместе прочитать скрамгайд и обсудить какие шаги вы можете вместе сделать чтобы что-то улучшить?

сейчас попробую. Чтобы строить критическую цепь и прогнозировать (это у нас на статистике основано) у тебя способ измерения скорости на весь прогнозируемый цикл должен быть одинаковый (иначе экстраполяция не работает). А это значит, что ты должден или с высокой точность оценивать, или с буферами или игнорировать ошибки заложенные в модель. Далее. Этот подход легализует скрам в проектной деятельности. Позволяя применять его там где известен образ результата. И тогда фидбэк луп от спринт ревью становится бессмысленным, а ретроспектива принципиально схему поменять не может - мы обвязаны методами измерения до конца проекта. В итоге реально работает только итеративность (спринт) и возможность буферы сверять раз в спринт и принимать решения какие-то. Т.е. по факту вместо того, чтобы управлять поставляемой ценностью - ты занимаешься оптимизацией проектного треугольника опять. Вопрос - нахрена? Нахрена тогда прикручивать скрам? Оставьте себе итеративную разработку + CCPM и всё.