Способы ограничить wip лимиты

WIP-лимиты здорового человека и WIP-лимиты курильщика

Я и мои коллеги по работе для внутренних сотрудников компании, в которой я работаю, периодически готовим небольшие статьи, где разбираем различные кейсы по гибким подходам, включая и кейсы использования Канбан-метода для совершенствования и управления процессами. Такие статьи мы называем «Agile-shorts». И я подумал, «А почему бы не открывать свои статьи и для более широкой аудитории?» И, вот, сегодня я публикую первую свою статью из этой серии.

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

Мало кто, работающий в ИТ-сфере, не слышал про гибкие подходы к созданию продуктов. Слова Agile, Kanban, Scrum уже крепко проникли в лексикон современных компаний. Кто-то их произносит с гордостью, кто-то с иронией, а кто-то сквозь зубы.

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

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

Ограничиваем Пользовательские Истории, а работаем с Подзадачами

Часто, познакомившись с основами практик и методов, которые используются в Agile-культуре, у людей складывается впечатление, что, нажав Ctrl+C и Ctrl+V, они у себя получат ту же замечательную вещь, которую они увидели в учебном кейсе. На деле же оказывается, что «Ctrl+V» приходится, как в анекдоте, тщательно дорабатывать напильником.

Визуализируя работу команды, неофиты часто совмещают на одном уровне задачи, которые несут ценность для Заказчика, с задачами, которые имеют ценность только внутри процесса. Почему, спросите, совмещают? В основном, потому что привыкли работать в парадигме – «мне поставили задачу – я делаю задачу – я сделал задачу», в которой для выполнения не обязательно задумываться о ценности: «Ведь начальник уже об этом сам подумал, раз отдает задачу в работу».

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

«Сделать MVP Продукта» — задача имеет ценность для Заказчика, так как пользователь получит в руки что-то, что может начать использовать.

Провести нагрузочное тестирование – не самостоятельная задача, а нужна для прогресса какой-то другой

Заключить контракт с поставщиком ХХХ – не самостоятельная задача, а нужна для старта работ по другой задаче

Реализовать функционал голосового ввода – пользователь получит новый функционал для использования

«Так причем же тут WIP-лимиты?», спросите вы. Так вот, новички часто начинают применять этот инструмент на таком, типичном для многих, контексте. Ограничили, надеются, что работы пойдут быстрее, а в итоге, почему-то, получается всё наоборот — работы встают, все запутываются.

Пример работы в такой системе: менеджер говорит, что задача «функционал голосового ввода» приоритетнее задачи «проведение нагрузочного тестирования», поэтому первое берем в работу (включаем в лимит), а второе ждёт. Но в какой-то момент приходит понимание, что реализовать функционал без проведения нагрузочного тестирования нельзя (конечно, ведь это часть работ, которые нужно провести, чтобы сделать функционал), задача блокируется и ждет, когда начнем делать тестирование. Но лимит-то заполнен! Как нам говорит теория — чтобы взять что-то в работу, надо сначала что-то завершить. Текущая задача бросается, внимание переключается на что-то другое, а заказчик, в итоге, не получает никакого результата.

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

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

Какие бывают уровни:

Работа на уровне исполнения задач одним человеком.

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

Работа на уровне команды. Для нормирования работы команды, используются:

лимиты на систему/команду/сервис (Бэклог спринта – частный случай лимита на систему)

лимиты на тип задач (Квотирование)

лимиты на этап (работа с узкими горлами)

и другие, более экзотические типы ограничений

В этом случае нужно смотреть на задачи глазами Заказчика работ. Появляется такой объект как Customer recognizable item – задача, смотря на которую, Заказчик понимает, что это именно то, что он заказывал, и видит, что происходит с заказом.

Работа на уровне портфеля

Для эффективного распределения ресурсов для реализации портфеля инициатив, используются лимиты на объекты портфеля.

Например, лимиты на Эпики, чтобы сфокусироваться на завершении какого-то направления, а не распыляться на всё сразу. Хотя, конечно, это уже вопрос маркетинговой стратегии. Или на инициативы портфеля инициатив – чтобы сфокусироваться на скорости проверки гипотез и, в свою очередь, выбрать именно те, что даст нам конкурентное преимущество.

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

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

Осознайте проблему, которую вы хотите решить применением инструмента

Если что-то не получается, допустите, что это не инструмент плох, а есть что-то, что вы не учли

И тогда, разочарование от того, что «мы потратили кучу времени, а оно не работает», вас обойдет стороной.

Источник

Установка ограничений выполнения работы в Azure Boards

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018–TFS 2013

Важнейшая практика канбана — ограничения на выполнение, которые называются «лимиты WIP» — ограничивает объем работы, которую команда будет выполнять на каждом рабочем этапе. Она предназначена для того, чтобы сосредоточиться на выполнении элементов перед началом новой работы. В первую очередь, интуитивно понятный счетчик, многие команды находят ограничения НЗП помогают повысить производительность и улучшить качество программного обеспечения.

Вы определяете ограничения WIP для каждого рабочего этапа, соответствующего каждому промежуточному столбцу. Ограничение устанавливает мягкое ограничение на число элементов, разрешенных в столбце. Ничто не предотвращает перемещение дополнительных элементов в столбец и превышение предела. На доске Канбан отображается количество элементов на каждом этапе рядом с каждым пределом.

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

Предварительные требования

