Jajj ne már, sikerült annyi félreértést összeírnod, hogy muszáj reagálnom :)
Mondjuk kezdem azzal, hogy egyértek: sok cégnél annyira személytelenné és felhasználó- illetve üzletmentessé vált a fejlesztés, hogy elszakadnak a valóságtól. Ez sajnos ilyen szakma, de azért nem reménytelen a helyzet. Az is tény, hogy sokan úgy tanítanak / konzultálnak / gyakorolnak dolgokat, hogy nem értik meg a lényegét, így inflálódott el az is, hogy "agilis", és így került a rossz gyakorlatok által rengeteg félreértés a téma köré. Ez egy kicsit reménytelenebb, mert az ilyen típusú emberek tipikusan "hangosabbak".
DE. (jó nagy de...)
A Scrum esetében:
- Eleve azzal kezdi, hogy "itt van kb. 10 módszer, használd azt, amit jónak látsz belőle, és használd azt, amit ezen kívül a szervezeted szükségesnek tart". Tehát Egy_Igaz_Agilis_Út-ról beszélni eleve sarlatánság, minimum 1000 variáció létezik belőle. Innentől kezdve az, hogy "az agilis nem működik" finoman szólva egy figyelmeztető jel arra, hogy kivel állsz szemben :)
- Azt senki nem ígéri, hogyha ki akarod zárni a világot, akkor nem tudod kizárni (azaz továbbra is tudsz a világtól elszakadva fejleszteni), viszont ha ezt felismered és nem akarod kizárni a világot, akkor a Scrum ad egy feedback-loopot, amihez lehet igazodni... És az igazodás a megrendelőnél és a fejlesztőknél is ugyanaz a pont, ami pl. egy waterfall esetében Az_Aláírt_Specifikáció, addig Scrum esetében a Fontosnak_Gondolt_Problémák. Hogy ténylegesen jól gondolják-e a fontosságot, az ugye egy más kérdés, ami nem technológiai/módszertani, hanem inkább HR-/üzleti elemzés kérdés.
- Azt senki nem ígéri, hogyha X módszertant használsz, akkor hirtelen megtáltosodsz, és 40 órányi munkák végzel el 1 óra alatt, vagy hogy hirtelen nem lesz szükséged szaktudásra. Sokat küzdöttem olyan managerekkel, akik ilyen mondatot akartak kipréselni belőlem (hogy aztán 200 fős olcsó outsource "scrum team" csinálhassa a munkát), de hiába, ezt csak azok merik kijelenteni, akik nem végeznek igazi fejlesztést. Viszont a Scrum segít abban, hogy a 40 órányi munkád nagyobb arányban legyen értékes, mint waterfall esetében. És itt az értékes (illetve annak aránya és megváltozása) az elég emberfüggő, meg csoportfüggő, meg szervezetfüggő, meg üzletfüggő...
- Azt senki sem ígéri, hogy Scrum esetében megúszod a tervezést vagy az újratervezést, vagy éppen a fejlesztés kidobását (vagy ha ezt ígérik, akkor megintcsak nem csináltak még valódi fejlesztést). Az ígéret arról szól, hogy korábban kiderülnek a problémák, amikre reagálni kell. Aki látott már 4+ éves projekteket "sikerülni", az sejti, hogy mire gondolok, és sajnos nem csak az állami szférára jellemzőek, sokkal inkább a pointy-haired-boss/clueless-megrendelő tipikus esetei.
Van még egy csomó más apróság is, de ezeket ki kellett írni ide :) Ahogy látod, nálam a scrum inkább a termékfejlesztésről és nem annyira a szoftverfejlesztésről szól. Persze, a cél tipikusan szoftver, és mint ilyen kell hozzá véső meg kalapács (*), viszont a scrum jól segíti azt a fókuszt, hogy ne csak egy lefordított bináris legyen a végeredmény, hanem egy termék is. Ettől még van akinek scrum nélkül is természetes módon adódik a termékfejlesztés része, és van akinek scrummal sem megy...
(*) mint tudjuk, ezek a szoftverfejlesztés elengedhetetlen eszközei a debugger mellett. on different topic: a kőműveseknél mi a debugger? :)