Видимо не понятно выразился - я не могу Вам даже сходу сказать ни одной задачи, которая была бы в разработке чего-то нового
Ну так даже в передовой науке так - все новые открытия основываются на предыдущих научных работах, открытиях и явлениях. Тем не менее, что-то не слышно о попытках поставить научные открытия на конвеер.
Продолжая метафору - у нас есть куча строительных блоков, из которых мы собираем нужное изделие
У вас есть проект условной многоэтажки для условий слабонесущего грунта в Питере. Есть склад с материалами и/или подрядчики, готовые их поставить в нужное время в нужном количестве.
Вам поступил заказ на постройку такой же многоэтажки. Но на скальном грунте в Карелии. Вы снарядите сваезабивную машину и полетите забивать сваи? Нет, вы будете менять проект, поскольку фундамент здания придется разрабатывать с нуля. После чего придется перерабатывать всю инженерку здания, поскольку технический подвал из-за изменений в конструкции фундамента будет отсутствовать.
И вот тут получается такая несуразица. Вроде и стеновые блоки те же. И остальные материалы. И финальный внешний вид продукта такой же. И даже потребительские качества один-в-один. А проектную документацию пришлось почти полностью перерабатывать с нуля. Как так получилось?
Удалось за счет того, что в компании организована хорошая коммуникация с заказчиком, который готов был слышать о сдвигах сроков и давать корректировки
Погодите, вы же только-только начали внедрение новой серебряной пули и уже нужно сдвигать сроки?
коллектив стабильно сохраняется уже очень долгое время, текучки у нас нет.
Вы же сами сказали, что внедрение началось только летом. Сейчас все только отошли от отпусков и начала учебного года. Просто нужно немного подождать.
Производственная линия вполне может поддерживать вариативность, это не делает процесс уникальным от изделия к изделию.
Вы определитесь, вы делаете что-то новое или просто повторяете что-то, что уже было сделано много раз. Если последнее, то зачем весь этот фестиваль, ведь можно просто взять уже имеющийся, отлаженный и проверенный временем продукт? В мире софта для этого даже конвеер строить не надо.
Любая методология может быть доведена до абсурда. Даже самая лучшая. Вы, к сожалению, были, возможно, свидетелем именно такого.
Я был неоднократным свидетелем и даже участником оглушительно успешного внердения скрам. Видел откровенно неудачные внедрения, впрочем, у этих неудач почти всегда оказывалось конкретное имя и фамилия. Успешные Waterfall тоже видел. С DF (кстати, почивший в начале 2000-х RUP есть этот самый DF, только вид сбоку) личная статистика другая - видел только провалы разной степени оглушительности.
Кстати, исходя из Вашей статьи (и картинки, которая должны была быть смешной), с внедрением agile у вас что-то конкретно не заладилось.
Вот как раз сократить количество неизвестных факторов по-хорошему DF и должен сократить.
И как он может это сократить, если эти факторы проявляются только в процессе разработки?
Кстати, есть еще одна вещь, которую тут пока еще не обсуждали: скорее всего, самые лучшие ваши разработчики (те самые, которые вытягивали предыдущие проекты, спасая горящие дедлайны) находятся уже в процессе выбора нового оффера.
Из изначально ложного предположения вытекает все, что угодно:
написание ПО больше напоминает сборку изделия на конвейере,
Нет, нет, и еще раз нет. Конвеер - это производственная линия, разделенная на участки, на каждом из которых специально обученные сотрудники при помощи узко специализированного инструмента выполняют крайне ограниченное число операций (в идеале - одну). При этом эти сотрудники не заменены на роботов либо по финансовым (робот дороже) соображениям, либо по совокупности причин (изделия отличаются - утром сверлим собираем седаны, после обеда - универсалы), когда проще поставить человека, чем изобретать адаптируемого робота.
Конвеер заточен в первую очередь на повторяемость.
Разработка ПО на это вообще не похожа. Разработка ПО - это именно проектно-изыскная работа. Когда инженеры проектируют изделие, которое нужно собрать, а то и придумывают конвеер для его сборки.
Попытки превратить разработку ПО в конвеер не прекращаются уже много лет. Без особого успеха.
Но это неважно. Важно другое:
То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
У вас проблемы лежат вовсе не в плоскости методологии разработки. А в коммуникации внутри компании. И, как показывает практика, в таких случаях нужно не на манифест кивать, а перечитывать Крылова.
Про "отсутствие документации" в скрам выше уже написали. И да, я лично был свидтелем "внедрения" "аджайл", где все внедрение свелось к тому, что "документацию писать не надо".
Разработчик берется за задачу, изучает её и пишет документацию прямо в файлах проекта, оставляет комментарии по месту планируемых изменений. Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка. Именно описанный сценарий — отправная точка для проверки всего остального. Он позволяет ревьюеру проверить логическую цепочку.
Если есть замечания по решению, ревьюер возвращает доброску на доработку документации с комментариями. Разработчик дорабатывает документацию. Проверка повторяется.
Сначала между первым и вторым пунктом проходит 15 минут.
Через неделю - полтора дня.
Еще через неделю ревьювер вообще перестает отвечать.
Эту статью я в пишу в сентябре 2025 года. Мы начали внедрять методологию два месяца назад.
Я был свидетелем внедрения доведенного до идеала подхода "Documentation first". Через два года "разработки" было очень много качественной, хорошо структурированной, рецензированной и подписанной документации. И было дано решение на самом верхнем уровне "а вот теперь пишем код". Через месяц написания кода весь этот сверкающий небоскреб из продуманной документации оказался карточным домиком и просто развалился.
Потому что разработка ПО, в отличие от многих других отраслей, отличается тем, что вы всегда имеете дело с неизвестным количеством неизвестных факторов. Которое невозможно предусмотреть заранее и которые выясняются только в процессе собственно разработки (и раннего тестирования). И нет, вы не сможете заранее "предусмотреть" и "выяснить" все незивестные путем "Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка."
У Vijeo Citect нет встроенной возможности удаленного управления. Его ядро до сих пор родом из начала 90-х, когда интернета как такового не существовало.
Вот в то, что конкретное оборудование могли попробовать окирпичить, ещё можно поверить. Но установка Citect подразумевает отдельную сеть, физически изолированную от интернета
По сути, это duff device на стероидах и имеет определенные (серьезные) ограничения. Но при правильном использовании позволяет очень эффективно реализовывать конечные автоматы, а оверхед при их использовании минимален - весь механизм запоминания состояния использует один int.
Ну так даже в передовой науке так - все новые открытия основываются на предыдущих научных работах, открытиях и явлениях. Тем не менее, что-то не слышно о попытках поставить научные открытия на конвеер.
У вас есть проект условной многоэтажки для условий слабонесущего грунта в Питере. Есть склад с материалами и/или подрядчики, готовые их поставить в нужное время в нужном количестве.
Вам поступил заказ на постройку такой же многоэтажки. Но на скальном грунте в Карелии. Вы снарядите сваезабивную машину и полетите забивать сваи? Нет, вы будете менять проект, поскольку фундамент здания придется разрабатывать с нуля. После чего придется перерабатывать всю инженерку здания, поскольку технический подвал из-за изменений в конструкции фундамента будет отсутствовать.
И вот тут получается такая несуразица. Вроде и стеновые блоки те же. И остальные материалы. И финальный внешний вид продукта такой же. И даже потребительские качества один-в-один. А проектную документацию пришлось почти полностью перерабатывать с нуля. Как так получилось?
Погодите, вы же только-только начали внедрение новой серебряной пули и уже нужно сдвигать сроки?
Вы же сами сказали, что внедрение началось только летом. Сейчас все только отошли от отпусков и начала учебного года. Просто нужно немного подождать.
Вы определитесь, вы делаете что-то новое или просто повторяете что-то, что уже было сделано много раз. Если последнее, то зачем весь этот фестиваль, ведь можно просто взять уже имеющийся, отлаженный и проверенный временем продукт? В мире софта для этого даже конвеер строить не надо.
Я был неоднократным свидетелем и даже участником оглушительно успешного внердения скрам. Видел откровенно неудачные внедрения, впрочем, у этих неудач почти всегда оказывалось конкретное имя и фамилия. Успешные 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.