Нет, сугубо математика :)

Что на другой?:) Эксперимент 3 недели не оправлался

3 недели маловато, тем более вы им не помогали в шторминг побыстрее попасть и выйти из него. Люди друг друга первый раз видели, все коммуникации по сути заново выстраивать. На такое 2-3 месяца нужно с коучем, тогда будет эффект. А без коуча до полугода :) вопрос в том - как надолго вам нужна команда? Инвестиции в себя она отобьет очень быстро потом

Нет, сугубо математика :)

Зарплатная ведомость?)))

3 недели маловато, тем более вы им не помогали в шторминг побыстрее попасть и выйти из него. Люди друг друга первый раз видели, все коммуникации по сути заново выстраивать. На такое 2-3 месяца нужно с коучем, тогда будет эффект. А без коуча до полугода :) вопрос в том - как надолго вам нужна команда? Инвестиции в себя она отобьет очень быстро потом

Спасибо за конкретику! На этот проект уже точно не рентабельно. За сколько по вашему опыту команда отбивает инвестиции, если посадка вместе это рост костов на 15% минимум?

Больше, им еще кого-то вроде скрам мастера нужно. Факторов очень много, за 3-4 месяца они в 0 выйдут, эти 15% точно отобьют. Так предел производительности в 3-4 раза можно увеличить. Но заметьте - как по волшебству не бывает, людей нужно учить работать иначе

И "учить работать иначе" это тоже кост

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

Кто-нибудь может поделиться примерами описания архитектуры системы в методиках togaf, feaf, archimate? Всех знакомых архитекторов обошел, никто не сталкивался( Если оффтоп, прошу извинить, удалю вопрос

Кто-нибудь может поделиться примерами описания архитектуры системы в методиках togaf, feaf, archimate? Всех знакомых архитекторов обошел, никто не сталкивался( Если оффтоп, прошу извинить, удалю вопрос

А точно интересует архитектура систем? Я сталкивался с описанием архитектуры предприятия. Всем привет)

А точно интересует архитектура систем? Я сталкивался с описанием архитектуры предприятия. Всем привет)

Да, крупная система, просят именно в этой методике. Можно поделиться примерами в личку?

Да)

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

Да она и сейчас достаточная. Мне не видно проблем с договоренностями, вполне общаются. Единственная сложность - брейнштормов нет, а обсуждения нуждаются в очень четкой фасилитации. Даже в 2 раза рост эффективности - это уровень разработки бог. Мы сейчас +- в тех же темпах, что стационарные команды других продуктов в том же стеке технологий. Информация со слов их РО. В 2 раза мы выросли после настройки коммуникаций и инструментов.

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

