Extremismus nemusí být na škodu: extrémní programování

Diskuze čtenářů k článku

nishkam  |  13. 05. 2003 01:28  | 

uvital bych nejake priklady z praxe. Takhle je to moc pekne, ale nevim jak se mi tato teorie muze hodit, napr. pri vyvoji e-obchodu. Nejak to nemuzu spojit s kazdodenni praci.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 10:28  | 

Vlastní zkušenosti z vývoje e-obchodu pomocí XP Vám při nejlepší vůli poskytnout nemohu, ale v příštích článcích na téma XP se určitě dočkáte konkrétnějších rad, postupů i příkladů procesu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin Pegner  |  14. 05. 2003 11:52  | 

Tento koncept je stary asi tak 5-8 let, ne-li dele. Kolega ho privezl z konference ve Spanelsku, kde byl prezentovan jako DSDM model (dynamic system development management) a ve firme jsme jej pouzivali asi od roku 1997-8 Nyni si to nejaky chytrulin nasel na webu a dela ze sebe genia... Zkuste http://www.dsdm.com/ At ziji PLAGIATORI !!!

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  14. 05. 2003 12:27  | 

Mate pravdu, ale prezentujete ji tak, že se zdá, jako byste někoho podezříval z toho, že prohlašuje opak. Pokud se mrknete na článek "Historické souvislosti, vznik a obsah Agilního manifestu", který vyšel na Živě 15.4.2003 (http://www.zive.cz/h/Programovani/Ar.asp?ARI=110332&CAI=2039), zjistíte, že celá agilní aliance vznikla v roce 2001 na konceptech, které v té době už dávno existovaly. Zástupci nejrůznějších metodologických směrů se v té době sešli v Utahu a na základě svých předchozích zkušeností a své předchozí práce zformulovali Manifest a založili alianci. Nikdo z nich nikdy neprohlásil, že vynalezl kolo: byli pouze překvapeni, že se tak snadno shodli, a shodli se především proto, že si všimli silné podobnosti svých dosavadních individuálních nápadů. Hovořit o plagiátorství proto není na místě.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dave G.  |  13. 05. 2003 06:06  | 

tak tedy příklad ze života:

zatímco programátor tvoří webové stránky:
COPY CON cely_web.rar

grafik se zabívá obrázkama
COPY CON images/obrazek.jpg

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  13. 05. 2003 07:28  | 

XP ma urcita pozitiva. Napriklad automaticke testovani modulu je dobry napad, byt ne vzdy realizovatelny (viz clanek pred nekolika dny o vyvoji WWW aplikaci).

Ale v metodice popsane v textu clanku vidim nektere rozpory. Napriklad:
- "... je lepší udělat něco jednoduchého dnes a zítra případně zaplatit víc za případnou změnu, než platit dnes za složitou věc, která se ovšem zítra nemusí využít"
- "Pokud tým zjistí, že dopředu cesta nevede (zásadní problém v architektuře, špatné rozhraní mezi moduly apod.), je nutné chybu opravit i v případě, že by to znamenalo zahození poloviny již napsaného zdrojového textu."

Tyto dve jsou v rozporu, nebot prvni rika, ze je lepsi dnes napsat neco o cem vim, ze bude potreba nez psat neco co zahodim (nevyuziji, ale to je ve vysledku totez). Druha veta rika opak - neni problem zahazovat kusy kodu.

Co mam zkusenosti s projekty, tak vetsinou jsou zdrzovany a prekracovan plan kvuli tomu, ze zadavatel rekne "chci to tak" a kdyz to je hotove tak rekne "chci to jinak" (coz je lepsi pripad, dost casto rekne "to nechci" ale neni schopen rici jak to chce).

Toto ale XP vubec neresi, to pouze rika, ze podobny pristup je v poradku. Tyto problemy se daji resit pouze uvedomelosti zadavatelu (vetsina z nich neni ochotna premyslet trochu dopredu a nad tim co vlastne chce se poradne zamysli az v okamziku kdy je to napsane) a pripadne prototypovanim.

Parove programovani je z hlediska spolehlivosti fajn vec, ale pro vetsinu tymu asi moc drahe

Souhlasím  |  Nesouhlasím  |  Odpovědět
laada  |  13. 05. 2003 09:48  | 

------------------------------------------------------------
"Co mam zkusenosti s projekty, tak vetsinou jsou zdrzovany a prekracovan plan kvuli tomu, ze zadavatel rekne "chci to tak" a kdyz to je hotove tak rekne "chci to jinak" (coz je lepsi pripad, dost casto rekne "to nechci" ale neni schopen rici jak to chce)."
-----------------------------------------------------------

tak tuhle pisnicku posloucham dost casto  

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  13. 05. 2003 10:30  | 

A jeste lepsi je pripad, kdy zakaznik zatvrzele neco chce, a vy mu to vymlouvate, ze to bude mit ty a ty spatne vlastnosti. A on si na tom trva. Tak to tedy napisete a az to je, tak rekne ze to nechce, protoze to ma presne ty spatne vlastnosti na ktere jste upozornoval.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  13. 05. 2003 13:13  | 

Jenze v tomhle prave XP docela pomaha, pokud budes delat fungujici celky strasne rychle (ja v praci delam max. par dni mezi verzema, ale to jen proto ze delam vsechno sam, mit tym tak chci denni verze) a budes to davat zakaznikovi ke hrani. Vetsina lidi si proste nedokaze poradne predstavit neco co neexistuje, tim ze jim budes davat (treba i mizerne fungujici) preview verze tak oni zjistej co vlastne chtej a jak to chtej.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  14. 05. 2003 13:11  | 

To co delas neni v tom pripade XP ale prototypovani Mas stesti, ze zakaznik je ochotny se venovat testovani prototypu. Znam dost co by reklo "na testovani nedodelku nemam cas, prineste to az to bude hotove".

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  14. 05. 2003 18:55  | 

Ze ja tu teorii programovani nestudoval vic, sice bych mozna nebyl schopnej napsat poradnej kod, ale zato bych vedel jak tomu rikat ;) Pokud vim, tak XP vyzaduje funkcni buildy ve velice kratkejch casovejch usecich. Protypovani je trochu neco jinyho. Ja nedelam protypy, ja delam preview, nebo alpha, nebo jak tomu chces rikat verze hotovyho produktu, ktery davam k dispozici spouste lidi. Fakt je, ze zakaznici vetsinou netestujou (i kdyz treba soucasnej release dokonce debugujou ;), mel sem se vyjadrit presnejc - testujou to salesmani co si dany ficurky vyzadali, na zaklade prani zakazniku. Jde o kombinaci bodu dva (o testovani, kde testuji vsichni) a sedm (o kratkych iteracich) kde s vyjimkou prvnich par dnu na projektu se mi velmi kratke iterace osvedcili na uplne vsem co sem delal (clovek toho musi zahazovat min cim driv prijde na to ze dela neco jinyho nez zakaznik chce ;). A samozrejme se koduje podle bodu 4 (nejjednodussi moznej kod), ale to je snad selskej rozum, ne XP.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel Jelínek  |  15. 05. 2003 20:28  | 

