MythBuster vs Agile – Mit 4: Agilne metodologije su korišćene i koriste se na izuzetno velikim projektima

U radu “WHAT IS THE ROI OF AGILE VS. TRADITIONAL METHODS?” (David F. et al., 2008) pored ostalog u svom zaključku kaže:

“Agile, new product development methods have been used for many large-scale, complex research and development projects such as Lockheed’s SR-71, NASA’s Apollo, and the Jet Propulsion Laboratory’s deep space probes.”

Lockheed-ov SR-71 razvijan je za potrebe Hladnog Rata i već dugo nije u upotrebi a Apollo program slanja čoveka na Mesec zatvoren je još 70-tih godina prošlog veka tj. pre nastanka agilnih metodologija. Ipak treba biti realan.

Takođe treba imati u vidu da je, u vreme široke upotrebe ”starih”  tradicionalnih metodologija nastalo većina današnjih operativnih sistema, većina rešenja za obradu teksta, većina rešenja za tabelerne proračune, većina baza podataka, svi ozbiljniji RDBMS sistemi, većina Mail servera, svi veći ERP sistemi itd. Takođe treba imati u vidu da se danas, sa novijim Agilnim metodologijama, vrlo malo toga novoga razvija i da je većina razvoja, kad su veći i ozbiljniji sistemi u pitanju, ustvari rad na novim verzijama, sitnijim doradama, refactoring-u postojećih sistema. Samim tim postavlja se pitanje koji su to danas projekti koji se mogu uporediti sa, recimo, kompletnim razvojem novog RDBMS-a, od početka do kraja, i da li takvi projekti mogu kompletno da se realizuju u skladu sa Agilnim principima?

Mit 4: Nepotvrđen

Literatura:

 

