Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

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

D>Прочитал книгу "Экстремальное программирование", :super: возник вопрос — кто-нибудь так работает? :xz: Поделитесь впечатлениями. И много ли контор в Москве где так работают?

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

Daenur wrote:

> Прочитал книгу "Экстремальное программирование", возник вопрос -
> кто-нибудь так работает? Поделитесь впечатлениями. И много ли
> контор в Москве где так работают?
Это не в Москве, а в ионе, но у них тоже эту штуку внедряли. Об этом Стив
Виноски упоминал с статье:
http://www.osp.ru/os/2004/01/059.htm
--
Александр Насонов,
Независимый консультант и разработчик ПО
alnsn-mycop@yandex.ru (для более быстрого ответа удалите -мусор из адреса)

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

S> Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

А что есть тогда "по-нормальному"???
Объясни чайникам, о гуру

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

D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

А ещё было бы интересно узнать и не только про Москву (не только там ведь люди живут...)

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

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

S>> Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

К>А что есть тогда "по-нормальному"???

Я не считаю XP нормальным процессом, потому, что когда я работал в команде, которая кричала: мы проповедуем XP, то я не высыпался, не понимал чем мы вообще занимаемся и чем все это хотя бы приблизительно закончится.. вот и все. Когда у разработчика такие чувства, то назвать процесс нормальным я не решился бы.

К>Объясни чайникам, о гуру :shuffle:

Зачем язвить?

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

S>>> Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

К>>А что есть тогда "по-нормальному"???

S> Я не считаю XP нормальным процессом, потому, что когда я работал в команде, которая кричала: мы проповедуем XP, то я не высыпался, не понимал чем мы вообще занимаемся и чем все это хотя бы приблизительно закончится.. вот и все. Когда у разработчика такие чувства, то назвать процесс нормальным я не решился бы.

Жаль, но дело, наверное, не в XP, а, возможно, в низкой квалификации разработчиков/менеджмента и/или непонимании ими методологии. Или несоответствии XP поставленной задаче. Между заявлениями "мы проповедуем" и эффективным использованием — большая разница.

Здравствуйте, Аноним, Вы писали:

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

S>>>> Я знаю мелкие команды, работающие удаленно, в соновном, на запад. Не могу сказать, что у них это хорошо выходит. Скорее это что-то вроде крика души, от безвыходности, неумения работать по-нормальному или поросто отстутсвия средств.

К>>>А что есть тогда "по-нормальному"???

S>> Я не считаю XP нормальным процессом, потому, что когда я работал в команде, которая кричала: мы проповедуем XP, то я не высыпался, не понимал чем мы вообще занимаемся и чем все это хотя бы приблизительно закончится.. вот и все. Когда у разработчика такие чувства, то назвать процесс нормальным я не решился бы.

А>Жаль, но дело, наверное, не в XP, а, возможно, в низкой квалификации разработчиков/менеджмента и/или непонимании ими методологии. Или несоответствии XP поставленной задаче. Между заявлениями "мы проповедуем" и эффективным использованием — большая разница.

Да. Абсолютно согласен. Думаю, что в этом случае так оно и было. Может быть не все до конца понимают концепий XP и берут только то, что им нравится, в итоге выходит не очень хорошее менение о методологии... Но мнение-то уже складывается. На RSDN уже не раз обсуждалась XP и большинство отзывов было отнюдь не лестных. Оппоненты правда говорят, что люди не понимаю, что же такое XP на самом деле...

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



S> Да. Абсолютно согласен. Думаю, что в этом случае так оно и было. Может быть не все до конца понимают концепий XP и берут только то, что им нравится, в итоге выходит не очень хорошее менение о методологии... Но мнение-то уже складывается. На RSDN уже не раз обсуждалась XP и большинство отзывов было отнюдь не лестных. Оппоненты правда говорят, что люди не понимаю, что же такое XP на самом деле...

А что же такое ХР на самом деле?
Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно! Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.

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

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



S>> Да. Абсолютно согласен. Думаю, что в этом случае так оно и было. Может быть не все до конца понимают концепий XP и берут только то, что им нравится, в итоге выходит не очень хорошее менение о методологии... Но мнение-то уже складывается. На RSDN уже не раз обсуждалась XP и большинство отзывов было отнюдь не лестных. Оппоненты правда говорят, что люди не понимаю, что же такое XP на самом деле...