Tady XP nepomůže, to je otázka project managementu.
Ideálně by to mělo vypadat tak, že je zadání jasné a funguje tam řízení změn.
Testování pak vypadá tak, že to otestovat musí a tím se pod to podepíšou - když to otestují špatně (a není to skrytá vada), tak je to dobrovůle dodavatele, že jim to upraví.
XP není špatná věc, ale vůbec se nezabývá řízením vztahu se zákazníkem, což je faktor, který na úspěch projektu a kvalitní výstup má mnohem větší vliv.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Prome  |  13. 05. 2003 22:54  | 

mluvite mi z duse, a jeste lepsi je kdyz mate zamestnance ktery ma dostat 1 penize za 2nasobek prace.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ja  |  13. 05. 2003 10:11  | 

"je lepší udělat něco jednoduchého dnes "
to je dano tempem doby. Je potreba dodat neco RYCHLE, protoze se to bude stejne pre/do-delavat.
Ze zkusenosti vim, ze clovek na vylepseni prijde az behem kodovani a uzivatel na spoustu veci
az tehdy, kdyz neco vidi. Neni se co divit. Neni zvykly si abstraktne predstavit, co ma novy system
delat tak, jak to ma delat v OOP analytik. My programatori pri analyze stale vidime v pozadi "jak to
pobezi na teto technologii" a "jak to bude napsane".

Taky jsem zjistil pri soukromem hrani, ze neni spatne si vec promyslet, rychle si zkusit spichnout nektere zasadni veci a pak teprve delat analyzu a designe.
Je pravda, ze je to zacarovany kruh, protoze spatne (nebo jen malo) promysleny navrh vede k paskvilu, na kterem se stavi analyza i nasledne druhe kolo kodovani. Na druhou stranu se bez
nulte verze programovani nezjisti, ze napr. komunikace mezi objekty ma probihat jinak nebo
na co si mam dat bacha. (potvrdily mi to i zazitky poslednich dvou mesicu)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  13. 05. 2003 10:26  | 

Prave tyhle problemy resi prototypovani. Udela se maketa aplikace (kabat s minimem vnitrnosti), na kterem si uzivatel a programator vyjasni zadani.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Karasek  |  14. 05. 2003 11:10  | 

...a uzivatel na spoustu veci  az tehdy, kdyz neco vidi. Neni se co divit. Neni zvykly si abstraktne predstavit, co ma novy system
delat ....

rad bych dodal, ze to take neni povinnost uzivatele si neco abstraktne predstavovat. Dokavad se bude programatorska obec odvolavat na to, ze uzivatel presne nevi co chce, tak ma sice pravniky na sve strane, ale nemusi se divit , ze dochazi k problemum.

V jinych odvetvich je to tak, ze uzivatel nastini mlhave, co by si predstavoval a dodavatel - znaly vsech zakouti problematiky - sahne do sve pokladnice reseni a pro uzivatele realizije to , co se uzivateli nejlepe hodi. K tomu nepotrebuje aby mu neznaly uzivatel radil nejake skopiciny, kdyz nezna a ani nemuze znat celou propletenost daneho reseni.

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  14. 05. 2003 12:31  | 

"dodavatel - znaly vsech zakouti problematiky - sahne do sve pokladnice reseni a pro uzivatele realizije to , co se uzivateli nejlepe hodi". Říkáte tedy, že dodavatel rozhodne, co se pro uživatele nejlépe hodí. Žádný dodavatel však není vševědoucí a může se tedy splést: neštěstí je na světě. Nikdo nebere zákazníkům právo definovat své požadavky vágně nebo dokonce nejasně. Na druhou stranu nikdo nemůže vyčítat dodavatelům, když odmítají odpovědnost za nesplnění projektu vzniklého na základě vágních nebo nejasných požadavků.

