Принципы Экстремального Производства

Какой % сделанного функционала в программном обеспечении реально используется? А какой % функционала делается, но так и не доезжает до клиента? Даже если он составляет 10-20% ненужных функций — это колоссальные потери времени и денег, хотя в некоторых случаях этот показатель составляет до 64%. Если предположить, что продукты реального производства имеют такие же показатели полезности для клиентов, то меня лично беспокоят масштабы неразумного использования ресурсов планеты. Эти мысли наводят на то, что если в ИТ-сфере люди нашли способ, как быстрее создавать более ценные продукты и услуги, то это возможно сделать и для реального производства. Это один из ключевых моментов, которые объединили меня с командой ScrumTrek. И действительно, в мире есть такие примеры. Лично меня вдохновила история Joe Justice и команды WIKISPEED. Мы связались с Joe и рассказали ему о наших планах и желании внести вклад в распространении Экстремального Производства. Joe с радостью нас поддержал и теперь наша команда воплощает в жизнь данное направление в нашей стране.

Мы решили начать с перевода теоретической базы, которую создала команда WIKISPEED. Далее мы начнем переводить кейсы применения Экстремального Производства и сейчас мы ищем производственную компанию, чтобы сделать кейс в России.

В нашем блоге вы можете ознакомиться с переводом Руководства по Скрам в Производстве.

А в данной статье мы познакомим вас с принципами Экстремального Производства.

Самой сложной задачей для многих Scrum-команд является создание потенциально готового к поставке приращения продукта (PSPI, Potentially Shippable Product Increment) в конце каждого спринта. На обзоре спринта команде необходимо получить обратную связь по продукту и извлечь из нее как можно больше информации. А что если продукт технически и технологически очень сложен? Как в реальном производстве создавать PSPI всего за одну или две недели?

Scrum-команды разрабатывающие программное обеспечение используют различные инженерные практики, такие как: eXtreme Programming (экстремальное программирование), TDD (разработка через тестирование), Pair Programming (парное программирование) и Continuous Integration (непрерывная интеграция) — но применение данных практик ограничено только разработкой программного обеспечения. Что делать, если нам приходится иметь дело с технически сложными материальными продуктами?

Экстремальное производство (Extreme Manufacturing) -  это набор принципов, описанных Joe Justice, во время создания проекта WIKISPEED. Эти принципы были опубликованы Peter Stevens. Далее представлен перевод его статей «Объяснение экстремального производства», опубликованных в июне 2013 года.

В 2008 году Joe Justice принял участие в конкурсе X-Prize, где участникам нужно было создать автомобиль с расходом 2,8 литра на 100 км (100 miles per gallon). Несмотря на то, что у Joe было мало времени, практически никакого бюджета, требования к победителю конкурса постоянно менялись, конкуренция со стороны более сотни хорошо финансируемых команд из автомобильных компаний и университетов по всему миру, команда WIKISPEED заняла 10-е место в классе Mainstream. Joe не только создал великолепный автомобиль, но и разработал Agile-подход к созданию физических продуктов.

Будучи разработчиком программного обеспечения, Joe был хорошо знаком с Agile-принципами. У него имелся опыт работы с такими Agile-подходами, как Scrum и Extreme Programming, поэтому его инженерный подход к созданию автомобиля в значительной степени опирался на его опыт создания программного обеспечения. Сегодня подход WIKISPEED к производству известен во всем мире и применяется в таких компаниях, как Boeing и John Deere.

Joe назвал свой подход «Extreme Manufacturing» (Экстремальным Производством — сокр. XM). XM акцентируется на быстром создании продуктов и быстрой интеграции изменений в существующие продукты. XM - это набор принципов и паттернов, которые помогут вам быстро создавать и адаптировать ваши продукты.

Принципы XM:

1. Оптимизируйте изменения.
2. Модульная архитектура.
3. Разработка через тестирование.
4. Взаимосвязи раньше элементов.
5. Итеративная разработка элементов.
6. Agile-паттерны материального производства.
7. Непрерывная интеграция.
8. Непрерывная поставка.
9. Паттерны масштабирования.
10. Шаблоны для партнеров.

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

