Programujte agilně, nic jiného vám nezbývá! A nebo ano?

no tak taketo nieco zazivam uz 2 roky. najlepsi zakaznik je taky, co tomu nerozumie vobec, alebo taky, co tomu rozumie uplne. Taky, co tomu rozumie stredne je najhorsi, pretoze tomu sice nerozumie ale mysli si ze ano a citi sa povolany rozpravat vam do roboty. ked sa vam takto zakaznik rype v robote a mudruje vam do toho, (pritom prd vie ale to mu nesmiete povedat:) mate chut ho zabit...

tot vse. nech zije analyza spravena niekym inym (pretoze pochopit co chce klient, ktory sam nevie co chce, to je umenie) a anonymni zakaznici 5000 kilometrov daleko.

preto cely ten software vyzera tak ako vyzera lebo vsetci chcu vsetko rychlo a ked to takto pojde dalej, budu fakt programovat len cinania za hrst ryze.

Moc pěkný článek, jen tak dál.

Hm. Vše, co tu popisujete, je ideální situace. Pusťte se do mě, ale to, že tady v diskuzi použijete kouzelnou frázi "unit test" nic neznamená. Troufám si tvrdit, že my z menších firem důkladně provázaných mezi více subjektů bychom pravidla museli hóódně přizpůsobit. Např. návrh databáze. Udělat změnu v databázi, kterou vám někdo spravuje je takřka nemožné, takže model musíte trefit "napoprvé". Nebo obsluhovaný hardware (vážní nebo dopravní (železnice) systémy), propojení do SAPu, to vše je VELMI špatně testovatelné, ale představuje běžnou náplň práce. Osobně si takřka vůbec nedokážu představit test, který by zajistil, že komplikovaný zápis nebo ČTENÍ (jak automaticky otestovat to, co se jen vytiskne, bez dalších kauzalit?) je neporušen, obzvlášť, pokud závisí na jedinečných podmínkách. Například naše obsluha tavící pece. Těžko vám poskytnou nějakou na hraní - a teď si představte, že by i tu někdo naprogramoval v XP bez dokumentace. Simulátory takřka neexistují - každá je unikát. Zřejmě jsem ale zabrousil do oblasti, která je příliš extrémní. Pro mě ne. A teď raďte...

;o) jasne, XP nie je svaty gral... XP sa niekde da a niekde neda pouzit. Vsetko ma svoje vyhody a nevyhody a urcite by som to nestaval do svetla ze Unified Process je za nami, odteraz uz len XP. To je samozrejme blbost.

Možná se podivíte, ale zřejmě se do Vás nikdo nepustí  Agilní přístupy jsou použitelné jen v určitých situacích a situace, které popisujete Vy, jsou samozřejmě zcela mimo cílovou oblast agilního hnutí. To platí obecně a pro každou konkrétní agilní metodologii nalezneme spoustu konkrétních argumentů: pokud použijeme XP a test unity trvá týden, těžko lze provádět každodenní testování. A nelze-li v XP provádět každodenní testování, nelze používat XP. Tečka. A takhle to funguje u všech. Takže samozřejmě nikdo netvrdí, že tradiční přístupy k vývoji jsou minulostí; třeba takový RUP bude používán ještě hodně dlouho a nikdo nemůže říci, že je to chyba.

V prve rade si nemyslim, ze "agilni programovani" znamena "chaoticke". Tzn. i v takovem pripade musim psat analyzy, dokumentaci apod. Rozdil vidim v tom, ze se snazim psat system po mensich castech a maximalne flexibilni pro budouci zmeny. To jen na okraj.

Ale chtel jsem zduraznit neco jineho. Zakaznik se rozhoduje pro investici do softwarove projektu pravdepodobne z duvodu, ze ocekava jakousi navratnost v rozumnem case. A ted je otazka, zda ten projekt je pro nej natolik kriticky, ze rekneme kazdym cekanim na prvni produkcni verzi ztraci velkou cast potencialnich zisku.
Muze se i stat, ze jeho ztrata nekolikanasobne prevysuje pripadne dodatecne naklady dodavatele softwaru zpusobene vyvojem agilni metodou. (Myslim, ze vyvoj agilni metodou rozhodne nakonec vyjde pro softwarehouse draz)
Chci tim rici, ze je potreba nehledat optimalni reseni jen z pohledu dodavatele, ale predevsim zakaznika. Ono totiz v praxi (a to i ve velkych firmach) je nekdy ta rychlost dulezitejsi nez vyborna kvalita.

Efektem tohoto stylu vývoje je to, že po roce programování přidání položky do menu stojí 3 člověkodny.
Programování tímto style m je ve finále pro firmu výrazně dražší než vypracování detailní analýzy software.
Bohužel to, že mají první modul do měsíce a za sto tisíc láká k představě jak levně ten vývoj pořídili.