A proto je tu extrémní programování , které zapojuje zákazníka do vývojového procesu a eliminuje tím výše popsané krizové scénáře.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 11:07  | 

O rozpory se jedná pouze zdánlivě. Věta "... je lepší udělat něco jednoduchého dnes a zítra případně zaplatit víc za případnou změnu, než platit dnes za složitou věc, která se ovšem zítra nemusí využít" říká vlastně totéž jako věta "Pokud tým zjistí, že dopředu cesta nevede (zásadní problém v architektuře, špatné rozhraní mezi moduly apod.), je nutné chybu opravit i v případě, že by to znamenalo zahození poloviny již napsaného zdrojového textu."

První věta hovoří odmítavě proti příliš robustním architekturám, rozsáhlým analýzám a složitým návrhům. Říká, že nemá smysl vymýšlet teď něco příliš komplikovaného, protože se to v budoucnu buď nevyužije vůbec nebo se to bude muset stejně změnit. Nemá smysl plýtvat penězi na něco, u čeho není zaručené využití. Druhá věta pak pouze říká, že povede-li tento přístup k nutnosti zahodit kus kódu, nevadí to. Situace, kterou popisuje druhá věta, je právě ta případná změna, o níž hovoří první věta - a za kterou podle první věty nevadí něco zaplatit.

Napíšete-li rychle (bez dalekosáhlých analýz) kus kódu a zjistíte-li později, že není použitelný, není to podle XP chyba. XP vychází z toho, že i při občasném zahození kusu kódu je vývoj efektivnější a levnější než při provádění rozsáhlých analýz a psaní rozsáhlých dokumentů - byť tento druhý přístup umožní nezahodit ani řádku.

Jinak s Vámi plně souhlasím v tom, že jedním z nejzávažnějších problémů při vývoji je neschopnost zákazníka specifikovat své požadavky. Jen bych rád podotkl, že v některých případech to může být pochopitelné - mezi vyřčením požadavku na SW a dodáním produktu uplyne určitá doba, změní se podmínky, konkurence, potřeby ... nesouhlasil bych ovšem s tím, že XP tento problém neřeší, pouze "legalizuje": XP nastoluje takový vývojový proces, který uvolňuje SW co nejrychleji (podmínky se tedy mění co nejméně) a zapojuje do procesu zákazníka (ten vidí, co se "chystá" a průběžně zasahuje). Nemůže se tedy stát situace, kdy několik týdnů práce přijde vniveč, protože zákazník na konci řekne "ne, tohle nechci". V XP procesu vidí zákazník vývoj každý den, takže to může říci mnohem dříve.

Párové programování je opravdu moc drahé, ale možné je, že pokud vezmete do úvahy všechny jeho přínosy (nejen zvýšení spolehlivosti), tedy rychlý rozvoj lidí, jejich rozšiřující se pole působnosti, snižování truck faktoru (každý v týmu má povědomost o každé části kódu), zlepšení architektury aplikace, zlepšená efektivita práce apod., můžete možná zjistit, že ve skutečnosti to nebude stát zase tak moc.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  13. 05. 2003 12:52  | 

Ja mam zkusenosti, ze pri podobnem postupu neni zmena "pripadna" ale je v dusledku menicich se pozadavku zahozeno obrovske mnozstvi kodu, dosti casto i vetsina. V takovych pripadech je opravdu levnejsi a rychlejsi udelat poradny navrh (nerikam vyprodukovat tuny papiru, ale opravdu se se zakaznikem zamyslet nad tim, co to vlastne ma delat a pak navrhnout architekturu). Plus identifikovat mozna problematicka mista a nechat s v nich vetsi volnost pro pripadne budouci zmeny.

Jinak zmena navrhu je podstatne lacinejsi, nez zmena kodu, to je nutne mit porad na pameti. A XP nezna jinou zmenu, nez kodu pote, co se funkcionalita napise.

O problemech s refaktoringem (kvuli pridani jedne funkcionality se musi prepsat velka cast kodu, protoze se program dostava do stavu kdy po zmene jedne funkce prestava deset dalsich fungovat) jsem psal uz u jednoho z minulych clanku.

Zapojeni zakaznika je dulezita vec u obou a pokud se vam to podari u navrhu systemu, nemelo by se stat, ze rekne "tohle nechci". Samozrejme zakaznik musi byt zapojeny ve vsech fazich procesu. O prototypovani v pripade nejistoty uz jsem take mluvil.

Parove progamovani: Mozne to samozrejme je, ale neznam studii, ktera by to potvrdila (nebo vyvratila).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Karasek  |  14. 05. 2003 11:00  | 

....se daji resit pouze uvedomelosti zadavatelu ...

takto argumentovali komuniste taky.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vasik  |  13. 05. 2003 08:22  | 

Ruznymi zpusoby vyvoje aplikaci jsem se ve firme hodne zabyvali, takze jsme samozrejme zkouseli i prvky extremniho programovani a hledali o nem strucne a jasne informace. Mohu rici, ze jsem nikde nenasel takhle jasne a strucne formulovany uvod. Jako strucny uvod se slibenym pokracovanim je to skvele, zcela se lisici od bezneho mizerneho standartu na Zive !!!

Souhlasím  |  Nesouhlasím  |  Odpovědět
Libb  |  13. 05. 2003 09:03  | 

Už chápu některá chování MS Windows...

Souhlasím  |  Nesouhlasím  |  Odpovědět
wang  |  13. 05. 2003 16:16  | 

