Бережливое производство пришло к нам из США. Фактически бережливое производство – это осмысление производственной системы Toyota американскими учеными. Бережливой такую систему организации труда называют, потому что она нацелена на сокращение издержек в виде потерь производства (вообще это достаточно узкий взгляд на данную систему).
Основателем производственной системы Toyota был Тайити Оно, который еще в послевоенное время сделал первые попытки оптимизации производства. Его компания была вынуждена конкурировать с такими гигантами, как Ford, которые за счет эффекта масштаба производства имели достаточно низкую себестоимость произведенных автомобилей.
Ценность – основа бережливого производства
Чтобы понять концепцию бережливого производства, нужно представлять, что такое ценность для потребителя. Ценность – это преимущества, которые потребитель получит от использования вашего продукта или услуги. Бережливое производство расценивает все, что не добавляет ценности продукту, потерями, которые на японском языке называются муда. Основой бережливого производства как раз и является устранение муды.
Виды потерь
Классически выделяются семь видов потерь:
• перепроизводство;
• ожидание;
• ненужная транспортировка;
• лишние этапы обработки;
• лишние запасы;
• ненужные перемещения;
• дефекты.
В самой популярной книге о производственной системе Toyota «Дао Toyota» авторы обозначили восьмой вид потерь: нереализованный творческий потенциал сотрудников.
Традиционно выделяют также еще два вида потерь:
• му́ри (перегрузка);
• му́ра (неравномерность).
Инструменты бережливого производства. Бережливое производство ПО
Принципы бережливого производства можно применить и в разработке программного обеспечения.
Уменьшение потерь. Видов потерь в разработке программного обеспечения достаточно много: от переключения между задачами до реализации лишнего функционала. Помните правило 20/80: 20 % функционала продукта приносят 80 % ценности заказчику, и именно гибкие методологии позволяют эти 20 % функционала выявить и назначить им максимальную важность.
Фокусировка на обучении. Весь процесс создания программного обеспечения фактически состоит из обучения: с каждой новой функцией мы узнаем что-то новое, поэтому, как и для любой другой инженерной деятельности, следует сосредотачиваться на обучении.
Встроенное качество. Необходимость высокого качества продуктов никто не оспаривает, но редко кто действительно вкладывает в это хотя бы чуточку усилий. В нашей индустрии есть устоявшиеся практики по контролю и обеспечению качества – это автоматические тесты и разработка в стиле TDD.
Позднее принятие решений. Очень важно принимать решения как можно позже. Самым ярким примером здесь является создание архитектуры приложения. В противоположность подходу Big Up Front Design мы создаем архитектуру только для текущего функционала, следуя принципам KISS и YAGNI.
Быстрая поставка. Бережливое производство ПО предполагает максимально быстрые и частые поставки для получения обратной связи.
Уважение к людям. Люди – это основа любой мыслительной деятельности, к которой, несомненно, относится разработка ПО. Мы должны уважительно относиться к командам, предоставляя им максимум полномочий и ответственности.
Оптимизация системы целиком. Мы должны оптимизировать всю систему целиком, не занимаюсь субоптимизацией отдельных сегментов.
Производственная система «Тойоты» (Toyota Production System, TPS)
Ниже приведены 14 принципов TPS.
1. Философия долгосрочной перспективы: можно пойти на убытки для достижения отдаленной цели.
2. Производственный поток должен быть непрерывным.
3. Канбан: производство по системе «точно вовремя» без промежуточных запасов.
4. Хейдзунка: равномерное распределение нагрузки на всех этапах технологического процесса.
5. Андон и дзидока: автоматическая остановка производства с целью решения проблем.
6. Формализация накопленных знаний: достигнутое нужно делать новым стандартом.
7. Визуальный контроль: иногда простая лампочка эффективнее компьютерного монитора.
8. Внедрять только проверенные технологии.
9. Воспитывать собственных лидеров, искренне исповедующих философию компании.
10. Формировать и воспитывать рабочие команды, в которых каждый искренне исповедует философию компании.
11. Уважать и развивать партнеров-поставщиков.
12. Генти гаубицу: перед тем как начать разбираться в ситуации, увидеть все своими глазами.
13. Немаваси: принимать коллективные решения только после согласия большинства, но внедрять немедленно.
14. Хансей и кайзен: любой процесс можно постоянно анализировать и совершенствовать.
Кайзен
Японское слово «кайзен» состоит из двух иероглифов, которые можно перевести как «изменения, направленные на улучшения».
Кайзен
На практике кайзен – это стратегия постоянного улучшения путем небольших изменений. Для реализации такого подхода необходимо следовать принципам кайзена, которые отлично согласуются с гибкими методологиями.
Фокус на клиентах – мы должны быть сфокусированы на клиентах, причем не только на словах, но и на деле.
Непрерывные изменения – все аспекты нашей производственной системы должны постоянно улучшаться небольшими шагами, для чего мы будем активно обсуждать процессы на ретроспективах.
Открытое признание проблем – мы должны честно и открыто признавать и обсуждать все проблемы не для поиска виноватых, а для оптимизации процессов.
Создание сообществ – организация сообществ (необязательно формальных) является важной частью оптимизации производства, потому что позволяет организовать обсуждения для инициативы снизу.
Управление проектами с помощью межфункциональных команд – команды в Scrum максимально многофункциональны и включают в себя всех необходимых специалистов для реализации проекта.
Формирование поддерживающих взаимоотношений – для организации таких взаимоотношений необходимо уделять внимание социальной атмосфере в коллективе.
Развитие самодисциплины – команды в Scrum самоуправляемы и могут определять, как они будут достигать целей, поставленных владельцем продукта.
Информирование каждого сотрудника – информация (в том числе коммерческая) должна быть максимально прозрачна для каждого сотрудника.
Делегирование полномочий каждому сотруднику – чем больше полномочий (и ответственности) делегировано конкретным исполнителям, тем больше возможность появления креативных и прорывных идей и тем больше времени у руководства для проработки стратегических решений.
Инструменты кайзена
Кроме философии и культуры, которые, безусловно, важны в долгосрочной перспективе, кайзен предлагает использовать набор инструментов для оптимизации производственных процессов. В этом разделе мы рассмотрим наиболее часто применяемые.
Карта потока создания ценности
Карта потока создания ценности (Value Stream Mapping) – инструмент, который отображает стадии производственного процесса и время между ними. Затем производится подсчет эффективности процесса, как частное от полезного времени, когда добавлялась ценность продукту, и общего времени работы процесса.
Пример карты потока создания стоимости
После этого процесс перестраивается с целью увеличить его эффективность. В рамках Scrum такой анализ имеет смысл проводить не по отдельным историям пользователя, а по эпикам или темам.
Пять «почему»
Самый простой инструмент, который может применяться даже в устной форме. Его суть состоит в поиске коренных причин проблем (например, дефектов) и принятии многоуровневых контрмер. Для этого по отношению к проблеме задается пять раз вопрос «Почему?», чтобы проникнуть в ее суть (табл. 11.1).
Таблица 11.1.
Пять «почему»
Диаграммы причинно-следственной связи
Такие диаграммы являются уже более тяжеловесным инструментом по сравнению с пятью «почему». На них отображается множество проблем и их связи, но целью та же – выявление коренных причин. В качестве нотации можно посоветовать упрощенную, предложенную Хенриком Книбергом («Scrum и XP: заметки с передовой», Книберг Хенрик).
Диаграммы Исикавы
Еще одним инструментом для анализа проблем, но уже на уровне организации в целом, является диаграмма Исикавы. На ней также отображаются проблемы, но они заранее сгруппированы по нескольким областям, например:
• методология;
• требования;
• разработка;
• контроль качества.
Пример нотации для анализа причинно-следственной связи
Пример диаграммы Исикавы
Контрольные карты
Данный инструмент используется для выявления несистематических отклонений и устранения вариаций. Для этого собираются данные и упорядочиваются, например, по времени. Затем вычисляется среднее значение и стандартное отклонение от него. В качестве примера приведу контрольную карту по дефектам, которая показывает пользу от внедрения инженерных практик.
Классическим применением является сравнение некоторых элементов системы по выбранному показателю. Например, мы хотим определить, насколько наши проекты хорошо тестируются. Для этого можно собрать простую статистику – количество дефектов в финальной версии продуктов в равных временных промежутках на одного разработчика – и построить по ним контрольную карту.
По ней видно, что проект № 9 имеет несистемные отклонения. Если количество дефектов больше, чем при стандартных отклонениях, то необходимо выработать меры, прежде всего процессные, для улучшения качества.
Контрольные карты бывают разных видов, например классические контрольные карты Шухарта ((Госстандарт России, 1999) и (Уилер и др., 2009)). Различия касаются формул и значений для выбора среднего значения и контрольных пределов. В контрольных картах Шухарта для определения предела используется не стандартное отклонение, а размах. Существует также набор правил для трактовки контрольных карт, например правила Western Electric и правила Нельсона.
Отдельно подчеркну, что нельзя использовать такие карты напрямую для оценки сотрудников: большая часть проблем относится к процессам, и работники часто просто не могут на эти причины повлиять.
Контрольная карта по дефектам
Контрольная карта по дефектам в разрезе проектов
Диаграмма Парето
Этот инструмент позволяет выявить модули, которые содержат определенный процент дефектов. Обычно получается соотношение, близкое к 20/80: 20 % модулей содержат 80 % дефектов.
Именно на эти модули стоит обратить внимание:
• покрыть их дополнительно тестами;
• провести дополнительные инспекции кода.
Диаграмму Парето можно использовать для анализа модулей по дефектам, но можно этим и не ограничиваться: аналогичный анализ можно провести по количеству вносимых изменений.
Диаграмма Парето
Модули, в которые часто вносятся изменения, экономически выгодно сделать более гибкими:
• сделать более гибкую и настраиваемую архитектуру;
• активно использовать шаблоны проектирования для дополнительной гибкости.
Итоги