Принципы lean: инструменты, методы и этапы внедрения – Что такое lean production и с чем его едят?

Содержание

Waterfall, Lean и Feature Driven Development / ИТ Гильдия corporate blog / Habr

В нашем прошлом материале мы писали о методологиях разработки программного обеспечения, которые помогают оптимизировать рабочие процессы. Тогда речь шла о Scrum, канбан и экстремальном программировании. Сегодня мы расскажем о Waterfall, FDD и Lean — оценим плюсы и минусы подходов и взглянем на опыт организаций, которые их используют, чтобы помочь вашим компаниям оптимизировать процессы.

/ Flickr / Hamza Butt / CC

Waterfall

Waterfall, или каскадная модель, — традиционная методология, которая существует с 1970 года. В ней разработку проекта разбивают на этапы: от анализа системных требований до выпуска продукта.

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

Изначально автор Waterfall Винстон Ройс (Winston Royce) привел каскадную модель как пример неэффективного способа разработки программного обеспечения, который ведет к ошибкам и выпуску некачественных продуктов. Однако потом в своей статье он довел методологию «до ума», отметив обратные связи и переходы от тестирования к написанию кода и др.

По данным исследования PMI, 12% компаний используют методологию Waterfall на постоянной основе, а 40% респондентов утверждают, что часто к ней обращаются. А по данным LiquidPlanner, каскадную модель используют 25% организаций.

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

Создание концепции. Первая фаза жизненного цикла разработки ПО (SDLC) включает в себя анализ затрат и результатов и оценку масштабов проекта.

Подготовка. Набор команды, определение целей и задач.

Анализ. Изучение объема работ и требований.

Дизайн. Создание прототипа и согласование его с заказчиком.

Разработка/написание кода. Создание ПО на основе утвержденного прототипа.

Тестирование. Готовый продукт тестируют.

Реализация. Продукт выходит на рынок.

Техническое обслуживание. Устранение выявленных недочетов и поддержка.

Среди преимуществ методологии можно выделить чёткую структуру и предсказуемый рабочий процесс. Это позволяет легко оценить затраты и прикинуть сроки выполнения до начала проекта. Резиденты Quora утверждают, что такие тонкости важны для финансовых и страховых компаний или компаний, которые разрабатывают «железо».

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

Однако есть и недостатки. Клиенты часто не знают, чего они действительно хотят, пока не взглянут на прототип. А по Waterfall нужно определять все требования заранее, поэтому есть риск что-то упустить. Исследование процесса разработки сайта компании Ericsson AB показало, что каскадная модель привела к путанице, и 26% изначальных требований оказались бесполезными.

Однако главный недостаток Waterfall — внесение изменений. Продукт тестируют в конце жизненного цикла, и может быть слишком поздно, чтобы что-то править. Именно стоимость внесения изменений побудила компанию Toyota задуматься о переходе на другую методологию разработки.

По словам Сатоси Исии (Satoshi Ishii), главного руководителя проектов компании, исправление дефектов, обнаруженных после производства, обходится в 1000–10000 раз дороже. Поэтому в Toyota решили отказаться от Waterfall и перейти к Lean, который мы рассмотрим далее.

Lean

Термин означает «бережливая разработка». Его корни уходят глубоко в историю компании Toyota и её подходов к решению задач. В компании вносят только те изменения, которые приносят пользу, требуют минимум затрат и отнимают не более 30% запланированного времени. Это помогло японской компании научиться переключать конвейеры на производство другой модели за считаные часы, в то время как другим автопроизводителям требовались недели.

Применили методологию Lean для разработки Мэри (Mary Poppendieck) и Том Поппендик (Tom Poppendieck). Они написали книгу «Lean Software Development». Дополнительную информацию также можно найти на их сайте, посвящённом Lean.

По данным исследования PMI, 8% компаний постоянно используют принципы Lean, а 26% часто к ним обращаются. Принципы Lean:

Устранение лишнего: того, что не приносит пользы.

Упор на обучение: цикличная разработка, обратная связь с клиентом.

Решения принимаются на основе фактов, а не прогнозов.

Целостность во всем: от информирования заказчика до рефакторинга.

Полномасштабное видение: важно оценивать проект как целое, а не по частям.

Среди плюсов методологии выделяют быстрый релиз продукта. Джо Фоли (Joe Foley), менеджер подразделения Intel Fab Operations в Лейкслипе, утверждает, что 5 лет назад компании требовалось 14 недель, чтобы начать производство новых чипов. Благодаря принципам Lean этот процесс теперь занимает 10 дней.

При этом, когда команда следует принципам бережливой разработки, она не просто выполняет задачи, а стремится сделать продукт с наименьшим количеством ошибок. В своём исследовании компания ВВС обнаружила, Lean повышает скорость разработки ПО на 37% и снижает количество багов на 24%.

Также, согласно исследованию Lean Business Report, в числе десяти преимуществ подхода указано снижение стоимости проектов — 27% IT-компаний уменьшили затраты за счет внедрения принципов Lean.

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

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

/ Flickr / Sebastian Sikora / CC

Feature Driven Development

Feature driven development (FDD) — методология, которая объединяет лучшие практики и сосредотачивает внимание разработчиков на функциональных элементах (features), полезных с точки зрения клиента. По этой ссылке можно найти примерную схему алгоритма разработки по FDD. Согласно исследованиям, 11% компаний постоянно используют Feature Driven Development, а 31% прибегает к использованию этой методологии время от времени.

Создатель FDD — Джефф де Лука (Jeff De Luca), впервые предложил методологию в 1997 году, когда искал оптимальное решение по разработке программного обеспечения для банка в Сингапуре. Тогда он предоставил комбинацию из 5 процессов:

Разработка общей модели. Команда разработчиков делится на группы создаёт модели для отдельных задач. Затем выбирается одна из предложенных моделей или их сочетание.

Создание списка функций.

Когда команда разработала общую модель, она определяет полезные для клиента функции.

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

Дизайн и разработка. На основе данных первого процесса, менеджер проекта выбирает группу функций, которые команда должна реализовать за определённый срок.

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