nemyslis Windows XP (extremely programmed)?

Souhlasím  |  Nesouhlasím  |  Odpovědět
dante  |  13. 05. 2003 09:13  | 

S tou odvahou v Evrope nebyva takovy problem, v Cesku je to o poznani horsi. Napriklad Deutsche Bahn vyhodili svuj projekt is asi po roce a pul a zacali znova ...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 11:10  | 

Ano, měl jsem na mysli především ČR, ale ani ostatní evropské státy po mém soudu nedosahují výše (nebo spíše úrovně) Ameriky (pokud jde o odvahu a o sebevědomí).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Luba Š.  |  13. 05. 2003 09:51  | 

O tom se ví již dávno. Problémy vidím 2:

- uživatel si nedovede v abstraktní rovině představit celou šíři toho, co by chtěl (ono se není co divit)

- uživatel by chtěl poměrně rozsáhlý software na zakázku, ale nechce mu za to platit (cenu si představuje na úrovni SW balíku prodávaného po tisících kusech/licencí - často by mu to také stačilo)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 11:15  | 

K té první poznámce - právě proto je v zákazník při XP vývoji nedílnou součástí týmu. K té druhé poznámce není co dodat

Souhlasím  |  Nesouhlasím  |  Odpovědět
Luba Š.  |  13. 05. 2003 12:02  | 

To musí být vždycky, jinak to nejde. Metodu od metody se však liší způsob jeho zapojení, to ano.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ja  |  13. 05. 2003 10:13  | 

Dekujeme za fundovany souhrn. Skoda, ze jsme cekali dlouho, i kdyz chapu,
ze clovek nema tolik casu.
Nam ostatnim ho usetrite, protoze se nemusime hrabat v hromadach textu, casto anglickeho.

Souhlasím  |  Nesouhlasím  |  Odpovědět
BC  |  13. 05. 2003 11:36  | 

"Implementujme teď, zkononalujme později". Je to chyba Jacka Stacka nebo autora článku? Neznamená to např.: uvedeme na trh nedodělaný produkt a konkurenci převálcujeme agresivním marketingem?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 12:08  | 

Možná to spíše znamená: "ztráty způsobené brzkým vydáním verze s chybami nejsou rozhodně větší než pozdní vydání bezchybné verze".

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  13. 05. 2003 13:17  | 

Presne tak, drtiva vetsina zakazniku bude cekat na novejsi verzi nez aby se ucila neco novyho. Byt prvni je neporovnatelne dulezitejsi nez byt lepsi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
sk  |  13. 05. 2003 15:58  | 

To ale rozhodne nemusi platit vzdy a vsade - su situacie, ked to moze byt naopak (aj ked ich asi vacsina nebude...)
Takze XP zase nie je ten jediny a univerzalny navod na vyvoj sw ...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 23:54  | 

Ano, ano... waiting for the silver bullet - tot vecny ukol softwaroveho inzenyra

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel  |  13. 05. 2003 11:44  | 

Nejsem prográmátor a proto se na to dívám z jiného úhlu:

1. To že zákazník přesně neví co chce je realita, se kterou se všichni výrobci a obchodníci už smířili, jen v oblasti SW to nějak pořád nejde (sledujte jak se např. nakupují šaty).  Čímž jste menší firma, tím více musíte poslouchat zákazníka.

2. Dobré je to , co vede rychle k cíli - vy to tady nazývate XP - potřebuji (i špatný) produkt, protože už jsem na trhu a zakázníci o mě vědí. To, že to není dokonalé zjistí až si to koupí, pak investují čas aby se s tím naučili žít a vy jim stejně za nějakou dobu dodáte upgrade. Ale ten co přijde pozdě sice z lepším řešením má problémy najít trh - mí zákazníci už ode mně neodejdou. Proto vede-li XP k rychlejší realizaci - sem s ní.

3. Můžete mi prosím vysvětlit rozdíl mezi analytikem a programátorem. Já to chápu tak, že analytik je architekt a programátor je pouze (vzdělaný typ) dělníka. Tady mám pocit, že vy v tom žádný rozdíl neděláte - sám si navrhnu, sám si naprogramuji a sám (snad i) prodám.

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Luba Š.  |  13. 05. 2003 12:12  | 

- analytik má sbírat a modelovat požadavky uživatele tak, aby byly konzistentní; zásadně nemá vymýšlet žádné řešení

- návrhář navrhuje způsob řešení požadavků, chcete-li tu architekturu

- programátor kóduje navržený způsob řešení

pozn. 1: výše uvedené neznamená, že by schopný jedinec nemohl vykonávat více z vyjmenovaných rolí

pozn. 2: takto to funguje v klasickém "vodopádu" (analýza-návrh-programování testování), který má velkou nevýhodu v tom, že dost tlačí zákazníka do abstraktního vymýšlení, co by potřeboval; pro překlenutí tohoto nedostatku vznikly další technniky jako prototypování, "životní cykly vývoje" jako RAD apod.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  13. 05. 2003 12:44  | 

1. Ale neni zvykem nechat si na zakazku usit saty a pak kdyz se mi nelibi nezaplatit ale chtit je zadarmo (a nejlepe do peti minut) predelat. Navic je docela rozdil mezi saty a SW. Kdyz se kvuli spatnemu zadani zpozdi o nekolik let nasazeni SW, jsou v sazce podstatne vetsi skody, nez kdyz si spatne vyberu saty.

