D-FENS

  Hlavní menukulatý roh
  • Hlavní stránka
  • Statistiky
  • Personalizace
  • Kniha hostů
  • Autoři webu
  • Oldschool D-FENS
  • Chlívek

  •   FAQkulatý roh
  • Jak se stát autorem?

  •   Toplistkulatý roh



    Komentáře
    ke článku: Sv. Scurvil, zapomínaný světec stavebnický
    (ze dne 07.12.2014, autor článku: LWG)

      Stránkovat

    Komentář ze dne: 08.12.2014 00:48:17     Reagovat
    Autor: lachtan - lachta
    Titulek:Vynikající
    vynikající :-)

    Komentář ze dne: 08.12.2014 08:41:03     Reagovat
    Autor: Doom - Doom
    Titulek:
    geniální článek. na nás pracovníky v IT to krásně sedí :D

     
    Komentář ze dne: 08.12.2014 09:17:20     Reagovat
    Autor: mhafan - mhafan
    Titulek:Re:
    Jo :-) Je to pozoruhodne. IT je obor prumyslu, ktery v soucasne dobe produkuje nejvetsi mnozstvi zmetku. Ta zmetkovitost dosahla temer nesnesitelne podoby s prichodem internetu. Pokud pamatujete devadesata leta, tak si snad vybavite zpusob distribuce programu na disketach. Nebyl technicky zpusob, jak distribuovat opravne verze, tak se publikovaly jenom dukladne overene programy.

     
    Komentář ze dne: 08.12.2014 09:24:36     Reagovat
    Autor: JJ - JJ
    Titulek:Re: Re:
    Devadesátá léta pamatuju. Taky pamatuju, že tehdejší software byl typicky o dost jednodušší, než je ten dnešní - a tam bych hledal hlavní důvod toho, že se mohl z uživatelského hlediska zdát odladěnější než dnešní hypertrofované balíky.

     
    Komentář ze dne: 08.12.2014 09:36:17     Reagovat
    Autor: mhafan - mhafan
    Titulek:Re: Re: Re:
    Ale jo, byl jednodussi. Kazdopadne bylo zvykem publikovat hotove dilo. Dnes neni problem prodat prototyp a ten dodelavat v opravnych verzich.

    Dokonce jsem uz nekde slysel, ze nekteri programatori nazyvaji uzivatele jako svoje beta-testery :-)

     
    Komentář ze dne: 08.12.2014 09:48:15     Reagovat
    Autor: deacon - deacon
    Titulek:Re: Re: Re: Re:
    No, to je věc jiná. Dneska programuje každej, kdo se nebojí myše a nekrmí ji sýrem, to 1).
    A 2) - moc se spěchá. Není čas to otestovat, není čas to optimalizovat a každej managor škrtá hlavně v IT sekci, protože ti jsou divní a vůbec, věčně nic nedělají. Z čehož vyplývá, že se ojebe dokumentace, protože tam se ztrácí nejvíce času a negeneruje to výsledek. Jenže právě díky ojebané dokumentaci někdo posere další modul/verzi, protože rozbije část, která byla uzavřena, otestována a prohlášena za "bug free"(nic takového neexistuje :D), protože se vrtal ve funkci, která je provázána právě s tou hotovou částí.

    A taky hromada malejch firem, které kombinují vše již zmíněné a ještě navíc dobrovolně. Also, neexistující dokumentace jako bonus, protože se všichni znají a tak si šecko řeknou. Pak najednou je úspěch, firma se zvětší na víc lidí, než jedna kancelář a najednou je průser. Protože Franta, co tu od začátku není, nechápe, k čemu je tamten soubor, tamta funkce a my si to už nepamatujeme úplně přesně :-)

     
    Komentář ze dne: 08.12.2014 10:03:23     Reagovat
    Autor: mhafan - mhafan
    Titulek:Re: Re: Re: Re: Re:
    Jo, takove ceske pojeti programovani produktu. Se obcas v tech firmach ptam, proc ty chyby neopravuji. Programator obvykle posmutni, prizna chyby a pak to vysvetli: my nesmime venovat cas prepracovani stavajiciho dila, nebot tuto praci neni komu fakturovat. Smime jenom pridavat novou funkcionalitu a to pouze na primou objednavku zakaznika. Firma taky povazuje za uspech, kdyz vymackne ze zakaznika penize na opravu nejakych prehistorickych vad - to ovsem nepublikuje v rozpoctu.

    Dokumentace je jiste samostatna perla. Existuje obava ze stavu, kdy veci rozumi dokonale pouze jeden clovek (charakterizuje se to jako zranitelnost), ale to neni duvod pro duraz na psani dokumentace :-)

     
    Komentář ze dne: 08.12.2014 10:09:41     Reagovat
    Autor: mhafan - mhafan
    Titulek:Re: Re: Re: Re: Re: Re:
    Dodam jeste, ze mluvim o firmach, ktere nedelaji programy na zakazku, ale vyviji vlastni dlouhodobe mineny produkt. Presto k nemu pristupuji jako k programu na zakazku. Neni to pro ne predmet staleho zdokonalovani. To se deje pouze na zakazku.

     
    Komentář ze dne: 08.12.2014 10:22:04     Reagovat
    Autor: deacon - deacon
    Titulek:Re: Re: Re: Re: Re: Re:
    Ono kolikrát dokumentaci prostě sepsat nejde. Když máte 90 000 řádek kódu, kdy ty nejstarší mají s klidem přes 10 let, tak to prostě nesepíšete. Spousta kódu by se dala zeškrtat, ale kdo si troufne v tak velkým kuse kódu škrtat, když nevím, co to má dělat a ani co to reálně dělá. Takže když se těch 90k řádek provede(velká obrazovka), tak se celý screen 3x překreslí, 4x se přepočítá půlka proměnných, 2x se zjistí stav obrazovky(editace, zobrazení, nové vložení, mazání...) a stejně se 2/3 obrazovky nakonec vyplní podle finálního kódu, kterej ignoruej celý ten počáteční cirkus. A to už se bavíme o tom, že to bylo optimalizováno :D

    Tohle je na odstřelení a přepsání, ale "na to nejsou lidi" a "na to nejsou peníze"(BTW emerická firma :-)). Poslední 2 verze má tato obrazovka v našem systému dohromady přes 600 změn, bavíme se o necelých 2 rocích(since červen 2013). Většina z toho jsou opravy oprav, které opravovaly opravy oprav .... :-)

    Samozřejmě, protože firma začínala tak, jak jsem to popsal(jedna kancelář plná lidí, co si všechno řeknou), tak nikdo neví jaké business procesy jsou tam skryty(ty známe samozřejmě lidi znají), protože tehdy dokumentace nebyla potřeba a dnes je již pozdě. Takových pěkných překvapení máme v kódu asi 5 nebo 6, dohromady snad půl milionu řádek kódu, kde každý postupuje jak v minovém poli. Nikdy nevíte, co při vaší práci bouchne :o) Hálelujá :-)

    Nerozumí tomu nikdo, kvalitně to zná jeden člověk, nadprůměrně asi 10 lidí ze 150 programátorů .-) Oh yeah!

     
    Komentář ze dne: 08.12.2014 10:38:02     Reagovat
    Autor: Karkulka - Karkulka
    Titulek:Re: Re: Re: Re: Re: Re: Re:
    Ono to hlavně často vznikne celé tak, že kdysi ten základ naprogramoval jeden napůl geniální a napůl šílený tvor, pak se na to deset let nabalovaly úpravy, a aby se to celé přepsalo tak je potřeba někdo kdo dokáže sepsat co přesně to dnešní dělá, analyzovat co by mělo umět to nové - což ale předpokládá že tam je někdo, kdo tuhle práci dokáže udělat.

     
    Komentář ze dne: 08.12.2014 10:48:42     Reagovat
    Autor: deacon - deacon
    Titulek:Re: Re: Re: Re: Re: Re: Re: Re:
    Na to nejsou lidi, pane ministře.

     
    Komentář ze dne: 12.12.2014 13:03:16     Reagovat
    Autor: vojta - Neregistrovaný
    Titulek:Re: Re: Re: Re: Re: Re: Re:
    nemate testy, nemate sebedokumentujici kod, a k tomu celych 10 lidi? na blbych 90000 radku? ja bych se stydel :)

     
    Komentář ze dne: 08.12.2014 11:09:16     Reagovat
    Autor: icu - icu
    Titulek:Re: Re: Re: Re:
    Dovolím si nesouhlasit.

    Za první jakž-takž použitelná MS Windows lze považoval až verzi 3 (a ještě lépe lépe 3.11) a ani český SW bych vždy jako odladěný při uvedení na trh nepovažoval - ať už šlo o T602, tak třeba o účetnický SW. Termín uvedení SW byl neúprosný - kdo nestihl Invex, ztratil de facto celý rok.
    Konečně, obrat uživatelé jako beta-testeři jsem slýchal v první polovině 90. let docela často - někdy jako vtip, někdy jako realitu (byť původně nezamýšlenou).

     
    Komentář ze dne: 08.12.2014 17:33:04     Reagovat
    Autor: cover72 - cover72
    Titulek:Prodej prototypu je nová norma
    Prodej prorotypu a následné jeho dodělávání nejenže není problém, je to dnes povinnost. Říká se tomu Adžájl Development Metodolodži a je to teď hrozně v módě.
    Takže "ANO, bude hůř."

    Adžájl je prezentováno jako spásné řešení, které umožní včas vydávat plně funkční produkty, zaměstnance zachrání od přesčasů a infarktů a hlavně perfektně splní přání zákazníka, protože ten dává programátorům zpětnou vazbu tak, jak dostává kusy programu, tzn. co pár týdnů či nanejvýš měsíců, a vůbec.

    Manažeři adžájl milují.

    Ti ajťáci, kteří v něm neodrostli a byl jim vnucen managementem jej nenávidí z hloubi duše, protože jim přijde, že je v něm špatně úplně všechno.

    Kupříkladu ve V-modelu, který byl rozšířený před Adžájlem, se na začátku udělala a se zákazníkem probrala naprosto jasná funkční specifikace: co PŘESNĚ to má dělat a jak se to má chovat. Ve školeních ajťáků se zdůrazňovalo, jak je přesnost zadání důležitá, protože ambiguity (např. "systém má umět posílat maily s přílohami max. 10MB") je zkázou projektu:
    - když je příloha větší, než 10MB, má systém mail zahodit, odeslat bez přílohy, nahlásit chybu ale vrátit uživatele do editoru nebo přílohu zkusit komprimovat?
    - vztahuje se limit 10MB na každou přílohu zvlášť nebo na všechny dohromady?
    - jedná se o MB nebo MiB, tzn. mocniny 10 nebo 2?
    - jaké maily má podporovat: s kódováním znaků 7B? 8B? 16B? které znakové sady má detekovat? Má je vůbec detekovat, nebo to nechat na prohlížeči?
    - v jakém kódování má odesílat maily? Nebo jaké má být výchozí?
    Atd.

    Z té se potom vyrobila Detailní Specifikace, tu dostali programátoři a na jejím základě vytvořili kód, ten se otestoval proti DDS, pak se otestovalo, zda odpovídá Funkční Specifikaci a když ano, zákazník dostal hotový produkt, který chováním přesně odpovídal zadání, které stálo na začátku.

    Samozřejmě byl problém, když zákazník odsouhlasil detailní Funkční Specifikaci a v půli vývoje si rozmyslel, že vlastně chce, aby se to chovalo úplně jinak. Pak se buď vše předělávalo za chodu a vznikaly zmetky, nebo byla smlouva napsaná tak, že měl náladový zákazník smolíka ("vyřiď si to se svým zadavatelem"), zaplatil a dodán byl produkt podle odsouhlasené specifikace a nové chování se řešilo novou verzí, opět detailně popsanou na počátku vývojového cyklu.

    Právě to má Adžájl řešit: je přeci pružný.

    Proto je základem Adžájl v praxi právě takové obecné, nicneříkající zadání ("Jako zákazník chci, aby mi Produkt umožnil odesílat maily. Tečka.") a to je vše. Vývoj a kontrola kvality si musí samy vymyslet, jak by to asi zákazník mohl chtít, splácat během pár týdnů kus kódu, zákazníkovu jej předvést, na základě kritiky jej během pár týdnů předělat a tak dále.

    Což vede jednak k tomu, že je vývoj nesystémový, jednak k tomu, že se zadání mění pod rukama (což je IMO zkáza každého projektu) a jednak a zejména k tomu, že
    - nikdo neví, co je chyba a co vlastnost
    - vedoucí Adžájl Týmu, Pchrodakcht Ounr, řeší stále více všetečných dotazů variací na téma "zákazník tyhle detaily nechce řešit, nějak to udělej/to neřeš a neumožni mu to dělat/to ani netestuj, stejně to zrušíme" -> iPhonizace SW, kdy každá další verze umí mén, než ta předchozí

    Ergo samotný fakt, že nikdo neví, co je chyba a co vlastnost dnes není chybou, nýbrž vlastností.
    Muhehe.

     
    Komentář ze dne: 08.12.2014 17:47:27     Reagovat
    Autor: JJ - JJ
    Titulek:Re: Prodej prototypu je nová norma
    Ono to má i druhou stranu - nějakou konsistentní funkční specifikaci Ti jsou schopni dát možná při vývoji na zaázku pro větší firmu v raném stadiu zazmrdování. U spousty aplikací prostě zadavatel něco podobného vytvořit neumí.

    A pak se buď použijí ty agilní přístupy, nebo aplikace nevznikne. Naštěstí část zadavatelů sice neumí sam od sebe připravit rozumnou specifikaci, ale dokáže alespoň dodat rozumné připomínky k něčemu, co jí dáš jako hrubý nástřel.

    Je to úplně stejná demokratisace na straně poptávky i nabídky, jakou jsme před časem viděli u fotografie, videa apod. Současná popotávka po software, v poslední době zejména po mobilních aplikacích, je tak velká, že pro její saturaci je prostě potřeba jít s úrovní dolů. A tak dnes za peníze programuje kdejeký blbec, co si na YouTube pustil tři díly nějakého tutorialu...

     
    Komentář ze dne: 08.12.2014 18:31:19     Reagovat
    Autor: cover72 - cover72
    Titulek:Re: Re: Prodej prototypu je nová norma
    To je sice na jednu stranu pravda, ale na stranu druhou onu FS může vytvořit i dodavatel, který onu "ambiguity" v zadání zmenší/odstraní tím, že se na konkrétní věci odpovědné osoby na straně zadavatele jednoduše zeptá, provede s ním review a nechá si to podepsat.

    Jenže to v Agile nejde, protože je to moc textu a, slovy jistého člověka z Agile prostředí, "s tím se ti v Agile nikdo psát nebude. Na to zapomeň."

    Viz Agile Manifesto:
    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan


    Jako všechny podobné manifesty to na první pohled vypadá rozumně, ale v praxi je to šílená hovadina, kdy se "to na pravé straně" prostě de facto zruší a jede se setrvačností.

    A nemluvím o nějakých mobilních aplikacích, nýbrž o dávno zavedenýmch produktech, které byly celé donuceny přejít s další verzí produktu z V-modelu na Agile, protože se někdo v nejvyšším managementu rozhodl, že Agile je "so cool and shiny", jak by řekl můj kolega, že to prostě všichni musí mít.

     
    Komentář ze dne: 08.12.2014 20:28:37     Reagovat
    Autor: Paflik - dantuin
    Titulek:Re: Re: Re: Prodej prototypu je nová norma
    predpokladate ze zadavatel vi co chce, a to presne do detailu.. a pokud ne tak ho donutite k volbe (pravdepodobne neoptimalniho) reseni predem

    co kdyz to ale zadavatel nevi (treba ani nemuze - v rychle se rozvijejicich oborech - kdo vi co presne bude potreba za rok, dva (viz ta vase velikost prilohy)) - coz neni zrovna vzacne

    ja vim, vy mate svoji roky starou specifikaci, takze jste kryti, no ale zakaznik celou dobu cekal a ted ma produkt k nicemu i kdyz perfektne podle specifikace


    naproti tomu pokud
    * posbirate use cases/user stories/whatever na zaklade zakaznikova workflow (ma to vubec cesky preklady?) tak abyste vedel, PROC A CO chce delat a je uz na vas vymyslet JAK presne to bude vypadat a fungovat
    * pravidelne si od nej nechate schvalovat dilci prototypy a upravujete/zpresnujete zadani a priority
    * pocitate se zmenami a podle toho (ne)planujete i vyvijite

    pak mate vzdy aktualni pozadavky, navic podlozene praktickou zkusenosti s prototypem (mensi sance, ze toho budete pulku predelavat, kdyz to na nej vybalite na konci najednou), kus software, ktery snese upravy a stastnejsiho zakaznika

    navic jak projekt postupuje ziskavate cim dal presnejsi predstavu o casove narocnosti pridavanych featur/stories - protoze je trackujete jako dilci celek a tak muzete zakaznikovi odpovidat na otazky jako - jak dlouho bude trvat pridat sem tuhle vec, co jsem si ted uvedomil by mi hodne ulehcila zivot - a pak to v radu tydnu dodat v ramci prototypu - zkuste to v pulce projektu na waterfallu

    k obecnym klise
    * agile nerika ze mate prodavat prototypy, jen ze tyto maji byt plne otestovane, funkcni a schopne nasazeni (byt s omezenou funkcnosti)
    * neni pravda ze se neplanuje, planuje se to co je potreba planovat (pokud jsou tam vzajmene zavislosti, priority) - tim myslim i dele nez na rekneme mesic; netravi se cas vytvarenim obrovskych detailnich planu na roky, ktere prestavaji platit okamzikem zverejneni a v okamziku vydani z nich nezbyde ani n

    rozumim tomu, ze analytickym lidem dela problem ten chaos a nepresne zadani, nicmene to vede rychleji k pouzitelnym produktum

     
    Komentář ze dne: 08.12.2014 21:19:05     Reagovat
    Autor: mhafan - mhafan
    Titulek:Re: Re: Re: Re: Prodej prototypu je nová norma
    lidi v tomhle oboru miluji presna zadani ;-)

    Ja tvrdim, ze zhotovitel dila - programu - musi vedet o potrebach zakaznika lip nez sam zakaznik. Nekteri moji zakaznici se mi to ani nestydeli takto rict: "najimame si vas proto, abyste nam rekl, co vlastne potrebujeme". Nebyla to vsak nikdy nejaka idylka - kdyz bych se netrefil do vkusu, tak by byly potize s predanim a placenim. Zakaznik muze chtit udelat blbost a jenom silenec by na zhotoveni blbosti pristoupil.

    Seriozni zhotovitel taky tak nejak tusi, ze vysledne dilo muze byt k pocatecnimu zadani skoro az k nepoznani. Da se na to v programu pripravit.

    Zustava jediny problem: praci predem spravne nacenit ;-) Vo to nam de predevsim. Jeste jsem nepotkal zakaznika, ktery by v ramci dobrych vztahu s dodavatelem souhlasil na proplaceni vicepraci. To se vzdycky argumentuje smlouvou, terminama apod.

     
    Komentář ze dne: 08.12.2014 22:04:58     Reagovat
    Autor: Paflik - dantuin
    Titulek:Re: Re: Re: Re: Re: Prodej prototypu je nová norma
    on zakaznik vetsinou vi ceho chce dosahnout a ma predstavu CO k tomu potrebuje, je ale nutne se nezastavit a ptat se hodne PROC - jednak vam to potom pomuze delat spravna rozhodnuti kdyz zadani je nejasne :) a druhak se casto zjisti ze vlastne potrebuje neco jineho nez si myslel a o cem treba netusil ze by vubec slo

    co se tyce ceny, pokud to vylozene neni prvni vec sveho druhu kde je opravdu hodne vyvoje novych veci a mate jakous takous zkusenost tak se to odhadnout da - ve smyslu, za tri mesice budeme mit tu a tu funkcionalitu, pokud se nic nezmeni (a neco se meni se souhlasem nebo primo na zadost zakaznika), za 6 mesicu tu a tu (cim delsi cas, tim konzervativnejsi odhad) a pak je na zakaznikovi, jak dlouho bude platit a kolikaty prototyp pro nej bude 'good enough' v pomeru cena/vykon

    kazdopadne je v tom vic nejistoty ale i volnosti - vy neztracite cas na vecech ktere budou ve finale k nicemu a zakaznik je nemusi platit a mate oba moznost rozsirovat prototypy podle chute a moznosti s tim, ze kdykoliv je to jako produkt nasaditelne a pouzitelne

     
    Komentář ze dne: 08.12.2014 22:01:02     Reagovat
    Autor: cover72 - cover72
    Titulek:
    Což je krásné, pokud děláte třeba nějaké ty mobilní aplikace, ve kterých se dá rychle a snadno vyvinout prototyp. Ve složitějším softwaru, kde prototyp=prakticky finální produkt to jaksi takhle nefunguje, nehledě na to, že než se vůbec naplní všechny SW prerekvizity pro to, aby zákazník vůbec mohl něco prakticky vidět (práce s binárními daty), zabere to vzhledem k rozsahu stories tři sprinty -- zjistit v této fázi, že si to zákazník vlastně představuje úplně jinak je k pomilování.

    Také to vznáší dost blbé požadavky na testery, protože oproti čemu mají v black box fázi testovat? Oproti jedné složené větě v trackovacím objektu pro Epic asi těžko, takže proti vlastnímu názoru na to, co je správné chování? Super, v tom případě je všechno feature, nic bug a na nějaké black box testování se můžem vykašlat. Devové si své unit testy udělají sami, testery propustíme a ještě ušetříme!

    S čímž souvisí i to, že Agile uspořádání "mixed a self-organized týmů" boří všechny best practices o dělbě práce a odpovědností, které existovaly. Jo, je to svižné a třeba v záplavě bug fixů je fajn, že se mohou lidé přelévat tam, kde je jich nedostatek -- ale tím se ztrácí optimum v podobě diametrálně odlišného mindsetu devů a qa a jejich cílů.

    A konečně, toto má za následek i praktickou likvidaci dokumentace: Devové mají možná nějaké své poznámky bokem, QA mé někde uložené simplistické test casy, ale nic podrobnějšího neexistuje, protože namísto dokumentace se přeci sejdeme na Scrumu -- a potom hodně štěstí, až se produkt bude přesunovat jinam nebo se tři čtvrtiny týmu vyhážou a na jejich místo nastoupí lidé produktem nedotčení.

    Suma sumárum, Agile bych dovedl pochopit u garážových start-upů, ale cpát je do zavedených firem se složitými produkty, které byly doposud vyvíjeny V-modelem mi přijde jako kapitální kravina.
    Jasně, že to "nějak" jde -- socík taky "nějak" fungoval 20 let po vyžrání zdrojů a ještě nějakou dobu by to táhl. Leč jaksi to nebylo ono.

     
    Komentář ze dne: 08.12.2014 22:34:49     Reagovat
    Autor: Paflik - dantuin
    Titulek:Re:
    Nerikam, ze se to hodi vsude, ale jenom vyvracim to absolutni zatraceni :)

    Je jasne, ze ten zaklad do prvniho prototypu je potreba naplanovat tak aby se nemusel vyhazovat, ostatne stejne jako kazdy dalsi prototyp. I v pripadech ktere zminujete se da udelat hodne - mockupy UI, API nebo jine vystupni casti, ktere se udelaji zvlast a pak jen pripoji na novou funkcionalitu.

    Tester si nachysta test plany a kostry testu, ktere take postupne napojuje. Ani v tom V-modelu ciste na zaklade specifikace asi neudela kompletni testy. A jakmile ma jakykoliv prototyp od develu, musi otestovat vsechno co zrovna umi.

    Samozrejme na vetsim projektu v urcite fazi prestanete vyvijet nove featury a soustredite se ve sprintech na stabilizaci, tak aby se QA nesypala hotova vec pod rukama. Ta nejasna odpovednost a spatna delba prace nemusi byt pravda. To dulezite je, ze se kompletni agilni tymy (kazdy s dev, qa, dokumentaristama, ,co ja vim..) soustredi na kompletovani jednotlivych featur/podprojektu. Neni to velka hromada develu, vedle velka hromada kvalitaku, atd. A ty tymy se koordinujou zase o uroven vys. Dokumentace (kde je potreba) je soucast stories, bez ktere se neakceptuji jako kompletni.

    Ono to nefunguje tak nejak, ono to prave vetsinou! funguje lip, jen pravda trva si na to zvyknout pokud tak clovek nikdy nepracoval.

     
    Komentář ze dne: 08.12.2014 23:02:44     Reagovat
    Autor: cover72 - cover72
    Titulek:Re: Re:
    Jenže to ne vždy jde. Pokud se třeba třídí data z binárního streamu, něco se v nich hledá a ukládá bokem a z toho se pak zákazníku dělá report, v okamžiku, kdy si zákazník usmyslí, že se vlastně mělo hledat něco podobného, ale technicky zcela jiného se prototyp musí předělat docela důkladně: struktura, vyhledávání, třídění, skládání, vyhodnocovací logika, na to napojené bloky kódu, které s tím pracují...

    V Black Box testování vychází tester prakticky výhradně z FS. Z čeho jiného? Pointa Black Box přeci spočívá v tom, že se nenechá ani podvědomě ovlivnit kódem a tím, co dělají Devové, protože ti to mohli špatně nejen naimplementovat, ale už pochopit, a proto tester verifikuje odpovídající úroveň na protější straně onoho "V" ve "V-modelu, tzn. FS, a simuluje zákazníka.

    Ohledně "stabilizace" to v praxi vypadá přesně tak, jako to pánové kritizovali výše: "to nikdo nevidí, je to úplně na konci backlogu." Ditto s chybami, které jsou třeba snadno reprodukovatelné, ale PO nepočítá s tím, že by zákazník mohl produkt použít tímto způsobem a proto si myslí, že do nich nevrazí: prostě se neopraví. Protože chyby, které nenahlásil zákazník, se neobjevují v interních tabulkách a není to featura, kterou by se dalo před zákazníkem chlubit, ergo žádná hodnota, ergo na to kašlem. To je právě teorie versus praxe.

    A problém s dokumentací je, že součástí akceptačních kritérií samozřejmě je manuál pro zákazníka, ale interní dokumentace se moc nevede, protože devové a qa si "to své" přeci drží v hlavě, sdílí to na sprintu a v duchu Agile Manifesta se s dokumnetací nebudou zdržovat. problém nastane až tehdy, když do rozjetého týmu přijde někdo nový. A to okolo sebe mohu vidět na více místech, i z doslechu od lidí, kteří přestoupili k novým firmám. A pořád se to jen zhoršuje.

    Někteří mí kolegové soudí, že je to důsledek toho, že IT firmám velí lidi bez IT zkušeností, kteří proto nedovedou ocenit význam a hodnotu některých postupů a mechanismů (interní dokumentace, mentalita, industry best practices atd.), neb nevidí její přínos v dlouhodobém horizontu. Koneckonců, když CEO v průměru vydrží 2-4 roky, zajímá jej to, aby na akcionáře zapůsobil na konci finančního roku a nikoli to, aby se celý produkt nezhroutil, až se bude polovina týmu nahrazovat nováčky, protože toho už se on nedožije.

    Je to ten samý problém, jako v parlamentní demokracii. Kupodivu se zdá, že nejlépe jsou na tom IT firmy, které koupily penzijní fondy, protože ty -- narozdíl od nenažraných akcionářů -- zajímá dlouhodobé hledisko, nejen aktuální cena na burze.

     
    Komentář ze dne: 08.12.2014 23:38:22     Reagovat
    Autor: Paflik - dantuin
    Titulek:Re: Re: Re:
    v black box testovani musi vedet jak ma vypadat vstup a vystup.. ja jen rikam ze pokud neni presna specifikace, agile mu umi i tohle dodat (treba jako mockup bez realne funkcionality, ale testy se nad tim napsat daji)

    pokud se stabilizace dostane do sprintu, nemohla bejt na konci backlogu, ale na zacatku - priority se muzou a taky meni pred kazdym sprintem

    jestli pustite ven prototyp s kritickyma chybama o kterych vite, je to jen vase spatne nastaveni release kriterii.. na druhou stranu bezchybny software neexistuje a snazit se opravit uplne kazdou blbost (typu preklep v dokumentaci) pred vydanim znamena ze nevydate nikdy

    je na vas jestli soucasti stories bude i interni dokumentace, ja to tak ve svym tymu mam (pokud jde fakt o nejakou pakarnu, kterou nestaci okomentovat v kodu)

    agile fakt neni o nedokumentovani, spechu, neporadnosti nebo jak to rict - i kdyz uznavam ze se casto nespravne pouziva jako ospravedlneni zmineneho, coz ale neni jeho chyba (to spis toho co uvadite v poslednich dvou odstavcich)


     
    Komentář ze dne: 09.12.2014 00:41:19     Reagovat
    Autor: cover72 - cover72
    Titulek:Re: Re: Re: Re:
    No, a není už náhodou kombinace přesné informace o vstupu, výstupu a toho, co se s tím musí provést, aby se ze známého vstupu dostal známý výstup něco přinejmenším zatraceně podobného funkční specifikaci? ;-)
    Rozhodně to není ono Agilovské simplistické "As a ____ I need _____ to _____ because _____.", které prý má stačit "a s detaily obtěžuj PO nebo zákazníka tak dlouho, až s tebou přestane komunikovat" ;-)

    Stabilizace je fpraxi korporátní pustá teorie. Znamená jen to, že poslední sprint před releasem, než je vyhlášeno moratorium na přesuny ze sandboxu do produkce, se alespoň chvíli řeší ty nejtěžší nedodělávky z minula, se kterými se ozval zákazník nebo které blokují vývoj nových featur.

    V praxi se totiž nevyhnutelně projeví to, že je pro každý task nějaká "odměna" -- vidí to zákazník, vidí to v tabulkách nadšéfové, atd., atp. -- a podle té tým, potažmo PO hodnotí, do čeho se pustí a do čeho ne.

    A jelikož za interní bugy žádná odměna není, protože je nehodnotí ani zákazník, ani vyšší mgmt, následuje replika "když to zákazník neobjevil doteď, neobjeví to ani nadále, protože to tak nepoužívá, a my budeme dělat něco, co někdo ocení" -- principielně platná pro jakýkoli bug objevený interně -- a šup na konec backlogu. To je lidská přirozenost, k tomu to IMO degeneruje zcela samozřejmě a nutně... No a Agile pro to jen nabízí dost slušnou pobídku a skvělé výmluvy.

    Jako OK, možná, že se Agile dá i v korporátu dělat rozumně, ale ještě nikdy jsem to neviděl a vzhledem k tomu, že všichni propagátoři Agile, které jsem kdy viděl (na konferencích, v práci i z jiných firem) mi přišli jako sveřepí Jasánci si to nedovedu představit.

     
    Komentář ze dne: 09.12.2014 09:45:43     Reagovat
    Autor: Paflik - dantuin
    Titulek:Re: Re: Re: Re: Re:
    rozumim, ze mate spatnou zkusenost jak s vedenim (nastavenim priorit a hodnoceni), tak s propagatory agile (kteri ho berou jako nabozenstvi) - to ale neni chyba vyvojove metodologie

     
    Komentář ze dne: 09.12.2014 15:48:25     Reagovat
    Autor: Field - Field
    Titulek:Re: Re: Re: Re: Re: Re:
    Ne, je to tím, že Agile prostě není pro všechny projekty stejně vhodné. Klidně použiju Agile pro startup, kde je životnost krátká a je potřeba vyrolovat produkt ASAP s tím, že to časem celé někdo koupí a integruje do jiného produktu nebo si jen vezme zákazníky a zavře to. Většina startupů na tomhle modelu zdárně funguje.

    Ale pro dlouhodobé projekty typu řízení leteckého provozu, bankovní systém nebo software řídících jednotek pro auta to fakt není. Jen to management musí pochopit, což se v atmosféře nadšeného jásání zhusta neděje.

     
    Komentář ze dne: 09.12.2014 18:21:52     Reagovat
    Autor: Paflik - dantuin
    Titulek:Re: Re: Re: Re: Re: Re: Re:
    zdarne to funguje i na dlouhodobych projektech typu udrzby a rozsirovani existujiciho systemu - mozna to neni management kdo by mel zacit chapat a myslet mimo krabicku

     
    Komentář ze dne: 09.12.2014 18:44:15     Reagovat
    Autor: Field - Field
    Titulek:Re: Re: Re: Re: Re: Re: Re: Re:
    Jak dlouho že to tam funguje?

     
    Komentář ze dne: 10.12.2014 00:41:45     Reagovat
    Autor: JiriF - jirif
    Titulek:Re: Re: Re: Re: Re: Re: Re: Re:
    zdarne to funguje i na dlouhodobych projektech typu udrzby a rozsirovani existujiciho systemu

    Asi bude hodně záležet na tom, co si představujete pod pojmem "dlouhodoby projekt".
    Mám za sebou dva úspěšné dlouhodobé projekty (1990-2006 a 1997-2010), a ani jeden by nebylo možné rozběhnout nebo dlouhodobě provozovat agilním způsobem. Jsou věci, které prostě musejí fungovat ze startu (třeba některé subsystémy v JE nebo drtivá většina rozsáhlejších CAM), a které není možné řešit metodou pokus-omyl. Do běžící JE nemůžete dodávat dozimetrii po kouskách s tím, že vám uživatel řekne, co máte dodělat do příštího týdne, protože fungující dozimetrický subsystém je součástí limit a podmínek.

     
    Komentář ze dne: 10.12.2014 20:10:27     Reagovat
    Autor: Paflik - dantuin
    Titulek:Re: Re: Re: Re: Re: Re: Re: Re: Re:
    nevim proc me porad nekdo dava priklady kde vsude si neumi agile predstavit, aby tim demonstroval ze je to nepouzitelne obecne - pritom ja nikdy netvrdil ze je to pouzitelne vzdy a vsude

    pokud agilni zpusob chapete jako pokus omyl, kdy se snad pocita s nasazenim tech 'pokusu resp. omylu' tak to chapete spatne

    pokud jsou pozadavky jasne a je malo pravdepodobne ze se nejak zasadne budou menit, pak je agile ne nepouzitelne, ale zbytecne.. celou dobu se ale bavim predevsim o odvetvich kde je to presne opacne

     
    Komentář ze dne: 10.12.2014 20:22:38     Reagovat
    Autor: cover72 - cover72
    Titulek:Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
    No, jenže v korporátu je způsobem "one-size-fits-all" nařízena jedna vývojová metodologie pro celou R&D divizi se všemi jejími pobočkami, produkty a týmy.

    Protože to, že jednotlivé produkty mají diemetrálně odlišné charakteristiky a cílí na segmenty trhu se specifickými zvyklostmi je naprosto pod rozlišovací schopnost top managementu, který se střídá po oněch 2-4 letech a o IT neví nic konkrétního, pouze čte nejnovější jásavé trendy a buzzwords v ekonomických a manažerských časopisech.

    Což momentálně znamená Svatou Trojici "Agile, Cloud a Big Data musí být, i kdyby měly nosné produkty shnít!

    Kdyby si tým mohl vybrat, co mu k charakteru produktu sedne, nic bych proti tomu neměl. Ale když se top-down nutí Agile, mám za to, že je to ve většině případů k více škodě, než užitku.

    A proto jsem také celou diskusi nastartoval konkrétní zmínkou o ajťácích, "kteří v něm neodrostli a byl jim vnucen managementem".

     
    Komentář ze dne: 11.12.2014 08:02:35     Reagovat
    Autor: Paflik - dantuin
    Titulek:Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
    to je samozrejme spatne, ale to je zase chyba toho direktivniho pristupu, nikoliv te zrovna protlacovane metody

    neni zadny duvod proc by kazdy tym nemohl pouzivat co mu vyhovuje - je to sice trochu opruz s koordinaci, reportingem - ty lidi tam ale nejsou kvuli papirovani ale kvuli vyvoji - staci dobre rozdelit funkcni celky

    asi ani neznam tym, ktery jede presne podle nejake prirucky. vzdycky si to upravi jak jim to vyhovuje a tak je to spravne, pokud u toho nedelaji nejakou zasadni chybu - proces to je pane dobry sluha, ale zly pan

     
    Komentář ze dne: 11.12.2014 00:03:12     Reagovat
    Autor: JiriF - jirif
    Titulek:Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
    pak je agile ne nepouzitelne, ale zbytecne.. celou dobu se ale bavim predevsim o odvetvich kde je to presne opacne

    Jenže v tomto vlákně se bavíme o tom, že se nekompetentní kindermanagement pokouší aplikovat agile tam, kde je to kontraproduktivní, Mlho :-)

     
    Komentář ze dne: 08.12.2014 22:21:47     Reagovat
    Autor: gr - greeny
    Titulek:Re: Re: Re: Re: Prodej prototypu je nová norma
    jj, naprosty souhlas.

    delal jsem na bankovni aplikaci, kde na zacatku byla detailni specifikace, ktere jsme se museli naprosto presne drzet, a to i v pripade, ze pozadovala ne-uplne-optimalni reseni. vysledkem byla sice funkcni, ale "toporna" aplikace.

    pak jsem delal jinou (nebankovni) aplikaci, kdy na zacatku bylo pomerne obecne zadani, ktere se behem vyvoje zpresnovalo. vyvoj probihal typicky tak, ze zakaznik kazdy tyden dostal nedokoncenou verzi, se kterou si mohl hrat a mohl ji pripominkovat. z druheho projektu mam podstatne lepsi pocit. takhle podle meho ma vypadat spravne pouzita metodika agilniho vyvoje.

     
    Komentář ze dne: 08.12.2014 23:05:48     Reagovat
    Autor: cover72 - cover72
    Titulek:Re: Re: Re: Re: Re: Prodej prototypu je nová norma
    Bankovní sektor je IMO dost specifický tím, že tam mají mnoho let (nezřídka 20-30) fungující IT systém kritické důležitosti a naprosto nejdůležitější je interoperabilita jednotlivých částí systému, jejich stabilita a bezpečnost. "Topornost" nikoho moc nezajímá.

    Koneckonců, v bankách se novinky zavádí nezřídka se zpožděním minimálně roku až dvou, aby "si to prve otestovaly ostatní firmy, než to nasadíme" -- takže tam Agile už úplně postrádá smysl.

     
    Komentář ze dne: 09.12.2014 15:25:11     Reagovat
    Autor: Field - Field
    Titulek:Re: Re: Re: Re: Re: Re: Prodej prototypu je nová norma
    No vidíte, a přesto se tam objevuje. Je to přesně v důsledku toho, o čem jste psal výše - nezkušený management s velkým tlakem na krátkodobé úspěchy, který naprosto nezajímá stabilita v horizontu delším dvou let Protože pak buď odrotuje někam jinam nebo s velkou slávou přejde do jiné firmy, kam půjde s image úspěšného manažera bankovního IT.

    Tyhle věci dneska trápí i banky. Tedy netrápí, zatím pořád ještě jednou na hype, ale vystřízlivění už se blíží.

     
    Komentář ze dne: 09.12.2014 15:26:12     Reagovat
    Autor: Field - Field
    Titulek:Re: Re: Re: Re: Re: Re: Re: Prodej prototypu je nová norma
    Kruci, sorry za ty překlepy. Budu si muset koupit novou klávesnici, ale snad je to k pochopení.

     
    Komentář ze dne: 09.12.2014 16:24:41     Reagovat
    Autor: cover72 - cover72
    Titulek:Re: Re: Re: Re: Re: Re: Re: Prodej prototypu je nová norma
    Člověče, to mne tak potěšilo, že v odporu k Agile na dlouhověkých produktech nejsem s hrstkou kolegů osamocen... ;-)

     
    Komentář ze dne: 10.12.2014 06:08:56     Reagovat
    Autor: obrien - Neregistrovaný
    Titulek:Re: Re: Re: Re: Re: Re: Re: Re: Prodej prototypu je nová norma
    Ono Agilni process se musi pouzivat spravne a na spravne projekty.

    Ja pracuju ve vyvoji operacnich systemu a aplikaci pro smart karty ( SIM karty, creditky , PKI karty atd.) a tady je kompletni, jasna a predem podepsana specifikace naprosto samozrejmost. Nikdo si nedovoli mit zasadni bug v aplikaci, ktera se bude nahravat na 10 milionu karet (v cene nekdy i nekolik dolaru za jednu)...
    Ovsem psani specifikace, dokumentace a validace je 70% meho budgetu..

    Na druhou stranu zkuste takhle navrhnout mobilni applikaci nebo PC tool... Tam je stoprocentni jistota, ze vam to zakaznik hodi na hlavu aspon 70x.. Treba proto, ze ta modra neni ta spravna modra byt je to presne ta co byla popsana ve specu na zacatku...
    Samozrejme muzete zakaznika nasrat a nechat si opravu zaplatit (je to prece ve specu), ale on priste pujde jinam.. U techto projektu se rozhodne vyplati jim poslat jenom UI bez funkcionality, mozna napsanej behen 2 tydnu, a nechat je at si klikaj...

     
    Komentář ze dne: 08.12.2014 09:37:58     Reagovat
    Autor: deacon - deacon
    Titulek:Re: Re: Re:
    Souhlas. Nám bylo na přednáškách(je to už nějaká doba) řečeno, že vše jednoduché už bylo napsáno a těch pár kousků, které ne, tak na ty musíme mít kulervoucí nápad/štěstí. Jinak že budeme lepit složité věci právě z těch jednoduchých dohromady.

    Navíc se v rámci rychlosti používá čím dál vyšší jazyk(tzn. více abstraktnější) za cenu nižší rychlosti.

    Což nic nemění na tom, že když jsem viděl SW pro sdílení videa pro TV Samsung, myslel jsem, že někoho ubiju... nebo každej druhej web plnej reklam a Flashe (áááááá, savior of the Universe!)

    Komentář ze dne: 08.12.2014 08:42:06     Reagovat
    Autor: CNNPRG - CNN
    Titulek:1
    Sv. Ríbůt?:-)

     
    Komentář ze dne: 08.12.2014 14:09:39     Reagovat
    Autor: opas - opas
    Titulek:Re: 1
    A jeho prorok Dr. Watson :-D

    Komentář ze dne: 08.12.2014 09:17:50     Reagovat
    Autor: FirkaJ - JirkaF
    Titulek::D
    za 1.

    Ještě bych zařadil pány Tonejde, Nemámčas, Tosamo, ... jen si netroufám je označit za svaté, abych se nedopustil mystifikace veřejnosti.

     
    Komentář ze dne: 08.12.2014 09:40:48     Reagovat
    Autor: deacon - deacon
    Titulek:Re: :D
    Zapomněl jste na pány Někdo By Měl a Mělo By Se. Jsou to velmi vytížení pánové ^^

     
    Komentář ze dne: 08.12.2014 10:55:00     Reagovat
    Autor: FirkaJ - JirkaF
    Titulek:Re: Re: :D
    :)

    Njn, ale to už smrdí nějakou neplechou. Třeba neohlášenou demonstrací, nebo co já vím...

     
    Komentář ze dne: 08.12.2014 12:27:59     Reagovat
    Autor: z477 - tomsth
    Titulek:Re: Re: :D
    Nelze opomenout jistého pána jménem Seto - pravděpodobně Asiat; ač tito jsou, jak známo, velice skromní, houževnatí a výkonní, je mi tohoto pána líto (a to jej osobně neznám), neb denně kolem sebe slýchám "Seto zařídí..či Seto nakoupí..Seto udělá to i tamto..chudák pan Seto..

     
    Komentář ze dne: 09.12.2014 23:04:46     Reagovat
    Autor: rory2k - rory2k
    Titulek:Re: Re: Re: :D
    Byl to Japonec, celým jménem Ono Setosamo. Spekulovalo se i o příbuzenském vztahu k Yoko Ono.;-)))

     
    Komentář ze dne: 11.12.2014 10:49:01     Reagovat
    Autor: paascha - paascha
    Titulek:Re: Re: Re: Re: :D
    A co teprve jeho rodný bratranec Se Tam Doi De:-))

     
    Komentář ze dne: 08.12.2014 12:31:32     Reagovat
    Autor: vova - vova
    Titulek:Re: Re: :D
    ja stretavam pana Robimenatom

    Komentář ze dne: 08.12.2014 10:02:33     Reagovat
    Autor: salamio - salam01
    Titulek:Nevím
    Nevím, s prominutím mi to připadá jako druhořadý odvar www.databazeknih.cz/knihy/nedokonceny-kalendar-na-tento-rok-a-vsechny- roky-pristi-55306.

     
    Komentář ze dne: 08.12.2014 10:44:32     Reagovat
    Autor: LWG - LWG
    Titulek:Re: Nevím
    Tuto knihu neznám, takže ani inspiračně nemůže jít o její odvar.

    Legendu o Sv. Scurvilu jsem sepsal poté, kdy jsem po světci pojmenoval svůj alternativní emailový stavební denník, kterým jsem své známé informoval o tom, co se na stavbě zase scurvilo nebo scurvit chystalo. Když jsem četl diskusi pod článkem "nezaměstnanost", tak mě to přišlo líto jen tak hodit do komentářů, tož jsem z toho udělal článek.

     
    Komentář ze dne: 08.12.2014 10:46:57     Reagovat
    Autor: root - Root
    Titulek:Re: Re: Nevím
    Denik je cesky s jednim n, slovensky se dvema. Jinak v te legende mate celkem ohromujici kvantum gramatickych chyb, potes koste, jestli tak vypadaji i vase odvolani.

     
    Komentář ze dne: 08.12.2014 10:56:48     Reagovat
    Autor: LWG - LWG
    Titulek:Re: Re: Re: Nevím
    Na čtení profesních písemností mám člověka (jsem solidní dylsectyk). Tohle bylo původně psáno tak nějak z terapeutických důvodů pro emailové podání a párkrát překopáno, což je na tom vidět. No což, možná jsem to měl dát jako diskusní příspěvek, tam se to trochu ztratí. Stalo se.

     
    Komentář ze dne: 08.12.2014 12:36:25     Reagovat
    Autor: TParanoik - Tparanoik
    Titulek:Re: Re: Re: Nevím
    Roote, obávám se že trpíte nemocí zvanou HoSiP. Autor zde již několikrát psal i ve článcích že je dyslektik a jak to řeší.

     
    Komentář ze dne: 08.12.2014 10:47:51     Reagovat
    Autor: salamio - salam01
    Titulek:Re: Re: Nevím
    V tom případě se omlouvám a knihu doporučuji :-)

     
    Komentář ze dne: 08.12.2014 19:49:18     Reagovat
    Autor: HonzaV - HonzaV
    Titulek:Re: Re: Re: Nevím
    Jo, jo, Kalendář nemá chybu - totiž vlastně má dvě: je nedokončenej a nedá se nikde sehnat :-D

    Jamek musel být snad něčím naspídovanej, když to dával dohromady. Ty inzeráty třeba... Nebo ho bolševik musel neskutečně točit a tohle byla rafinovaná pomsta.

     
    Komentář ze dne: 08.12.2014 17:39:46     Reagovat
    Autor: cover72 - cover72
    Titulek:Re: Re: Nevím
    A dobře jsi udělal. Přesně něco takto odlehčeného a vtipného jsem si potřeboval přečíst po vší té posedlosti "propagandami těch druhých", která otravuje ovzduší v celé zemi :)
    Takže dík

    Komentář ze dne: 08.12.2014 13:37:13     Reagovat
    Autor: integrale - integrale
    Titulek:Ještě sv. Vonoseto
    Sv. Vonoseto sice pochází z východu, ale i pro křesťanství má neskonalý význam.

    Komentář ze dne: 08.12.2014 22:16:55     Reagovat
    Autor: FirkaJ - JirkaF
    Titulek:Jo za Heroda, to jste byli krotký,
    teď nám tu po světě dupou Scurvilovi botky. :)

    Teď jsem shlédl nějaký dokument o starověkých stavbách. Byly tam dvě. Chrámová hora v Jeruzalémě a Herodův kopec, kdysi s palácem.

    Scanovali to 3D scanerem a tehdy ještě Scurvil určo nežil, páč by třeba ta chrámová hora těch pár tisíc let nedala. Zajímavé bylo jak změřili tu přesnost. Odchylka 3mm ve výšce na 40ceti metrech zdi z přesných vápencových kvádrů je i na dnešek mazec.

    Chtěl bych vidět jak ručně vyrubaný kvádr 300t, 14x4m přepravovali z lomů na místo bez techniky.

     
    Komentář ze dne: 09.12.2014 14:20:31     Reagovat
    Autor: LWG - LWG
    Titulek:Re: Jo za Heroda, to jste byli krotký,
    Věřím, že si poradili a přišlo jim to normální.

    Teď jsme dělali krov. Když jsem viděl, jak jednoduchými prostředky se zajišťuje přesnost, provádí úpravy, atd., překvapovalo mě to. V podstatě stačil úhelník, kus lana, sekera, kramle, která se dala kamkoliv zarazit a střešní lať jako páka. Jistě, byla tam motorovka, která zrychlovala úpravy, které by sekerou a pilou trvaly déle.

     
    Komentář ze dne: 10.12.2014 17:21:38     Reagovat
    Autor: Libor - Neregistrovaný
    Titulek:Re: Jo za Heroda, to jste byli krotký,
    I ve starověku řádil Scurvil a některé jeho produkty existují doteď. Afaik zlatá budka nad sarkofágem jistého faraona byla sestavena obráceně a vzhledem k tomu, že části budky díky tomu neseděly, tak to tam Scurvil namlátil kladivem. Zdroj nějak nemůžu dohledat, ale mám pocit, že to byla kniha Bohové, hroby a učenci.

    Komentář ze dne: 08.12.2014 23:05:07     Reagovat
    Autor: RIK - RIK
    Titulek:hezky clanek
    Nadherne :)

    Komentář ze dne: 11.12.2014 10:47:51     Reagovat
    Autor: paascha - paascha
    Titulek::-)
    Ano, základem všeho je přesně definovaná hranice mezi vlastností a chybou, která se mění v čase a prostoru jako plamen ve větru:-)

      Stránkovat

    TOPlist

    Web site powered by phpRS V kodu tohoto webu byly pouzity casti z phpRS - redakčního systému napsaného v PHP jazyce.