Еще стоит сказать про гранулярность времени. Оценка всегда дается в часах и кратно часу. Не бывает оценок 8 часов 23 минуты. Округление всегда вверх. Задач меньше чем на 1 час не бывает. За редким исключением. Например, поменять текст у кнопки — 30 минут. Не 1 и не 10, а не меньше 30. Задач больше 40 часов не бывает…
Да, время на коммуникацию тоже оплачивается тоже… Т.е. после каждого скайп чата можно смело писать в систему трекинга времени — standup 0.5h.
Да, так я работаю в самоорганизующейся команде, которая состоит из ответственных и опытных разработчиков, которых не надо гонять палкой. Менеджера или Тимлидера с нашей стороны нет. Кастомер сам рулит нами ненавязчиво. Да, кстати, раз я уже заговорил про цифры, то скажу что их менеджер в час стоит 90 EUR… Это если кто-то задается вопросами ценообразования…
Работаю так с голландской компанией более 5 лет. Они научили меня многому. Вкратце, все действительно как описал автор и это работает отлично. Более того, они (мой customer) другого пути взаимодействия не приемлют. Они приходят ко мне с большим проектом, но не отдают его сразу целиком. Они сами разбивают его на user story. Сами выделяют tasks в user story. Я только даю свой estimate. Они либо соглашаются с ним, либо нет. Если не соглашаются, то я им делаю work break down c estimate по каждому пункту. В этом случае они лишний раз убеждаются что я их не обманываю и это перерастает в нерушимое доверие. Они платят только за prefect часы. Им это выгодно потому что они не платят за мой простой. Им это выгодно потому что они подрядчики, а я субподрядчик. Часы которые я им выставил в качестве estimate, они выставляют своему customerу и получают за это также пропорционально часам или больше, я не знаю, может они и увеличивают. Для сравнения, их час стоит 60EUR. Мой в разы меньше. Все счастливы. Но если я делаю проект для них, то тоже все хорошо, потому что они мне верят и час для их проекта стоит чуть меньше, потому что я понимаю что они тут платят из своего кармана, а свои деньги всегда считаешь.
С ними работать не просто. Каждый день standup. Три вопроса — что сделал, что собираюсь делать, есть ли проблемы. Все это по скайпу текстом. Разговор отбирает больше времени. Все отработано так чтобы время тратилось эффективно. На болтовню редко уходит больше 30 минут, но никогда больше 1 часа.
Мне кажется это отличная схема для честных отношений. Она позволяет защитить и интересы разработчика и интересы заказчика. Заказчик знает за что платит, а разработчик учится давать точные с определенной вероятностью оценки, которые позволяют ему включить и тестирование и риски и никуда не спешить и не вгонять себя в стресс. При такой схеме работы по выходным не случается, переработок тоже. А если хочешь подработать или сил много, то пожалуйста, начинай раньше, заканчивай позже. При этом ты знаешь что получишь процентов на >50% больше… Мотивация хорошая…
>>>… иначе страница будет загружаться через раз, так как в ответе 304 не было указано Last-Modified. Такое поведение было замечено за FF3.
Я столкнулся с подобной проблемой. Но у меня это отражается на картинках. Вкратце, я делаю поддержку тем для веб-приложения. Чтобы иметь возможность переключать тему «на лету» я добавил опции кэширования. Пока тема прежняя сервер для всех картинок и css отвечает 304, как только тема меняется, серве отвечает 200 меняя last modified timestamp и etag. Плюс я использую «Cache-Control»: «public, must-revalidate». Работает в Chrome, IE, Safari. В FF 3 работает «частично». Проблема в следующем. В приложении есть Табы, которые состоят из 3-х картинок — левая часть, правая часть, бэкграунд. Так вот Табов больше одного, соответственно одинаковых ссылок на одни и те же картинки столько же сколько и Табов. Так вот FF 3 обновляет картинки Табов не для всех Табов, причем LiveHTTPHeaders и Fiddler показывают что сервер работает правильно — отдает «свежую» картинку. Но FF 3 обновляет не все Табы :(( Такое ощущение что есть проблема в синхронизации. Например, FF одновременно шлет несколько запросов на одну и ту же картинку. Первый реквест получает 200 респонс. Следующий реквет уже получает 304 респонс. Первая картинка обновляется из респонса и кладется в локальны или ин-мемори кэш FF, но при этом успевает вернуться второй ответ с кодом 304, который лезет в кэш и берет еще не обновившуюся картинку %). Если кликнуть по любой ссылке или рефрешнуть страничку, то все обновится правильно, потому что в кэше уже будут лежать «свежие» картинки.
Помогите кто может советом, очень хочется побороть эту траблу?
Практически все браузеры (ручаюсь за FF2-3 и IE7-8) отлично все кэшируют, если им правильно сказать как они должны это делать. Например,
Cache-Control: «public, must-revalidate» (говорит о том, что можно кэшировать, но при этом надо валидировать)
Expires: -1 (говорит о том что ресурс устарел и его надо проверить, но не всем браузерам это обязательно говорить)
Last-Modified: дата (на основании этого сервер шлет либо 200 OK, либо 304 Not Modified)
Кроме того, если использовать строгий валидатор ETag, то его одного уже будет достаточно, чтобы все работало без всяких лишних инструкций/заголовков в response.
Рандомные числа — это что-то вроде «хака». Но честно говоря, разобраться в RFC 2616 сложнее, чем быстренько все имплементировать с помощью этого простого «хака».
Да, время на коммуникацию тоже оплачивается тоже… Т.е. после каждого скайп чата можно смело писать в систему трекинга времени — standup 0.5h.
С ними работать не просто. Каждый день standup. Три вопроса — что сделал, что собираюсь делать, есть ли проблемы. Все это по скайпу текстом. Разговор отбирает больше времени. Все отработано так чтобы время тратилось эффективно. На болтовню редко уходит больше 30 минут, но никогда больше 1 часа.
Мне кажется это отличная схема для честных отношений. Она позволяет защитить и интересы разработчика и интересы заказчика. Заказчик знает за что платит, а разработчик учится давать точные с определенной вероятностью оценки, которые позволяют ему включить и тестирование и риски и никуда не спешить и не вгонять себя в стресс. При такой схеме работы по выходным не случается, переработок тоже. А если хочешь подработать или сил много, то пожалуйста, начинай раньше, заканчивай позже. При этом ты знаешь что получишь процентов на >50% больше… Мотивация хорошая…
Я столкнулся с подобной проблемой. Но у меня это отражается на картинках. Вкратце, я делаю поддержку тем для веб-приложения. Чтобы иметь возможность переключать тему «на лету» я добавил опции кэширования. Пока тема прежняя сервер для всех картинок и css отвечает 304, как только тема меняется, серве отвечает 200 меняя last modified timestamp и etag. Плюс я использую «Cache-Control»: «public, must-revalidate». Работает в Chrome, IE, Safari. В FF 3 работает «частично». Проблема в следующем. В приложении есть Табы, которые состоят из 3-х картинок — левая часть, правая часть, бэкграунд. Так вот Табов больше одного, соответственно одинаковых ссылок на одни и те же картинки столько же сколько и Табов. Так вот FF 3 обновляет картинки Табов не для всех Табов, причем LiveHTTPHeaders и Fiddler показывают что сервер работает правильно — отдает «свежую» картинку. Но FF 3 обновляет не все Табы :(( Такое ощущение что есть проблема в синхронизации. Например, FF одновременно шлет несколько запросов на одну и ту же картинку. Первый реквест получает 200 респонс. Следующий реквет уже получает 304 респонс. Первая картинка обновляется из респонса и кладется в локальны или ин-мемори кэш FF, но при этом успевает вернуться второй ответ с кодом 304, который лезет в кэш и берет еще не обновившуюся картинку %). Если кликнуть по любой ссылке или рефрешнуть страничку, то все обновится правильно, потому что в кэше уже будут лежать «свежие» картинки.
Помогите кто может советом, очень хочется побороть эту траблу?
Cache-Control: «public, must-revalidate» (говорит о том, что можно кэшировать, но при этом надо валидировать)
Expires: -1 (говорит о том что ресурс устарел и его надо проверить, но не всем браузерам это обязательно говорить)
Last-Modified: дата (на основании этого сервер шлет либо 200 OK, либо 304 Not Modified)
Кроме того, если использовать строгий валидатор ETag, то его одного уже будет достаточно, чтобы все работало без всяких лишних инструкций/заголовков в response.
Рандомные числа — это что-то вроде «хака». Но честно говоря, разобраться в RFC 2616 сложнее, чем быстренько все имплементировать с помощью этого простого «хака».