extremeprogramming?

за доминиращата роля - предполагам, че постепенно уменията в отбора ще се изравнят и тогава вече ще има равностойна комуникация. защо се опитваш да делиш програмистите на по-разбиращи и не толкова разбиращи? радваш се когато си част от йерархия в стил архитект, анализатор, старши програмисти, младши програмисти и т.н.? не е ли по-добре старшия и по-опитен програмист да работи тъкмо с неопитни такива? в началото ще върви по-бавно работата, но след малко време ще тръгне по-бързо тъкмо поради развитието на младите. като цяло отбора ще върви по-бързо, а това е крайната цел нали? вярваш ли, че старшия ще знае ВСИЧКО и младия до него няма да може да му помогне с нищо? аз не вярвам!

>струва ми се че за големи задачи обаче тоя подход ще срещне трудности.
големите задачи могат да се разбият на подзадачи. прилагаме метода на всяка подзадача.
>нетривиални елементи на ръба на способностите на хората
>и които не се знае "дали ще станат".
нетривиалните елементи могат да се разбият на тривиални елементи. виж по-горе за подзадачите. за незнаенето дали нещо ще стане - погледни на какво се казва спайк ( Spike ) в ЕП литературата.

>>" Extreme Programming Explained - на Кент Бек - създателя на процеса. това е първата книга по методологията. още известна като the white book
Extreme Programming Installed - от Рон Джефрис - един от участниците в C3. в момента един от най-активните евангелисти :)
Refactoring - Improving the Design of Existing Code - от Мартин Фаулър. "

Аз лично съм заинтересован:)
особено след като прочетох тази тема...
Аз поне ще съм ти благодарен ако ги качиш някъде тези книги.

книгите са на едно цд, което не е у мен. намерих линкове за първата и третата. ще кача Installed другата седмица и ще се обадя във форума.

на някой да му се намира Lean Software Development: An Agile Toolkit на Mary Poppendieck?

Много благодаря особено за ценният сайт:)

не го знаех:)

>аз също съм имал проблеми при прилагането на някои от практиките. но не съм си помислял "ЕП е глупост и при мен не работи"

Nesto pak ne mi e iasno, az li krivo govoria ili ti krivo me razbirash? Koga sam kazval che e glupost?

V tazi chast ot proekta v koito az rabotia ne ni triabva nito XP, nito dvu-programirane :)
Tova e server i cialata komunikacia e prez protokol koito varvi po socket-i, i taka ili inache ne moze da se promeni, interface-ite na klienta sa tochno specificirani i niama mardane ot tiah, trima choveka sme i makar che sme vseki e "specializiral" v razlichna podsistema na server-a prakticheski vseki znae kakvo stava v drugite. Kogato se nalaga da promeniam code koito ne e moi obiknovenno vikam tozi koito otgovaria za podsistemata i bistrime reshenia dokato omeknat glavite ili programata :) Sled koeto reshavame koi da implementira code-a. Nakraia vsichko zavarshva s code review na promianata v source-a.
Kato se dobaviat features predvaritelno se obsazdat i se reshava kakvo i kak da se napravi. Kogato promianata e sastestvenna niakoi se praviat leki modifikacia na code-a nesto s koeto da se dokaze che tova moze da se realizira (ne e zadazlitelno da ima palna funkcionalnost e zadalzitelno dori da raboti vazno e da se vidi tova izobsto fit-va li se v code-a koito sastestvuva i kakvi usilia ste sa nuzni). Po sastoto vreme ot sastia chovek se pishe i dokumentaciata. Taka mezdu drugoto se poluchava jiznena specifikacia koiato e realno rabotesta. I sled tova se praviat promenite i pak code review i checkin.
Tova raboti perfektno i ne vizdam smisal da se promenia.

Vsastnost dumata mi beshe za horata ot drugite otdeli. Te si izpatiha ot eksperimenta. I te zapochnaha da se oplakvat che taka nestata ne varviat.

Proekta koito se pishe (vsastnost releas-na veche) e naistina goliam ne znam kolko clasa ima ne sam gi broil no sa mnogo. Vsastnost Crisler biha mogal da si napishat proekta s nego bez da im se nalaga pisaneto na nikolko desetki hiliadi klasa :)