G>А что же такое ХР на самом деле?

Ты у меня спрашиваешь? :) Я не эксперт... это у Брукса или у Бека надо стросить...

G>Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно!

Это, кстати, одно из немного, что мне нравится в XP. Классная идея в том случае, если правильно подобраны партнеры. Можно получать очень качественный код.

G>Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.

вот-вот... согласен. Это все дело для каких-то очень странных проектов.

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

S> вот-вот... согласен. Это все дело для каких-то очень странных проектов.
Мне в этом плане больше UP нравится. Там и отдельные элементы ХР имеют место, но в тоже время есть четкое планирование, написание кода и тестирование.

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

D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

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

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

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

G>А что же такое ХР на самом деле?
G>Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно!
Очень удобно... Один пишет код а со стороны идет мощная корректировка и оптимизация причем багов в написанном таким способом коде не остается вообще... Исчезает торможение по поводу уйиы мелочей которые постоянно ищеш по полчаса в MSDN.. Вообще при написании кода в паре при соответствующих условиях наблюдается реальный прорыв..(ситуация из разряда одна голова хорошо а две лучше)
G>Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.
Это другая ситуация программист как бы одновременно как бы является тестером аналитиком архитектором и девелопереом в одном лице. При этом пропуская всяческие "научные" этапы (анализ, составление ТЗ и п.р.) можно приступить непосредственно к работе. Как пошутили над таким моим подходом к работе в одной фирме "Если он согласен получать за это одну зарлату... ради бога пусть работает".

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

H>Очень удобно... Один пишет код а со стороны идет мощная корректировка и оптимизация причем багов в написанном таким способом коде не остается вообще... Исчезает торможение по поводу уйиы мелочей которые постоянно ищеш по полчаса в MSDN.. Вообще при написании кода в паре при соответствующих условиях наблюдается реальный прорыв..(ситуация из разряда одна голова хорошо а две лучше)
+1 Согласен. Помнится мы еще на 2 курсе с соседом эту фишку просекли, когда делали лабы и курсачи в последний момент. На самых трудных участках программы сидели вдвоем и дергая друг у друга клаву писали. Хорошо получалось.

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

D>Прочитал книгу "Экстремальное программирование", возник вопрос — кто-нибудь так работает? Поделитесь впечатлениями. И много ли контор в Москве где так работают?

На конференции разработчиков компьютерных игр (КРИ-2004), прошедшей в эти выходные, выступал руководитель игровых проектов компании "Никита" (которая игры пишет). Доклад назывался как-то типа "XP и реальная жизнь: опыт применения в компании Никита". Ну вот он утверждал, что такие методики, как маленькие циклы разработки, постоянный рефакторинг, парное программирование (не в том смысле, что за одним компом сидят двое программеров, а в том, что задание даётся на двоих), написание unit test'ов -- используется в их компании.

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

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

H>Здравствуйте, Glоbus, Вы писали:

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

G>>А что же такое ХР на самом деле?
G>>Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно!
H>Очень удобно... Один пишет код а со стороны идет мощная корректировка и оптимизация причем багов в написанном таким способом коде не остается вообще... Исчезает торможение по поводу уйиы мелочей которые постоянно ищеш по полчаса в MSDN.. Вообще при написании кода в паре при соответствующих условиях наблюдается реальный прорыв..(ситуация из разряда одна голова хорошо а две лучше)

Ага. А если ни один из челов в паре не знает вопроса, тггда что? Вдвоем в мсдн-е рыться?

G>>Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.
H>Это другая ситуация программист как бы одновременно как бы является тестером аналитиком архитектором и девелопереом в одном лице. При этом пропуская всяческие "научные" этапы (анализ, составление ТЗ и п.р.) можно приступить непосредственно к работе. Как пошутили над таким моим подходом к работе в одной фирме "Если он согласен получать за это одну зарлату... ради бога пусть работает".

