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