Имхо, будущее за той компанией, которая даст больше прикладного результата пользователям. А здесь Google на голову впереди всех конкурентов. У него одного фактически сейчас возможность интегрировать LLM в большую часть областей жизни/работы: Android (и Pixel в частности), браузер, почта, Docs/Sheets, Drive, Cloud, поиск и уйма чего ещё.
Верно ли, что раньше TL, допустим, пришедший с рынка, мог вырасти в DL, допустим, за 2 цикла перф ревью (1 год), а теперь этот маршрут стал в среднем в 2 раза длиннее?
M2 > M3 вероятно остаётся таким же. Но М1 > М3 или М2 > М4 уже точно затянется на пару лет. А М1 > М4 на все несколько.
Не понял один момент - первая половина статьи про CIO, во второй уже больше употребляется CTO. А на одном изображении есть сразу обе аббревиатуры. Но это же разные роли и ожидания от них разные.
На сервис А налили так много трафика, что перестала выдерживать его зависимость Б (сам сервис А нагрузку держал). На клиентах сервиса А были выставлены низкие таймауты, поэтому клиенты начали рвать к нему коннекты. Разрыв коннекта -> ретрай. Между сервисами был включен mTLS, у каждого был Envoy в виде сайдкара для межсервисной авторизации, rate limiting и прочего. И вот из-за хендшейков CPU у Envoy уперлось в лимит, из-за чего не доходило даже до проверки токенов в бакете рейт лимитера.
Команда 1 TL + 7 dev, пишем на Python + Go, проблем нет. Задачи следующего спринта всегда прогрумлены на 90%, остаётся догрумить "влёты". Оценённый беклог колеблется от 4 до 5 спринтов.
Непонятно только за что минусят мои комментарии без каких-либо аргументов :)
Мы оцениваем задачи всей командой дважды в неделю по часу. В среднем в беклоге есть оценённых задач на 5 спринтов вперёд.
Сначала у нас была проблема - мы ужались до того, что все задачи укладывались в 1-3 SP. Мы провели аффинную оценку:
я вытащил из беклога 50 выполненных задач, то есть известных команде
сделал на доске (любой аналог Miro) несколько столбцов
всей командой двигали задачи туда-сюда, оценивая их относительно друг друга -> задачи отсортировались по сложности
выделили что-то общее у задач в каждом столбце
дальше на столбцы натянули стори поинты
из полученного сделали таблицу эталонов
Если на PBR есть разногласия, идём в эталоны. Если в эталонах нет подходящего варианта, дополняем.
В итоге у команды всегда есть "линейка" для задач, и эта линейка не привязана ни к одному исполнителю.
во время покера команда что - вообще не учитывает производительность отдельных чуваков?
Не учитывает, у нас есть прогнозируемый велосити команды и приблизительный каждого члена команды. Сама задача должна быть описана так, чтобы любой исполнитель знал что нужно сделать.
Понятно, что условный овнер сервиса сделает задачу быстрее того, кто с ним дела не имел, но это максимум влияет на метрики спринта, на горизонте квартала - это статистическая погрешность.
Ни сложности и времени, а трудоёмкости. Задача может быть не сложной, но потребовать много ресёрча, коммуникации и прочей активности. И она может быть оценена также, как и технически сложная задача.
У вас 2 сеньора, старый делает за спринт 15 SP, на нового закладываете минимум, например, 5 SP. На стоимость задачи в SP это не должно влиять никак.
Но привязки ни к исполнителю, ни к его уровню у вас быть не должно, иначе ваше планирование превращается в хаос. Как вы будете считать капасити квартала, если у вас одна и та же задача для Jun будет 8, а для Sen будет 3?
Вы смотрите ретроспективно предыдущий период и видите там, что команда выполнила 180 SP - это оценка по какому исполнителю?
В SP можно учитывать многое, это решается на уровне команды, но не исполнителя, от него задача должна быть отвязана.
Нет, ровно наоборот. Оценка задачи в SP не должна зависеть от исполнителя, но сеньор выполняет больше SP, чем джун. При этом оценка одной и той же задачи может меняться со временем.
Другие ребята написали Note Companion, и он функциональнее и интереснее. Кроме "общения с заметками", например, можно кидать быструю заметку в inbox, а плагин по тексту сам поймет, к чему она относится, и перенесет в соответствующую директорию. Или может разметить ее тегами и переименовать, или привести к определенному формату и т.п.
Я бы сказал, что когда ты видишь цифры, это уже оказывает психологическое давление и начинает работать. Да и вы же сами понимаете, что между купить жене цветы за 10к и не купить вообще есть ещё диапазон от 0 до 10к.
Пользуюсь Whispering, работает отлично
Имхо, будущее за той компанией, которая даст больше прикладного результата пользователям. А здесь Google на голову впереди всех конкурентов. У него одного фактически сейчас возможность интегрировать LLM в большую часть областей жизни/работы: Android (и Pixel в частности), браузер, почта, Docs/Sheets, Drive, Cloud, поиск и уйма чего ещё.
18 принципов как не допускать оверинжиниринг - это не оверинжиниринг?
Верно ли, что раньше TL, допустим, пришедший с рынка, мог вырасти в DL, допустим, за 2 цикла перф ревью (1 год), а теперь этот маршрут стал в среднем в 2 раза длиннее?
M2 > M3 вероятно остаётся таким же. Но М1 > М3 или М2 > М4 уже точно затянется на пару лет. А М1 > М4 на все несколько.
ИИ-комменты теперь и на Хабре?
Не понял один момент - первая половина статьи про CIO, во второй уже больше употребляется CTO. А на одном изображении есть сразу обе аббревиатуры. Но это же разные роли и ожидания от них разные.
Кейс из практики.
На сервис А налили так много трафика, что перестала выдерживать его зависимость Б (сам сервис А нагрузку держал). На клиентах сервиса А были выставлены низкие таймауты, поэтому клиенты начали рвать к нему коннекты. Разрыв коннекта -> ретрай. Между сервисами был включен mTLS, у каждого был Envoy в виде сайдкара для межсервисной авторизации, rate limiting и прочего. И вот из-за хендшейков CPU у Envoy уперлось в лимит, из-за чего не доходило даже до проверки токенов в бакете рейт лимитера.
А у Яндекса нет платформы, где можно посмотреть зависимости между сервисами?
Отличная статья, спасибо. Идея концептуально прикольная, не встречал раньше в других языках с GC
Команда 1 TL + 7 dev, пишем на Python + Go, проблем нет. Задачи следующего спринта всегда прогрумлены на 90%, остаётся догрумить "влёты". Оценённый беклог колеблется от 4 до 5 спринтов.
Непонятно только за что минусят мои комментарии без каких-либо аргументов :)
Спасибо Вам за перевод и дополнение, из этого цикла статей уже можно делать учебник 👍
Расскажу как сделано у меня в команде.
Мы оцениваем задачи всей командой дважды в неделю по часу. В среднем в беклоге есть оценённых задач на 5 спринтов вперёд.
Сначала у нас была проблема - мы ужались до того, что все задачи укладывались в 1-3 SP. Мы провели аффинную оценку:
я вытащил из беклога 50 выполненных задач, то есть известных команде
сделал на доске (любой аналог Miro) несколько столбцов
всей командой двигали задачи туда-сюда, оценивая их относительно друг друга -> задачи отсортировались по сложности
выделили что-то общее у задач в каждом столбце
дальше на столбцы натянули стори поинты
из полученного сделали таблицу эталонов
Если на PBR есть разногласия, идём в эталоны. Если в эталонах нет подходящего варианта, дополняем.
В итоге у команды всегда есть "линейка" для задач, и эта линейка не привязана ни к одному исполнителю.
Не учитывает, у нас есть прогнозируемый велосити команды и приблизительный каждого члена команды. Сама задача должна быть описана так, чтобы любой исполнитель знал что нужно сделать.
Понятно, что условный овнер сервиса сделает задачу быстрее того, кто с ним дела не имел, но это максимум влияет на метрики спринта, на горизонте квартала - это статистическая погрешность.
Ни сложности и времени, а трудоёмкости. Задача может быть не сложной, но потребовать много ресёрча, коммуникации и прочей активности. И она может быть оценена также, как и технически сложная задача.
У вас 2 сеньора, старый делает за спринт 15 SP, на нового закладываете минимум, например, 5 SP. На стоимость задачи в SP это не должно влиять никак.
Как писал выше - трудоёмкости:
Выше сложность -> больше SP
Больше коммуникации -> больше SP
Больше неопределённости -> больше SP
и т.д.
Но привязки ни к исполнителю, ни к его уровню у вас быть не должно, иначе ваше планирование превращается в хаос. Как вы будете считать капасити квартала, если у вас одна и та же задача для Jun будет 8, а для Sen будет 3?
Вы смотрите ретроспективно предыдущий период и видите там, что команда выполнила 180 SP - это оценка по какому исполнителю?
В SP можно учитывать многое, это решается на уровне команды, но не исполнителя, от него задача должна быть отвязана.
А в целом, при каких условиях вы готовы разрешить сотрудникам использовать такой инструментарий?
Вы в банке готовы разрешить сотрудникам пользоваться инструментами, которые неизвестно куда выгружают ваш код?
Потому что инструментов с открытым кодом, позволяющих использовать собственные модели, меньше на порядок.
Нет, ровно наоборот. Оценка задачи в SP не должна зависеть от исполнителя, но сеньор выполняет больше SP, чем джун. При этом оценка одной и той же задачи может меняться со временем.
Автор же написал, что это результат А/Б-теста. Как тогда подтвердить?
Другие ребята написали Note Companion, и он функциональнее и интереснее. Кроме "общения с заметками", например, можно кидать быструю заметку в inbox, а плагин по тексту сам поймет, к чему она относится, и перенесет в соответствующую директорию. Или может разметить ее тегами и переименовать, или привести к определенному формату и т.п.
https://www.notecompanion.ai/
Я бы сказал, что когда ты видишь цифры, это уже оказывает психологическое давление и начинает работать. Да и вы же сами понимаете, что между купить жене цветы за 10к и не купить вообще есть ещё диапазон от 0 до 10к.