Troška idealismu nezaškodí.... celá řada přístupů metodika vývoje by se měla vždy přizpůsobovat konkrétním podmínkám nejedná se o normu, absolutní pravdu.

Prezentace na téma: "Troška idealismu nezaškodí.... celá řada přístupů metodika vývoje by se měla vždy přizpůsobovat konkrétním podmínkám nejedná se o normu, absolutní pravdu."— Transkript prezentace:

1 Troška idealismu nezaškodí...

2 celá řada přístupů metodika vývoje by se měla vždy přizpůsobovat konkrétním podmínkám nejedná se o normu, absolutní pravdu jedná se o soubor vhodných a doporučených postupů Dva základní typy SW (z pohledu vývoje): „krabicový“ – poskytovaný „as is“, bez nároku na změnu (krabice × služba) na míru – buď přizpůsobený podle požadavků zákazníka nebo kompletně celý na míru

3 Kroky sběr požadavků, specifikace zadání analýza požadavků návrh řešení, architektury, výběr technologie vývoj, programování testování nasazení reklamace... ?

4 Výchozí předpoklad: Zákazník není přesně schopen specifikovat co potřebuje, protože: 1.jeho potřeby se neustále mění 2.sám neví jakým způsobem řešit svoje problémy Agilní metodika ≈ Dobře organizovaný chaos Rezignujeme na fázi „specifikace zadání“ Rezignace na zadání = chaos

5 Navrhují a implementují se pouze aktuálně požadované funkce. Nevytváří se něco, co možná někdy někdo bude potřebovat. Místo křížového výslechu zákazníka se preferuje rychlé vytvoření prototypu. Refactoring, refactoring, refactoring, refactoring,... -> Testování (automatické) Požadavky od zákazníka se sbírají a zaznamenávají. Vedoucí projektu ve spolupráci se zákazníkem přiděluje požadavkům prioritu.

6 Klíčovou součástí je intenzivní komunikace manažer projektu – zákazník manažer týmu – zákazník manažer projektu – manažer týmu člen týmu – manažer týmu člen týmu A – člen týmu A člen týmu A – manažer týmu B člen týmu A – člen týmu B časté schůzky, práce ve skupinách, brainstorming, teambuilding

7 Vývojový tým musí být schopen reagovat na stále měnící se požadavky zákazníka. Vývojový tým musí být schopen flexibilně měnit strukturu/architekturu aplikace. Zákazník musí být schopen přijmout měnící se termín dodání požadovaných funkcí. Vývojový tým musí být schopen dělat to, co chce zákazník a vzdát se toho, co chce vývojový tým. Vývojáři nesmí být líto „zahodit“ svou práci.

8 Nejznámější: Extrémní programování SCRUM Další: Crystal Adaptive software development Test driven development Z velké části jsou to variace na totéž téma

9 vedou k rychlejšímu dodání nejnutnějších funkcí celkový čas realizace projektu bývá spíše delší (vzhledem k mnoha změnám) zákazník je ale spokojenější, protože může nejnutnější funkce používat rychleji agilní metodiky jsou vhodnější pro menší projekty a menší skupiny lidí vhodnější pro SW na míru

10 na velmi velké projekty (stovky vývojářů, roky vývoje) jsou naprosto nevhodné příliš málo organizované a příliš chaotické na některé projekty nelze použít vůbec – komplexní systémy, kde nelze vyžadovat zpětnou vazbu od zákazníka (např. jádro OS) vyžadují spolupráci od zákazníka vyžadují spolupráci zaměstnanců, aktivní účast na projektu

11 Konec idealismu, zpět k realitě

12 sběr požadavků od zákazníka stanovení priorit vedoucím projektu analýza požadavků a návrh řešení nejjednoduššího pro vývojáře (snaha vyhnout se refactoringu) implementace některých požadavků s nejvyšší prioritou skoro podle požadavků zákazníka refactoring kvůli realizaci požadavků s nižší prioritou termín předání předání zákazníkovi buď lehce otestované, hodně po termínu, nebo neotestované skoro v termínu reklamace – skoro zaplacení – soud – exekuce

13 Dokumentaci uděláme později, protože zdržuje. Testy doděláme až to bude hotové, aby se nemusely pořád přepisovat. Začneme to implementovat hned, jak přijde specifikace od zákazníka Zákazník chce X, ale uděláme Y, protože to je lepší/rychlejší/jednodušší. To si nemusím psát, to vím/si pamatuji. Potřebujeme software X, abychom mohli vývoj organizovat.

14 teoreticky jsou agilní metodiky relativně jednoduché horší je to s jejich dodržováním zkusíme experimentovat a vyvinout kousek nějakého existujícího SW každý bude dělat něco a dohromady to bude stát za to SCRUM metodika cílem je vyzkoušet agilní postupy v praxi jsou velmi užitečné i mimo agilní vývoj

15 Aplikace Task manager Task Management – plánování úkolů, sledování dokončenosti, plánování projektu Další drobné funkce – sledování emailů, grafy Brněnská firma IT Park PHP + MySQL Nabízíme možnost vykonání povinné praxe Bakalářská – 100 hodin Magisterská – 150 hodin Sledování hodin

16 do čtvrtka (25.9.2014) poslat strukturní odborný životopis vynechte osobní údaje čím můžete přispět k řešení projektu jakou funkci můžete/chcete zastávat vedoucí (skupiny/projektu) vývoj testování překlad/dokumentace ostatní? Zašlete na ondrej.popelka@mendelu.czondrej.popelka@mendelu.cz