Дэвид Андерсон - Канбан. Альтернативный путь в Agile
Еще одна альтернатива – спросить, в каком уровне ответной реакции нуждается бизнес. Лучше всего это сделать в контексте задания классов обслуживания. Например, если вам говорят: «Нам нужен релиз через три дня», спросите: «Все ли элементы нужно реализовать за три дня?» Чаще всего ответ будет отрицательным. Это даст возможность запросить определение типов запросов, которые должны быть реализованы в течение трех дней. После этого можно создать класс обслуживания для данного типа заданий. Повторите процесс для оставшихся заданий.
В итоге должно получиться расслоение рабочих запросов на несколько уровней, которым и будут соответствовать разные классы обслуживания. Не исключено, что на каждом уровне встретятся задания, которые потребуют примерно одинаковых издержек из-за отсрочки. Подробнее создание классов обслуживания и идея функций издержек из-за отсрочки описаны в главе 11.
Целевое время выполнения, которое вы устанавливаете для каждого класса обслуживания, должно быть именно целью, а не обещанием. Вы обещаете сделать все от вас зависящее, чтобы уложиться в целевое время и сообщить о выполнении в срок, установленный в соглашении об уровне обслуживания для каждого класса обслуживания. В некоторых ситуациях, чтобы договориться о том, что время выполнения в соглашении об уровне обслуживания – это цель, а не обязательство, может не хватить доверия. Если приходится согласиться с тем, что время выполнения в соглашении об уровне обслуживания считается обязательным, следует ради безопасности установить буфер. Это укажет на то, что низкий уровень доверия выливается в прямые экономические расходы.
Выходные критерии для обсуждений с партнерами таковы: вы добились консенсуса по WIP-лимитам по всей цепочке создания ценности, достигнуто соглашение о координации расстановки приоритетов и используемом для нее методе и такое же соглашение о координации и методах сдачи работы, имеется определение набора соглашений об уровне обслуживания, включающее целевое время выполнения для каждого класса обслуживания.
Выводы
• Можно выделить как минимум восемь целей внедрения Канбана в вашей организации.
• Улучшайте производительность, внося в процесс усовершенствования, которые будут встречены с минимальным сопротивлением.
• Сдавайте высококачественную работу.
• Время выполнения должно оставаться предсказуемым благодаря контролю числа незавершенных заданий.
• Создайте оптимальные условия для членов команды, улучшив их баланс работы и жизни.
• Внесите в систему резервы, сбалансировав нагрузку и пропускную способность.
• Обеспечьте простой механизм расстановки приоритетов, при котором обязательства откладываются, а варианты долго остаются возможными.
• Обеспечьте прозрачную схему, чтобы были видны возможности для роста. Тогда будут возможными сдвиги в сторону культуры большего сотрудничества, которые приведут к непрерывному совершенствованию.
• Боритесь за процесс, дающий предсказуемые результаты, деловую гибкость, хорошее управление и переход к тому, что Институт по разработке программного обеспечения называет организацией высокой зрелости.
• Важно определить цели и уметь формулировать преимущества введения Канбана, чтобы достичь консенсусного соглашения с другими заинтересованными лицами.
• Следуйте пошаговому 12-этапному руководству по введению Канбан-процесса.
• Канбан предполагает иной тип сделки с внешними заинтересованными лицами и владельцами бизнеса. Это сделка, основанная на долгосрочных отношениях и обязательствах по производительности на системном уровне.
• Привлечение внешних заинтересованных лиц к договору о базовых элементах канбан-системы позволяет заручиться их сотрудничеством.
• Основные правила, касающиеся WIP-лимитов, целевого времени выполнения, классов обслуживания, расстановки приоритетов и релизов, – это правила совместной игры по разработке программного обеспечения.
• Привлечение внешних заинтересованных лиц к сотрудничеству позволит рассчитывать на их помощь позже, когда система подвергнется серьезным нагрузкам.
Часть IV
Совершенствование
Глава 16
Три типа возможностей для совершенствования
Главы 6–15 рассказывают о том, как создать канбан-систему и поддерживать ее работу и как принять на вооружение Канбан-подход к управлению изменениями и совершенствованию. Оставшаяся часть этой книги описывает, как обнаружить возможности для совершенствования, что с ними делать и как выбрать между разными возможностями.
В главе 2 приводятся пять ключевых практик, которыми должна обладать организация, использующая Канбан. Пятая по счету связана с использованием моделей для определения, оценки и стимулирования возможностей по совершенствованию. Вариантов много. В этой главе речь пойдет о трех распространенных моделях и некоторых их разновидностях: о теории ограничения систем и ее пяти направляющих, об идее бережливого мышления (Lean Thinking), которая определяет ненужные действия как экономические затраты, а также о некоторых вариантах, сводящихся к определению и снижению вариативности. Возможны и другие модели. Уже проходят эксперименты с такими моделями, как теория реальных опционов и управление рисками. Ниже приводятся примеры, которые можно использовать как точку отсчета. Хотелось бы, чтобы вы взяли эти методы на вооружение, поскольку они действительно работают, а впоследствии расширяли горизонты знаний и изучали другие модели, позволяющие командам создавать усовершенствования.
Бутылочные горлышки, устранение потерь и снижение вариативности
Каждая из этих моделей совершенствования подробно исследовалась и разрабатывалась в соответствующей области знаний. В каждой из них присутствует свой стиль представлений о теории непрерывного совершенствования. В Канбане я постарался синтезировать все три школы и дать обзор того, как выявлять возможности совершенствования и реализовывать усовершенствования при внедрении каждой модели.
В каждой из трех школ, описанных выше, есть группа лидеров, конференции, собственный набор знаний и опыта, группа последователей. Любая компания может влиться в одну или сразу в несколько таких школ. Преимущество в данном случае – это умение показать, как Канбан-метод может открыть возможности совершенствования в любимом стиле вашей организации. Широкий набор парадигм для улучшения и инструментов, из которых можно выбрать, должен обеспечить высокий уровень гибкости при изменениях. Те, кто хорошо знаком с методологиями непрерывного совершенствования, могут пролистать эти страницы и перейти сразу к главе 17. А всем, кому интересен анализ доступных методов, а также сведения из литературы и истории, оставшаяся часть главы будет полезна.
Теория ограничения
Теория ограничения была разработана Элияху Голдраттом и опубликована впервые в уже упоминавшемся бизнес-романе «Цель» в 1984 году. За последние 25 лет вышло несколько редакций «Цели», в последних из которых была более четко обрисована теоретическая структура, известная как «пять направляющих шагов».
Пять направляющих шагов – основа непрерывного совершенствования в теории ограничений. Это так называемый процесс непрерывного совершенствования (POOGI, Process Of OnGoing Improvement). Теория ограничений (или TOC) вообще полна аббревиатур. Как ни странно, пять направляющих шагов – исключение. Эти названия не сокращаются до ПНШ.
В 1990-е годы в рамках теории ограничений разработан метод анализа глубинных причин и управления изменениями, известный как мыслительные процессы (он же TP, Thinking Processes). Причина в осознании консультантами, придерживающимися ТОС, того факта, что их ограниченный успех в работе с клиентами вызван сопротивлением изменениям и недостаточно умелым управлением ими.
Казалось, что пять направляющих шагов успешно работают только с проблемами потока, а многое из того, что возникает на рабочем месте, не слишком вписывается в эту парадигму. Так возникли TP. Профессиональная подготовка и программа обучения для консультантов по ТОС сместилась от использования пяти направляющих шагов и применения этой концепции (например, «барабан-буфер-канат») к использованию ТР. Поэтому многие члены сообщества, говоря о ТОС, имеют в виду ТР, а не пять направляющих шагов. Бывая на конференциях по ТОС, могу с уверенностью сказать, что использование пяти направляющих шагов кажется сейчас своего рода утраченным искусством.
Сообщество ТОС, насколько я могу судить, склоняется к принятию существующих парадигм и не ставит их под сомнение. Поэтому решение ТОС для управления проектами – критическая цепь – развилось из парадигмы тройного ограничения (объем, бюджет и сроки) и модели графика зависимостей для организации задач в проекте. Эта модель не подверглась никаким сомнениям, пока я не опубликовал свою первую книгу Agile Management for Software Engineering, где высказал критику в адрес парадигмы управления проектами и предположил, что лучше моделировать проекты как цепочку создания ценности и проблему потока, к которым применять впоследствии пять направляющих шагов. Благодаря этому стало возможно использовать все знания в области бережливого управления, основанные на понятии потока, и совместить их с представлением о бутылочных горлышках, характерном для пяти направляющих шагов. Синтез ТОС с бережливым управлением привел к улучшению производительности проектов и всей организации и заложил основания для зарождения Канбана.
