А как вы на практике это делаете?:)

Чуть позже отвечу

Механика тут https://less.works/ru/less/framework/product-backlog-refinement.html

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

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

В одном из вариантов планирование может происходить как ворлд кафе проходит. Тогда каждая команда побывает у каждой и поймёт оценку.

Но такой дизайн не очень прост в исполнении

В одном из вариантов планирование может происходить как ворлд кафе проходит. Тогда каждая команда побывает у каждой и поймёт оценку.

PI Planning?:)

Это не сарказм, кстати. Просто напомню, что концепция PI PLanning была не леффингвеллом придумана :)

Я не читал каноничный дизайн PI planning А те что видел - это далеко от LeSS

В сафе это планирование направлено на, в лучше из случаев, на выявление зависимостей

в LeSS - на поддержку общего конектста в такой большой команде

В сафе это планирование направлено на, в лучше из случаев, на выявление зависимостей

Ммм, нет, оно больше про единый контекст.

У SAFe и LeSS одинаковая цель у big room planing.

Процесс сильно отличается.

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

Не. Они одинаковые. Мы на Overall PBR с представителями всех команд (два от каждого, всего 14-15 человек) берем из бэклога очередной элемент. Продакт рассказывает о нем. Все задают любые вопросы. Это поверхностный анализ, для того, чтобы понять какие компоненты задействованы и объем работы. Потом с помощью карт (числа фибоначи) высчитываем ОБЩУЮ оценку. Если оценка больше 13SP мы разделяем ее на более мелкие истории и снова оцениваем. Потом команды выбирают из списка оцененных элементы с 8 и 13 SP и забирают их на командный или многокомандный PBR. Там уже копают ее до деталей и формируют приемочные критерии. После этого история Ready для Спринта. И за несколько дней до Планирования они дополнительно на таком же мероприятии презентуют (три минуты) критерии и кратко говорят об элементе. Решение о том какая команда будет делать конкретную задачу максимально оттягивается до планирования.

Таким образом все оценки одинаковы для всех команд

Как-то это не похоже на team owns it tools :)

Ну я ХЗ, все как в LeSS guide. Все продумано. Я ссылку приводил :)

Сергей, так я не спорю :)

У меня с LeSS вообще часто взырв мозга случается в последнее время :)

Твои английские словечки меня иногда в ступор вводят :)

Твои английские словечки меня иногда в ступор вводят :)

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

В одном из вариантов планирование может происходить как ворлд кафе проходит. Тогда каждая команда побывает у каждой и поймёт оценку.

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

И по понятным причинам agile я с семьей не обсуждаю :)

В результате ВСЕ команды знают ВСЕ задачи.

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

Да я шучу. Просто мне язык подтягивать надо :)

А мне русский не забыть :)

Я первый год внутренне прикалывался над иммигрантами и рунглишем. На второй год понял, что сам говорю на рунглише :)

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

ладно, давай обратно к LeSS

Ну про оценки понятно?

Понятно, хотя я не согласен с методом :)

По идее копать надо все истории, но мы пока делаем на 8 и 13, этого вполне достаточно.

Понятно, хотя я не согласен с методом :)

По моему все просто.

Я не говорю, что сложно. Я говорю, что с методом не согласен :)

В чем?

Во первых, anchoring - установка внешнего эстимейта перед тем, как задача в команду попадет. Во вторых, оценка представителями разных команд != оценке командами

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

Так после этого элемент уходит на многокомандный PBR и там оценка может быть уточнена. Там все команды.

Сергей, да.

Но якорь уже задан.

И не командой.

Ну наверное он не идеален. Бывает и все сделали, а в Спринте элемент в 40SP вырастает.

Но чем тщательнее все сделано до Спринта, тем точнее прогноз. И команды не сразу, но поняли значимость PBR

Идеальных вообще нету.

У нас тоже не так гладко. Мы только начали. То же разбиение задач не вмегла выходит.

Но в общем и целом это работает.

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

Не нашел.

Покер вообще плохо работает, даже в командах.

Без него долго. С ним все проще. Больше двух, максимум трех итераций пока не было ни разу. Я сначала не хотел, мне говорили, что это долго. С ним мы Overall PBR в потора-два укоадываемся

У покера есть другие проблемы, кроме того, что долго "а реально долго) :)

мне кажется, или тут две недели чат – это диалог?

Да, еще момент. LeSS guide говорит о том, что на эти мероприятия желательно каждый раз ходить новым людям.

мне кажется, или тут две недели чат – это диалог?

Нет, иногда другие люди подключаются :)

мне кажется, или тут две недели чат – это диалог?

