Přejít k navigační liště

Zdroják » Různé » Agilní vývoj: Úvod

Agilní vývoj: Úvod

Články Různé

K tomu, aby byl člověk dobrým programátorem, nestačí znát jen programovací jazyky a mít praxi. Opravdový vývojář se neobejde bez znalostí v dalších oblastech, například metodiky práce. Jedním z nejdiskutovanějších pojmů v této oblasti je takzvané Agilní programování. V tomto seriálu si ukážeme, že nejde jen o módní výraz.

Seriál: Agilní vývoj (3 díly)

  1. Agilní vývoj: Úvod 11. 12. 2009
  2. Agilní vývoj: Scrum 18. 12. 2009
  3. Agilní vývoj: Getting Real 23. 12. 2009

Text tohoto seriálu vychází z práce Jiřího Knesla o řízení agilních týmů pro BIBS. – pozn.red.

Software lze vyvíjet celou řadou způsobů. Ať už se jedná o tzv. Waterfall model (klasický přístup, od analýzy přes návrh a betaverze k finálnímu produktu) nebo o agilní metodiku, je nutné, aby manažer tým analytiků, vývojářů a testerů koordinoval, bral v potaz zájem klienta a zároveň kladl důraz na kvalitu a produktivitu samotných pracovníků. Protože jsou světy agilních a neagilních týmů poměrně oddělené a zároveň velmi komplexní, zaměříme se na jednu z oblastí. Tedy na agilní metodiky, jejich vliv na produktivitu a také na to, jak agilní metodiky v týmu podporovat.

Agilní metodika a Agilní technika

Přestože se tyto termíny často zaměňují, nebo dokonce považují za totéž, ve skutečnosti se jedná o rozdílné (jakkoliv propojené) oblasti s naprosto rozdílnými významy.

Agilní metodika je způsob rozvržení a ověřování práce. Cílem Agilní metodiky bývá lepší organizace práce. Odlišné Agilní metodiky vedou k odlišným produktům, protože považují jiné aspekty produktu za klíčové. Liší se i přístup ke změně zadání. Možnost změny zadání je ale určující podmínkou Agile:

“Agile is the ability both to create and respond to change in order to profit in a turbulent business environment.”

Agilní technika je naproti tomu konkrétní postup, který se většinou týká samotných vývojářů. Cílem těchto technik bývá zvýšení produktivity práce, odstranění chyb, kvalitnější software nebo přesnější dodržení specifikace. Agilní techniky jsou od metodik oddělitelné. Cílem Agilní techniky bývá kvalitnější produkt.

Rozdíly mezi agilní metodikou a technikou:

  • Agilní metodika se zaměřuje na organizaci práce bez ohledu na to, zda se ve firmě vyvíjí software, nebo se jedná o jinou oblast, kde lze agilní řízení uplatnit.
  • V agilní metodice je kladen důraz na možnost změny, agilní technika nic takového nevyžaduje.
  • Agilní metodika se týká nejen vývojářů, ale i managementu.
  • Agilní technika je konkrétní činnost (především vývojáře, může se ale týkat i například klienta).

Agilní metodiky i agilní techniky historicky vycházejí z Agile Manifesto. Tento manifest vznikl na bázi dlouholetých zkušeností špičkových vývojářů, analytiků zdola nahoru. Tedy managementu navzdory. Přesto se postupy z něj vycházející osvědčily, protože řeší následující problémy:

  • Ubude práce manažera a tým přitom zlepší svou výkonnost. Jeden manažer je schopen uřídit více zaměstnanců, větší produkt, nebo se více zaměřit na kvalitu. Ať už je to povahou sebeřízení, tím, že se nepíší mrtvé dokumenty nebo tím, že manažer má stejně v průběhu iterace omezené pravomoci.
  • Je předem známo, kolik práce je tým schopen udělat (v časovém rozsahu jedné iterace). To proto, že z minulosti je známo, jaká je rychlost v jednotlivých iteracích. Protože se zároveň dělají časové odhady na co nejkratší úkoly, je možné řídit rychlost týmu.
  • Změny zadání za běhu (což je například pro klasický Waterfall model naprosto neřešitelný problém)
  • Zrychlení doručování produktu od vývojáře k zákazníkovi (protože klientovi produkt doručujete po každém běhu – zákazník se navíc často účastní běhu firmy)
  • Garance kvality (pomocí automatizovaných testů)
  • Odstranění třecích ploch mezi produktem a vývojáři.
  • Omezení rigidních procesů ve prospěch komunikace (jakkoliv Agile proti dobře nastaveným procesům nejdou – pouze omezují ty procesy, které brání efektivitě, komunikaci a agilnímu přístupu k práci)

Fáze celého projektu v agilních metodikách

  1. Nultá iterace – první krátká analýza a naprogramování nějaké základní činnosti. V agilním týmu nejde příliš o to, co se v této části bude implementovat. Podmínkou je, aby na konci byl hotový kousek aplikace, který se dá předvést (tedy i klientovi).
  2. Analýza změny (výběr toho, co se bude implementovat, analýza a designování změn).
  3. Samotná implementace požadované vlastnosti (či vlastností).
  4. Předvedení klientovi.
  5. Pokud není produkt hotov, zpět na bod 2.
  6. Pokud ano, následuje údržba, rozvoj (rovněž v iteracích).

