Komentáře k článku

Agilní vývoj: Úvod

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.

Zpět na článek

36 komentářů k článku Agilní vývoj: Úvod:

  1. xx

    Re: Agilní vývoj: Úvod

    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.

    1. balki

      Re: Agilní vývoj: Úvod

      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 :)

    2. Jiří Knesl

      Re: Agilní vývoj: Úvod

      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).

      1. xx

        Re: Agilní vývoj: Úvod

        > 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.

        1. TrSek

          Re: Agilní vývoj: Úvod

          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.

          1. Jiří Knesl

            Re: Agilní vývoj: Úvod

            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.

        2. Jiří Knesl

          Re: Agilní vývoj: Úvod

          > 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“.

  2. HerrFranz

    Stand-up meeting

    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.

  3. X

    Můžete trošku vysvětlit tento oxymoron?

    „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).“

    1. Martin Malý

      Re: Můžete trošku vysvětlit tento oxymoron?

      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“.

  4. balki

    OT: Skoda ze nejde hodnotit clanky na zdrojaku.

    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.

  5. rooobertek

    Re: Agilní vývoj: Úvod

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

    1. Ped

      Re: Agilní vývoj: Úvod

      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.

      1. rooobertek

        Re: Agilní vývoj: Úvod

        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…

        1. Ped

          Re: Agilní vývoj: Úvod

          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“.

      2. TrSek

        Re: Agilní vývoj: Úvod

        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 …

        1. Ped

          Re: Agilní vývoj: Úvod

          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.

  6. JS

    Neverim na to

    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.

    1. Jiří Knesl

      Re: Neverim na to

      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.

      1. JS

        Re: Neverim na to

        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.

        1. vkralik

          Re: Neverim na to

          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.

        2. Ped

          Re: Neverim na to

          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.

    2. ijacek

      Re: Neverim na to

      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.

      1. JS

        Re: Neverim na to

        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.

        1. ijacek

          Re: Neverim na to

          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.

        2. bpbp

          Re: Neverim na to

          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

  7. Ruthion

    Extrémní

    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?

    1. Michal Augustýn

      Re: Extrémní

      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?

    2. Jiří Knesl

      Re: Extrémní

      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.

  8. Miroslav Kašpar

    Ohodnocení díla
    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“?

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3134