Portál AbcLinuxu, 16. listopadu 2025 23:07
Jak se v knize pise, tak hlavni problem je prave v tom perfekcionismu. Mame tendenci vydat program az kdyz je dokonaly (my, jako evropane). Zatimco (viz treba MS) oni vydaji program o kterem vedi, ze ma k dokonalosti daleko, a pak postupne vydavaji opravy.
Problem je v tom, ze kdyz my vydame svuj perfektni program, tak trh je uz zvykli na konkurencni, ikdyz mene kvalitni, a nema chut prechazet.
Takze at se nam to libi nebo ne, tak jejich postup je vetsinou trzne uspesnejsi.
Taky cisty SCRUM nefunguje rovnako, ako nefunguje cisty vodopad. Podla skusenosti je dobre prejst si viac metodik, z kazdej zobrat jednu-dve veci, ktore vyhovuju danemu timu ci organizacii, ostatne zahodit. Proste vytvorit si vlastnu metodiku situ na mieru. Kent Beck tak odporuca zavadzanie XP: vezmite najpalcivejsi problem vasho timu a rieste ho v style XP (ja by som rozsiril ze v style agilneho programovania), az prestane byt problemom. Postupujte dalsim problemom. XP niekedy nemusi vyhovovat. Ja by som to pretransformoval takto: identifikujte svoj najpalcivejsi problem, najdite vhodne riesenie v metodike, ktora ma tuto oblast zvladnutu dobre a zaroven jednoducho a zavedte to u seba. Ked sa takto budu riesit problemy vyvoja, moze sa dost k zaujimavej hybridnej metodike, kde napr. specifikacia bude z vodopadu, implementacia bude feature driven, integracia bude z XP, testovanie zo spiraly a komunikacia v time sa bude riesit "skrumazami".
Prvykrat som ju cital zbezne, druhykrat zo zvyraznovacom v ruke a viem, ze ju budem citat znovu. Ak robis vyvoj softveru v time, je tych par korun vysoko navratnou investiciou; ak, pravda, nemas zvladnute vsetky metodiky aspon tak (alebo lepsie), ako su rozobrate v knihe. Ale dovolim si tvrdit, ze o tretine z v knihe rozoberanych metodik vacsina vyvojarov ani nepocula a nevie ze existuju.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.