extremeprogramming?

Predi tri dena vav firmata v koitao rabotia zabraniha polzvaneto na extremeprogramming kato metodologia :)
Blizo edna godina rabotihme po tova chudo sega se vrastame na starata tehnologia s pisane na MRD, FRD, ERD i vsichko kakto si mu e reda.

Polzval li go e niakoi za naistina goliam proekt i kakvo e mnenieto mu?

Какво е MRD, FRD, ERD ?

Лично на мен extremeprg не ми допада из основи заради pair programming - това значи да не мога да се съсредоточа нито за момент, а да трябва да се обяснявам нонстоп с колегата -програмист :)

1. MRD-Marketing Requirements Document
2. FRD-Functional Requirements Document
3. ERD-Engineering Requirements Document
4. FS-Functional Specification
5. TestPlan

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

Ami znache vie ia polzvate otdavna :)

abe hora!!!!!! pisete na balgarski be!
aman ot tia izmisleni(bezsmislenni) terminologii!!!!!!!!!
(i pisete na kirilica!!!!!! ne kato mene! :-)

че то в екстр. прг-то забранено ли е да се правят такива документи?
по-скоро там се допълват итеративно, а не един единствен път (waterflow)?
но не знам де - не съм много навътре - както казах, за мен не става XP-то :)

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

аз се опитвам да правя нещо подобно не ЕксПи... засега самичък защото няма с кого да дву-програмирам ( баси превода )

никога не съм вярвал, пък и не са ме насилвали да ползвам тежък уотърфол процес.

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

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

мисля, че най-големите печалби при подобна "гъвкава" ( agile ) методология идват от възможността за промяна. каквато и да е промяна - когато и да е в проекта. на много хора това звучи абсурдно, но явно наистина е възможно - стига да имаш поддържащ се код и една сюрия автоматизирани тестове. не мисля, че бих се върнал някога към предишния "шамански" code-n-fix начин на писане на код. TDD( test driven development ) наистина променя радикално. пробвайте иска се малко свикване и в началото се "върви" по-бавно, но после няма да искате да се връщате.

малко ресурси за хората дето се чудят какво е ЕП:
[линк]
[линк]
==========
ей ама съм... има и ЕП група регистрирана на яху групс. казва се xp-bulgaria. няма много членове и никой не поства, но бих се радвал ако се оживи.

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

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

2) много по-малко дефекти ( бъгове ). все пак 2ма човека гледат какво става.

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

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

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

ценен ресурс: [линк] нещо нямам достъп до него в момента. дано по-късно да се оправи

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

а така!

а сега пробвайте TDD и си изхвърлете дебъгера.

откакто се занимавам с PHP, Python и Ruby не ползвам дебъгер, пък и не ми е липсвал изобщо.

И аз се съгласявам!:)
Ако е за нещо та се помогне - за 1, 2, 3,... часа - двама на компютъра - добре!
Ама всеки ден по около 8 часа комплект - баааааааа!:)
Ами аз кога ще си преглеждам пощата, ICQ- то, картинки (интересни!) от интернета!? - нееее, нема да стане тая:)

първо, че 8 часа наистина е нереалистично. може би 5-6.

>Ами аз кога ще си преглеждам пощата, ICQ- то, картинки
>(интересни!) от интернета!?

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

Гледай сега... За картинките (интересните най-вече) си има добър pair вариант - вземаш една колежка и... такова... разглеждате де.

Маха!:)
С възможен инфаркт на работното място по време на....разглеждане:)
Нещо като "паднал с чест на бойното поле!":)

Ne ne sam.

