Comments 5
"принципиально изменило работу с требованиями и проектирование системы."
"Реализацию каждой user story проектируют отдельно. Часто это делает разработчик перед реализацией, и лишь для сложных user story проводят дизайн-сессии. Впрочем, тут есть много деталей, которые присутствуют в процессе неявно.
В частности, для решения о включении в спринт должно быть не только понятно, что user story реализуема, — важна примерная оценка трудоемкости реализации. А это означает, что общее представление о дизайне уже должно быть, и для этого еще на этапе подготовки бэклога к планированию привлекается кто-то из опытных разработчиков"
Если проектируется именно реализация отдельных историй, то в какой момент проектируется архитектура?
Это - слабое место Agile-методов. Архитектура проектируется в нулевой итерации, которая готовит старт проекта. Но там речь идет, скорее, о выборе технологий и фреймворка: взяли и погнали делать истории. А в первых историях - всегда самые распространенные сценарии: заказ оплачивается и отгружается полностью, весь товар склад находит и отгружает и так далее. То есть вместо 1:n связь 1:1, что позволяет вообще объединить сущности, расширив атрибутный состав. А дальше, когда доходит до сложных историй, выясняется, что рефакторить надо не только хранение - весь интерфейс заточен на то, что оплата - одна, а отгрузка - полная, а не частичная. И рефакторинг - дорогой.
Впрочем, часто можно не рефакторить. Не нашел склад какой-то товар - так вместо фиксации неполной отгрузки взяли и разделили заказ на два, один - отгружен, второй - нет. И оплату тоже разделили на две. Там с выпиской не будет биться по документам, но это - локальное усложнение, можно на атрибутах отработать. Вот много оплат за 1 единицу дорого товара принять - да, тут надо как-то будет придумывать при единственной оплате...
Но это все равно про фрагменты, с архитектурой сложной системы в целом с развитием получается беда быстрее, чем при развитии после проектирования. Хотя при проектировании тоже можно не угадать.
На этом я завершаю разговор про те способы работы с требованиями, которые появились благодаря Agile.
а что насчёт Domain Storytelling? добавляет ли он что полезное к ES?
Я о Domain Storytelling не знал, спасибо за наводку. Сейчас быстро посмотрел материалы - там две идеи. Первая - что вместо индивидуальных интервью спецов аналитиками с последующим сведением того, что они расскажут лучше собрать вместе экспертов и команду на workshop. Для беглого знакомства, наверное, лучше, и по астрономическому времени - быстрее, а вот по человеко-часам - больше, так что эффективность сильно зависит от организации встреч.
И вторая - визуальный язык для записи этих историй. Он повышает эффективность встреч. Но пригоден только для задач документооборота, историю о выверки отчетности или другие аналитические истории на нем не запишешь.
По сравнению с Event Storming отличается язык моделирования. В ES у нас события, в DS - workflow документооборота. События - более общий язык. F еще детальность, ES просто фиксирует наличие истории, детализация - вне сессии, а DS - углубляется в нее. Так что DS можно применять для тех областей, где его язык адекватен для детализации и погружения взамен обычной проработки user story через интервью.
а что на счет https://eventmodeling.org ?
Agile-методы: light-версии требований