Приглашаем к диалогу :)

Не. Они одинаковые. Мы на Overall PBR с представителями всех команд (два от каждого, всего 14-15 человек) берем из бэклога очередной элемент. Продакт рассказывает о нем. Все задают любые вопросы. Это поверхностный анализ, для того, чтобы понять какие компоненты задействованы и объем работы. Потом с помощью карт (числа фибоначи) высчитываем ОБЩУЮ оценку. Если оценка больше 13SP мы разделяем ее на более мелкие истории и снова оцениваем. Потом команды выбирают из списка оцененных элементы с 8 и 13 SP и забирают их на командный или многокомандный PBR. Там уже копают ее до деталей и формируют приемочные критерии. После этого история Ready для Спринта. И за несколько дней до Планирования они дополнительно на таком же мероприятии презентуют (три минуты) критерии и кратко говорят об элементе. Решение о том какая команда будет делать конкретную задачу максимально оттягивается до планирования.

конечно, так вообще огонь)

мне кажется, или тут две недели чат – это диалог?

все ж лучше, чем про *логии

2166 участников :)

все ж лучше, чем про *логии

Про что?:)

Про что?:)

не обращай внимание))

Теперь не могу :) Можешь в личку рассказать?:)

Почитал Кеневин фреймворк. Сразу всплыло в памяти понятие "Ситуационное лидерство" https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%82%D1%83%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BB%D0%B8%D0%B4%D0%B5%D1%80%D1%81%D1%82%D0%B2%D0%BE

Сильно не копал, но перекликается, имхо

Это больше применительно к статье, которую вы раньше скинули. Там про полицейского и стили руководства лидера в разных контекстах. Возможно это только одно из применений модели?

В контексте (начала) дискуссии мы вообще о фреймворках и области применения говорили :)

Оки. Пошел читать дальше ...

cynefin вообще вышел за исходную область применения. Просто не все с этм согласны :)

В принятой в "стартап-сообществе Долины" интерпретации cynefin и его домены сейчас выглядят так: Chaos - "за пивом с коллегами вы решаете, что вы неплохая команда и может пора заканчивать работать на дядю и неплохо было бы сделать стартап". У вас нет структуры, нет идеи, нет понимания рынка и вообще ничего нет, только идея "неплохо было бы собраться". Сюда же относятся стартапы в духе "офигенно было бы сделать снапчат для животных" и прочите "мы сделаем свой ворл оф варкрафт, но про ОБЧР" Вашей (групповой) задачей на этом этапе является определить, что именно вы хотите сделать. Для этого более-менее подходит design sprint, потому что позволяет сформулировать возможную проблему, обсудить пути ее решения и как-то верифицировать результат, предлагая при этом очень простую стурктуру и готовое расписание. Как только вы смогли сформулировать что именно вы делаете, добро пожаловать в один из доменов: complex - "ваш стартап решил делать что-то, в чем ни один из вас не является экспертом". У вас будет много экспериментов, много попыток понять, как достигнуть результат, мало определенности и большой шанс вернуться обратно в Chaos. Из общих подходов тут правит бал Lean Startup Cycle, но так ак этот цикл - очень общий (и на самом деле захватывает и chaos), как рекомендация для домена он не подходит. Есть довольно старый подход RAD (rapid application development), который помогает в этом домене. Тут же можно использовать scrum, но будет тяжело: постоянная смена контекса, очень нечеткий бэклог, тяжело установить фиксированную каденцию, часто меняющиеся приоритеты... со всем этим можно жить, но не факт, что вы справитесь и что это действительно нужно. Цель - вырваться в complicated/simple с пониманием, что именно вы собираетесь получить в качестве результата. Понимание - это не сформулированная идея, а подвержденный экспериментами и подкрепленный цифрами "бизнес-план". Complicated - "вы знаете свою бизнес-модель и ищете способ эффективного достижения цели". Тут начинаются процессы, поставки реальных результатов, формирование команды и т.п. Отмечу, что comlicated это не "мы знаем о том, что хотим получить 100% заранее", но достаточно четкое понимание результата, чтобы иметь полноценный бэклог с элементами, которые позволяют получить применимый результат, поставить его "клиенту", кем бы он ни был, получить feedback и улучшить этот результат, оставаясь в пределах той бизнес-модели, которую вы определили. Scrum. Тут правит Scrum. Он для этого домена создавался, и в этом домене тяжело предложить более удобную и при этом более известную альтернативу. Хотя можно взять Kanban Method или Scrumban в любой инкарнации. Simple - "мы посовещались и решили, что будем делать то же самое, что делаем, работая на нынешнего дядю, но лучше". Вы точно знаете что делать и как это сделать. Весь набор акронимов из курса MBA в вашм распоряжении. Disorder - вы оказываетесь туту, если неверно поняли, где были до этого. Или ошиблись с подходом. Скрам в хаосе, вотерфол в complex/complicated, ТРИЗ в simple - привет, disorder. Из disorder надо просто выходить, чаще всего в chaos. Вот как раз для него нет нормальных фреймворков, тут начинается мое "любимое" антикризисное управление.

