Так может ей какой-то статус сделать типа on hold?

И на нее не вешать wip-лимит? Да, вполне себе решение. Подумаем.

А разве висячие задачи это не та проблема, для решения которой как раз придумали wip?

Как вариант)

отдельный

Коллеги, вопрос небольшой. А можно ли по канбану возвращать взятые задачи обратно в бэклог? Например, задача зависит от неких внешних факторов (согласование в другом отделе), ну и чтобы wip не нарушать, можно вернуть ее и поработать пока над другой задачей. Или лучше не практиковать такое?

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

боюсь шторминг и все бомбят)

Для преодоления storming увы советы вообще не помгоут :)

Коллеги, привет. Я начинаю скрам мастер

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

Тут одна из техник. https://blog.unusual-concepts.ru/2017/12/speed-boat/

кажется, не нужно брать задачу в разработку, пока она висит в другом отделе на согласовании 🤔

Это про LeSS. LeSS is Scrum. Caution! No analysts, specification writers, UI/UX designers, or architects in a “Product Owner Team.” That would maintain the status quo problems and structures under a new label. Specialists join normal feature teams.

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

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

Когда задача берется в работу, заранее не известно, потребуется ли привлечение внешних отделов.

но это же неправильно, разве нет? Это как пускать машину собирать на конвеере, не получив согласования инженеров

А согласование инженеров как получить? Не по канбану?

Когда задача берется в работу, заранее не известно, потребуется ли привлечение внешних отделов.

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

Кстати да, интересный вопрос. PBR в канбане уместен?

Коллеги, вопрос небольшой. А можно ли по канбану возвращать взятые задачи обратно в бэклог? Например, задача зависит от неких внешних факторов (согласование в другом отделе), ну и чтобы wip не нарушать, можно вернуть ее и поработать пока над другой задачей. Или лучше не практиковать такое?

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

Это когда вся организация канбанизирована. А когда только один отдел?

Я вот тоже задумался над этим. Кто PBR’ит и когда?

И что это меняет?

Что я так и не понимаю до конца, как такие внешние процессы укладывать в канбан

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

не совссем вторую часть понял

Это я про отдельные команды дизайнеров в Скраме. Не нужно их. Всех в команды.

Артем, смотри, ты решаешь задачу как бы люди были все время заняты.

Это я про отдельные команды дизайнеров в Скраме. Не нужно их. Всех в команды.

Нет в Скраме архитекторов :) Аналитиков и дизайнеров - в команды.

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

Ну тогда еще один вопрос. Кто и как в канбане приоритезирует таски? Я вот полагаю, что это, например, должен делать начальник отдела. Он всегда в курсе, к нему стекается вся инфа, эскалируются срочные вопросы и он расставляет приоритеты. А исполнители незадумываясь берут задачи с максимальным приоритетом.

Тогда, люди должны простаивать, это обеспечит зарас по мощности и как следствие т2м

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

Звучит невероятно )) Я про простаивание

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

У меня было так ) Сделай опрос 360. ПУсть каждый о каждом выскажется. Кто-то после этого сам уйдет )

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

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

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

Я самоорганизацию понимаю так, что начальник делегирует все команде, но если команда не справилась, то он вмешивается. Иначе что, ну херовая команда и все, понять и простить? Команда должна вписываться в организацию, если она не вписывается, то компания (в лице начальника) решает вопрос.

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

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

Главное понять, что совершать оишбки - необходимо. И соответственно изменить свое отношение к ним.

Отлично а кто думает о связей компонентов и интеграции с внешними системами?

Разработчики.

Про аналитиков и архитекторов. У нас есть команды(состав be, fe,qa), есть эксперты- дизайнеры, аналитики, архитекторы. Есть бизнес и продакт. Продакт приотезирует задачи, информирует закачкика. Примерно за пару итераций до разработки эксперты прорабатывают задачу в каждый одновременно в своей части. За итерацию начинаются груминги. И в идеале, если нечего не пошло не по плану к планированию команде поступает готовая к реализации задача. Вопрос как это организовать, если эксперты будут в команде.

Вопрос скорее в систематически херовой производительности. И фидбек дали человеку, но все не то.