Комментарии на: Офисное дизайнерское: удалённый офис http://blog.nundesign.com/%d0%be%d1%84%d0%b8%d1%81%d0%bd%d0%be%d0%b5/2008/04/distributed-office/ Fri, 09 Sep 2011 10:49:02 +0000 hourly 1 http://wordpress.org/?v=3.2.1 От: Блог NunDesign » Blog Archive » CSS Naked Day в поддержку веб-стандартов http://blog.nundesign.com/%d0%be%d1%84%d0%b8%d1%81%d0%bd%d0%be%d0%b5/2008/04/distributed-office/#comment-1459 Блог NunDesign » Blog Archive » CSS Naked Day в поддержку веб-стандартов Wed, 09 Apr 2008 09:46:33 +0000 http://blog.nundesign.com/office/2008/04/distributed-office/#comment-1459 [...] арт-директора, о котором я немного писала в заметке про офисное дизайнерское и удалённый (в смысле отдалён..., кажется, с формулировкой “за отвратительный [...] [...] арт-директора, о котором я немного писала в заметке про офисное дизайнерское и удалённый (в смысле отдалён…, кажется, с формулировкой “за отвратительный [...]

]]> От: Scratch http://blog.nundesign.com/%d0%be%d1%84%d0%b8%d1%81%d0%bd%d0%be%d0%b5/2008/04/distributed-office/#comment-1458 Scratch Mon, 07 Apr 2008 02:18:26 +0000 http://blog.nundesign.com/office/2008/04/distributed-office/#comment-1458 Это не пути развития проекта, это точки синхронизации. То есть в любом случае проект синхронизируется. Но в этих трех случаях идет либо синхронизация по времени, либо по задачам. Кстати, первый вариант (синхронизация по времени) хорош когда нужен быстрый фидбек... Но часто не подходит. Например, в моей практике был заказчик, который выходил в онлайн примерно в 12 ночи (по нашему местному) и исчезал ровно в восемь утра. Это было очень неудобно, с учетом того что тот PM который вел проект, также вел другой проект, на этот раз уже с другим временным промежутком... А сделать "по третьему варианту" просто не получалось -- для получения фидбека или любых комментариев заказчика приходилось слегка подпинывать... Как это разрулилось, к сожалению, не знаю (судя по всему -- никак, сначала ушел я, потом упомянутый PM). Это не пути развития проекта, это точки синхронизации.
То есть в любом случае проект синхронизируется. Но в этих трех случаях идет либо синхронизация по времени, либо по задачам.
Кстати, первый вариант (синхронизация по времени) хорош когда нужен быстрый фидбек… Но часто не подходит. Например, в моей практике был заказчик, который выходил в онлайн примерно в 12 ночи (по нашему местному) и исчезал ровно в восемь утра.
Это было очень неудобно, с учетом того что тот PM который вел проект, также вел другой проект, на этот раз уже с другим временным промежутком…

А сделать “по третьему варианту” просто не получалось — для получения фидбека или любых комментариев заказчика приходилось слегка подпинывать… Как это разрулилось, к сожалению, не знаю (судя по всему — никак, сначала ушел я, потом упомянутый PM).

]]> От: Anton Naumov http://blog.nundesign.com/%d0%be%d1%84%d0%b8%d1%81%d0%bd%d0%be%d0%b5/2008/04/distributed-office/#comment-1457 Anton Naumov Fri, 04 Apr 2008 20:30:05 +0000 http://blog.nundesign.com/office/2008/04/distributed-office/#comment-1457 я вижу всего три пути развития проекта в распределенной команде. все три кем-то применяются на практике, но не факт, что подойдут у тебя. 1) снихронизация по времени -- это переход на американское время полностью или частично. так работает, к примеру, DBBest. в данном случае хорошо заказчикам и "совам". на сколько у вас это подойдет, не знаю. я например не стану работать в таком режиме, во всяком случае дольше месяца точно не стану. 2) синхронизация по релизам -- четкая формализация событий релиза. и если таковая произойдет, то все что происходит <strong>после</strong> или <strong>в непосредственной близости</strong> от дедлайна автоматически относится к следующему релизу. это наверное самая лучшая схема и именно по ней я сейчас работаю. у нас код-фриз делают за неделю до выпуска в продакшин. можно сократить до 3 дней, но неделя -- это хорошо. 3) детализация тасков до однодневной/однонедельной. одна из ХР практик, когда билд стоится постоянно. т.е. вы должны к концу рабочего дня/рабочей недели выдать на гора некий результат дневного труда. ваши канадские коллеги в течении своего рабочего дня эти результаты посмотрят, сделают замечания и спустят их обратно. в теории должно работать. на практике, есть очень большой риск не своевременного фидбэка. я вижу всего три пути развития проекта в распределенной команде. все три кем-то применяются на практике, но не факт, что подойдут у тебя.
1) снихронизация по времени — это переход на американское время полностью или частично. так работает, к примеру, DBBest. в данном случае хорошо заказчикам и “совам”. на сколько у вас это подойдет, не знаю. я например не стану работать в таком режиме, во всяком случае дольше месяца точно не стану.
2) синхронизация по релизам — четкая формализация событий релиза. и если таковая произойдет, то все что происходит после или в непосредственной близости от дедлайна автоматически относится к следующему релизу. это наверное самая лучшая схема и именно по ней я сейчас работаю. у нас код-фриз делают за неделю до выпуска в продакшин. можно сократить до 3 дней, но неделя — это хорошо.
3) детализация тасков до однодневной/однонедельной. одна из ХР практик, когда билд стоится постоянно. т.е. вы должны к концу рабочего дня/рабочей недели выдать на гора некий результат дневного труда. ваши канадские коллеги в течении своего рабочего дня эти результаты посмотрят, сделают замечания и спустят их обратно. в теории должно работать. на практике, есть очень большой риск не своевременного фидбэка.

]]>