◀

Úvod

Troška idealismu nezaškodí…

Metodiky vývoje SW

  • vždy: zadání ⇒ analýza ⇒ návrh ⇒ implementace ⇒ testování ⇒ nasazení ⇒ údržba
  • délka trvání jednotlivých kroků?
  • celá řada přístupů v organizaci kroků
  • metodika by se vždy měla přizpůsobovat konkrétním podmínkám
    • nejedná se o normu a absolutní pravdu
    • soubor vhodných doporučení

Metodiky vývoje SW

  • 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 - přizpůsobovaný požadavkům zákazníka (customizace) nebo kompletně na míru
  • enterprise vs. startup

„Klasické“ Metodiky

  • 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 … ?
  • Klasické != Staré

„Agilní“ Metodiky

  • Výchozí předpoklad:
    • Rezignujeme na fázi specifikace zadání.
    • Zákazník není přesně schopen specifikovat co potřebuje, protože:
      • jeho potřeby se neustále mění,
      • sám neví jakým způsobem řešit svoje problémy.
  • Rezignace na zadání = chaos a ☠
  • Agilní metodika ≈ Dobře organizovaný chaos
    • Neorganizovaný chaos = ☠
  • Přenesení zodpovědnosti × Micromanagement

Hlavní zásady

  • 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, …
    • Vyžaduje automatizované testování
  • Všechny 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.

Hlavní zásady

  • Komunikace:
    • intenzivní,
    • placatá struktura,
    • časté schůzky, práce ve skupinách,
    • meeting, briefing, brainstorming, já jsem king …

Hlavní zásady

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

Flexibilita

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

Vlastnosti

  • AM 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.
  • AM jsou vhodnější pro menší projekty a menší skupiny lidí.
  • AM jsou o něco vhodnější pro SW na míru.

Vlastnosti

  • 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ů (softskills), aktivní účast na projektu.

Pokračování

Konec idealismu, zpět k realitě

Bastardní Metodiky

  • sběr požadavků od zákazníka
  • stanovení priorit vedoucím projektu
  • analýza požadavků a návrh nejjednoduššího řešení (není čas na refactoring)
  • 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
  • pevný 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 - ☠

Bastardní Argumenty

  • Na to není čas
  • Dokumentaci uděláme později, protože zdržuje.
  • Testy spustíme až nakonec.
  • Dokumentaci uděláme až to bude hotové.
  • 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.

Bastardní Argumenty cont.

  • Potřebujeme software X, abychom mohli vývoj organizovat.
  • To si uděláme sami (líp, levněji, rychleji).
  • Uděláme X, to se budou jednou hodit.
  • Když už se to mění, tak uděláme XY.
  • Uděláme to takhle, dořeší se to potom.
  • Když už je to napsaný, tak to tak necháme.

AMP

Jak se nesklouznout k bastardním metodikám.

AMP

  • teoreticky jsou agilní metodiky jednoduché
    • horší je to s jejich dodržováním
    • je snadné minout princip a sklouznout k formě (5 min)
  • 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

AMP Co

  • 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
  • Aktivní účast na projektu.
  • Možnost vykonání povinné praxe
    • Magisterská – 150 hodin
    • Sledování hodin (nahlásit předem)

AMP Jak

  • Cvičení, Přednášky
  • Daily standup
  • Sprint
  • Úkoly
  • Slack
  • TimeTracking

AMP

  • do čtvrtka dopoledne (27. 9. 2018) poslat strukturovaný odborný životopis
    • vynechte osobní údaje
    • čím můžete přispět k řešení projektu
    • jakou funkci můžete/chcete zastávat
      • teamleader
      • vývoj
      • testování
      • překlad/dokumentace
      • ostatní?
    • Zašlete na jiri.lysek@mendelu.cz
  • Aktivovat účty ve Slacku a BitBucketu