Как и у любого инструмента, у этого подхода есть как плюсы, так и минусы. А главное - место применения. И вот тут кроется проблема. Для большинства приложений она избыточна, на мой взгляд. А понять нужно ли тебе будет на ходу менять реализацию, изначально скорее всего ты не сможешь.
То что решает данная архитектура можно спокойно сделать одним способом (не называя это архитектурой) - разделяй уровень представления и бизнес логику. И для этого в java уже давно всё есть - dto, mapper, и паттернов адаптер, фасад.
В начале весьма пугало то, как выйти на уровень, на котором я почуствовал бы себя комфортно. Но как только я принял участие во встрече, то понял, что таких же разработчиков, как и я, было множество.
Ценность заключается во встрече с такими же людьми, которым некомфортно от своего уровня знаний/умений?
Вы правы, но видимо у нас возникла проблема в терминологии. В статье я говорю про фичи — некоторый функционал, который можно протестировать, т.е. он что-то но делать будет. Таски на мой взгляд — это больше про конкретные задачи исполнителю, и способ их дробления во многом зависит от проекта и его стадии. Например, на старте проекта нормально иметь таски с эстимейтом в пару дней.
Так же стоит оговориться относительно релизной политики. У нас заведено следующее — мастер всегда полностью работоспособен и готов к выпуску (используем слека накрученный git-flow). Если что-то протестировали — оно льётся в мастер. Соотвествено чем меньше времени живёт таска, тем менее вероятно, что она с кем-то пересечётся по коду.
Любая фукционально-техническая задача на маштабе выливается в задачу управления. Agile тут про то, чтобы понять как дожить до светлого будущего с параметризацией и настройками, а не помереть по дороге.
Как и у любого инструмента, у этого подхода есть как плюсы, так и минусы. А главное - место применения. И вот тут кроется проблема. Для большинства приложений она избыточна, на мой взгляд. А понять нужно ли тебе будет на ходу менять реализацию, изначально скорее всего ты не сможешь.
То что решает данная архитектура можно спокойно сделать одним способом (не называя это архитектурой) - разделяй уровень представления и бизнес логику. И для этого в java уже давно всё есть - dto, mapper, и паттернов адаптер, фасад.
Ценность заключается во встрече с такими же людьми, которым некомфортно от своего уровня знаний/умений?
Так же стоит оговориться относительно релизной политики. У нас заведено следующее — мастер всегда полностью работоспособен и готов к выпуску (используем слека накрученный git-flow). Если что-то протестировали — оно льётся в мастер. Соотвествено чем меньше времени живёт таска, тем менее вероятно, что она с кем-то пересечётся по коду.