Pod planovost imah v predvid da ima proekt(plan) po koito se raboti, a ne da pravish redesign vseki niakolko dena (sedmici pak dori i na mesec).
Moeto mnenie e: Ako promianata zasiaga nesto koeto e v core-a i ne e jizneno neobhodima, da hodi v sledvastata versia.
Vsastnost tova napalno savpada s menieto na prkia mi shef i sam mnogo dovolen ot tova. Suma pati ni e spasiaval da dobaviame gluposti v programata :)

Imah edin drug shef, ne blesteshe s mnogo akal, no vednaz kaza nesto koeto mnogo mi haresa: "Maistora e maistor, zastoto znae koga da spre".

Moze i horata koito reshiha da go prilozat da ne sa razbrali pravilno kak triabva da se pravi, no opredeleno tvarda che ne sa prosti i imat dostatachno bagaz v glavite si, taka che ne znam dokolko e tehen problem tova che se provaliha nestata ili e problem na metodologiata kato takava. Ta zatova povdignah i temata de.

Vsastnost nestata ne se provaliha, produkta e nalice i raboti, no vremeto, usiliata i nai-veche nervite na horata biaha siakash mnogo poveche ot kolkoto se nalagashe.

Taka che ne che ne raboti ili e glupost, a siakash ima nesto koeto ne e kakto triabva. I spored mene tova e lipsata na dokument v nachaloto na proekta koiato da kaze tova da tova ne, tova v sledvastata versia. Vsichko se reshava v procesa na rabota. Tova go praveh kogato zapochnah da ucha programirane taman vidia che nesto raboti i otkrivam che moze da se napravi po-dobre, i vsichko otnachalo. Taka moze da se raboti po kursovi raboti, malki proekti, no ne i v goliam produkt ot koito chakash pari. Nai-malkoto che kato izleze programata ste si umrial ot glad. :)

съжалявам за "глупостта" - не съм искал да звучи така, просто не съм се изразил добре.

>Pod planovost imah v predvid da ima proekt(plan) po koito se raboti,
>a ne da pravish redesign vseki niakolko dena (sedmici pak dori i na mesec).

кой е казал, че в ЕП няма план? виж Planning Game, Release Planning.

>pak code review i checkin.
>Tova raboti perfektno i ne vizdam smisal da se promenia.

работи, но може би не е оптимално. какво би станало ако заменим документацията и код ревютата с ОнСайт клиент и дву-програмиране?

>Moze i horata koito reshiha da go prilozat da ne sa razbrali pravilno kak
>triabva da se pravi, no opredeleno tvarda che ne sa prosti i imat
>dostatachno bagaz v glavite si, taka che ne znam dokolko e tehen
>problem tova che se provaliha nestata ili e problem na
>metodologiata kato takava.

възможно ли е точно багажа да е попречил? правили сме нещата така и се опитваме да продължаваме да ги правим по същия начин, нищо че им викаме другоче? питам защото съм виждал такива хора - прекрасни специалисти в областта си, но в непозната територия карат по инерция.

за знаенето кога да се спре и постоянното подобрение, заради което те е страх, че няма да се стигне до пускане на продукта -- всяка история има ясно дефинирано условие за край! когато теста мине -- значи си свършил. не искам да те обидя (сигурно аз не се изразявам достатъчно ясно, което съмнение вече изразих ) - но явно не се разбираме изобщо - налична е цялостна промяна на модела за разработка на софтуер. неща като: съществени промени, код ревю, специализация на програмистите, голямо планиране ( BDUF - big design up-front ) -- звучат малко странно в ЕП контекста. можеш наистина да хвърлиш едно око на книгата на Бек. малка е, няма и 200 страници, леко четиво е и става за четене в кенефа или преди заспиване. там той обяснява практиките, тяхната координация и допълване и т.н. много често почнах да виждам мнения, че ЕП и другите гъвкави методи са проявление на много от "тънките" (Lean) принципи на производство, които почват да се прилагат и в софтуера - много добра статия по въпроса има тук: [линк].

това за документите покрай историите ми звучи интересно. можеш ли да ми разкажеш за ОнСайт клиента - как се сработи с програмистите, как се провеждаше планирането на итерацията, как ставаха оценките на историите. кой дефинира аксептънс тестовете?

коя е била най-мъчната част в ЕП за вашия отбор? тест дривън девелопмънта? дву-програмирането? наличието на клиент и планирането? за сравнение - за отбора, с който пробвахме за първи път най-трудни за нас бяха тестовете.

