Тем самым user story mapping оказывается про принципиальную схему взаимодействия пользователя с системой, функциональный анализ -- "как оно работает, как получается польза". Поэтому user story map так сильно отличается от product backlog, который появляется исключительно в попытке модульного синтеза -- "как это реализовать, из каких кусков сделано".
Поразглядывайте примеры для user story map в google image. Очень поучительно.
И сразу становится понятным, почему user story mapping хорошо сочетается с domain-driven design (DDD) -- http://blog.eriksen.com.br/en/mapping-domain-knowledge.
Забавно, как принципы хорошего архитектурного моделирования, основанные на системном мышлении мееееедленно вползают в жизнь: из стенки и липучек изображают эдакий системный моделер, который по мере воплощения основных принципов системного мышления работает лучше и лучше.
Одно системное мышление, тысяча применений.
Но интересно читать, как понятия архитектурной работы "по норме" пытаются изложить "на пальцах" в коммуникативной парадигме ("истории", "нарратив", "эпопеи"). Скажем, берём принципиальную схему радиоприёмника, и рассказываем про "эпопею настройки колебательного контура", "эпопею подключения антенны", только чтобы не использовать системноинженерного языка.
Вот что пишет автор подхода user story map (http://jpattonassociates.com/the-new-backlog/): "I hate that word “epic.” I haven’t written Beowulf here. There’s no hero with a magic weapon slaying a monster. It’s just my user “managing email” – a relatively basic thing from my user’s perspective. At least the terms “activity” and “user task” give me some idea of what kinds of stories they are. That said, I’m not fond of the term “user story” either, but I’ve come to accept it. It beats the crap out of requirement.
Куда ведёт в этой цитате ссылочка со слова requirements? К его же статье Requirements considered harmful, где от слова requirements с его кажущейся неизменяемостью и окончательностью он уходит к слову decision, что можно было бы изменять и объяснять. Но кончается всё опять-таки не словом desicion, а теми самыми "нарративами" и "эпопеями" (epic) в user stories -- описаниями. Требования всего-то описания системы как чёрного ящика, со стороны её работы в составе использующей системы. И, конечно, описания могут меняться по мере продвижения в понимании, почему бы и нет.
То есть борьба у современных аджилистов IMHO идёт с ветряными мельницами, а не "бюрократической инженерией", но при этом медленно-медленно всё таки они ползут в сторону принятия системного мышления -- а хоть и устраивая системный моделер из стенки и липучек. Но мне кажется, один раз разницу между модульными и компонентными описаниями объяснить проще, чем мучительно переизобретать её снова и снова (например, противопоставляя product backlog и narrative -- хотя да, требуется дополнительный мыслительный шаг, модуль в product backlog это не просто новый файл или обособленный фрагмент кода, но распределённость в мышлении о модуле дела не меняет. Это именно "из чего сделано").
UPDATE: пара интересных реплик на этот пост появилась в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10206161610733298