To zavisi od stylu programovania. Sucastou XP je aj permanentny refactoring napisaneho kodu (pricom sa spoliehame na unit testy). Ak sa z vyvojoveho cyklu refactoring vynecha, tak potom mate pravdu - ten kod bude o rok velmi pravdepodobne necitatelny. V XP ide o to v prvom rade napisat testy ktore urcuju mantinely spravania sa kodu. Potom spravit kod ktory tieto pravidla splna. Nasledne sa snazit ten kod pomocou refactoringu co najviac zjednodusit a sprehladnit, pricom sa zachova funkcnost (testy su stale ok).

Tady bych nesouhlasil; cílem agilních přístupů není produkovat nekvalitní software, to v žádném případě. Jak je uvedeno v další odpovědi na Váš příspěvek, v průběhu agilního vývoje se průběžně zajišťuje a ověřuje kvalita výsledného kódu, a to jednak refaktorizací (častými změnami kódu bez změny funkce aplikace), jednak testováním, jednak stanovením poměrně striktních pravidel na psaní kódu (prohlásíme-li kód za základního nositele informace, musíme zajistit jeho jednoznačnost a kvalitu), jednak konkrétnimi vývojovými metodami (např. párové programování, v němž jeden člověk píše kód a druhý přemýšlí, je-li tento kód správný z hlediska celkové perspektivy) a jednak zapracováním návrhu do každodenní činnosti všech programátorů. Programování tímto style m může být pro firmu podstatně levnější, než vypracování detailní analýzy softwaru - za předpokladu, že závěry vzešlé z analýzy nebudou za pár měsíců odpovídat realitě. A nebo to může být dražší, pokud budou. Nelze říct jednoznačně ano nebo ne bez znalosti parametrů konkrétniho projektu.

Tento zpusob se uz davno pouziva. Da se prirovnat k pujceni penez.

Ihned budu mit castecne funkcni aplikaci, ale to, co se osidilo, se v budoucnu bude resit dele, tudiz nakladneji.

Bohuzel funkcnost aplikace vyvijene delsi dobu "agilnim" pristupem je katastrofalni a naklady na opravu jsou exponencialni.

Z clanku mam prave pocit, ze pouziti tohoto pristupu je urcene prave pro projekty, u nichz je budoucnost jen tezko predvidatelna. Tedy nema cenu premyslet o tom, zda se v budoucnu bude neco resit dele a nakladneji, kdyz nevim, jestli vubec nejaka takova budoucnost bude. Zmeni-li se pozadavky na funkcnost, ci dokonce nejakou funkcionalitu shleda zakaznik nepotrebnou, pak nebudu v budoucnu nic resit a usetril jsem cas (ktery mohu treba venovat na prepracovavani jinych casti). V tom vase prirovnani kulha (penize musim vratit _vzdy_ - i s urokem).

No to bych zrovna netvrdil, kdyz programujete slusne a mate slusne zaklady, dokazete delat podobne kousky bez problemu. Ono vsechny ty tridy maji sve opodstatneni, tam se vam nestane ze neco zmenite a ono to shori - ne pokud nebastlite :)

Ano, presne to jsem se snazil v clanku naznacit a o tom opravdu jsou agilni pristupy. Nejvhodnejsi jsou pro projekty s nejistym nebo menicim se zadanim. Otazkou ovsem je, jak stabilni je zadani u beznych projektu; pozadavky se meni skoro vzdy a budoucnost projektu je nejista take velmi casto.

to by me fakt zajimalo. V tom co jste popsali bych rekl v nicem ... A at uz Rational Unified Process nebo eXtreme Programming (alespon v nekterych rysech) je IMHO docela pouzivanej - bohuzel jde podle me dobre aplikovat jen an vyspelejsi programovaci jazyky a prostredi - treba na Javu .

RUP je velmi komplexní, propracovaná komerční objektově orientovaná metodologie pro vývoj softwaru. Ponechme teď stranou skutečnost, že RUP jde opravdu do hloubky (odpovídá i na otázky "jak konkrétně udělat tento krok", zatímco běžné metodologie - včetně agilních - odpovídají spíše jen na otázky "kdy udělat tento krok a jak k němu přistoupit"). RUP je představitelem tradičního, konzervativního přístupu k vývoji (i když díky nesmírné přizpůsobitelnosti a komplexnosti RUP je možné jej přizpůsobit prakticky jakémukoliv týmu, projektu a vývoji). RUP sice představuje iterativní způsob vývoje, ale pořád se striktně dělí do oddělených fází a kroků. Naproti tomu XP je typickým představitelem agilní metodologie; k vývoji přistupuje netradičně a progresivně: znehodnocuje význam dokumentů a oddělených vývojových fází. Podrobnosti o obou metodologiích budou uvedeny v některém z příštích článků na toto téma :)

