Скорее всего это связано с тем, что все эти методики очень популярны, известны, но почти никто не умеет их успешно применять. Не достаточно подойти к программисту и спросить - сколько сторипоинтов? 8? Хорошо. И на этом закончить. Но в большинстве случаев все именно так и происходит.
По мне, так самая основная проблема оценки как раз отсутствие методики и требований к ней, чтобы задачу хотя бы пару часов поковыряли, посмотрели проект, что помнят, что не помнят, где коду 5 лет и т.п.
Конечно, заказчикам может не понравиться, если вместо обычного спринта скажут, что теперь эта задача занимает три, но за-то это будут реальные три, а не один с опозданием на два
Спасибо, полностью с вами согласен, метрика «пользовательское счастье» это гораздо более объективная оценка полезности оптимизации. Значит надо уменьшать время загрузки и обработки HTML:
И того, что указано в теге head. Собственно для этого я и решил попробовать разбить JS файлы на более мелкие, иначе время задержки остается огромным даже при кешировании (судя по показателям инспектора). Сейчас вот в поисках того, на чем можно это попробовать, что бы были конкретные цифры, как там на слайдах.
Скорее второе, но как следствие уменьшения трафика – чем больше запомнит браузер пользователя, тем лучше. С одной стороны хочется при безлимитном трафике получать страницу как можно быстрее, а с другой – мобильные версии все больше похожи на приложения и такая оптимизация позволит сохранить в кеш всю визуальную часть, а значит ее можно сделать еще более продвинутой и при этом снизить трафик. Нагрузка на клиента сильно зависит от того, как разбивать JS скрипты и в скольких файлах хранить HTML шаблоны – их же тоже можно подгружать, а значит она должна быть приемлемой.
Демо будет в следующем посте, с подробным разбором и тестами.
Скорее всего это связано с тем, что все эти методики очень популярны, известны, но почти никто не умеет их успешно применять. Не достаточно подойти к программисту и спросить - сколько сторипоинтов? 8? Хорошо. И на этом закончить. Но в большинстве случаев все именно так и происходит.
По мне, так самая основная проблема оценки как раз отсутствие методики и требований к ней, чтобы задачу хотя бы пару часов поковыряли, посмотрели проект, что помнят, что не помнят, где коду 5 лет и т.п.
Конечно, заказчикам может не понравиться, если вместо обычного спринта скажут, что теперь эта задача занимает три, но за-то это будут реальные три, а не один с опозданием на два
И того, что указано в теге head. Собственно для этого я и решил попробовать разбить JS файлы на более мелкие, иначе время задержки остается огромным даже при кешировании (судя по показателям инспектора). Сейчас вот в поисках того, на чем можно это попробовать, что бы были конкретные цифры, как там на слайдах.
Демо будет в следующем посте, с подробным разбором и тестами.