Wip ограничения что это
WIP лимиты
Один из важных принципов работы по методологии «Канбан» — это ограничение количества выполняющейся в данный момент работы (WIP).
Ограничения WIP повышают пропускную способность команды и сокращают объем работы, «почти выполненной», заставляя команду сосредоточиться на меньшем наборе задач. На фундаментальном уровне ограничения WIP поощряют культуру «сделано». Что еще более важно, установленные ограничения WIP делают узкие места видимыми.
Чтобы наладить работу, команда должна разобраться и устранить проблемы, которые тормозят или блокируют успешное прохождение задачи на последний этап «Завершена».
Цифры по WIP ограничениям подбираются каждой командой экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.
Например, если вы имеете 8 программистов в команде, то в столбец «Разработка» вы можете поместить цифру 4. Это значит, что одновременно программисты будут делать не более 4-х задач, а значит у них будет много причин для общения и обмена опытом.
Если вы поставите туда цифру 2, то 8 программистов, занимающихся двумя задачами, могут заскучать или терять слишком много времени на обсуждениях. Если поставить 8, то каждый будет заниматься своей задачей и некоторые задачи будут задерживаться на доске надолго, а ведь главная задача Канбан — это уменьшение времени прохождения задачи от начала до стадии готовности.
Лимиты: обратите внимание
Мы исходим из того, что одна и та же команда может одновременно работать над разными проектами. Исходя из этого, лимиты устанавливаются на все проекты группы проектов «Канбан», т.е. если у вас в столбце «Дизайн» максимум 4 задачи, это означает что по всем проектам в статусе «Дизайн» может находиться не более 4 задач.
Если над каждым проектом у вас работают разные команды, рекомендуем вам делать отдельные планировщики с лимитами под каждую команду для каждого проекта.
Что такое канбан и как не «похоронить» проект в Trello
История канбана
Своим появлением термин «канбан» обязан компании Toyota Motor Corporation, разработавшей и внедрившей на своих автомобилестроительных заводах принцип производства и снабжения, обеспечивающий реализацию системы «точно в срок». При этом немногие знают, что именно послужило источником появления этой методологии, которая сейчас широко используется в финансах, бизнесе и ИТ-секторе.
В 1958 году тогда еще никому не известная за рубежом и сравнительно небольшая компания Toyota неожиданно для всех выиграла тендер на поставку крупной партии внедорожников в далекую Австралию, где стартовал один из самых амбициозных проектов той эпохи по созданию системы водохранилищ и гидроэлектростанций. Запуск этого проекта не только помог Австралии справиться с послевоенным упадком экономики, но и запустил очередную волну иммиграции из сотен тысяч талантливых инженеров и их семей.
«Благодаря этому проекту Toyota впервые запустила производство своих автомобилей за рубежом в австралийском городе Мельбурн, а принцип канбана помог ей справиться с многократно возросшей нагрузкой в плане объема реализуемых в единицу времени задач и вырасти в одну из крупнейших мировых корпораций. Сегодня канбан широко используется в проектном и производственном управлении, начиная от ставшего модным в последнее время «гроуз-хакинга», заканчивая комплексными проектами по запуску космических аппаратов», — говорит Сергей Кофанов, руководитель направления по продвижению цифровых продуктов «СберСервис».
Growth Hacking — механизмы или действия, помогающие продукту и бизнесу быстро расти. Важные элементы процесса — непрерывное экспериментирование, проверка гипотез и извлечение выводов из ошибок.
Принципы канбана
Канбан берет начало в сервисной парадигме, где все существует в виде экосистемы сервисов. В ее основе лежат четыре принципа:
Кроме принципов, канбан предлагает ряд полезных практик, которые помогут достичь желаемого результата при его использовании. Современный канбан — это набор специального инструментария, который образует систему и не терпит пренебрежения в недоиспользовании хотя бы части из него. К основным элементам этого инструментария следует отнести:
Весь этот инструментарий необходим для кратного повышения пропускной способности потока задач в организации при том же ее ресурсе, а основная идея канбана — поэтапное движение проекта.
Любая задача/проект/активность разбивается на последовательные этапы. Канбан-доску можно сравнить с движением автобуса, где конечная — это финальная цель, остановки — промежуточные этапы, а сам автобус — карточки на канбан-доске. Все участники доски знают, какова конечная цель команды, видят, какие существуют промежуточные этапы, когда и кому нужно подключиться. Таким образом, главное преимущество канбана — хорошая визуализация процессов.
Применение канбана
На сегодня принципы канбана используются во многих сферах и отраслях. Система популярна в ИТ-среде, цифровой сфере и маркетинге, строительстве, HR и СМИ. В целом методика подходит для любого бизнеса, где процесс создания продукта можно разбить на этапы с ясной последовательностью задач (задача внутри одного проекта проходит одни и те же стадии). При этом существует два основных канбана: канбан-метод и производственный канбан.
Канбан-метод придумал американский эксперт в области менеджмента Дэвид Андерсон с целью оптимизации процессов в интеллектуальных профессиях (разработчики, маркетологи, дизайнеры и так далее). Его применяют многие крупные мировые компании: Microsoft, Intel, Hewlett-Packard, Meizu. В России интересные кейсы у Тинькофф Банка, HeadHunter, REG.RU.
Производственный «канбан» подходит для оптимизации процессов на различных предприятиях, а также в рамках lean manufacturing (бережливого производства). Например, применительно к компании «Газпром нефть» метод зарекомендовал себя как инструмент, который повышает эффективность снабжения месторождений, где компания ведет или планирует вести добычу.
Существует также распространенное суждение, что метод часто применяют в ИТ, но это не совсем так. Например, в разработке он используется редко, поскольку разработчикам нужно более строгое планирование задач, разделение на спринты в одну или две недели, возможность оценить промежуточные результаты и скорректировать последующие планы.
«В Mail.ru Cloud Solutions используется Scrum. Обе эти методологии относятся к Agile-подходам, но сильно различаются между собой. Канбан позволяет выполнять потоковые работы и оценивать пропускную способность, Scrum — решать новые задачи разной сложности, дробить их на подзадачи, контролировать и корректировать ход работ и скорость выполнения. Поэтому канбан подойдет, например, для call-центра или отдела техподдержки, но не для разработчиков», — рассказывает Мурад Бяшимов, руководитель команды Mail.ru Cloud Solutions.
Канбан-доска
Канбан-доска позволяет вывести процесс выполнения задач в визуальное восприятие. Такой подход помогает видеть весь рабочий процесс, четко распределять задачи и вовремя направлять усилия в «слабые» зоны.
Это работает так: столбики представляют собой разные этапы, на которые разбивают рабочий процесс. Карточки в столбцах — это конкретные задачи-шаги. За каждый этап несет ответственность отдел/сотрудник. Карточки перемещаются по столбцам в соответствии со своим статусом.
При этом принцип формирования каждого столбца должен быть один. Например, это могут быть этапы производственного процесса («прототипирование», «дизайн», «разработка», «тестирование») или статусы выполнения задач («предстоит сделать», «в работе», «на проверке», «завершено»). По каждой колонке должно быть определено ограничение объема незавершенной работы — это позволяет предупредить перегрузы и простои. Этот принцип берет свое начало в законе американского ученого Джона Литтла, согласно которому при увеличении количества одновременно выполняемых задач, снижается скорость выполнения каждой из них. Поэтому команды постоянно балансируют между ограничением на невыполненную работу и скоростью пропускной системы. Лучшие практики ведения канбан-доски основаны на простых компонентах — обсуждение, баланс и взаимодействие.
«Не существует какого-то идеального представления о том, как должна выглядеть доска. Это живой механизм, и в определенный момент времени она показывает какую-то проблему, которую необходимо решать. Это механизм отзеркаливания процессов. Если доска показывает ту или иную проблему в процессах и подсвечивает ее команде, которая обслуживает этот сервис или продукт, то это хорошая канбан-доска», — говорит Артур Нек, директор по процессному управлению REG.RU (аккредитованный kanban-тренер и кандидат в kanban-консультанты).
Ключевые правила работы с канбан-доской:
Ошибки в применении канбана
Существует миф о том, что канбан является неким фреймворком, который можно установить с понедельника, и все начнет работать. Канбан-метод — это набор из около 140 инструментов, которые нужно постепенно применять к процессам компании, улучшая их, а также сокращать время производства, увеличивать выпуск продукта каким-либо подразделением. Здесь не получится подсмотреть у кого-то, как они используют канбан. Можно лишь взять текущие процессы и, применяя инструменты, нарастить ценность того, что уже происходит в компании, а это процесс последовательный.
Ошибка 1. Не объяснять сотрудникам принципы и практики метода, в связи с чем команды на ранних этапах внедрения терпят неудачу. Прежде всего руководителям необходимо обучить команду.
Ошибка 2. Игнорировать ограничения: часто компании ставят на доску количество задач, которое превышает ранее оговоренный лимит. В связи с этим сотрудники перерабатывают, теряют понимание цели их работы и тем самым мотивацию к повышению пропускной способности системы.
Ошибка 3. Не фиксировать срочные задачи на канбан-доске. В результате происходят перекосы рабочего процесса.
Ошибка 4. Не считаться с ограничениями WIP (количеством незавершенной работы), а это базовая практика для погружения сотрудников в текущую работу. Игнорируя WIP, вы упускаете возможность выявить узкие места рабочего процесса.
Ошибка 5. Не использовать все возможности канбана: часто в первые недели игнорируются инструменты для отслеживания метрик, такие как кумулятивная диаграмма потока, гистограмма времени производственного цикла и другие. По истечении первого периода нужно использовать эти данные как фундамент для будущих улучшений.
Ошибка 6. Не актуализировать статус задачи (например, задача выполнена, а на доске она еще в процессе работы). Это может создать неправильное представление о загрузке команды и статусе проекта.
Ошибка 7. Не подключать к канбан-доске всех лиц, которые принимают решения и планируют загрузку отделов. Если другие сотрудники не видят визуализацию процессов, они могут не в полной мере понять решения менеджера, который ведет доску.
Ошибка 8. Перегружать команды: если в одной колонке больше 15 карточек, то ее уже сложно воспринимать комплексно в контексте других задач, создается локальный «захлеб». Решение — добавлять более крупные задачи и дробить их внутри на подзадачи (например, используя чек-листы).
Ошибка 9. Не давать обратную связь в команде: улучшения невозможны без анализа текущего состояния.
Ошибка 10. Отсутствие вовлеченности команды. Канбан визуализирует процессы и задачи, объединяет людей, чтобы они вместе искали возможности для оптимизации. Непонимание командой сути использования метода может приводить в лучшем случае к ситуациям, когда все начинается и так и заканчивается доской, в худшем — к сбоям в работе.
Ошибка 11. Отсутствие приоритетов и ответственных за исполнение задач.
Сервисы для ведения канбан-досок
Для ведения канбан-доски можно взять любой из популярных сервисов, но выбор лучше делать, исходя из задач.
Trello — самый популярный и интуитивно понятный сервис, подходящий для проектов из разных сфер. Здесь можно создавать любое количество досок с разным составом команды (в бесплатной версии есть ограничение на количество досок). К карточкам можно добавлять разноцветные метки, прикреплять вложения и оставлять комментарии. Число колонок не ограничено. Однако по мере эволюции процесса, когда компания будет применять разные практики, инструментов этого сервиса может стать недостаточно, возникнет потребность расширить функционал. Именно поэтому Trello купила компания Atlassian, чтобы аудитория органически перетекала в схожий, но платный и более сложный инструмент — JIRA, откуда пользователь уже сможет перейти на еще более широкий пакет софта в облаке, если ему нужно, например, хранить документацию по проекту, или обсуждать задачи более удобный образом.
JIRA — больше подходит для ИТ, а также для технических команд и процессов, находящихся вне системы Agile. Этот сервис используют крупные компании, у которых численность штата специалистов больше, чем в малом бизнесе. Помимо возможности создавать проекты и отслеживать прогресс, в Jira есть функции отслеживания багов и интеграции со сторонними сервисами.
Kanbanize — англоязычная программа, которая поддерживает большую часть необходимых инструментов канбана, но пока не распространена в России.
Kaiten — российский сервис, максимально адаптированный к применению всех инструментов канбана и позволяющий собирать большой объем аналитики.
В целом сервисов для применения канбана довольно много: Сonceptboard, Taskify, Targetprocess, Favro, Higger, Smartsheet, TargetProcess, SwiftKanban, LeanKit, Miro, Blossom, ZenHub, MeisterTask, Kanbanchi, Breeze, ProofHub, Битрикс24, YouTrack, Asana, Kanbanery.
Как не «похоронить» проект в канбане
Самое важное — наладить работу команды с сервисом. Для этого необходимо составить инструкцию и отслеживать, как команда работает с ним. Для быстрого старта хорошо подойдут готовые шаблоны канбан-досок, но обязательно с оглядкой на реальные процессы в компании.
При этом желание внедрить канбан повсеместно во всей организации и на всю глубину сразу чревато тем, что вы завалите дело в силу его неподъемности. Во всех успешных организациях метод внедрялся не разом, а постепенно, от вдохновляющего успеха на одном участке к успеху на другом, что фактически и тождественно вдохновляющей концепции lean-стартап.
Нужно четко осознавать, что Trello (или любой другой сервис) — это всего лишь инструмент, который позволяет визуализировать активности, рассчитывать метрики. Не нужно полагаться только на инструменты при применении любого подхода, нужно сначала изучить основы и принципы, понять, зачем все это нужно, а потом уже подстраивать инструменты под свои нужды, и тогда успех обеспечен.
В создании материала также участвовали:
В Telegram-канале «Списать не получится» мы еще больше рассказываем о трендах в образовании и о том, как учиться в течение всей жизни и делать это с удовольствием. Подписывайтесь!
Пределы разрабатываемого проекта
Возвращение «потока» обратно в рабочий процесс с лимитами WIP
Лимита работы в процессе выполнения не предназначены для фактического лимита вашего прогресса. На самом деле, совершенно наоборот.
Каковы лимиты WIP?
В гибкой Agile разработке пределы незавершенного производства (WIP) задают максимальный объем работы, который может существовать в каждом статусе рабочего процесса. Ограничение объема выполняемой работы облегчает выявление неэффективности в рабочем процессе команды. Узкие места в конвеере предоставления команды хорошо видны до того, как ситуация станет ужасной.
Почему лимиты WIP важны?
Итак, теперь вы думаете: «Скажи мне больше!» (Ну, я надеюсь, что вы.)
Лимиты WIP повышают пропускную способность и сокращают объем работы, «почти выполненной», заставляя группу сосредоточиться на меньшем наборе задач. На фундаментальном уровне лимиты WIP поощряют культуру «сделано». Более того, лимиты WIP делают блокировщики и узкие места видимыми. Команды могут копаться в блокирующих задачах, чтобы их понять, реализовать и решить, когда есть четкий индикатор того, что существующая работа вызывает узкое место. Как только блокировки устранены, работа в команде снова возобнавляется. Эти преимущества гарантируют, что прирост стоимости будет предоставлен клиентам быстрее, что делает WIP-лимиты ценным инструментом в Agile разработке.
ТВИИТ: Кроме того, многозадачность обманчиво трудоемка.
Наконец, лимиты WIP указывают на области хронического бездействия или перегрузки. Они помогают команде увидеть неэффективность всего процесса, а не только конкретной области, в которой они работают.
PRO TIP:
Для команд, плохо знакомых с лимитами WIP, они будут чувствовать себя неловко. Потратьте время, чтобы обсудить их в первых нескольких итерациях. Понять, когда и почему команда превысила лимиты WIP. Не поддавайтесь искушению вначале произвольно настроить их. Если брешь становится постоянной, это признак того, что либо лимиты WIP слишком ограничены, либо процесс команды неэффективен.
Использование лимитов WIP для Agile команд
Теперь, когда вы проданы по их стоимости, давайте приступим к медным тикам.
При внедрении нового рабочего процесса примите групповое решение, чтобы определить лимит WIP для каждого статуса. Мы рекомендуем устанавливать лимиты WIP после отслеживания среднего количества рабочих элементов в каждом статусе за несколько спринтов.
Ниже приведен пример Agile доски с лимитами WIP, используемой типичной командой разработчиков программного обеспечения.
Выше был установлен лимит WIP при проверке кода. Поскольку столбец превышает свой предел, фон стал красным.
Поскольку после того, как задача будет решена, ничего не остается делать, там нет необходимости в лимите WIP. На приведенной выше доске «Готово для разработки» означает, что история полностью проверена владельцем продукта и командой. Команда разработчиков переводит работу из состояния «готово для разработки» в состояние «в процессе», когда они начинают работу над заданиями. Рекомендуется сохранять достаточное количество работы в статусе «готово для разработки», чтобы каждый член команды разработчиков оставался полностью задействованным. Сохраняя только достаточное количество историй в состоянии «готово к разработке», владелец продукта не слишком далеко опережает игру, когда речь идет об уточнении требований, и программа становится более отзывчивой к изменениям.
Списки статусов «в процессе» работают в активной разработке. Цель лимитов WIP в этом случае состоит в том, чтобы гарантировать, что у каждого есть работа, но никто не занимается многозадачностью. На приведенной выше доске лимит на количество элементов в процессе составляет 4, и в настоящее время в этом состоянии находятся 3 элемента. Это говорит команде, что у них есть возможность взять на себя больше работы. В качестве лучшей практики некоторые команды устанавливают максимальный лимит WIP ниже количества членов команды. Идея состоит в том, чтобы приготовить в комнате для хорошей Agile практики. Если разработчик заканчивает работу над элементом, но команда уже достигла лимита WIP, он знает, что пришло время отказаться от нескольких обзоров кода или присоединиться другому разработчику для некоторого парного программирования.
Лимиты WIP гарантируют, что не пересмотренный код не накапливается в куче.
Обратите внимание, что на Agile доске выше, у команды слишком много обзоров кода, поэтому столбец стал красным, чтобы указать на это.
АНТИ-ОБРАЗЦЫ, ДЛЯ НАБЛЮДЕНИЯ:
4 цели для Agile команд, использующих лимиты WIP
Цель 1: Последовательно измеряйте отдельные задачи. Разбивая требования и истории пользователей, важно, чтобы отдельные задачи выполнялись не более 16 часов. Это повышает способность команды уверенно оценивать и помогает избежать узких мест. Ничто не замедляет работу команды и не усугубляет лимитов WIP, как большой рабочий элемент, замедляющий процесс разработки.
PRO TIP:
Цель 2: Сопоставляйте лимиты WIP с навыками команды. В приведенном выше примере предполагается, что члены команды имеют схожие наборы навыков. Если в вашей команде есть специалисты, лимиты работы в процессе выполнения могут отличаться в зависимости от специалиста. Создавайте статус, специфичный для работы специалиста. Если в этом статусе возникают узкие места, используйте возможность обучить других членов команды, чтобы добавить дополнительные возможности для наборов навыков специалиста и увеличить поток по всей команде.
Цель 3: Уменьшайте безделие. Если у члена команды есть время простоя, попросите его помочь вышестоящему или последующему члену команды. Они будут способствовать общей продуктивности команды и чему-то научатся!
Цель 4: Защищайте устойчивую инженерную культуру. Лимиты работы в процессе выполнения не означают, что разработчики должны торопиться с работой, чтобы избежать перегрузки в конкретном статусе. Они предназначены для поддержки надежных практик Agile разработки, которые защищают качество продукта и работоспособность базы кода.
По материалам Agile Coach «WIP limits»
WIP-лимиты здорового человека и WIP-лимиты курильщика
Я и мои коллеги по работе для внутренних сотрудников компании, в которой я работаю, периодически готовим небольшие статьи, где разбираем различные кейсы по гибким подходам, включая и кейсы использования Канбан-метода для совершенствования и управления процессами. Такие статьи мы называем «Agile-shorts». И я подумал, «А почему бы не открывать свои статьи и для более широкой аудитории?» И, вот, сегодня я публикую первую свою статью из этой серии.
Сегодня я расскажу один из кейсов, почему проваливается использование такой практики как «Ограничение количества незавершенной работы» или WiP-лимиты. Оговорюсь, что это не единственная причина, но, на моей практике, очень распространенная. В будущих статьях, я, возможно, раскрою эту тему дополнительными интересными ситуациями.
Мало кто, работающий в ИТ-сфере, не слышал про гибкие подходы к созданию продуктов. Слова Agile, Kanban, Scrum уже крепко проникли в лексикон современных компаний. Кто-то их произносит с гордостью, кто-то с иронией, а кто-то сквозь зубы.
Последние, вероятно, на своем опыте столкнулись с неудачным использованием какого-то управленческого инструмента, и спроецировали свой негативный опыт на все будущие идеи.
Но эта заметка не для них. Эта заметка для вас, тех, кто понимает, что инструменты можно использовать по-разному, а на ошибках готов учиться.
Ограничиваем Пользовательские Истории, а работаем с Подзадачами
Часто, познакомившись с основами практик и методов, которые используются в Agile-культуре, у людей складывается впечатление, что, нажав Ctrl+C и Ctrl+V, они у себя получат ту же замечательную вещь, которую они увидели в учебном кейсе. На деле же оказывается, что «Ctrl+V» приходится, как в анекдоте, тщательно дорабатывать напильником.
Визуализируя работу команды, неофиты часто совмещают на одном уровне задачи, которые несут ценность для Заказчика, с задачами, которые имеют ценность только внутри процесса. Почему, спросите, совмещают? В основном, потому что привыкли работать в парадигме – «мне поставили задачу – я делаю задачу – я сделал задачу», в которой для выполнения не обязательно задумываться о ценности: «Ведь начальник уже об этом сам подумал, раз отдает задачу в работу».
В итоге, на одном уровне управления можно встретить такие задачи:
Провести нагрузочное тестирование – не самостоятельная задача, а нужна для прогресса какой-то другой
Заключить контракт с поставщиком ХХХ – не самостоятельная задача, а нужна для старта работ по другой задаче
Реализовать функционал голосового ввода – пользователь получит новый функционал для использования
Что же делать, спросите вы? Ответ в том, чтобы разделить разные уровни управления и понимать, какую проблему мы решаем.
Какие бывают уровни:
Работа на уровне исполнения задач одним человеком.
Для снятия перегруза с сотрудника используются персональные лимиты. В этом случае рассматриваются взгляд исполнителя – на задачи смотрят со стороны сотрудника, который выполняет работу.
Работа на уровне команды. Для нормирования работы команды, используются:
лимиты на систему/команду/сервис (Бэклог спринта – частный случай лимита на систему)
лимиты на тип задач (Квотирование)
лимиты на этап (работа с узкими горлами)
и другие, более экзотические типы ограничений
В этом случае нужно смотреть на задачи глазами Заказчика работ. Появляется такой объект как Customer recognizable item – задача, смотря на которую, Заказчик понимает, что это именно то, что он заказывал, и видит, что происходит с заказом.
Работа на уровне портфеля
Для эффективного распределения ресурсов для реализации портфеля инициатив, используются лимиты на объекты портфеля.
Например, лимиты на Эпики, чтобы сфокусироваться на завершении какого-то направления, а не распыляться на всё сразу. Хотя, конечно, это уже вопрос маркетинговой стратегии. Или на инициативы портфеля инициатив – чтобы сфокусироваться на скорости проверки гипотез и, в свою очередь, выбрать именно те, что даст нам конкурентное преимущество.
Резюмируя эту заметку, хочется подчеркнуть три вещи, которые помогут вам избежать ошибок и получить положительный опыт:
Попробуйте понять, для чего нужен инструмент, и в каком контексте он работает
Осознайте проблему, которую вы хотите решить применением инструмента
Если что-то не получается, допустите, что это не инструмент плох, а есть что-то, что вы не учли
И тогда, разочарование от того, что «мы потратили кучу времени, а оно не работает», вас обойдет стороной.