Очень клево — и швец, и жнец и на дуде дудец. И действительно клево ТЗ нету, никакой анализ не проведен, ничего не знаем, но зато начали педалить, наверх рапортуем об успехах, причем вдвоем с напарником наперегонки.
Кстати у меня всегда возникал вопрос — а как распределяется ответсвенность за написанный такоим образом код? И как эти товарищи договоряться что и как писать, если архитектуры общей нету. Откуда они знают место своего куска во всем прожекте, если у них даже ТЗ нету, не говоря уже об общей схеме приложения?

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

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

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



S>>> Да. Абсолютно согласен. Думаю, что в этом случае так оно и было. Может быть не все до конца понимают концепий XP и берут только то, что им нравится, в итоге выходит не очень хорошее менение о методологии... Но мнение-то уже складывается. На RSDN уже не раз обсуждалась XP и большинство отзывов было отнюдь не лестных. Оппоненты правда говорят, что люди не понимаю, что же такое XP на самом деле...

G>>А что же такое ХР на самом деле?

S> Ты у меня спрашиваешь? Я не эксперт... это у Брукса или у Бека надо стросить...

G>>Я вот в журнальчике читал приличных размеров статью, о том какая клевая тема ХР. Меня среди прочих равных выбил из колеи такой момент как писалово в парах. Типа сидят двое за компом и педалят оп очереди. Вот это конечно мегаэффективно!

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

А подбирать ты их как будешь.
А код можно получить а можно и не получить
А спросим потом с кого?

G>>Да и такие вещи как почти полное отсутствие планирование и жизнь сегодняшним днем тоже настораживает — типа прожект всегда готов к сдаче. То есть может порносайты из 5 страничек и можно таким робом делать, но не более.

S> вот-вот... согласен. Это все дело для каких-то очень странных проектов.

Не странных а козлятских. вон товарищ написал что они лабы и курсачи в институте так писали. То есть сразу чувствуется серъезность "прожекта"

G>Не странных а козлятских. вон товарищ написал что они лабы и курсачи в институте так писали. То есть сразу чувствуется серъезность "прожекта"

А с чего это вдруг такое пренебрежение к лабам и курсовикам? "Серьезность" начинается именно с них. Это первое. Второе — лично для меня "серьезные" проекты — давно в прошлом. От "серьезных" проектов я не получаю ничего, кроме рутины и зеленой тоски. Я уже не мальчик, чтобы работать запросто так, без фана. Фан в работе имеет для меня огромное значение.
Третье. Как говрится, "Если высказывание можно истолковать неправильлно, оно будет истолковано неправильно", Если же высказывание таково, что его просто невозможно истолковать неправильлно, оно, тем не менее, все равно будет истолковано неправильно.

Это касательно идей XP и применения их на практике. Кто-то сказал, что не высыпался, работая в таком режиме. Это означает, что организатор — просто дурак и он ни фига не понял. Он просто решил, прикрываясь красивым словом, заставить людей побольше сделать за те же деньги.

"Проект всегда готов к сдаче" означает не житие сегодняшним днем и не отсутствие планирования. Это означает то, что написано, а именно "Проект всегда готов к сдаче". Не мешало бы научиться просто читать то, что написано, без выдумывания отсебятины.

Где в XP сказано, что не надо никаких планов? Где сказано, что планирование — это плохо? Там сказано, что надо быть гибче. Если план не срабатывает (ну негодный план, не торкает — это бывает сплошь и рядом), то ну его на фиг, такой план, на как можно более раннем этапе.

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

Работа парами ставит целью не повышение "мгновенной" эффективности. Наоборот, зачаструю это медленее, больше ругани, и т.д. Тем более, платить надо двоим за ту же работу. Работа парами ставит собой две цели. Первое — наладить естественным образом коммуникации между людьми. Каждый станотся более-менее в курсе того, что делается за соседним столом. Code Review говорите? Совершенно бесполезная, скучная и искусственно насаждаемая байда. С какой стати я должен разбираться в чужом коде, если я не вовлечен в процесс соседа и у него все работает (до поры, до времени)? Вторая цель — процентов 80 всей работы — это рутина. Не знаю как вы, но я от рутины постепенно сдуваюсь. Работать вдвоем над рутиной — просто веселее. Это очень важно. И не надо кивать на то, что "работа есть работа", "за нее деньги платят", "у нас серьезный проект", "тебе налили — вот сиди и пей" (последнее — как естественное логическое продолжение). Работать должно быть весело и приятно — только в этом случае можно выдать что-то хорошее.

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

