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

+ cost of delay для разработчиков на основе данных, которые у вас есть

Не успевают обслуживать скрам-команды, не успевают поставлять данные аналитикам для формализации сторей

У нас один Владелец на семь команд :)

Я прочёл: у нас один Властелин колец )))

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

What if I tell you, что 7 команд могут работать из одного бэклога?:)

What if I tell you, что 7 команд могут работать из одного бэклога?:)

Только если так

What if I tell you, что 7 команд могут работать из одного бэклога?:)

Then, кто ты? куда ты дел Павла? =) я помню был разговор раньше про то, что одновременная работа нескольких команд над одним беклогом - это скорее иллюзия..

Then, кто ты? куда ты дел Павла? =) я помню был разговор раньше про то, что одновременная работа нескольких команд над одним беклогом - это скорее иллюзия..

Съел. Его хватило почти на две недели, и еще осталось немного салатиков и холодец...

Да, иллюзия, но и работа одного PO с 7 командами - иллюзия. Просто в какой-то момент кто-то осознает, что в командах давно уже есть прокси :)

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

А зачем семь? Один!

Я кстати понял недавно, почему в LeSS Huge у одного Area Product Owner желательно иметь от четырех и более команд. Инача будет семь бэклогов и семь продактов.

Опять подискутируем про количество бэклогов?:)

Не, а то выгонят :)

Опять подискутируем про количество бэклогов?:)

ночью разве что)

Да я понял, что чат - не место для дискуссий :)

😂

в @agile_jobs пожалуйста)

Я кстати понял недавно, почему в LeSS Huge у одного Area Product Owner желательно иметь от четырех и более команд. Инача будет семь бэклогов и семь продактов.

Прикольно. Я думал что АПО на одну команду, беклог продукта один. 2 бэклога, уже 2 продукта.

Но safe все равно интереснее.

Но safe все равно интереснее.

Чем?:)

Круче продукт упакован..

Это да.

Лучшй фреймфорк для консультантов :)

И всегда можно менеджеров пристроить

А это минус... или нет :)

Технически их надо переучить

Это огромный плюс.

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

очень много зависимостей, но все цели разные по итогу

общие

Нужно немного больше контекста :)

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

очень много зависимостей, но все цели разные по итогу

Да не, все понятно. Вельюстримы постройте и дайте информацию командам. И попросите разделиться на команды по стримам. А в чем проблема?

Блин, не сочти за агрессию и сарказм.

Но раскажи, как построить вельюстрим, а потом попросить команды разделиться?:)

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

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

Рискну предположить что у вас поставка разным клиентам. Развертывайте проектный офис, эшелонируйте проекты на пересекающихся задачах/ресурсах. Внутри каждого проекта scrum/xp/crystal/aup/... Контролируйте проекты по ccpm или reliable scrum

Рискну предположить что у вас поставка разным клиентам. Развертывайте проектный офис, эшелонируйте проекты на пересекающихся задачах/ресурсах. Внутри каждого проекта scrum/xp/crystal/aup/... Контролируйте проекты по ccpm или reliable scrum

И начинайте оазделять core и custom

У нас в команде два разработчика и один продукт овнер. Лучше бы он код писал, толку больше было бы. У меня всё. *Идёт в выходной на работу закрывать квартал за просто так*

У нас в команде два разработчика и один продукт овнер. Лучше бы он код писал, толку больше было бы. У меня всё. *Идёт в выходной на работу закрывать квартал за просто так*

У вас нет команды, судя по вашим словам )

У вас нет команды, судя по вашим словам )

Ну вот) а как это определить?)

Ну вот) а как это определить?)

Я думаю самое главное это общее понимание, общая цель, желание двигаться в одну сторону.

И начинайте оазделять core и custom

Я подумал что это неизбежно произойдет, как только начнется оформляться проектный офис. Так как придется формализовать проекты и их зависимости.

