Agile
Проект, который закончен, обычно переводят на стадию поддержки. Поддержкой проекта уже занимается другая команда, которая специализируется не на написании кода, а на его использовании.
Это вполне нормальная практика. Проект закончен, за него получены деньги, он сдан заказчику. Чего же тут необычного?
По-моему это лучше, чем вяло - текущий проект с постоянными доработками, авралами и прочими штучками.
Никто в здравом уме и твердой памяти не будет называть собранный за 4 месяца проект серьезным или "обширным". Скорее всего это банальный конструктор, т.е. взяли готовые модули и подогнали их под конкретного заказчика.
Во всяком случае, именно так мы работали на упомянутой мной фирме (когда делали мелкие проекты на заказ). У нас был набор библиотек с готовыми решениями и мы просто составляли готовый как пазл. Там, где детальки не подходили - мы их подгоняли под требования. И проекты были в основном от 2 недель до 6 месяцев.
По-моему это лучше, чем вяло - текущий проект с постоянными доработками, авралами и прочими штучками.
А по-моему ты говоришь об очень узком сегменте. Большая же часть проектов - если можно так выразиться "коробочные продукты", т.е. фирма разрабатывает свой проект (не важно у себя в штате или на аутсорсе) и эти продукты длятся до тех пор пока кто-то из менеджмента не закроет проект своим волевым решением (или пока дающая деньги фирма не обанкротится).
Вы правы: это не коробочный проект.
Раньше коробочные проекты были в большинстве. Но сейчас появилось много проектов, связанных с поддержкой оборудования, выпускаемого компанией.
Импортозамещение. Сейчас только ленивый не пишет проекты на контроллерах. Если же проект на контроллерах скрестить с промышленным продуктом (импортозамещение), то в результате часто получаются весьма интересные с разных точек зрения, хорошо масштабируемые решения...
Я всегда руководствовался принципом "Делай, что должен и будь, что будет". И до сих пор жив.
Сорры, нефига не понял. Я же быдлокодер из скрама. Мои задачи висят на борде, в крайнем случае в бэклоге. Я не могу, даже если хочу, навешать своих задач, сам оценить и начать их решать. Разрешение на любой модуль, включая внутренне необходимые перестроeния я получаю от продуктовнера(не напрямую, но в принципе).
Ни разу не встречал ошибок типа lock-free, хотя с многопоточных и приложениями работаю уже не первый десяток лет регулярно. А за последние 5 лет на рынке появилось такое множество инструментов разруливания lock-free проблем, что получить deadline ситуацию сейчас можно разве что по убеждению.
Не понял, при чем тут deadlocks, если оно "locks-free" изначально? Чтобы не быть голословным, вот пример жопы: прием и декодирование multicast UDP от биржи, с минимально возможными задержками, когда канал был 1 гигабит, то все работало, и не один год. Теперь канал 10 гигабит и неслабо возросший траффик (а все датаграммы по 50-100 байт), и прежний дизайн не справляется... И начинается препарирование Boost, приходится отказываться от sequentally-consistent семантики доступа в atomic, и переходить к семантике ослабленного упорядочивания memory_order_acquire/memory_order_release/memory_order_relaxed, а там столько граблей...
У нас, например, есть как проекты, которые длятся уже больше 15 лет, так и такие, которые сделаны и забыты, но это, как правило, что-то небольшое. Первое подразумевает постоянный заработок для фирмы. Авралы тут каким боком? Я не понимаю. У вас какая-то каша в голове.
Биржа локальная или глобальная? Вообще, о какой бирже речь?
почему не ведутся? Agile бывает разный, просто для продуктовых проектов надо делать коррекции, которые зависят от:
- сложности проекта - одно дело клепать "стандартные" вещи, типа веб-сайтов и т.п., в которых можно делать оценку задач достаточно легко, другое дело - когда требуется серьезный research, плюс интеграция со сложными продуктами (особенно плохо документированными)
- наличия требований
- как он распространяется - firmware, on premise, cloud - соотвественно разные длительности спринтов и т.п.
- количества людей на проекте (как вам проект с парой тысяч людей?)
- и т.п.
Мы в свое время (на предыдущей работе) нашли правильный подход, который типа Agile, но без 2-3 недельных спринтов и т.п.