Причем тут скрам и ТЗ? Проблема совершенно не в этом.
1) Скрам и дедлайн несовместимы. В скраме фича готова, когда команда говорит, что фича готова. Для этого команда работает столько сколько нужно. Если это не так, то у вас не скрам, а бардак.
2) Планирование фичи должно заключаться в проработке User Story. Для Story должны быть как минимум определены сценарии и критерии приемки. Набор сторей и будет ваше ТЗ. Если такого нет, то это не скрам, а бардак.
3) В скраме нужно планировать релизы. Одна итерация перед релизом обычно уделяется на «вылизывание» продукта: устранение дефектов с прошлого релиза, устранение некритичных багов (фичи с критичными багами просто не включаются в релиз) итд. Если такого нет, то это не скрам, а бардак.
4) Если в скраме не удается уложиться в план (итерации, релиза), то всегда жертвуются фичи. Если к релизу недостаточно фич, то надо просто признать фейл, перенести релиз, пересчитать velocity, учесть при планировании следующего релиза и продолжать работать в том же темпе. Никакого форсирования работ не допускается. Если такого нет… ну вы поняли.
Основной фокус скрама — ритмичные релизы, более стабильное получение фидбека и включение его в разработку, создание продукта, максимально удовлетворяющего клиента. Это достигается фактически снижением темпа выпуска фич и закрытия багов.
Если смотреть на треугольник полезность-качество-скорость, то скрам торгует скорость на полезность.
В этом случае будет эффективно все данные пользователя отдавать одним запросом в вид JSON, а потом внедрять в страницу с помощью knockout или аналогичного инструмента. В идеале потом кешировать эти данные так, как в посте.
Но в любом случае все что связано с быстродействием надо измерять.
Если страница и её части 90% времени отдаются из кеша клиента\прокси сервера, то это будет все равно быстрее, чем сколь угодно заоптимизированная страница, отдаваемая серверным кодом. Потому что результат один и тот же (в смысле ответа сервера), а время на передачу данных от сервера клиенту гораздо меньше.
Кеширование HTTP использует в качестве ключа url. Если серверу придется каждый раз отдавать страницу, даже собираемую из кеша на сервере, то это будет в разы медленнее, чем клиент просто будет брать страницу из локального кеша или из кеша прокси-сервера.
Я такое делал когда еще Velocity Cache не стал Windows Server App Fabric. Там это довольно легко сделать через паттерн publish\subscribe, ну и кеш когерентный получается. Но изобретать такое с нуля — проблематично.
CacheDependency можно повесить на произвольную СУБД\веб-сервис? CacheDependency не везде существует.
Если говорим про фронтэнд на HTTP, то там уже все есть. А если нет, то реализация очень нетривиальная. Мне, к сожалению, пришлось прикручивать такой кеш к SOAP вебсервису. Код кеширования (клиент+сервер) в итоге оказался больше, чем код всего веб-сервиса.
Одна и та же сущность может быть закеширована много раз, например в персональных кешах пользователей или просто для разных представлений. Как выяснить какие кеши нужно экспайрить?
Почему не будет? Как приложение узнает что cached пора обновить? Иначе получится что cached заполнится один раз на все время жизни приложения и не будет меняться. Такого, конечно, не бывает.
«Какой-то expire добавить» выливается в объем кода, сравнимый с объемом кода логики приложения.
Можно посчитать. Предположим 1000 пользователей, каждый держит в кеше по 100кб. Объем кеша 50МБ — то есть примерно 50% пользовательских кешей будет влезать. Если все 1000 пользователей запрашивают равновероятно, то матожидание попадания в кеш будет 50%. Это довольно низкий процент. При увеличении количества пользователей эффективность падает. При всплесках нагрузки кеш окажется почти бесполезным.
Этот аццкий псевдокод реализует lazy кеш. Зачастую его даже писать не надо, он во многие фреймворки встроен. Но, по причинам описанным в посте, мало полезен.
А в кешах для каждого юзера сложности нет, но процент попадай в кеш получается низкий, когда юзеров много.
1) Скрам и дедлайн несовместимы. В скраме фича готова, когда команда говорит, что фича готова. Для этого команда работает столько сколько нужно. Если это не так, то у вас не скрам, а бардак.
2) Планирование фичи должно заключаться в проработке User Story. Для Story должны быть как минимум определены сценарии и критерии приемки. Набор сторей и будет ваше ТЗ. Если такого нет, то это не скрам, а бардак.
3) В скраме нужно планировать релизы. Одна итерация перед релизом обычно уделяется на «вылизывание» продукта: устранение дефектов с прошлого релиза, устранение некритичных багов (фичи с критичными багами просто не включаются в релиз) итд. Если такого нет, то это не скрам, а бардак.
4) Если в скраме не удается уложиться в план (итерации, релиза), то всегда жертвуются фичи. Если к релизу недостаточно фич, то надо просто признать фейл, перенести релиз, пересчитать velocity, учесть при планировании следующего релиза и продолжать работать в том же темпе. Никакого форсирования работ не допускается. Если такого нет… ну вы поняли.
Основной фокус скрама — ритмичные релизы, более стабильное получение фидбека и включение его в разработку, создание продукта, максимально удовлетворяющего клиента. Это достигается фактически снижением темпа выпуска фич и закрытия багов.
Если смотреть на треугольник полезность-качество-скорость, то скрам торгует скорость на полезность.
Но в любом случае все что связано с быстродействием надо измерять.
Если говорим про фронтэнд на HTTP, то там уже все есть. А если нет, то реализация очень нетривиальная. Мне, к сожалению, пришлось прикручивать такой кеш к SOAP вебсервису. Код кеширования (клиент+сервер) в итоге оказался больше, чем код всего веб-сервиса.
100кб может быть много для одного запроса, но для нескольких — очень даже мало.
«Какой-то expire добавить» выливается в объем кода, сравнимый с объемом кода логики приложения.
А в кешах для каждого юзера сложности нет, но процент попадай в кеш получается низкий, когда юзеров много.