1. Оптимизируйте изменения

Что происходит, когда инженер создает более безопасную дверь для автомобиля? Можем ли мы сразу начать ее производство? Нет. Автомобильные двери производятся серийным оборудованием с использованием пресс-форм, которые изготавливают двери одного типа без возможности внесения изменений. Стоимость штамповочного оборудование и пресс-форм может достигать более 10 миллионов долларов, и сначала компания должна амортизировать вложения, прежде чем производство новый двери будет экономически обоснованно. Учитывая высокую стоимость оборудования, на это может уйти десятки лет, прежде чем более безопасная дверь сможет поступить в производство. Мы все наблюдаем, как влияет необходимость амортизации огромных инвестиций на автомобильную промышленность. Небольшие изменения происходят раз в 2-3 года, а серьезные раз в 5-10 лет.

Компания WIKISPEED может изменять дизайн автомобиля каждые семь дней. Они используют такие инструменты, как карта создания потока ценности (Value Stream Mapping), что позволяет уменьшить разнообразие вариаций продукта, оптимизировать загрузку производственной линии на основе потока ценности, а, самое главное, это позволяет снизить стоимость изменений в продукте. Для команды WIKISPEED использование нового дизайна обходится не дороже, чем использование существующего. Поэтому, если у них появилась более безопасная дверь, то они начнут использовать ее на следующей неделе.

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

2. Модульная архитектура

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

Такая «сильная связанность» между частями продукта широко распространена в автомобильном производстве. Изменение в подвеске потребуют изменения шасси, что в повлечет за собой изменения чего-то другого, что в конечном итоге повлияет на конструкцию всего автомобиля.

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

На конкурсе X-Prize многие участники выбыли из соревнования до финальной гонки. Почему? Потому что изначально организаторы планировали провести гонку на улицах города, чтобы определить победителя. Условия были изменены в ходе конкурса, и победителя решили определять на ралли от побережья к побережью, а в итоге остановились на гонке по сложной гоночной трассе. Изменения сценария гонки серьезно влияли на требования к подвеске автомобиля. Эти изменения создали серьезные сложности для команд, которые не могли быстро подхватить изменения.

Автомобиль WIKISPEED был сконструирован из 8 модулей с простыми интерфейсами между модулями. Благодаря модульной архитектуре команда WIKISPEED могла изменять модуль подвески с минимальными усилиями. Команда WIKISPEED также обнаружила, что может применять связанные шаблоны, такие как наследование и повторное использование кода, как преимущество.

Принятие изменений является ключевой Agile-ценностью. Способность быстро адаптироваться позволила команде WIKISPEED стать лучше сотни участников, которые выбыли еще до гонки.

Как достичь модульной архитектуры? Вам помогут следующие два принципа: разработка через тестирование (3) и взаимосвязи раньше элементов (4).

3. Разработка через тестирование

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

Благодаря полученной модели Джо смог рассчитать характеристики, которые должен иметь автомобиль WIKISPEED, чтобы расход топлива был 2,8 литра на 100 км. А в дальнейшем модель помогла команде WIKISPEED получить характеристики, достойные автомобилей спортивного класса.

Команда WIKISPEED хотела получить пять звезд в краш-тестах по спецификациям NHTSA (National Highway Traffic Safety Administration — Национальная дорожная ассоциация безопасности дорожного движения) и IIHS (Insurance Institute for Highway Safety — Страховой институт дорожной безопасности). Краш-тесты выявляют уровень повреждений, которые могут получить его участники, на основе ударопрочности автомобилей.

Фронтальный краш-тест (NHTSA)
5 звезд (означает 10% или меньшую вероятность получения серьезной травмы)
Фронтальный краш-тест (IIHS)
5 звезд (имеется в виду 5% или меньшая вероятность получения серьезной травмы)