2. (Sarkasmus: Jasne to je obchodnicky pohled Proc prodat kvalitni SW, kdyz jim muzu prodat smejd a jeste je donutit si koupit upgrade

3. Uz tu bylo

Souhlasím  |  Nesouhlasím  |  Odpovědět
Adam  |  13. 05. 2003 12:59  | 

Implementujme teď, zkononalujme později.

Asi sem obycejnej ceskej prostacek a u pana Jack Stack bych nemel sanci, ale todle se me moc nelibi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  13. 05. 2003 13:21  | 

Kvalita je zbytecne draha. Zakaznik radsi koupi levnejsi produkt pred kvalitnejsim. Prikladu je nespocet, pro zacatek treba x64 a IA-64 - Itanium ma nesporne lepsi architekturu ktera se poucila z chyb x86, x64 je jen 64bitova x86, se vsema spatnejma vlastnostma ty architektury. Ale je levnejsi a proto v konecnym dusledku bude vic pouzivana (uspesnejsi?).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  13. 05. 2003 13:52  | 

To sice plati, ale ne nutne. U drazsiho produktu musite zakaznika presvedcit, ze se mu jeho koupe vyplati, ze za pridanou cenu dostane pridanou hodnotu. Pokud to nedokazete (bud jste spatny obchodnik, nebo dobre vlastnosti produktu proste nejsou v praxi potreba), tak neprodate.

Krasny priklad je treba velikost disku. Kdysi se delaly velke "kravy" 5'1/4. Pak se preslo na 3 1/2. A logicky se zdalo, ze vyvoj bude pokracovat k 2 1/2. Dokonce do Amigy 1200 se 3 1/2 vesla jen za cenu urcitych uprav. Ale nepreslo se a dodnes se delaji (krome notebooku) 3 1/2, proste proto, ze ten palec rozmeru uz neni tak podstatny, aby vyvazil vyzsi cenu...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  13. 05. 2003 21:27  | 

Ale vzdyt to sem psal. Zakaznik preferuje cenu pred kvalitou (a cimkoli jinym). Prestoze maly disky budou rychlejsi (mensi vzdalenosti pri seekovani) tak jejich cena zakazniky odradi bez ohledu na cokoli jineho. Kdyz uz sme u tech disku - SCSI versus IDE, SCSI je taky neporovnatelne kvalitnejsi, ale o kvalitu nejde, jde o cenu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Prome  |  13. 05. 2003 22:50  | 

neni pravda, podstatny je pomer kvalita/cena nikoliv pouze kvalita nebo cena  

Souhlasím  |  Nesouhlasím  |  Odpovědět
Michal Kara  |  14. 05. 2003 07:51  | 

Viz predchozi odpoved - jde o pomer kvalita/cena. 3 1/2 byly take (minimalne ze zacatku) drazsi a presto se prosadily. Take jde o to, ze cenu je schopen zakaznik porovnat velmi rychle, kdezto u kvality to tak jednoduche neni.

SCSI vs IDE naopak ukazuje ze zalezi na (pro zakaznika) "vyuzitelne kvalite". Kupovat si do domaci herni konzole SCSI je nanic. Ale do trochu vic vytizeneho serveru na kterem mi zalezi bych IDE nedal.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  14. 05. 2003 19:04  | 

Kvalita/cena je dulezity pro business, ne pro domaciho uzivatele (proste jednotlivce, nevim jak to popsat). Vsechny nove technologie sou ze zacatku drazzsi, ale prosadi se az pote co jejich cena klesne (coz je pripad disku, vypalovacek, DVD mechanik a tak dal). Spousta technlogii na to dneska jeste furt ceka, prestoze jejich kvalita/cena pomer je o dost lepsi nez existujici favorit, prikladem budiz treba cena DVD vypalovacek versus CD vypalovacek, LCD monitoru versus CRT, DSL/Cable versus dial-up a tak dal...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 13:23  | 

Ano, to je právě ten zásadní rozdíl - nám se tenhle přístup moc nelíbí, zatímco pro Američany je zcela přirozený. A co je možná ještě překvapivější - chápou to tak i tamní zákazníci. Když jsem pracoval v USA, všiml jsem si, že pokud zákazníkovi poskytnete nekvalitní službu, přijde vám ji asertivně, s úsměvem, leč rezolutně hodit na hlavu. A když mu pak stejně asertivně a se stejným úsměvem poskytnete službu lepší, vůbec v jeho očích neklesnete - je spokojen, protože tak je to prostě běžné. A příště přijde zas. A ještě je potěšen tím, jak ochotně řešíte jeho problém (přestože jste ten problém de facto předtím sám způsobil). U nás je to právě jiné a to je přesně ten rozdíl, o nemž v článku píši.

Souhlasím  |  Nesouhlasím  |  Odpovědět
tibor  |  13. 05. 2003 21:28  | 

a myslis ze je to dobra vlastnost? teda podla mna, na mieste americanov sa nie je s cim chvalit. Nas pristup (myslim, ze aj Slovensko je na tom podobne v tejto oblasti ako CR) sa mi zda ovela ferovejsi a cestnejsi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 23:58  | 

To je právě otázka. Ten přístup evidentně není férový a není správný, prokazatelně však vede k dobrým ekonomickým výsledkům. Záleží, co očekáváte.

Souhlasím  |  Nesouhlasím  |  Odpovědět
nishkam  |  14. 05. 2003 00:35  | 

Ten přístup evidentně není férový a není správný, prokazatelně však vede k dobrým ekonomickým výsledkům.

hmm... zajimave.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr  |  14. 05. 2003 11:22  | 

Ja si predstavuju asi takhle: Jsem zakaznik a koupim si ucetni program, ktery bude vypracovany touhle skvelou metodou (tzn. zabugovany az hruza). Pul roku na nem budu uctovat a on mi tam naseka spoustu chyb. Chybne faktury, proste hruza.

A vyvojovy tym to postupne snad nejak dodela a opravi. Podekuje mi, ze jsem jim to tak pekne otestoval a ja budu mit smulu, protoze oni za to nenesou zodpovednost.

Co myslite, ze bych jako takovy zakaznik udelal? Poslal bych je samozrejme do p****e.

Jestli chcete nadavat na "cesky perfekcionisticky zpusob", tak si uvedomte, ze treba v te bance mate svoje penize a oni tam zacnou pouzivat nejaky nedodelany software. Ono to treba neco spatne vypocita a vy se najednou budete divit, ze vam na konte chybi 30000. Proste proto, ze jsou to lempli co napisou soft a po mesicich ostreho uzivani vychytavaji chyby. A pak se snima hadejte.

Samozrejme nelze cekat, ze bude neco stoprocentni, ale alespon nejaka snaha pred uvedenim na trh by tam byt mela. U Chryslera to ten chlapik podelal a ted o tom napsal knihu a hraje chytreho jak je inovativni. A bohuzel mu to nekteri zerou. Nezapomente, ze americani sou lini jak vsi a ze v USA pise "knihy" kdejaka guma. Bohuzel uz sem s nima taky mel tu "cest".

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin Pegner  |  14. 05. 2003 11:57  | 

Pisete blbosti Petre, tento zpusob "neperfekcionistickeho" programovani neznamena delat SW s chybama... ve vasem priklade to znamena napriklad, ze ucetni SW bude sice spravne uctovat faktury, ale nebude mit moznost vystavit fakturu zalohovou, proformu anebo treba nebude podporovat zrovna vasi tiskarnu privezenou z Japonska... To se da pozdeji doprogramovat... PONJATNO ???

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr  |  14. 05. 2003 12:11  | 

Kdyby se mi to nestalo, tak tyhle "blbosti" nepisu.

To ze si Martine nedokazete predstavit veskere dusledky tohoto zpusobu jeste neznamena, ze se nemuze stat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  14. 05. 2003 12:44  | 

Petře, to, co píšete, podle mě opravdu není na místě: Jack Stack určitě neměl na mysli software, který by odčítal zákazníkům peníze z jejich kont. Jedná se opravdu o nalezení správné hranice mezi dobou vývoje a funkčností výsledku. Tato hranice se ve světě posouvá čím dál více směrem k rychlejšímu dodání.

Vzpomeňte si například na ohromné problémy, které měl se svým účetním systémem při spuštění sítě náš třetí operátor. Nevím, kolik zákazníků operátor v té době nenávratně ztratil, ale jsem si skoro jist, že pokud nějaké ztratil, nebylo to způsobeno chybnými vyúčtováními, ale zamítnutím oprávněných reklamací. A jsme tedy zase u toho amerického přístupu: představte si (dle vašich slov) hypotetickou banku, která jako první nabídne skvělý systém třeba přímého bankovnictví. Tento systém je plný chyb a odčítá zákazníkům peníze z účtů. Odejdou okamžitě zákazníci k jiné bance? Myslím, že ne. Napíší reklamaci. Pokud banka odpoví: "promiňte, došlo k chybě, peníze vám vracíme a jako kompenzaci máte rok vedení účtu zdarma", vzroste loajalita zákazníků možná na dvojnásobek loajality před vznikem problému. Zákazníci zůstanou a banka má prvenství v zavedení služby.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr  |  14. 05. 2003 13:20  | 

A pokud se jim to stane 7x do tydne, tak uz z toho budou na mrtvici.

Uz jste videl u nas banku, ktera se vam omluvi rokem vedeni uctu zdarma? Nejdriv vas budou buz**ovat pri podavani reklamace a pak vam po mesici napisou aroganti dopis, ze sice chyba byla vyresena, ale jste si tim vinen sam, protoze to neumite pouzivat. Asi nechapete jednu vec....zakaznik se nezblazni pokud bude neco o mesic pozdeji, ale zblazni se pokud to nebude fungovat. Tyhle "rychle vyvoje" jsem uz zazil za tu dobu u IBM. Zkuste se schvalne podivat jake updaty a v jakem poctu se u nich vyskytuji.

Mozna jste uz slysel heslo "Prace kvapna malo platna". Byt prvni neni to nejdulezitejsi kdyz to pak v praxi nefunguje. A narazel jsem na toho vedouciho cloveka ve sporitelne, protoze tam je kvalita hodne dulezite meritko. A on si stezoval na perfekcionismus v oblasti chyb. Ne na snahu mit vseho hned kompletni.

Urychleni vyvoje ....... prosim, ale ne za tu cenu aby zakaznik byl obtezovan s testovanim produktu. Bezny zakaznik predpoklada, ze kdyz za neco zaplatil, tak to funguje a nechce slyset vymluvy. Pouze lide co v tom maji alespon naky prehled chapou, ze nelze udelat perfektni veci.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vaclav Kadlec  |  14. 05. 2003 13:37  | 

Vzdyt to je presne to, o cem mluvim! Problem neni v tom, ze banka zavedla produkt obsahujici chyby. Zasadni problem je v tom, jak sam pisete, ze "Nejdriv vas budou buz**ovat pri podavani reklamace a pak vam po mesici napisou aroganti dopis, ze sice chyba byla vyresena, ale jste si tim vinen sam, protoze to neumite pouzivat." Jen se snazim zduraznit, ze KDYBY se omluvili a KDYBY Vam dali ten rok zdarma, problem lezici v chybnem systemu zdaleka nebude tak palcivy. Na tom je prave zalozen ten americky pristup (at uz je dobry nebo spatny - je proste takovy).

Zakaznik se urcite nezblazni, pokud bude neco o mesic pozdeji, ale pokud to v tom mesici nabidne nekdo jiny, poridi si to u nej. A i kdyz to tomu druhemu nebude fungovat, nebude pro nej obtizne si toho zakaznika udrzet (pokud se bude aspon trochu snazit).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr  |  14. 05. 2003 14:25  | 

To je prave KDYBY.

Ale americky model u nas nefunguje (tedy s vyjimkou IBM, ktera se chova jako doma).

Firmy si zpravidla vybiraji software nekolik mesicu a pak ho jeste dlouho testuji nez na nej prejdou. Takze pokud v nem budou zasadni chyby a vyrobce se k tomu nepostavi celem......omlati mu to o hlavu (zrovna takovy problem resime z pozice zakaznika). A ze na to vyrobci kaslou je bohuzel casta praxe a to i v USA.

To je sice skoro totez co rikate Vy, ale s jednim drobnym detailem.....nesmi to byt za ostreho provozu a tudiz po tom co si to uz nekdo koupi a zaplati casto znacne sumy za implementaci apod. Zakaznik, ktery si bude vedom rizika nedokonceneho produktu si jej nekoupi. Lhostejno zda bude o mesic driv nebo ne. Zakaznici vyzaduji reference.

Co rikam je, ze by se v honbe za terminy nemely opomijet testy. Protoze pak muzou nastat hodne velke problemy pro zakaznika a to neni dobre. Viz. M$ produkty.

Souhlasím  |  Nesouhlasím  |  Odpovědět
sss  |  17. 05. 2003 09:25  | 

"Co rikam je, ze by se v honbe za terminy nemely opomijet testy"
XP dost striktne dba na testy (test driven development), a doraz dava na automatizovane.
Najskor napisem testy. Potom spravim program, ktory nimi prejde.
Ked treba refaktorizovat, mam testy, ktore mi otestuju, ze to, co som zmenil este stale funguje.
Ak mam pridat novu feature, tak napisem testy a potom dopisem program.
Tento pristup velmi urychluje vyvoj - chyby sa ohlasia sami.

Souhlasím  |  Nesouhlasím  |  Odpovědět
mkobylan  |  13. 05. 2003 13:42  | 

Toto sa mi zda ako odstranovanie priznakov zleho programovania. Namiesto toho by sa mala odstranovat pricina.

Souhlasím  |  Nesouhlasím  |  Odpovědět
turby  |  13. 05. 2003 14:03  | 

v drtive vetsine pripadu chce zakaznik vyvojem vyresit nejaky zasadni problem a ten byva vetsinou jen jeden ci dva. pokud se mu doda reseni jeho problemu behem nekolika dnu ci tydnu a jeho zasadni problem se tim vyresi bude spokojen a postupne bude doplnovat dalsi pozadavky na funkcionalitu s docela jasnou predstavou co chce. take to znamena malou zatez uzivatelu jelikoz system je velmi jednoduchy a lze ho implementovat a zaskolit behem hodin az dnu.

tohle jsem zjistil a pouzil pri vyvoji systemu pro nase pobocky v EE a cena byla nakonec 20% puvodni planovane (pocitalo se s vyvojem supersystemu, ktery by umel "vsechno" :) a diky jednoduchosti aplikace nebylo nutne ani provadet skoleni v jednotlivych zemich. jen se rozeslal manual o par stranach a instalace :o)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Majlath  |  13. 05. 2003 18:27  | 

