А если понимаешь - то скрам и не нужен

упс

Контроль за процессом в эмерджентных ситуациях невозможен. Потому что процесс прерывается.

процесс стандартный прерывается, начинается нестандартный 🙂

даже в скраме есть немного про это (см. отмена цели спринта и остановка спринта)

Контроль над несуществующим - это уже опасный признак)

Да, это верно. Но если процесс прервался, то и управление процессом прервалось. Как и работа менеджера. И тут тимлид превращается из менеджера в прораба)

С другой стороны, у нас 2 года назад была такая проблема, что разрабов всё время отвлекали текущими операционными задачами. Выгрузить какой-то нестандартный отчёт, сделать какую-то очень срочную фичу и так далее. Возможно, сейчас речь о чём-то подобном.

Ну, окончательно решить эту проблему мы смогли только созданием команды эксплуатации и техподдержки внутри неё. Опять-таки, это чисто системное решение проблемы. Оно вообще никакого отношения не имеет к достоинствам и недостаткам методологии управления процессом.

Кстати, для команды эксплуатации (да и для любой операционной деятельности, кмк) гораздо органичнее канбан чем скрам.

Первый вариант (более экономный и не требует выхода на уровень выше) был в выделении дежурного. По команде делали график дежурств и на целый спринт чувак выпадал из работы, занимаясь исключительно операционкой. К сожалению, это тоже так себе работало из-за разницы в экспертизе. Чаще всего дежурный в итоге всё равно пригружал кого-нибудь ещё. Поэтому, собственно, через год мучений пошли наверх и стали требовать разделить разработку и эксплуатацию.

Ну и я очень хорошо себе представляю ситуацию когда участники команды не рефлексируют свою работу (не собирают обратную связь с процесса), и годами работают в такой вот жопе. Ну, собственно, до меня тут это продолжалось лет 5.

А потом удивляются, чего это люди уходят.

Я это к чему всё. Процесс эксплуатации и процесс разработки это две большие разницы.

Если у вас в обоих процессах задействованы одни и те же люди, то вы регулярно будете сталкиваться с пожарами, которые будут выбивать у вас людей из процесса разработки. Ну и это будут не опытные пожарные, которые натасканы именно на пожары и весь их процесс выстроен именно для тушения пожаров, а так, любители с огнетушителем и песком. Соответственно, оба процесса будут неэффективны.

А чаще даже дело обстоит так, что команда заточена строго под разработку, но когда приходит какой-нибудь песец - переключается в абсолютно непрописанную несистемную деятельность, которая никакими регламентами не управляется. Это и правда похоже на тушение пожара любителями) Ну и разумеется такой процесс не поддаётся никакому управлению. Потому что процесса не существует. Вместо процесса - просто кучка рассинхронизированных людей в нервном истощении, пытающаяся сделать хоть что-то.
Но почему-то многие считают, что так и должно быть.

В первую очередь нужно понять фундаментальную разницу между разработкой (развитием) и эксплуатацией. НИИ нельзя управлять как пожарной частью. Пожарной частью нельзя управлять как НИИ. Тогда станет намного понятней какие методологии куда применять и жизнь станет проще.

из этого следует что devops как подход не имеет права на жизнь, потому что одни и те же люди не могут писать код и гонять его в продакшене
как жить теперь?

так что применять то?)

Я откуда знаю что вам применять?)

ну вот и ответ - что нет универсальных рецептов, а скрам  - очень нишевая штука.

Не. Девопс вполне себе в эту схему ложится. Это эксплуатация как раз. Читали "проект феникс"?

девопс это команда, которая и разрабатывает, и эксплуатирует

эксплуатация это просто опс

Если я усну, и проснусь через сто лет, и меня спросят, что сейчас обсуждают в тимлидских чатах, я отвечу: обсуждают скрам и пытаются понять, чем занимается тимлид...

Комнда, которая и разрабатывает, и эксплуатирует, есть буквально в каждой продуктовой компании)
И они были задолго до появления девопса. Почему это не привело ни к чему хорошему?

от жиза