Краш-тесты стоят довольно дорого, около 10 000 долларов за тест, плюс стоимость самого автомобиля, его транспортировки и утилизации после проведения тестов. Как команда WIKISPEED может обновлять конструкцию автомобиля каждую неделю, когда каждое изменение требует проведение краш-теста? В первую очередь команда использовала конечно-элементный анализ (FEA) во время симуляции краш-тестов. Когда они поверили, что их автомобиль пройдет реальное испытание, они провели краш-тест.

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

Когда разрабатываете новые компоненты:

1. Сначала создайте тест, который предполагается пройти. Это могут быть очень сложные тесты, типа испытания на выброс СО2 или краш-тесты. Или это могут быть простые тесты для одного компонента. Если возможно автоматизировать тест (или создать для его частичную цифровую модель), то сделайте это как можно быстрее — это снизит стоимость проведения тестов для будущих изменений в продукте.
2. Создайте самую простую конструкцию, которая сможет пройти тест.
3. Итеративно улучшайте конструкцию до тех пор, пока изменения конкретного компонента приносят наибольшую ценность для всего продукта.

В разработке программного обеспечения этот процесс известен как «Red-Green-Refactor». Чтобы реализовать что-то, сначала создайте тест, который по определению будет провален (красный). Затем реализуйте функционал, чтобы он прошел тест (зеленый). Затем улучшайте функционал для лучшей ремонтопригодности, эффективности и т.д. (рефакторинг).

4. Взаимосвязи раньше элементов

Первое решение о конструкции автомобиля WIKISPEED состояло в том, что он должен состоять из восьми модулей: кузов, шасси, двигатель, подвеска, салон и т.д. До того, как команда WIKISPEED приступила к разработке отдельных компонентов, они разработали способы взаимодействия (интерфейсы) между этими модулями.

Джо не знал, какая подвеска будет использоваться в автомобиле, но он смог определить внешние параметры и границы характеристик подвески. Получив эти данные, он решил, что если подвеска сможет выдержать восемь ходов, этого будет более чем достаточно, чтобы соответствовать всем требованиям, даже для участия в гонках Формулы-1. После команда разработала алюминиевый блок, который сможет выдержать такую нагрузку. Любая подвеска, которая может быть установлена на этот блок, может использоваться на автомобиле WIKISPEED без изменения остальной части автомобиля.

Таким образом, при разработке решений:

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

P.S. Обязательно ознакомьтесь с шаблоном Декоратор, чтобы обеспечить независимость между продуктом и компонентами от поставщиков.

5. Итеративная разработка элементов

Команды, которые создают материальные продукты, часто задают вопрос, касательно Scrum: «Как мы можем создавать реальный продукт в каждом спринте? Разработка продукта требует больше времени и не сможет вписаться в двухнедельный спринт!» В разработке материальных продуктов немного другой взгляд на итерационный процесс разработки.

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

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

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

1. Создайте тест, который ваш элемент должен пройти.
2. Создайте простейшую конструкцию, позволяющую пройти тест.
3. Улучшите дизайн, чтобы он был проще и элегантнее.
4. Повторяйте этот процесс до тех пор, пока улучшение элемента не перестанут приносить наибольшую ценностью для всего продукта.

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

Используя Agile-принципы при разработке программного обеспечения каждая итерация должна создавать потенциально готовую к поставке функциональность. Это может быть невозможно при разработке материальных продуктов, поэтому вам может потребоваться выполнить итерацию определенного элемента много раз, прежде чем он станет удовлетворительным. В случае с командой WIKISPEED последующие итерации включали следующие тесты: «Аварийный тормоз удерживает автомобиль на месте» и «Аварийный тормоз не влияет на движение автомобиля, после использования».

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

6. Agile-паттерны материального производства

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