Body 2–4 se označují jako jedna iterace. Tyto body se opakují tak dlouho, dokud není vývoj ukončen (úspěchem, odložením projektu, proto, že dojdou peníze, změnou priorit klienta).

Zajímá vás Zend Framework nebo unit testování? Chcete se dozvědět víc? Autor článku Jiří Knesl pořádá školení na tato témata. Více informací naleznete na stránce školení Zend Frameworku.

Fáze jednotlivých iterací

Jak jsme si uvedli v předchozím textu, samotná iterace se skládá z analýzy, implementace a předvedení klientovi, přesně v tomto pořadí. Nyní si jednotlivé iterace rozebereme, protože právě v nich tráví tým nejvíc času.

Analýza změny

V této fázi dostane analytik (nebo celý tým) k dispozici priority klienta pro další iteraci. Právě v tuto chvíli se rozjíždí analýza. Někdy se předem ví, co se bude vyvíjet příštích několik iterací nebo zůstaly nedokončené práce z předchozí iterace. Pak se smí zohlednit i úpravy pro lepší kompatibilitu s dalšími změnami. Je stanoveno, které práce se mají provést.

V této fázi se používá velmi často prototypování, aby se vyjasnilo, jak má vypadat výsledek. Analytici (a programátoři) upravují model tak, aby vyhovoval změně. Rovněž se připravují akceptační testy, změny datových modelů, úpravy a přidávání (či mazání) logiky, úpravy pomocných knihoven atd. Samotná analýza sice nezabere příliš mnoho času, ale nemělo by se kvůli ní příliš otálet. (Pro případného zájemce o hlubší informace je vhodná např. přednáška Scotta W. Amplera, pravděpodobně největšího guru agilních metod, na IANA Local Conference 2007)

Implementace změny

V této části se plně uplatňuje samořízení týmu. Rolí manažera je pravidelně kontrolovat plnění úkolů, komunikovat změny do další iterace, odstraňovat problémy, které brání vývojářům při práci. Agilní přístup roli manažera zásadně omezuje na rovnocenné postavení s týmem, kde všichni společně pracují na jedné věci, a to na dodržení obsahu na čas.

V této části má manažer méně nutné práce s týmem. Zároveň je tato sekce nejdelší. Týmy jsou často tak dobře sebeřízené, že se dokonce role manažera redukuje na 1 hodinu denně (a to tehdy, kdy manažer zastává jednu z přímo zainteresovaných rolí – sebeřízení, přistoupí-li klient na platby za iteraci, může vést k tomu, že je manažer v týmu nadbytečný).

Předvedení zákazníkovi

Pravidlem je, že zákazníkovi se ukazuje pouze skutečně dokončená práce, všechny nehotové vlastnosti se musí skrýt z grafického rozhraní pryč. Zákazník tedy musí mít před sebou viditelné změny (když ne změny v rozhraní, pak se může například jednat o urychlení aplikace apod.). O všech nedodělcích tedy zákazník ví. V této části by měl zákazník zhodnotit změny za daný běh a vybrat, co se bude implementovat dál.

V příštích dílech se podíváme podrobněji na metodiku Scrum, na metodiku Getting Real a na některé Agilní techniky.

Komentáře

Subscribe
Upozornit na
guest
36 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
xx

Přijde mi to jako spirála, jaké jsou rozdíly vůči spirále?

Mj. pochybuji o tom, že je možné garantovat kvalitu pomocí testů,
ledaže byste otestoval všechny možné případy.

balki

Ano, je to jedna z metodik vyuzivajucich spiralu. Rozdiely voci ktorej spirale myslite ?

Kvalitu pomocou unit testov nejde zarucit, ale ide dokazat, ze sa nepokazilo to, co prave sledujeme. Napriklad, ci sa nepokazilo to, co fungovalo.

A co sa tyka akceptacnych testov, tie maju zarucit to, ze to zakaznik podpise a nevymysla dalej :)

Jiří Knesl

Samozřejmě psaní testů nezabrání chybám zcela. To je u většího kusu software snad i nemožné.

V čem testy pomohou?

při test driven developmentu:
– vzniká testovatelný kód (což je samo o sobě jedno z měřítek kvality kódu, jakkoliv zdaleka ne jediné)
– jsou nejčastější use-cases otestované (opět – při zadání speciálních parametrů apod. může k chybě dojít)
– zkušený vývojář už sám na sobě ví, v kterých oblastech dělá nejčastější chyby (a tam těch testů napíše podstatně víc)

při hledání chyby:
– se napíše test reprodukující chybu, takže se ověřuje, že se chyba v nějakém budoucím commitu nevrátila (což se děje velmi často, co si budeme povídat)
– mohou testy pomoci při lokalizaci chyby, zejména unit testy, které často hledání problému omezí na jednu třídu (a třídy psané pomocí TDD bývají většinou velmi malé a jednoduché, proto hledání chyb v nich nebývá až takový problém)

