→
Agile Hardware. Как сократить время релиза хардверного продукта до недели
Публичный пост
27 мая 2021
715
😥 Этот пост был удален самим автором и от него остались лишь комментарии участников. Если вы хотите приютить и развить эту тему как новый автор, напишите модераторам Клуба: moderator@vas3k.club.
Посмотрел я доклад, но это же реально жопа и горячка какая-то!
И в придачу это все работает на том, что хомячки Маска закрывают глаза на отстойное качество, согласны быть бета-тестерами сырого продукта и покупаются на рекламу от Мессии.
Но суть то в том, что все эти законы и требования безопасности, на которые эти ребята кладут с высоты трехчасового спринта, написаны кровью погибших в катастрофах и авариях. С эти то что делать?
Плюс китайцы вот вроде объявили крестовый ход против Теслы. А уж они точно очень хорошо умеют работать в стиле 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 а вот тебе вопрос на засыпку: как и кем в "серийных" спутниках прокладываются кабели связи, питания и пр. в теле самого прибора? ;)