Pavel , про какое "сообщество" вы говорите? В вашем определении Chaotic (так правильно домен называется) описан как Complex. Complex - The complicated domain consists of the "known unknowns". Here it is possible to work rationally toward a decision, but doing so requires refined judgment and expertise. В примере с уходом в стартап нет ничего угрожающего системе. Единственная задача в Chaotic - остановить смертельное состояние, которая(внимание) убивает систему здесь и сейчас. Никаких известных паттернов там нет и быть не может. Остановитесь делать дизайн спринт - заберут имущество, которое в залоге за оборудование. Например. В этот момент надо делать что-то и сразу. Сноуден пишет -a leader’s immediate job is not to discover patterns but to staunch the bleeding. Домена Simple уже 4 года как нет, не используйте старые знания, пжалуйста. Есть домен Obvious.

Pavel , про какое "сообщество" вы говорите? В вашем определении Chaotic (так правильно домен называется) описан как Complex. Complex - The complicated domain consists of the "known unknowns". Here it is possible to work rationally toward a decision, but doing so requires refined judgment and expertise. В примере с уходом в стартап нет ничего угрожающего системе. Единственная задача в Chaotic - остановить смертельное состояние, которая(внимание) убивает систему здесь и сейчас. Никаких известных паттернов там нет и быть не может. Остановитесь делать дизайн спринт - заберут имущество, которое в залоге за оборудование. Например. В этот момент надо делать что-то и сразу. Сноуден пишет -a leader’s immediate job is not to discover patterns but to staunch the bleeding. Домена Simple уже 4 года как нет, не используйте старые знания, пжалуйста. Есть домен Obvious.

Левон, спасибо за комментарий. Про chaos (chaotic) и simple (obvious) - я понимаю, что использование неверных терминов из cynefin очень мешает полноценному обсуждению самого фреймворка. Но пожалуйста, обратите внимание, что я говорю об интепретации Точто так же интерпретации касается описание доменов. Так же замечу, что эта интерпретация происходит в контексте области применения фреймворков, чаще всего из Agile Domain, в рамках обсуждения стартапов и их жизненного цикла, в Калифории и нескольких других местах, где я это встречал на конференциях и митапах. Я понимаю, что "захват" терминов и их неверное применение мешает, но, к сожалению, часто приходится просто смириться. Как lean смирилось с "захватом" kanban, а lean startup - с "захватом" MVP.

Т.е. когда речь идет о применении Design Sprint в Chaos(Chaotic) речь очень часто идет не о "предприятии в кризисе", а о "стартапе в фазе определения, что он будет делать". Шанс стартапа в этой фазе развалиться - примерно соответствуют таковому у шансов любого предприятия в системном кризисе, потому что все признаки и симптомы будут примерно одинаковыми

Но уже в зависимости от контекста - подходы к выходу будут отличаться.

Design Sprint возможно выведет стартап из хаоса, но угробит зрелое предприятие

Мне даже ответить вам нечего. В вашей интерпретации cynefin может использоваться что угодно, я понял.

Мне даже ответить вам нечего. В вашей интерпретации cynefin может использоваться что угодно, я понял.

Это тоже хороший вариант

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

Левон, спасибо за комментарий. Про chaos (chaotic) и simple (obvious) - я понимаю, что использование неверных терминов из cynefin очень мешает полноценному обсуждению самого фреймворка. Но пожалуйста, обратите внимание, что я говорю об интепретации Точто так же интерпретации касается описание доменов. Так же замечу, что эта интерпретация происходит в контексте области применения фреймворков, чаще всего из Agile Domain, в рамках обсуждения стартапов и их жизненного цикла, в Калифории и нескольких других местах, где я это встречал на конференциях и митапах. Я понимаю, что "захват" терминов и их неверное применение мешает, но, к сожалению, часто приходится просто смириться. Как lean смирилось с "захватом" kanban, а lean startup - с "захватом" MVP.

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

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

Ну в самом начале же написано, что интепретация. Я сейчас отредактирую, чтобы было понятней, о каком сообществе речь идет.

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

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

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