při deploymentu nové verze:
– jsou akceptační testy výborné. dokonale ověří, že je možné např. zaregistrovat se, přihlásit, vložit zboží do košíku a objednat. takové testy mohou potenciálně zabránit obrovským ztrátám (jak ve směru finančním, tak i v oblasti důvěry zákazníka)

Testovat lze ale celá řada dalších oblastí. Výkon, bezpečnost, použitelnost, konverzní poměry (ano, lze to i automatizovat).

xx

> Samozřejmě psaní testů nezabrání chybám zcela. To je u většího kusu software snad i nemožné.

Ale v článku máte „Garance kvality (pomocí automatizovaných testů)“.

Já samozřejmě nechci tvrdit, že je to k ničemu, na druhou stranu je třeba zdůraznit, že to rozhodně negarantuje bezchybný výsledek.

> zkušený vývojář už sám na sobě ví, v kterých oblastech dělá nejčastější chyby (a tam těch testů napíše podstatně víc)

Na druhou stranu, pokud testy píše sám, tak typicky nepíše testy tam, kde si myslí, že to funguje, což může být problém.

TrSek

Iste ak vyvojar pise sam sebe tesy moze to mat neblahe dosledky. Hlavne ak ten vyvojar za nic nestoji. Vtedy s velkou pravdepodobnostou odflakne aj testy.

Na druhu stranu ked raz najdem chybu (ja alebo zakaznik) tak napisem test ktory mi tu chybu odhali. To sa velmi hodi pri opatovnom testovani. Pretoze chyby maju tendenciu sa vraciat (ako to uz niekto pisal). No a neviem ako vy, ale mna vzdycky boli ked musim vysvetlovat ze tam mam zase chybu ktoru som tam mal obverziu a v tej minulej bola odstranena. Vtedy sa citil ako fakt blbec.

Jiří Knesl

Pokud ten vývojář za nic nestojí, měl by pracovat formou párového programování, minimálně dokud za něco stát nebude.

Ad testování v případě chyby – ano, toto je jedno z velmi dobrých využití pro testy.

Jiří Knesl

> Ale v článku máte „Garance kvality (pomocí automatizovaných testů)“.

Kvalita je intenzivní veličina. Můžeme mít vyšší kvalitu i nižší kvalitu. Unit Testy garantují kvalitu tam, kde je kód pokryt testy. Pokrývat testy 100 % by nebylo efektivní.

> Na druhou stranu, pokud testy píše sám, tak typicky nepíše testy tam, kde si myslí, že to funguje, což může být problém.

Záleží na postupu. V TDD bych si troufnul říci, že se testy píší správně. Samozřejmě zabere nějaký čas se to naučit, aby člověk skutečně psal „testy, které testují“ a ne jen „testy pro testy“.

HerrFranz

Je schuzka/porada, kde nikdo nesmi sedet. Dusledek: mluvi se k veci a tim padem to ma clovek driv za sebou :)

Ad unit testy – kvalita se neda „vtestovat“. Ale regresni testy se fakt hodej.

X

„V agilním týmu nejde příliš o to, co se v této části bude implementovat. Podmínkou je, aby na konci byl hotový kousek aplikace, který se dá předvést (tedy i klientovi).“

Martin Malý

Oxymoron není. Zkuste si to přečíst takto: „Na konci musí být hotový kousek, který předvedeme klientovi, a je jedno jaký kousek konkrétně to bude“.

biq

tiez je jedno kusok coho to bude ……:D

balki

Skoda ze nejde hodnotit clanky na zdrojaku, dal by som mu 1. Clankov o metodikach vyvoja softveru je malo. Prevazuje vacsinou cista koderina.

Nechcem koderinu zhadzovat, dobry koder je na nezaplatenie. Ale vacsinou si aj profesionali neuvedomuju, ze len dobri koderi nestacia a povazuju vsetko okrem programovania za druhorade a zbytocne.

rooobertek

Toto keď raz budem ovládať… Za to by som dal aj dvojročný plat, aby ma to niekto naučil.

Ped

Easy to learn, hard to master. ;)

„Naucit“ sa scrum/tdd/xp/… je otazka par vecerov a trochy citania na webe.

Uspesne ho pouzivat v praxi, to je uz zlozitejsie. Ale ono je aj zlozite efektivne vyvijat lubovolnou inou metodikou, takze ak mate aktualne team fungujuci na „hura systeme“, tak je jedno na aku metodiku skusite prejst, problemov s prechodom si uzijete dost (ale hura system podla mna treba zrusit za kazdu cenu). Ak mate team ktory funguje neuspesne na „waterfall“, tak nemozete cakat ze agile vas zachrani, je potrebne najskor zistit preco nefunguje waterfall metodika, a co z toho agile pomoze odstranit alebo naopak nebude fungovat ani tam. Ak mate funkcny team na inej metodike, bol by som velmi opatrny s prechodom. Je dobre ine metodiky poznat, pripadne aj skusit, ale stale plati stare dobre „ak nieco funguje, nemenit“.

