Интересно было бы разобрать такой вопрос:
Что именно подразумевается под задержкой(пингом) от игрока до сервера в статьях и в целом в индустрии. Является ли это число в мc разницей между отправкой и получением ICMP пакета от игрока до сервера, или же всегда подразумевается задержка, с кототорой отправляются UDP пакеты с полезной игровой информацией от игрока до сервера в одну сторону?
Влияет ли как-то количество отображаемых FPS у клиента на получение более свежего состояния мира от сервера до этого клиента?
спасибо большое. еще вопрос — нет же никаких способов синхронизировать букмейт с kindle? а то после настройки синхронизации между телефоном и ридером для контента на амазоне жить стало гораздо лучше и веселее.
плохо только, что контент там «разный»
сейчас есть куча вариантов, чтобы конвертить fb2 в mobi, который киндл легко понимает. Я использую Calibre — вопросов нет, кроме некоторых нюансов при выравнивании русскоязычного текста по ширине )
Я тоже не мегакрут в положительных рисках — так что давай рассуждать.
Если исходить из примеров в статье, то положительный риск — это какие-то действия, которые в случае позитивного исхода принесут выгоду, в случае негативного — убытки. Таким образом, пока риск не сработал — мы получаем выгоду, как только он сработал (к примеру, какие-то проблемы в используемой системе, нехватка знаний и тд) — мы начинаем нести убытки.
Так что все по-прежнему, mitigation может быть направлена на уменьшение likelihood (примером такой стратегии может быть проведение курсов и обучения персонала использованию новой системы или фреймворка, детальное исследование используемой библиотеки, и тд) и перевернутости нет.
Давай попробуем рассмотреть пример 2 из статьи
Была сделана оценка, согласно которой необходимо 6 месяцев, чтобы закончить проект среднего размера. Мы можем закончить проект раньше, если использовать методологию Экстремального программирования. При этом, первый билд будет доставлен заказчику через 3 месяца, остальные — каждый месяц. Однако, при таком подходе существует риск, что данная методология не сработает для этого проекта, либо что проектная команда будет сопротивляться изменениям, что повлечет задержки в проекте.
В данном случае риском у нас является использование методологии разработки, которая может быть недостаточно знакома команде, либо она может не нравиться команде, либо еще что-то…
Если все пройдет гладко, то проект закончится раньше, а риск не сработает. Если же нет (риск сработал) — у нас будут потери в виде затрат времени, больших первоначальной оценки в 6 месяцев.
Таким образом mitigation strategy должна минимизировать вероятность срабатывания риска — можно проводить тренинги с командой на предмет улучшения знаний по принятой методологии, проактивный менеджмент проекта, который будет отслеживать малейшие колебания в команде и тд. Contingency plan в данном случае также не будет отличаться от обычных рисков — то есть будет направлен на уменьшение негативных последствий.
Спасибо за ссылку — я ее не смог найти при подготовке статьи, хотя очень хотел ;)
Насчет базы данных проектов и рисков — у нас в компании такие ведутся:
Project Management office — набор инструментов для управления проектом, интеграция с джира, круиз контролом и SVN
business intelligence — сбор и анализ метрик
Что именно подразумевается под задержкой(пингом) от игрока до сервера в статьях и в целом в индустрии. Является ли это число в мc разницей между отправкой и получением ICMP пакета от игрока до сервера, или же всегда подразумевается задержка, с кототорой отправляются UDP пакеты с полезной игровой информацией от игрока до сервера в одну сторону?
Влияет ли как-то количество отображаемых FPS у клиента на получение более свежего состояния мира от сервера до этого клиента?
спасибо! )
плохо только, что контент там «разный»
X1
ну почти, но все равно неплохо! ;)
+1 ;)
Я тоже не мегакрут в положительных рисках — так что давай рассуждать.
Если исходить из примеров в статье, то положительный риск — это какие-то действия, которые в случае позитивного исхода принесут выгоду, в случае негативного — убытки. Таким образом, пока риск не сработал — мы получаем выгоду, как только он сработал (к примеру, какие-то проблемы в используемой системе, нехватка знаний и тд) — мы начинаем нести убытки.
Так что все по-прежнему, mitigation может быть направлена на уменьшение likelihood (примером такой стратегии может быть проведение курсов и обучения персонала использованию новой системы или фреймворка, детальное исследование используемой библиотеки, и тд) и перевернутости нет.
Давай попробуем рассмотреть пример 2 из статьи
В данном случае риском у нас является использование методологии разработки, которая может быть недостаточно знакома команде, либо она может не нравиться команде, либо еще что-то…
Если все пройдет гладко, то проект закончится раньше, а риск не сработает. Если же нет (риск сработал) — у нас будут потери в виде затрат времени, больших первоначальной оценки в 6 месяцев.
Таким образом mitigation strategy должна минимизировать вероятность срабатывания риска — можно проводить тренинги с командой на предмет улучшения знаний по принятой методологии, проактивный менеджмент проекта, который будет отслеживать малейшие колебания в команде и тд. Contingency plan в данном случае также не будет отличаться от обычных рисков — то есть будет направлен на уменьшение негативных последствий.
Надеюсь, что не сумбурно изложил… ;)
Обзор в целом неплох, но очень хочется увидеть своими глазами…
Книг, переведенных на русский язык я не встречал — только источники на английском да свои соображения ;)
Насчет базы данных проектов и рисков — у нас в компании такие ведутся:
Project Management office — набор инструментов для управления проектом, интеграция с джира, круиз контролом и SVN
business intelligence — сбор и анализ метрик
Непонятно, где конкретно заблуждение…
Поясните?! ;)
Софта пока нету даже в планах — риски планируем в экселе с ручным переносом в проектные планы.
Кстати, это идея — можно еще описать особенности планирования и отслеживания рисков в плане проекта с помощью MS Project. Запланирую на будущее ;)