@nkrgovic - pa automatizacija se primenjuje i u waterfal modelu - upravo takva kakvu si opisao.
Scrum bi bio najbolje opisan kao servisno orjentisan model razvoja - gde korisnik kontinualno placa i ima mogucnost da paralelno koristi aplikaciju koja se kontinualno razvija za njega. Dok waterfal je orjentisan ka prethodno jasno definisanom proizvodu - i kraj je isporuka gotovog proizvoda.
Dakle waterfal - ides kod arhitekte, on ti napravi dizajn kuce, i sve proracune, statiku, orjentaciju i dostavi ti detaljni projekt. On angazuje majstore, koji imaju jasno podeljene role, datume kad grade koji deo kuce, i kriterijem kad su zavrsili svoj deo. Uspesan zavrsetak projekta je objekt koji je inicijalno dogovoren sa arhitektom.
Scrum, skupis majstore i dogovoris da sledecih 2 godine grade za tebe, i definises sta je minimalno uslov da bi se taj objekt koristio kao kuca. Kazes, meni je ok ako mi podignete prvi sprat i stavite krov. Ti se uselis. Skontas fali garaza - skupis majstore kazes, prioritet mi je garaza - oni sledecih mesec dana pikaju garazu. Posle toga kazes - ajde da dignemo jos jedan sprat, oni skidaju krov, zidaju sprat itd.
E sad - koristio sam primer kuce da pokazem kako je scrum ustvari neupotrebljiv kod tog taska. Ali je veoma upotrebljiv kod razvoja sw, posto korisnik definise "projekt kuce" na pocetku, ali veoma brzo shvati da taj projekt ima 70% stvari koje mu nisu bitne, a fali mu 30% stvari koje su mu krucijalne, i to u pola projekta. Tako da je veoma koristno da kroz scrum ima mogucnost da kontinualno menja svoje zahteve i prilagodjava projekt svojim potrebama, dok istovremeno koristi isti taj software koji se razvija za njega.
I scrum jako jako dobro funkcionise sa malim timovima, ali je problematican za velike organizacije, posto ne postoji nikakva jaka struktura, niti metod saradnje razlicitih scrum-ova ni top managamenta itd. Nista nije definisano, i onda ulecu koje-kakvi hibridi i frankenstajni