то есть как не нужен!??! чо я зря чтоли в сертификацию вкладывался!??!

)

пфф)

вы застряли с устаревшим мышлением если думаете что размер вашего сертификата это важно :D

Ща мы с Глебкой обоснуем ему за сертификаты

то есть как не нужен!??! чо я зря чтоли в сертификацию вкладывался!??!

Лучше бы в развитие скилов пророка и телепата вкладывался.

Говоря об аналитике в agile :)

А если без смехуечков, то выделенная роль архитектора иногда нужна, но чаще команда должна знать паттерны и подходы к архитектуре (что далеко не rocket science) и применять то, что им удобно и что они сами считают оптимальным.

ВЫделенная архитектурная роль - чаще всего антипаттерн

Тут вопрос масштаба, у нас например огромная экосистема. И продукт 99% времени не касается солидной ее части.

Команда мыслит на уровне продукта. Архитектор на уровне экосистемы

Ну да, в некоторых случаях архитектор (или команда архитекторов) может быть

как и интерфейс так и архитектура

прорабатывается нескоько вараинтов

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

)

простите в быквы не попадаю (

Ну типа так же, как есть оргструктура всегда за пределами скрам тим? Она же существует, ведь верно. По идее архитектор вполне может контирбьтит для беклога с контроль продукт оунера.

Я тоже :) Ну то есть как один из стейкхолдеров он может присутствовать, к примеру.

Я заранее извиняюсь за чушь, если я ее несу. Просто хочется послушать советов бывалых.

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

Если это уровень constraints и общих требований - все ок.

Если это конкретные решения... ну, иногда это оправданно, чаще всего - нет.

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

С другой стороны, если команд много, то тут уже нужны организационные стандарты, которые вполне могут быть частью ДоД

у кого-нибудь есть опыт написания плагинов для редмайна?

Увольте терминатора

зачем? он хороший...

Но ленивый

😒 он хорошо фильтрует

да че-т не особо походу

Где-то 1 из 10 пропускает, по моим ощущениям

Как формулировать цель Спринта по мнению Романа Пихлера https://www.romanpichler.com/blog/sprint-goal-template/

Основная идея - ответить на три вопроса. Зачем мы делаем что-то в Спринте. Как этого достичь и как понять что мы ее достигли

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

А вот комментарии не увидел. Похоже то, что надо

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

Ну куча обсуждений и статей таких была Суть в том, что это само по себе дисфункция

От этого надо избавляться

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

Именно так и есть :) И в целом это потеря фокуса.

От цели? Или от нескольких блоков-направлений?

От цели? Или от нескольких блоков-направлений?

От надергивания в один спринт разной не связанной хрени

Походу для охоты на ботов тут нужен Т-1000

Ну вот смотри. Есть сейчас у нас несколько блоков - ввод функционала работы с маркировкой табака (требования регулятора), ввод новой версии документов для работы с алкоголем (требование регулятора), ввод с 1 января НДС 20% (требование регулятора). Развитие функционала касс (удобство использования). Ну вот крупными мазками

Это разные наборы требований. Но продукт один

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

Но все они нужны и важны

Так а зачем каждой команде дергать из каждого набора?

Все команды одинаковые. Все могут сделать все фичи.

И что, это автоматом означает, что все команды должны делать все фичи?

Они сами выбирают что делать. Скрам.

Не вижу с этим проблем. Они шарят знания и снижают риски.

Ну вот выбирают-выбирают и опа, потеря фокуса :)

Проблема как дать им фокус, да.

В это и закопался.

Сергей, ты ищешь единственно правильный метод?:)

Ограничить их одним набором неправильно. Сейчас у них получается фичи из двух-трех наборов. Я ищу способ дать команде цель.

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

Бэклог как раз и сформирован по этим наборам. Это и есть нужды бизнеса по сути. На последнем планировании цель сформировали по наборам. Получилось уже лучше. Более верхнеуровнево, но по крайней мере что-то определенное и понятное. Дальше буду копать

Нормально ли когда часть элементов бэклога (пусть даже самых неважных из всех) выпадает из сформулированной цели?

Я имею ввиду Бэклог Спринта

Реально ли охватить все элементы? У кого как из практики?

Ищите родственные 2-3 блока и обобщайте целью

Необязательно подбирать "целевой" скоуп аккурат под размер спринта. Если он займёт 60-80% - отлично. Остальное засыпьте песком. Главное - достичь цели. Если попутно разберётесь с мелочью, то хорошо. Если нет, всё равно в выигрыше - цель достигнута.

Допустим, есть в продуктовом беклоге 10 блоков. Лучше взять в команду 1,2 и 8 - однородные, которые можно обобщить одной целью. Нежели взять 1,2,3,4 - пускай помещающиеся, но описывающие две разные цели. Две разные цели способны порвать весь спринт и в итоге как в пословице про двух зайцев.

Может я чего не понимаю, но по логике, если 1, 2 и 8 не дадут MVP, то 1,2,3,4 тем более MVP не дадут. ))) 3 и 4 из другой оперы слегка, а 1,2,8 > 1,2. ))

Это просто не работает на дальнюю перспективу

поэтому лучше сразу принять, что она тоже может итеративно меняться, а не высечена в камне 😄

Необязательно подбирать "целевой" скоуп аккурат под размер спринта. Если он займёт 60-80% - отлично. Остальное засыпьте песком. Главное - достичь цели. Если попутно разберётесь с мелочью, то хорошо. Если нет, всё равно в выигрыше - цель достигнута.

👍

За один спринт вообще сложно mvp достичь.

Поэтому не расстраивайтесь, и делайте mvp за пару спринтов =)

Жаль нет возможности долго спорить :)

В общем, если вы делаете MVP за несколько спринтов, вы его делаете еврей неправильно ;)

И скорее всего путаете MVP c MMP:)

или MDP 😁

MMP более распространённый :)

maximum malfunction product?

Хехе

Minimum marketable product

Необязательно подбирать "целевой" скоуп аккурат под размер спринта. Если он займёт 60-80% - отлично. Остальное засыпьте песком. Главное - достичь цели. Если попутно разберётесь с мелочью, то хорошо. Если нет, всё равно в выигрыше - цель достигнута.

Спасибо. Так и есть сейчас. Но так «теряется» часть элементов. Этого и хочу избежать.

Поэтому не расстраивайтесь, и делайте mvp за пару спринтов =)

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

В общем, если вы делаете MVP за несколько спринтов, вы его делаете еврей неправильно ;)