Кто-нибудь может поделиться примерами описания архитектуры системы в методиках togaf, feaf, archimate? Всех знакомых архитекторов обошел, никто не сталкивался( Если оффтоп, прошу извинить, удалю вопрос

В группе spbsoa в ВК выложены материалы

А на ютуб-канале мастер-класс по моделированию архитектуры в archimate

Кто-нибудь может поделиться примерами описания архитектуры системы в методиках togaf, feaf, archimate? Всех знакомых архитекторов обошел, никто не сталкивался( Если оффтоп, прошу извинить, удалю вопрос

В чате @spbcoa можно спросить о практическом опыте, там есть такие аналитики

Благодарю

Другое дело, что в @itarchitect есть настоящие архитекторы

Коллеги, добрый день. Подскажите как учитывать процессорные активности? По кейсу, который для меня очевиден и хорошо задокументирован потратил сегодня несколько часов на объяснения коллегам аналитикам. Подобное было и вчера, весьма вероятно будет и завтра. Как такие активности учитывать в скраме?

Коллеги, добрый день. Подскажите как учитывать процессорные активности? По кейсу, который для меня очевиден и хорошо задокументирован потратил сегодня несколько часов на объяснения коллегам аналитикам. Подобное было и вчера, весьма вероятно будет и завтра. Как такие активности учитывать в скраме?

а каков был результат всстречи ? появились уточненные задачи ?

Уточнение Бэклога Продукта (PBR) – это деятельность, направленная на уточнение, оценку и упорядочивание элементов в Бэклоге Продукта. Речь идет о непрерывном процессе, в рамках которого Владелец Продукта и Команда Разработки обсуждают детали Элементов Бэклога Продукта, тем самым проверяя и пересматривая эти элементы.

Результат: все понятно, вопросов нет. Никакие дополнительные задачи, активности не возникли.

Скрам-команда решает, как и когда должно производиться Уточнение Бэклога Продукта. Обычно этот процесс занимает не более 10% от доступного времени Скрам-команды. При этом Элементы Бэклога Продукта в любой момент времени могут быть изменены как самим Владельцем Продукта, так и по его указанию.

Скрам-команда решает, как и когда должно производиться Уточнение Бэклога Продукта. Обычно этот процесс занимает не более 10% от доступного времени Скрам-команды. При этом Элементы Бэклога Продукта в любой момент времени могут быть изменены как самим Владельцем Продукта, так и по его указанию.

Это не PBR. Другая активность. Мой вопрос актуален.

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

Коллеги, добрый день. Подскажите как учитывать процессорные активности? По кейсу, который для меня очевиден и хорошо задокументирован потратил сегодня несколько часов на объяснения коллегам аналитикам. Подобное было и вчера, весьма вероятно будет и завтра. Как такие активности учитывать в скраме?

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

Это не PBR. Другая активность. Мой вопрос актуален.

Это ваше НоуХао, если я правильно понял то Вы потратили время чтобы написать документ а потом потратили время чтобы объяснить

Это ваше НоуХао, если я правильно понял то Вы потратили время чтобы написать документ а потом потратили время чтобы объяснить

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

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

Вопрос: как в спринт беклоге зафиксировать процессную деятельность? Либо сделать таск "Консультация"

А зачем фиксировать это в спринт бэклоге?

Просто у вас велосити упал. Считай учли.

А упал он из-за отсутствия общего понимания.

Тут скорее вопрос надо ставить - зачем вы объясняли другим аналитикам? Или - почему они не были в курсе раньше?

Тут скорее вопрос надо ставить - зачем вы объясняли другим аналитикам? Или - почему они не были в курсе раньше?

или почему они не могут прочитать документ)))

А зачем фиксировать это в спринт бэклоге?

у нас по процессу/kpi задачи выполненые сверх запланированных поощряются. Я хочу деятельность оформить в виде задачи, списать на нее время.

у нас по процессу/kpi задачи выполненые сверх запланированных поощряются. Я хочу деятельность оформить в виде задачи, списать на нее время.

Хорошо у вас. продуктивно :)

у нас по процессу/kpi задачи выполненые сверх запланированных поощряются. Я хочу деятельность оформить в виде задачи, списать на нее время.

А зачем списывать время? Разве не важнее дать ценность для потребителя?

А зачем списывать время? Разве не важнее дать ценность для потребителя?

Процесс такой, KPI завязан. Время списал - деньги получил

у нас несколько скрам команд. Наша работала над ценностью. По результатам квартала смотрели велосити, но так же был показатель "задачи овер плана" у нас пусто, у других команд был. С т.з. РО они больше молодцы.

Жутковато звучит.

Как будто есть велосити, а есть еще сверхвелосити. Такой способ соковыжимания )

Какая то жуть

GosAgile что вы хотите)

у нас несколько скрам команд. Наша работала над ценностью. По результатам квартала смотрели велосити, но так же был показатель "задачи овер плана" у нас пусто, у других команд был. С т.з. РО они больше молодцы.

А вообще корректно ли сравнивать велосити разных команд?

Во первых какой в этом реальный смысл Во вторых каким образом сравнили? По количеству стори сравнивать некорректно имхо

А вообще корректно ли сравнивать велосити разных команд?

Хороший вопрос, надо Скрам оф Скрам погуглить.

Во первых какой в этом реальный смысл Во вторых каким образом сравнили? По количеству стори сравнивать некорректно имхо

Сколько запланировали, сколько по факту выполнили

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

Сколько запланировали, сколько по факту выполнили

Выполнили в каком смысле? Стори поинты или бизнес велью?