Успех проекта напрямую зависит от опыта и знаний ведущего программиста. В FDD он играет все главные роли: руководителя, наставника, аналитика и так далее. При этом методология создана для долгосрочных проектов, поэтому, как отмечают резиденты Stack Overflow, применять её для небольших задач просто нет смысла.

Однако есть и плюсы. Постоянное составление отчетов о проделанной работе на всех уровнях помогает отслеживать прогресс и результаты. Это позволяет регулярно обновлять проект, выявлять ошибки и предоставлять клиенту информацию в любое время. А один из резидентов Stack Overflow утверждает, что главный плюс FDD — возможность в любой момент оценить отстаёт ли проект от графика или продвигается быстрее.

Как уже было отмечено, FDD используется в масштабных проектах, поскольку на первом этапе ведётся разработка общей модели, позволяющей разобраться в продукте. Это же свойство помогает привлекать к работе новых разработчиков. При этом более глубокое понимание проектных требований и ожиданий клиента снижает риск нежелательных «сюрпризов».

P.S. О чем еще мы пишем в нашем корпоративном блоге:

Бережливая разработка программного обеспечения — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 3 апреля 2016;
проверки требуют 5 правок.
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 3 апреля 2016;
проверки требуют 5 правок.

Бережли́вая разрабо́тка програ́ммного обеспече́ния — методология разработки программного обеспечения, использующая методы концепции бережливого производства. Возникла из среды сторонников концепции гибкой методологии разработки.

Впервые освещена в одноимённой книге (англ. Lean Software Development) Мэри Поппендик и Toма Поппендика. В
книге представлены традиционные принципы бережливого производства применительно к разработке программного обеспечения, также набор из 22 инструментов (практик) и их сравнение с гибкой методологией разработки. Мэри и Том участвовали в ряде различных конференций, посвящённых методикам Agile, что объясняет известность концепции бережливого производства среди сообщества гибкой методологии разработки.

Исключение потерь. Потерями считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.

Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.
Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
Предельно быстрая доставка заказчику. Короткие итерации.
Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.
Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.
Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, делать быстро, ошибаться мало; учиться стремительно».

Некоторые практики бережливой разработки аналогичны практикам быстрой разработки, а некоторые несколько различаются. Примеры практик:

Мэри Поппендик, Toм Поппендик. Бережливое производство программного обеспечения: от идеи до прибыли / Вильямс, 2009 г. ISBN 978-5-8459-1538-2

Современные методологии управления производством / Habr

Введение

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

В XX веке доминировала методология управления производством получившая название «Фордизм», по имени своего основоположника Генри Форда. Фордизм — модель массового производства стандартизированных товаров на сборочных конвейерах с использованием низкоквалифицированных работников, занятых простыми операциями и объединенных на крупных фабриках. Такое производство обладает «эффектом масштаба» и отличается низкой себестоимостью единицы продукции, доступной массовому потребителю. Один из основных постулатов фордизма: «Производить большие партии изделий выгоднее, чем мелкие», прочно укоренился в головах управленцев XX века.

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

Рождение новых методологий

Со второй половины XX века (после второй мировой войны) предпринималось множество попыток модифицировать фордистскую модель. В частности на заводах «Тойота» в 50х годах стали ставить эксперименты, адаптируя американские концепции массового производства к реалиям послевоенной промышленности Японии. Тогда была переделана система крепления прессового инструмента, чтобы сделать его замену более быстрой. Потом были и другие новаторские решения и открытия, со временем сложившиеся в новую методологию — Lean Manufacturing (LM) – Бережливое производство.

В 80х и 90х появился целый зоопарк методологий и парадигм по управлению производством, среди которых подробнее остановлюсь на двух: Quick Response Manufacturing (QRM) – Быстрореагирующее производство и Agile Manufacturing (AM) – Активное производство. Современные, более гибкие по сравнению с фордизмом методологии, часто объединяют термином «постфордизм».

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

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

Ниже приведена таблица основных отличий фордисткой и постфордисткой концепций промышленного производства [1].

Признак	Фордизм	Постфордизм
Базисная ориентация	Продукт	Клиент
Снижение стоимости единицы продукции	За счет объёмов	За счет быстрой переналадки оборудования
Работник	Рабочая сила (Узкие, малоквалифицированные рабочие)	Носитель компетенций (вектор развития, многофункциональные специалисты)
Организационная форма	Отдельные рабочие места	Командная работа
Отношение к браку	Допустимый уровень	Абсолютное качество
Инновации осуществляются	Специалистами	Всем персоналом

Сейчас подробнее о каждой из рассматриваемых новых методологий

Бережливое производство (Lean Manufacturing, LM)

Цель LM – производить продукцию с постоянным уменьшением усилий людей, с меньшим объемом применения аппаратуры, как можно быстрее, на минимальном пространстве и при том делать то, что ожидает купить клиент. Эта концепция родилась в послевоенной Японии, тогда промышленность страны испытывала нехватку во всем: в ресурсах, материалах, аппаратуре, кадрах, и не могла рассчитывать на помощь государства. Япония мобилизовала свои силы и стала рационально использовать любые ресурсы, одновременно находясь в процессе поиска, выявления и ликвидации потерь любого масштаба.
Брак стал одной из самых больших потерь, а потому много сил было потрачено на то, чтобы его предотвращать. В «Тойоте» появилось правило — брак не допустим в принципе. Тайити Оно (1912—1990), один из создателей производственной системы компании Тойота, выделил 7 видов потерь:

потери из-за перепроизводства;;

потери времени из-за ожидания;

потери при ненужной транспортировке;

потери из-за лишних этапов обработки;

потери из-за лишних запасов;

потери из-за ненужных перемещений;

потери из-за выпуска дефектной продукции.

Позже к видам потерь были добавлены:

нереализованный творческий потенциал сотрудников.

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

