А то по садится в баги и начинает думать не о том :)

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

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

Имеет наверное если сложный продукт где там внутри ни одна команда, а так* это одно и то же

А, ок. Тогда нахрена ПО вообще туда лезть, если он например не ты

В смысле не кодит

Ну как же - хозяин процесса :)

Просто хозяин;)

МиниСЕО

Ну я серьезно. перенесите груминг, планнинг и ретро на выходные

И Дэйли заодно. Все.

Будет тогда викэндли

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

не может или не должен работать с тех беклогом?

читай как не должен

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

цели спринта - "сделать эти фичи" или "релиз такой-то даты":) тут даже не надо лезть и смотреть что там внутри

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

Как это относится к технической части?

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

скоро всех разгонят

:)

Господа и дамы, кто какие вопросы спрашивает на стэндапе? (что делал, что буду, какие сложности - не предлагайте, это скучно и не интересно)

Ключевая ошибка кмк в отсутствии одной буквы. Мне неважно что человек делал. Важно что он _с_делал

это все равно все не то, это ведет к репортам, потому что важно должно быть не ТЕБЕ, а команде

Я просто хочу расширить стэк своих вопросов, чтобы увеличить вовлеченность

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

и зачем вопросы задавать, они что такие сложные? каждый и сам может на них ответить

а если ответы не те, то можно на ретро обсудить

еще раз: рассказывать свой статус - это репортинг

нет

репортинг, это когда все подошли и отчитались перед кем-то

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

Это то, что как раз ты и предлагаешь с Вячеславом

Мы не в спринтах

тогда стоит начать с того, зачем вам стендапы

Что минимально надо сделать мне сегодня, чтобы переместить свою задачу(и) в следующий этап (если этапность) или сделать релиз

Приходить на стендап подгтовленным (имея ответ на этот вопрос)

бгг и как вам это не надоело

тогда стоит начать с того, зачем вам стендапы

ахаха. То есть если нет спринтов, то стендапы не нужны по твоему?

Я просто хочу расширить стэк своих вопросов, чтобы увеличить вовлеченность

Что тормозит выполнение задач (создаёт препятствия эффективной работе)

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

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

Именно это я и спросил и имел ввиду ;)

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

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

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

ахаха. То есть если нет спринтов, то стендапы не нужны по твоему?

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

Еще раз, нет спринтов

Канбан это

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

Причем тут ретроспектива? :)

а как вы улучшаете процесс?

а может вернуться к вопросу? Ибо я не про ретроспективу спрашивал ;)

Вот вопрос

Господа и дамы, кто какие вопросы спрашивает на стэндапе? (что делал, что буду, какие сложности - не предлагайте, это скучно и не интересно)

подчеркиваю слово СТЭНДАП

нет, это правильные впоросы

Что делал, остальные знают что сделал коллега

Что буду - коллеги понимают что делает коллега и работа не дублируется

и какие возникли проблемы - подключается SM и устраняет препятствия

Я выше написал - это репортинг в таком случае

сорри, пропустил... а есть кейс

Что смущает ?

хочу расширить стэк своих вопросов, чтобы увеличить вовлеченность, чтобы вызывать дискуссию и именно шэринг информации, а не репортинг СМ

Так делай это на ретро

стендап = 15 минут

что бы ценность для PO и стейкхолдеров не потерять стендап = 15 минут

http://blog.byndyu.ru/2015/05/kanban.html

я бы спросил тогда кто еще такие стэйкхолдеры в вашем понимании, ну да ладно

@neemah (кстати, где твой кайзенио, или запретили?) Статью знаю, вопросы знаю, на данный момент есть около 12 вопросов (все на английском), пытаюсь придумать новые, более изощереные

Я сначала не понял вопрос, но потом понял. Все на месте :)

Можно спрашивать топ-3 самых непонятных вещей на сегодня (задачи, технологии, интеграции, коммуникации)

#whois Добрый день! Работаю на заводе по производству автокомпонентов ведущим инженером. Интересна возможность применения agile на заводе. Надеюсь буду полезен группе, так же как и она мне!

Подписка на #whois

#whois Добрый день! Работаю на заводе по производству автокомпонентов ведущим инженером. Интересна возможность применения agile на заводе. Надеюсь буду полезен группе, так же как и она мне!

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

А вам прямо брать книги по Тойоте и мотороле и пытаться внедрить то что внедряется )))

#whois Добрый день! Работаю на заводе по производству автокомпонентов ведущим инженером. Интересна возможность применения agile на заводе. Надеюсь буду полезен группе, так же как и она мне!

Элия Голдрат "Цель: процесс непрерывного совершенствования", там как раз про завод

#whois Добрый день! Работаю на заводе по производству автокомпонентов ведущим инженером. Интересна возможность применения agile на заводе. Надеюсь буду полезен группе, так же как и она мне!

Привет! Позвольте поинтересоваться, а что побудило поинтересоваться?

#whois Добрый день! Работаю на заводе по производству автокомпонентов ведущим инженером. Интересна возможность применения agile на заводе. Надеюсь буду полезен группе, так же как и она мне!

Перспективная тема! Респект за интерес

Всем привет! - Работаю в компании заказной разработки ПО (100+ сотрудников) - Немного занимаюсь внутренними бизнес процессами производства, в остальное время руковожу отделом бизнес и системного анализа - Могу быть полезен тем, что лично поломал много копий в попытках скрестить Agile и Госзаказчиков, пока с переменным успехом. - Ищу здесь полезные советы, идеи, кейсы по применению Agile на практике - из Москвы - Узнал по группе через прямую ссылку в чате Business Nanlysis Magazine #whois

Подписка на #whois

#whois Добрый день! Работаю на заводе по производству автокомпонентов ведущим инженером. Интересна возможность применения agile на заводе. Надеюсь буду полезен группе, так же как и она мне!

Про QRM ещё почитай, для завода они друг друга дополняют