Za "dvu-programiraneto" vinagi sam go polzval osobenno kato se nalaga da opraviam nesto v chuzd code. Vikam tozi koito go e pisal i obsazadame dokato reshime kakvo da pravime i kak da go fixneme (ako se nalaga). Tova ne e prioritet na XP-to, a tova niakoi da ti visi na glavata bez prichina dori 2 chasa si e kofti. Znam edin chovek koito kato sedneshe niakoi do nego i pochvashe da pravi postoianno sintaktichni greshki, prosto niakoi hora ne obichat da gi gledat v racete, pritesniavat se ili znam li kakvo.
Ami na mene XP-to oste ot nachalo mi prilichashe na pach-ilnica. Za malki proekti sam ubeden che krainia rezultat ste bade po-stabilen kode, no za goliam kadeto rabotiat nad 100 dushi se poluchava bardak. Smianata na interface zastoto niakoe user story go iziskvalo vodi do nevazmoznost edna kamara hora da si kompilirat code-a. Predstavi si slednata situacia. Pisal si i iskash da si commit-nesh code-a v source repository-to. Razbira se vsichki testove triabva da pass-nat i v tova niama nisto losho. No dokato ti svarshish test-vaneto onzi koito e promenil interface-a e commitnal negovite promeni. Comitvash tvoite promeni (ako niama conflikti. ne dai boje!!) sledvastia koito se opita da si update-ne coda i da go build-ne mu idva da se zastrelia, zastoto to daze ne se compilira (za varvene duma ne stava).
Vsasstnost zabraniha go zaradi svoevolnite promeni na interface-i. Tova se nalaga ot tova che niama palna specifikacia na interface-ite a za vsiako user story se dobavia (ili oste po-losho promenia) interface-a za da varshi i tova koeto se iziskva.
Izobsto planovata ikonomika :) e slabo zalegnala v tazi metodologia.
S drugi dumi "Simple design" ne varvi za golemi proekti.

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

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

Това ми напомня да отбележа че екстрем билдинга е изключително разпространен по наште географски ширини - издигнат в степен на изкуство, 10 човека се подкрепят с домашна шльокавица и окуражават дежурния дето се е минал да копа.

>obsazadame dokato reshime kakvo da pravime i kak da go
>fixneme (ako se nalaga)
това доста се различава от моето разбиране за дву-програмиране. кода, който пипате сигурно е писан от двойка, в която един от вас двамата е участвал. след модификацията вече има 3ма човека, които могат смело да барат там. Collective code ownership се улеснява.

>Ami na mene XP-to oste ot nachalo mi prilichashe na pach-ilnica.
ЕП иска невероятна дисциплина от участниците. не знам какво имаш предвид последната дума в изречението, но на мен ми звучи като нещо несериозно - уверявам те, такова нещо няма :)

>goliam kadeto rabotiat nad 100 dushi se poluchava bardak.
ЕП обикновено се препоръчва за малки отбори. тия 100 човека може да направят няколко отбора. толкова голям проект сигурно така или иначе е разделен на подпроекти.

>Smianata na interface zastoto niakoe user story go iziskvalo vodi
>do nevazmoznost edna kamara hora da si kompilirat code-a.
представям си какво ЕП е било като сте нямали Continuous Integration. много хора ползват т.нар. Integration Token - защо вие не сте го ползвали като е можел да реши проблема? представям си също какъв е бил кода - подозирам огромни дупликации и ниско качество - щом промяна на интерфейс докарва огромни конфликти и трудно разрешими проблеми при компилацията - къде ви е бил рефакторинга?

>No dokato ti svarshish test-vaneto
тестването е автоматизирано. не трябва да отнема повече от няколко секунди

>Izobsto planovata ikonomika :) e slabo zalegnala v tazi metodologia.
вярно е. ама плановата икономика и уотърфол процеса е доста масово отречен... дори от създателя му, доколкото съм чувал. evolutionary design... evolutionary delivery... anyone?!

>S drugi dumi "Simple design" ne varvi za golemi proekti.
ето ти контрапример - първият ЕП проект - C3 за Крайслер - е бил огромен. говоря за десетки хиляди класове и голяма функционалност. за сведение, направен е от сравнително малък отбор ( нямало е 100+ човека както в твоите съмнения по-горе ). гледах история и статистики за него по уеба, но не мога да изровя линка в момента :(.

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

не съм толкова опитен и сладкодумен като някои хора - бих искал да ви поканя да си зададете въпросите и съмненията на 2 групи на яху групс, където несъмнено ще получите по-изчерпателни отговори.
extremeprogramming@yahoogroups.com и xp-bulgaria@yahoogroups.com. втората група е доста тиха, но може би някой ще отговори.

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

ако някой иска да чете - ще ги сложа някъде на уеба.