Klasické a agilní metodiky vývoje software

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
This entry was posted in programování. Bookmark the permalink.

2 Responses to Klasické a agilní metodiky vývoje software

  1. Praetor says:

    Huuu, dostal jsem z toho husí kůži.

  2. `-´ says:

    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 🙂

Comments are closed.