защо деля програмистите на разбиращи и неразбиращи? а защо продавачите на пазара делят доматите на едри и дребни? защо жените се делят на красиви и грозни?
не знам защо, такъв е живота. колкото и хората да се опитват да си затварят очите пред такива неудобни неща, те са факт. и не само че са факт, ами са основен движещ факт, около който се върти всичко - изборът на по-доброто. изборът означава узаконяване на неравенството. самоят факт че има такова нещо като избор мисля отговаря на въпроса ти.
а това с разделянето на голямата задача на малки е малко... хм. самата концепция на екстремното програмиране е такава че малко не виждам как ще стане. там ясно е казано - всички работят по целия проект и са добре запознати с него. както и да ,е аз не съм много наясно с концепциите му. но по втората част с нетривиалните задачи - е тук вече твърдо не съм съгласен. нетривиалната задача е нетривиална. не знам дали си разбрал правилно, но аз казах че екстремното програмиране, така поне както аз го схванах, мисля е по-подходящо точно за решаване на нетривиални задачи. но ако искам да ми направят текстов редактор, май ще избера конвенционална стратегия.

Taka kato se zamislia moze i da ne e bila vinovna metodologiata, prosto s trion hliab ne se razi nito pak s bradva. Ima si noz s koito pak darva ne se rezat.

No eto nakratko za kakvo stava duma.

Kazah che tova e middleware. No za da stane po-iasno predstavi si kak bi prilozil XP metodologiata v proekti ot roda na Tuxedo ili WebSphere application server + vsichki komponenti okolo tiah. ОнСайт клиент-i niama i nemoze da ima v takava sistema. Edinstvenno pri fix-vane na bugove mozesh da pratish prerelease na naikoi klient da vidish kak raboti fix-a v realnata sistema i to samo sled razgovor na visoko ravniste sas shefovete i ako klienta izrichno proiavi zelanie da go izpolzvame za "tester".

Kakvo oznachava simple design za slozen proekt? Ne mozesh da zapochnesh s design na calculator i da napishesh Excel. Slozen proekt iziskva dostatachno slozen i tochen design.
I tuka beshe parvata greshka zapochnaha kato na shega s programki koito sa simple, no v tiah niama nachin da zalegne cialata funkcionalnost na proekta. Prosto e nevazmozno. (excel-a i calculatora).

Goliama chast ot proektite v C++ predi godini se provaliaha zaradi tova che niama hora koito mogat da napraviat design na OO sistema. A OO ne prostava losh design.
> XP teams build software to a simple design. They start simple, and through programmer testing and design improvement, they keep it that way. An XP team keeps the design exactly suited for the current functionality of the system. There is no wasted motion, and the software is always ready for what's next.
Vaprosa e: What's next?

I taka idvame v Planning Game.
XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next.
Dori samata duma predicting ne mi haresva. Tova e programirane ne okulistika. Za kakvi predskazania stava duma?
Konkretno v nashia sluchai predskazaniata biaha za proletta a sega e esenta :) Produkta izleze predi koito i drug da e uspial da izkara nesto blizko po funkcionalnost, no vse pak meseci sled plana.
I tuka idva miastoto na iteration planing-a. Direction-ite se meniat vseki den, ne moze da se izkara dve sedmici kakto go pishe v knigite :). I izobsto kakvo planirane moze da ima kogato dori SUN promeniat specifikaciite si, a produkta triabva da e J2EE complient?
Та така големи итерации паднаха :)

Ужас но е halloween какво да се прави :)

Жалко наистина, Дъми, че не се е получило.
Нямам богат опит с ЕксПи процеса, бих казал почти идентичен с Муслон.
Обаче темата ме интересува, понеже от малкото, което опитах и от това което чета - за чужд опит, разбрах че ЕксПи може да бъде много продуктивен и същевременно природосъобразен ( почти като ВиБи :) ) метод за изграждане на софтуерни проекти от всякаква големина и сложност.
Продуктивен, защото това е залегнало в самата му идея, като един 'agile' процес, би трябвало постепенно да се увеличава производителността на всички членове на отбора(екипа), да се намалят загубите от гршки и дефекти, или поне да е ясно на всички, когато работата върви на зле, клиента включително.
Природосъобразен, защото би трябвало до доведе до намаляване на прединфарктните ситуации причинени при натиск от страна на клиента и ръководството, скубането на коси, носенето на проблеми в къщи, след 12-часов работен ден и какви ли не още изродени производни.