G>>Не странных а козлятских. вон товарищ написал что они лабы и курсачи в институте так писали. То есть сразу чувствуется серъезность "прожекта"

MS>А с чего это вдруг такое пренебрежение к лабам и курсовикам? "Серьезность" начинается именно с них. Это первое. Второе — лично для меня "серьезные" проекты — давно в прошлом. От "серьезных" проектов я не получаю ничего, кроме рутины и зеленой тоски. Я уже не мальчик, чтобы работать запросто так, без фана. Фан в работе имеет для меня огромное значение.
MS>Третье. Как говрится, "Если высказывание можно истолковать неправильлно, оно будет истолковано неправильно", Если же высказывание таково, что его просто невозможно истолковать неправильлно, оно, тем не менее, все равно будет истолковано неправильно.

Интересно, если "серьезные" прожекты в прошлом, то что же в настоящем. Чтобы не было разночтений давайте сразу определимся что суть "серьезный" проект а что "несерьезный". По моему субъективному мнению лабы и курсовики нельзя назвать "серьезными" прожектами, да и прожектами вообще потому что зачастую, с вероятностью 0.95, они все просто "слиты" — на то закрыли глаза, там замазали — вот и сдали, ну и славненько. В коммерческих пролектах это тоже встречается, но имеет гараздо меньший удельный вес — за реальные прожекты трахают по-настоящему все начиная с твоего непосредственного начальника, который видит что твой алгоритм работает недостаточно быстро, и заканчивая заказчиком в далеком городке на берегу мисисипи за то что кнопка лежит не так.

MS>Это касательно идей XP и применения их на практике. Кто-то сказал, что не высыпался, работая в таком режиме. Это означает, что организатор — просто дурак и он ни фига не понял. Он просто решил, прикрываясь красивым словом, заставить людей побольше сделать за те же деньги.

Уважаемый, а вот ответь мне, простому русскому человеку, контора в которой ты работаешь применяет хр на практике? Реально просто интересно.

MS>"Проект всегда готов к сдаче" означает не житие сегодняшним днем и не отсутствие планирования. Это означает то, что написано, а именно "Проект всегда готов к сдаче". Не мешало бы научиться просто читать то, что написано, без выдумывания отсебятины.

Нет, "прожект всегда готов к сдаче" означает именно житие сегодняшним днем. положим у меня есть программулина, состоящая из весьма приличных по размеру и сложных по внутренней организации модулей. То есть на реализацию каждого из них недостаточно одного дня, нужны скажем недели работы. Как тогда быть в "стиле хр"? получается что прожект не готов к сдаче всегда?

MS>Где в XP сказано, что не надо никаких планов? Где сказано, что планирование — это плохо? Там сказано, что надо быть гибче. Если план не срабатывает (ну негодный план, не торкает — это бывает сплошь и рядом), то ну его на фиг, такой план, на как можно более раннем этапе.

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

Это другая ситуация программист как бы одновременно как бы является тестером аналитиком архитектором и девелопереом в одном лице. При этом пропуская всяческие "научные" этапы (анализ, составление ТЗ и п.р.) можно приступить непосредственно к работе. Как пошутили над таким моим подходом к работе в одной фирме "Если он согласен получать за это одну зарлату... ради бога пусть работает".

Эк удобно то. Сам себе и архитектор, и тестер, и программер. Интересно было бы посмотреть на архитектуру того приложения, которым он занимался. А теперь представим что у нас таких архитекторов скажем 6. И все они равноправны требовать принятия своего решения. В хорошей книженке брукса описывается построение группы разработчиков по принципы операционной бригады. Всегда есть человек во главе процесса. он один принимает решения и он за это отвечает. Все остальные товарищи могут либо ваще играть роль исполнителей либо иметь совещательный голос в зависимости от квалификации и своего проф уровня.


