Погуглить? Чтобы как в анекдоте - "Надо брать Теслу, но дизель атмосферник на механике", да?
Кроме шуток, сейчас не нулевые. Особенно если речь идет об абсолютно новой модели. Все, что получится найти, это сгенерированные AI очередные дифирамбы тому, что новый авто экологичнее, экономнее, надежнее и долговечнее всех ацтойных старых авто.
150 километров? Да, ходит. Крупный судебный процесс против группы, в которую входит Ситроен, уже завершился. Стелантис будет ремонтировать бесплатно и выплачивать компенсации. На подходе такой же против Форда.
Просто не покупайте машины с ними.
Как потребителя, меня вообще не должно интересовать, какой там ремень. Я вообще не обязан знать, что он там есть. Ведь "Современный ДВС очень надежен. Прямо невероятно надежен. И при этом недорог в обслуживании.", не так ли?
Так вот. ДВС принципиально ненадежен, так как он гаратированно выйдет из строя. Вопрос только в "когда". Он работает исключительно благодаря очень точно подогнанным парам трения. Которые, как известно, подвержены износу. По наступлению критичексого износа такой двигатель подлежит полной разборке, дефектовке и ремонту.
Чудеса науки и инженерии 20 века привели к тому, что появились материалы, станки и электроника, которая позволяет очень сильно отодвинуть этот момент критического износа до такой степени, что большинству автовладельцев понятие "капитальный ремонт двигателя" уже не знакомо.
А потом пришли продукты 21 века, в обиходе называемые "маркетологами", и все это испортили. И теперь в ходу не слово "капиталка", а выражение "контрактный движок"
Теперь, для его зарядки нужно эти самые 30 кВт*ч в день
Вот тут все эти расчеты и рассыпаслись.
30 кВт*ч в день требуется только в том случае, если каждый день эти 30 кВт*ч полностью выезжаются. Консервативно это 200 километров. В день. Без праздников и выходных.
У подавляющего большинства дневной пробег в среднем сильно меньше.
Видимо не понятно выразился - я не могу Вам даже сходу сказать ни одной задачи, которая была бы в разработке чего-то нового
Ну так даже в передовой науке так - все новые открытия основываются на предыдущих научных работах, открытиях и явлениях. Тем не менее, что-то не слышно о попытках поставить научные открытия на конвеер.
Продолжая метафору - у нас есть куча строительных блоков, из которых мы собираем нужное изделие
У вас есть проект условной многоэтажки для условий слабонесущего грунта в Питере. Есть склад с материалами и/или подрядчики, готовые их поставить в нужное время в нужном количестве.
Вам поступил заказ на постройку такой же многоэтажки. Но на скальном грунте в Карелии. Вы снарядите сваезабивную машину и полетите забивать сваи? Нет, вы будете менять проект, поскольку фундамент здания придется разрабатывать с нуля. После чего придется перерабатывать всю инженерку здания, поскольку технический подвал из-за изменений в конструкции фундамента будет отсутствовать.
И вот тут получается такая несуразица. Вроде и стеновые блоки те же. И остальные материалы. И финальный внешний вид продукта такой же. И даже потребительские качества один-в-один. А проектную документацию пришлось почти полностью перерабатывать с нуля. Как так получилось?
Удалось за счет того, что в компании организована хорошая коммуникация с заказчиком, который готов был слышать о сдвигах сроков и давать корректировки
Погодите, вы же только-только начали внедрение новой серебряной пули и уже нужно сдвигать сроки?
коллектив стабильно сохраняется уже очень долгое время, текучки у нас нет.
Вы же сами сказали, что внедрение началось только летом. Сейчас все только отошли от отпусков и начала учебного года. Просто нужно немного подождать.
Производственная линия вполне может поддерживать вариативность, это не делает процесс уникальным от изделия к изделию.
Вы определитесь, вы делаете что-то новое или просто повторяете что-то, что уже было сделано много раз. Если последнее, то зачем весь этот фестиваль, ведь можно просто взять уже имеющийся, отлаженный и проверенный временем продукт? В мире софта для этого даже конвеер строить не надо.
Любая методология может быть доведена до абсурда. Даже самая лучшая. Вы, к сожалению, были, возможно, свидетелем именно такого.
Я был неоднократным свидетелем и даже участником оглушительно успешного внердения скрам. Видел откровенно неудачные внедрения, впрочем, у этих неудач почти всегда оказывалось конкретное имя и фамилия. Успешные Waterfall тоже видел. С DF (кстати, почивший в начале 2000-х RUP есть этот самый DF, только вид сбоку) личная статистика другая - видел только провалы разной степени оглушительности.
Кстати, исходя из Вашей статьи (и картинки, которая должны была быть смешной), с внедрением agile у вас что-то конкретно не заладилось.
Вот как раз сократить количество неизвестных факторов по-хорошему DF и должен сократить.
И как он может это сократить, если эти факторы проявляются только в процессе разработки?
Кстати, есть еще одна вещь, которую тут пока еще не обсуждали: скорее всего, самые лучшие ваши разработчики (те самые, которые вытягивали предыдущие проекты, спасая горящие дедлайны) находятся уже в процессе выбора нового оффера.
Из изначально ложного предположения вытекает все, что угодно:
написание ПО больше напоминает сборку изделия на конвейере,
Нет, нет, и еще раз нет. Конвеер - это производственная линия, разделенная на участки, на каждом из которых специально обученные сотрудники при помощи узко специализированного инструмента выполняют крайне ограниченное число операций (в идеале - одну). При этом эти сотрудники не заменены на роботов либо по финансовым (робот дороже) соображениям, либо по совокупности причин (изделия отличаются - утром сверлим собираем седаны, после обеда - универсалы), когда проще поставить человека, чем изобретать адаптируемого робота.
Конвеер заточен в первую очередь на повторяемость.
Разработка ПО на это вообще не похожа. Разработка ПО - это именно проектно-изыскная работа. Когда инженеры проектируют изделие, которое нужно собрать, а то и придумывают конвеер для его сборки.
Попытки превратить разработку ПО в конвеер не прекращаются уже много лет. Без особого успеха.
Но это неважно. Важно другое:
То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
У вас проблемы лежат вовсе не в плоскости методологии разработки. А в коммуникации внутри компании. И, как показывает практика, в таких случаях нужно не на манифест кивать, а перечитывать Крылова.
Про "отсутствие документации" в скрам выше уже написали. И да, я лично был свидтелем "внедрения" "аджайл", где все внедрение свелось к тому, что "документацию писать не надо".
Разработчик берется за задачу, изучает её и пишет документацию прямо в файлах проекта, оставляет комментарии по месту планируемых изменений. Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка. Именно описанный сценарий — отправная точка для проверки всего остального. Он позволяет ревьюеру проверить логическую цепочку.
Если есть замечания по решению, ревьюер возвращает доброску на доработку документации с комментариями. Разработчик дорабатывает документацию. Проверка повторяется.
Сначала между первым и вторым пунктом проходит 15 минут.
Через неделю - полтора дня.
Еще через неделю ревьювер вообще перестает отвечать.
Эту статью я в пишу в сентябре 2025 года. Мы начали внедрять методологию два месяца назад.
Я был свидетелем внедрения доведенного до идеала подхода "Documentation first". Через два года "разработки" было очень много качественной, хорошо структурированной, рецензированной и подписанной документации. И было дано решение на самом верхнем уровне "а вот теперь пишем код". Через месяц написания кода весь этот сверкающий небоскреб из продуманной документации оказался карточным домиком и просто развалился.
Потому что разработка ПО, в отличие от многих других отраслей, отличается тем, что вы всегда имеете дело с неизвестным количеством неизвестных факторов. Которое невозможно предусмотреть заранее и которые выясняются только в процессе собственно разработки (и раннего тестирования). И нет, вы не сможете заранее "предусмотреть" и "выяснить" все незивестные путем "Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка."
У Vijeo Citect нет встроенной возможности удаленного управления. Его ядро до сих пор родом из начала 90-х, когда интернета как такового не существовало.
Вот в то, что конкретное оборудование могли попробовать окирпичить, ещё можно поверить. Но установка Citect подразумевает отдельную сеть, физически изолированную от интернета
По сути, это duff device на стероидах и имеет определенные (серьезные) ограничения. Но при правильном использовании позволяет очень эффективно реализовывать конечные автоматы, а оверхед при их использовании минимален - весь механизм запоминания состояния использует один int.
Погуглить? Чтобы как в анекдоте - "Надо брать Теслу, но дизель атмосферник на механике", да?
Кроме шуток, сейчас не нулевые. Особенно если речь идет об абсолютно новой модели. Все, что получится найти, это сгенерированные AI очередные дифирамбы тому, что новый авто экологичнее, экономнее, надежнее и долговечнее всех ацтойных старых авто.
150 километров? Да, ходит. Крупный судебный процесс против группы, в которую входит Ситроен, уже завершился. Стелантис будет ремонтировать бесплатно и выплачивать компенсации. На подходе такой же против Форда.
Как потребителя, меня вообще не должно интересовать, какой там ремень. Я вообще не обязан знать, что он там есть. Ведь "Современный ДВС очень надежен. Прямо невероятно надежен. И при этом недорог в обслуживании.", не так ли?
Так вот. ДВС принципиально ненадежен, так как он гаратированно выйдет из строя. Вопрос только в "когда". Он работает исключительно благодаря очень точно подогнанным парам трения. Которые, как известно, подвержены износу. По наступлению критичексого износа такой двигатель подлежит полной разборке, дефектовке и ремонту.
Чудеса науки и инженерии 20 века привели к тому, что появились материалы, станки и электроника, которая позволяет очень сильно отодвинуть этот момент критического износа до такой степени, что большинству автовладельцев понятие "капитальный ремонт двигателя" уже не знакомо.
А потом пришли продукты 21 века, в обиходе называемые "маркетологами", и все это испортили. И теперь в ходу не слово "капиталка", а выражение "контрактный движок"
Вот тут все эти расчеты и рассыпаслись.
30 кВт*ч в день требуется только в том случае, если каждый день эти 30 кВт*ч полностью выезжаются. Консервативно это 200 километров. В день. Без праздников и выходных.
У подавляющего большинства дневной пробег в среднем сильно меньше.
Форд со своим "мокрым ремнем":
Ауди, где для замены свечей нужно двигатель снимать:
ФВ с жором масла в литр с завода:
Подержите наше пиво!
Ну так даже в передовой науке так - все новые открытия основываются на предыдущих научных работах, открытиях и явлениях. Тем не менее, что-то не слышно о попытках поставить научные открытия на конвеер.
У вас есть проект условной многоэтажки для условий слабонесущего грунта в Питере. Есть склад с материалами и/или подрядчики, готовые их поставить в нужное время в нужном количестве.
Вам поступил заказ на постройку такой же многоэтажки. Но на скальном грунте в Карелии. Вы снарядите сваезабивную машину и полетите забивать сваи? Нет, вы будете менять проект, поскольку фундамент здания придется разрабатывать с нуля. После чего придется перерабатывать всю инженерку здания, поскольку технический подвал из-за изменений в конструкции фундамента будет отсутствовать.
И вот тут получается такая несуразица. Вроде и стеновые блоки те же. И остальные материалы. И финальный внешний вид продукта такой же. И даже потребительские качества один-в-один. А проектную документацию пришлось почти полностью перерабатывать с нуля. Как так получилось?
Погодите, вы же только-только начали внедрение новой серебряной пули и уже нужно сдвигать сроки?
Вы же сами сказали, что внедрение началось только летом. Сейчас все только отошли от отпусков и начала учебного года. Просто нужно немного подождать.
Вы определитесь, вы делаете что-то новое или просто повторяете что-то, что уже было сделано много раз. Если последнее, то зачем весь этот фестиваль, ведь можно просто взять уже имеющийся, отлаженный и проверенный временем продукт? В мире софта для этого даже конвеер строить не надо.
Я был неоднократным свидетелем и даже участником оглушительно успешного внердения скрам. Видел откровенно неудачные внедрения, впрочем, у этих неудач почти всегда оказывалось конкретное имя и фамилия. Успешные Waterfall тоже видел. С DF (кстати, почивший в начале 2000-х RUP есть этот самый DF, только вид сбоку) личная статистика другая - видел только провалы разной степени оглушительности.
Кстати, исходя из Вашей статьи (и картинки, которая должны была быть смешной), с внедрением agile у вас что-то конкретно не заладилось.
И как он может это сократить, если эти факторы проявляются только в процессе разработки?
Кстати, есть еще одна вещь, которую тут пока еще не обсуждали: скорее всего, самые лучшие ваши разработчики (те самые, которые вытягивали предыдущие проекты, спасая горящие дедлайны) находятся уже в процессе выбора нового оффера.
Из изначально ложного предположения вытекает все, что угодно:
Нет, нет, и еще раз нет. Конвеер - это производственная линия, разделенная на участки, на каждом из которых специально обученные сотрудники при помощи узко специализированного инструмента выполняют крайне ограниченное число операций (в идеале - одну). При этом эти сотрудники не заменены на роботов либо по финансовым (робот дороже) соображениям, либо по совокупности причин (изделия отличаются - утром сверлим собираем седаны, после обеда - универсалы), когда проще поставить человека, чем изобретать адаптируемого робота.
Конвеер заточен в первую очередь на повторяемость.
Разработка ПО на это вообще не похожа. Разработка ПО - это именно проектно-изыскная работа. Когда инженеры проектируют изделие, которое нужно собрать, а то и придумывают конвеер для его сборки.
Попытки превратить разработку ПО в конвеер не прекращаются уже много лет. Без особого успеха.
Но это неважно. Важно другое:
У вас проблемы лежат вовсе не в плоскости методологии разработки. А в коммуникации внутри компании. И, как показывает практика, в таких случаях нужно не на манифест кивать, а перечитывать Крылова.
Про "отсутствие документации" в скрам выше уже написали. И да, я лично был свидтелем "внедрения" "аджайл", где все внедрение свелось к тому, что "документацию писать не надо".
Сначала между первым и вторым пунктом проходит 15 минут.
Через неделю - полтора дня.
Еще через неделю ревьювер вообще перестает отвечать.
Я был свидетелем внедрения доведенного до идеала подхода "Documentation first". Через два года "разработки" было очень много качественной, хорошо структурированной, рецензированной и подписанной документации. И было дано решение на самом верхнем уровне "а вот теперь пишем код". Через месяц написания кода весь этот сверкающий небоскреб из продуманной документации оказался карточным домиком и просто развалился.
Потому что разработка ПО, в отличие от многих других отраслей, отличается тем, что вы всегда имеете дело с неизвестным количеством неизвестных факторов. Которое невозможно предусмотреть заранее и которые выясняются только в процессе собственно разработки (и раннего тестирования). И нет, вы не сможете заранее "предусмотреть" и "выяснить" все незивестные путем "Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка."
Короче, ждем статью в сентябре 2026 года.
У Vijeo Citect нет встроенной возможности удаленного управления. Его ядро до сих пор родом из начала 90-х, когда интернета как такового не существовало.
Вот в то, что конкретное оборудование могли попробовать окирпичить, ещё можно поверить. Но установка Citect подразумевает отдельную сеть, физически изолированную от интернета
Поддержу boost::coroutine - вполне рабочее решение.
Но для борьбы с callback hell при работе с асинхронными API может быть стрельбой по воробъям. В состав boost::asio входят stackless coroutines: https://think-async.com/Asio/asio-1.22.0/doc/asio/overview/core/coroutine.html
По сути, это duff device на стероидах и имеет определенные (серьезные) ограничения. Но при правильном использовании позволяет очень эффективно реализовывать конечные автоматы, а оверхед при их использовании минимален - весь механизм запоминания состояния использует один int.