Вярно обаче че началото в повечето случаи е трудно. В групите на Яху ( за които Муслон спомена ), редовно се появяват хора, търсещи помощ или най-малко насока при стартиране/преминаване към ЕксПи процес.

До колкото разбрах на вас ви е било също 'сефтето'. Затова ми е интересно, ако можеш да споделиш малко информация, за останалите членовете от екипа - в съответните роли - какъв опит имат, дали са участвали успешно/неуспешно в други ЕксПи проекти. А дали са направили някакъв вид анализ на причините за неуспеха? Явно шефовете поне са решили, че това е заради процеса, щом прекратяват практиката, а останалите?
Мерси предварително.

"We, who are not as others"

Vsastnost shefovete ia prekratiha pod natiska na horata, nedovolstvoto stana dosta goliamo, horata se iznerviha, no za tova veche pisah: opitite da se commit-nat promenite v source otnemashe chasove, imshe sluchai v koito tova otnemashe poveche ot edin den. Po vaprosa za predinfarktnite situacii, inash gi mnogo :)
Ili niakoi ia e polzval nepravilno ili metodologiata ne raboti za vsichki proekti. Lichno az mislia che e vtoroto. Niama edno reshenie za vsichki vidove programi (inache shtiahme da sme bez rabota :)), zasto togava se machime da prilozime edna metodologia za vsichki vidove proekti.

Sasto taka az kazah che ne biah priak uchastnik v bardaka koito nastapi :). Ekipa v koito rabotia polzvame staria princip na rabota (shefa mi reshi taka i spored mene beshe prav, pri nas po edna ili druga prichina tove ne mislia che se nalagashe).

съгласен съм, че малко трудно ще се убедим кое какво и защо. ти си виждал как ЕП се проваля, аз съм виждал как дори и част от него дава много по-добри резултати от предишните. знаеш ли какво ми направи впечатление? Vsastnost shefovete ia prekratiha pod natiska na horata, nedovolstvoto stana dosta goliamo, horata se iznerviha. ЕП процеса е бил наложен "отгоре", насила на хората, които са работили по проекта? ако е било така - мисля, че проблема е там. някой от мениджмънта ви, сигурно гледа редовно дилбърт и не е разбрал, че онова там е сатира :(

толкова по темата от мен.

Мерси за отговора, само бих желал още да попитам: тренерът на ЕксПи отбора - той с какъв опит беше, а някой друг там, който е казвал как да се "ползват" методологиите? А опитаха ли се да подобрят техниката, така че да променят евентуално ситуацията с "бардака"? Дали са споменали, коя(и) от практиките, според екипа, не са сработили? По каква причина?
Станаха повече въпроси, но ще съм благодарен ако можеш и имаш желание да отговориш, дори и на част от тях. Мерси.

"We, who are not as others"

мога да се съглася, че за някои проекти някои процеси биха дали по-добри резултати. проблема е, че никой не е измислил система, която да определя правилния процес за даден проект! избутвам темата към умиране, така че ще се опитам само да доизгладя някои неразбирания.

>Kazah che tova e middleware. No za da stane po-iasno predstavi si kak bi
>prilozil XP metodologiata v proekti ot roda na Tuxedo ili WebSphere application
>server + vsichki komponenti okolo tiah. ОнСайт клиент-i niama i nemoze da
>ma v takava sistema.

ОнСайт клиента ти би могъл да е мениджъра на проекта или представител на маркетинга, който е излязъл с визията за продаваемия продукт. само за пример - подобна система се използва в Тойота - има един "шампион" ( забравих японския термин ), който е напълно отговорен за дадена кола. цялата работа се ръководи от него - избиране на отбор, водачество, комуникация с отбора, изграждането на култура на постоянно подобрение и т.н. той е човека, който прави колата. по същия начин за нормално ЕП в случая е трябвало да се намери човека, който е замислил продукта, човека, който знае какви функции иска, за да може да го продаде. колкото до неможенето да има такъв човек - другите отбори по света как могат и имат?

>Kakvo oznachava simple design za slozen proekt? Ne mozesh da
> zapochnesh s design na calculator i da napishesh Excel. Slozen proekt
> iziskva dostatachno slozen i tochen design.

прост дизайн не значи глупав дизайн!!! може да се почне от калкулатор, и първата история, която иска нещо по-сложно ще бутне еволюцията натам. един човек на мейлинг листа на яху сподели, че е еволюирал цял Модел-Вю-Контролер патърн само с агресивен рефакторинг! опитваме се да гоним такива модели :)

