😂Почитать вас интересно

Спасибо.

Только не по технологиям, а по уровню понимания проблем пользователя :)

И вот ЭТУ специализацию ты безболезненно не предотвратишь :)

Даже кобол-мафиозо проще обучитьч ему-то еще :)

ТАк вот такие команды тоже отлично специализируются :)

Я с этим согласился. Я про потерю гибкости в случае нескольких бэклогов и как избежать этого рассказал.

Только не по технологиям, а по уровню понимания проблем пользователя :)

А тут нам LeSS говорит про практики общения команд напрямую с пользователями. И тут все сложно.

Я с этим согласился. Я про потерю гибкости в случае нескольких бэклогов и как избежать этого рассказал.

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

т.е. вот, все оптимистично, команды - эксперты в пользвоателях, только каждый в своей группе. Нормальное T-shaped понимание продукта.

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

Я же рассказал как это делается в LeSS :)

Я же рассказал как это делается в LeSS :)

Нет, ты рассказал, как это делается в самом начале.

Я устал, давай тормознемся ;) У меня нет столько аргументов.

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

Потому что если ответ "ничего", то поздравляю, у тебя несолько бэклогов :)

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

Ну я привел практику чередования выборки элементов на планировании.

Сергей, а в чем эффективность чередования?

Команда получила знания о проблемах реальных пользователей... и ушла решать проблемы других пользователей?:)

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

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

Ну ок, я спорю ради спора.

У нас снег выпал, даже погулять не сходить :)

У нас вчера -1 с утра был

У нас снег выпал, даже погулять не сходить :)

А почему не сходить?

А вы где?)

Да, на снегоступах

😃

Я в Ульяновске

А почему не сходить?

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

А вы где?)

Я в Миннеаполисе :)

Разброс 🙂 Скрам шагает по планете

Да уж.

Но, Сергей, я так и не понял, зачем в LeSS применяют метод ротации :)

Это одна из практик.

Т.е. если отсутсвтие глубокого понимания групп пользователей командами - цена за единый бэклог, то я пас :)

С другйо стороны, мне и подход SAFe не нравится

Я вообще зануда, хехе :)

Пользователи одни и те же. PBR каждого элемента делают по возможности все команды. Допустимо использовать однокомандный PBR, но это крайность. Рекомендация - все команды знают все элементы и могут их реализовать.

Кто берет элемент решается на планировании.

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

Я вообще зануда, хехе :)

Еще какой!

А теперь возвращаясь к бэклогам. Так как вот таким командам обрабатывать свои результаты ретро?

PBI рождённые Scrum Team на ретро идут в следующий Sprint Backlog напрямую, без Product Backlog. Если таких PBI команда за ретро насочиняла в сумме больше спринта, то поступаем как и в случае с Product Backlog - приоритезируем =) Я бы сказал, что если команда за спринт будет делать хотя бы по одной PBI для саморазвития - они уже крутые.

(моё текущее понимание)

С первым снегом =)

PBI рождённые Scrum Team на ретро идут в следующий Sprint Backlog напрямую, без Product Backlog. Если таких PBI команда за ретро насочиняла в сумме больше спринта, то поступаем как и в случае с Product Backlog - приоритезируем =) Я бы сказал, что если команда за спринт будет делать хотя бы по одной PBI для саморазвития - они уже крутые.

Это не всегда верно и приоретизация не всегда спасет :)

Давай конкретнее =) можно на примерах

Ладно, кобол обсудили, на SAFe фыркнули, LeSS похвалили - все ок :)

Давай конкретнее =) можно на примерах

Да вон, выше, пример со спайками у мейнфреймовой команды :)

Почему нельзя взять только один спайк в спринт? Или ситуация настолько сложная, что без всех спайков, в сумме дающих больше спринта, нельзя дальше разрабатывать продукт? Тогда кто-то продолбал свою роль =)

PBI рождённые Scrum Team на ретро идут в следующий Sprint Backlog напрямую, без Product Backlog. Если таких PBI команда за ретро насочиняла в сумме больше спринта, то поступаем как и в случае с Product Backlog - приоритезируем =) Я бы сказал, что если команда за спринт будет делать хотя бы по одной PBI для саморазвития - они уже крутые.

Create a plan for implementing improvements to the way the Scrum Team does its work. Имхо тут важно, что это не спайки или техстори. Это именно про команду. Все остальное у нас, например, решается в Community of practics.

Create a plan for implementing improvements to the way the Scrum Team does its work. Имхо тут важно, что это не спайки или техстори. Это именно про команду. Все остальное у нас, например, решается в Community of practics.

Да, хорошее замечание. Согласен.

Спайки и техстори - в product backlog

Это не всегда верно и приоретизация не всегда спасет :)

И да, универсальных правил тут почти нет. Иначе давно автоматизировали бы всё и нас уволили =)

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.

И да, универсальных правил тут почти нет. Иначе давно автоматизировали бы всё и нас уволили =)

Да блин этот Скрам - фреймворк «Крути как умеешь». Главное элементы не выкидывай :)

Создатели LeSS намеренно туда добавили много рецептов, которые Скраму не противоречат.

