Forwarded from ScrumTrek
Media is too big
VIEW IN TELEGRAM
IT-тренды 2026
📹 Короткое видео о том, куда движется IT-индустрия: какие тренды перестали быть хайпом и превращаются в новую норму, а какие только набирают обороты.
💡 Основная мысль – мы начинаем смотреть на архитектуру как на инструмент выживания и роста компании и перестаем воспринимать ее как просто набор паттернов.
Приятного просмотра, делитесь своими мыслями в комментариях!⬇️
📹 Короткое видео о том, куда движется IT-индустрия: какие тренды перестали быть хайпом и превращаются в новую норму, а какие только набирают обороты.
Приятного просмотра, делитесь своими мыслями в комментариях!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7🤨4😐2
Подскажите в комментариях, пожалуйста, какие вам известны коммерчески успешные продукты, созданные ИИ?
Игры, приложения, что угодно, доступное публично и коммерчески успешное (или хотя бы просто публично).
Краткое исследование не позволило мне пока найти ни одного, но, возможно, я не там или не то искал.
Игры, приложения, что угодно, доступное публично и коммерчески успешное (или хотя бы просто публично).
Краткое исследование не позволило мне пока найти ни одного, но, возможно, я не там или не то искал.
🤔5❤1👍1
Новый кейс в архитектурных этюдах и… это случилось!
Тема «Архитектура управления проектированием в гражданском строительстве»
Буквально, alma mater 🙂
Подключаемся, автор кейса в канале, ответит на любые вопросы, кейс выглядит очень интересным и масштабным, так что не исключаю возможность проведения очного митапа 🙂
https://t.me/archicases/1/8326
Запрос:
— какие сложности в реализации видит сообщество;
— что бы поменяли в предложенной архитектуре.
Тема «Архитектура управления проектированием в гражданском строительстве»
Буквально, alma mater 🙂
Подключаемся, автор кейса в канале, ответит на любые вопросы, кейс выглядит очень интересным и масштабным, так что не исключаю возможность проведения очного митапа 🙂
https://t.me/archicases/1/8326
Запрос:
— какие сложности в реализации видит сообщество;
— что бы поменяли в предложенной архитектуре.
Опрос о потребности в архитекторах со знанием как проектировать системы, в которых есть ИИ-компонента (агентные/мультиагентные). В вашей компании:
Anonymous Poll
3%
Ищут на рынке архитекторов со знанием ИИ и находят
3%
Ищут на рынке архитекторов со знанием ИИ и не находят
15%
Дообучают архитекторов знанию ИИ внутри
4%
Дообучают архитекторов знанию ИИ на внешних курсах
21%
Инициативы ИИ есть, знаний нет, обходимся чем богаты, пытаемся разобраться
10%
У нас нет ИИ-инициатив
8%
Мы суперпрофи в ИИ, сами кого хочешь научим проектированию
50%
Посмотреть ответы
❤1
Forwarded from Сергей Баранов
Сам чатгпт говорит:
Чистый код (поддерживаемый, понятный, реализующий чистую архитектуру и Domain model) код будет нужен, и, более того, ценность «богатой» доменной модели и чистой архитектуры в ближайшие годы, скорее всего, вырастет, а не исчезнет. Изменится не сама идея, а инструменты вокруг неё: как модель описывается, проверяется и как из неё генерируется документация и вспомогательный код.
Spec‑driven / doc‑driven подходы становятся популярными именно потому, что спека становится тем, что «ест» ИИ для генерации кода и тестов.
Одновременно развивается и обратный вектор: инструменты, которые строят спеку и документацию поверх уже существующего domain model (код‑first), чтобы разные команды могли понимать и использовать модель.
Для сложных продуктовых доменов и длинноиграющих систем бизнесу нужны: стабильные инварианты, предсказуемое поведение и возможность быстро менять правила без переписывания всего окружения — это ровно то, что даёт хорошо спроектированный доменный код.
По мере роста роли ИИ именно строгий и чистый доменный слой становится «опорой» для генерации A/B‑тестов, сценариев, спецификаций API и прочих текстов: модели проще учиться и проверяться на базе кода с явными инвариантами, чем на «грязном» скриптовом зоопарке.
Если упростить: вкладываться в чистый, выразительный доменный код сейчас рационально; горизонт 5–10 лет выглядит как мир, в котором хороший доменный слой — это главный актив, на который уже «навешиваются» ИИ‑спеки, генерация документации и экспериментов, а не наоборот.
Чистый код (поддерживаемый, понятный, реализующий чистую архитектуру и Domain model) код будет нужен, и, более того, ценность «богатой» доменной модели и чистой архитектуры в ближайшие годы, скорее всего, вырастет, а не исчезнет. Изменится не сама идея, а инструменты вокруг неё: как модель описывается, проверяется и как из неё генерируется документация и вспомогательный код.
Spec‑driven / doc‑driven подходы становятся популярными именно потому, что спека становится тем, что «ест» ИИ для генерации кода и тестов.
Одновременно развивается и обратный вектор: инструменты, которые строят спеку и документацию поверх уже существующего domain model (код‑first), чтобы разные команды могли понимать и использовать модель.
Для сложных продуктовых доменов и длинноиграющих систем бизнесу нужны: стабильные инварианты, предсказуемое поведение и возможность быстро менять правила без переписывания всего окружения — это ровно то, что даёт хорошо спроектированный доменный код.
По мере роста роли ИИ именно строгий и чистый доменный слой становится «опорой» для генерации A/B‑тестов, сценариев, спецификаций API и прочих текстов: модели проще учиться и проверяться на базе кода с явными инвариантами, чем на «грязном» скриптовом зоопарке.
Если упростить: вкладываться в чистый, выразительный доменный код сейчас рационально; горизонт 5–10 лет выглядит как мир, в котором хороший доменный слой — это главный актив, на который уже «навешиваются» ИИ‑спеки, генерация документации и экспериментов, а не наоборот.
🔥18❤4🤔3❤🔥1👎1👌1
Катастрофа была неизбежна | GEO
https://www.youtube.com/watch?v=l_QcNZqUyN4
Я считаю, что это видео обязательно к просмотру каждому инженеру, это крутейший разбор аварии Челенджера. Я сам вначале был скептически настроен, но оно в итоге осталось настолко крутым, что решил разместить здесь.
Здесь и:
- Тема урезания скоупа для mission critical
- Придуманные цифры для оценки вероятности отказа
- Бюджетные войны
- Политика
- Пренебрежение безопасностью
В общем, я гарантирую, что будет интересно.
https://www.youtube.com/watch?v=l_QcNZqUyN4
Я считаю, что это видео обязательно к просмотру каждому инженеру, это крутейший разбор аварии Челенджера. Я сам вначале был скептически настроен, но оно в итоге осталось настолко крутым, что решил разместить здесь.
Здесь и:
- Тема урезания скоупа для mission critical
- Придуманные цифры для оценки вероятности отказа
- Бюджетные войны
- Политика
- Пренебрежение безопасностью
В общем, я гарантирую, что будет интересно.
👍9❤3🤔1
Forwarded from Блог Сергея Баранова (Сергей Баранов)
Эпистемическая диверсификация в мультиагентных системах
Некоторое время уже обсуждаю такую мысль в некоторых кругах.
Чтобы использовать курсор нужно забыть как писать код и использовать спек дривен вообще не глядя в код.
Потому что я вот детально уже описываю и он генерит рабочий и годный код, но либо с уязвимостями, либо с такой, который явно упадет при немного некорректных данных.
Код насквозь в ошибках разного рода и чем кода больше, тем больше ошибок.
При этом компилируется, работает, все в порядке…
Оно даже часто набор докер-файлов сгенерить не может так, чтобы специалист по делу не придрался.
Все работает, но специалист видит, в каком случае упадет и вероятность этих случаев стремится к 100% по мере эксплуатации.
——
Одно из решений, - это мультиагентные системы, но и они в экспериментах не решали обозначенной выше проблемы.
Я где-то месяц размышлял на эту тему, - ну мы же видим, мы же знаем, мы же можем.
И сегодня, кажется, понял. В мультагентной системе разработки агенты должны обучаться до достижения требуемого уровня (senior, middle, junior) разработчика, но на немного разных источниках. Так, как обучаются люди. У людей разная траектория развития и разный опыт. Это делает живую команду устойчивой и сильной.
Получается 7 разрабочтиков агентов с эпистемической диверсификацией, – опыта, навыков, знаний. Включая некоторый набор общеобразовательных знаний.
Остается сложность прослойке формирования общей ментальной модели, видимо оркестратор должен выступать фасилитатором для взаимного обучения в определенных областях, но эта мысль еще не настоялась. И вот такие агенты будут писать, реаьюить друг за другим и немного по-разному обучаться.
Почему эта мысль не пришла ранее? Потому что 90% всех работ, статей, кейсов, существующих сейчас - про узкую специализацию агентов, выполняющих свою функцию, и это рабочий подход для детерминированных систем, но не интеллетктуальных стохастических.
То есть мы собираем команду как настоящую команду, с разнообразием, но они в условно случайном порядке выполняют разные функции, обладая при этом полным контекстом знаний обо всех внутрикомандных функциях.
Давайте попробуем глубоко обсудить эту мысль. Я и сам уже вижу много сложностей с ее реализацией (например - само последовательное обучение + на чем именно обучаться и, что самое главное – «разобучение»), но хотелось бы послушать больше мнений.
Некоторое время уже обсуждаю такую мысль в некоторых кругах.
Чтобы использовать курсор нужно забыть как писать код и использовать спек дривен вообще не глядя в код.
Потому что я вот детально уже описываю и он генерит рабочий и годный код, но либо с уязвимостями, либо с такой, который явно упадет при немного некорректных данных.
Код насквозь в ошибках разного рода и чем кода больше, тем больше ошибок.
При этом компилируется, работает, все в порядке…
Оно даже часто набор докер-файлов сгенерить не может так, чтобы специалист по делу не придрался.
Все работает, но специалист видит, в каком случае упадет и вероятность этих случаев стремится к 100% по мере эксплуатации.
——
Одно из решений, - это мультиагентные системы, но и они в экспериментах не решали обозначенной выше проблемы.
Я где-то месяц размышлял на эту тему, - ну мы же видим, мы же знаем, мы же можем.
И сегодня, кажется, понял. В мультагентной системе разработки агенты должны обучаться до достижения требуемого уровня (senior, middle, junior) разработчика, но на немного разных источниках. Так, как обучаются люди. У людей разная траектория развития и разный опыт. Это делает живую команду устойчивой и сильной.
Получается 7 разрабочтиков агентов с эпистемической диверсификацией, – опыта, навыков, знаний. Включая некоторый набор общеобразовательных знаний.
Остается сложность прослойке формирования общей ментальной модели, видимо оркестратор должен выступать фасилитатором для взаимного обучения в определенных областях, но эта мысль еще не настоялась. И вот такие агенты будут писать, реаьюить друг за другим и немного по-разному обучаться.
Почему эта мысль не пришла ранее? Потому что 90% всех работ, статей, кейсов, существующих сейчас - про узкую специализацию агентов, выполняющих свою функцию, и это рабочий подход для детерминированных систем, но не интеллетктуальных стохастических.
То есть мы собираем команду как настоящую команду, с разнообразием, но они в условно случайном порядке выполняют разные функции, обладая при этом полным контекстом знаний обо всех внутрикомандных функциях.
Давайте попробуем глубоко обсудить эту мысль. Я и сам уже вижу много сложностей с ее реализацией (например - само последовательное обучение + на чем именно обучаться и, что самое главное – «разобучение»), но хотелось бы послушать больше мнений.
🔥4❤3👍1😁1
Forwarded from Блог Сергея Баранова (Сергей Баранов)
tarasenko01.pdf
213.1 KB
Наступает время личных и корпоративных стратегических выборов
Стратегический выбор стоит начинать не с выбора решений, а с тщательного исследования Problem Space – что именно является проблемой, для кого и почему это вообще проблема. В связи с этим – полезный материал по изучению проблемы и выбора типов решений (полагаю, Тарасенко для большинства подписчиков моего канала – вовсе не новая фамилия, а для кого новая – рекомендую его работы).
Отдельно добавлю про технологическую стратегию.
Для нее это означает, что «правильность» выбора направления развития нельзя обсуждать в вакууме. Необходимо явно перечислить стейкхолдеров, их интересы и критерии (качество, риски, скорость, стоимость, комплаенс, …), потому что именно в Problem Space формируются ограничения и критерии будущих решений. Сама идея «улучшающего вмешательства» (никому не хуже, кому-то лучше) полезна как граница для технологических инициатив, то есть хорошая стратегия должна улучшать положение целевых групп и не создавать новых проблем для остальных (безопасность/эксплуатация/финансы/…).
Это очень полезные 16 страниц 🚀
Стратегический выбор стоит начинать не с выбора решений, а с тщательного исследования Problem Space – что именно является проблемой, для кого и почему это вообще проблема. В связи с этим – полезный материал по изучению проблемы и выбора типов решений (полагаю, Тарасенко для большинства подписчиков моего канала – вовсе не новая фамилия, а для кого новая – рекомендую его работы).
Отдельно добавлю про технологическую стратегию.
Для нее это означает, что «правильность» выбора направления развития нельзя обсуждать в вакууме. Необходимо явно перечислить стейкхолдеров, их интересы и критерии (качество, риски, скорость, стоимость, комплаенс, …), потому что именно в Problem Space формируются ограничения и критерии будущих решений. Сама идея «улучшающего вмешательства» (никому не хуже, кому-то лучше) полезна как граница для технологических инициатив, то есть хорошая стратегия должна улучшать положение целевых групп и не создавать новых проблем для остальных (безопасность/эксплуатация/финансы/…).
Это очень полезные 16 страниц 🚀
stakeholders.pdf
169.9 KB
О полноте стейкхолдеров
При принятии решения, особенно при выработке «улучшающего вмешательства» критически важно учесть интересы стейкхолдеров. И не важно – это стратегическое решение или небольшое решение в рамках продукта. Любое решение на кого-то влияет (иначе зачем вы вообще его принимаете?).
В этой части книги информация о том, как выявить максимально полное множество стейкхолдеров.
От себя добавлю. Это «упражнение» тем проще, чем чаще его проводить. Чем уже скоуп, тем более стабильной будет структура стейкхолдеров. Для конкретного продукта она может меняться буквально на несколько стейкхолдеров от задачи к задаче, для ИТ-стратегии, за счет широты влияния, может меняться значительно сильнее, но и периодичность принятия решений отличается, что дает временнОе пространство для маневра.
При принятии решения, особенно при выработке «улучшающего вмешательства» критически важно учесть интересы стейкхолдеров. И не важно – это стратегическое решение или небольшое решение в рамках продукта. Любое решение на кого-то влияет (иначе зачем вы вообще его принимаете?).
В этой части книги информация о том, как выявить максимально полное множество стейкхолдеров.
От себя добавлю. Это «упражнение» тем проще, чем чаще его проводить. Чем уже скоуп, тем более стабильной будет структура стейкхолдеров. Для конкретного продукта она может меняться буквально на несколько стейкхолдеров от задачи к задаче, для ИТ-стратегии, за счет широты влияния, может меняться значительно сильнее, но и периодичность принятия решений отличается, что дает временнОе пространство для маневра.
👍3
Forwarded from Блог Сергея Баранова (Сергей Баранов)
Почему микросервисы – это сложно?
Это диаграмма 2018-го года. Обратите внимание на прямоугольники ближе к центру и дальше от него.
Чем дальше – тем конкретнее, лепестки – конкретные технологии. И с 2018-го года часть из них изменилась. Но то, что ближе к центру – остается стабильным.
Знание технологий не дает понимания или знания в микросервисах, оно дает знание технологий, которые помогают технически обеспечить работу микросервисного решения.
Это никоим образом не обесценивает знание технологий, они нужны, но только знание технологий, конкретных продуктов, ну никак не позволит спроектировать микросервисную архитектуру. Шанс случайно получить решение, обладающее всеми свойствами микросервисного архитектурного стиля стремится к нулю.
Это диаграмма 2018-го года. Обратите внимание на прямоугольники ближе к центру и дальше от него.
Чем дальше – тем конкретнее, лепестки – конкретные технологии. И с 2018-го года часть из них изменилась. Но то, что ближе к центру – остается стабильным.
Знание технологий не дает понимания или знания в микросервисах, оно дает знание технологий, которые помогают технически обеспечить работу микросервисного решения.
Это никоим образом не обесценивает знание технологий, они нужны, но только знание технологий, конкретных продуктов, ну никак не позволит спроектировать микросервисную архитектуру. Шанс случайно получить решение, обладающее всеми свойствами микросервисного архитектурного стиля стремится к нулю.
❤1👍1🔥1
Forwarded from Блог Сергея Баранова (Сергей Баранов)
Принципы Agile-манифеста.pdf
28.5 MB
Почему agile-это сложно?
Презентация 2017-го года, разъясняющая принципы agile-манифеста. Публично в первый раз выкладываю, менять не стал ничего, все по-прежнему актуально, хоть мы и продвинулись вперед.
Здесь я раскрывал принципы манифеста для лидеров команд и самих команд, много проговаривал и отвечал на вопросы, но на мой взгляд, пролистать презентацию без пояснений тоже будет полезно.
В чем ценность этой презентации?
Agile не любят не за сами принципы, а за «операции под чужим флагом», когда называя что-то agile устраивали разработчикам потогонку, просто сократив 1 месяц до 2 недель, не меняя толком процессы, инженерию.
Этим постом я бы хотел показать, что agile как манифест или как слово не дает практических рекомендаций или схем, – для этого у человека должны быть очень глубокие знания и понимание в области организационного дизайна, инженерии, построения процессов разработки, управления изменениями. И, внезапно, под флагом agile появилось много людей, которые в этом не разбираются или разбираются поверхностно, опять же, на хайпе, и мы получили то, что получили. Практически как с микросервисами.
Чтобы вы понимали, – иногда запуск и развитие одной команды (со снятием технических ограничений, наработкой опыта и практики, развитием инженерных компетенций, практик взаимоействия, устранения зависимостей, переходу к непрерывной поставке) могло занимать год! Но эта команда в итоге могла дать фору десяткам других команд.
Презентация 2017-го года, разъясняющая принципы agile-манифеста. Публично в первый раз выкладываю, менять не стал ничего, все по-прежнему актуально, хоть мы и продвинулись вперед.
Здесь я раскрывал принципы манифеста для лидеров команд и самих команд, много проговаривал и отвечал на вопросы, но на мой взгляд, пролистать презентацию без пояснений тоже будет полезно.
В чем ценность этой презентации?
Agile не любят не за сами принципы, а за «операции под чужим флагом», когда называя что-то agile устраивали разработчикам потогонку, просто сократив 1 месяц до 2 недель, не меняя толком процессы, инженерию.
Этим постом я бы хотел показать, что agile как манифест или как слово не дает практических рекомендаций или схем, – для этого у человека должны быть очень глубокие знания и понимание в области организационного дизайна, инженерии, построения процессов разработки, управления изменениями. И, внезапно, под флагом agile появилось много людей, которые в этом не разбираются или разбираются поверхностно, опять же, на хайпе, и мы получили то, что получили. Практически как с микросервисами.
Чтобы вы понимали, – иногда запуск и развитие одной команды (со снятием технических ограничений, наработкой опыта и практики, развитием инженерных компетенций, практик взаимоействия, устранения зависимостей, переходу к непрерывной поставке) могло занимать год! Но эта команда в итоге могла дать фору десяткам других команд.
🔥4❤2👍2