• Необходимо настроить настраиваемую доску Канбан. При добавлении команды вы добавляете доску Канбан для этой команды. Дополнительные сведения см. в разделе о командах и гибких инструментах.
• чтобы настроить параметры команды, необходимо быть членом роли администратора команды или входить в группу безопасности Project администраторы . Дополнительные сведения см. в статьях Добавление администратора команды или Установка разрешений на уровне проекта или коллекции.
• Пользователи, которым назначен базовый доступ или более высокий уровень, могут использовать все невыполненные работы и возможности доски.
• Пользователи, которым назначен доступ заинтересованным лицам , имеют ограниченный доступ к невыполненной работе и возможностям доски. Заинтересованные лица могут изменять рабочие элементы на доске и добавлять существующие теги в рабочий элемент. Они не могут добавлять рабочие элементы на доску и не могут обновлять поля, отображаемые на карточках. Дополнительные сведения см. в разделе сведения об уровнях доступа.

• Необходимо настроить настраиваемую доску Канбан. При добавлении команды вы добавляете доску Канбан для этой команды. Дополнительные сведения см. в разделе о командах и гибких инструментах.
• чтобы настроить параметры команды, необходимо быть членом роли администратора команды или входить в группу безопасности Project администраторы . Дополнительные сведения см. в статьях Добавление администратора команды или Установка разрешений на уровне проекта или коллекции.
• Пользователи, которым назначен базовый доступ или более высокий уровень, могут использовать все невыполненные работы и возможности доски.
• Пользователи, которым назначен доступ заинтересованным лицам , имеют ограниченный доступ к невыполненной работе и возможностям доски. Заинтересованные лица могут изменять рабочие элементы на доске и добавлять существующие теги в рабочий элемент. Они не могут добавлять рабочие элементы на доску, не могут перетаскивать рабочие элементы для обновления состояния или переупорядочивать карты и не могут обновлять поля, отображаемые на карточках. Дополнительные сведения см. в разделе сведения об уровнях доступа.

Определение ограничений начального НЗП

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

Установите ограничения на основе текущих выполняемых операций. Подсчет элементов, имеющихся в существующих столбцах канбана.

Установите ограничения, которые не превышают два или три элемента на одного участника команды, работающего в пределах этапа. Например, если у вас есть три члена группы и каждый участник команды может работать с не более чем двумя задачами одновременно, то итоговый лимит НЗП равен 6 (= 3 разработчикам X 2 задачам и разработчикам).

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

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

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

Не учитывать ограничения WIP

После настройки ограничений WIP необходимо отвестись от того, насколько хорошо ваша команда следит за ограничениями.

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

Несмотря на то что простая в теории, хранение в пределах WIP может привести к принудительной работе отдельных пользователей, групп и организаций. Участники команды, которые наподобие многозадачности, могут быть ограничены. Другие могут найти себя без работы, если они ожидают завершения работы на вышестоящем этапе.

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

Выявление узких мест

Чтобы оптимизировать поток значений, необходимо точно выявлять и устранять узкие места. Узкие места указывают на то, что отходы существуют в общем рабочем процессе.

Отслеживая свою доску Канбан с течением времени, вы можете узнать, где возникают узкие места. Если несколько элементов находятся в столбце в нерабочее время в течение нескольких дней, возникло узкое место. Узкие места обычно возникают, если пределы WIP слишком высоки. Однако узкие места не могут означать, что ограничения НЗП слишком низкие.

Бесплатная электронная книга, Канбан и Scrum — большинство из нихпредоставляют следующие рекомендации:

Слишком низкое ограничение WIP = неактивные люди > = нехватка производительности>

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

Такие моментальные снимки могут показывать вашу команду:

• Сколько элементов в среднем существует в пределах этапа или столбца рабочего процесса
• Количество элементов, обрабатываемых по сравнению с участниками команды, работающими на стадии рабочего процесса или в столбце
• Число и количество элементов, оставшихся на этапе или столбце рабочего процесса в течение длительных периодов времени
• Сколько элементов выполнила команда в конце 1, 2 или 3 недельного периода?

Устранение отходов

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

Распространенные отходы при разработке программного обеспечения включают:

• Неиспользуемый код или функции
• Дефекты, которые привели к переработе
• Задержки или время, затраченное на ожидание чего-либо
• Хандоффс от одного человека, команды или бизнес-процесса к другому
• Недостаточные требования
• Низкая или низкая связь

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

Установка ограничений WIP

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

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

Щелкните значок шестеренки, чтобы настроить доску и задать общие параметры команды.

Выберите столбцы , а затем вкладку столбец, чтобы задать ограничение WIP для этого столбца.

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

После внесения изменений нажмите кнопку сохранить.

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

Щелкните , чтобы открыть диалоговое окно Общие параметры конфигурации для доски Канбан.

Выберите столбцы , а затем вкладку столбец, чтобы задать ограничение WIP для этого столбца.

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

После внесения изменений нажмите кнопку сохранить.

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

Щелкните значок шестеренки, чтобы открыть диалоговое окно Общие параметры конфигурации для доски Канбан.

TFS 2015,1 и более поздние версии

Выберите столбцы , а затем вкладку столбец, чтобы задать ограничение WIP для этого столбца.

После внесения изменений нажмите кнопку сохранить.

TFS 2015

Установите ограничения WIP для каждого промежуточного столбца.

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

Щелкните значок шестеренки, чтобы открыть диалоговое окно Общие параметры конфигурации для доски Канбан.

Установите ограничения WIP для каждого промежуточного столбца.

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

Источник