Недавно меня попросили проверить систему Канбан, которой придерживается наша компания, и у меня возникли некоторые трудности с ее исправлением. Я работаю в стартапе, а в отделе программного обеспечения 5 разработчиков и 1 тестер. Мы используем JIRA для нашей канбан-доски. Задачи изначально появляются в бэклоге, а когда задача утверждается и назначается разработчик, она перемещается в разработку. Когда разработчик начинает работать над задачей, она переходит в состояние «Выполняется», а затем отправляется на этап проверки/тестирования/развертывания. Если он не прошел проверку или проверку, он снова возвращается в разработку, в противном случае он завершается и переходит в статус «Готово».
У нас действительно большой бэклог, он полон задач, которые почти забыты и кажется, что лучше не становится. Например, самой старой задаче уже 3 года.
В основном мы работаем над срочными запросами клиентов или важными ошибками. Разработчики жалуются, что не хватает времени, чтобы исключить часть работы из бэклога, так как они в основном заняты срочными задачами. Также есть некоторые застойные работы, которые являются задачами, с которыми наша команда не может понять, как справиться, и эти задачи повсюду - отставание, разработка и даже проверка. Задачи застревают на этапе проверки, потому что для имитации или тестирования некоторых из них требуется много времени, поэтому разработчики не хотят проходить этап тестирования, потому что предпочитают работать над срочными задачами.
В WIP нет предела, потому что они говорят, что их постоянно прерывают незапланированные или срочные задачи, и что было бы бессмысленно ограничивать WIP. Поэтому я не могу ограничить количество задач, над которыми работают разработчики.
Я не думаю, что команда разработчиков малочисленна, я просто думаю, что им не хватает системы, и они любят решать проблемы по-своему. Работа, которую я проделал до сих пор, заключалась в фильтрации требований клиентов, чтобы в невыполненной работе не было избыточных задач, но старые задачи все еще были там.
Что я могу предложить команде, чтобы они могли заниматься как срочными задачами, так и тупиковыми задачами?
Во-первых: очевидно, что ваша группа тестирования слишком мала . Соотношение 5:1 просто (1) приведет к огромному отставанию и (2) приведет к просачиванию ошибок. Ваш собственный проект тому подтверждение.
Даже если вы сможете доказать, что вашего соотношения 5:1 достаточно, вам нужен как минимум еще один тестер. Команда из 1 тестировщика — не лучшая идея, потому что у вас нет никого, кто бы тестировал тестировщика. Как вы сами писали у вас постоянный список важных багов ! КЭД.
Второе: ваша команда тратит много времени на жонглирование списком. И некоторые из этого списка просто никогда не будут выполнены . За деревьями не видно леса!
Я предлагаю провести день и сыграть в «Убей список» .
Потратьте первые полчаса на установление правил (которые вы должны подготовить заранее, но вы хотите, чтобы бай-ин в размере 80% сохранял ваше здравомыслие).
Несколько правил, с которых вы можете начать:
Цель этого состоит в том, чтобы сделать список достаточно маленьким, чтобы каждый мог видеть, что он собирается делать в обозримом будущем. Они перестанут тратить свое время на просмотр вещей, которые им никогда не удастся сделать.
Последнее: вам не кажется, что команда разработчиков слишком мала . Но если вы перечитаете свой пост еще раз, в это трудно поверить. Я не понимаю, как даже самая отлаженная система в мире может сократить отставание на 3 с лишним года, которое постоянно пополняется, без добавления рабочей силы.
Здесь есть пара проблем.
Первая проблема — большое отставание. Это относительно легко решить — просмотрите элементы в невыполненной работе и решите все, что больше не нужно. Решение может быть любым: от удаления элементов до пометки их как «неподходящие» или «устаревшие». Удаление дубликатов также может быть выполнено в это время. Этому меньшему отставанию должно быть легче расставить приоритеты и в целом управлять в будущем. Я бы предостерег от удаления известных проблем из списка невыполненных работ — вполне возможно, что клиенты или потенциальные клиенты могут запросить доступ к известным проблемам или соответствующему подмножеству известных проблем.
Вторая проблема — отсутствие лимитов WIP. Я бы порекомендовал создать их экземпляры. Однако, поскольку вы также работаете над критическими проблемами, у вас есть строка «ускорить» на доске Канбан. Я бы также рекомендовал начать собирать показатели пропускной способности и времени цикла, чтобы вы могли начать прогнозировать будущую работу или когда вы, возможно, сможете начать и закончить работу, основываясь на том, где она находится в невыполненной работе. Я полагаю, что одна из вещей, которые покажут эти показатели, заключается в том, что вам нужны дополнительные люди или изменение в процессе, которое позволит вам перейти от времени, готового к тестированию, к более быстрому выполнению.
Третья проблема связана с количеством критических проблем. Наличие большого количества критических проблем, которые не могут ждать или требуют срочного решения, может указывать на низкое качество. Это также может указывать на плохое управление продуктом и приоритизацию этих проблем. Возвращаясь к метрикам, если у вас есть данные о том, сколько времени потребуется на выполнение работы с учетом места в журнале невыполненных работ, вы можете работать с заинтересованными сторонами, чтобы определить, действительно ли нужно ускорить работу или ее можно правильно расставить по приоритетам и следовать ей. ваши лимиты WIP. В целом, сокращение количества работ по исправлению дефектов, добавляемых в бэклог, также будет полезно для команды и проекта.
У нас действительно большой бэклог, он полон задач, которые почти забыты и кажется, что лучше не становится. Например, самой старой задаче уже 3 года.
Один из подходов, который я использовал в прошлом, заключается в следующем:
Я считаю, что этот подход имеет тенденцию концентрировать умы. Часто бывает так, что либо люди, запрашивающие работу, соглашаются архивировать задачи, либо требуют дополнительных ресурсов для вашей команды, чтобы задачи выполнялись быстрее.
В WIP нет предела, потому что они говорят, что их постоянно прерывают незапланированные или срочные задачи, и что было бы бессмысленно ограничивать WIP.
Это ситуация, когда WIP работает очень хорошо!
Когда появляется срочная или незапланированная задача, команда проверяет, не приведет ли она к превышению лимита незавершенного производства. Если это так, то что-то еще должно быть изъято из этой очереди.
Например, приходит срочное исправление ошибки. У команды уже есть 5 элементов в столбце «Разработка», что является пределом WIP. Они просматривают список и удаляют один элемент, помещая его обратно в столбец ожидания начала.
Затем команда информирует человека, запросившего элемент, который только что был возвращен, в столбец ожидания начала. Они говорят им, что их работа будет отложена из-за задачи с более высоким приоритетом.
Преимущества этого подхода:
Наконец, вы можете счесть полезным попытаться количественно оценить влияние срочных и незапланированных задач.
Например, вы можете отправить двухнедельное электронное письмо со статусом, в котором будут такие вещи, как:
Из-за срочных исправлений в базе данных, пришедших на прошлой неделе, нам пришлось приостановить работу над несколькими задачами. Команде потребовался почти день, чтобы переключиться на новые задачи, и это время фактически потеряно. По нашим оценкам, на команду повлияло снижение эффективности на 10-20% в течение двух недель.
Опять же, это поможет сосредоточить умы.
Тот факт, что вашей самой старой заметке (задаче) три года, не обязательно является проблемой, просто потому, что независимо от того, насколько большая у вас команда, они вместе с вашими клиентами всегда смогут генерировать больше идей о новых вещах для разработки/изменения/рефакторинга. /fix/etc, чем то, с чем сможет справиться ваша команда. Если члены команды поймут это, у них будет меньше проблем с постоянно растущим отставанием. Однако вы можете потратить день или два в год на его очистку; просто просматривая старые предметы и избавляясь от тех, которые больше не будут создавать ценность.
По моему мнению, преимущества использования лимитов WIP очень хорошо описаны https://leankit.com/learn/kanban/benefits-of-wip-limits/ .
Однако ваш вопрос был о том, как управлять как срочными, так и зависшими задачами, позвольте мне попытаться немного рассказать о том, как мы справляемся с этим в нашей разработке, которая работает довольно хорошо.
Прежде всего, я полагаю, вы могли бы подумать об изменении содержания ваших заметок. Вы упомянули, что у вас есть заметки, содержащие задачи. В нашей модели разработки мы пытаемся убедиться, что каждое примечание описывает результат, который добавит ценность продукту. Чтобы завершить этот результат (примечание), может потребоваться выполнить множество различных задач (анализ требований, выбор архитектуры, проектирование, реализация, документация, проверка, проверка и т. д.). При работе с лимитами WIP мы увидели, что она становится более эффективной, если вы используете результаты вместо задач. У нас есть два разных лимита WIP. Один для заметок на всей доске (не включая заметки в невыполненной работе или столбцах «Готово»), мы называем это лимитом WIP Kanboard (KWL). Другой — это лимит WIP для отдельных фаз на Kanboard, мы называем этот лимит WIP по фазам (PWL).
Пример: если ваша Kanboard имеет этапы «Требования и дизайн» (RAD), «Разработка и тестирование компонентов» (DCT), «Тестирование функций» (FTE) и «Тестирование интеграции» (ITE), а размер вашей команды равен 4. KWL будет равен 3 (размер команды - 1) и PWL <= 3. PWL начинается с единицы в крайнем правом столбце и увеличивается на единицу до максимального значения 3 в этом случае.
Мы стараемся удерживать расчетные усилия для заметки в невыполненной работе на максимальном уровне, который может быть выполнен в течение 2 человеко-недель. Поскольку количество незавершенных заметок ограничено лимитом WIP, это означает, что по крайней мере над одной из заметок будет работать более одного человека; поощрение командной работы. Поскольку количество PWL уменьшается по всем направлениям, это также поддерживает основную идею Канбана по поддержке потока (подготовка вещей к выпуску) вместо того, чтобы поддерживать выполнение (или остановку) многих вещей одновременно. Если заметка застряла в столбце ITE, то никакая другая заметка не может туда перемещаться. Это еще больше подчеркивает, что для команды более важно совместно завершить оставшиеся задачи, чтобы выполнить эту заметку, а не начинать что-то новое. С предполагаемыми результатами не более 2 человеко-недель, мы считаем, что они разбиты достаточно хорошо, чтобы все члены команды могли понять, что нужно сделать, чтобы поместить примечание в столбец «готово к выпуску». Когда результаты в бэклоге больше этого, слишком много времени, как правило, тратится на выполнение ненужных действий или что-то упускается просто потому, что недостаточно ясно, что нужно сделать.
Предположим, что в столбце ITE застрял элемент, и только 3 из четырех человек в команде могут внести свой вклад в работу над ним, тогда четвертый человек должен работать над самой верхней нотой в столбце FTE (самый высокий приоритет в сверху в каждом столбце, как и в отставании). Может быть, этот четвертый человек не может (легко) внести свой вклад в примечание FTE, примечание DCT или примечание RAD, если уж на то пошло. В этом случае произошел люфт (люфт в смысле того, что описано в ссылке выше).
Приостановленные заметки должны управляться командой или менеджерами группы так же, как и любой другой заметкой. Если что-то мешает команде продолжать работу над этим, тогда менеджер/менеджер продукта/менеджер проекта/мастер схватки/мастер agile (или кто у вас есть на месте) должен помочь в устранении препятствия. Если это что-то, что не касается членов команды, то заметку следует снова вернуть в бэклог (поскольку никто в команде активно над ней не работает).
Срочные задачи, как вы говорите, вполне могут быть задачами (не обязательно результатами). Это может быть «исследовать этот отчет об ошибке», или «измерить это», или «обобщить это для клиента», «необходимо устранить ошибку, которая мешает работе команды» и т. д. Для этих случаев мы ввели скорую помощь (всего одну ) на нашей Канборде. Такая срочная записка сопровождается машиной скорой помощи, когда она движется по доске, и машина скорой помощи — единственный предмет, которому разрешено нарушать лимит WIP. Когда скорая помощь находится на доске, она имеет приоритет над другими заметками, и как можно больше членов команды должны внести свой вклад в устранение срочной записки как можно быстрее.
Если вы используете эту настройку и оказываетесь в ситуации, когда скорая помощь всегда (или очень часто) присутствует на Kanboard, вам, возможно, придется рассмотреть возможность создания одной конкретной команды для управления только заметками о скорой помощи.