MS>Рефакторинг означает не то, что надо постоянно все переделывать, как это многие извращенно понимают. Это значит, что надо не стесняться переделывать, если что-то оказалось неудачными, даже если это стоит больших усилий всей группы. Такой подход позволяем сохранять уровень энтропии кода на приемлемом уровне и не загонять себя в угол все более и более кривеющего тулкита, чем очень часто страдает традиционный подход. Кто скажет, что его ни разу не тошнило от проделанной самим же работы, тот либо самодовольный болван, либо молодой еще.

А никто не говорит что рефакторинг это плохо. Но посуди сам, мой благородный друг, что лучше применять рефакторинг в исключительных случаях нежели использовать его как часть методологии. Именно таким подходом и можно загнать себя в угол, потому что переделывать код каждый божий день грабли отвалятся, как бы тебя не тошнило от него. Так что сначала думать надо, а потом делать.

MS>Работа парами ставит целью не повышение "мгновенной" эффективности. Наоборот, зачаструю это медленее, больше ругани, и т.д. Тем более, платить надо двоим за ту же работу. Работа парами ставит собой две цели. Первое — наладить естественным образом коммуникации между людьми. Каждый станотся более-менее в курсе того, что делается за соседним столом. Code Review говорите? Совершенно бесполезная, скучная и искусственно насаждаемая байда. С какой стати я должен разбираться в чужом коде, если я не вовлечен в процесс соседа и у него все работает (до поры, до времени)? Вторая цель — процентов 80 всей работы — это рутина. Не знаю как вы, но я от рутины постепенно сдуваюсь. Работать вдвоем над рутиной — просто веселее. Это очень важно. И не надо кивать на то, что "работа есть работа", "за нее деньги платят", "у нас серьезный проект", "тебе налили — вот сиди и пей" (последнее — как естественное логическое продолжение). Работать должно быть весело и приятно — только в этом случае можно выдать что-то хорошее.

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

G>Интересно, если "серьезные" прожекты в прошлом, то что же в настоящем. Чтобы не было разночтений давайте сразу определимся что суть "серьезный" проект а что "несерьезный". По моему субъективному мнению лабы и курсовики нельзя назвать "серьезными" прожектами, да и прожектами вообще потому что зачастую, с вероятностью 0.95, они все просто "слиты" — на то закрыли глаза, там замазали — вот и сдали, ну и славненько.

Ну так я об этом и говорю! Отношение к работе, желание выпендиться, если угодно. "Сдали, ну и славненько" — этим как раз страдает большинство коммерческих контор. Какая там квача внутри, никого не касается. И начинается это именно с тех самых курсовиков. Любой проект надо воспринимать как серьезный, но работать над ним надо не серьезно, а если угодно, с азартом.

MS>>Это касательно идей XP и применения их на практике. Кто-то сказал, что не высыпался, работая в таком режиме. Это означает, что организатор — просто дурак и он ни фига не понял. Он просто решил, прикрываясь красивым словом, заставить людей побольше сделать за те же деньги.

G>Уважаемый, а вот ответь мне, простому русскому человеку, контора в которой ты работаешь применяет хр на практике? Реально просто интересно.

Нет, не применяем — в этом нет необходимости. Я, кстати, и не говорил, что являюсь апологетом XP Я говорил о том, что тяжело понять и принять такую философию. Опять-же, учимся читать то, что написано.

G>Нет, "прожект всегда готов к сдаче" означает именно житие сегодняшним днем. положим у меня есть программулина, состоящая из весьма приличных по размеру и сложных по внутренней организации модулей. То есть на реализацию каждого из них недостаточно одного дня, нужны скажем недели работы. Как тогда быть в "стиле хр"? получается что прожект не готов к сдаче всегда?

Это означает, что заказчик постоянно его видит и наблюдает за развитием. Все определяется целью — как правило, это именно "слить" проект и получить деньги — это гнилая цель. Хорошая цель — это попытаться удивить мир, начиная с того же заказчика. Для этого надо иметь амбиции, а это непросто.