1. Декоратор (Wrapper) — используйте шаблон декоратор, чтобы приспособить сторонние элементы к вашим интерфейсам. Если вы используете интерфейс поставщика в качестве базового, то любое изменение у поставщика или в продукте, скорее всего, приведет к изменению способа взаимодействия элементов (интерфейса), что является дорогостоящим мероприятием.
2. Фасад (Facade) — это точка входа, кото­рая предо­став­ля­ет про­стой интер­фейс к слож­ной системе. Например, когда несколько проводов (питание, данные) подходят в одно и тоже место.
3. Одиночка (Singleton) — каждый элемент нуждается в питании, данных и заземлении. Первое, что каждый инженер хочет создать при проектировании нового элемента — это шина питания, данных и заземления. Паттерн одиночка говорит, что для всех базовых элементов используется одни и те же шины.

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

Было ли использование шаблона целесообразным? Да, потому что этот паттерн позволил команде: а) снизить вес автомобиля на несколько сотен фунтов благодаря постоянной оптимизации; б) реагировать на изменяющиеся требования к подвеске легко и экономно. Если бы они не смогли этого сделать, они не смогли бы участвовать в финальном отборочном туре.

7. Непрерывная интеграция

Члены команды WIKISPEED находятся более чем 20-ти странах и работают в разное время суток и разные дни. Как они научились создавать совместный и ценный продукт? Ответ состоит из двух частей: первая часть посвящена инженерным практикам, а вторая — о том, как их масштабировать.

На инженерном уровне Экстремальное производство использует практику непрерывной интеграции разработки (Continuous Integration Development, CID) и регулярного прохождения всех необходимых тестов (см. Принцип 3 — Разработка через тестирование).

Непрерывная поставка (см. Принцип 8) обеспечивает тесное сотрудничество между этапами создания продукта и его производством. Таким образом, команда смогла выпускать новую версию продукта не более чем за 7 дней.

Непрерывная интеграция разработки (CID) требует, чтобы тесты были максимально автоматизированы. Как только член команд создает обновленный элемент, автоматически запускается обширный набор тестов.

Каждый раз, когда кто-то из команды загружает новый 3D-чертеж в DropBox, Box.net, Windows SkyDrive или любой другой сервис для обмена файлами, команда WIKISPEED запускает тесты. Команда может моделировать краш-тесты и стресс-тесты элементов, используя FEA (анализ методом конечных элементов) и программное обеспечение, как LS Dyna или AMPStech. Команда WIKISPEED может моделировать воздушные потоки для проверки аэродинамики, потоки жидкостей, теплообменные и электротехнические процессы, используя CFD (Computational Fluid Dynamics).

Такие тесты можно запускать автоматически каждый раз, когда появляется новый файл CAD (Computer-Aided Design), а после теста команда WIKISPEED получает одностраничный отчет об успешных (зеленых) и проваленных (красных) тестах. Зеленый означает, что тест пройдет с таким же результатом, как и в прошлой версии или лучше, либо что данный тест явно проходит конкретная деталь или модуль.

Таким образом, участники команды со всего света могут одновременно вносить вклад в совершенно разные элементы для улучшения каждого модуля и автомобиля в целом.

Данный принцип позволяет легко определить, насколько хороша та или иная идея по улучшению продукта. Запись всех пройденных тестов позволяет найти лучшие сочетание ранее проверенных идей.

Тесты команды WIKISPEED включают такие характеристики как простота элементов и их стоимость, а также эргономика для клиента, ремонтопригодность, технологичность и соответствие интерфейсу модуля.

8. Непрерывная поставка

Экстремальное Производство требует переходить от идеи к готовому к работе продукту или услуги за 7 дней или меньше. Как можно это осуществить в такой сжатый срок?

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

Как сжать годы выполнения заказа до недельного цикла поставки?

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

Достижение функционирующей гибкости производства означает использование аддитивных технологий или оборудования для быстрого прототипирования. Это может выражаться в том, что некоторое оборудование или U-ячейки размещаются на запираемых роликах, чтобы их можно было перемещать в производственном потоке или убирать из него в зависимости от цели спринта. Часто это означает, что команда ежедневно перенастраивает оборудование после ежедневного Scrum. И это всегда означает, что оборудование для тестирование подключено к сигнальной системе на всех этапах производства.