В LM устранение потерь и оптимизация процессов производства осуществляются не от случая к случаю, а становятся постоянным делом. Усовершенствование осуществляют все работники, а не только высококвалифицированные специалисты. Непосредственно с LM связывают открытие, что уменьшение времени переналадки оборудования и увеличение гибкости производства позволяют быстро создавать небольшие партии товара и конкурировать с масштабным производством аналогичных товаров.

Впоследствии, в рамках концепции бережливого производства было выделено множество элементов, каждый из которых представляет собой определённый метод: Поток единичных изделий, Канбан, Всеобщий уход за оборудованием, Система 5S, быстрая переналадка (SMED), Кайдзен, Защита от дурака.

Некоторые методы сами претендуют на статус самостоятельной производственной методологии.

Сегодня концепция LM используется в тысячах компаний, занимающихся производством, и даже, в организациях, не связанных с промышленностью вообще. Вот довольно внушительный список компаний использующих LM в России (рис 1)

Надо сказать, что Lean Manufacturing связан со многими методологиями, появившимися в конце XX века, в частности с

«Шесть сигм» (Six Sigma), нацеленную на снижение вариабельности процессов и стабилизацию характеристик продукции.

Всеобщее управление качеством (англ. Total Quality Management, TQM) — общеорганизационный метод непрерывного повышения качества всех организационных процессов. TQM был популярен в конце 80-х и начале 90-х, однако позже уступил ISO 9000, Lean Manufacturing и Six Sigma.

Эти три методологии содержат множество похожих инструментов и методов, а также похожую философию.

Быстрореагирующее производство (Quick Response Manufacturing, QRM)

Происхождение бережливого производства связано с компанией Тойота, особенность которой – постоянные большие объёмы выпускаемой продукции. Однако за последние несколько лет произошёл быстрый рост количества функции, предлагаемых производителями своим заказчикам, это связанно в частности с:

Развитием CAD/CAM (системы автоматизированного проектирования и производства), позволяющим компаниям разрабатывать «под клиента», а потом производить продукцию без несения высоких дополнительных расходов.

Развитием Интернет, который позволяет покупателю/заказчику без труда оценивать огромное количество функций и делать свой выбор.

Данные тенденции развития дают основания полагать, что в XXI веке будет расти спрос на небольшую по объёму и крайне разнообразную продукцию с такими функциями, которые пожелают сами заказчики/покупатели. На этой почве и появилась методология QRM, которая была сформирована американским математиком Раджан Сури и подробно описана в его монографии вышедшей в свет в 1998 году.
Итак, быстрореагирующее производство (QRM) – используемая компаниями стратегия для сокращения времени выполнения заказа, которая охватывает всё предприятие. Цель QRM – сократить время выполнения заказа за счет всех операций компании, как внутренних, так и внешних.
Почему скорость выполнения заказа является основополагающим понятием QRM отлично иллюстрирует простой пример (рис 2). Данные на графике взяты из реальных показателей компании Midwest. Синим цветом показано реальное время выполнение заказа (когда кто-то делает работу), белым – общее время выполнение заказа.

Обычный заказ лежит 5 дней в отделе приема заказов, прежде чем его отправят на производство, потом уходит 12 дней находится на изготовление компонентов, 9 дней на сборку и 8 дней на то, чтобы уже выполненный заказ упаковали и отправили заказчику. В итоге на выполнение заказа уходит 34 дня (белый цвет). Если сложить участки серого цвета, то получим 19,5 часов, т.е меньше 3 дней при восьми часовом рабочем дне. Остальное время – это когда данной работой никто не занимается. По словам Сури, данное соотношение не является случайным, во многих производственных проектах реальное время работы составляет менее 5% от времени выполнения заказа.

Бережливое производство и другие похожие методологии, основанные на снижении затрат, направленны на сокращение реального времени работы, QRM ориентирован на снижение всего времени выполнения заказа.

Снижение всего времени выполнения заказа потенциально дает гораздо больший эффект, поскольку именно простои между реальными работами над заказом занимают большую часть времени. Снижение времени выполнения заказа, как правило, понижает стоимость продукта, повышает его качество и делает всю компанию более конкурентно способной [2].

Общий знаменатель QRM называется критическим путем производства (КПП, Manufacturing Critical-path Time) – календарное время, отсчет которого начинается, когда заказчик делает заказ, проходящий по критическому пути, и заканчивается тогда, когда первое изделие данного заказа поставлено заказчику. Ключевая идея КПП, сравнить количество «серого времени», уходящего на реальные операции, с общим показателем КПП.

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

На протяжении всей книги [2] Сури показывает громадные потери предприятия в следствии длинного КПП, а также описывает инструменты уменьшения КПП.

Основные концепции QRM:

Бизнес построенный при работе «для склада» (когда, чтобы быстрее выполнить заказы, основная номенклатура продуктов производиться заранее и кладется на склад), из-за ошибок планирования и изменчивости спроса приводит увеличению КПП, и в итоге к тому что компания не может быстро реагировать на потребности клиентов. Если сильно упростить – лучше инвестировать в станки и стандартно быструю реализацию заказов, чем в склады.

Переход от функциональных цехов к QRM-ячейкам. Ячейка – это набор независимых (отделенных от остальной компании), сочетаемых друг с другом многофункциональных ресурсов (людей и станков). QRM-ячейка направлена на выполнение всех видов работ вокруг определенного рыночного сегмента (например, конкретный тип продукции). В философии QRM-ячейки можно проследить некоторую аналогию с Scrum командой.

Иметь в запасе мощность до 20% для наиболее часто используемого оборудования. Это необходимо для предупреждения «пробок», уменьшает КПП и делает предприятие более готовым в изменчивости спроса.

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

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

К сожалению не нашёл нормальных примеров внедрения QRM в России, есть информация о применении на Челябинском компрессорном заводе и ещё нескольких предприятиях, но в целом данных по России очень мало. Думаю, что время QRM в России ещё придёт.
Все знают что время – деньги, но на самом деле время – гораздо большие деньги, чем полагают большинство менеджеров! (Чак Гейтс, президент компании).

Активное производство (Agile Manufacturing, AM)

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

