Разделение проекта на стори

Хотелось бы разобрать конкретные примеры, т.к. зачастую под «ядром» понимают реализацию бизнес-логики, которая может быть безболезненно распределена между несколькими «родственными» user story.

В целом, я вижу здесь два НЕвзаимоисключающих подхода.

Первый: разрешить заносить в product backlog так называемые «technical stories» при неукоснительном соблюдении следующих условий:
а) В результате выполнения такой technical story получается повторно используемый компонент, который будет задействован в большом количестве user story (например, инфраструктура логгирования или DI контейнер)
б) Для этой technical story сформулирован Definition of Done — например, компонент покрыт автоматизированными интеграционными тестами и они все проходят, он успешно прошел design и code review и т.п.

Второй: разрешить иметь зависимости в product backlog, когда в рамках одной из «родственных» user story делается часть функционала, которая будет потом повторно использована в других user story — соответственно, все эти остальные user story не могут быть сделаны раньше, чем первая. Это усложняет приоритезацию, но иногда является необходимым злом.

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

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

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

Другой очевидный пример: берем какой-нить RoR, и поговорив часок-другой, начинаем фигарить интернет-магазин. Можно даже без RoR, все-равно интернет-магазин не первый, и вполне понятно чего там куда и как. Никаких забот и хлопот о мифической архитектуре и ядрах — все уже есть, или есть четкое представление о том как должно есть. Или еще более радикальный вариант: «пофигу на архитектуру, она сама сложится, главное чтобы были тесты, если что-то будет не так — переделаем».

User stories, кстати, вроде как задача Product Owner’а, команда вроде как берет историю и пытается ее делить на задачи(или как их там они называют). Поэтому, если уж приходится играть по странным правилам с самого начала, и вспоминая что задачи — это таки прерогатива команды, куда-то там всунуть куски «ядра» можно пробовать.