>A OO ne prostava losh design.
а кой позволява и прощава лошия дизайн? техническия дълг от лошия дизайн или нискокачествения код си проличава... рано или късно.

>Dori samata duma predicting ne mi haresva. Tova e programirane ne
>okulistika. Za kakvi predskazania stava duma?

никой не говори за окултистика. представи си сега, че имаш работа за 2 седмици. нея можеш да я оцениш и да дадеш предварителна преценка с минимални отклонения. така - представи си сега, че клиента има представа от работата и по груба преценка това нещо ще отнеме да кажем половин година. разделяме половин годината на итерации, слагаме няколко условни точки за предварителни версии -- ето ти release plan. след всяка итерация можеш да видиш дали се движиш по план - с каква вероятност ще уцелиш крайния срок и дали ще се наложи да промениш приоритетите, така че накрая да имаш максимална стойност за времето, което се е отделило за разработката. един от гурутата на ЕП-то, Рон Джефрис, се хвалеше, че може да оцени работа за година напред за няколко дни, съответно да оцени работа за следващата итерация ( 2-3 седмици ) за минути. не всички са толкова добри, но могат да станат :)

ключът тук е, че клиента знае след всяка итерация накъде отива и може да контролира процеса. постепенно предварителните оценки ще станат и по-точни. кажи ми сега във вашия процес как правите планирането и кога и как уведомявате клиента - искам да видя и ако подхода е по-добър да се опитам да го приложа.

>I tuka idva miastoto na iteration planing-a. Direction-ite se meniat vseki den
>, ne moze da se izkara dve sedmici kakto go pishe v knigite :)
в новата ми работа ( където за съжаление вече не съм колега с Machie ) новите ми шефове също сменяха посоката всеки ден. резултата беше голямо буксуване и много похабени усилия. мисля, че постигнахме компромисен вариант - итерация от 1 седмица и възможност за променяне на функционалност само в понеделник. напълно ясно им стана, че ако излезе нещо ново и спешно по средата на седмицата - трябва да се прекъсне итерацията, да се оцени всичко наново и да се почне нова итерация. това не е моя идея - видях го от някое ръководство по SCRUM ( където на итерацията викат спринт :) ). буксуването спря, и всички сме по-доволни.

Бтв, ако имаш време и интерес погледни [линк]. Цялата нишка е интригуваща. Може и да намериш отговор на своето лично запитване - кои са били причините за неуспеха. А пък и ако го напишеш там, ще е много добре, пък може и да ти стане по-леко - не си сам в мизерията :).

"We, who are not as others"

за разделянето - хората са различни. няма по-големи или по-малки. всеки си има предимства и недостатъци. виж например, че в арабския свят дебелите жени са красиви :). опитвам се да мисля, че е по-лесно да определиш някого като некадърник - истинското майсторство е да можеш да работиш с него. ако наистина е неподходящ за текущата задача може да се предприеме коригиращо действие, но мисля, че страшно малко хора са неподходящи.

>самата концепция на екстремното програмиране е такава че малко не
> виждам как ще стане. там ясно е казано - всички работят по целия
>проект и са добре запознати с него.

това изключва ли разделяне на работата и работене по различните части едновременно със сменяне на двойките, така че всички да са наравно запознати?

думата екстремно няма отношение по това какъв е проекта. името идва от друго място. не съм съгласен, че става само за нетривиални неща! колкото до примера ти за текстов редактор - допускаш ли, че е възможно конкуренцията да прави текстов редактор с ЕП и да извади по-добър продукт по-бързо?

