Agile
Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
KPI
LeSS
OKR
OKR-инструменты
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Тренинг
Фасилитация
Финансы
Холакратия
Применить

Руководство по Скрам в Производстве

Данное руководство содержит описание модели Скрама в Производстве и технические практики для достижения выпуска продукции за короткие итерации.

Руководство по Скрам в Производстве

Руководство по Скрам в производстве было разработано Joe Justice. Джо является президентом Scrum Inc., а также основателем и генеральным директором команды WIKISPEED. Джо имеет опыт сотрудничества с такими компаниями как Bosch, Microsoft, Toyota, Amazon, 3M, Ford, Boston Scientific, QuintilesIMS, Chevrolet, MIT, HP Labs, Xerox PARC и еще сотней других компаний, и доставки до клиентов продуктов и услуг за недельные спринты и меньше. Также Джо проводит тренинги по Scrum in Hardware.

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

Цель Руководства по Скрам в Производстве

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

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

Неопределенность в производственной сфере

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

Заглушки и макеты

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

Модульность

Полноценный продукт должен быть готов к использованию в течение одной недели. Это позволяет еженедельно получать обратную связь от любых заинтересованных и должностных лиц, проверять соблюдение нормативных требований, что позволяет исключить необходимость разделения производства продукта на этапы и снизить риски. В тех случаях, когда технология производства не позволяет создавать продукт за неделю, мы можем разделить его на модули, которые позволят изолировать крупные, сложные или строго регулируемые части продукта. Разделение продукта на модули называется «нарезкой» и является ключевым моментом. У каждой команды должна быть возможность проверять предположения об их части продукта, независимо от других команд. Например проверка аэродинамики автомобиля проходит лучше и быстрее, когда только одна команда владеет и работает над экстерьером. Модули также можно использовать для разделения продукта на части по циклам испытаний и сертификации, чтобы модули с короткими циклами можно было перепроверять и утверждать быстрее.

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

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

Дизайн интерфейсов

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

Тестирование и разработка на основе данных

Разработка должна быть спроектирована таким образом, чтобы мы могли проверять наши гипотезы относительно продукта (TDD — Test Driven Development). Варианты тестирования продукта могут быть написаны до производства. С помощью Интернета вещей (IoT — Internet of Things) и сенсорных технологии (Sensor technology) можно измерять данные почти о любом поведении компонентов продукта, и на основе полученных данных мы постоянно улучшаем продукт.

Команда

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

Рабочий продукт в конце каждого спринта

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

Об авторах

Joe Justice — президент Scrum Inc., а также основатель и генеральный директор команды WIKISPEED. Джо имеет опыт сотрудничества с такими компаниями как Bosch, Microsoft, Toyota, Amazon, 3M, Ford, Boston Scientific, QuintilesIMS, Chevrolet, MIT, HP Labs, Xerox PARC и еще сотней других компаний, и доставки до клиентов продуктов и услуг за недельные спринты и меньше.

Команда WIKISPEED является международным производителем автомобилей работая в 23 странах и циклом внедрения новой модели в течение 1 недели.

Fabian Schwartz — основатель ScrumColombia.org, СEO CASMENA и консультант SBS.

William Newing — основатель консалтинговой фирмы Pink Cherry Blossom и Владельцем продукта (Product Owner) фабрики WIKISPEED в Линнвуд, Вашингтон, США.

Chris Wallace — профессиональный Скрам Коуч (Scrum Coach), консультант и Владелец Продукта (Product Owner) фабрики WIKISPEED в Бёрлсон, Техас, США.

Mary Michael Justice — Скрам Мастер (Scrum Master) в корпорации WIKISPEED, запустила первую Скрам команду в компании, устраняет препятствия на пути к счастью или скорости, если на языке высшего менеджмента.

Данный материал защищен авторским правом 2017 Джо Джастис. Документ доступен для использования в любом месте без изменений.

P.S.: Благодарю Joe Justice за возможность переводить материалы с сайта Scrum Inc. и за поддержку в создании сообщества Scrum in Hardware Russia.

P.S.: Thanks to Joe Justice for the opportunity to translate content from Scrum Inc. and for support in creating community the Scrum in Hardware Russia.

27 янв 2019, Дмитрий Кустов
Другие статьи
22 ноя 2020, Василий Савунов
Scrum: что это и зачем нужно

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

14 ноя 2020, Алексей Евдокимов
Обзор Agile. Что это: методология, метод или философия?

В русскоязычных книгах и статьях Agile (Аджайл) часто называют гибкой методологией разработки. Если считать методологией семейство разных методов и методик разработки программного обеспечения, то это почти правда: Agile действительно создан как обобщение разных подходов к разработке ПО. Однако …

Agile манифест
20 сен 2020, Василий Савунов
Как появился Agile. Часть 3. Призыв

Это завершающая часть статьи про причины появления Agile.