Historické souvislosti, vznik a obsah Agilního manifestu

Diskuze čtenářů k článku

Bohuslav Roztočil  |  15. 04. 2003 09:19  | 

Nechci napadat myšlenky manifestu; sám zažívám podobné problémy, které se snaží řešit. Nemohu se však ubránit pocitu, že povyšování komunikace nad dokumentaci vzdaluje vývoj software ostatním inženýrským disciplínám. Připadá mi to jako by výsledkem vývoje nového vozu bylo hotové auto a nějaké náčrtky a poznámky. Ale žádné plány.
Možná je software opravdu hodně odlišný. Většina výrobků jsou originály a když je potřeba, vždycky se dají nakopírovat. Jen se mi tak nějak nelíbí, že se něco vyvine a nikdo vlastně není schopen říct proč tímto způsobem, těmito technologiemi, těmito postupy. Je to takové 'aliterární', 'předhistorické'.
No, budu si muset Agilní Manifest pořádně prostudovat. Díky za článek, jinak bych se o něm asi nedozvěděl.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Radek  |  15. 04. 2003 09:45  | 

Myslim, ze dokumentace je zakladni formou komunikace. Jak mezi vyvojovym tymem, tak mezi vyvojari a zakaznikem. Proto musi byt rozdelena do nekolika urovni podrobnosti  a hlavne musi byt srozumitelna.

Souhlasím  |  Nesouhlasím  |  Odpovědět
sss  |  15. 04. 2003 11:05  | 

Projekt 'Vyvoj auta' nie je dobrym prikladom k sw, pretoze produktom projektu 'Vyvoj auta' je technicka dokumentacia auta a pripadne prototyp. Vyroba auta je uz produkcia.
Pre sw je produktom fungujuci sw, uzivatelska a administratorska prirucka ap. Pouzivanie sw je produkcia.
Teda obe inzinierske discipliny robia veci viacmenej identicky.

Dokumentaciou je aj samotny zdrojovy kod (a to nielen poznamky v nom, ale aj funkcna cast) - to su vlastne tie plany na vyrobu auta.

V com su agilne metodologie (AM) ine ako klasicka waterfall (WF) metodologia je reakcia na zmeny. Zmena v neskorsich fazach WF modelu je velmi draha, pretoze sa treba vratit na zaciatok a postupne prejst vsetkymi fazami, aby sa nespravila chyba. AM sa snazi znizit prave naklady na zmeny v neskorsich fazach (XP to napr. riesi automatizovanymi testami a refaktorizaciou).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vaclav Kadlec  |  23. 04. 2003 20:00  | 

Agilní přístupy ani tak nedegradují dokumentaci jako takovou - snaží se spíše zmenšit význam tradičních forem dokumentace (specifikací, plánů apod.) na úkor zdrojového kódu. Zdrojový kód považují za nejexaktnější formu dokumentace.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Radek  |  15. 04. 2003 09:53  | 

Pouzivate pri vyvoji prototypy vyvijene aplikace? Nebo se snazite nejit vsechna skryta mista dukladnym modelovanim v UMLku? Nebo uplne jniak? Zaroven by to melo slouzit zakaznikovi, aby se podival, jestli vubec delaeme to, co on chce. Prece jen u vetsich systemu se neda casto dokoncit predveditelna cast behem tech 2 mesicu a kdyby se melo planovat, jak do reseni zakaznikova problemu jeste doplnit ne uplne funkcni, jen predveditelnou cast, nekolikrat by to podle me cely vyvoj protahlo, znasobilo pocatecni analyzu a s agilnim programovanim by to moc spolecneho nemelo.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Radek Beneš  |  15. 04. 2003 14:17  | 

Hurá hurá hurá - američané objevili Ameriku. Ale vážně a bez ironie. Živím se tvorbou SW od sedmdesátých let minulého století a tento manifest nemohu než podepsat. Za celou svou praxi jsem ještě nezažil jediný úspěšný projekt, jehož finální podoba (pokud vlastně vůbec kdy nějaká vznikne, protože SW buď umře, nedo se neustále vyvíjí a mění) by se přesně kryla s původním zadáním. Celá záležitost má ovšem jeden velmi nepříjemný obchodní aspekt. Stanovte předem cenu projektu, když máte v rukou pouze hrubou představu, jak to celé vlastně bude funguvat a stejně víte, že všechno bude jinak. Tento přístup (a jej používám celou svou praxi) vyžaduje velmi značnou dávku důvěry mezi partnery a navíc je vhodný pouze pro zodpovědné vývojáře s určitými zkušenostmi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vaclav Kadlec  |  23. 04. 2003 19:55  | 

Přesně tak. A kromě toho může být využit jen v takovém prostředí, v němž se nutnost změny již hotového fragmentu (třeba kódu) nepovažuje za selhání. Takové prostředí je jaksi přirozeně přítomno třeba v USA (sebevědomí Američanů je všeobecně známo), problematické však může být jeho vytvoření v našich zeměpisných šířkách.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Karby  |  06. 05. 2003 14:02  | 

Ahoj všem,
několika projekty už jsem prošel (web, intranet, ale i klasické Win app) a v součtu s tímto článkem mám trochu strach. Při představě, že spolupracuji na vývoji dejme tomu intranetové aplikace se SW firmou, kterou jsem si čerstvě najal a která se hlásí k agilnímu přístupu, můžu mít velmi oprávněný strach, že odevzdá mizerné dílo, protože původní seznámení se s problematikou (interními procesy firmy) a následnou analýzu "omezí" podle manifestu. Pak dodají jakousi verzi, dejme tomu půl roku budeme v úzkém kontaktu a vyvine se celkem příjemný intranet.
Až dosud OK, jenže pak mi dojdou peníze, firmu přestanu platit a mám na stole hromadu zdrojáků, které sice pracují, ale už nemám nic moc extra analýzy, návrhy a dokumentaci, abych mohl na projektu dejme tomu interně (nebo s někým jiným) trochu dál pracovat (s nízkým rozpočtem).
Chci říct, že metody SWI jsou předvevším o tom, aby v rámci projektu mohli fluktuovat různí lidé, různé firmy. Aby ti nově příchozí měli odkud začít, pokud není možný přímý kontakt s původními autory.
Takže je fajn, že někdo zformuloval fundovaný protipól k SWI, ale dávejte bacha, připadá mi to jako opačné extrémní křídlo, takže dobré zkušenosti a "klidný život" budou asi někde uprostřed. Nicméně především pro webové aplikace (kterých neustále přibývá) se agilní přístup jeví jako jediný možný, pokud je kladen důraz na rychlé nasazení první verze.

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

Speciál o přechodu na DVB-T2

Velký test herních myší

Super fotky i z levného mobilu

Jak snadno upravit PDF