"Nejvíc mě překvapuje posedlost dokonalostí, snaha mých českých kolegů vyhnout se chybě." - skuste stravit niekolko rokov v nasich skolach (zakladnych, strednych), kde je akakolvek chyba hned trestana a chvalou sa velmi setri. Potom pochopite omnoho lahsie.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Václav Kadlec  |  13. 05. 2003 23:59  | 

No právě! To je přesně ono, tenhle přístup má u nás hluboké kořeny a používáme jej jaksi podvědomě, protože jsme jím od dětství obklopeni.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Josse  |  14. 05. 2003 15:09  | 

Ta firma, která se řídí heslem "Implementujme teď, zkononalujme později" to dotáhla do takové dokonalosti, že dala světu operační systém. Ovšem v jaké kvalitě. Již několik roků čekám, až skončí implementace a začne dolaďování.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  14. 05. 2003 18:59  | 

Myslis Linux? Protoze pokud vim ten byl taky k dispozici davno predtim nez byl dokonalej... To samy Mozilla a jakejkoli jinej SW projekt (at open nebo closed source, zadarmo nebo za penize).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ashen  |  23. 05. 2003 10:17  | 

Ty ses vul, to snad neni mozny....

Souhlasím  |  Nesouhlasím  |  Odpovědět
Honza  |  03. 06. 2003 15:24  | 

