Scrum — это гибкая методология управления проектами и разработки программного обеспечения, которая используется для эффективного создания продуктов в условиях неопределенности и постоянных изменений. Основные принципы и элементы Scrum включают:

1. Итеративный и инкрементальный подход: Работа над проектом делится на короткие итерации, называемые спринтами, продолжительность которых обычно составляет от одной до четырех недель. В конце каждого спринта команда предоставляет работающий продукт или его часть.

2. Роли: В Scrum есть три основные роли:

   • Product Owner (владелец продукта): Ответственен за максимизацию ценности продукта и управление бэклогом продукта.

   • Scrum Master: Обеспечивает соблюдение Scrum-процессов, помогает команде устранять препятствия и содействует улучшению.

   • Development Team (команда разработки): Кросс-функциональная команда, которая работает над созданием продукта.

3. Артефакты:

   • Product Backlog (бэклог продукта): Список всех задач и требований к продукту, приоритезированный владельцем продукта.

   • Sprint Backlog (бэклог спринта): Набор задач из бэклога продукта, отобранных для выполнения в текущем спринте.

   • Increment (инкремент): Завершенная часть продукта, созданная за спринт, которая добавляется к предыдущим инкрементам.

4. События:

   • Sprint Planning (планирование спринта): Встреча, на которой команда планирует задачи на предстоящий спринт.

   • Daily Scrum (ежедневный скрам): Короткие (до 15 минут) ежедневные встречи, где команда обсуждает прогресс и выявляет препятствия.

   • Sprint Review (обзор спринта): Встреча в конце спринта для демонстрации выполненной работы и сбора обратной связи.

   • Sprint Retrospective (ретроспектива спринта): Встреча, где команда анализирует прошедший спринт и разрабатывает планы по улучшению процессов.

Scrum ориентирован на сотрудничество, адаптивное планирование и быструю доставку ценного продукта клиенту.

С другой стороны, можно зафиксировать скоуп, но тогда либо сроки будут плавать, либо качество.

Но мне кажется причина в требовании коммитмента на сроках
В Agile про коммитмент ничего не сказано и он скорее противоречит духу гибкой методологии

Во-первых, agile и гибкая методология это одно и тоже, это буквальный перевод.

Во-вторых, agile в целом ничего не говорит про коммитменты, он скорее про коммуникации и построение процессов вокруг коммуникации, а не вокруг документации. Сверху можно навалить больше методологических слоев, которые уже помогут зафиксировать сроки, обработать риски и прочее, например - тот самый SAFe.

То, о чем вы говорите, скорее вытекает из нежелания бизнеса признавать триаду проектного управления, из чего вытекают нереалистичные ожидания. Скрам тут только подливает масла в огонь, так как построен вокруг баланса скоуп-время (при фиксированном размере команды обычно, то есть бюджете), что в свою очередь просто не подходит для проектной деятельности, где все три параметра зафиксированы заранее.

В чем проблема взять задачу-плейсхолдер на весь спринт

Именно про это я и говорю! Какая польза от этого? Мы синтетически "натягиваем" рабочий процесс на спринты, чтобы "было по скраму", при этом скрам никак не отражает реальный процесс, а то, что мы видим в нем - фикция, плейсхолдер.

В итоге рабочий процесс идет как и шел, а в трекере стоят нерепрезентативные заглушки, но зато менеджмент доволен, все под контролем!

Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.

Не уверен, что это действительно так. Кроме каких-то совсем маленьких компаний или компнаий с "особым путем", все поголовно используют скрам, многие лишь потому что "ну все так делают".

И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.

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

В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить.

К процессам претензий нет, претензия к карго-культизму. Когда процесс не ради решения задач, а потому что надо.

А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер?

Я бы сказал, что это зависит. Большие задачи само по себе не очень хорошо, и дробление задач оправдано, когда это делается с целью уменьшения энтропии, а не с целью "чтобы влезло в спринт". Не знаю, делают ли так, но не вижу причин не ввести поправку на размер, если конечно мы умеем определять размер.

Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.

Такие проекты вообще на любую методологию хорошо ложатся. Управлять известным объемом при известном капасити много ума не надо. Сложности (и потребность в методологиях) повышается, когда растут неизвестные, а с ними и риски.

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

Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:

1. Что происходит?

2. Когда будет готово?

Ответы на эти вопросы можно найти в Jira; в любой момент времени и в любом формате. Не обязательно всех в шеренгу ставить.

В самом скрам нет проблем, это узкоспециализировнный инструмент, подходящих для конкретных задач, а для каких то неподходящий.

Как и везде? Было бы странно рассматривать методологию в отрыве от практики ее применения.

Сам по себе скрам неплох, но увы - делают с ним что-то не то.

Когда требования и планы могут меняться каждый месяц...

Вы сейчас описываете не скрам, а аджайл манифесто.

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

Можно свалить на неумение разбивать - с этим тоже не спорю. Большинство аргументов в пользу скрама и сводятся к тезису "вы просто не умеете его готовить".

Но если мало кто умеет его готовить, может не в поваре дело?

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

Мы не используем event-sourcing, у нас более классический подход, основанный на CQRS, где запросы выполняются синхронно по gRPC, а команды асинхронно через сообщения. Где вы в такой модели видите размытия границ, я не вижу, при том, что запросы на чтение ничего не изменяют (а значит, никакого bounded contexts по факту там нет, да и доменов нет, потому что для запросов в CQRS отдельные упрощенные и оптимизированные для скорости чтения и кеширования модели), а запросы на изменение (команды) четко ограничены обработкой внутри домена, и никаких открытых соединений с другими сервисами в процессе этого нет, только чтение из брокера и запись в брокер..

В итоге в дереве вызовов (или дереве транзакций) из A->B->C получается, что A оркестрирует B, а B оркестрирует C (в статье даже есть картинка). При этом А ничего не знает про С, С не знает про B, и B не знает про A, и это больше похоже на хореографическую сагу.

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

	switch state {
	case model.InitialState:
		switch event {
		case eventNodeChanged:
			// ...

		case eventNodeDeleted:
			// ...
		}

	case model.NodeInstanceCreationPending:
		switch event {
		case eventNodeChanged:
			// ...

		case eventNodeDeleted:
			// ...
		}

	case ...
	}

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