А для каких целей нужна оценка? Если нужна оценка большой фичи, то там оценка вообще выглядит не как число, а как набор рисков и вероятностей, попытка свести к одному числу - бесполезно. При этом оценка в SP никак не коррелирует с реальной трудоемкостью задачи или временем на ее выполнение (так как ни к чему не привязано). Ну а сходимость велосити - это про "самосбывающийся прогноз", к реальным оценкам и трудоемкости никакого отношения не имеет, просто решение подгоняется под готовый ответ, это популярное заблуждение.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Но меня забавляет настойчивость в использовании плохих методов менеджмента, даже их авторами уже признанными неудачными )
Команда может быть исполнителем с предсказуемой производительностью только если: 1) структура команды не меняется 2) все сотрудники в команде являются одинаковыми по производительности 3) входящие задачи имеют рутинный характер.
Увы, в реальности ни один из этих пунктов не соблюдается. Команда постоянно меняется (отпуска, смена мест работы, личный рост). Люди в команде тоже все разные и то, что один из них умеет делать плохо - другой делает хорошо и без планирования ресурсов внутри команды нельзя определить трудоемкость задачи. Входящие задачи тоже крайне редко настолько похожи друг на друга, что можно их оценивать одной линейкой.
Ну и, конечно, трудоемкость задачи (даже кривая в SP) никак не соотносится с временем доставки, так что нет никакой возможности на основе оценок SP хоть как-то вычислять время готовности к дедлайну, это тоже заблуждение.
Есть куча сценариев, где данные все-таки нужно запрашивать (ответ нужен синхронно, объем чужих данных очень большой, другой сервис не умеет в стриминг изменений, нет ресурсов для хранения чужих данных, нельзя получать данные не под запрос) и в этом случае запрос все-таки нужен. Да и получение потока чужих данных дает довольно сильную логическую связность, большую чем синхронный запрос.
Например есть статья от человека, который придумал SP: https://ronjeffries.com/articles/019-01ff/story-points/Index.html Про оценки сроков и трудоемкости неплохо написано у ДиМарко и Листера в "Вальсируя с медведями", короткий пересказ, например, в https://dev.to/tlakomy/why-i-don-t-like-story-point-driven-estimates-28h7 Но вообще бессмысленность оценок сложности, не соотнесенных с исполнителем достаточно очевидна, не понятно, зачем для этого что-то читать. Вообще, Scrum как магнит притягивает к себе кучу разнообразных плохих практик, по вполне понятным причинам.
На самом деле SP вообще не пригодны для каких-то оценок, кроме оценок рисков (и тогда сводятся к майкам). Вообще использование SP в большинстве случаев антипаттерн, но в предложенной методике и так настолько много сомнительных решений, что одним больше или меньше - уже не важно.
Да и "по возможности стоит избегать" - не совсем верно. Скорее уж асинхронное взаимодействие по возможности лучше избегать - как сложно контролируемое, увеличивающее latency и сложность кода.
(Прошу прощения, промахнулся по оценке, постарался компенсировать в других ваших комментариях). В конкретных случаях - да, может быть, так как фактически речь идет о стриминге изменений между двумя bounded contexts. Правда, кролик тут неудачный выбор и нужно бы Transaction Outbox прикрутить. Впрочем, когда есть TO, то он может и синхронно отправлять события, зачем там асинхронный MQ. Но, в любом случае, это не про "синхронные взаимодействия вообще плохи".
Это неверно. Если нужен ответ от сервиса, то все равно вызывающий ждет response-сообщения от MQ, только при этом требуется гораздо больше времени. А если ответ не нужен - то зачем его ждать? Клиенту нужен результат и если для его получения нужно вызвать 10 методов - они все будут вызваны, не важно, через MQ или синхронно. Но если вызывать через http/grpc, то результат будет быстрее и нагрузка на систему будет гораздо меньше.
Если приляжет MQ, то нужно будет сделать точно то же, так что логика retry в коде все равно будет нужна. Впрочем, нормальный resilience для http есть во всех языках и странно его не использовать.
В общем, не видно, с чего бы вызовы через ненадежный и без гарантий рэббит был бы хоть по каким-то параметрам лучше, чем прямой http вызов. Ну а если в кролике включать гарантии доставки (или, лучше, ставить кафку), то latency вырастет еще выше. Да и проблему с отправкой сообщений все равно не решить (
Но это же не так. Сделать http вызов с serviceA на serviceB очевидно дешевле, чем с ServiceA к брокеру и с брокера на ServiceB. Я уж не говорю, что тот же кролик "из коробки" не дает никаких гарантий, а для доставки at-least-once нужно будет громоздить кластер, персистанс и специального человека на поддержку всего этого добра. Впрочем, чистый http call тоже не дает никаких гарантий, но хотя бы не является SPOF
На 10000 серверах на каждом есть пайтон для запуска скриптов, написанных разработчиком? И к каждому с доступом на выполнение скриптов? И с логами, которые пишутся в файлы? Я не верю )
Кстати, yaznahar, а вы действительно не знаете про современные подходы к observability? Про системы сбора и хранения метрик, про системы сбора и хранения логов, про разделение метрик, логов и трейсов, про алертинги, про концепцию сайдкаров, про изоляцию продакшена от админов и разработчиков, про контейнеризацию и так далее и так далее? Пост действительно выглядит как пришедший из прошлого тысячелетия.
Э, нет конечно. Мы просто вешаем алерт на систему логгинга (которых бесконечное количество на любой вкус). И делаем это без каких-либо операций с продакшен-системой (типа добавления однострочников), крона и так далее. В стандартном стеке это делается в несколько кликов в графане. Она при этом еще и письмо пришлет или в телегу напишет.
Ну вот серьезно, уже XXI век на дворе, откуда эти идеи времен "приходящих виндовс-админов"?
А зачем вообще руками смотреть логи, да еще и запоминать позицию? Вроде бы уже XXI век, для постоянной работы с логами есть куча утилит и стоит пользоваться именно ими.
На Шекспира еще больше ссылок из научных трудов, что не делает "Сон в летнюю ночь" валидным научным трудом по межвидовой коммуникации. Проблема не в увлечении феминизмом, а в откровенной научной безграмотности конкретных утверждений. Но я уже понял, никаких обоснований хоть какого-то статуса DISC не будет.
Ну как, автор создал и продавал полиграф (нет научных подтверждений его работы и каких-либо подтверждений его работоспособности), развивал примитивный феминизм (женщины честнее и прочую фигню), а большую часть жизни вообще рисовал комиксы. Научных публикаций (кроме диссертации) я не смог найти.
Из персональных характеристик, насколько я помню, какое-то обоснование имеет только Big5, все прочие модели не имеют подтверждения. Но Big5 не предполагает быстрого определения параметров и довольно сложным образом коррелирует с поведением. Использование же ложной модели для выстраивания коммуникации хуже, нежели отсутствие моделей вообще.
А для каких целей нужна оценка?
Если нужна оценка большой фичи, то там оценка вообще выглядит не как число, а как набор рисков и вероятностей, попытка свести к одному числу - бесполезно. При этом оценка в SP никак не коррелирует с реальной трудоемкостью задачи или временем на ее выполнение (так как ни к чему не привязано).
Ну а сходимость велосити - это про "самосбывающийся прогноз", к реальным оценкам и трудоемкости никакого отношения не имеет, просто решение подгоняется под готовый ответ, это популярное заблуждение.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Но меня забавляет настойчивость в использовании плохих методов менеджмента, даже их авторами уже признанными неудачными )
Команда может быть исполнителем с предсказуемой производительностью только если:
1) структура команды не меняется
2) все сотрудники в команде являются одинаковыми по производительности
3) входящие задачи имеют рутинный характер.
Увы, в реальности ни один из этих пунктов не соблюдается. Команда постоянно меняется (отпуска, смена мест работы, личный рост). Люди в команде тоже все разные и то, что один из них умеет делать плохо - другой делает хорошо и без планирования ресурсов внутри команды нельзя определить трудоемкость задачи. Входящие задачи тоже крайне редко настолько похожи друг на друга, что можно их оценивать одной линейкой.
Все это приводит к бесполезности и оценки в SP и в оценке velocity вообще.
Тот же Рон про велосити пишет "If I invented velocity, I'm sorry" ( https://twitter.com/RonJeffries/status/1488220234750246919)
Ну и, конечно, трудоемкость задачи (даже кривая в SP) никак не соотносится с временем доставки, так что нет никакой возможности на основе оценок SP хоть как-то вычислять время готовности к дедлайну, это тоже заблуждение.
Есть куча сценариев, где данные все-таки нужно запрашивать (ответ нужен синхронно, объем чужих данных очень большой, другой сервис не умеет в стриминг изменений, нет ресурсов для хранения чужих данных, нельзя получать данные не под запрос) и в этом случае запрос все-таки нужен.
Да и получение потока чужих данных дает довольно сильную логическую связность, большую чем синхронный запрос.
Например есть статья от человека, который придумал SP: https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Про оценки сроков и трудоемкости неплохо написано у ДиМарко и Листера в "Вальсируя с медведями", короткий пересказ, например, в https://dev.to/tlakomy/why-i-don-t-like-story-point-driven-estimates-28h7
Но вообще бессмысленность оценок сложности, не соотнесенных с исполнителем достаточно очевидна, не понятно, зачем для этого что-то читать.
Вообще, Scrum как магнит притягивает к себе кучу разнообразных плохих практик, по вполне понятным причинам.
На самом деле SP вообще не пригодны для каких-то оценок, кроме оценок рисков (и тогда сводятся к майкам). Вообще использование SP в большинстве случаев антипаттерн, но в предложенной методике и так настолько много сомнительных решений, что одним больше или меньше - уже не важно.
Да и "по возможности стоит избегать" - не совсем верно. Скорее уж асинхронное взаимодействие по возможности лучше избегать - как сложно контролируемое, увеличивающее latency и сложность кода.
Нет разницы, как запрашивать данные, синхронно или асинхронно, в обоих случаях результат можно сохранить, если он нужен.
(Прошу прощения, промахнулся по оценке, постарался компенсировать в других ваших комментариях).
В конкретных случаях - да, может быть, так как фактически речь идет о стриминге изменений между двумя bounded contexts. Правда, кролик тут неудачный выбор и нужно бы Transaction Outbox прикрутить. Впрочем, когда есть TO, то он может и синхронно отправлять события, зачем там асинхронный MQ.
Но, в любом случае, это не про "синхронные взаимодействия вообще плохи".
Это неверно. Если нужен ответ от сервиса, то все равно вызывающий ждет response-сообщения от MQ, только при этом требуется гораздо больше времени. А если ответ не нужен - то зачем его ждать?
Клиенту нужен результат и если для его получения нужно вызвать 10 методов - они все будут вызваны, не важно, через MQ или синхронно. Но если вызывать через http/grpc, то результат будет быстрее и нагрузка на систему будет гораздо меньше.
Если приляжет MQ, то нужно будет сделать точно то же, так что логика retry в коде все равно будет нужна. Впрочем, нормальный resilience для http есть во всех языках и странно его не использовать.
В общем, не видно, с чего бы вызовы через ненадежный и без гарантий рэббит был бы хоть по каким-то параметрам лучше, чем прямой http вызов. Ну а если в кролике включать гарантии доставки (или, лучше, ставить кафку), то latency вырастет еще выше. Да и проблему с отправкой сообщений все равно не решить (
Но это же не так.
Сделать http вызов с serviceA на serviceB очевидно дешевле, чем с ServiceA к брокеру и с брокера на ServiceB.
Я уж не говорю, что тот же кролик "из коробки" не дает никаких гарантий, а для доставки at-least-once нужно будет громоздить кластер, персистанс и специального человека на поддержку всего этого добра. Впрочем, чистый http call тоже не дает никаких гарантий, но хотя бы не является SPOF
Автор пишет "Такое взаимодействие называется синхронным. Его лучше избегать". Хотелось бы понять, чем обусловлена такая рекомендация?
А чем все-таки плох синхронный подход? Простой и, в данном сценарии, наиболее надежный, с минимальной latency, простотой контроля и развития.
На 10000 серверах на каждом есть пайтон для запуска скриптов, написанных разработчиком? И к каждому с доступом на выполнение скриптов? И с логами, которые пишутся в файлы?
Я не верю )
Хм, они нормально работают от масштабов "один маленький сервер в чужом облаке" и до масштабов Гугла. А у тебя какой масштаб?
Кстати, yaznahar, а вы действительно не знаете про современные подходы к observability?
Про системы сбора и хранения метрик, про системы сбора и хранения логов, про разделение метрик, логов и трейсов, про алертинги, про концепцию сайдкаров, про изоляцию продакшена от админов и разработчиков, про контейнеризацию и так далее и так далее?
Пост действительно выглядит как пришедший из прошлого тысячелетия.
Нет, зачем там метрика с хоста? Достаточно метрики на основании запроса в систему логов, так все и делают обычно.
Э, нет конечно. Мы просто вешаем алерт на систему логгинга (которых бесконечное количество на любой вкус). И делаем это без каких-либо операций с продакшен-системой (типа добавления однострочников), крона и так далее.
В стандартном стеке это делается в несколько кликов в графане. Она при этом еще и письмо пришлет или в телегу напишет.
Ну вот серьезно, уже XXI век на дворе, откуда эти идеи времен "приходящих виндовс-админов"?
А зачем вообще руками смотреть логи, да еще и запоминать позицию? Вроде бы уже XXI век, для постоянной работы с логами есть куча утилит и стоит пользоваться именно ими.
На Шекспира еще больше ссылок из научных трудов, что не делает "Сон в летнюю ночь" валидным научным трудом по межвидовой коммуникации.
Проблема не в увлечении феминизмом, а в откровенной научной безграмотности конкретных утверждений.
Но я уже понял, никаких обоснований хоть какого-то статуса DISC не будет.
Ну как, автор создал и продавал полиграф (нет научных подтверждений его работы и каких-либо подтверждений его работоспособности), развивал примитивный феминизм (женщины честнее и прочую фигню), а большую часть жизни вообще рисовал комиксы. Научных публикаций (кроме диссертации) я не смог найти.
Из персональных характеристик, насколько я помню, какое-то обоснование имеет только Big5, все прочие модели не имеют подтверждения. Но Big5 не предполагает быстрого определения параметров и довольно сложным образом коррелирует с поведением. Использование же ложной модели для выстраивания коммуникации хуже, нежели отсутствие моделей вообще.