Mikhail
И да, я не понимаю - нафига 3 недельный спринт, если вы несколько раз в неделю релизитесь?
Mikhail
условия задачи неполные :)
Dmitry
Ну потому что не хотят откладывать решение того,что мешает прямо сейчас. Обычно как бывает? Проблемв не решабтся годами. Вот тут хорошо помогает ретро. У них в другую сторону. Решают соазу. Я бы делал ретро, но ретро по результатам проека, этапа. Большое ретро
============ FALCON ============
Повторю тогда корневую проблему. Во время спринта возникают значимые явления, достойные обсуждения на ретро. Спринт длится 3 недели. Или для яркости давайте возьмём 4.
Проблема - приходится ждать конца спринта чтобы провести ретро, ибо так говорит гайд. Два компонента проблемы: за 3-4 недели уходит контекст и то, что легко обсуждать было "по месту" становится сложно обсуждать спустя 3-4 недели. Второй компонент - изменения принятые к действию на ретро вступят в силу в лучшем случае на следующем спринте.
Наше решение - уход от одного большого ретро после ревью к ряду асинхронных ретро по запросу. С сохранением тайминга, подготовки, реальности решений и прочих атрибутов. Нарушили только "правило" проводить ретро после ревью и до планирования.
А что мешает закидывать в доку все эти вопросы и опи ать контекст для ретро до этого самого ретро?
Алекс
А что мешает закидывать в доку все эти вопросы и опи ать контекст для ретро до этого самого ретро?
Проблема насколько я понимаю в том, что нужно каждый раз придумывать локальные улучшения
Dmitry
Идея была какая: постепенно отлаживать процесс. Шаг за шагом. Они это делают.
Dmitry
Да, скрам гайд говорит, что они теперь не скрам. Но не убогие, точно))
Max
И да, я не понимаю - нафига 3 недельный спринт, если вы несколько раз в неделю релизитесь?
Всё просто - это два разных примера
============ FALCON ============
Может на месте решать и хорошо, но тогда проблема возникает как раз с частотоц и свяханностью решений
============ FALCON ============
В конце спринта одним махом все вопросы по приориету же лучше?
Dmitry
Чем?)
Dmitry
Время ушло. 2 недели им что то мешало
Dmitry
Они копили. Злились)
Max
Проблема насколько я понимаю в том, что нужно каждый раз придумывать локальные улучшения
Это не локальные улучшения, а системные. Просто решения по ним принимаются не дожидаясь окончания спринта. Я так и не услышал рока почему ретро важно проводить строго после ревью и до планирования. Ну кроме аргументации к хрени =)
============ FALCON ============
Бедняжки) обиженные ходили на см
Dmitry
Хотя, я считаю, что чем больнее было, тем потом лучше решение)
Mikhail
не вижу смысла продолжать, сорри
Max
Вольному воля
Mikhail
Это не локальные улучшения, а системные. Просто решения по ним принимаются не дожидаясь окончания спринта. Я так и не услышал рока почему ретро важно проводить строго после ревью и до планирования. Ну кроме аргументации к хрени =)
Потому что обсуждение улучшений имеет смысл продолжать только после фиксации завершенного. Иначе риск спекуляций "а может быть", "а может не быть". Если у вас релиз и сбор обратной связи внутри спринта несколько раз, то и ок
Max
очень частое недопонимание когда думают что посреди спринта релизить нельзя :D
Это неверная трактовка описанного мной кейса. Я не утверждаю что релизиться посреди спринта нельзя. Сегодня это сложно себе представить в большинстве контекстов.
Мой кейс был в том, что есть команда которая может работать со скоростью 1 спринт в день. И что же им делать? Не называться скрамом? Форматировать свой процесс принудительно под 1 недельные таймбоксы, чтобы следовать гайду?
Mikhail
Это неверная трактовка описанного мной кейса. Я не утверждаю что релизиться посреди спринта нельзя. Сегодня это сложно себе представить в большинстве контекстов.
Мой кейс был в том, что есть команда которая может работать со скоростью 1 спринт в день. И что же им делать? Не называться скрамом? Форматировать свой процесс принудительно под 1 недельные таймбоксы, чтобы следовать гайду?
Знает ли эта команда сегодня что будет релизить в пятницу?
Max
Потому что обсуждение улучшений имеет смысл продолжать только после фиксации завершенного. Иначе риск спекуляций "а может быть", "а может не быть". Если у вас релиз и сбор обратной связи внутри спринта несколько раз, то и ок
Ревью - это гарантия фиксации завершенного? Можно ли зафиксировать частную проблему раньше ревью?
Mikhail
============ FALCON ============
А вся команда участвует в принятии этих улучшений?
============ FALCON ============
В обсуждении т. е.
Mikhail
Ревью, на котором мы точно знаем что сделано из запланированного, что не сделано и какая обратная связь - да, гарантия
Max
Знает ли эта команда сегодня что будет релизить в пятницу?
С некоторой вероятностью - да, беклог в актуальном состоянии поддерживается PO, он же в режиме реального времени смотрит на результат. Актуализация задач происходит каждое утро, каждый вечер - подведение итогов и задание дальнейшего вектора.
Mikhail
А вход в ретро вида: я хз успеем или нет, но вот проблема называется ежедневным скрамом
Almaz
Это неверная трактовка описанного мной кейса. Я не утверждаю что релизиться посреди спринта нельзя. Сегодня это сложно себе представить в большинстве контекстов.
Мой кейс был в том, что есть команда которая может работать со скоростью 1 спринт в день. И что же им делать? Не называться скрамом? Форматировать свой процесс принудительно под 1 недельные таймбоксы, чтобы следовать гайду?
А гайд и не запрещает делать 1 дневные спринты, ради бога
Almaz
I mean the scrum guide
Almaz
Другой вопрос в целесообразности
Pavel
А гайд и не запрещает делать 1 дневные спринты, ради бога
Скрам гайд вообще ничего не запрещает.
Pavel
Но зачем?:)
Almaz
🙈🙊🙉
Igor
Это неверная трактовка описанного мной кейса. Я не утверждаю что релизиться посреди спринта нельзя. Сегодня это сложно себе представить в большинстве контекстов.
Мой кейс был в том, что есть команда которая может работать со скоростью 1 спринт в день. И что же им делать? Не называться скрамом? Форматировать свой процесс принудительно под 1 недельные таймбоксы, чтобы следовать гайду?
у вас при спринте в один день все эвенты для скрама будут очень маленькие и проблем это не должно создать. буквально 5 минут на планнинг и 2 на ретроспективу :D
Igor
Скрам гайд вообще ничего не запрещает.
вообще то он много чего запрещает :D например быть PO в лице коммитета.
Pavel
Вот прям написано "запрещено"?:)
Igor
да
Pavel
А ссылку можно?
Pavel
На абзац.
Pavel
https://www.scrumguides.org/scrum-guide.html#team-po
Igor
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner
Pavel
Не написано, что "запрещено" :)
Pavel
Игорь, а запрет где?
Igor
написано что это один человек а не коммитет
Pavel
Правильно.
Pavel
Про запрет ничего не написано.
Pavel
Scrum guide вообще запретов не содержит. Просто если не следовать предписаниям - не получится scrum
Igor
это как раз запрет если вы внедряете скрам :D
Pavel
Нет же :)
Pavel
ОСОБЕННО если внедряю.
Pavel
Игорь, как вы думаете, какой самый надежный способ внедрить скрам?
Igor
себя не обманывать :D
Igor
и всех остальных
Pavel
А более адаптированно к скраму?:)
Igor
это именно адаптировано
Igor
об этом даже спрашивают на экзаменах
Igor
вопрос из разряда почему нельзя менять терминологию
Pavel
На экзаменах по скраму, замечу. Не по внедрению.
Igor
нельзя если вы хотите внедрить рабочий скрам
Pavel
Игорь, терминологию менять можно. На экзамене спрашивают, какие будут последствия.
Igor
эти последствия не дадут вам ничего внедрить :D
Igor
и кроме описанных в экзаменах будут еще куча других последствий
Pavel
Этого нигде не говорится и это очень... допущение
Pavel
Смена терминологии, если уж говорить о внедрение, вообще выступает индикатором того, что трансформация движется в сторону скрама.
Pavel
Но никак не является целью.
Igor
это показатель того что люди начинают подменять понятия
Igor
а скрам это коммуникативный фреймворк и подмена понятий для него смертельна.
Pavel
Игорь, если все артефакты, роли и ритуалы сущестивуют, поставка ценности достигается, но роли называются Team Lead, Project Manager и т.п. вместо scrum master и product owner - в чем конкретная проблема?:)
Pavel
На примере.
Pavel
Или абстрактно - не суть.
Pavel
Потому что, например, в ситуации трансформации из вотерфола, в предприятии с существующей сеткой ролей, заниматься изменениями ролей вместо работы с командой...
Pavel
Не думаю, что это приведет к успешному скраму.
Igor
в том что team lead имеет совершенно другие задачи и ответственности, project manager потому и менеджер что не занимается повышением ценности того что делает команда а занимается менеджментом команды.
Igor
так или иначе у вас все равно останутся те же роли вроде тимлида и проджект менеджера :D
Igor
даже если вы скажете что они вот должны другим заниматся