Позднее мы выстроили новую компанию (после того как я отдал все долги!), а принципы которые легли в основу работы компании оказались очень близки в Agile Manufacturing (далее AM). AM находится в стадии формирования, пока это не методология, а набор принципов, литературы и информации в интернет мало, тем не менее, думаю что идеи AM будут интересны и полезны аудитории хабра.

Сегодня одной из главных проблем для промышленных компаний становиться проблема неопределенности и быстрых изменений в бизнес среде. AM – это стратегия управления компанией, цель которой сделать производственную компанию более устойчивой к кризисам, переменам спроса и другим непрогнозируемым изменениям. Президент корпорации Хонда, в интервью журналу Business Week, по этому поводу отметил, что: “Мы обязаны стать очень гибкими для того, чтобы быстро реагировать на непредсказуемое будущее. Век agility (активного производства) уже наступил”.

Для компаний, работающих по AM, свойственна способность быстро реконфигурировать трудовые и материальные ресурсы, чтобы не упускать возможности заработать и избегать неприятностей. Основным преимуществом концепции AM является умение оперативно подстраиваться под изменяющуюся ситуацию и работать в условиях неопределенности на рынке. AM подходит для отраслей, где высок уровень неопределенности (например ИТ, потребительская электроника).

Постоянная готовность к изменениям и ответ на них с помощью сценарных стратегий. СценарийСценарий — рациональный метод представления вероятных вариантов будущего, в которых могут реализоваться принятые организацией решения. Сценарий не является прогнозом, то есть описанием сравнительно предсказуемого развития событий настоящего. Не является он и видением — желаемым будущим. Сценарий — это тщательно продуманный ответ на вопрос: «Что случится предположительно?» или: «Что произойдет, если…?». Сценарий отличается и от прогноза, и от видения, которые имеют тенденцию скрывать риски. Сценарий же, напротив, дает возможность управлять рисками. Наличие сценариев действий, разработанных для наиболее вероятных ситуаций, в которых может оказаться компания, и отработанных механизмов их реализации, позволяют компаниям быстро и с минимальными затратами реагировать на изменения в деловой среде. Подробнее о сценарных стратегиях здесь.

Как можно больше интеллектуальных ресурсов и как можно меньше материальных.

Постоянная стержневая группа кроссфункциональных специалистов. Группа специалистов на проектах на договорной основе, а также вынос непрофильных работ на аутсорс. Штат не раздувается, а люди составляющие ядро компании горят делом.

Далее приведены принципы, на которые ориентируется AM, помогающие компании оставаться на плаву при изменчивости рынка:

Разветвлённая сеть партнерских организации (с дублирующими и дополняющими компетенциями) и поставщиков.

Организация работ: проектно—командная, иерархия минимальная.

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

Сравнение методологий и заключение

Три рассмотренные методологии отличаются в первую очередь стратегической ориентацией. LM нацелено на создание большего с помощью минимальных средств. Иными словами, LM постоянно выявляет потери любого плана и их ликвидирует. QRM нацелено на единственную цель – уменьшение времени цикла производства от получения заявки и до сдачи продукта заказчику. У AM главной целью является совершенствование возможностей для работы в условиях неопределенности и изменчивости рынка.

Выбор той или иной методологии зависит от объёмов производства, а также от отрасли в которой работает компания. Если производство серийное, то главная задача как правило — это минимизация расходов т.е.- LM. Компании, создающие небольшие партии продукта, должны уметь выполнять заказы быстро, поэтому интереснее ориентироваться на QRM. Те, кто работает с индивидуальными заказами — могут выбрать AM.

Если говорить об инновациях, то с ними гораздо проще AM компаниям, а LM труднее всего. Ведь главным плюсом AM производства является способность работать во всегда изменяющемся поле, разбираясь с индивидуальными проблемами. QRM занимает среднее положение.

Ниже приведена таблица основных отличий LM, QRM, AM [2].

Фактор	Бережливое производство (Lean Manufacturing, LM)	Быстрореагирующее производство (Quick Response Manufacturing, QRM)	Активное производство (Agile Manufacturing, AM)
Стратегический ориентир	Сокращение издержек	Скорость выполнения заказа	Эффективные действия в условиях высокой неопределенности
Тип производства	Крупно серийное и массовое	Средне и мелкосерийное	Мелкосерийное и индивидуализированное
Уровень кастомизации продукта и услуг	Низкий — средний	Средний — высокий	Высокий
Уровень задействования ресурсов	100%	80%	> 100% (использования множества сторонних ресурсов)
Инновационный потенциал	Низкий — средний	Средний — высокий	Высокий

Автоматизация заводов сейчас востребована, и мы регулярно бываем на разных типах заводов, обсуждая с заказчиками варианты сотрудничества. Если посмотреть на Российские производственные компании через призму вышеописанных методологий, я могу выделить 4 типа заводов:

Заводы, работающие по старинке. Станки старые, зарплаты мизерные, люди делают однотипную работу как роботы, потому что начальство не хочет или не может инвестировать в новое оборудование. Так сказать отголоски Фордизма, такие компании, как правило, имеют очень узкую номенклатуру простой продукции (например, контейнеры для яиц). Тем не менее, раз эти компании длительное время на рынке без помощи государства – они рентабельны.

Небольшие и средние современные производственные компании. Такие компании оснащены современным оборудованием, регулярно занимаются улучшением процессов, выпускают много однотипной продукции (например, бочки или хлеб). Среди таких заводов есть как филиалы западных, так и отечественные предприятия. Их методология часто LM или её части.

Маленькие инновационные производственные предприятия. Работают с штучными заказами или небольшими партиями, выпуская зачастую узкоспециализированные технологичные вещи (например, кабины для кранов). Сами того не зная эти компании близки в своих принципах к AM.

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

Кстати, меня сильно удивляет, что на тех заводах, на которых мне пришлось побывать, люди практически не используют или вообще не знают о существовании сервисов управления проектам и задачами. Вместо этого планируют в Excel, на бумажках и в электронных письмах. Когда показываешь обычные таск трекеры, часто люди начинают радоваться, а на небольших производственных компаниях начинают вести свои проекты с помощью сервисов (например, Битрикс24 или Zoho Projects).

