Руководство по Скрам в Производстве
Данное руководство содержит описание модели Скрама в Производстве и технические практики для достижения выпуска продукции за короткие итерации.
Руководство по Скрам в Производстве
Руководство по Скрам в производстве было разработано 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 Джо Джастис. Документ доступен для использования в любом месте без изменений.
Какие этапы развития и карьеры обычно проходят скрам-мастера вплоть до Agile-коуча? На какую зарплату можно рассчитывать начинающим и опытным? Какие тренинги или курсы скрам-мастеров подходят на разных этапах карьеры?
Статья для тех, кто хочет понять свои перспективы в этой необычной профессии и решить, какие навыки и как уже стоит прокачивать, а на что пока не стоит тратить время.
Как стать Scrum-мастером? Как понять, нужно ли вам это? Какие сертификации могут помочь на старте карьеры Scrum-мастера? Как реальные люди получали работу в этой роли, придя из должности инженера, продажника, проектного менеджера и т.д.? Какие компании вам подойдут?
Статья скорее для тех, кто пока лишь думает о работе скрам-мастера и хочет построить для себя осмысленный план трудоустройства, а не спонтанно проходить курсы и рассылать резюме.
Идеи Scrum — это мощный инструмент для управления проектами и разработки продуктов. Кто-то считает, что применять Скрам нужно в формате «бери и делай», другие уверены, что реальный мир гораздо сложнее постулатов фреймворка и важно соответствовать бизнес-контексту. Так что же, Скрам — это монолит или инструмент, который поддается индивидуальным настройкам?
В статье обсудим, когда дополнения к Scrum не просто допустимы, а необходимы современным командам, а когда изменениям лучше сказать твердое «нет».