AT
это и был комплимент
Size: a a a
2020 September 18
PT
Крутяк.
PT
Спасибо.
G
Надо организовать свой банк бородачей.
И клиентов только бородатых пускать.
И клиентов только бородатых пускать.
Можно мне бородатую карту, пожалуйста!
IG
Там две составляющие:
1) технологическая = быстрое сравнение проектного решения с реализацией + быстрый реверс + кликабельные графы-схемы-процессные карты.
2) психологическая = team desing, "то-что-называют-культурой-но-не-про-таблички-и-обязанности" + внутреннее предпринимательство
По одной не работает, только два подхода вместе.
1) технологическая = быстрое сравнение проектного решения с реализацией + быстрый реверс + кликабельные графы-схемы-процессные карты.
2) психологическая = team desing, "то-что-называют-культурой-но-не-про-таблички-и-обязанности" + внутреннее предпринимательство
По одной не работает, только два подхода вместе.
> team design
очевидно, никакой реальной власти над этими командами он не имеет, иначе откуда взялся бы сам вопрос?
очевидно, никакой реальной власти над этими командами он не имеет, иначе откуда взялся бы сам вопрос?
IG
типа, "Ребят, я тут всем рулю, но меня на важные звонки приглашают только по нелепой случайности, что делать?"
AP
> team design
очевидно, никакой реальной власти над этими командами он не имеет, иначе откуда взялся бы сам вопрос?
очевидно, никакой реальной власти над этими командами он не имеет, иначе откуда взялся бы сам вопрос?
16 команд это 2.5 часа в неделю на каждую максимум. В таком раскладе крайне хорошим результатом будет уже то, что архитектор вообще хотя бы помнит, чем хоть примерно какая команда занимается
IG
но ведь в обсуждении новой интеграции двух продуктов явно участвовали представители двух команд (вряд ли только одной), и какой-то общий руководитель как минимум дал добро, и если (гипотетически) никто из них не решил спросить мнения главного архитектора, тут проблема не в архитектуре ПО
F
16 команд это 2.5 часа в неделю на каждую максимум. В таком раскладе крайне хорошим результатом будет уже то, что архитектор вообще хотя бы помнит, чем хоть примерно какая команда занимается
А если не помнит, то какой он архитектор? Мы не гворим про нагрузки и так далее, это проблемы организационного порядка. Но если входить в эту воду, то он должен не просто помнить а знать, к какому моменту что будет изменено.
F
но ведь в обсуждении новой интеграции двух продуктов явно участвовали представители двух команд (вряд ли только одной), и какой-то общий руководитель как минимум дал добро, и если (гипотетически) никто из них не решил спросить мнения главного архитектора, тут проблема не в архитектуре ПО
проблема в процессе, притом может быть как в сторону архитектора так и нет.
AP
А если не помнит, то какой он архитектор? Мы не гворим про нагрузки и так далее, это проблемы организационного порядка. Но если входить в эту воду, то он должен не просто помнить а знать, к какому моменту что будет изменено.
upfront design, при котором архитектор вообще может не участвовать в проекте после начала разработки, не учитываем?
F
Неа, его ценность начинает падать, а если его ценность падает, другие его роли отыграют, на каждый новый проект буду подбирать подходящего, а общий ландшафт, худо бедно будет дышать. И так можно, но вот хочется так, а главное как нужно то?
RT
Недавно я по счастливой случайности попал на созвон, на котором обсуждалась фича - хотели, утрируя, порвать к херам bounded context и в продукт X засунуть компонент от продукта Y. Если бы это случилось, мне бы пришлось потом это расхлебывать год.
Вот кстати, поделитесь кейсом аргументации как отбились.
Прилепить что-то к чему-то уже имеющемуся ведь всегда быстрее чем делать самостоятельный сервис/контекст/etc.
Кейс аргументации будет ценен сообществу)
Прилепить что-то к чему-то уже имеющемуся ведь всегда быстрее чем делать самостоятельный сервис/контекст/etc.
Кейс аргументации будет ценен сообществу)
AT
Можно мне бородатую карту, пожалуйста!
А ему такие отвечают: А по бороде?!
v
I
Там две составляющие:
1) технологическая = быстрое сравнение проектного решения с реализацией + быстрый реверс + кликабельные графы-схемы-процессные карты.
2) психологическая = team desing, "то-что-называют-культурой-но-не-про-таблички-и-обязанности" + внутреннее предпринимательство
По одной не работает, только два подхода вместе.
1) технологическая = быстрое сравнение проектного решения с реализацией + быстрый реверс + кликабельные графы-схемы-процессные карты.
2) психологическая = team desing, "то-что-называют-культурой-но-не-про-таблички-и-обязанности" + внутреннее предпринимательство
По одной не работает, только два подхода вместе.
+
I
Надо организовать свой банк бородачей.
И клиентов только бородатых пускать.
И клиентов только бородатых пускать.
Борода - центральный элемент логотипа московского DDD-сообщества)
EI
> team design
очевидно, никакой реальной власти над этими командами он не имеет, иначе откуда взялся бы сам вопрос?
очевидно, никакой реальной власти над этими командами он не имеет, иначе откуда взялся бы сам вопрос?
А как выглядит "реальная власть" над командами?
I
И хочется понять, как за этим можно следить, учитывая что у меня, если быть точным, 16 команд.
Нужно иметь круг "опорных программистов" и работать с ними, так как разорваться на всех вы не сможете. В Agile важно, чтобы команда была подготовлена к реализации, ибо незнание всегда порождает страх, неуверенность, и стремление ходить обходными, но более знакомыми для команды путями. Т.е. нужно предвидеть круг проблем на несколько месяцев вперед, и направлять развитие команды в нужном направлении. Ну и, периодически нужно заглядывать в код, разумеется. Если в продукт X впихнули компонент от Y, значит, не хватило знаний, чтобы разрешить этот вопрос правильно. Значит, были предвестники, которые можно было обнаружить на более ранних стадиях.