Здравствуйте, ironwit, Вы писали:

I>Здравствуйте, Spidola, Вы писали:

S>>Позволю себе себя процитировать здесь

Автор: Spidola
Дата: 01.12.04

. Может чего сгодится...
I>Неплохо... Там есть упоминание о том, что не стоит выдавать на гора бумажки о том, "Что я сделал за сегодня". Почему?

Потому что такие мумажки требуются в нескольких случаях:
— когда в команде много народу и требуется общий формат контроля (и формальный процесс контроля по бумажкам уже простроен);
— когда эти "бумажки" имеют фактический вес при распределении благ (например, по ним выплачивается зарплата);
— когда нет возможности переговорить с каждым сотрудником;
— когда нет электронных средств контроля и т.п.

В общем я считаю, что такие бумажки вообще не нужны. Если нужен контроль, то желательно делать это какими-то автоматизированными средствами (например, анализом реализованных Requirements). Да и раздражают эти бумажки людей основательно. А уж в команде, где 3 человека можно всё решить словами или усилиями одного секретаря (читай — роль "администратор проекта").

Здравствуйте, serg_mo, Вы писали:

>Особенность географически распределенной команды состоит в затрудненности общения между членами команды. Но, на мой взгляд, современные технические средства позволяют наладить уровень общения, приемлемый для применения XP. Для непосредственного общения разработчиков могу предложить IRC (его преимущество в обеспечении возможности группового общения в real-time), а для ведения журналов разработки, оформления требований и т. д. — Wiki, как электронную замену карточек.

По-моему, не правильно смешивать XP и распределенную команду. Это понятия как бы из разных опер. Можно в рамках любой методологии работать распределенно.
И позволю себе ложку дегтя в сторону Wiki. В целом Wiki вещь интересная и полезная. Но только причем здесь управление проектом? Wiki предназначена для структурирования информации вообще. А для управления проектами существуют специализированные средства, и все они, видимо, клиент-серверные. Поэтому при использовании правильных средств управления проектом и так называемая распределенная разработка ничем не будет отличается от разработки в офисе. Просто локальная сеть заменяется глобальной интернетовской.
Мы сейчас так и работаем (правда по выделенке unlimited "Стрим" в Москве): в офисе несколько серверов (программных), реализующих функции упправления требованиями, контроля версий, СУБД. И разницы никакой — что дома мы сидим, что в офисе. И соответственно методология процесса разработки произвольная может быть. У нас как бы RUP. Хотя что такое RUP? У каждого он свой.

Здравствуйте, Spidola, Вы писали:

S> Вы отдаляетесь от него. Фактически, вы пытаетесь инкапсулировать в индивидууме несколько ролей и последовательно выступаете в этих ролях. Парное программирование подразумевает размазывание роли по нескольким индивидуумам (конкретно по двум).

Да, именно так я и поступаю — выступаю последовательно в 2 ролях. И это не парное программирование. Я, фактически, не просто отдаляюсь от парного программирования, я подменяю его суррогатом, в некотором роде. А что делать, если в команде нечетное количество человек? Кто-то вынужден работать в одиночку.
И наиболее эффективный способ, до которого мы дошли, был именно в последовательном переключении ролей. Когда программист, находясь в кепке драйвера, чувствовал, что заходит в ступор, он немедленно одевал кепку навигатора. Если и в кепке навигатора он не мог из этого ступора выйти, он кричал "хелп" и вторая пара на время отвлекалась от своей задачи и бросалась к нему на помощь. Как только выход из ступора нахоодился, все продолжали работу.

Еще раз повторюсь — это _не_ парное программирование. И по эффективности такой подход, конечно, уступает парному программированию. Он требует от разработчика большей самодисциплины и внимательности. Но это — тот способ, который позволил нам минимизировать негативное влияние отсутствия полноценного парного программирования.

Не поймите меня неправильно — я не считаю парное программирование несущественной практикой. Наоборот, эта практика очень важна, поскольку она, во-первых, позволяет повысить скорость и качество работы команды, а во-вторых, обеспечивает постоянный обмен знаниями между членами команды и вообще создает благоприятный климат для коммуникации.

Почему тогда я не считаю эту практику ключевой? Большинство практик являются для XP жизненно необходимыми. Уберите планирование — разработка уйдет в хаос. Уберите рефакторинг — забудьте о простом дизайне — забудьте о коротких релизах — забудьте об обратной связи с заказчиком. Но есть ряд практик, невозможность которых можно компенсировать другими средствами. Например , заказчик в команде — если не удается получить реального заказчика себе в команду, его можно "изобрести". Аналогично, на мой взгляд, и с парным программированием. Но, естественно, отсутствие парного программирования придется компенсировать другими средствами. Альтернатива, наверное, будет менее эффективна, но все же возможно будет поддерживать постоянный прогнозируемый темп разработки и сохранить быструю реакцию на изменения требований.