R&D (Research and Development — Исследования и Разработка) является началом производственной линии. Если команда разработчиков нового продукта находится в пределах слышимости от линии массового производства, происходит двунаправленная связь. Если команда R&D использует производственные линии каждый спринт, то обе команды могут работать вместе, чтобы перенастраивать линию для тестирования и производства новых продуктов. По мере роста межфункциональных навыков различия между командой исследования и разработки и производственной командой исчезает. И таким простым способом у нас появляется кросс-функциональная продуктовая команда разработчиков. У каждого человека есть специализация, например, сварочные сертификаты, но, благодаря работе в парах, они работают над каждым аспектом потока создания продукта от идеи до доставки клиенту.

Как вы собираетесь получить продукт товарного вида, если у вас есть только 7 дней? См. Пятый принцип Экстремального Производства: итеративная разработка элементов. Цель состоит в том, чтобы создать первую версию в течение недели. Затем итерационно улучшайте элементы, чтобы привести их к товарному виду. Используйте промежуточные результаты, чтобы получить обратную связь от клиентов, пользователей и других заинтересованных лиц. Ранние версии продукта будут выглядеть большими и неуклюжими, потому что не все элементы продукта будут готовы к использованию, но когда вы итерационно улучшаете продукт и получаете отзывы о нем, ваш фокус всегда остается на ценности продукта.

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

9. Паттерны масштабирования

Экстремальное производство масштабируется так же как Scrum, добавляя команды. Координация команд может осуществляться через Владельцев Продукта, Scrum-мастера или Членов Команды в зависимости от масштаба затрагиваемых вопросов.

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

Создание команд

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

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

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

Координация команд

В Экстремальном производстве используется Scrum-of-Scrums. Команды состоят из 5 человек, включая Владельца Продукта и Scrum-мастера. Каждый Владелец Продукта несет ответственность за вытягивание элементов из Бэклога Портфеля (или просто «Бэклога»), а также за получение командой ясности о том, что нужно создать, почему это ценно клиента и о влиянии элемента бэклога на показатель чистой текущей стоимости (Net Present Value, NPV).

Эта ясность исходит от Главного Владельца Продукта (Chief Product Owner, CPO), который постоянно упорядочивает и уточняет Бэклог портфеля. CPO — это не старшая роль по оплатам или опыту, а просто человек достаточно доступный для того, чтобы поддерживать готовность команды к работе, отвечать на вопросы команды и иметь наиболее четкое представление о видимой для клиента ценности, которую намеревается создать Бэклог Портфеля. В идеале, CPO — это клиент, который платит за продукт или услуги, которые мы намереваемся произвести.

В каждой команде есть Scrum-мастер, который отвечает за увеличение скорости работы команды, то есть за объем работы, выполняемой в течение каждого спринта. Устойчивое развитие подразумевает, что люди в команде счастливы и вся выполненная работа соответствует метрике качества, называемой «Критерии готовности». У Scrum-мастеров есть и дополнительная работа: они сотрудничают со Scrum-мастерами других команд, чтобы согласовать общие ресурсы, такие как: пространство, оборудование, инструменты и модули продукта — между командами.

Таким образом, команда из 5 человек имеет четкие ожидания относительно того, как устранить наиболее распространенные типы препятствий. Отсутствие ясности устраняется как можно скорее Владельцем Продукта. Отсутствие объема работ устраняется Владельцем Продукта. Отсутствие видимости у команды, понимание тренда своей производительности/качества создаваемого продукта/уровня счастья устраняются Scrum-мастером. И препятствия связанные с ограниченными ресурсами и их координацией между командами также устраняет Scrum-мастер.

10. Шаблоны для партнеров

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

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

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

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

Данные список неокончательная версия принципов Agile-производства, а скорее отправная точка, помогающая открывать лучшие способы производства.

Материал взят из книги “Scrum for Hardware”с разрешения автора Paolo Sammicheli.