Да, спасибо, понял вашу модель мира разработки. Резюме
Бизнес и разработка - это про проблемы и боль, а не про достижения новых целей. Только уменьшение или устранение этой боли. Команда разработки - это спасатели и врачеватели.
Сначала где-то в голове декомпозируем задачу проблему до разработки, на этапе разработки спохватываемся и начинаем обратную композицию, не потеряли ли что по дороге (ведь артефактов декомпозиции нет, потому что на этапе разработки "уже забывается", верно? Если бы они были, то при обязательной валидации каждого последующего шага декомпозиции обратная цепочка говорит лишь об профессиональном провале всех уровней анализа проекта)
По рис.2. Системы решают только проблемы? Просто задачи бизнеса они не решают?
Рис.4 противоречит содержанию всей статьи. Движение от разработки к решению задач бизнеса - как такое возможно? Собираются, значит, разрабы и давай разворачивать программные компоненты чтобы... и постепенно так рождаются задачи бизнеса. Прямо пластилиновый мультик
Когда-то давно тратил часы для бытовых задач (сложные групповые переименования), чтобы разобраться в этом адовом скпоплении символов. Как правило, безуспешно. И какая прекрасная эра наступила сейчас! Формулирую ИИ, вставляю какой-тоужасныйнаборнепонятночего в нужную программку - и всё, программка выдаёт нужный результат.
Если что, я, конечно, реально преклоняюсь перед теми, кто в этом как в воде. Но это надо иметь очень продвинутый мозг...
У домена нет ограниченного контекста - значит, что или домен не имеет контекста, или контекст не ограничен. В 1-м случае домен перестаёт существовать, т.к. ничего не содержит. Отметаем. Во 2-м случае мы можем напихать в контекст что угодно. В приведённом примере можно добавить, что компания занимается майнингом и торговлей криптовалюты для обеспечения закупок и взаиморасчётов. Теперь ваш домен включает приличный кусок деятельности, обеспечение которой может затмить (заменить, угробить) поставленную цель.
Так есть у домена свой ограниченный контекст или нет? Пока не понимаю, почему ограниченный контекст внезапно появляется только в поддоменах
Тут я приготовился увидеть резюме статьи для лентяев типа меня. И... вижу какие-то общие слова и какое-то изречение для камня. Т.е. вся статья, с уймой технических подробностей и типа смешными картинками, была написана, чтобы в финале дать наставления читающим?!
В хендбрейке те же опции, что и в статье, только через ГУИ.
Ну, у автора же посыл, что к чёрту все эти удобные штуки, побежали в командную строку, там всё гораздо интереснее
При CRF-кодировании ограничение битрейта нужно для того чтобы новая порция данных успевала считаться с диска или загрузиться по сети, а также учитывается размер буфера на плеере
Мы же говорим про кодирование, а не про воспроизведение? Каким образом я, перекодируя видео, могу предвидеть, какой там буфер у заранее неизвестного плеера и какие там скорости будут у совершенно мне неведомого носителя?
В общем, я впервые слышу, что при выборе CRF надо учитывать параметры носителя и плеера. Возможно, для специальных случаев, но явно не "для дома, для семьи". Не могу представить, чтобы HDD даже 10-15 летней давности (SATA-II, правильно помню?) не тянули полноценный блюрей, не говоря уже о пожатых видео
указание большего или меньшего значения CRF в большей степени зависит от скорости вашего накопителя, нежели от процессора
Какое отношение уровень качества видео имеет к скорости накопителя? Вообще никакого. В худшем случае, от скорости накопителя будет зависеть скорость кодирования, но никак не CRF.
В целом, статья совсем не убедила перейти с Handbrake или StaxRip на предложенную командную строку
Пример Use Case содержит ряд грехов по версии всех религий, кроме ленивой.
Актор висит в вакууме, выбрает товары в вакууме и т.п. Если свою систему не причисляете к акторам (а зря), то надо указать, с чем взаимодействует один этот актор.
Система, по-видимому, обладает телепатией, раз знает, есть товар на складе или нет. Надо анализировать наличие товара в системе с признаком "склад", а не товар на складе - это очень грубая ошибка, какой бы суперавтоматизированной система ни была
Полностью солидарен с @Cordekk Если не зафиксировать (для всех участников!) мемо в самое короткое время после окончания встречи, то какие-то детали потеряются. Если вообще не зафиксировать - потеряется значимое инфо, причём у всех сторон. Сплошь и рядом вижу это
Не советую новичку это читать. Какая-то дикая смесь всего со всем, потом потратите гораздо больше времени на исправление своих знаний.
Прямо с первой же картинки. Попробуйте определить, кто на ком там стоял - компоненты системы чудесным образом взаимодействуют то ли с архитектурным стилем, то ли с API в вакууме (сервер-то отдельно нарисован).
Схемы "неоднородных", прости господи, фронта и бэка просто чудесны, но тут уж сами, мне дальше лень
Допустим, что наша цель в 2024 году — это увеличить лояльность.
Хотите сделаю 99% всех клиентов абсолютно лояльными? Предоставлю им бесплатные полёты! Зачем какие-то розетки придумывать? С точки достижения цели я гораздо вас эффективнее - берёте на работу?
Это к тому, что явно с целью что-то не то. Толсто намекаю - есть цель, а есть способ достижения цели, и есть средства для каждого способа
Собственно, к объявленной теме - как обеспечить (= формировать) качественный бэклог - статья имеет весьма посредственное отношение. Очередной (возможно, полезный) рассказ о том, как выстроены рабочие процессы разработки глазами системного аналитика
Не есть гуд, если в команде бэклог формирует системный аналитик при наличии других ролей, близких к бизнесу. Что и видно по статье, прямо с первых строчек, что аналитик - пуп разработки
Таким образом, монолит — это не что иное, как строго одна единица развёртывания
Хотелось бы добавить, что при этом допускается изменение монолита отдельно по модулям, т.е. деплой отдельных модулей в рамках уже развёрнутого монолита (так понял рассказы разрабов).
По итогам статьи не понял, насколько хорошо сработал (срабатывает) эта модель оценки? Вы как-то оценивали попадание, разброс оценок и реальность?
В целом, к сожалению, модель применима исключительно к продуктовой команде, которая много лет сидит на продукте и может многими итерациями подгонять свои коэффициенты
Суть статьи даже не обсуждаю, абсолютно верно. Но проблема на другом уровне - уровне организации проекта/продукта. Если процессы построены так, что вопросы системного аналитика игнорятся, потому что ответственные за это роли - БА, продакт, роли заказчика - уже приняли решение, и приняли без вас (у них сроки/планы/бюджеты и, не дай бог, завышенная оценка своих решений), то вся эта красота про критическое мышление лопается.
Было пару раз недавно при прохождении собесов, на раунде уже с "главным" аналитиком. Звучало примерно так: "наш БА утверждает требования, а дальше твоя задача это реализовать. Если у тебя вопросы, то это твоя проблема - наш БА очень занят, и мы ценим время заказчика". Весьма уважаемые компании. После таких собесов ещё по полчаса приходил в себя :). К сожалению, бывают проблемы и внутри команды. Справедливости ради, столкнулся лишь на предпоследнем проекте - когда на твои вопросы твой же коллега-аналитик(!) в команде отвечал, что "вопросы бесполезные" и со спокойной совестью сливался в туман. О каком тут критическом мышлении можно говорить?
Вижу маленькую коробочку (слайд 2) с офигительной вычислительной мощностью и полным отсутствием принудительной вентиляции. Очень интересно
А мне немного странно, что вместо ответа по существу лезем в профиль человека и начинаем его обсуждать. Очень топорное поведение
Да, спасибо, понял вашу модель мира разработки. Резюме
Бизнес и разработка - это про проблемы и боль, а не про достижения новых целей. Только уменьшение или устранение этой боли. Команда разработки - это спасатели и врачеватели.
Сначала где-то в голове декомпозируем
задачупроблему до разработки, на этапе разработки спохватываемся и начинаем обратную композицию, не потеряли ли что по дороге (ведь артефактов декомпозиции нет, потому что на этапе разработки "уже забывается", верно? Если бы они были, то при обязательной валидации каждого последующего шага декомпозиции обратная цепочка говорит лишь об профессиональном провале всех уровней анализа проекта)По рис.2. Системы решают только проблемы? Просто задачи бизнеса они не решают?
Рис.4 противоречит содержанию всей статьи. Движение от разработки к решению задач бизнеса - как такое возможно?
Собираются, значит, разрабы и давай разворачивать программные компоненты чтобы... и постепенно так рождаются задачи бизнеса. Прямо пластилиновый мультик
Когда-то давно тратил часы для бытовых задач (сложные групповые переименования), чтобы разобраться в этом адовом скпоплении символов. Как правило, безуспешно. И какая прекрасная эра наступила сейчас! Формулирую ИИ, вставляю какой-тоужасныйнаборнепонятночего в нужную программку - и всё, программка выдаёт нужный результат.
Если что, я, конечно, реально преклоняюсь перед теми, кто в этом как в воде. Но это надо иметь очень продвинутый мозг...
У домена нет ограниченного контекста - значит, что или домен не имеет контекста, или контекст не ограничен.
В 1-м случае домен перестаёт существовать, т.к. ничего не содержит. Отметаем.
Во 2-м случае мы можем напихать в контекст что угодно. В приведённом примере можно добавить, что компания занимается майнингом и торговлей криптовалюты для обеспечения закупок и взаиморасчётов. Теперь ваш домен включает приличный кусок деятельности, обеспечение которой может затмить (заменить, угробить) поставленную цель.
Так есть у домена свой ограниченный контекст или нет?
Пока не понимаю, почему ограниченный контекст внезапно появляется только в поддоменах
Тут я приготовился увидеть резюме статьи для лентяев типа меня. И... вижу какие-то общие слова и какое-то изречение для камня.
Т.е. вся статья, с уймой технических подробностей и типа смешными картинками, была написана, чтобы в финале дать наставления читающим?!
Ну, у автора же посыл, что к чёрту все эти удобные штуки, побежали в командную строку, там всё гораздо интереснее
Мы же говорим про кодирование, а не про воспроизведение?
Каким образом я, перекодируя видео, могу предвидеть, какой там буфер у заранее неизвестного плеера и какие там скорости будут у совершенно мне неведомого носителя?
В общем, я впервые слышу, что при выборе CRF надо учитывать параметры носителя и плеера. Возможно, для специальных случаев, но явно не "для дома, для семьи". Не могу представить, чтобы HDD даже 10-15 летней давности (SATA-II, правильно помню?) не тянули полноценный блюрей, не говоря уже о пожатых видео
Какое отношение уровень качества видео имеет к скорости накопителя? Вообще никакого.
В худшем случае, от скорости накопителя будет зависеть скорость кодирования, но никак не CRF.
В целом, статья совсем не убедила перейти с Handbrake или StaxRip на предложенную командную строку
Пример Use Case содержит ряд грехов по версии всех религий, кроме ленивой.
Актор висит в вакууме, выбрает товары в вакууме и т.п.
Если свою систему не причисляете к акторам (а зря), то надо указать, с чем взаимодействует один этот актор.
Система, по-видимому, обладает телепатией, раз знает, есть товар на складе или нет. Надо анализировать наличие товара в системе с признаком "склад", а не товар на складе - это очень грубая ошибка, какой бы суперавтоматизированной система ни была
Про видео соглашусь частично. После записи иногда пользуюсь. Но видео довольно быстро устаревает.
Возможно, скоро будет обыденностью запускать AI по, в т.ч., видео для быстрого поиска и даже для наполнения базы знаний
Полностью солидарен с @Cordekk
Если не зафиксировать (для всех участников!) мемо в самое короткое время после окончания встречи, то какие-то детали потеряются. Если вообще не зафиксировать - потеряется значимое инфо, причём у всех сторон.
Сплошь и рядом вижу это
надеюсь, коммент не требуется
Не советую новичку это читать. Какая-то дикая смесь всего со всем, потом потратите гораздо больше времени на исправление своих знаний.
Прямо с первой же картинки. Попробуйте определить, кто на ком там стоял - компоненты системы чудесным образом взаимодействуют то ли с архитектурным стилем, то ли с API в вакууме (сервер-то отдельно нарисован).
Схемы "неоднородных", прости господи, фронта и бэка просто чудесны, но тут уж сами, мне дальше лень
Дочитал только до слов
Хотите сделаю 99% всех клиентов абсолютно лояльными? Предоставлю им бесплатные полёты! Зачем какие-то розетки придумывать? С точки достижения цели я гораздо вас эффективнее - берёте на работу?
Это к тому, что явно с целью что-то не то. Толсто намекаю - есть цель, а есть способ достижения цели, и есть средства для каждого способа
Собственно, к объявленной теме - как обеспечить (= формировать) качественный бэклог - статья имеет весьма посредственное отношение. Очередной (возможно, полезный) рассказ о том, как выстроены рабочие процессы разработки глазами системного аналитика
Не есть гуд, если в команде бэклог формирует системный аналитик при наличии других ролей, близких к бизнесу. Что и видно по статье, прямо с первых строчек, что аналитик - пуп разработки
Хотелось бы добавить, что при этом допускается изменение монолита отдельно по модулям, т.е. деплой отдельных модулей в рамках уже развёрнутого монолита (так понял рассказы разрабов).
Спасибо за коммент.
Просто обратил внимания на противоречия, а здесь как раз с логикой надо быть очень аккуратным.
Попал сюда по выдаче поисковика, чтобы перед собесом пробежаться по верхам, что такое EPC, которое было в требованиях. Ну, вот результат.
За ссылку на сравнение спасибо, посмотрю
По итогам статьи не понял, насколько хорошо сработал (срабатывает) эта модель оценки? Вы как-то оценивали попадание, разброс оценок и реальность?
В целом, к сожалению, модель применима исключительно к продуктовой команде, которая много лет сидит на продукте и может многими итерациями подгонять свои коэффициенты
Суть статьи даже не обсуждаю, абсолютно верно.
Но проблема на другом уровне - уровне организации проекта/продукта. Если процессы построены так, что вопросы системного аналитика игнорятся, потому что ответственные за это роли - БА, продакт, роли заказчика - уже приняли решение, и приняли без вас (у них сроки/планы/бюджеты и, не дай бог, завышенная оценка своих решений), то вся эта красота про критическое мышление лопается.
Было пару раз недавно при прохождении собесов, на раунде уже с "главным" аналитиком. Звучало примерно так: "наш БА утверждает требования, а дальше твоя задача это реализовать. Если у тебя вопросы, то это твоя проблема - наш БА очень занят, и мы ценим время заказчика". Весьма уважаемые компании. После таких собесов ещё по полчаса приходил в себя :).
К сожалению, бывают проблемы и внутри команды. Справедливости ради, столкнулся лишь на предпоследнем проекте - когда на твои вопросы твой же коллега-аналитик(!) в команде отвечал, что "вопросы бесполезные" и со спокойной совестью сливался в туман.
О каком тут критическом мышлении можно говорить?