По мне, работа этих сервисов показатель ограниченности пользователей. Если я вчера посмотрел боевик, то сегодня мне, скорее всего, захочется чего-нибудь другого.
Теперь вернемся к степени солености пищи. Как вы считаете, один и тот же человек предпочитает одну и ту же соленость или разную для одного и того же блюда? У кого больше возможностей учесть предпочтения - у повара, который солит по своему вкусу или у киберповара с загруженным профилем пользователя?
Смотрите, во-первых, странно видеть утверждение, что что-то не работает на основании одного примера. Это как сказать, что отвертка не работает потому, что она бесполезна, когда надо забить гвоздь. Я могу привести пример, когда рекомендательные сервисы работают. Например навигатор достаточно часто угадывает куда я хочу ехать.
Во-вторых, в самом примере логика достаточно странная. Если я что-от посмотрел вчера оно мне может быть нужно сегодня. Кроме того случая, когда оно потребляется смотрением типа фильма. Коньяк вроде пьют а не смотрят обычно.
В-третьих, любой рандомный товар мне тоже "скорее всего" не нужен. И вопрос - насколько это "скорее всего" больше или меньше чем "скорее всего" у коньяка. Например, я посморел но не выбрал. Или я регулярный покупатель коньяков и он мне нужен будет завтра. Или я регулярный покупатель коньяков и запомню марку до следующего раза. Короче надо сравнивать вероятность успешность продажи у коньяка и у случайной рекламы.
В-четвертых, странно, что все делают рекомендательные сервисы. Вряд ли они все дурачки.
Естественный язык появился как способ записывать звук. Даже если мы его формализуем то в нум останется легаси вот этой последовательной одномерности.
Имхо плюс может быть только в пороге входа. А минус - эта последовательная одномерность (конечно есть костыли в виде всякого форматирования, но все равно если порог входа и так большой - как в математике - то лучше уж переориентировать систему обозначений на визуальную).
Возможно так же сама похожесть на естестенный язык будет не только помогать но и мешать. Разные неформальные оттенки значений которые присутствуют в естестенном языке будут накладываться на на формализованные значения. Я думаю, именно поэтому даже для обычных слов в науке вводят какие-то специальные термины
Очевидно солить по вкусу. Вкус берется в настройках или выводится по предыдущим лайкам конкретного пользователя или обобщенного профиля целевой аудитории. См. как рекомендательные фичи работают.
Угу. Негативная мотивация. Показывать позитив нельзя. Надо стращать негативом. Для этого нанимать наглядное пособие по цене зарплата программиста * k + цена найма и увольнения.
ИМХО, если человек работает на результат, до него можно достучаться логикой (дать попробовать его идею, показать, к чему приводит, прислушаться к нему попробовать найти рациональное зерно, показать ограничения и достигнуть консенсуса). Если он не работает, то надо избавляться на этапе испытательного
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
Это и есть "содержать цикл". Программа тоже не выполняется сама, она декларирует наличие цикла. Чтобы его выполнить нужен какой-то интерпретатор - компьютер или человек может в уме выполнить.
а если разработчики не понимают как оценивать задачи из-за того что не знают как именно будут их решать?
Скрам мастер должен умет учить команду как ей самоуправляться. Один из аспектов самоуправления - умение планировать. Соответственно, он должен знать техники планирования.
Менеджер предложит оформить задачу как исследовательскую и отказаться от её оценки
Да. Это называется spikes. Это как раз один из приемов оценки. Такой же как и использование менее точных единиц измерения. По ссылке еще про backlog refinement.
Тимлид же засчёт технических навыков и опыта может подсказать решение тем самым устранив неопределённость при оценке вместо борьбы с её симптомами.
Тимлид может как иметь так и не иметь технических навыков. эксперт по технологиям может как быть так и не быть тимлидом.
Задача тимлида организовать получение этих знаний из специалиста, если он есть или другим образом, если его нет. Задача скрам мастера - научить команду саму организовывать получение знаний
Не совсем. Скрам не является интерфейсом. Скрам содержит код игрового цикла, который требует наличия реализации интерфейса.
Скрам мастер это разновидность менеджера, по крайней мере так метание считают.
Опытный мастер - опытный менеджер. Неопытный мастер - неопытный менеджер. Как и любой менеджер он не обязан быть специалистом в чем-то ещё, чтобы быть полезным но это ему поможет.
Если каркас можно чем-то обшить, например сайдингом. То описание каркаса обшить не получится.
В области информации каркас и есть описание. И так же как обшиание сайдингом (не знаю, обшивают ли на самом деле или как-то прикрепляют панели, а сайдинг это уже не то) требует сайдинга и навыков а не только каркаса (я, например, не смогу без дополнительного обучения), так же каркаса процесса недостаточно чтобы им овладеть.
Предствьте что Скрам это программный фрефмворк вот с таким кодом
public static void main()
{
IScrumTeam team = this.GetScrumTeam();
while (true)
{
var backlog = team.GetBacklog();
team.RefineBacklog(backlog);
var sprintBacklog = team.GetSprintBacklog(backlog);
team.DoBacklog(sprintBacklog, timeout: team.GetSprintLenght())()
team.ReviewSprint();
var processChanges = team.PerformRetrospective(sprint);
}
}
IScrumTeam это абстрактный интерфейс - задача конкретной команды его реализовать. Чтобы ее написать, надо знать алгоритмы, которые распространяются отдельно либо можете придумать самостоятельно, если готовые не устраивают.
В вашем случае мне непонятно, почему скрам мастера не помогли.
По идее, их задача помось скоммуницировать команде - подружить вас с PO чтобы он смог вам обяснить почему не берутся в спринт предложенные вами изменения либо чтобы вы объяснили PO, почему их надо взять. PO мог бы помочь с определением бизнес-ценности того, что вы хотели сделать (например, поговорить с заинтересованными лицами) и тогда или бы PBI взяли в спринт либо вы бы могли сказать почему их не взяли.
Приведите, пожалуйста, пример проблемы, созданной из-за несоблюдения интересов наемных инженеров, но никак не затрагивающих интересы бизнеса.
Я тут вижу только три варианта:
Инженеры действуют в интересах бизнеса напрямую - делают фичи, фиксят баги
Инженеры действуют в интересах бизнеса опосредованно (рефакторят код, чтобы его потом проще было менять, т.е. уменьшают стоимость и время пукта 1 в будущем)
Инженеры занимаются инженирингом just for fun - хобби проект, рефакторинг модуля, который все равно выкинут через неделю и заменят сторонним решением, оптимизация како-то процесса, который не находится в узком месте и никогда не будет
Третье я бы классифицировал как хобби за деньги и на оборудовании работодателей. Это не плохо, но должно быть согласовано и рассматриваться как часть пакета компенсации (зарплата, ДМС, льготы на обслуживание у работодателя и т.п.)
Если инженеры действуют в интересах бизнеса то бизнес обладает полнотой информации и ответственнустью за принятия решений - инженер может только рассказать про возможные варианты последствий решения (Если сейчас не отрефактрим, то потом будет в 10 раз труднее менять).
Так как я не могу обосновать бизнес-ценность, они наврядли будут учтены при планировании.
Вот это интересно. А почему вы не можете обосновать бизнес ценность? Вы делаете какие-то задачи не зная зачем? Или вы считаете что надо посчитать с точностью до копейки?
Для постройки дома нужны навыки проектирования, инструменты, материалы, умение с ними работать, знание СНИПов
Каркас дома это не дом - посмотрите на картинку. Для постройки дома на основании каркаса нужны материалы для стен и прочее. В каркасе нельзя жить.
В случае скрама есть дополнительная информация - книжки и люди.
Как я понимаю, со скрам мастерами так же как и с психологами. Окончания ВУЗа недостаточно чтобы он был гарантировано полезен. Вот, напрмимер, статья про то, как человек их собеседовал и сколько он отсеял
Любое слово похоже на стандарт, так как есть набор критериев, обозначать ли им явление или нет.
Допустим вы выпускаете каркасы домов (ну или набор чертежей для производства каркасов) под названием "Сетунь-3". Кто-то покупает ваши каркасы, навешивает на них каки-нибудь панели и получается готовый дом.
Потом вдруг люди начинают жаловаться что "Сетунь-3" непрочный отстой.
Вы расследуете причины и выясняете, что покупатели решили что часть балок им не нужно, и решили их отпилить, но готовые дома все равно называют "сделано на базе Сетунь-3" потому, что "Сетунь-3" это раскрученная марка и модно в определенных кругах.
Вы добавляете в инструкцию слова "Вы можете производить любые модификации, только, пожалуйста, на называйте результат "Сетунь-3"".
Фактически, с программными фреймворками та же ситуация - если вы переделаете Spring и будете называть свой фреймворк тоже Spring это приведет к путанице.
Програмные фреймворки в отличие от библиотек, это то, что вызывает ваш код => код должен подчиняться каким-то ограничениям (реализовывать предопределенные фремворком интерфейсы, например), а в библиотеках вы просто пользуетесь набором иструментов из коробки (или как если бы вам поставляли набор балок для вашего каркаса вместо самого каркаса)
In a framework, all the control flow is already there and there are many predefined white spots that we should fill out with our code.
Фактически как и скрам, которые определяет некоторые события и артефакты (control flow) и что от них ожидается, а не просто набор практик.
Мозговой штурм - это конкретная техника в состав которой водят определенные этапы и ведущий.
Теперь вернемся к степени солености пищи. Как вы считаете, один и тот же человек предпочитает одну и ту же соленость или разную для одного и того же блюда? У кого больше возможностей учесть предпочтения - у повара, который солит по своему вкусу или у киберповара с загруженным профилем пользователя?
Смотрите, во-первых, странно видеть утверждение, что что-то не работает на основании одного примера. Это как сказать, что отвертка не работает потому, что она бесполезна, когда надо забить гвоздь. Я могу привести пример, когда рекомендательные сервисы работают. Например навигатор достаточно часто угадывает куда я хочу ехать.
Во-вторых, в самом примере логика достаточно странная. Если я что-от посмотрел вчера оно мне может быть нужно сегодня. Кроме того случая, когда оно потребляется смотрением типа фильма. Коньяк вроде пьют а не смотрят обычно.
В-третьих, любой рандомный товар мне тоже "скорее всего" не нужен. И вопрос - насколько это "скорее всего" больше или меньше чем "скорее всего" у коньяка. Например, я посморел но не выбрал. Или я регулярный покупатель коньяков и он мне нужен будет завтра. Или я регулярный покупатель коньяков и запомню марку до следующего раза. Короче надо сравнивать вероятность успешность продажи у коньяка и у случайной рекламы.
В-четвертых, странно, что все делают рекомендательные сервисы. Вряд ли они все дурачки.
Естественный язык появился как способ записывать звук. Даже если мы его формализуем то в нум останется легаси вот этой последовательной одномерности.
Имхо плюс может быть только в пороге входа. А минус - эта последовательная одномерность (конечно есть костыли в виде всякого форматирования, но все равно если порог входа и так большой - как в математике - то лучше уж переориентировать систему обозначений на визуальную).
Возможно так же сама похожесть на естестенный язык будет не только помогать но и мешать. Разные неформальные оттенки значений которые присутствуют в естестенном языке будут накладываться на на формализованные значения. Я думаю, именно поэтому даже для обычных слов в науке вводят какие-то специальные термины
Очевидно солить по вкусу. Вкус берется в настройках или выводится по предыдущим лайкам конкретного пользователя или обобщенного профиля целевой аудитории. См. как рекомендательные фичи работают.
Чем меньше непривычных. А это уже зависит от того, к чему привык
А почему это сложнее просто запоминания какого-то отдельного слова?
Оптимист!
"СПОСОБНОСТЬ К ДОВЕРИЮ И ПОДЧИНЕНИЮ
Учитель лучше знает, что для тебя хорошо, а что плохо. Поэтому надо делать то, что говорит учитель. Даже если тебе кажется, что он не прав. "
Угу. Негативная мотивация. Показывать позитив нельзя. Надо стращать негативом. Для этого нанимать наглядное пособие по цене зарплата программиста * k + цена найма и увольнения.
ИМХО, если человек работает на результат, до него можно достучаться логикой (дать попробовать его идею, показать, к чему приводит, прислушаться к нему попробовать найти рациональное зерно, показать ограничения и достигнуть консенсуса). Если он не работает, то надо избавляться на этапе испытательного
А как его творение через код ресью проходило? Или он не код творил?
Чем?
Скрам гайд:
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
Это и есть "содержать цикл". Программа тоже не выполняется сама, она декларирует наличие цикла. Чтобы его выполнить нужен какой-то интерпретатор - компьютер или человек может в уме выполнить.
Скрам мастер должен умет учить команду как ей самоуправляться. Один из аспектов самоуправления - умение планировать. Соответственно, он должен знать техники планирования.
Да. Это называется spikes. Это как раз один из приемов оценки. Такой же как и использование менее точных единиц измерения. По ссылке еще про backlog refinement.
Тимлид может как иметь так и не иметь технических навыков. эксперт по технологиям может как быть так и не быть тимлидом.
Задача тимлида организовать получение этих знаний из специалиста, если он есть или другим образом, если его нет. Задача скрам мастера - научить команду саму организовывать получение знаний
Не совсем. Скрам не является интерфейсом. Скрам содержит код игрового цикла, который требует наличия реализации интерфейса.
Скрам мастер это разновидность менеджера, по крайней мере так метание считают.
Опытный мастер - опытный менеджер. Неопытный мастер - неопытный менеджер. Как и любой менеджер он не обязан быть специалистом в чем-то ещё, чтобы быть полезным но это ему поможет.
https://www.scrum.org/resources/blog/scrum-master-manager
В области информации каркас и есть описание. И так же как обшиание сайдингом (не знаю, обшивают ли на самом деле или как-то прикрепляют панели, а сайдинг это уже не то) требует сайдинга и навыков а не только каркаса (я, например, не смогу без дополнительного обучения), так же каркаса процесса недостаточно чтобы им овладеть.
Предствьте что Скрам это программный фрефмворк вот с таким кодом
IScrumTeam это абстрактный интерфейс - задача конкретной команды его реализовать. Чтобы ее написать, надо знать алгоритмы, которые распространяются отдельно либо можете придумать самостоятельно, если готовые не устраивают.
Например, для backlog refinement надо знать техники декомпозиции PBI и для приоретизации тоже есть техники.
В вашем случае мне непонятно, почему скрам мастера не помогли.
По идее, их задача помось скоммуницировать команде - подружить вас с PO чтобы он смог вам обяснить почему не берутся в спринт предложенные вами изменения либо чтобы вы объяснили PO, почему их надо взять. PO мог бы помочь с определением бизнес-ценности того, что вы хотели сделать (например, поговорить с заинтересованными лицами) и тогда или бы PBI взяли в спринт либо вы бы могли сказать почему их не взяли.
Приведите, пожалуйста, пример проблемы, созданной из-за несоблюдения интересов наемных инженеров, но никак не затрагивающих интересы бизнеса.
Я тут вижу только три варианта:
Инженеры действуют в интересах бизнеса напрямую - делают фичи, фиксят баги
Инженеры действуют в интересах бизнеса опосредованно (рефакторят код, чтобы его потом проще было менять, т.е. уменьшают стоимость и время пукта 1 в будущем)
Инженеры занимаются инженирингом just for fun - хобби проект, рефакторинг модуля, который все равно выкинут через неделю и заменят сторонним решением, оптимизация како-то процесса, который не находится в узком месте и никогда не будет
Третье я бы классифицировал как хобби за деньги и на оборудовании работодателей. Это не плохо, но должно быть согласовано и рассматриваться как часть пакета компенсации (зарплата, ДМС, льготы на обслуживание у работодателя и т.п.)
Если инженеры действуют в интересах бизнеса то бизнес обладает полнотой информации и ответственнустью за принятия решений - инженер может только рассказать про возможные варианты последствий решения (Если сейчас не отрефактрим, то потом будет в 10 раз труднее менять).
Вот это интересно. А почему вы не можете обосновать бизнес ценность? Вы делаете какие-то задачи не зная зачем? Или вы считаете что надо посчитать с точностью до копейки?
Каркас дома это не дом - посмотрите на картинку. Для постройки дома на основании каркаса нужны материалы для стен и прочее. В каркасе нельзя жить.
В случае скрама есть дополнительная информация - книжки и люди.
Как я понимаю, со скрам мастерами так же как и с психологами. Окончания ВУЗа недостаточно чтобы он был гарантировано полезен. Вот, напрмимер, статья про то, как человек их собеседовал и сколько он отсеял
Любое слово похоже на стандарт, так как есть набор критериев, обозначать ли им явление или нет.
Допустим вы выпускаете каркасы домов (ну или набор чертежей для производства каркасов) под названием "Сетунь-3". Кто-то покупает ваши каркасы, навешивает на них каки-нибудь панели и получается готовый дом.
Потом вдруг люди начинают жаловаться что "Сетунь-3" непрочный отстой.
Вы расследуете причины и выясняете, что покупатели решили что часть балок им не нужно, и решили их отпилить, но готовые дома все равно называют "сделано на базе Сетунь-3" потому, что "Сетунь-3" это раскрученная марка и модно в определенных кругах.
Вы добавляете в инструкцию слова "Вы можете производить любые модификации, только, пожалуйста, на называйте результат "Сетунь-3"".
Фактически, с программными фреймворками та же ситуация - если вы переделаете Spring и будете называть свой фреймворк тоже Spring это приведет к путанице.
Програмные фреймворки в отличие от библиотек, это то, что вызывает ваш код => код должен подчиняться каким-то ограничениям (реализовывать предопределенные фремворком интерфейсы, например), а в библиотеках вы просто пользуетесь набором иструментов из коробки (или как если бы вам поставляли набор балок для вашего каркаса вместо самого каркаса)
Фактически как и скрам, которые определяет некоторые события и артефакты (control flow) и что от них ожидается, а не просто набор практик.