Список литературы

Менеджмент в России и за рубежом №6′ 2013. Лузин А.Е., Бабанова Ю.В. Постфордизм – три ключевые производственные парадигмы нового столетия.

Данная статья послужила отправной точкой для моего анализа методологий производства.

Раджан Сури. Время — деньги. Конкурентное преимущество быстрореагирующего производства.

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

Эдвардс Деминг. Выход из кризиса. Новая парадигма управления людьми, системами и процессами.

Основополагающая книга по TQM

Вумек Джеймс П., Джонс Даниел Т. Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании, 2011.

Основополагающая книга по LM

Бережливая разработка программ | Открытые системы. СУБД

Термин бережливый (lean) изначально использовали для обозначения процесса управления производством, а затем в Массачусетском технологическом институте в середине 1980-х годов стали употреблять для процесса проектирования изделий. Джон Крафчик, ныне генеральный директор Hyundai Motor America, стал первым американским инженером, нанятым компанией Toyota для работы на ее калифорнийском сборочном заводе New United Motor Manufacturing, основанном как совместное предприятие с General Motors. В 1986 году Крафчик поступил в школу менеджмента MIT Sloan, где получил магистерскую степень. За год до этого была опубликовала книга «Японская автомобильная индустрия», в которой сообщалось, что Toyota, используя методы, развивавшиеся еще с конца 40-х годов, тратила на выпуск автомобилей примерно вдвое меньше человеко-часов, чем компании из «большой тройки» американского автопрома. При этом у Toyota были гораздо более быстрая оборачиваемость складских запасов и более высокое качество. Не отставала от Toyota и Nissan. Крафчик при содействии директора по исследованиям Международной автомобильной программы МТИ Джеймса Вомака начал исследование с целью сравнения автомобильных заводов во всем мире. В 1988 году в статьях Sloan Management Review были даны обобщения управленческой философии Toyota и представлены данные, демонстрирующие японское превосходство. В то же время Крафчик предложил термин «бережливый» в противовес «буферной» системе массового производства Ford.

Тощий, да не бедный

Lean Manufacturing — одна из наиболее востребованных идей в экономике и управлении производством, а для индустрии ПО Lean Software Management сулит выгоду от эффективной организации совместной работы всех участников цепочки создания ценностей

Сергей Колесников

Методы Toyota позволяли радикально уменьшить объем промежуточных и конечных запасов, предоставляя рабочим сборочной линии возможность управления большим количеством машин и вменяя им в обязанность слежение за качеством. Ключевым моментом было то, что в Toyota обратили вспять поток информационных сигналов (на то время в форме карточек «Канбан»), управляющих производственными операциями. В результате этой перемены фабрики Toyota получили возможность выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT) для конечной сборки и поставки дилерам. При этом устранялась большая часть промежуточных и конечных запасов, создаваемых «на всякий случай». Главный принцип заключался в том, чтобы непрерывно «тянуть» материалы и комплектующие через производственную систему по мере необходимости, а не «толкать» и складировать согласно строгим производственным планам. Термины «бережливый» и JIT позднее были популяризованы в международном бестселлере «The Machine That Changed the World», авторы которого термином lean обозначали любые практические методы эффективного управления, позволявшие минимизировать потери, в том числе при проектировании изделий. Излагались методы, благодаря которым японские производители достигали на треть более коротких сроков поставки и вдвое меньших затрат времени на проектирование по сравнению с американскими и европейскими. Более подробное исследование на эту тему было проведено в Гарвардской школе бизнеса Кимом Кларком и Такахиро Фудзимото, опубликовавшими работу «Product Development Performance».

Некоторые общие черты между японским менеджментом и разработкой ПО для персональных компьютеров начали становиться очевидными уже в середине 1990-х — например, в книге «Microsoft Secrets» Кузумано и Ричард Селби упомянули применявшийся в Microsoft принцип ежедневных сборок, когда инженеры должны были каждый день приостанавливать работу для исправления ошибок (в книге это было названо «процессом синхронизации и стабилизации»). Авторы отметили сходство с философией JIT у Toyota, когда рабочие должны были останавливать сборочные линии при обнаружении проблем для их немедленного устранения. В книге еще не использовался термин lean для разработки ПО — в то время речь шла в основном о распространенных практиках JIT-инженерии и контроле качества, а также о меньшей бюрократизации и численности персонала в Microsoft по сравнению с другими корпорациями, такими как IBM. Чтобы глубже погрузиться в автомобильную индустрию, Кузумано с аспирантом Кентаро Нобеокой провел еще одно исследование, изложенное в книге «Thinking beyond Lean». Вдохновением для нее послужила работа Джеймса Вомака и Дэниела Джонса «Lean Thinking» 1996 года, в которой делалась попытка обобщить lean-методы и их применения. В книге речь шла о более новых подходах к проектированию изделий, упор делался на систематическое повторное использование продуктовых платформ и основных комплектующих, а также на другие методы, например, короткие, перекрывающиеся стадии (параллельное проектирование), позволяющие ускорить инженерный этап. Однако о разработке ПО упоминалось лишь вкратце.

Популяризация термина lean и появление ассоциации со скорой (agile) разработкой программных продуктов произошли благодаря более поздним исследованиям, в частности книге «Lean Software Development» Мэри и Тома Поппендик (2003 год). Как и предыдущие исследователи, авторы сделали акцент на устранении потерь и уменьшении бюрократии при разработке, обучении за счет коротких циклов и частых сборок, отсрочке принятия решений и быстрых итерациях, а также на принципе «вытягивания», когда модификации продукта обуславливались отзывами, в отличие от «выталкивания», когда разработка идет согласно техническому заданию и жестко заданным планам.