Я подумал что это неизбежно произойдет, как только начнется оформляться проектный офис. Так как придется формализовать проекты и их зависимости.

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

Рискну предположить что у вас поставка разным клиентам. Развертывайте проектный офис, эшелонируйте проекты на пересекающихся задачах/ресурсах. Внутри каждого проекта scrum/xp/crystal/aup/... Контролируйте проекты по ccpm или reliable scrum

да, есть примерно 10 стейкходеров +- у кторых свои цели/задачи, скоорденировать их очень трудно. Пректный офис уже формируется и я его лид, но пока все очень трудно идет

да, есть примерно 10 стейкходеров +- у кторых свои цели/задачи, скоорденировать их очень трудно. Пректный офис уже формируется и я его лид, но пока все очень трудно идет

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

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

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

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

А как вы думаете есть какие общии правила построения процесса разработки или "правила хорошего тона". Интересует именно взаимодействия между людьми в каманде

А как вы думаете есть какие общии правила построения процесса разработки или "правила хорошего тона". Интересует именно взаимодействия между людьми в каманде

Так люди или процессы?

А как вы думаете есть какие общии правила построения процесса разработки или "правила хорошего тона". Интересует именно взаимодействия между людьми в каманде

Эти понятия ортогональны. Процессы это про функции, не про людей

А как вы думаете есть какие общии правила построения процесса разработки или "правила хорошего тона". Интересует именно взаимодействия между людьми в каманде

Подозреваю, вопрос, как построить хорошую культуру разработки в команде?

Подозреваю, вопрос, как построить хорошую культуру разработки в команде?

Да) вы меня поняли)

Да) вы меня поняли)

Есть конечно, это очень хорошо описано в книгах по XP

Да) вы меня поняли)

https://worksection.com/blog/extreme-programming.html Для начала ознакомления, и берите инженерные и командные практики, они проверенны они работают.

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

Спасибо большое

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

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

Вы знаете, достаточно использовать правила описанные в Agile manifesto. Использовать их хорошо помогает scrum. И, конечно, как Сергей написал - практики XP. Самое важное в формировании команды - думать о ценностях, которые лежат в основе scrum, xp, lean и т.д. Но следовать им непросто, нужен хороший фасилитатор и лидер, чтобы ценности из бумаги перекочевали в головы.

А процессы подтянутся, когда майндсет начнет формироваться.

Хотя с другой стороны процессы могут помочь сформировать майндсет )

Хотя с другой стороны процессы могут помочь сформировать майндсет )

в таком случае процессы будут подстроены под текущий майндсет :D

в таком случае процессы будут подстроены под текущий майндсет :D

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

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

👍

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

а как тогда появляются мифы что скрам это куча безполезных митингов?

а как тогда появляются мифы что скрам это куча безполезных митингов?

Я думаю такие мифы появляются, когда не обращают внимание на смысловое наполнение скрама - его ценности и предназначение.

Я думаю такие мифы появляются, когда не обращают внимание на смысловое наполнение скрама - его ценности и предназначение.

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

я для себя выработал правило - mindset goes first

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

А как по-вашему менять майндсет?

А как по-вашему менять майндсет?

надо объяснять почему надо именно так

как - так?

и тут вопрос даже не в том чтобы объяснить процесс

а почему надо работать с заказчиком постоянно

почему не проблема если у него поменялись хотелки

если честно процесс в данном случае не важен

так как он будет выстроен каким либо образом

Делаешь скрам, разъясняешь его активности и дальше поддерживаешь его, наблюдая как фреймворк заставляет людей меняться. Не без помощи, но все таки.

адаптация блабла уважение блабла прозрачность....

так на практическом примере помогаешь понять требуемый майндсет

адаптация блабла уважение блабла прозрачность....

вот на блабла и рождаются мифы про безполезность :) скрам оч сложный чтобы его осознать без наличия майндсета. команда не осозновая ценности митингов начинает искать свою ценность в них.