Есть трансляторы с 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, в финтех рынке ЛАТАМа.
Глубины не предполагалось, потому что это только про знакомство с подходом. Оно скорее про то, чтобы задуматься и, возможно, попробовать у себя почелленджить. Для меня этот калькулятор - самый базовый инструмент, чтобы просто сделать быструю диагностику дел в компании.
Спасибо Станислав, мы с вами прекрасно знаем как в стартапе прекрасно работается с отказоустойчивой архитектурой и какие ресурсы были выделены в этом конкретном примере. В условиях ограниченного бюджета и конкретных штатных единиц более подходящим и управляемым оперировать в рамках описанной выше таксономии. Безусловно, вы как более опытный специалист и с опытом внедрения ITIL-а, как более мачурного фреймворка имеете обширный опыт в работе с инцидентами. Было бы здорово поработать с вами в будущем.
Это подмножество обычны метрикик реагирования на сбои, но если у вас есть конкретная NOC-команда - то она может отвечать и работать в рамках этих конкретных метрик. То есть именно они те самые предметные владельцы Response, Acknowledge, Assemble. А не кто-то еще. Это скорее особенность и KPI при такой таксономии отделов.
Блин, у нас часто похоже на воскресный приход)
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, в финтех рынке ЛАТАМа.
Глубины не предполагалось, потому что это только про знакомство с подходом. Оно скорее про то, чтобы задуматься и, возможно, попробовать у себя почелленджить. Для меня этот калькулятор - самый базовый инструмент, чтобы просто сделать быструю диагностику дел в компании.
Так и есть, команда целиком и полностью смотрит 24/7 на алерты, графики, и чат с саппортом. Эта команда под ключ которая этим и занимается.
Спасибо Станислав, мы с вами прекрасно знаем как в стартапе прекрасно работается с отказоустойчивой архитектурой и какие ресурсы были выделены в этом конкретном примере. В условиях ограниченного бюджета и конкретных штатных единиц более подходящим и управляемым оперировать в рамках описанной выше таксономии. Безусловно, вы как более опытный специалист и с опытом внедрения ITIL-а, как более мачурного фреймворка имеете обширный опыт в работе с инцидентами. Было бы здорово поработать с вами в будущем.
Это подмножество обычны метрикик реагирования на сбои, но если у вас есть конкретная NOC-команда - то она может отвечать и работать в рамках этих конкретных метрик. То есть именно они те самые предметные владельцы Response, Acknowledge, Assemble. А не кто-то еще. Это скорее особенность и KPI при такой таксономии отделов.