4 comments

  1. Jovan Popovic says:

    Ovo je zanimljiva tema ali na zalost ima suvise malo podataka da bi potvrdila ili opovrgla ova hipoteza. Kada bi mit bio da se trenutno vise koriste tradicionalne tehnologije na velikim projektima i taj mit bi na isti nacin bio nepotvrdjen zbog “nedostatka dokaza”.

    Na primer mogli bismo da izvucemo neki rad kao http://collaboration.csc.ncsu.edu/laurie/Papers/ESEM11_SCRUM_Experience_CameraReady.pdf koji govori o projektu koji je radjen agilno (19 ljudi, 18 meseci) u Microsoftu i da uzmemo to kao dokaz da se agilini razvoj primenjuje u velikim firmama (ako Microsoft nije primer velike softverske kompanijee ko je?) na velikim projektima.

    Ja verujem da sami timovi na osnovu svoje procene i dobrih/losih iskustava biraju agilne ili formalne metode. Mozda to zavisi i od tipa projekta. Slazem se da su sistemi napravljeni jos pre 10 godina sa nasledjenim kodom uradjeni formalnim metodologijama i to se ne moze promeniti, medjutim ako govorimo o novim velikim aplikacijama, onda su bolji primeri Facebook, Linkedin, Twitter, Azure. Iskreno, ne verujem da je Facebook pravljen nekom teskom specifikacijom ili UMLovanjem. Isto tako ako vidimo kako Microsoft/Google izbacuju beta verzije novih sistema/aplikacija i stalno ih menjaju to mi vise lici na metodologiju ispitivanja trzista sto vise lici na agilan a ne na strogo predefinisan razvoj.

    Mislim da bi ipak trebalo upotpuniti ovu analizu sa nekim podacima koje su objavile stvarno veike kompanije i kojima se jasno kaze sta one koriste u razvoju.

    • gmilanov says:

      Odličan komentar. Hvala. Primer sa Microsoftovim projektom je Ok ali ja nisam nigde napisao da velike firme ne rade neke projekte u skladu sa preporukama nekih agilnih metodologija. Verujem da je malo verovatno da se veći projekti u potpunosti rade u skladu sa nekom agilnom metodologijom. S druge strane kad je pomenuti primer sa Microsoftom u pitanju sami brojevi od 19 ljudi i 18 meseci se baš i ne slažu sa Agilnim. Podsetiću da je SCRUM preporuka da tim ima 5-7 osoba i da projekat ne traje duže od 3 meseca. Microsoft takođe ima svoju metodologiju, Agilni MSF, koji je po mom mišljenju mnogo ozbilnija metodologija od recimo SCRUM-a. Na kraju krajeva nebitno je. Iza ovog mog kratkog posta je priča da SCRUM (kao najšire korišćena agilna metodologija) baš i nema striktno definisano kako zajedno radi više agilnih timova. Kad neki autori to i pokušaju da definišu (recimo Ken Schwaber, The Enterprise and Scrum, Microsoft Press, 2007) cela ta priča više i ne liči na agilno već na iterativno. Šta će u nekoj realnoj priči od recimo 60 developera razbijenih u više timova da ostane od agilnog? Verovatno samo način pisanja dokumentacije. Kad sam već pomenuo dokumentaciju, Vi ste pomenuli UML i iterativno. Smatram da su UML i agilno itekako spojivi i da se mnogo toga dobroga može dobiti u tom spoju. Ipak ne treba praviti nauku od dokumentovanja sistema. Bitno je da dokumentacija bude jasna i dovoljna da bi se razvio kvalitetan proizvod. Sve u svemu, slažem se sa Vama i potrudiću se da ovaj moj post produbim u mojim narednim postovima u skladu sa nekim tezama koje sam u ovom mom komentaru samo nabacao.

    • gmilanov says:

      Apsolutno se slažem da moj zaključak nije baš argumentovan. Zaključak da SCRUM ne može da u potpunosti da pokrije sve što je potrebno da bi se organizovao rad više timova na nekom većem projektu baziram samo na mojim iskustvima. Smatram da je moguće organizovati da se neki delovi većeg projekta razvijaju u skladu sa SCRUM preporukama ali ne i ceo projekat. I sama teorija, kad je u pitanju organizovanje više SCRUM timova na većem projektu, je problematična. Ono što piše Ken Schwaber je Ok ali se to ne razlikuje od preporuka Iterativnih metodologija za organizovanje više timova na većem projektu. Scrum of Scrums (Mihe Cohn) je problematično samo po sebi zato što se integritet SCRUM tima garantuje samo do kraja konkretnog sprinta. To znači da bi posle svakog sprinta, pošto bi morali da preuredimo timove, a neke i da ugasimo, morali ponovo da formiramo sve hijerarhijske Scrum of Scrums timove (odozdo pa naviše). Tek je to blago rečeno nerealno…

  2. Jovan Popovic says:

    Mozda nisam dobro razumeo temu posta, ali ako je tema da li se agilne metodologije koriste na velikim projektima, onda cak i na osnovu Vaseg odgovora mozemo zakljuciti da ako Microsoft koristi MFS Agile i ako ga koristi ne nekom od svojih projekata (koji su obicno veliki) onda to upravo dokazuje mit. Na zalost, ja nemam nikakav rad koji to dokazuje(ovaj govori o scrumu), tako da je mit i dalje niti potvrdjen niti nepotvrdjen.

    Ako je tema kritika SCRUM-a onda diskusija zasluzuje poseban post. Ja cu samo ukratko odgovoriti na Vase komentare:
    1. SCRUM ne ogranicava velicinu projekta niti velicinu tima (bar ne po zvanicnom Scrum guide koji su napisali Schwaber i Sutherland – ja ne racunam samostalne filozofe koji daju svoja licna misljenja). Ne verujem da bi bilo kakav SCRUM tim odbio projekat samo zato sto ima mnogo da se radi (vise od tri meseca). Cak je sprint u scrumu nekada i mesec dana pa bi to znacilo da projekat moze da traje ne vise od tri sprinta, a to onda vise lici na par mini verzija u manjem MSF projektu.
    2. Ogranicenje na 5-7 clanova je u stvari nesto sto se radi u praksi (cak postoji i PM termin management span koji to opravdava), iako nije obavezno po scrumu. Cak i u “formalnim” metodologijama bismo verovatno podelili tim od 50 ljudi na podgrupe koje bi radile na koliko toliko nezavisnim delovima. Koliko je to uspesno u SCRUMu ne znam, ali isti problemi deljenja tima su u svim metodologijama. SCRUM ima integraciju podeljenih timova pomocu Scrum of Scrums sastanaka, CMMI ima Integrated Project Management za takve slucajeve, ne znam koliko detaljno ostale metodologije govore kako treba raditi u tim slucajevima, ali verujem da uspesnost zavisi od tima do tima.
    3. Pravi SCRUM je toliko pojednostavljen model bez jakih ogranicenja i pravila da dva tima koja rade 90% razlicitih procesa mogu da tvrde da koriste SCRUM, samo ako koriste 10% obaveznih stvari. Zbog toga je nemoguce definisati kriterijum koji bi rekao da li neki tim “u potpunosti radi u skladu sa skrumom” cak i ako radi na velikom projektu.
    4.Slazem se da je UML+agile odlican spoj. Cak u eXtreme Programmingu (koji je po meni jos uvek prva i prava agilna metodogija bez obzira sto je SCRUM u modi) je obavezno koriscenje modelovanja, CRC kartica i slicno. Cak su definisali i Agile modeling kao skup najbitnijih modela koje treba napraviti ali i dalje je akcenat bio na vizuelizaciji i modelovanju. SCRUM je samo pojednostavljena verzija koja dosta stvari iz XPa prebacuje u opcione, pa se u praksi na zalost i ne koriste.

    Praticu vase naredne postove nadam se da ce biti zanimljivi kao i ovaj.

Leave a Reply

%d bloggers like this: