☝️Внимание, вопрос: В рамках спринта один из членов команды делает задачу и переносит её в колонку "На согласование". Что он должен сделать дальше: перейти к следующей задаче или ожидать обратной связи для доработки или переноса в колонку "Завершено"? Тут беспокоит противоречие: или простой члена команды, выполнившиего задачу или соотв. переключение контекста у других участников команды.

Оценка завершенности производится по мере завершения задач или по итогам спринта?

Такие вопросы решаются на scrum daily

Оценка завершенности производится по мере завершения задач или по итогам спринта?

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

Непонятно, что делать, когда 1 из членов команды сделал свою задачу. Он должен сразу перейти к следующей? Или дождаться обратной связи от других членов команды, чтобы перенести её в выполненно?

Буду рад конструктивной критике.

Оценка завершенности производится по мере завершения задач или по итогам спринта?

На скрам-доске только три колонки: делать, делаем, сделали. Когда больше - вы пытаетесь применить канбан. Тогда вам нужны лимиты незавершенной работы и они подскажут что делать.

Как делали мы. У нас Скрам: 1. Собрать кросс-функциональную фиче-команду. ВСЕ делается в команде. 2. Использовать не выталкивающую систему, а вытягивающую. Пока задачу никто не берет в работу дальше - она в буфере Ready. Мы это используем на доске так To Do -> DEV In Progress-> DEV Ready-> Test->Done. задача сделанная разработчиком не идет дальше. Пока ее не вытянут дальше. Мы видим прогресс на Daily. Если убрать DEV Ready - непонятно будет, работают с задачей или нет. 3. Выработали всеми командами общее правило. Если раработчик свободен - он помогает другим членам команды. Если у команды нет для него работы (редкость), он предлагает помощь другим командам. Если у них нет для него работы (редкость) он медленно и печально бредет в Бэклог и ищет варианты там (ни разу не было). Ну как то так.

можно же поработать над технической частью, начиная с багов и прочих документирований-автоматизаций), плюс проработка бэклога наперед — было бы желание 😄

Тут основной посыл - ВСЕ что нужно для достижения цели Спринта должно быть в команде. В этом случае не надо ничего ни с кем согласовывать. Просто берем и пилим. Уточнение Бэклога Продукта (в новом Скрам гайде вместо него будет слово Актуализация) это 80% успеха команды в Спринте. Личное мнение.

Да, если сотрудник свободен (что редкость) можно заняться Актуализацией задач для следующих Спринтов, самообразованием, помощью другим командам, устранить техдолг, да и много чего еще. Приоритетно - помощь своей команде.

☝️Внимание, вопрос: В рамках спринта один из членов команды делает задачу и переносит её в колонку "На согласование". Что он должен сделать дальше: перейти к следующей задаче или ожидать обратной связи для доработки или переноса в колонку "Завершено"? Тут беспокоит противоречие: или простой члена команды, выполнившиего задачу или соотв. переключение контекста у других участников команды.

Коллеги, а я вот вижу у @AlexUsov следующую проблему: Подскажите пожалуйста, а какой «обратной связи» человек, выполнивший задачу, ждет от других членов команды? И зачем ему эта обратная связь? Ну т.е. когда задача в спринте, это значит что она обсуждена вдоль и поперек и все знают, что делать. Дальше она идет чисто по исполнителям. «Обратную связь» дает обычно РО на спринт ревью. Возможно у нас просто терминологическая рассинхронизация. Хочу понять.

добрый день, господа. Разрабатываем регламент для работы с проектами в редмайне. Хотим внедрять скрам. Есть у кого пример или шаблон для управления именно в редмайне?

Я понимаю ваше отношение к регламентам, но вы слишком утрируете.

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

Регламент не самая хорошая история. Поддерживаю. Мы в редмайне ведем только Общий бэклог. На физических досках Спринт Бэклоги в командах. Планирование тоже на физ. доске, на стикерах номера задач в редмайне. Единственно что делают в редмайне команды это забирют задачу в Спринт и Отдают задачу из Спринта. Да, еще по результатам PBR записывают туда приемочные критерии (для задач на 8 и 13 SP). В остальном там работает Влдаделец Продукта. Это его зона. Для того чтобы все работало команды собрались и создали рабочее соглашение на одном плакате. Там порядок работы, который ПОДДЕРЖАЛИ ВСЕ. Все. Если сделать регламент - никто его соблюдать не будет. Да и смотрящих нет, некому их заставлять его выполнять :)

Сейчас будем спорить что же такое регламент и цитировать вики))

под регламентом имелось ввиду исключельно взаимодействие между подразделениями. Чтобы минимизировать случаи, когда левая рука не в курсе, что делает правая и приоритетность выполнения. Проекты меняются очень часто и задачи тоже. Всех пугает жесткий контроль, но еще больше раздражает время ожидание от коллег или переброс от задач к задачи. Идея в том, чтобы с помощью редмайна контроллировать ход проектов, и чтобы коллеги друг другу палки в колеса не вставляли.

Тут надо Ваш контекст понимать, так сложно. В общем случае желательно строить самодостаточные команды, которые любую фичу могут сделать без зависимостей.

Толмачев нам очень хорошо это дело (Mob Prorgamming) поставил. Думаю он может подсказать.

спасибо

Предполагаю, что ответ про Толмачева был дан Алексею на вопрос о mob programming :)

а у вас тестирование и багфикс в Definition of done не включены?

а у вас тестирование и багфикс в Definition of done не включены?

А как быть с багами, которые были найдены по закрытым в прошлых спринтах историям?