случай.
Если для работы над задачей требуется передача ее другой команде (не всегда одной и той же, но будем считать, что мы заранее знаем какой) и продолжение работы будет когда они таску вернут — как с этим работают? Представителей всех команд на ежедневный каденс каждой команды же не пригласишь, на все XX команд единое собрание тоже делать не будешь.
Трекать и двигать каждую такую задачу на досках обоих команд?
Или когда задача доходит до стадии работы соседей заводить задачу им на доске с отдельным классом сервиса о котором договориться дополнительно?
Я понимаю, что это антипаттерн командной организации, но прежде чем он устранится начинать с чего-то надо.
Одно из решений - колонка в общем процессе для такой команды. Концепция апстрим/даунстрим знакома?
имеется в виду построить VSM для таких задач, заранее оптимизировать его так, чтобы возвратов по возможности не было и использовать доску с этим VSM как источник задач для обеих досок?
А ты практически все верно описал. У одной команды есть колонка, которую стикер покинет, когда такой же стикер проедет по целой доске другой команды. Стикеры по идее имеют связь parent-child. Каждая команда имеет своё статусное собрание, а вот трекинг задач может идти по разному в зависимости от того как организовались. Если вторая команда может предоставить sla, то у первой команды просто на стикере пишется прогноз завершения и ближе к нему лидер партии монады может уточнять у второй команды как дела. Если у вас пока работа втооой команды не особо предсказуема, то либо лидер первой ходит ко вторым на статус, либо представитель второй ходит на статус к первым. Ну и для второй команды надо делать процедуру пополнения с участием лидера первой команды. Отдельный класс обслуживания тут необязателен и помните, что то, что от первой команды идёт во вторую - это уже закоммиченая работа
А при чем здесь апстрим и даунстрим?
Вообще не понял чего действия
Обсуждают сегодня