Inac agile vs waterfall v pripade ze oba modely funguju efektivne, tak su IMHO rovnocenne, ale z osobnej skusenosti by som povedal ze na vacsinu zadani ku ktorym sa firma vyvijajuca SW dostane je vhodnejsia agile metodika. Podla mna len mensina zadani je dostatocne statickych na to aby waterfall mohol fungovat efektivne. Ale zaklad je mat aspon nejaku metodiku a vediet ju vyuzit.

rooobertek

Náš tím funguje na spôsob „omfg“ = nefunguje ani po pár pokusoch o zmenu. Chýba niekto, kto by tieto veci ovládal v praxi. Aj keď najnovší maník by hádam mohol s týmto volačo…

Ped

No ja mam prax z vlastnych projektov, kde je pocet ludi 1~3, ale zaklady su rovnake aj pre vacsi tim, takze to by nebol problem vas naucit.

Problem je v tom, ze podla toho co pises, mate podla mna hlbsie problemy v samotnom time (a vedeni), ktore samotne „agile skolenie“ nevyriesi.

Ak ste mysleli ten dvojrocny plat za to ze vam niekto spojazdni cely tim, tak to chapem, ak to bolo za naucenie „agile“, tak to kludne spravim za zlomok tej sumy… :P :D

Inac nevidel som velmi vela naozaj funkcnych a efektivnych timov, takze sa netreba bat si priznat ze nieco nefunguje, maloktora firma funguje idealne. Dolezite je mat nastroje ako merat ci tim funguje a ako velmi funguje, ako najst jeho najvacsie problemy a ako na nich potom pracovat a situaciu zlepsit. Ked pravidelne vylepsite ten najhorsi problem, tak casom ostanu bud len nove velke problemy, alebo take ktore su v porovnani s povodnymi „drobnosti“.

TrSek

Developer:
1. Bude to zo zaciatku stat neake peniaze.
2. Bude potreba obetovat neaky cas mozno ludi ktory sa tomu budu venovat.

Vedenie:
Tak toto nie, potrebujeme pracovat a nie venovat sa …

Ped

V takej firme je vhodne zvazit vypoved a ist niekam kde vedenie chce aby im firma fungovala a generovala zisk. Alebo sa viezt dalej a pracovat aspon na sebe, ale riskujete stratu sebeucty a profesionalnych schopnosti a vobec chuti zit.

rooobertek

Presne ste to vystihol. Priamo do čierneho, za 100 bodov a ešte krát desať.

biq

to ako ze im zoberu klavesnice ?

JS

Neverim na Agile. Podle me je to buzzword, ktery neprinasi nic noveho. Cetl jsem Agile Manifesto, a tam jsou triviality typu:

„Business people and developers must work together daily throughout the project.“

„Build projects around motivated individuals.“

„Working software is the primary measure of progress.“

Ze bychom tohle nevedeli? Uz jenom to, ze prejmenovali spoustu veci vzbuzuje pochybnosti (podobne jako tzv. navrhove vzory). Proste, od Brookse nic noveho.

Vsechno, co se rika v tom manifestu lze aplikovat i na vodopad. Jasne, ze je levnejsi, kdyz se chyby v navrhu najdou driv. Jasne, ze je lepsi, kdyz si nejdriv udelate prototyp. Jasne, ze existuje nejaka optimalni doba vyvojoveho cyklu. A tak dale. (O unit testingu mam ponekud pochybnosti – muj nazor je, ze je to obezlicka kolem nedokonalosti programovacich jazyku, ale dejme tomu, mozna je to inovace, akorat nepochazi od lidi kolem Agile.)

Proste, podle me neni uniku – bud budete planovat, a pak vas to bude stat usili navic (vodopad extrem). Nebo nebudete planovat, a pak to bude soustavne dopadat spatne a bude se to muset stale predelavat (agile extrem). Ja na neplanovani neverim.

Druha vec je, ze je tady tato myslenka pochazejici z open source – „release early, release often“. V podstate to souvisi s tvrzenim, ze lide nejlepe pracuji, pokud se organizuji sami. Jenze to jde proti idei hierarchickeho rizeni, a to se managerum nemuze libit; proto se tam daly veci jako SCRUM a podobne hlouposti. SCRUM je zlo. Misto toho, abych jednou za tyden na hodinove porade nekomu vysvetlil, co jsem udelal, to delam jednou za den v prubehu 5ti minut. Na prvni pohled je to totez. Ale neni to totez – v tom prvnim pripade mohu vynechat radu detailu, protoze ze zpetneho pohledu se treba neco ukazalo jinak v prubehu tydne. Kdezto v tom druhem pripade se diskusi techto pitomosti stravi daleko vice casu.

A jeste treti problem – dejme tomu, ze nekdo zavisi na produktu tymu, ktery pouziva Agile. Jejich „embrace the change“ pak ovlivnuje ty, kteri na to spolehaji, a stoji je to mnohem vic prace na vic. Podle me to tedy muze fungovat jenom na projektech do urcite maximalni velikosti, dejme tomu 10 lidi sedicich v jedne mistnosti; pak uz budou tyto „ripple“ efekty ze vsech tech zmen vsech ostatnich tak vysoke, ze prevazi nad tim (slibovanym) ziskem.