Все авторы, использующие термин lean для разработки ПО, подчеркивают различия между старыми, более трудоемкими и забюрократизированными «выталкивающими» процессами, которые раньше ассоциировались с мэйнфреймами, и новыми гибкими итеративными или инкрементальными методами. Очевидно, что есть немало общего между бережливым производством в стиле Toyota и скорой разработкой в стиле Microsoft (до того как команды разработчиков Windows стали чрезмерно большими в конце 1990-х – начале 2000-х), даже если рассматривать отдельные практики. В книге Кузумано от 2010 года перечислены эти сходные элементы, иллюстрирующие принцип «тяните, а не только толкайте» (см. табл. 1).

*Сравнение процессов Toyota и Microsoft*
Бережливое производство Toyota (ручное «вытягивание» в зависимости от спроса с использованием карточек «Канбан»)	Скорая разработка Microsoft 1990-х (ежедневные сборки с совершенствованием функциональности)
JIT-выпуск небольших партий	Разработка малых функций
Минимум промежуточных запасов	Короткие циклы и интервалы между вехами
Географическая концентрация — производство	Географическая концентрация — разработка
Равномерное производство	Планирование по функциям и вехам
Быстрая наладка	Автоматизированные средства сборки и быстрые тесты
Оптимизация оборудования и линий	Ориентация на малые, мультифункциональные команды
Стандартизация работы	Стандарты проектирования, кодирования и тестирования
Простые в использовании средства автоматизации	Сборки и непрерывное интеграционное тестирование
Рабочие-«многостаночники»	Несколько обязанностей у каждого участника
Избирательная автоматизация	Автоматизированные средства, но без генераторов кода
Непрерывное улучшение	Анализ по методу «посмертного вскрытия», развитие процессов

Раннее использование термина lean, без сомнения, исходило из популярности японских методов менеджмента, но упор всегда делался на избавление от потерь времени и лишних кадровых ресурсов; на ценность изделия с точки зрения заказчика, продукта и предприятия; а также на преимущества более гибкого, итеративного, малозатратного процесса разработки. Аналогичные акценты заметны и в методах XP и Scrum, называемых итеративными, инкрементальными или скорыми и реализующих ряд методов разработки ПО.

Бережливая разработка ПО

Scrum: гибкое управление разработкой

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

Михаил Борисов

Уместны ли вообще принципы бережливого производства для разработки ПО или программной инженерии? Нередки комментарии вроде «Разработка не имеет ничего общего с производством». Если понимать lean как набор практик управления производством, то при переносе на разработку они кажутся малоприменимыми, однако если рассматривать концепцию lean как набор принципов, а не практических методов, то в применении к проектированию и программной инженерии они выглядят более разумными, способными улучшить процессы и качество.

На самом деле идея применения бережливых принципов к разработке ПО существует почти столько же, сколько и сам термин lean. В 1990-х Роберт Шаретт пользовался термином «бережливая разработка» для обозначения стратегии управления рисками, динамически обеспечивающей стабильность организации за счет повышения ее устойчивости, толерантности к изменениям и быстроты перестройки. В 2002 году Шаретт опубликовал статью Challenging the Fundamental Notions of Software Development, за десять лет не утратившую своей актуальности. В ней он дает краткое изложение основных тезисов данного руководства: «Как уже давно было отмечено, единственное назначение бизнеса — создавать заказчика и обслуживать его. Поэтому суть бережливой разработки не в процессе разработки как таковой, а в том, как с помощью ИТ приносить пользу заказчикам. Таким образом, бережливая разработка — это не методология программной инженерии в обычном понимании, это система практических методов, принципов и философии построения программных систем для использования заказчиком».

Авторы книги «Lean Software Development» также выделили семь принципов бережливой разработки:

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

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

Оптимизация целого

Бережливая разработка должна основываться на глубоком понимании задачи, стоящей перед заказчиком, и того, как ее можно решить с помощью ПО. Выяснить, чего заказчики хотят и что оценят, непросто, особенно если учесть, что сам по себе программный продукт редко является ценностью — ценность ПО проявляется в контексте более крупных систем: автомобиля, онлайн-магазина, автоматизированного процесса выполнения заказов и т. п. Более того, ценность ПО формируется не только на стадии разработки — важны также проектирование и развертывание. Наконец, ценность ПО редко создается разовым ограниченным по времени усилием — главным фактором общей ценности обычно является возможность менять кодовую базу со временем.

Устранение потерь

В терминах бережливой разработки потери — это все, что не приносит прямой пользы заказчику и не добавляет знаний о том, как более эффективно приносить эту пользу. Среди основных видов потерь при разработке ПО: ненужные функции, потеря знаний, недовыполненная работа, передача ответственности и многозадачность, а также затраты времени на поиск и устранение дефектов, отнимающие до 40–50% времени разработки. Корни многих видов потерь лежат в большом объеме работы, недоделанной при последовательной организации работ, а также в границах между разными функциями и задержках и потерях знаний, когда эти границы приходится пересекать. Если следить за всем потоком создания ценности (value stream), то причины потерь выявляются и устраняются проще, как и в случае с «вытягивающей» системой JIT-производства.

Забота о качестве

Процесс синхронизации и стабилизации в Microsoft выглядел как резкий отход от преобладающего в то время принципа, согласно которому интеграция малых программных модулей в единую систему проводилась только в конце цикла разработки. Но на самом деле непрерывная интеграция малых модулей в более крупные системы уже давно считалась оптимальным методом, хотя и не очень широко применялась. Еще в 1970 году Харлан Миллс из IBM предложил подход, который он назвал «программированием сверху вниз», — процесс, когда модули интегрируются в общую систему по мере написания, а не в конце разработки. В своей книге 1988 года Software Productivity он заметил: «Главный критерий, по которому я сужу, использовалось ли программирование сверху вниз, — это отсутствие трудностей интеграции».

Постоянное обучение

В конечном счете разработка ПО — это получение знаний и использование их для реализации программного продукта. Бережливая разработка рекомендует два подхода к приобретению знаний, применяемых в зависимости от контекста.

