Agile v praxi v services nikdy nefungoval - doporučuju nastudovat si zveřejněné případové studie. Interně si můžete jet iterace, ale externě existují pouze dvě data: počátek projekt a datum předání, stejně jako očekávaný scope a cena. Byl jsem velký fanda agilního vývoje, v R&D jsme tak jeli dlouho, ale to je jiný svět než service delivery.
BTW, jedna ze základních pouček u agilního vývoje je, že musí být variabilní složky "železného trojúhelníku" (scope, čas, cena). A explicitně že v případě fixed price, fixed scope... nemá agile smysl ani žádnou hodnotu, což dá rozum, když nemůže nic měnit.
Agile nefungoval, protože by v principu negungoval. Agile nefungoval, protože tebou braný metriky vzaly ty MBAčka jako fixed. V praxi při vývoji pracuješ s
odhadem. Ten říká, že "s pravděpodobností X bude v den Y aplikace v požadovaným stavu." MBAčka to vezmou tak, že "S pravděpodobností 110% to dodáme v čase Y/2".
A obecně jsou tyhle možnosti:
a) Jede se na fixní cenu a čas: Co se stihne, to se stihne. Udělá se FMEA s prioritama a jede se podle ní.
b) Jede se na fixní featury a čas: Udělá se kostra a na ni se věší featury. Aby se to stihlo, přidávají/ubírají se lidi, kteří přidávají featury. Podle toho se mění cena
c) Limitují to featury a rozpočet, tam je variabilní čas a obvykle se dostane někam, kde už produkt nemá smysl, nebo se ošidí.
d) Jede se podle milníků (v tom a tom čase musí být to a to) s paušálem. Odhaduje se od milníku k milníku, je tam feedback a pokud jednou podstřelíš, zahojíš se příště. Proti fixed features je možnost reagovat na konkurenci (tohle se konkurentům neosvědčilo, udělejme to takhle) a změny podmínek (migrace na jinou DB / verzi knihovny) - takže iterace a jedeš agile.
Ale vraťme se k tématu - kvalita něčeho, co už neexistuje (čti "zkoumejme vlastnosti objeku, na který ukazuje null pointer")