Jiří Knesl

Zkusím to vzít popořadě a k věci.

1) Agile manifesto – jen popisuje skutečnou realitu, reaguje na to, že se zadání skutečně často mění a že to není zle, naopak je to správné. Jen agilní tým je připraven po např. roce vývoje eshopu na konci iterace obrátit a začít vyvíjet například informační systém (což je extrémní případ). Agile manifesto mluví o komunikaci, o rigidních procesech. Obecné věty skrývají větší významy. Křesťanům taky nebudete kopat do desatera, když „nezabiješ“ je přeci samozřejmost. (ufff, doufám, že teď v sobě nenajde nikdo dostatek fanatismu, aby mě nařknul z toho, že dělám z agile náboženství) ;)

2) Návrhové vzory – opět jen vychází z reality, z toho, co už tady dlouho je. Jsou to jen kusy kódu, kterým někdo dal jméno. Chybou je „cpát“ návrhové vzory všude za každou cenu, stejně tak je chybou, pokud potřebuji např. factory, říkat tomu „objekt na objekty“, když je pro to celosvětově používaný termín factory. Aspoň si programátoři a analytici lépe rozumí a jsou schopni obsáhnout větší část systému.

3) „Scrum je zlo“ – sám nejsem velkým příznivcem Scrumu, ale některé výborné aspekty se mu přiznat rozhodně musí. Například backlogy, pevná doba iterace, odhadování v bodech a zjišťování velocity týmu jsou vynikající způsoby, jak určit „kolik se toho vlastně stihne“. Časové odhady při hurá-programování mají proti Scrumu přesnost delfské věštírny.

4) O škálování Agile píše prakticky neustále Scott W. Ambler. Možná to u Vás nefunguje, v IBM očividně se škálováním stovek vývojářů podle agilních metodik problém nemají (rozhodně ne neřešitelné).

5) Unit Testy obézlička kolem programovacího jazyka? V čem proboha? Unit Testy se píší „kolem programátora“ (případně „kolem algoritmu“), ne „kolem jazyka“. Pokud nepoužijete jiný přístup (např. design by contract, který se tolik prosazuje v jazyce Eiffel, formální verifikace, která je drahá, nebo živé testování, které je nejen drahé, ale navíc pomalé a nespolehlivé) nemáte žádnou možnost říct: „za těchto podmínek to funguje, tak jak má“. Nehledě na to, že hledat chybu v kódu bez testů je práce pro vrahy.

JS

ad 1. Je mi lito, ale ja Agile trochu jako nabozenstvi vnimam, a zatim me nic nepresvedcilo o opaku. Fakt, ze si Agile jeho zastanci vykladaji dost ruzne, tomu take moc nepridava. Jinak co se tyce desatera, do toho bych se klidne oprel – krome nezabijes a nepokrades, coz jsou zakony platne asi v kazde lidske spolecnosti, jsou ostatni jeho moralni imperativy z dnesniho pohledu v lepsim pripade sporne, v horsim zavrzenihodne.

ad 2. Nevim, proc bych misto factory nemel rikat objekt vracejici objekt. Ted ctu knizku „On Lisp“ od Paula Grahama, a take pouziva „funkce vracejici funkci“, prestoze ta koncepce je znama desitky let. A on neni blbec. Vetsina navrhovych vzoru podle me vychazi z omezeni danych OOP, ze zkratka, pro vas mozna prekvapive, svet nelze vzdy dobre popsat jako oddelene objekty. A stejne jako mi nepripada uzitecne navrhove vzory nejak explicitne pojmenovavat, nepripada mi uzitecne rikat „SCRUM“ misto „status meeting“. Premyslim, jak bych vam asi nejlepe objasnil, co mi na tom vadi. Je to asi jako vsem vyrazum v matematice ve tvaru „sqrt(x2 + y2)“ rikat honosne L2-norma. Zadne zprehledneni nebo hlubsi pochopeni to neprinasi.

ad 3. Nevim, co je hura-programovani; ja to porovnaval s vodopadem. Myslim, ze status jednou za tyden je postacujici. O SCRUMU napisu reakci nize.

ad 4. No, tak by mohl vysvetlit, jak se pak vyporadaji s tim, ze nejaka komponenta, na kterou vsichni spolehaji, nahle (agilne) zmeni chovani nebo API (protoze se nenavrhlo poradne dopredu, nebo se neco nestiha), a vsichni ostatni si to musi predelat. Tak to totiz zakonite musi dopadnout, pokud se neplanuje. A pokud se planuje, pak je to proste vodopad. Nerikam, ze je to neresitelny problem, ale ze to v konecnem dusledku stoji vice penez. A otazka taky je, zda vam nejaka firma rekne do oci „no jo, ta metodika X, co jsme zavedli, to je katastrofa“.

ad 5. Ja osobne si myslim, ze je lepsi investovat do assertu (defenzivniho programovani) a lepsich abstrakci nez do testovani. Myslim, ze benefit je vetsi za stejne naklady (nesmi se to zase prehnat – ne vsechno lze formalne popsat). Tim nerikam, ze testovani nema sve misto, ale v tomto smyslu je to obezlicka. Jazyky jako vami zminovany Eiffel, Haskell nebo Common Lisp tyto veci podporuji lepe nez bezne imperativni jazyky. Misto abychom tedy bezne imperativni jazyky rozsirili o to, co je v techto jazycich dobre, pouzivame TDD.