За что им огромное спасибо.

Ладно, кобол обсудили, на SAFe фыркнули, LeSS похвалили - все ок :)

Канбан забыли ;)

Почему нельзя взять только один спайк в спринт? Или ситуация настолько сложная, что без всех спайков, в сумме дающих больше спринта, нельзя дальше разрабатывать продукт? Тогда кто-то продолбал свою роль =)

Продукт можно, ситуацию с CD улучшить нельзя. Спайки разные, потому что подходы разные, не факт, что тот, что команда возьмет в спринт, принесет позитивный результат :)

Спайк же

Мы на коммьюнити решаем такие вещи. Туда приходят люди из всех команд. Удобно.

https://scontent.ffcm1-2.fna.fbcdn.net/v/t1.0-9/44155139_2150462668311943_4932989322090512384_n.jpg?_nc_cat=111&oh=d41f5bff40550740e12eab1ed97af2a7&oe=5C60DA8E

:)

Я спать. Pavel спасибо за спор. Разговоры с Тобой позволяют задуматься.

Канбан забыли ;)

Как я мог!

Продукт можно, ситуацию с CD улучшить нельзя. Спайки разные, потому что подходы разные, не факт, что тот, что команда возьмет в спринт, принесет позитивный результат :)

Если devteam сама не может CD быстро наладить, то быть может это как раз прямой повод положить такую задачу в общий беклог - найдутся другие команды, которые сделают быстрее и лучше =)

Если devteam сама не может CD быстро наладить, то быть может это как раз прямой повод положить такую задачу в общий беклог - найдутся другие команды, которые сделают быстрее и лучше =)

Макс, по услвоиям кейса остальные команды к мейнфреймам отношения не имеют и радостно пилят свою жаву в облака :)

С мейнфреймами, кстати, «реальный случай» :)

Страховые, все дела.

А у меня вопрос, кстати, Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. Но почему-то все делают один митинг для этого обычно. Или у вас другая практика? Как у вас проходит рефайнмент беклога?

Мне кажется вы неправильно трактуете мультифункциональность. Знания должны расти в ширину, но отдаем себе отчет, что с глубиной будет средненько. Например, в команде не должен быть взращен графический дизайнер - вы не научите человека рисовать, но обращаться с графическими редакторами что бы что то себе нарезать или пару пикселей подвинуть - маст хэв и должен в теории научиться каждый. Есть специализация, а есть вторая/третья специальность - в данном ключе о развитии этих навыков идёт речь.

😂Почитать вас интересно

Применить здравые мысли на практике тоже очень интересно :) но боюсь мне никто не даст...

А у меня вопрос, кстати, Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. Но почему-то все делают один митинг для этого обычно. Или у вас другая практика? Как у вас проходит рефайнмент беклога?

Если не ошибаюсь, в рекомендациях 10% от времени спринта должен занимать PBR. У нас сейчас 5%. Спринт 2-недельный, 4 PBR митинга по 1 часу. Этого очень мало конкретно для нас. Скорость выпуска ready for dev очень маленькая. Трублю во все трубы, но пока встречаю сопротивление.

Если не ошибаюсь, в рекомендациях 10% от времени спринта должен занимать PBR. У нас сейчас 5%. Спринт 2-недельный, 4 PBR митинга по 1 часу. Этого очень мало конкретно для нас. Скорость выпуска ready for dev очень маленькая. Трублю во все трубы, но пока встречаю сопротивление.

Да, написано про 10.

Применить здравые мысли на практике тоже очень интересно :) но боюсь мне никто не даст...

Аналогично, пока не видно благодатной почвы…просто читаю, как про единорогов

Аналогично, пока не видно благодатной почвы…просто читаю, как про единорогов

😂👍🏻

Грезю волшебной страной, ага

Начал читать про less. Кроме самого фреймворка там в принципе обоснования толковые «зачем и почему». Посмотрим, куда заведет меня эта дорожка)

Если не ошибаюсь, в рекомендациях 10% от времени спринта должен занимать PBR. У нас сейчас 5%. Спринт 2-недельный, 4 PBR митинга по 1 часу. Этого очень мало конкретно для нас. Скорость выпуска ready for dev очень маленькая. Трублю во все трубы, но пока встречаю сопротивление.

а что мешает сделать 4х1.5 часа? типа минут на 30 задержались ... ;)

Тут я пас. Я много видел компаний с липовыми сертификатами. Как то не верю я в их магическую силу.

А я не про липовость, я про то что если вам нужно единообразие и повторяемость. Вот оно. Берите и внедряйте, будет работать, Главное не совершить основную ошибку. Технические проблемы - решать организационно Организационные - технически.

а что мешает сделать 4х1.5 часа? типа минут на 30 задержались ... ;)

Да всех вроде пока устраивает (кроме меня). Мол «вроде и так нормально работаем».

А у меня вопрос, кстати, Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. Но почему-то все делают один митинг для этого обычно. Или у вас другая практика? Как у вас проходит рефайнмент беклога?

Не все, но делать выделеный митинг для этого просто удобно. Рефайнмент это еще и набор скиллов, которые должны быть у команды.