G>Эк удобно то. Сам себе и архитектор, и тестер, и программер. Интересно было бы посмотреть на архитектуру того приложения, которым он занимался. А теперь представим что у нас таких архитекторов скажем 6. И все они равноправны требовать принятия своего решения. В хорошей книженке брукса описывается построение группы разработчиков по принципы операционной бригады. Всегда есть человек во главе процесса. он один принимает решения и он за это отвечает. Все остальные товарищи могут либо ваще играть роль исполнителей либо иметь совещательный голос в зависимости от квалификации и своего проф уровня.

Здесь все зависит от этого начальника-архитектора. А это нехорошо. Начальник завсегда может свою ответственность слить. Как показывает практика.

MS>>Рефакторинг означает не то, что надо постоянно все переделывать, как это многие извращенно понимают. Это значит, что надо не стесняться переделывать, если что-то оказалось неудачными, даже если это стоит больших усилий всей группы. Такой подход позволяем сохранять уровень энтропии кода на приемлемом уровне и не загонять себя в угол все более и более кривеющего тулкита, чем очень часто страдает традиционный подход. Кто скажет, что его ни разу не тошнило от проделанной самим же работы, тот либо самодовольный болван, либо молодой еще.

G>А никто не говорит что рефакторинг это плохо. Но посуди сам, мой благородный друг, что лучше применять рефакторинг в исключительных случаях нежели использовать его как часть методологии. Именно таким подходом и можно загнать себя в угол, потому что переделывать код каждый божий день грабли отвалятся, как бы тебя не тошнило от него. Так что сначала думать надо, а потом делать.

Для этого надо быть провидцем на практике. Я таких не встречал. Чтобы хорошо придумать, надо хорошенько повертеть в руках сначала. Попробовать так и сяк. Не стесняться выкинуть написанный код и сделать лучше.

G>Писанина вдвоем это мне кажется реально байда. По большому счету разработчику практически не надо знать что делается за соседним столом как ты говоришь, уважаемый. У него должен быть список жестких требований к его модулю, а как он будет реализован это его маленькие интимные секреты. И с помощью этих секретов он должен уложить результат своих деяний в прокрустово ложе этих самых требований. А вот составить список требований по каждому модулю, да так чтоб все модули потом состыковались, и чтобы все было просто красиво и быстро — вот это настоящее искуство, в этом и состоит красота программинга как деятельности, а не в том чтобы...

Так о том и речь! К сожалению, все, что люди понимают из XP — это

G>...побыстрее напедалить чтобы все было "в любой момент готово к сдаче".

На более глубокое понимание их не хватает. Смею утверждать, что я понимаю в XP гораздо больше, но тем не менее, считаю эту философию недостаточно очевидной для применения ее на практике. Во всяком случае, не сейчас.

А что "должен быть список жестких требований к его модулю" — это в коне неверно. Список требований должен быть. Список жестких требований — блажь и самодурство начальников-архитекторов. Может это мне так не везло, но вот пример очень яркий. Был у нас проект по довольно сложной обработке геномных данных. Объемы гигантские, алгоритмы хитрые. Ораклы всякие. Так называетый главный архитектор определил модули, интерфейсы, и прочее. Все очень красиво и прельстиво. Осталось все реализовать. И вот, под конец выясняется, что "прокрустово ложе" интерфеса само по себе диктует сложность алгоритма на уровне O(N^3), в то время как и O(N log N) — многовато. Изначально это не было очевидно, все было красиво и все радовались. Нам удалось доказать несостоятельность его дизайна только лишь продемонстрировав что даже с пустышками вся система просто затыкается на реальных объемах. И все равно сдали именно так, потому как "сроки и планы". Заказчики вежливо отказались, репутация группы была испорчена, зато все в срок и с хорошим, красивым дизайном.

Согласен, есть задачи, где изначально очевидно, что все получится, надо только все грамотно расписать. Мне они не интересны — это рутина и тоска изначально, хоть на уровне проектирования, хоть на уровне кодирования. Мне интересны задачи со значительным риском — получится/не получится. Мне надо "поиграться", прикинуть Х к Н, подумать как следут (думать для меня означает пробовать так и сяк, вертеть в руках). А здесь первичен именно алгоритм, а не дизайн. И секреты у меня не "маленькие интимные", а большие и удивительные