Первый — это рассмотрение многих вариантов затратных решений: изменение фундаментальной архитектуры, выбор языка и идеологии пользовательского интерфейса и т. д. Предлагается откладывать критически важные решения до последнего момента, а затем действовать с учетом накопленных знаний. Когда рассматриваются многие варианты, всегда найдется подходящая альтернатива и можно выбрать вариант, лучше всего оптимизирующий систему в целом. Часто этот подход называют принципом приоритета обучения (learn first).

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

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

Быстрая доставка

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

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

Быстрая доставка продукта не должна ограничиваться только разработкой ПО: весь цикл разработки продукта должен происходить потоком, а ПО — это только один из аспектов такого цикла. Например, поток разработки встроенного ПО обычно перенимает характеристики потока создания основного продукта.

Вовлечение всех участников

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

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

Непрерывное совершенствование

В статье «Decoding the DNA of the Toyota Production System», опубликованной в 1999 году, Стивен Спиэр и Кент Бауэн указывают, что в Toyota все рабочие системы постоянно совершенствуются по научно обоснованному методу, под руководством наставника и на самом низком возможном уровне. Согласно lean-философии, конкретные практические методы, как бы они с виду хорошо ни действовали в других ситуациях, редко являются оптимальным решением каждой конкретной актуальной проблемы. Поэтому в соответствии с принципами lean можно рекомендовать организациям, начинающим с методологий вроде XP и/или Scrum, рассматривать их как начальную платформу, которая со временем будет адаптироваться и совершенствоваться командами, выполняющими работу для заказчиков.

Скорая разработка ПО

Чтобы поместить бережливую разработку в контекст, полезно указать на общие черты с agile-разработкой и отличия от нее. Распространенный сегодня термин agile в 1990-х годах использовался для обозначения гибких систем производства. В феврале 2001 года его применили к разработке ПО, когда группа единомышленников подготовила «Манифест скорой разработки ПО», в котором провозглашается, что при разработке ПО необходимо ставить людей и их взаимодействие выше процессов и инструментов; работоспособное ПО — выше полной документации; взаимодействие с заказчиком — выше переговоров по контракту; реакцию на изменения — выше следования плану. Эти предписания противопоставлялись распространенным в то время практикам разработки ПО, и они определенно согласуются с lean-принципами. Однако последние предоставляют более полное руководство по выбору практических методов разработки, подходящих для конкретных ситуаций, причем речь не только о разработке ПО.

Экстремальное программирование

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

Кент Бек

Первый ставший популярным agile-процесс — это экстремальное программирование (XP), основы которого подробно изложены в книге «Extreme Programming Explained» Кента Бека (2000 год). Основу XP образуют технические практики, самая примечательная из которых — разработка через тестирование (test-driven development). Его реализация требует частого использования системы тестирования модулей, благодаря чему дефекты распознаются практически сразу после их появления в кодовой базе. Этот подход доказал свою эффективность как первый шаг к избавлению кода от ошибок. Со временем методы усовершенствовались — время исполнения системы тестирования свели к минимуму, а масштабы тестов ограничили так, чтобы они не выходили за разумные пределы.

Со временем концепция разработки через тестирование расширилась — в нее включили автоматизированное формирование спецификаций, подготовив почву для автоматического регрессионного тестирования. Реализация соответствующих систем сильно зависит от предметной области, поэтому появились новые инструментарии и методики, помогающие в решении этой задачи: Framework for Integrated Testing (Fit) и FitNesse, разработка через приемочное тестирование (acceptance-test driven development), разработка, основанная на функционировании (behavior-driven development), спецификация на основе примеров (specification by example). Сегодня наиболее распространенным инструментом, используемым для выполнения lean-принципа заботы о качестве, являются каркасы систем автоматизированного тестирования.

Scrum

Следующим agile-процессом, получившим распространение, стал Scrum, описанный в книге 2001 года «Agile Software Development with SCRUM» Кена Швабера и Майка Бидла. На протяжении следующих лет Scrum стал популярен как метод, заменяющий традиционное управление проектами на итерации разработки длиной один месяц (а позднее — две недели), поэтому Scrum — отличный способ ввести в разработку ПО lean-концепцию поточного процесса. Ввиду широкой популярности Scrum его часто приравнивают к agile-разработке, однако этот метод не претендует на звание полноценной методологии — нет технических практик, как в XP, и в целом Scrum ограничивается лишь этапом разработки ПО в потоке создания ценности. Тем не менее ранние agile-процессы доказали, что инкрементальный выпуск ПО можно применять во многих предметных областях и что за счет строгого выполнения принципов разработки через тестирование можно значительно улучшить качество программ.

Роли

Scrum и XP — это наборы практик, нацеленные на оптимизацию процесса разработки ПО как отдельного вида деятельности в потоке создания ценности. В обоих есть место ролям. На исполнителе лежит ответственность за принятие решений по спецификациям продукта — это роли «заказчика» в XP и «владельца продукта» в Scrum. От участников команды обычно не требуются меры по обеспечению общего успеха работы; ответственность за это возлагается на заказчика или владельца. На практике опора на эти роли часто приводит к нарушению lean-принципа оптимизации целого.

Lean-методика рассматривает разработку ПО как один из этапов единого потока создания ценности продукта, а разработчиков — как участников более крупной команды создания продукта. При этом все участники такой команды несут ответственность за успех. В бережливой разработке нет ролей владельца продукта или заказчика. Команды бережливой разработки могут возглавляться, например, главным инженером (в Toyota), менеджером по программам (в Microsoft) или куратором по продуктам (в 3M) — роль такого руководителя напоминает роль предпринимателя, возглавляющего начинающую компанию. Даже если кажется, что есть сходство с ролью заказчика или владельца продукта, то на практике есть большие различия. Главный инженер несет общую ответственность за готовый продукт, в том числе за его рыночный успех, и вовлекает всех участников мультидисциплинарной команды в подготовку этого успеха. Нет промежуточного руководителя, который бы отдельно приоритизировал деятельность команды разработки ПО.

«Канбан»