vkralik

ad 1. Je mi lito, ale ja Agile trochu jako nabozenstvi vnimam
Nabozenstvo == viera v nieco/niekoho.
Zastanci ( a tvorcovia ) agilneho manifestu veria v skustocnosti tam popisovane.
Zastanci povodnych metodik ( ala waterfall ) stale veria v udrzatelnost povodnych pristupov. Agilne metodiky vznikli ako reakcia na neuspechy povodnych metodik. To ci je to spravny smer ukaze cas.

ad 2. Nevim, proc bych misto factory nemel rikat objekt vracejici objekt.

Kvoli dvom veciam :

  1. Spolocny slovnik na dorozumenie s ostatnymi programatormi.
  2. Jednoznacnu definiciu pojmu.

ad 4. … Tak to totiz zakonite musi dopadnout, pokud se neplanuje. A pokud se planuje, pak je to proste vodopad.
Preco tvrdite, ze agilne metodiky neplanuju ? Podla mojho nazoru planuju velmi presne, ale iba veci, ktore sa daju rozumne planovat t.j. do rozsahu jednej/dvoch kratkych iteracii. Dlhsie planovanie by znemoznilo uplatnit jeden z principov agilnych metodik ( reakcia na zmenu ). Predstava, ze podrobne naplanujem dopredu projekt na jeden/dva roky dopredu je naivna.

ad 5. Ja osobne si myslim, ze je lepsi investovat do assertu (defenzivniho programovani) a lepsich abstrakci nez do testovani.
T.j. vzdy viete presne definovat najslabsiu vstupnu a najsilnejsiu vystupnu podmieku pre kazdu funkciu. Ak nie su splnene tieto podmienky, tak program spadne ? Pre mna sa to podoba na matematicky dokaz programu. Takyto dokaz je tazky resp. nemozny. Preto je lacnejsie investovat cas do pisania unit-testov, ktore mi automatizovanym sposobom dokazu, ze zmenou v kode som nic nepokazil a navyse pre dalsich programatorov funguju ako dokumentacia pre pouzitie daneho kodu.

xx

> Takyto dokaz je tazky resp. nemozny

U některých programů samozřejmě možný je.

Ped

Chtel bych rict ze vasi skepsi docela chapu, taky mne ruzne buzzwords dost otravuji, ale konkretne agile & spol. ja osobne az tak cerne nevidim.

SCRUM podle mne ma vyznam. Celkove mnozstvi minut status meetingu se asi zvysi, ale nakonec hlavni meritko je jak v jakych nakladech je schopna firma vytvorit nejaky SW a z tech par ojedinelych vyjimek o kterych jsem v praxi slysel, tak nikdo nemel problem konkurovat klasickym waterfall teamum, spis byly o neco napred.

Unit testy vs defenzivni programovani … o tomhle ja osobne vubec nepochybuji, defenzivni programovani kryje hlavne vady v programu, unit testy (specialne u TDD) definuji i funkcionalitu.
Nemyslim ze by programovaci jazyky byly az tak spatne, staci se podivat na to co produkuji lide v bezne hovorove mluve s rodnym jazykem. Jestli je to chyba jazyka, proc se za ty stovky let nevyvinul do formy ktera takovym paskvilum brani? Ja myslim ze nedokonali jsou hlavne lide kteri ten jazyk pouzivaji. Ne kazdy umi psat kvalitni roman. Ja myslim ze unit testy umozni vetsimu procentu populace psat kvalitni kod, rozhodne vetsimu procentu, nez defenzivni programovani (ktere je uz prinosem proti primitivnimu buseni zdrojaku).
Jestli Eiffel, Haskel nebo Common Lisp umozni tolik pohodlnejsi spravny zapis, proc je nepouziva vetsina programatoru, proc se neusetri tolik na nakladech za vyvoj SW? Ja myslim ze to bude tim, ze ne kazdy je schopny vyhod Haskellu vyuzit, presto muze byt dost dobry na to aby treba s TDD a Javou produkoval dost dobry kod na to aby byl v zisku. Nebudte takovy „elitista“ a uznejte ze kazdy ma pravo na zivot a muze ho zit tak jak on sam uzna za vhodne a ze ne kazdy je schopny zit tak jak mu vy radite. Jestli dokazete tohle akceptovat, pak najednou zacne davat smysl (pro nektere lidi) spoustu veci z TDD/XP/Agile/at­d.. i kdyz konkretne pro vas treba smysl nemaji.

