Výpisky a poznámky po přečtení knihy Agilní programování (Václav Kadlec, Computer Press 2004)
Tradiční metodiky
- Vodopádový model
-
- Nejstarší metodika (70. léta), dnes už nepoužitelná
- Několik fází (specifikace, návrh, implementace, integrace, údržba), mezi kterými nelze přeskakovat, ani se vracet, na konci každé je sepsání a schálení; jediný skok: z údržby zpět na návrh
- Postřehy: nepružné, klidně se stane, že zákazník dostane něco jiného, než chtěl; vzniká hodně dokumentace (prakticky ke všemu)
- Spirálový model
-
- Komplexní, pro velké projekty
- Plánování – stanovení cílů – analýza rizik – vývoj a testování – Plánování … a takto dokola nejprve pro koncept, pak pro specifikaci, pak pro návrh a architekturu, pak pro design, implementaci, testy, …
- Před každým vývojem vyrobení prototypu
- Často se zvažují alternativy
- Postřehy: to se dělá i prototyp dokumentace i prototyp architektury? Velmi velký důraz na analýzu rizik. Objevuje se LCO, LCA, IOC.
- Rational Unified Process
-
- Rozsáhlá, placená, s nástrojem, který umožňuje “naklikat” metodiku na míru
- Objektově orientované; základ: Případy použití
- Pracovníci: (kdo? např. programátor), činnosti (např. spuštění testu), meziprodukty (např. zdrojový kód, model)
- 4 fáze, zahájení 10% / projektování 30% / realizace 50% / předání 10%; doporučuje vzdělané lidi
- Postřehy: je to velké a stojí to moc peněz; ale může to stát za to
- Unified Software Development Process (UP)
-
- “Free Alternativa RUP”
- Opět kdo (pracovníci), co (činnosti), kdy a jak; případy použití, UML; iterativní dodávky
- Čtyři fáze, mezi nimi LCO, LCA, IOC
Agilní metodiky
Stručně: jde o rychlé dodávky – zákazník rychleji zjišťuje, co vlastně chce; hodně komunikace, zákazník blízko; funkcionalita je proměnná, čas a zdoje fixní; tradiční metodiky to vnímaly opačně (naivní); někdy (XP) přibude čtvrtá proměnná – kvalita; zákazník pak nastaví tři z nich, dodavatel odpovídajícím způsobem odvodí čtvrtou
- Extrémní programování
-
- Dodává se nejjednodušší možná verze, která ještě bude fungovat; dělají se revize kódu, unit testy, všichni mění návrh a vylepšují architekturu; respekt – všichni vlastní všechen kód, kdokoliv edituje cokoliv
- vysvětlení celkové funkčnosti nějaké komponenty – metaforou
- Postřeh: pěkná idea refaktorizace – při psaní kódu buďto přidávám novou funkčnost – pak jen přidávám nové řádky kódu, žádné původní nemažu ani neupravuju; nebo refaktorizuji – pak přepisuji, upravuji a vylepšuji stávající kód, aniž bych přidal nějakou (plánovanou) novou vlastnost; takto “se přepínám” (“vyměňuji klobouky”), nikdy nedělám obojí zároveň
- Párové programování – jeden píše aktuální věc, druhý sedí a přemýšlí v globálním měřítku, jak jedna funkčnost zapadne do celkového návrhu, zdali nenaruší architekturu, testy, integritu, …
- Plánovací hra: sepíše se User story, z nich všech se sepíše závazek na nějakou skupinu funkčností (karty zadání), následují iterace vývoje
- Postřehy: předepisuje 40 hodinový pracovní týden – super; předepisuje oslavu odevzdání – super; předepisuje oslavu v případě smrti projektu – super 🙂
- SCRUM Development Process
-
- SCRUM týmy 3-6 lidí, každý den Scrum Meeting, supluje centrální plánování, iterace = sprint, na konci každého sprintu dodání Dema
- Za jeden objekt odpovídá jedna osoba; rizika se probírají na každé schůzce
- Backlog – seznam věcí, které je třeba udělat; write právo má manažer, read právo mají všichni; po každém sprintu se aktualizuje
- členové vývojového týmu – pigs; ostatní – chickens; chickens při meetingu nesmějí nic říkat
- Lean Development
-
- Pro Toyotu byl navržen postup, jak začít vyrábět auta pro všechny; jádro – vyhodit úplně všechno zbytečné, minimalizovat zásoby (nic nesmí ležet na skladě)
- Všechna rozhodnutí dělat co nejpozději; každý může rozhodovat (nižší pozice o malých věcech); neoptimalizovat zbytečně lokálně (snaha o 100% vytížení linky většinou vede k neefektivitě globálně)
- Plýtvání: programátoři programují co není třeba programovat; někdo na někoho čeká; někdo na něco čeká (stahování, instalace); kroky navíc; nepoužívání automatizovaných nástrojů; chyby
- Postřeh: Líbí se mi pravidlo: pokud nevíme jistě, zda je daná funkčnost / artefakt v produktu potřeba, nepřidáme jej; Co se stane, kdyby toto ve výsledném produktu nebylo?
- Nepsat rozsáhlé dokumentace, pokud je nikdo nebude číst
- Feature Driven Development
-
- Základ: vlastnost, formát: akce-předmět-podrobnosti
- Snaha dosáhnout vlastností relativně stejných úrovní složitosti
- Na každé vlastnosti dělá tým několika lidí, jeden člověk může být ve více týmech
- Předepisuje několik fází, ze kterých dostaneme rozdělení lidí a času a přiřazení vlastností týmům
- Vlastník odpovídá za integritu třídy; nemůže se stát, že do ní nějak zasáhne někdo, kdo nemá dostatečné znalosti souvislostí a něco tak poruší
- dvy typy nadstandardních vývojářů: šéfové týmů; vlastníci tříd
- Test Driven Development
-
- Postřeh: Zajímavý postup: nejprve napíšu kód testu, předem žádný kód programu nepíšů; až je test hotov, začnu psát kód; jakmile kód projde testem (všemi testy), okamžitě končím s programováním
- Chyby jsou odhaleny velmi brzo
- Asi nelze použít všude, ale na některé případy se může dost hodit
- Crystal
- Komplexní, “mnoho barevných obdélníků”, každý z nich je nějaká konkrétní sub-metodika
- Adaptive Software Development
- Provádějí se spekulace a všichni by se měli naučít žít s tím, že občas se něco bude muset označit za špatně zvolené (rozhodnuté) a bude nutné vybrat jiný postup a znovu vypracovat danou věc jinak; učením a sdělováním zkušeností se následující iterace lépe přizpůsobují
- Dynamic Software Development Menthod
- Zákazník musí být součástí týmu
Huuu, dostal jsem z toho husí kůži.
hezky sepsané, díky 🙂 jestli to dobře chápu tak Spirálový model je podobný RUPu a je to nastavba vodopádového modelu, která umožňuje alespoň nějakou změnu požadavků, ale nemělo by se to přehánět 😀 výhodou je, že zákazník se nestresuje, protože vidí pokroky a v případě total failu se rozpozná dřív 🙂