На мой взгляд такое сравнение применимо только к сферическим средним командам в ваакуме)

Может я ошибаюсь, просто мое личное мнение...

Выполнили в каком смысле? Стори поинты или бизнес велью?

Стори поинт. С бизнес велью все сложно. Условно её функцию выполняет приоритет (блорек, высокий, средний, низкий)

Как сравнить велосити команд , измеряюх pbi в майках, ряду Фебоначчи и от 1 до 5?))

у нас несколько скрам команд. Наша работала над ценностью. По результатам квартала смотрели велосити, но так же был показатель "задачи овер плана" у нас пусто, у других команд был. С т.з. РО они больше молодцы.

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

Короче читят)))

они должны брать больше задач и в ноль выйти

В итоге через пару спринтов в идеале все должны делать ровно столько насколько закомитались верно?

Как сравнить велосити команд , измеряюх pbi в майках, ряду Фебоначчи и от 1 до 5?))

на глаз!

они должны брать больше задач и в ноль выйти

А вечно делать больше ну давайте посудим это вообще реально?

Велосити стремится к бесконечности)

Закон: что измеряем, то и получаем. Все будут показывать 70-90 sp. А объем работы ни кого волновать не будет.

Именно)) не в бровь, а в глаз👍

Есть очень простой способ увеличить велосити.

До любой цифры.

Нужно на ретро решить оценку умножать на 2?

Просто переопределите значение SP - пусть айтем на 5 стоит 8, например.

Остальную шкалу под это подгоните - велосити вырастет.

В цифрах, разумеется :)

👍

Просто переопределите значение SP - пусть айтем на 5 стоит 8, например.

Как избежать? Давно мучает вопрос. Всегда можно по запросу "увличить велосити" получить самый простой способ ее увеличения.

Не использовать велосити как метрику эффективности команды

Зачем стремиться увеличивать велосити? Если уж так хочется ее использовать не только для планирования , то оцениваете добавленную стоимость 1 балла велосити, например. Но Паша О. выше правильнее сказал:"Не используйте как показатель". Оцениваете команду по продукту.

Зачем стремиться увеличивать велосити? Если уж так хочется ее использовать не только для планирования , то оцениваете добавленную стоимость 1 балла велосити, например. Но Паша О. выше правильнее сказал:"Не используйте как показатель". Оцениваете команду по продукту.

А как оценивать продукт?

А как оценивать продукт?

Метрики оценки продукта же есть. Например, опрос удрвлетворенности пользователей как минимум. Воронки использования продукта. Время юзера на этапе. Много всего, для каждого продукта свое специфическое.

Метрики оценки продукта же есть. Например, опрос удрвлетворенности пользователей как минимум. Воронки использования продукта. Время юзера на этапе. Много всего, для каждого продукта свое специфическое.

Да, и тут наверное ключевое, перед тем как что то делать команде разработки Владелец продукта должен иметь метрики.

Метрики оценки продукта же есть. Например, опрос удрвлетворенности пользователей как минимум. Воронки использования продукта. Время юзера на этапе. Много всего, для каждого продукта свое специфическое.

есть текущие задачи, у которых "хорошее" бизнес велью, есть переспективные/иновационные которые делать надо, но результат будет не сразу.

Да, и тут наверное ключевое, перед тем как что то делать команде разработки Владелец продукта должен иметь метрики.

Оооо, это от среды зависит ))) Я бы сказал, что это "было бы круто считать". У меня просто времени нет двинуться дальше оффлайн опроса. Идей много, но среда не даёт.

Зачем стремиться увеличивать велосити? Если уж так хочется ее использовать не только для планирования , то оцениваете добавленную стоимость 1 балла велосити, например. Но Паша О. выше правильнее сказал:"Не используйте как показатель". Оцениваете команду по продукту.

Что даст оценка команды по продукту? За какую часть отвечает команда?

Метрики оценки продукта же есть. Например, опрос удрвлетворенности пользователей как минимум. Воронки использования продукта. Время юзера на этапе. Много всего, для каждого продукта свое специфическое.

Это разве не продакт должен делать?