Co je zaroven odpoved na vase obavy o agile v ramci velkych projektu. Kdyz jednou nejaky jiny team potrebuje aby API foo( x ) vracelo y, tuto potrebu vyjadri unit testem, tak dotycny team odpovedny za implementaci foo muze byt agilni jak chce, ale smerem ven zadne „ripples“ neproniknou. To co popisujete je rizikem zmeny v API, ktere jsou casto potreba i u waterfall vyvoje. Ale diky unit testum se v TDD prostredi takove zmeny delaji mnohem levneji. U waterfall se casto kvuli cene takove zmeny nakonec zatnou zuby a jede se dal bez zmeny, ale to nakonec taky stoji strasne penize, nekdy dokonce vic nez nakladna zmena uprostred vyvoje.
Je to samozrejme o spravnem planovani, pokud ma waterfall „spravny“ navrh, tak zmena neni potrebna. V praxi se malokdy setkavam se 100% spravnym navrhem od zacatku implementace, obvykle 2. verze stejneho SW je prvni temer spravna (I kdyz Brooks v The Mythical Man-Month varuje ze prave u druhe verze team vymysli desne skopiciny).
Agile tohle predpoklada a rika co s tim, waterfall predpoklada ze kazdy udela svou praci kvalitne a neni potreba se nikam vracet nebo neco menit.

Taky zalezi na jakem projektu se dela, asi nema vyznam kazdy tyden radikalne menit smerovani teamu ktery vyviji SW pro rizeni raketoplanu, jednak se tam docela dlouho vi co ten SW ma delat, jednak na tom delaji lide kteri asi uz i v prvni verzi trefi docela dobre to co je opravdu potreba. Kdyz se dela firemni webova aplikace, chtel bych videt firmu ktera udela smysluplne zadani a po 12 mesicich vyvoje bude porad platne, nejspis budou mit uz nove (opravnene) pozadavky a priority.

KarelI
UT
test driven development – mate jednoduchy a rychly zpusob jak testovat vysledky sve prace, mate rychle rozhrani, ktere muze hned zacit nekdo pouzivat (ve chvili kdy to bude prelozitelne), aniz by to uvnitr fungovalo
da se brat jako dokumentace, vzorove pouziti nejake tridy…
pri oprave chyb – rychle testovani, zaruka, ze se chyba nevrati
pri zmene vnitrnich casti systemu – kdyz si dobre vytipujete, co byste asi tak mohl podelat, tak vam to pomuze to nepodelat :-)
kdyz trva pusteni aplikace a naklikani neceho treba minutu a pusteni testu radove sekundy, tak to vyznamne urychli praci
pomuze pri designu, napr. separace GUI a vykonnych casti

Kdyz si vezmu, kolikrat uz mi UT zarval, ze neco neni jak byvalo…

SCRUM: me se jako managerovi libi – mam prehled o tom co kdo dela, kde se zasekl a kde jsou pripadne problemy, hlavne to taky vedi vsichni ostatni. Tester vi co je k testovani a co neni, programatori vedi na co se zamerit aby se na ne necekalo atd. Taky to lidi dobre nastartuje a udrzuje se lip tempo. Takze za tech 15 minut denne to urcite stoji. :-).
K vasemu pripadu – jestli resite pitomosti, tak to neni scrum, ten ma byt strucny. Detaily muzou byt dost dulezite pro ostatni, zvlast pokud se tykaji nejake zmeny. Takhle o nich vite jen vy a za ten tyden to spolehlive zapomenete.

JS

Jak rikam vyse, kdyz jste schopen vytipovat, co se asi muze pokazit, je podle me lepsi investovat do abstrakce, ktera zaruci, ze se to nepokazi (jelikoz to pak bude delat pocitac, a ten se neplete). Kazdopadne, ja UT nezatracuji, akorat si myslim, ze abstrakce a asserty jsou silnejsi nastroj.

K tomu SCRUMU – samozrejme, ze managerum to vyhovuje. Jenze kazde mereni postupu neco stoji (kdybychom museli zduvodnovat kazdy krok, nic neudelame). Pokud clovek umi komunikovat, jsou tyhle mitinky zbytecne, protoze pak se proste s relevantnimi lidmi na tom API dohodne a je to. A pokud to neumi, pak je asi potreba to resit nejak individualne, a ne to vnucovat i ostatnim. Jenze to je prave to – takovahle ad hoc organizace managerum nevyhovuje, protoze pak maji pocit, ze nemaji prehled a jsou tedy zbytecni. Bez ohledu na to, ze to tak muze byt efektivnejsi.

A to pomijim fakt, ze jste nijak neadresoval moji namitku, ze kratsi doba vydavani zmen (dny misto tydnu) zpusobuje mnohem vice regresi a obecne reseni detailu, ktere se z delsiho obdobi ukazaly jako nepodstatne.

KarelI

K tipovani co se muze pokazit – mel jsem na mysli vyssi uroven. Asserty zajisti jednoduche invarianty v algoritmu, abstrakce muze napomoci flexibilite atd., ale pak jsou pripady, kdy mam predstavu o ruzne singularnich, extremnich, okrajovych vstupech a zajima me, jestli si s tim algoritmus poradi a da rozumny vystup. Jsou problemy, kdy je snad nemozne podchytit vsechny pripady a domyslet vsechny stavy, nebo je proste jednodussi vypustit to na extremni data a videt co se deje a pak to doladit. Jista mira abstrakce se zachova, asserty tam jsou, ale bez testovani na to proste nelze prijit. Pak jsou UT velmi uzitecne.

