Многие фреймворки по дефолту выдают зарестрикченный Cache-Control (no-cache, maxage:0). То есть в такой парадигме — дать закешировать ответ — специальное телодвижение. Мне такой подход ближе
По поводу умных проксей — чаще всего решение — это просовывать Cache-Control даже для ошибок. Понятно, что «кривых» имплементаций полно, но тут кодами это не решить
Проблема, с которой мы столкнулись при попытке использовать code-first подход к сваггеру — это не удобство обсуждения и согласования планируемых изменений между разными частями организации. По итогу делаем сначала сваггер (спека), а код ее реализует.
Обычно аренда на годовом контракте — так просто не пошлешь (либо в конце года, либо с расходами). Ну, конечно, кроме случая когда все заранее перед арендой проговорено
Ну тут, скорее, даже не с точки зрения убеждения заказчика (предположим, что у нас полное доверие), а скорее как бы радостно не продолбить даты увлекаясь планированиями пары спринтов вперед
А как оно натягивается на сценарий «огромный скоуп — фиксированная дата»? Понятно, что кейс ужасный для любой методологии, но в дикой природе постоянно встречается. Типичный пример- партнерское соглашение с уже подписанной датой и обязательствами сторон. Ну, то есть, инкрементально деливерить можно сколько угодно, но пока все не сделано value=0.
Open source — это волонтерство\благотворительность\хобби, если хотите. Очень мало компаний, цель которых — это OS, чаще всего, это всего-лишь средство достижения цели (цель все еще прибыль). И даже таких компаний меньшинство, в сравнении с классической пропиретарщиной.
Я не думаю что стоит смешивать благотворительность с коммерческой деятельностью — это очень разные парадигмы и обычно для волонтеров это не основной источник дохода
Конечно, можно и за полчаса. Можно и за 5 секунд. У меня был конкретный процесс, который происходил за 10-20 дней, стал происходить за 4 дня. Для меня очевидно, что производительность в разы увеличилась, причем именно после перехода на аджайл.
Вам очевидно, условному Васе — нет. Это должно быть измеримо и очевидно всем. Количество дней на деливери — метрика хорошая, но недостаточная.
Если что-то работает не как надо, «теперь мы делаем по-другому» — достаточная метрика.
Слушайте, ну мы же тут про инженерию говорим все-таки. Соответственно постановка задачи «болит тут на 8 из 10», затем гипотеза «внедрение смузи-аджайла позволит сделать менее больно без угрозы качеству», результат «болеть стало на 3 из 10 и ноги не отвалились». Альтернативный результат — «тут больше не болит, но голова отвалилась». То что я вижу — внедряют чтобы внедрить, попутно круша все вокруг, а результат замылен.
Я рассказал, что у меня болело, и как лично я дошел от «на фига я в это ввязался» до «хорошо, что мы этим занялись»
Да я не лично про вас, если что. Не принимайте, пожалуйста, близко к сердцу. Просто пример разбираю на основе своего опыта и делюсь своим взглядом, если кому интересно.
Количественный — время выкатки нового лендинга. Пока оно уменьшилось с 10-20 рабочих дней до 4, я вижу, что можно уменьшить до 2
Можно и за пол часа. При этом неплохо бы мерять как много изменений случилось, как много проблем нашли и какой MTTR при этом.
И качественный — от «работаем по шаблону» мы перешли к «проверяем гипотезы».
И в чем тут метрика привязанная к качеству продукта? Как раз пример плохой, «эфимерной» метрики, как мне кажется. «Теперь мы делаем по-другому!» — галочка.
Все ерунда пока нет четких критериев, чем изменение процесса улучшило ситуацию, как мне кажется. Заодно и скептиков убедить проще будет. Иначе «восторженные дурачки» продолжат что-то делать и выдавать это под соусом улучшения. Естественно, эфимерного. Можно усугубить отсутствием KPI на доставку по вкусу.
«Стоимость» работника — это, скорее про стоимость замены работника, чем про стоимость работы, которую он выполняет. Наверняка есть какая-то корреляция и со стоимостью работы, но она вряд ли основная
Особенно круто нанять скрам-мастера, который налаживает процессы, но никак не отвечает за результат работы команды. Просто вершина успеха, как мне кажется.
Вроде как аллергии не входят в список повышенных рисков www.cdc.gov/mmwr/volumes/69/wr/mm6915e3.htm#T1_down
Я не думаю что стоит смешивать благотворительность с коммерческой деятельностью — это очень разные парадигмы и обычно для волонтеров это не основной источник дохода
Дальше можно не читать. Кошелек дяди-владельца=«высокая цель». Ок
Есть вероятность, что вернут
Вам очевидно, условному Васе — нет. Это должно быть измеримо и очевидно всем. Количество дней на деливери — метрика хорошая, но недостаточная.
Слушайте, ну мы же тут про инженерию говорим все-таки. Соответственно постановка задачи «болит тут на 8 из 10», затем гипотеза «внедрение смузи-аджайла позволит сделать менее больно без угрозы качеству», результат «болеть стало на 3 из 10 и ноги не отвалились». Альтернативный результат — «тут больше не болит, но голова отвалилась». То что я вижу — внедряют чтобы внедрить, попутно круша все вокруг, а результат замылен.
Да я не лично про вас, если что. Не принимайте, пожалуйста, близко к сердцу. Просто пример разбираю на основе своего опыта и делюсь своим взглядом, если кому интересно.
Можно и за пол часа. При этом неплохо бы мерять как много изменений случилось, как много проблем нашли и какой MTTR при этом.
И в чем тут метрика привязанная к качеству продукта? Как раз пример плохой, «эфимерной» метрики, как мне кажется. «Теперь мы делаем по-другому!» — галочка.