No, me spis pripada, ze v XP nejde ani tak o nejakou rychlost. mam knizku od Kenta Becka a nevzpominam si, ze by se tam mluvilo o rychlosti. Ovsem XP svou metodikou tak nejak zrejme samo asi zpusobuje, ze vyvoj jde rychleji. Samozrejme, zalezi na programatorech. Beck pise, ze aby jsme programovali skutecne extremne, musime uplatnit vsecky prvky XP, ale ty hlavni (aspon to tak vyznelo) jsou programovani v paru (a vubec neomezena komunikace tymu) a psani automatizovanych testu pred vlastnim programovanim.

Stejne je ale i pri tomhle pristupu si uz na zacatku stanovit nejake hranice a ramcovou celkovou funkcnost projektu. Jinak se stane, ze po case zacne byt architektura SW neodpovidajici jeho funkcnosti coz se projevi potrebou sahodlouhych prepisovani pri byt i pomerne jednoduchych zmenach.
<P>
Proste program se dostane do klasickeho stavu ze clovek sahne na jednu funkci a nejaka uplne jina tim prestane fungovat. Tak opravi tu a prestane fungovat zase neco jineho.

Což se stane přesně tehdy, když programuje bez analýzy a kterýmu nejsou cizi side-effecty ve funkcích. Což je mimochodem typická začátečnická chyba.

Duraz na automatizovane testy. Pokud necham program projet testem a vse slape jak ma, je to OK. Potom se nebojim udelat i vetsi a radikalni zasah do nekolik let stareho kodu. Zakaznik vetsinou nic nepozna, pouze zlepseni napr. odezvy.

Ano, stanovení hranic a rámcové funkčnosti je nezbytné a nezpochybnitelné. Podstata agilních metodologií tkví v tom, že (když to trochu přeženu) kromě těchto hrubých rysů se už nestanovuje nic jiného - žádné příliš podrobné funkční specifikace, žádný příliš robustní návrh: promýšlí se vždy jen jeden (nebo několik málo) budoucích kroků (např. vývojových iterací) a další změny se zapracovávají průběžně. Některé agilní metodologie, jak uvidíte z dalších článků, jdou dokonce tak daleko, že prohlašují: je lepší v budoucnu přepracovat celý datový model, než nad jeho návrhem dnes ztratit zbytečně týden. Na první pohled to vypadá opravdu nesmyslně, ale v důsledku to má něco do sebe. To je ale na podrobnější rozbor.

Zajimave, ale uvidime, jak to bude vypadat v praxi. Dokazi si pouziti teto metodologie v relativne malem, mladem, progresivnim tymu vyvojaru, ale ani nahodou napr. v molochu typu PVT, ktery existuje snad jen ze setrvacnosti a personalnim srustem vedoucich pracovniku se statni spravou!

Skutecnosti je, ze odrazi potreby skutecneho vyvoje, ale bude asi jeste nejaky cas trvat, nez se v nejake forme stane obecne platnou. Kdyz si napriklad vezmeme, jak dlouho trvalo, nez se obecne prosadil objektove orientovany pristup k modelovani a programovani od teorie (70. leta) do siroke praxe ...

Během své programátorské praxe ( cca 7 let ) jsem se ani s jiným přístupem než s tím,co je zde nazváno agilní programování, nesetkal.
A že jsem dělal na dost velkých projektech! Pokud se chcete programováním živit, tak to ani jinak nejde. Klient nepotřebuje dokonalý SW, potřebuje sice ne zcela optimální, ale plně funkční, ale především ho potřebuje rychle. Při vývoji "dokonalého" SW se může stát, že vám klient "umře"(malé firmy), změní se u něj management IT, který má úplně jinou představu o použité technologii (velké firmy) nebo již velkou část "dokonalé" funkčnosti nepotřebuje, ale naopak potřebuje novou funkčnost, kterou než "dokonale" vytvoříte, bude již opět nepotřebná. Člověk sice z vývoje takto nedokonalého SW nemá moc dobrý vnitřní pocit, ale taková je realita.

Zkuste tímto způsobem programovat pro instituce typu banka, pojišťovna. Co týden, čtrnáct dní malá aktualizace, co čtvrt roku větší. V tak krátké době nelze provést bezpečnostní analýzu ani slušné testy kódu.

Agilní programování lze použít, dle mého názoru, pouze na projektech menšího rozsahu.