ех, де да бяха много малко неподходящите хора...
между другото - в нашата фирма стила на работа е близък до този за който говорим. проекта се държи винаги в работно състояние, тръгва се да се прави без да се има ясна представа какво трябва да излезе накрая, а чак като стане се пише документация за него. преди да дойда аз, са използвали дори принципа с двамата души на един компютър. но когато дойдох, тая практика я прекратих. точно факта че в началото и аз работих малко по този начин (нали бях новобранец, не мога веднага да си наложа мнението, а и още не знаех че е лошо) ме накара да застана твърдо против този начин на работа. може би ако хората си пасват и стават за тоя начин, може и да става. но аз съм пример за хората които не могат да работят с даване на акъл.
когато бях студент имах един приятел, който беше доста добър на шах. никога не бях успявал да го бия, и ето че един ден чудото беше на път да стане. бях го разбил напълно, беше останал само по няколко пешки, цар и кон ли беше офицер ли. вече го натисках към мат, и тогава дойде един друг приятел, и взе да ми дава акъл. резултата - загубих от спечелена позиция.

но сега се сещам за едно положително свойство на работа по двойки. забелязал съм че аз, и не само аз, когато обяснявам на някого някаква концепция, на мен самия ми става много по-ясна и мога да мисля върху нея много по-добре. но явно идеолозите на ХР нямат това предвид. за тях двамата души са равни партньори, и никой не е в позицията на спаринг партньор.
друг един недостатък на ХР, който забелязвам от практиката ми (защото аз все пак работя по сходен на ХР начин) е изкушението за добавяне на все повече и повече функционалност на продукта, дори когато крайният срок е опасно близо. това води често до ситуация с вторично възникнали бъгове. става въпрос за бъг в модул, който е правен по-рано и е вече тестван, но който се предизвиква от новата функционалност която се добавя на финала. най често това са модули които на пръв поглед нямат нищо общо, и по тая причина не се тестват наново, просто на никокой не му идва на ум че могат да се скапят от нещо толкова несвързано с тях.

Не критикувам. Единственото, което ми е интересно, е да изясня и за себе си някои подробности.

>застана твърдо против този начин на работа. може би ако хората си пасват >и стават за тоя начин, може и да става. но аз съм пример за хората които
>не могат да работят с даване на акъл.

При двупрограмирането е твърде силно да се каже че се 'дава акъл'. По-скоро двама души едновременно гледат писанията и мислят по проблемите. Проявява се способността на всеки поотделно да анализира един и същи проблем и да допринесе за качествено и бързо решение. Аз лично, съм получавал много помощ, дори от програмисти, които не са опитно богати в текущата задача. Наблюдавал съм и други да споделят подобно. И на своя ред съм помагал при не толкова ясни за мен проблеми.
Друго важно предимство на практиката е премахването на личното пространство около текущата разработка. Често програмистът, след повторен прочит на творението си стига до въпроса - как съм успял да сътворя такава глупост? Често програмистът може да се срамува от качеството на произведеното, но тъй като за конкретния случай върши работа, а и никой не е видял подробностите, проблема си остава скрит дълбоко в архитектурата на приложението ( сигурен съм, че ако се поровят из спомените си много програмисти могат да дадът подобен пример ).
Тези недостатъци ( както и доста други, описани в подходящата, вече споментата литература ) могат да се отсранят, ако двама програмисти едновременно се занимават с разработката на конкретна задача. Най-общо казано, всеки трябва да е наясно с ограничението, кето му поставя собствената му черепната кухина. Помощ никога не е излишна. Например, ако се поставиш на мястото на новака? А това състояния трябва да се появява периодично като следствие от прогрес - или както е казано - всяка прогресираща личност, достига нивото си на некомпетентност.
Примерът с шаха е показателен за възможни взимоотношения между партньори. Всеки един от тях в продължение на времето може и трябва да се научи да излага мнението си по конкретия проблем. А след дискусия да се приеме по-доброто ( поне привидно ) решение. С течение на времето следва да се забележи покачването на продуктивносста и при двамата. Конкретно по твоя случай - пробвали ли сте например, да играете по-често партии шах, двамата с твоя приятел? Например по 4-6 часа на ден?
При това може би ще се забележи, в последствие, възможността на всеки от вас поотделно да развива самостоятелно дадена партия, зарязана посредата - неоспоримо предимство при всяка система в жизнения и цикъл.

>когато обяснявам на някого някаква концепция, на мен самия
>ми става много по-ясна и мога да мисля върху нея много по-добре
Правилно. Не е случайна сентенцията - най-добре си разбрал нещо, ако можеш да го обясниш на някой, така че и той да го разбере. Дву-програмирането развива комуникативните способности на партньорите. ( може да изровя и линк към статия с повече обосновка )

