Я не поклонник схватки, и у меня есть только год практического опыта. Таким образом, следующее должно быть прочитано с частичкой соли.
Я вижу несколько красных флажков в том, что вы пишете:
5-часовое планирование спринта
Это слишком долго для спринта на одну неделю.
Целью планирования спринта является AFAIR для
- позволить команде знать, каковы текущие приоритеты и
- разработать план битвы на предстоящий спринт.
Чтобы сделать это эффективно, каждая сторона должна понимать Product Backlog items
.
Чтобы понять Product Backlog items
отставание, оно должно быть в хорошей форме.
На конкретном этапе планирования Product Backlog items
они преобразуются в Sprint Backlog items
.
Одна из возможных причин заключается в том, что эти пункты недостаточно уточнены / уточнены.
Другая возможная причина в том, что предметы слишком сложны и оставляют место для слишком большого количества интерпретаций.
Обсудите очень подробно в планировании спринта
Как сказано выше, этап обсуждения будет короче, когда пункты будут более конкретными.
С другой стороны: планирование спринта предполагает профессиональное поведение каждого участника. Это включает в себя избегание велосипедных дискуссий.
Возможно, все и так понятно, но кто-то начинает велосипедную дискуссию.
Больше: избегайте дискуссий о деталях реализации . Хотя каждая идея в какой-то момент времени оказывается в коде, не стоит обсуждать планирование спринта: подойдет ли простой массив или будет лучше использовать связанный список.
Поскольку большинство членов команды не старшие
В схватках нет различия между старшим и младшим . Оба просто разработчики. И это хорошая отправная точка, которая поможет вам сосредоточить обсуждение на жизнеспособном решении, подкрепленном лучшими аргументами, а не зарплатой.
Ошибки реализации и редизайна в спринте
Кажется, существует фундаментальная проблема в сборе требований, за которой следует очень расплывчатое отставание продукта.
Как я сказал выше: пока Product Backlog
он в хорошей форме, трудно упустить момент.
Я не могу представить ситуацию, как:
»Как пользователь, я хочу видеть несколько клиентов!«
«О, вы не имели в виду каждого из наших 2 миллионов клиентов?»
OTOH: Что в этом контексте означает редизайн ? Если разработчик выбрал медленный алгоритм выполнения, то есть следующая ясная цель: выбрать более эффективный алгоритм. Но это не «редизайн», это оптимизация.
На ваши основные вопросы:
Как с этим бороться?
Упрощенно упомянуть, но я все равно это делаю: не забывайте, что вы имеете дело с людьми .
Очень трудно иметь группу разных умов, способных делиться общими понятиями (как в Rashomon ). Чтобы эффективно справиться с этим, используйте как можно больше избыточности в своем общении: например, подробно объясните контекст предмета, даже если каждый «должен знать», что делать. Задайте вопросы, все ли понимают, какова тема данного предмета.
Если вы играете в покер-планировщик, то хорошим показателем того, что понимание достаточно хорошее, является то, что задания оцениваются низко. Низкий означает низкую сложность, значит легко понять и трудно пропустить.
Одним из побочных эффектов итерации является то, что числа для определенных задач будут расти (потому что у команды есть понимание ее возможностей и скрытых сложностей). Тогда есть шанс разбить предмет на несколько менее сложных предметов с меньшей сложностью.
Сколько деталей я должен обсудить при планировании подгонки 2 часа в спринте на неделю?
Саломонический ответ: как можно меньше и столько, сколько нужно, но не больше.
ТЛ; др
Выберите легкий язык (если это поможет, используйте простой английский или ELI5
), чтобы избежать недоразумений
Улучшить сбор требований
Улучшить отставание
Повысить уверенность членов команды в их индивидуальных способностях, а также в способностях команды
Избегайте велосипедных прогулок
Улучшить личную дисциплину
Возможно, используйте фиксированные временные рамки для каждого предмета для обсуждения
Укрепить позицию, scrum master
чтобы эффективно модерировать.