В принципе, опытная сработавшаяся команда ХР может достаточно вольно обращаться с практиками.

Написал последнее предложение и надолго задумался. Результатом раздумий было то, что я изменил свое мнение относительно целесообразности применения ХР в данном конкретном случае. Несмотря на то, что я все же считаю, что распределенная команда — не помеха для использования ХР, в данном случае, думаю, что попытка его применения не пройдет. Именно потому, что потребуется адаптация "чистого ХР". Новичкам в этой методологии я бы не рекомендовал заниматься этим — очень много шансов наделать ошибок из-за осутствия опыта.

В данной ситуации, думаю, подойдет методология, уже готовая для распределенной команды.

Да и вообще, Spidola прав — выбирать процесс надо исходя из требований реальной ситуации. Это я тут бросился защищать ХР из-за заявления, что в распределенной среде ХР не применимо. Сорри, погорячился

S>>>Ключевые параметры модели только убирать нельзя — модель перестаёт поддаваться управлению (анализу сроков и т.п.). Так что брать XP и убирать парное программирование — не советую.

S>Я, конечно, не адепт XP, но насколько я читал — парное программирование суть одно из "основных правил XP"... Вот тут, например, даже схемка есть, где парное программирование визуально в центре модели изображено.

Парное программирование называют основным правилом ХР, потому что в ХР это — основной способ рабочего общения программистов. Но если вы его уберете и грамотно заполните образовавшийся пробел, модель все же останется управляемой и дух ХР не пострадает.

Кстати, приведенная картинка группирует практики по другому принципу. Внеший слой составляют практики, относящиеся к общению с заказчиком, средний — к отношениям между разработчиками в команде, и внутренний — к собственно процессу кодирования. Она не отражает взаимного влияния практик. Такая картинка приведена в книге Бека "XP Explained".

Здравствуйте, segeyros, Вы писали:

S>По-моему, не правильно смешивать XP и распределенную команду. Это понятия как бы из разных опер. Можно в рамках любой методологии работать распределенно.

Ну, все-таки ХР в своем "каноническом" виде малопригодно для распределенной разработки — упор делается на постоянную и очень тесную коммуникацию разработчиков.

S>И позволю себе ложку дегтя в сторону Wiki. В целом Wiki вещь интересная и полезная. Но только причем здесь управление проектом? Wiki предназначена для структурирования информации вообще. А для управления проектами существуют специализированные средства, и все они, видимо, клиент-серверные.

Я исходил из принципа "The simplest thing possible". Мой коллега в своей команде применял Wiki для координации разработчиков и заказчика, и я имел аналогичный опыт. И мне, и ему Wiki хватало за глаза, работать с ней было просто и удобно. Да и обмен информацией получался менее формальный.


S>Мы сейчас так и работаем (правда по выделенке unlimited "Стрим" в Москве): в офисе несколько серверов (программных), реализующих функции упправления требованиями, контроля версий, СУБД. И разницы никакой — что дома мы сидим, что в офисе. И соответственно методология процесса разработки произвольная может быть. У нас как бы RUP. Хотя что такое RUP? У каждого он свой.

Тогда посоветуй ребятам (см. начальный пост). Возможно, это то, что им нужно.

Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, ironwit, Вы писали:

I>>Здравствуйте, Spidola, Вы писали:

S>>>Позволю себе себя процитировать здесь

Автор: Spidola
Дата: 01.12.04

. Может чего сгодится...
I>>Неплохо... Там есть упоминание о том, что не стоит выдавать на гора бумажки о том, "Что я сделал за сегодня". Почему?

S>В общем я считаю, что такие бумажки вообще не нужны. Если нужен контроль, то желательно делать это какими-то автоматизированными средствами (например, анализом реализованных Requirements). Да и раздражают эти бумажки людей основательно. А уж в команде, где 3 человека можно всё решить словами или усилиями одного секретаря (читай — роль "администратор проекта").
Ясно, спасибо. В этом полностью с тобой согласен

I>>Типа пример ТЗ, как 3 человекам контролировать процесс разработки...
S>Позволю себе себя процитировать здесь

Автор: Spidola
Дата: 01.12.04

. Может чего сгодится...
Вот ещё бы это в статью оформить

Здравствуйте, Dog, Вы писали:

I>>>Типа пример ТЗ, как 3 человекам контролировать процесс разработки...
S>>Позволю себе себя процитировать здесь

Автор: Spidola
Дата: 01.12.04

. Может чего сгодится...
Dog>Вот ещё бы это в статью оформить

А оно того стоит?

Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, Dog, Вы писали:

I>>>>Типа пример ТЗ, как 3 человекам контролировать процесс разработки...
S>>>Позволю себе себя процитировать здесь

Автор: Spidola
Дата: 01.12.04

. Может чего сгодится...
Dog>>Вот ещё бы это в статью оформить

S>А оно того стоит?
Стоит, стоит. Много нового узнал, а со статьи еще больше узнаю...