Насколько важна визуализация процесса? Я для себя вывел, что хорошая визуализация решает 2 задачи:
Быстрее ориентируешься в приоритетах задач
Быстрее принимаешь решения
Дальше будет тред, основанный на реальных болях, как можно с помощью визуализации упорядочить хаос >>>
Этот тред можно смело будет назвать — "о чем я бы хотел знать про визуализацию перед тем, как стал тимлидом"
Классический подход, который я встречал в куче мест: это когда заводят для задач разработчиков 5 колонок: туду, в работе, ревью, тестирование, релиз. И обычно во время туду \ работы и ревью задача висит на разработчике, а потом на тестировщике.
Тут мы сталкиваемся с первой проблемой. Если мы перевели задачку в тестирование, она тестируется или нет? Что с ней происходит?
Чтобы решить эту проблему, иногда возникает желание добавить метку или комментарий в задачку "ожидает тестирования". Но это желание порочно. Потому что сейчас мы разбираем только одно место. Затем появляется еще одно и еще одно. Становится вот так:
Это плохо тем, что любому члену команды, чтобы понять "а что там с задачей" придется открывать каждую задачу, искать комментарий и т.д. Лучше придерживаться правила "что было в вегасе, остается в вегасе" ой, "что можно визуализировать, лучше визуализировать в одном месте".
Решением может быть разделение колонки Ревью на 2: "ревью: в процессе" и "ревью: готово". В этой системе тестировщик, придя на работу, видит текущие задачи, которые нужно завершить, и свой "беклог" задач, которые можно вытягивать когда появляется вакуум.
Решение легко масштабируется и на другие подобные проблемы. Мы получаем доску, на которой мы понимаем, что происходит. Это полезно как самой команде (легче выбирать задачи, проще договариваться), так и тимлиду.
Вторая проблема: тестировщик находит критические баги в задаче. Выпускать нельзя. Здесь есть разные пути решения. Можно реопнуть задачу и для всех переоткрытых задач иметь свой swimline, либо оставить в текущем статусе, но указать на доске исполнителем разработчика.
Зачем в этом случае такие навороты?
Задачка уже сделана, на нее уже потрачены силы\нервы\деньги\обсуждения. Приоритет такой задачи, скорее всего, выше, чем у других. Поэтому если мы оставляем ее на уровне тестирования — разработчик легко видит такой "блок" и с большим приоритетом переключается туда.
И тут мы подходим к такой штуке как определение приоритетов на доске.
Самый простой и "нативный" способ — это чтение справа налево по строкам. Т.е. мы сортируем наши swimlines по приоритетам — вначале критикалы, потом баги, потом задачи (например).
Члены команды при выборе очередной задачи проходят по этим swimlines и выбирают первую задачу, над которой они работали \ могут взять в работу.
В результате, если тестировщик перевесил задачку на разработчика, то разработчик, закончив текущую работу, открывает доску и видит, что справа у него есть задачка.
Преимуществом такого подхода является отсутствие излишних коммуникаций.
Этот подход можно использовать и для проведения стендапов. Идти по задачкам, справа налево. В теории, это позволяет быстро ответить на вопрос "а что нужно сделать, чтобы задачу быстрее выпустить" и не обсуждать излишние вещи на стендапах.
Мы в двух командах пробовали сделать так для стендапа и каждый раз мы терпели фиаско. Потому что, во-первых, этот подход требует определенной зрелости команды, во-вторых, можно терять в коммуникации.