Obecne kazda uroven testu je k necemu dobra – asserty, UT, integracni, aplikacni, a bud se clovek necha nakopnout, nebo na to v bolestech prijde sam… :-)

Ke scrumu – ja prece nemluvim o zduvodnovani kazdeho kroku a mereni postupu. Jde o to aby kazdy rano behem par minut rekl jak je na tom, cimz se pomuze tomu, ze se sladi postup a odhali pripadne problemy v zarodku. Kolik vas stoji 3 minuty denne? Kolik stoji kdyz tyden delate neco jineho nez bylo potreba? Kolik stoji, kdyz se po mesici zjisti, ze je vysledek uplne k nicemu, protoze si kazdy hrabal na svem pisecku a s nikym nemluvil? Mozna jste genialni a odevzdavate kvalitni a hotovy produkt. Ja znam lidi, kteri driv nebyli schopni dat dohromady vysledek ani pul roku po terminu, se scrumem to dotahli na zpozdeni 1–2 tydny a dalo se to pouzivat. Pokud mel na zacatku nekdo pocit, ze je do toho nucen, tak byl nakonec rad, ze to tak dopadlo.

Co se tyce doby vydavani, vyvoj a ladeni trva zhruba 4 tydny, mam dobrou zkusenost s tydennimi revizemi – programatori jsou jesitni a muzou se pretrhnout aby ukazali, ze uz neco funguje :-). Dale se osvedcila kazdodenni komunikace mezi programatory a testery.

Obecne, nerikam, ze „agilni“ je dogma a nezavadim bezhlave vsechno co kde prectu. Take mam alergii na buzzwordy. Na druhou stranu se snazim byt otevreny k novym myslenkam a kdyz slysim, ze se nekde neco osvedcilo, tak proc to nezkusit taky. Byl bych hloupy a naivni, kdybych si dal klapky na oci a s blahosklonnym pocitem ze je vsecho idealni odpalkoval vsechno nove. Celkove mam dobrou zkusenost s lidma, kteri chteji zkouset nove a zlepsovat stavajici a velmi spatnou se suvereny kteri vsechno znaji a udajne to delaji nejlepe.

Tady jen pisu o tom, co se mi osvedcilo nekomu, kdo tomu neveri. Ted uz je to na vas jak si to preberete, ale presvedcovat me o tom, ze to k nicemu neni jaksi nema smysl.

bpbp

SCRUM není o dohodách nad API – je to o tom, že se veřejně a pravidelně říká, jak se postoupilo s pracemi. Hlavní je se vzájemně informovat a zdůvodnit změny odhadů práce a tím umožni řízení projektu.

Ano setkal jsem se s „neporozuměním“ a odmítáním, ale jen od manažerů, kteří jsou tam opravdu zbyteční. Od lidí, co jsou opravdovými manažery (rozuměj kouči, mající zájem na tom, aby lidi pracovali samostatně a odborně rostli), jsem zažil nadšení a pochopení.

Délka iterace na 1 release má obecné doporučení cca 3 týdny, takže jaké dny?

Obecné řešení detailu… ano může se stát velmi nezkušenému týmu. 1×.
Součástí iterace je i evaluace toho co a jak funguje. A nefunguje. K nezaplacení.

A vůbec – přečtěte si prosím o tom tohle – psal to praktik
http://www.infoq.com/…the-trenches

xoxoxo

ze jsou to jenom kecy… a mezi nima trikrat reklama na skoleni zendu a unit testovani, LOL

skolitel

pic kozu do vazu:)

Ruthion

Jestli to dobře chápu, jde o jakýsi kompromis mezi extrémním programováním a klasickou metodikou shora řízeného vývoje?

Michal Augustýn

Já to chápu jako kompromis mezi hurá vývojem a vývojem shora dolů.
Resp. to chápu tak, že je to několik iterací klasického vývoje shora dolů (přičemž se analyzuje na menší dobu dopředu).
Chápu to dobře?

Jiří Knesl

Není to tak. Extrémní programování je také agilní přístup (kombinací metodiky a technik), je tedy podmnožinou. Nicméně je pravdou, že XP vnímám mnohem víc jako rámec pro použití technik, než jako metodiku. Ale ona stejně pevná hranice, co je a co není metodika, neexistuje. Ostatně i proto se v této sérii bude mluvit i o Getting Real, které se oficiálně za metodiku nepovažuje.

Miroslav Kašpar

Zdravím,

zní to dobře. Tenhle způsob vývoje se pravděpodobně týká zakázek tak velkých, že klientovi nezáleží na tom, jestli zaplatí o pár desítek tisíc méně nebo více.

Pokud se ale jedná o menší zakázky, většinou chce klient hned na začátku jasně vědět, kolik ho to bude stát a jak dlouho to bude trvat. Přičemž jediným způsobem, jak mu vyhovět, se mi zdá, že je pokusit se odhadnout to, vynásobit dvěma, a doufat, že ten odhad nikdy nepřesáhnete.

Jak ale vyhovět takovým otázkám klienta při agile, který se prostě „opakuje tak dlouho, dokud není klient spokojen“?

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.