В книге «Scrumban: Essays on Kanban Systems for Lean Software Development» Кори Ладас (2009 год) описал, как пользоваться системой «Канбан» для отслеживания прогресса разработки ПО и ограничения объема выполняемой работы. В 2010 году вышла книга Дэвида Андерсона «Kanban», в которой объясняется, как применять «Канбан» для организации эффективной поточной системы разработки ПО.

В «Канбан» поток создания ценности отображается на диаграмме (предпочтительно реальной, висящей на стене), состоящей из столбцов, каждый из которых соответствует своему этапу потока. Карточки «Канбан» (маркеры фрагментов работы) размещаются в столбце, отражающем текущую стадию. Когда фрагмент работы соответствует заданным признакам завершенности, маркер перемещается в следующий столбец, и со временем карточка проходит слева направо по всей доске — наглядно можно видеть поток работы в системе. Главная особенность «Канбан» в том, что объем работы в любом столбце (представляющем стадию потока создания ценности) ограничен. Это означает, что и система в целом содержит лишь ограниченный объем работы.

Системы «Канбан» дают организациям хорошую базу для перехода к lean-принципам, поскольку правил и ролей здесь немного, а сами системы требуют вдумчивого изучения и адаптации. Например, для начала доской «Канбан» можно пользоваться только в среде разработки ПО, но впоследствии можно будет легко добавить новые стадии потока создания ценности, например маркетинг и производственную деятельность. Поэтому «Канбан» — хороший инструмент для команд, участвующих в потоке создания ценности. В системах «Канбан» потоку ценности уделяется особое внимание — поток и узкие места процесса разработки являются главными темами ежедневных собраний. Кроме того, структура и правила доски «Канбан» должны регулярно пересматриваться и совершенствоваться. Отличное ситуационное исследование по применению системы «Канбан» при работе по крупному контракту с правительством приведено в книге Хенрика Книберга «Lean from the Trenches», вышедшей в 2011 году.

Тенденции

На протяжении последнего десятилетия появлялись все более сложные инструменты, сделавшие разработку ПО более защищенной от ошибок и позволившие безопасно непрерывным потоком вносить небольшие новшества в рабочие версии. Эти инструменты вначале были предложены для Web-платформ доставки ПО в виде сервиса.

Непрерывный выпуск

Еще в 2004 году одна крупная Web-компания в конце каждого дня выпускала рабочие версии всего ПО, над которым шла работа в течение дня. Топ-менеджер этой компании недавно отметил, что, по его мнению, быстрота — это основа всех lean-принципов: «Если вы выпускаете продукт ежедневно, потери становятся видны практически сразу; у вас нет выбора кроме как заботиться о качестве; вы быстро выясняете, что ценят заказчики; все участники на всех уровнях ориентируются на выполнение требований заказчика; поскольку проблемы обнаруживаются быстро, непрерывное совершенствование является неизбежным; и наконец, когда происходят ежедневные внедрения, частичная оптимизация просто недопустима».

В 2011 году Джез Хамбл и Дэвид Фарли в книге «Continuous Delivery» изложили технические практики, необходимые, чтобы непрерывным потоком выпускать готовое к внедрению ПО безопасно и без дефектов. Эта книга, написанная для корпоративных департаментов ИТ, перечисляет инструменты, технологии и организационные меры, необходимые, чтобы достичь lean-идеала безопасного ввода ПО в рабочую эксплуатацию немедленно после написания. В ИТ-департаментах, последовавших принципам этой книги, выяснили, что для достижения цели еженедельных, ежедневных или даже непрерывных выпусков достаточно примерно года усердной работы.

Бережливый стартап

Agile-методы обычно предполагают, что действия команды разработки ПО направляет заказчик или посредник, однако скорые методики практически не предоставляют механизмов, следящих, чтобы требования посредника эффективно решали задачу заказчика. Кроме того, agile-методы обычно не привлекают команду разработки к обеспечению рыночного успеха продукта. В 2011 году Эрик Рис рассмотрел эти проблемы в книге «Lean Startup», приведя доводы в пользу того, чтобы компании начинали с бизнес-плана, а затем проверяли влияние функций на выполнение прогнозов, на которых план был построен. При таком подходе команда разработки ПО оказывается вовлеченной в создание контуров обратной связи, таких как совместное тестирование (split test, предложение одновременно нескольких версий продукта заказчику), которые помогают определить полезность новых особенностей. Таким образом, разработчики ПО участвуют в процессе оценки пользы новых функций для заказчиков и на основании их отзывов вносят поправки. Получение откликов о каждой функции позволяет эффективно оценивать действенность различных подходов в компаниях, ориентирующихся на большую аудиторию заказчиков.

Дизайнерское мышление

Советы мэтра

Профессор школы бизнеса Массачусетского технологического института Майкл Кузумано хорошо известен в мировой программной индустрии как эксперт по бизнес-проблемам разработки ПО.

Наталья Дубова

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

***

Методы скорой разработки в целом подразумевают, что проектирование системной архитектуры и пользовательского интерфейса происходит вне команды разработки либо выполняется ею, но в очень малых объемах. Ввиду этого agile-практики часто оказываются недостаточными для решения проблемы проектирования самого решения, взаимодействия с пользователем и высокоуровневой системной архитектуры. Поэтому agile-практики все шире рассматриваются как хороший способ организовать разработку, но недостаточно хороший для организации проектирования. Поскольку проектирование по своей сути итеративно, то если оно не будет выполняться в тесной интеграции с разработкой, пострадают обе дисциплины. Учитывая, что принципы бережливой разработки требуют многопрофильного подхода, ориентированного на продукт в целом и его полный жизненный цикл, lean-метод — более удачный кандидат для компоновки проектирования, разработки, развертывания и аттестации в единый контур обратной связи, ориентированный на выяснение потребностей заказчика и их выполнение.

Мэри Поппендик ([email protected]) — президент компании Poppendieck, Майкл Кузумано ([email protected]) — заслуженный профессор Массачусетского технологического института.

Lean Software Development,бережливая разработка,качество ПО,надежность,agile-методики

Поделитесь материалом с коллегами и друзьями