Plne souhlasim, takovyhle ignoranti by se meli strilet...

Souhlasím  |  Nesouhlasím  |  Odpovědět
pepe  |  15. 07. 2003 13:28  | 

ja bych ani nerekl ...
no schvalne, ktery sw byl dodan na trh odladeny a bez chyb?

Petr

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Karasek  |  14. 05. 2003 16:43  | 

...s teroristou muzete vyjednavat...

napsal rexas na penguinu. Za tento vtip stoleti mu touto cestou dekuji.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Richard Musil  |  14. 05. 2003 21:20  | 

Přijde mi, že někdo měl pocit méněcenosti z toho, že nedovede udělat abstraktní návrh a tak svoje zoufalé pokusy se střídavými úspěchy nazval extrémním programováním :).

Teď vážně. Pokud budu něco vyvíjet sám, nebo v pár lidech s relativně velkou samostatností, tak si mohu dovolit, to co se tady popisuje, protože když někdo špatně navrhne datový model tak je šance, že člověk, který psal engine sice zahodí všechno, ale člověk, který psal UI nebo instalaci si bude moci svůj kód ponechat. Přesto bych byl nerad, kdyby se tento přístup považoval za výhodu. Platí totiž, že čím lepší abstraktní návrh a funkční specifikace tím lepší pozice později, kdy se ukáže, že je potřeba něco změnit (ať už proto, že si to přeje zákazník, nebo proto, že jsme to "nějak nedomysleli"). Pak se totiž začnou řešit otázky, co stane, když změníme tady tu funkčnost, co se stane, když změníme tenhle datový model, co se stane, když zvýšíme nároky na systém o tolik a pokud v té chvíli neexistují nějaké (promyšlené) podklady pro původní řešení kde je zdůvodněno, proč jsme se rozhodli pro tohle a tamto, tak se není o co opřít a co zpochybnit a můžeme klidně to co nevyhovuje zahodit, nakódovat to znova a pak se divit, že to zase není ono.

