Při vyvíjení softwaru nás čeká hodně úskalí a problémů. Každý projekt je jiný, zákazník je jiný, tým je jiný apod. Neexistuje nějaký unifikovaný návod na to, jak dělat projekty, aby se všechno splnilo na 100 %. Každopádně je důležité identifikovat problematická místa a jejich řešení testovat na dalších projektech (a případně tato řešení zanést do běžných postupů).
K tomu existují i metodiky, které tyhle pracovní postupy standardizují.
- přínosy: standardizace pracovních postupů
- opakovatelnost
- zjednodušení řízení projektu
- snadnější kontrola, měření, vyhodnocování, odhadování
- definice požadovaných artefaktů a jejich obsahu
- nevýhody:
- práce navíc, potřeba se metodiku naučit a seznámit s ní tým
- metodiku je potřeba přizpůsobit pro aktuální projekt a tým
- nějaké jsou placené
Žádná metodika není nejlepší. Je hodně potřeba ji přizpůsobit projektu. Nelze však vynechávat části, které metodika považuje za povinné.
A pozor na přehnanou důvěru v metodiku, není to žádná garance úspěchu projektu.
Klasické
- důraz na tvorbu dokumentace
- jsou propracovanější a složitější (někdy přidělávají až moc práce)
- řeší širší spektrum problémů
- Unified process (UP), MSA (= modern structured analysis), RUP (= rational unified process)
Agilní
- zaměření na vlastní tvorbu produktu
- množství dokumentace se minimalizuje
- cílem je co nejdříve dodat první verzi zákazníkovi a úpravy se jedou až ze zpětné vazby
- SCRUM, TDD (= test driven development), XP (= extrémní programování)
- Agilní přístup