>но явно идеолозите на ХР нямат това предвид.
Защо да е явно - от какъв източник черпиш информация?

>за тях двамата души са равни партньори, и никой не е в
>позицията на спаринг партньор
Каво означава спаринг партньор? Такъв дето да го млатиш, докато не си признае че е по-слаб? Акое е това сигурно си прав - не съм срещал някой 'идол' на ЕП да толерира подобно отношение.

А дали имаш предвид, че ти е в помощ, ако някой съотборник ти 'играе' опозиция? Защото ако е така - никак не е лошо - 'в спора се ражда истината' :). Но не трябва да се забравя, че подобното е само за избистряне на идеите. В никакъв случай унижение. Не трябва да се подценява факта, че способностите на колегите, най-вероятно, се отличават само във времето - опитът се натрупва с времето, по-бързо ако има учителр например. Можеш да си помислиш обаче, че все пак не ти плащт за изнасяне на уроци - но ако можеш да научиш партньра си ще е със сигурност предимство за в бъдеще. Ако пък не можеш - има си други ръководни кадри да решат, какво да правят в случая - може би смяна на партньора.

> друг един недостатък на ХР, който забелязвам
>е изкушението за добавяне на все повече и повече
>функционалност на продукта, когато крайният срок е
>опасно близо

Забелязваш грешно. Добавят се фунционалности в точно определен период ( итерация ). Ако не може да се добави съответната фунционалност, за следващата итерация, се преизчислява количеството на добавките. Можеш да направиш справка с архитектурата на процеса.

>бъг в модул, който е правен по-рано и е вече тестван, но който се >предизвиква от новата функционалност която се добавя на
>финала. най често това са модули които на пръв поглед нямат
>нищо общо, и по тая причина не се тестват наново, просто на
>никокой не му идва на ум че могат
>да се скапят от нещо толкова несвързано с тях

Това е въпрос единствено на достатъчна 'покривка' с автоматизирани и приемни тестове. Няма нещо 'толкова несвързано', с което програмистите да не са нясно - все пак те изграждат системата. Това че са забравили да тестват дадена функционалност е проблем само на опит. Затова и ролята на тренера в екипа е много важна. Да покаже и съдейства при обучението е почти изцяло негова задача. В последствие програмистите трябва да са способни да измерят дали покривката е достатъчна. Но периодът на преход не е лесен.
'Но кое на света, което наистина си заслужава е лесно достижимо?' ( Рон Джефрис )

"We, who are not as others"

> но сега се сещам за едно положително свойство на работа по двойки. забелязал съм че аз, и не само аз, когато обяснявам на някого някаква концепция, на мен самия ми става много по-ясна и мога да мисля върху нея много по-добре
Za tova sam absolutno saglasen kakto i za tova che kogato se reshava kakvo i kak da se napravi triabva da misliat vsichki v ekipa (ne samo dvama) i triabva da se izlozi s iasna koncepcia kakvo i kak prieta ot vsichki (po vazmoznost).
Az imah poznat mnogo silen da vadi ot 10 kladeneca voda da ti dokaze che ne si prav. Spored mene triabva da se naznachava edin takav za vseki proekt da te kara da mislish. Dori i glupavite vaprosi mogat da te nakarat da se zamislish za podrobnosti koito si propusnal (a toi ne zadavashe glupai vaprosi ).
> става въпрос за бъг в модул, който е правен по-рано и е вече тестван, но който се предизвиква от новата функционалност която се добавя на финала. най често това са модули които на пръв поглед нямат нищо общо, и по тая причина не се тестват наново, просто на никокой не му идва на ум че могат да се скапят от нещо толкова несвързано с тях.
Sasto mnogo viarno. Dori da ima testove v bolshinstvoto sluchai te ne otkrivat tochno tazi greshka. Proiaviava se sled releas-a i e mnogo nepriatno. Vsastnost tova biaha bolshinstvoto sluchai i pri nas, nai-veche zaradi tova che vsichki polzvat code-a na core-a. A tam trudno se i pishat testove, prosto bez ostanalite moduli, sam za sebe si core-a e po-skoro edna goliama biblioteka, koito kolkoto i da ia testvash nikoga ne mozesh da pokriesh cialata funcionalnost.