Как мы успешно внедрили Scrum в производственную компанию

Меня зовут Кириченко Иван, я СЕО/СТО проекта «Роботикс», ведущего разработки в области боевой робототехники. За 6 лет компания многое прошла, создала, приобрела опыта. Хочу поделиться мнением об успешной имплементации фреймворка Scrum в производственные процессы.

Scrum в IT давно стал привычным и понятным. Насколько успешен и удачен он может быть в производственных и R&D процессах и компаниях? Почему современные подходы в управлении командами разработчиков так медленно входят в отличные от IT-сектора экономики?

Немного теории

Scrum — это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью (из руководства по скраму, К. Швабер, Д. Сазерленд, 2017 г.).

Структурная схема фреймворка Scrum

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

Условный пример Scrum-доски

И тут отдельные знатоки могут сходу отрекомендовать Kanban вместо фреймворка Scrum для производственных и R&D-целей. Однако не будем торопиться и сделаем выводы позже.

Scrum в R&D

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

Предложенный новичками стэндфордский проект ROS (Robot Operating System) изначально приняли за основу, и команда приступила к его внедрению практически в режиме «свободного плавания».

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

Мобильная платформа комплекса БРП

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

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

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

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

  1. Сначала распределили роли (Product Owner, разработчики, Scrum Master) в классическом понимании, с той лишь разницей, что Product Owner был ориентирован на внутреннего заказчика, что, безусловно, способствовало упрощению коммуникаций.
  2. Создали бэклог продукта, именно как упорядоченный список конкретных требований к нему.
  3. Составили бэклог спринта/ов как набор элементов бэклога, взятых в спринт, плюс план по достижению цели спринта и поставке инкремента продукта.
  4. Закипела структурированная работа с недельным спринтом с постоянным отслеживанием прогресса продукта и инкремента спринта.

На глазах по кирпичику в течение 3–4 месяцев создали:

  1. Основное ядро ориентации мобильной платформы в пространстве, на физическом уровне включающее GPS-приемник, 9-осевой MЭMS-сенсор (гироскоп, акселерометр, магнитометр).
  2. Систему автономного движения исключительно на основе сигналов GPS, а также с учетом данных магнитометра, гироскопа и акселерометра.
  3. Систему автоматического возврата в базовую точку в случае потери связи или по команде оператора.
  4. Приоритизацию сигналов управления от четырех центров:
    • переносного пульта управления;
    • основного автоматизированного рабочего места оператора системы;
    • системы автономного движения на уровне базового контроллера движения;
    • системы распознавания образов на основе нейронных сетей.

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

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

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

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

Система автономного движения успешно испытывается с 2019 года и сейчас лишь усиливается отдельными функциями и возможностями.

Никто из основных конкурентов (эстонская Milrem Robotics, немецкий Rheinmetall Defence) со штатами в десятки разработчиков и фантастическими бюджетами в 2019 году не имел собственной системы автономного движения по пересеченной местности даже на уровне MVP.

Только сейчас компания из Эстонии начинает демонстрировать систему Follow me (абсолютно вредную и бестолковую в военном деле), а также автоматический возврат по ранее пройденному пути.

При этом, кроме собственных инвестиций учредителей, эстонская Milrem Robotics, считающая себя лидером отрасли в ЕС, каждый год осваивает изрядное количество грантовых средств со стороны Еврокомиссии. Это позволяет эстонцам содержать общий штат в полторы сотни сотрудников и с тремя десятками разработчиков программного продукта.

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

Естественно, на пути создания полноценной системы автономного движения rough terrain, работы в рое, автономной системы распознавания Military-классов для боевого наземного дрона предстоит еще горы свернуть.

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

Scrum в разработке конструкторской документации

Другим интересным направлением имплементации Scrum стала разработка рабочей конструкторской документации (РКД). Разработка РКД регламентируется десятками ГОСТов, в том числе закрытых, и обычно вызывает головную боль для руководителя компании и линейных управленцев.

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

Одним из наиболее удачных электронных решений систематизации и визуализации Scrum является Jira Software от Atlassian (бесплатен до 10 пользователей). Альтернативные варианты — Codegaint (бесплатен), ClickUp (бесплатен без «Премиум»):

Пример реальной электронной доски Scrum в процессе разработки РКД нашим конструкторским бюро

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

Разработка РКД — циклический/итеративный процесс с проверками, выводами, доработками. Внедрение Scrum и Jira (или аналогов) позволяет отлично систематизировать, ускорить, визуализировать этот «запутанный» процесс. Наша команда очень рекомендует использовать эти технологии.

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




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

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

👍НравитсяПонравилось5
В избранноеВ избранном1
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Подписаться на комментарии