пробовал внедрять у себя? Очень интересен опыт внедрения и как он вообще в реале работает
Я думал эксперементы с этим в 0-ых закончились. Если серьезно - а зачем тебе? У тебя работа с гос заказами или какой-то аутсорс со спецификациями?
1. Бывает такое что ребята делают среднюю/большую задачу, кидают на ревью, а там много переделывать надо, иногда чуть ли не все, а код уже написан. Кмк архитектурное ревью могло бы сильно полечить боли в этом месте 2. Ребята часто не пишут никакую доку, а у нас 20 человек которые кодовую базу меняют + мы меняемся между продуктовыми командами, тяжело шарить знания 3. На архитектуру при разработке в общем обращают мало внимания, качество кода от этого страдает Сейчас у нас нет четких фаз сбора требований, написания и ревью архитектуры, в RUP все это подробно описано, вот и спрашиваю. В каком виде у вас собираются требования, рисуете ли диаграммы, есть ли ревью архитектуры на новые фичи и какие там требования? Вот это все интересно
дизайн ревью вам просто нужен. на тему этих фаз "сбор требований архитектура кодинг" - это все не работает. Точнее как - работает если ты разбиваешь это на маленькие итерации. большой upfront дизайн как правило это пустая трата времени.
короч не рекомендую RUP так как ты просто добавишь бюрократии (которую легко наебать - кто-то эти доки будет ревьювить и пока они ревьювятся это время ожидания)
сча кину тебе один докладик на тему
Сначала налепите стикерами что хотите Аля только события в эвентшторминг. Потом обведите как хотите разбить. И любую доп инфу подпишите что понимаете. Прокиньте это через стандартный флоу разработки и согласования. А потом сделайте таску на реализацию. Если будет профит наращивайте и меняйте что надо в процессе в процессе.
это не тот масштаб. Это (шторминги и обводить) нужно когда тебе надо разделить людей на команды адекватно (выделение доменов и контекстов, что бы потом stream aligned teams и вот это все). Словом когда у тебя разработчиков больше пары десятков.
Это работает и для обсуждения небольших тасок. В масштабе конечно это лучше фитится, но даже для просто прикинуть чтобы быстро исправить очевидное это хороший быстрый способ
process modeling да работает, но у них пока проблема что стадии анализа декомпозиции фич нет.
В руп кстати это тоже описано, за доклады большое спасибо – посмотрю
ну короч я RUP не осилил. я в целом плохо воспринимаю "фреймворки" для процессов (всякие scrum/SAFe/less и прочее говно)
Обсуждают сегодня