Дэвид Андерсон - Канбан. Альтернативный путь в Agile

Драгош Думитриу в команде XIT в Microsoft решил, что разработчики и тестировщики не должны работать одновременно более чем над одним заданием. Никакой многозадачности. Объявление было сделано в одностороннем порядке, но, к счастью, не привело к проблемам с другими заинтересованными лицами. Это соответствовало текущим методам работы и индивидуальному процессу разработки ПО (PSP), принятому в то время в команде. Организация обладала достаточной степенью зрелости, чтобы поддерживать дисциплину и следовать заранее установленным процедурам. Как уже упоминалось, осенью 2004 года в команде было три разработчика и три тестировщика. Таким образом, WIP-лимит на разработку и тестирование равнялся трем.

В 2006 году в Corbis, выступив с инициативой в области инженерного обеспечения, мы приняли такое же решение: аналитики, разработчики и тестировщики должны работать над одной задачей одновременно. Для новых крупных проектов мы принимали другие решения. Работа над ними предусматривала увеличение численности команды. Нередко над одной задачей трудились небольшие команды из двух-трех человек. Поскольку эти задачи могли блокироваться или откладываться, мы решили использовать переключение между задачами и дополнительную параллельность в работе, поэтому WIP-лимит был задан с таким расчетом, чтобы над единицей работали два-три человека, но допускалось некоторое перекрытие задач. Например, если у нас было десять человек и расчет «два человека на задачу», то WIP-лимит составил бы пять плюс еще немного, чтобы нивелировать возможный эффект от блокировки. В таких обстоятельствах подходящее значение лимита – 8 (5 + 3).

Некоторых авторов исследования и эмпирические наблюдения привели к мысли, что две задачи в работе на одного квалифицированного специалиста – это оптимальный вариант. Часто этот вывод приводят в качестве оправдания многозадачности. Однако я считаю, что эти наблюдения отражают только состояние в изучаемых организациях, где существует множество задержек и причин для откладывания работы. В исследованиях не отражена организационная зрелость компаний, к тому же они не соотносятся с данными внешних источников (варианты систематических погрешностей, о которых пойдет речь в главе 19). Таким образом, результат может отражать только изучаемые условия и не подходить для иных ситуаций. Тем не менее нужно быть готовым к тому, что решение брать не более одной задачи в работу на одного-двух сотрудников или на небольшую команду встретит сопротивление как слишком жесткий вариант. В таком случае разумно сделать WIP-лимит для одного-двух сотрудников или на команду. Порой приемлем и лимит в три задачи.

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

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

Например, очереди «Разработка» и «Готово к разработке» объединены, как показано на рис. 10.1. Если установлены действительно жесткие правила по WIP-лимитам, например строго один элемент на одного-двух человек или на небольшую команду, то необходимо организовать очередь, чтобы поддерживать рабочие задания и амортизировать вариативность. Когда ваша канбан-система на практике страдает от политики «остановка-запуск», которая вынуждает сотрудников к простою из-за того, что на выполнение заданий требуется разное время, стоит подумать об увеличении размеров очереди. Однако если вы сделали выбор в пользу, например, двух задач на одного-двух человек или на команду, то буфер для амортизации вариативности уже организован, так что размер очереди часто будет равен нулю. Просто объедините столбец рабочих задач с очередью.

Рис. 10.1. Стена карточек, демонстрирующая различные типы очередей и буфер

Бутылочное горлышко в рабочем потоке может потребовать буфера перед ним, как показано на рис. 10.1. Это типичный механизм амортизации бутылочных горлышек, о чем будет рассказано в главе 16 Глава 16 Три типа возможностей для совершенствования Главы 6–15 рассказывают о том, как создать канбан-систему и поддерживать ее работу и как принять на вооружение Канбан-подход к управлению изменениями и совершенствованию. Оставшаяся часть этой книги описывает, как обнаружить возможности для совершенствования, что с ними делать и как выбрать между разными возможностями. В главе 2 приводятся пять ключевых практик, которыми должна обладать организация, использующая Канбан. Пятая по счету связана с использованием моделей для определения, оценки и стимулирования возможностей по совершенствованию. Вариантов много. В этой главе речь пойдет о трех распространенных моделях и некоторых их разновидностях: о теории ограничения систем и ее пяти направляющих, об идее бережливого мышления (Lean Thinking), которая определяет ненужные действия как экономические затраты, а также о некоторых вариантах, сводящихся к определению и снижению вариативности. Возможны и другие модели. Уже проходят эксперименты с такими моделями, как теория реальных опционов и управление рисками. Ниже приводятся примеры, которые можно использовать как точку отсчета. Хотелось бы, чтобы вы взяли эти методы на вооружение, поскольку они действительно работают, а впоследствии расширяли горизонты знаний и изучали другие модели, позволяющие командам создавать усовершенствования. . Важен масштаб буфера – желательно, чтобы он был как можно меньше. Буферы и очереди вносят в систему незавершенные задачи, что увеличивает время выполнения. Однако буферы и очереди делают рабочий поток более равномерным, что улучшает предсказуемость времени выполнения. Тем самым они увеличивают пропускную способность, и канбан-система может обработать больше задач. Буферы также сохраняют более равномерную занятость людей. Необходим баланс, который и помогают поддерживать буферы. Во многих случаях приходится стремиться к деловой гибкости и более короткому времени выполнения, а также повышению качества, связанному с меньшим количеством незавершенных задач. Однако в погоне за гибкостью или качеством не стоит жертвовать предсказуемостью. Если размеры очереди и буфера слишком малы, так что ваша система страдает от политики «остановка-запуск», вызванной вариативностью, то время выполнения окажется непредсказуемым, а вариативность – огромной. Выбирая WIP-лимит для буфера, нужно иметь в виду, что он должен быть достаточно большим, чтобы обеспечить равномерный ход работы по системе и исключить простой перед бутылочными горлышками. Подробнее о масштабах буфера и о том, как создать буферы для бутылочных горлышек с ограниченной пропускной способностью и задержкой доступа элементов, мы расскажем в главе 16 Глава 16 Три типа возможностей для совершенствования Главы 6–15 рассказывают о том, как создать канбан-систему и поддерживать ее работу и как принять на вооружение Канбан-подход к управлению изменениями и совершенствованию. Оставшаяся часть этой книги описывает, как обнаружить возможности для совершенствования, что с ними делать и как выбрать между разными возможностями. В главе 2 приводятся пять ключевых практик, которыми должна обладать организация, использующая Канбан. Пятая по счету связана с использованием моделей для определения, оценки и стимулирования возможностей по совершенствованию. Вариантов много. В этой главе речь пойдет о трех распространенных моделях и некоторых их разновидностях: о теории ограничения систем и ее пяти направляющих, об идее бережливого мышления (Lean Thinking), которая определяет ненужные действия как экономические затраты, а также о некоторых вариантах, сводящихся к определению и снижению вариативности. Возможны и другие модели. Уже проходят эксперименты с такими моделями, как теория реальных опционов и управление рисками. Ниже приводятся примеры, которые можно использовать как точку отсчета. Хотелось бы, чтобы вы взяли эти методы на вооружение, поскольку они действительно работают, а впоследствии расширяли горизонты знаний и изучали другие модели, позволяющие командам создавать усовершенствования. .