Agile Hardware. Как сократить время релиза хардверного продукта до недели
Публичный постДля тех кто со мной хоть чуть-чуть знаком не секрет, что я фанат системной инженерии, системного мышления и, вообще, счастливый прихожанин Школы Системного Менеджмента.
Так же для многих не является секретом тот факт, что край науки системной инженерии проходит по вашей айтишечке. Поэтому даже разработчики «железных» систем посматривают на гибкие методы разработки и используют их у себя.
Совершенно точно это не является секретом для Илона Маска, с его то бэкграундом в Zip2, X.com и PayPal. Поэтому в его нынешних компаниях активно работают комитеты по внедрению Agile, Scrum, etc., которые так и называются Agile @ Tesla, например.
Именно от ключевого сотрудника комитета Agile @ Tesla вы и увидите доклад по ссылке.
Меня поразил тот факт, что длительность спринта в Тесле длится 3 часа! Не полгода, не месяц, не неделя. 3 часа. Но и результаты потрясающие, это до 27 изменений в продакшене за неделю у Теслы. Автомобиля из алюминия, стекла и резины. Это удивительно.
Явным образом нигде не встречал (Но и не искал, буду рад если кто поделиться ссылкой), но не удивлюсь если существует и комитет Agile @ SpaceX. Это бы многое объясняло в скорости выкатки очередных SN для RUD («Rapid Unscheduled Disassembly»). (И однозначно объясняет потогонку, которая в SpaceX царит)
Анатолий Игоревич Левенчук — руководитель «Школы системного менеджмента» и директор по исследованиям Русского отделения INCOSE (Международного совета по системной инженерии) очень любит приводить примеры Теслы и СпейсИкс в материалах Школы, поэтому я обратился к нему за комментарием, как же удаётся совмещать Agile и старые кондовые водопады аэрокосмической (да и автомобильной) промышленности?
Мне показалось полезным поделиться с вами его ответом:
Общий ответ на этот вопрос в создании двух потоков работ:
1. «Как надо в жизни», оформляется стандартами предприятия. Продукты получают статус "рабочих продуктов".
2. «Как надо регулятору» — самые низкооплачиваемые сотрудники просто формулируют результаты конечных работ «как надо в жизни» в соответствии с тем, «как надо регулятору». Никакой разработки, готовые результаты сдаются как итоговые в архив (но в жизни не используются, в жизни используются свежие информационные модели).
Это дороже, чем один поток работ, но не вдвое (ибо «как надо регулятору - это просто оформление, а не разработка»). Такое даже за рубежом используют (я уточнял в INCOSE), когда надо не просто оформить, но чтобы ещё «и летало, и не падало».
Это SoTA инженерии по госконтрактам.
Это на 100% подтверждается моим опытом работы в аэрокосмической промышленности. 100 лет в обед все конструкции делают в Solid'е и обмениваются с подрядчиками 3д-сборками, но как результат заказчику сдаются КД оформленные по ЕСКД.
Надеюсь кому-то будет полезно, и я не против от дискуссии и прохладных историй о применении гибких методов разработки в «железных» проектах у вас.
PS
А хотел просто ссылочкой поделиться. 😏
Посмотрел я доклад, но это же реально жопа и горячка какая-то!
И в придачу это все работает на том, что хомячки Маска закрывают глаза на отстойное качество, согласны быть бета-тестерами сырого продукта и покупаются на рекламу от Мессии.
Но суть то в том, что все эти законы и требования безопасности, на которые эти ребята кладут с высоты трехчасового спринта, написаны кровью погибших в катастрофах и авариях. С эти то что делать?
Плюс китайцы вот вроде объявили крестовый ход против Теслы. А уж они точно очень хорошо умеют работать в стиле 9-9-6 и класть на меры безопасности и авторское право. Срочно запасаемся попкорном.
Сам доклад интересный и может принести полезные мысли. Хотя так вкалывать, как они вкалывают, я пас, пожалуй. За 3 часа ты даже расчет нормально не проведешь, куда там деталь разработать!
В SpaceX пошли дальше и некоторые сотрудники работают 9-9-7:
«Salaried employees end up working a ridiculous amount of hours in many cases. I have worked for weeks on end between 70 and 85 hours, though I would say on average employees mostly work between 50 and 60 hours, which is quite typical for a tech company.» © Glassdoor.com
Готов?
Еще не смотрел, но первая же мысль: "А там всеобъемлюще и в каждом уголочке спринт идёт три часа - или как с определением << Автопилот>>" ? 😋
https://cliffberg.medium.com/spacexs-use-of-agile-methods-c63042178a33
Никогда не слышал про Rapid Unscheduled Disassembly, так что в голос!
Весьма интересно.
Как я понял, всего этого сверх-быстрого деливери они добиваются за счёт строго оговоренных интерфейсов между разными узлами. Над каждым узлом работает маленькая и гибкая команда, а деливерят они тем быстрее, чем мельче разбиение всей машины на узлы.
Вот что не могу у себя в мозгах уместить. Как им удается поддерживать стабильность (неизменность) интерфейсов при таком мелком разбиении на узлы/команды, если сами узлы меняются раз в три часа, а стабильность интерфейсов - главный залог того, что всё это успешно сынтегрируется в одну работоспособную машину?
@VBodrov вот тебе комментарий примерно четырехлетней давности от инженера в power electronic в американском отделе Тесла.
Немцы тоже уже давно и много где так делают. :)))
Да, это как автоваз — поддерживай отечественное, т.е. NI ;-) Мы сейчас пытаемся сообразить что-то похожее на Xilinx Zynq, эквивалентное типичной NI платформе, вроде как руководство поддерживает.
Не могу сказать про все ECU и все компоненты. Но достаточно часто используется Robot Framework для Python, особенно для HIL. Иногда HIL полностью автоматизированный — т.е. ты пушишь свою ветку в Git, и он автоматически ставит ее в очередь на HIL. Если SIL — то пытаемся оформить как юнит-тесты, которые периодически крутятся на Jenkins. Если в SIL используется модель из Simulink — то она компилируется как shared library. MIL — как я сказал Simulink.
@VBodrov а вот тебе вопрос на засыпку: как и кем в "серийных" спутниках прокладываются кабели связи, питания и пр. в теле самого прибора? ;)