Есть трансляторы с CUDA на свою технологию, но Nvidia из-за этого судится. Ну и как бы большинство компаний под ограничениями или санкциями, так что им даже не дадут интегрироваться нормально.
Логика такая: H100 это де факто самый массовый GPU на рынке и по нему удобнее сравнивать - так как ты сравниваешь с базовым рыночным решением (а не премиумом, который ему сейчас H200).
Если с 200й сравнивать, там разрыв космически растет :)
Если я правильно понял, то как раз в примере, где сравнивались для небольшого проекта SP / Issue Count, оказался Issue Count точнее.
Но я опять повторю, что прогноз надо постоянно обновлять потому что динамика работы команды может сильно поменяться (зависимости, болезни, увольнения, инфра, ...) - поэтому каждый спринт (минимум) мы должны итерировать прогноз, чтобы после этого его обновлять и коммуницировать со стейкхолдерами.
Это всегда так. Именно поэтому мы обновляем прогноз каждую итерацию (раз в две недели, например). Мы можем построить прогноз на throughput + wip + Lead Time (в predictable.team есть epic forecasting в Monte Carlo, там можно тыкнуть на +1 эпик и наполнить его в соответствии с вашими задачами. Тогда разброс в прогнозе будет учитывать одновременное историческое количество элементов в работе + параллельную работу + Lead Time и 50 и 85 перцентилей). Тогда ваша историческая информация о времени завершения задач будет учитывать и хвосты.
Это если у вас тендеры и аутсорс, наверное? Взаимоотношения между компаниями, предоставляющими и потребляющими услуги всегда разные. Звучит как совсем другая (хоть и очень наболевшая) проблема :)
Но мы тут говорим что прогноз первоначальный всегда надо обновлять, просто есть стат данные в не-аутсорс компаниях что на основе этой метрики считать честнее и корректнее.
А так - всегда есть миллион факторов, которые влияют на прогнозы, потому и обновляем. Также как в метеорологии первоначальные прогнозы никогда не сбываются, и они дают их с уверенностью в 30%.
В АйТи параметров прогноза меньше, но без обновления все равно никуда.
Титаническая и кропотливая работа) насколько активно те же топы или другой менеджмент пользуется самими дешами? Если активно, то это в рамках каких-то каденций или самостоятельно по необходимости?
Все верно, именно поэтому стори поинты хороши когда вам надо выровняться.
Но для квартальных и далее планирований стори поинты часто неточны. В том пункте мы говорим про кросс-командную работу - чтобы запланироваться толпой команд вместе, и вовремя выйти в прод. Так как все используют SP по-разному, надежность прогнозов когда именно та или иная команда сделает свой кусок работы низкая.
Опыт написания этого поста как раз вышел из работы в стартапе, и применим к стартапам - это я знаю точно =) Стартапе в Series B, с ~$780kk valuation, в финтех рынке ЛАТАМа.
Глубины не предполагалось, потому что это только про знакомство с подходом. Оно скорее про то, чтобы задуматься и, возможно, попробовать у себя почелленджить. Для меня этот калькулятор - самый базовый инструмент, чтобы просто сделать быструю диагностику дел в компании.
набрел три года спустя на коммент! Это стоило примерно как один senior разработчик на аутсорсе в Индии)
dry в целом можно запихнуть как правило в agents.md, думаю.
Есть уже какие-то заработки и практики, которыми можно было бы поделиться?) круто было б почитать
Блин, у нас часто похоже на воскресный приход)
fixed, спасибо за наблюдение.
а, не так прочел) сорян
Так как китайцы часто сами позиционируют и сравнивают с H100, проще и реалистичнее найти сравнение с ней
Никакой 🙈
Есть трансляторы с CUDA на свою технологию, но Nvidia из-за этого судится. Ну и как бы большинство компаний под ограничениями или санкциями, так что им даже не дадут интегрироваться нормально.
Логика такая: H100 это де факто самый массовый GPU на рынке и по нему удобнее сравнивать - так как ты сравниваешь с базовым рыночным решением (а не премиумом, который ему сейчас H200).
Если с 200й сравнивать, там разрыв космически растет :)
Если я правильно понял, то как раз в примере, где сравнивались для небольшого проекта SP / Issue Count, оказался Issue Count точнее.
Но я опять повторю, что прогноз надо постоянно обновлять потому что динамика работы команды может сильно поменяться (зависимости, болезни, увольнения, инфра, ...) - поэтому каждый спринт (минимум) мы должны итерировать прогноз, чтобы после этого его обновлять и коммуницировать со стейкхолдерами.
Если прям приводить кейсы, то есть вот такой пост https://www.prokanban.org/blog/trustingmcs
https://www.prokanban.org/blog/https-prokanban-org-blog-monte-carlo-simulations-accuracy-and-unplanned-work-a-case-study
+ бложик Мэтт Филипа https://mattphilip.wordpress.com/wp-content/uploads/2018/02/to-estimate-or-not-to-estimate-is-that-the-question_-by-matt-philip.pdf
А, я с радостью погуглю и поизучаю, спасибо. Вы первый, кто дал такой коммент :)
это про UI?
Это всегда так. Именно поэтому мы обновляем прогноз каждую итерацию (раз в две недели, например). Мы можем построить прогноз на throughput + wip + Lead Time (в predictable.team есть epic forecasting в Monte Carlo, там можно тыкнуть на +1 эпик и наполнить его в соответствии с вашими задачами. Тогда разброс в прогнозе будет учитывать одновременное историческое количество элементов в работе + параллельную работу + Lead Time и 50 и 85 перцентилей). Тогда ваша историческая информация о времени завершения задач будет учитывать и хвосты.
Это если у вас тендеры и аутсорс, наверное? Взаимоотношения между компаниями, предоставляющими и потребляющими услуги всегда разные. Звучит как совсем другая (хоть и очень наболевшая) проблема :)
Но мы тут говорим что прогноз первоначальный всегда надо обновлять, просто есть стат данные в не-аутсорс компаниях что на основе этой метрики считать честнее и корректнее.
А так - всегда есть миллион факторов, которые влияют на прогнозы, потому и обновляем. Также как в метеорологии первоначальные прогнозы никогда не сбываются, и они дают их с уверенностью в 30%.
В АйТи параметров прогноза меньше, но без обновления все равно никуда.
спасибо, незаметил :)
Спасибо за интересную статью.
Титаническая и кропотливая работа) насколько активно те же топы или другой менеджмент пользуется самими дешами? Если активно, то это в рамках каких-то каденций или самостоятельно по необходимости?
Наверное, если экстраполировать, он не работает эффективно для абсолютного большинства.
Я согласен с тем, что инструмент не самый простой, и поэтому на масштабе при отсутствии людей которые поддержат процесс он работает плохо.
Все верно, именно поэтому стори поинты хороши когда вам надо выровняться.
Но для квартальных и далее планирований стори поинты часто неточны. В том пункте мы говорим про кросс-командную работу - чтобы запланироваться толпой команд вместе, и вовремя выйти в прод. Так как все используют SP по-разному, надежность прогнозов когда именно та или иная команда сделает свой кусок работы низкая.
Я к тому чтобы не прогнозировать через SP.
Опыт написания этого поста как раз вышел из работы в стартапе, и применим к стартапам - это я знаю точно =) Стартапе в Series B, с ~$780kk valuation, в финтех рынке ЛАТАМа.
Глубины не предполагалось, потому что это только про знакомство с подходом. Оно скорее про то, чтобы задуматься и, возможно, попробовать у себя почелленджить. Для меня этот калькулятор - самый базовый инструмент, чтобы просто сделать быструю диагностику дел в компании.