Blbost - kdyz budu mit unitovy testy napsany od zacatku a budu je i psat v prubehu aktualizaci, vysledkem bude vyrazne stabilnejsi kod s minimalnim mnoztvi chyb a pritom se programeri nebudou bat delat i radikalnejsi zasahy do dejme tomu 2 roky stareho kodu.

Mimochodem nevim co je podle vas projekt mensiho rozsahu - ale treba Eclipse (IDE pro Javu), NetBeans (IDE pro Javu), JBOss (J2EE aplikacni server) jsou priklady relativne velkych projektu, ktere pouzivaji alespon nektere rysy (automaticke testy) tohoto pristupu (i kdyz AFAIK zadny z techto projektu to nenazyva agilnim programovanim)

Myslíte? V bankách se většinou řídí dle normy ISO 17799, která určuje jisté mantinely pro bezpečnost. Tak časté aktualizace si prostě málokterý administrátor velkého systému dovolí. Do produkce se implementují většinou v cyklu vývojová, testovací a až naposled produkční databáze.

Nezlobte se, ale to jsou pro mne příklady menších systémů. Za větší považuji produkční systémy typu Oceanic (pojišťovny), DI (banky) apod. Tady se asi neshodneme, velikost je opravdu relativní.

OK - velikost je opravdu relativni a je fakt ze nejaky IDE o velikosti cca 120MB zapakovanej archiv lze povazovat za maly produkt.

Ale souhlasim s tim, ze caste aktualizace u produkcniho systemu jsou nesmysl - nicmene prave rozsahle unitovy testy vyrazne zkrati cas pro testovani ve vyvojovym i produkcnim cyklu - tzn. ty updaty za stejny cas mohou byt rozsahlejsi ....

To ano, myslím, že se shodujeme.

No zrovna Oceanic je pripad software, na kterem si vylame zuby jakakoliv organizace systematickeho vyvoje ).

:o))) Zdá se, že ho znáte... I když si myslím, že i ten by se dal ustát. Ale stojí to zatraceně úsilí...

Ano, ale nelze zaměňovat použití unitových testů s kompletním agilním přístupem (ať už jakýmkoliv - XP, SCRUM, Crystal, FDD apod.): autoři agilních metodologií si vcelku zakládají na tom, že buď se jejich metodologie použije kompletní a nebo se nepoužije vůbec. Kent Beck třeba píše, že pokud mu někdo řekne "jedeme plně podle extrémního programování, jen ty testy zatím neděláme, ale naopak máme stostránkovou specifikaci", pak je to jistě zajímavý počin, ale nelze to prohlásit za nasazení XP. To jen na okraj - kompletní agilní metodologie je skutečně použitelná spíše pro menší projekty.

Máte pravdu - vidíte to stejně jako zakladatelé agilního hnutí: tyto přístupy skutečně nejsou dobře použitelné pro rozsáhlé projekty.

Je to přesně tak, jak říkáte. A kromě toho všeho (klienti spěchají, požadavky se mění apod.) agilní metodologie jsou založeny na snaze vést programování v souladu s lidskými instinkty: co chtějí lidé? K čemu intuitivně směřují? Od samého pravěku programování mají programátoři tendenci po získání zadání bezprostředně usednout k počítači a začít kódovat. Tento naivní "hurá" přístup samozřejmě nevede k rozumné a ekonomické tvorbě softwaru (snad s výjimkou opravdu malých systémů), nicméně tradiční softwarově-inženýrské techniky se snaží prosazovat pravý opak a nutit lidi, aby se věnovali zdlouhavým analýzám, návrhům a specifikacím. Agilní přístupy nejdou do opačného extrému, ale snaží se využít i v tomto ohledu lidský potenciál (nazvěme to možná raději lidské nadšení) - s tím, že návrh samozřejmě není vynechán, jen probíhá průběžně a současně s kódováním.

Ano, agilní programovací metodologie jsou obecně určeny spíše pro menší týmy a nepříliš rozsáhlé projekty. Například Kent Beck, autor extrémního programování (XP), jasně uvádí, že XP určitě nebude fungovat pro stočlenný tým; že pravděpodobně nebude fungovat ani pro dvacetičlenný tým, ale že pro desetičlenný by fungovat mohlo. Osobně si myslím totéž - v PVT, v České spořitelně, v Českých drahách ani v jiné podobně rozsáhlé organizaci nelze o agilním vývoji seriózně uvažovat.

jen tak neco placnu: PLAAAC

http://zive.dev.cpress.cz/programujte-agilne-nic-ji... ...

neco

http://www.math.fme.vutbr.cz/Default.aspx...

xxx a jeste jedno

http://www.google.cz/search...

Příspěvek byl 15× upraven, naposled 17. 09. 2009 14:37