мне даже проще представить совмещение PO и SM (ну тоже так - поднапрягшись))

PO и SM не совместимы

мне даже проще представить совмещение PO и SM (ну тоже так - поднапрягшись))

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

Вы организуете скрам-коману из требуемых специалистов, чтобы на себя замкнуть весь цикл поставки

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

А что это значит - не включать, зарплату не платить? :)

PO и SM не совместимы

согласен

ну напр, рассматривать как ресурсы или внешнее окружение но, конечно, любя, ценя и одуховторяя!)) (а то ща как набегут "Стасы" всякие!))

Вся тема в том, чтобы замкнуть полный цикл внутри команды. Чтобы команда ни от кого не зависила. Если есть внешняя зависимости, которая неконтроллируется или не доступна on demand - то это проблема. Если этот "релиз менеджер" всегда все команда делает вовремя, то и вопроса нет о включении

То есть РМ должен быть внутри, он не разработчик, но влияет?

пишите лучше RM ;)

PM или PO, PM - в скраме нет

РМ - релиз менеджер - человек отвечающий за роадмап продукта

Роди PM нет в скраме

Вот. Теперь вообще не понятно ))

а RM, да правка в тему

что такое отвечать за роадмап продукта, владеть файлом на gdrive ?

в scrum вообще нет технический ролей, насколько мне известно комбинируйте с другими методологиями и фрейворками: DevOps, XP...

РМ - релиз менеджер - человек отвечающий за роадмап продукта

Релизной планирование делает PO

где-то здесь, кстати, любопытная картинка была...

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Russian.pdf - вот кстати гайд на русском

Фреймворк правда слово с точки зрения понимания бестолковое, но на "каркас", "процессный каркас" не решились :)

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Russian.pdf - вот кстати гайд на русском

👍Он развеет сомнения и наведёт порядок в голове)

Релизной планирование делает PO

ну после estimate'ов от команды - т.е. все-таки совместно с ней, так ведь?

Кто там про каноны спрашивал?) Про SM в девтим: Канон не запрещает скрам-мастеру быть разработчиком Хотя все сходятся к тому, что эта роль занимает 100% времени Диссонанса особо не будет, просто помимо коллективной работы над продуктом, SM отвечает за то, чтобы скрам работал Про PO в девтим: Примерно тоже самое, это еще реже встречается, но гайд не запрещает, ибо все кто делает инкремент это девтим Про RM Слава все верно написал Важен только готовый продукт, над ним работает команда и команда должна иметь все необходимые компетенции для создания продукта Никаких должностей там нету, но люди могут быть любых специальностей, если нужны)

ну после estimate'ов от команды - т.е. все-таки совместно с ней, так ведь?

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

То есть приоритет тупо выставляет?

Исходя из бизнеса и роадмапа.

А команда сама внутри скрама по приоритетам живет

Я чес говоря в йоте это увидел, и мне очень понравилось

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

Я бы не сказал, что PO ответственный за даты релизов Ответственность PO — это максимизация пользы от работы ДТ. Планированием релизов занимается PO для формирования ожиданий клиентов и тд, но он не берет на себя коммитменты по датам, например

То есть приоритет тупо выставляет?

Как PO угодно, так и выставляет. Главное доносить ценность для заказчиков.

Это не бизнес овнеры, а тех люди которые отвечают за правильное развитее платформ-сервисов.

Я бы не сказал, что PO ответственный за даты релизов Ответственность PO — это максимизация пользы от работы ДТ. Планированием релизов занимается PO для формирования ожиданий клиентов и тд, но он не берет на себя коммитменты по датам, например

А про комитты, никто не говорил. Есть инструменты для этого, например burn chart, который позволяет прогнозировать достаточно точно.

Я бы кстати был счастлив если бы мы совместно зафигачили орг структуры в виде схем для команд разного масштаба бизнеса - вот так шпаргалка ценная!

Это не бизнес овнеры, а тех люди которые отвечают за правильное развитее платформ-сервисов.

Кто такие бизнес овнеры? Инвесторы, акционеры, собственники?

А про комитты, никто не говорил. Есть инструменты для этого, например burn chart, который позволяет прогнозировать достаточно точно.

Инструменты для прогнозов есть, да)

Кто такие бизнес овнеры? Инвесторы, акционеры, собственники?

Те кто бизнес развитие в рамках коммерческих инициатив мутят.

Я бы кстати был счастлив если бы мы совместно зафигачили орг структуры в виде схем для команд разного масштаба бизнеса - вот так шпаргалка ценная!

Чего за оргструктуры?) А как же самоорганизация?)

Они про бабло.

Они про бабло.

Так-то нормальный РО всегда думает про бабло, если проект коммерческий.

Дим, один фиг все ищут правильные с точки зрения размера бизнеса оргструктуры самодостаточные и эффективные для нужного времени

Дим, один фиг все ищут правильные с точки зрения размера бизнеса оргструктуры самодостаточные и эффективные для нужного времени

Ну не все...

Ну точнее

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

Мне нравится подход - соберите сотрудников в одной комнате и профасилитируйте их встречу, на которой они объединятся в команды

Подходит далеко не всем

Это когда народу дофига

А как правило народу, вернее компетенций не всегда хватает в полном обьеме

Но там, где подходит - мотивация и результаты крутые

Профасилитировать

А так будет понятно, каких компетенций привлечь

Профасилитаторство

!

Слав, я тоже слово записал ))

А так будет понятно, каких компетенций привлечь

Так команда решит же Кого нанять надо)

Профасилитаторство

😁😁

А что делает ваш скрам-мастер, он профасилистаторствовал и уже сил на код не хватает

Так команда решит же Кого нанять надо)

Не все знают кого надо для полной эффективности.

Ты про каких то опытных гуру в тыще проектов говоришь

Кстати да SM это фул-тайм, я раньше думал что нет, но там все сложно. Особенно с ретроспективами

А что делает ваш скрам-мастер, он профасилистаторствовал и уже сил на код не хватает

Ну, поэтому я и говорю, что сейчас все идет к тому, что SM это фултайм

А что делает ваш скрам-мастер, он профасилистаторствовал и уже сил на код не хватает

если это гибрид с девтимом - то 100%! 😄

Не все знают кого надо для полной эффективности.

А что значит "полная эффективность"?

А что значит "полная эффективность"?

Ну если у тебя много plsql то есть dba для оптимизации отдельновзятыйй

Ты про каких то опытных гуру в тыще проектов говоришь

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

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

Согласен, но все зависит от задач бизнеса

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

Ну если у тебя много plsql то есть dba для оптимизации отдельновзятыйй

Ну, думаешь команда этого не поймет, если она знает, что много psql, даже если пока что нет дба?

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

Да, поэтому самоорганизация это про long perspective

На короткой дистанции - лучше лично найми пару супер спецов и дай им тз Они сделают и все рады И они уйдут

Но

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

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

И вопрос не про биг компани с кучей народа

Это удивительно, на самом деле.. Обычно, в стартапах и маленьких компаниях - самоорганизация by design

Хотя

Если никого нету, то наверно вопрос логичен)

Ну ты решил сделать что то. Ты бизнес. Есть деньги. Немного. Хочется эффективно их потратить. Ты задаешь масштаб, рынок, задачи. Надо людей набрать. Кого? )))

Но начинать лучше с малого Если айти продукт - лучше с программиста

Наверное лучше с перспективного CTO.