Osobně používám něco, čemu říkám ZLR (zdravý lidský rozum) a to mi říká, že vývoj bude mít tyto fáze:

1) analýza => 2) funkční specifikace => 3) detailní funkční specifikace => 4) implementační specifikace => 5) implementace

Ty šipky je možné chápat tak, že ne vždy to nutně budou všechny fáze, ne vždy to nutně bude následovat po sobě, ale nikdy to nebude napřeskáčku (pokud to tedy nebudu používat v iteracích). Čím víc toho vychytám v bodech předchozích, tím míň toho budu muset zahodit v bodech následujících, a pokud budu něco zahazovat, budu vědět proč a také budu vědět, že když něco zahodím, jaký to bude mít dopad, protože z předchozí analýzy budu mít jasno v tom, proč jsem to začal vlastně vůbec implementovat. Problém s tímto přístupem je ten, že vyžaduje poměrně intenzivní přemýšlení a soustředění a to tím víc, čím je fáze víc vpředu (abstraktnější, nezáživnější). To ne každého baví, ne každý to umí a ne každý na to má. Přimět programátory (nebo obecně vývojáře) aby přemýšleli je nejtěžší věc na celém vývoji (viz Jim McCarthy, Dynamics Of Software Development).

Pokud se to ovšem podaří, je velká šance na skvělý výsledek, protože cílem vývoje není produkt ale ... vývojáři. V opačném případě je výsledkem produkt plně v intencích toho, co je uvedeno v článku.

Souhlasím  |  Nesouhlasím  |  Odpovědět
asdd  |  15. 05. 2003 21:00  | 

omg

Souhlasím  |  Nesouhlasím  |  Odpovědět
Johny  |  16. 05. 2003 09:35  | 

Vyhoda XP je v tom, ze se zacne psat implementace. A prvni implementace se udela hodne rychle a, rekneme, v polohotovem stavu se to ukaze zakaznikovi. Ten rekne, ze takhle si to vubec nepredstavoval. Tak se to znova prepise. A postupnymi iteracemi se dojde k vysledku, ktery se zakaznikovi libi. Tradicni pristup ma nevyhodu v tom, ze zakaznik analyze nerozumi, takze vam na zacatku odkejve, ze to mate dobre. Jenze v posledni implementacni fazi se zmeni podminky a vy vsechno musite predelat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ales Pavel  |  15. 07. 2003 16:56  | 

Kluci ja mam furt pocit ze extremni programovani je i trochu neco vic a tohle co tu autor napsal je vsechno pravda, ale souvisi to hlavne s tim, ze se tam pouzivaji velmi narocne techniky (proto to narocne testovani a opravovani), napriklad je tam vyhnana do extremu dedicnost az do krajnosti. Pak maji vsechny tyhle techniky popsane v clanku smysl, ale je to spis dusledek nez zasada )

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  15. 07. 2003 18:06  | 

Smyslem extrémního programování je prostě udělat něco rychle. Náročné testování a opravování je tam IMHO hlavně proto, že metody extrémního programování mají extrémní tendenci spět k průšvihům, pokud nemáte malý tým, který se dokonale zná, nemáte v něm dokonale zkušené, samostatné a vyzrálé lidi - osobnosti a pokud v týmu nejsou pouze pozice člověk člověku vlkem. To neustále zdůrazňované testování, a proto to neustále zdůrazňované zahazování kódu, je tam také proto, aby se alespoň riziko průšvihu trochu snížilo.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Test 9 bezdrátových reproduktorů

Jak ovládnout Instagram

Test levných 27" herních monitorů

Jak se zbavit nepotřebných věcí na internetu