Comments 10
Мне очень понравилось. Сразу стало понятно, чем человек занимается, и какие навыки нужны (предыдущие статьи еще не читал)
Кстати о Дейли, мы тут как раз про них записали выпуск подкаста: https://newpodcast2.live/podcast/estimates-and-dailies/
Начал слушать, но у вас сторона менеджмента. Архитектору не важно, кто и когда сделает. Важно как. Соответствует ли дизайну. Нет ли сюрпризов ломающих концепции. Допустим если разработчик делает и фронт и бэк, то часто появляются скрытые конвенции. Текстовое поле в запросе, которое ожидает магическое значение, без которого чуда не будет. Такое не проверишь тестом. Все ATP и QA тесты будут зелёные, а через пол года, когда другой разработчик будет менять фронт, выяснится, что у нас тут участки распределённого монолита...
Я тут экспериментирую со стилем
Ах, вот оно что! Предупреждать вверху надо.
Предупреждать о том, что есть 5 частей до этого в начале, означает, что все просто пройдут мимо. С другой стороны раз вы поняли, что это — ежедневная рутина архитектора, то всё прекрасно получилось.
Хороший вопрос. Я про такие не знаю. Архитектура больших решений очень тесно связанна с бизнес процессами и организацией. Закон Конвея. Поэтому из своего опыта я вижу только пару-тройку практик, которые были бы актуальны и переходили со мной в другие компании.
Я работал в нескольких компаниях и знаю от друзей о еще десятке — всё на 90% разное. Enterprise — это не "ещё один стартап, который мы подняли за неделю". Корпорации живут засчёт того, что они разные — одинаковых двух рынок не выдержит. В каждой есть свой нюанс и "у нас такой стандарт". Если VW и перенял методологию Toyota, то её адаптируют под себя. Акценты другие и границы должностей. В любом калькуляторе вас не интересуют 5 переменных, что есть у всех, а те 20 которые нужны только вам. В конкретном проекте конкретной компании. Можете сравнить Cost Calculator у Azure, GCP и AWS.
Архитектура архитектуры. Шаг 6: Ежедневный стэндап