Galerija

Šta je to RUP?

Uspesna softverska firma srednje dimenzije da bi to opstala, mora se baviti trima stvarima:

a.) organizacionim procesom
b.) konstantnim podizanjem nivoa kompetencije i kvaliteta svojih ljudi
c.) da ima izvrsne product managere sa briljantnim idejama

Ovog puta zeleo bih da opisem samo prvi aspekt: Organizacioni Proces. Zasto je on vazan, i opisao bih jedan konkretan primer ciji je teoretski model razvila firma IBM i zove se RUP – Rational Unified Process. Mala deca mali problemi, velika deca veliki problemi to znaju svi roditelji. To nekako isto vazi i za firme. Dok imate desetak ljudi na okupu, dok jos svi mogu da stanu u jednu sobu i da direktor lupi pesnicom na sto i kaze bice ovako, problemi se brzo resavaju. Firme sa par stotina ili par hiljada ljudi to ni fizioloski ne mogu. I onda se firma vise ne moze voditi harizmatski, vec pravilima. Pravilima koja svi treba da nauce i prihvate, po smislu, cokolada se ne krade ne samo zato sto me mama sad gleda nego zato sto i sam verujem da je lose za porodicu da se hrana krisom krade. Jer samo tako se pravila mogu primeniti, da ih ljudi preuzmu kao svoja. Praksa je dokazala, da bi se resili problemi ovog sveta, moraju se stvarati sve slozeniji sistemi proizvodi i usluge, niz nepovezanih malih resenja resava male neesencijalne probleme. Jedan obican automobil da bi se stvorio potreban je citav niz komponenti, timova i firmi uz jaku kontrolu project managementa. Evo kako se ovim problemom bavio IBM i od cega se satoji metodologija razvoja RUP.

IBM logo

RUP je u stvari reakcija na Waterfall ili Vodopad proces, koji je bio omiljen u softverskom inzenjeringu, a narocito u vojnom inzenjerstvu u prvim decenijama softverske industrije. To je u stvari bio ideal po kome bi grupa inzenjera sela sa product managerima i napisala kompletnu specifikaciju citavog proizvoda, od A do S. Svaki aspekt bi bio analiziran, svaki detalj propisan, citav plan bi bio izradjen. Rezultat bi bila debela knjiga koju bi predali timu za realizaciju. Oni bi knjigu dobro procitali, napravili bi procenu vremena potrebnim za izradu, i kada bi proizvod zavrsili, predvidjeno i realno vreme bi bili slicni. Dakle, nema promena, nema iznenadjenja san mnogih programera. Sve se zna unapred, dakle, lako se kalibrisu serveri, zna se kojom brzinom treba da rade, pravi raj. Sve divno i krasno osim jednog malog detalja, proizvod nakon svog izbacivanja na trziste vise nije potreban ili je prevazidjen konkurenciom. Obicno su takvi projekti bili dugi, a softverska industrija je predinamicna da bi trpela staticne projekte duge 2-3 godine. I mnogi projekti iako jako dobro planirani i izvedeni nisu bili isplativi. Dakle problem. Nakon toga, IBM (ali i drugi) su se setili i izmislili novi slogan „Embrace The Change“, ili „Prigrli Promene“. Kao prvi korak, veliki dugi vodopad su podelili na nekoliko kracih. Projekat od 2 godine je podeljen na 4 pod-projekta od 6 meseci, izradio bi se svaki deo, proizvod bi se lansirao interno u okviru organizacije ili na samo trziste, analizirao bi se i onda bi se napisala nova specifikacija za sledeci pod-projekat od 6 meseci. Vec to je donelo ogromne uspehe i proizvodi su postali mnogo korisniji za trziste i profitabilniji za firme. Ali ni to nije bilo dovoljno, pa se i sam vodopad morao podeliti na pod faze, ali ovog puta ne samo vremenke vec i kvalitativne. Poznate faze se zovu: inception, elaboration, construction i transition. Ili u prevodu: pocetak, razrada, izgradnja i plasiranje. U fazi koja se zove inception ili pocetak ne trazi se od product managera cela specifikacija vec najvaznije crte odrednice. Inzenjeri identifikuju koje probleme treba resiti i daju prvu procenu vremena izrade celog sistema, Ako to biznisu oidgovara, ulazi u sledecu fazu elaboration ili razrada. Prethodno uoceni problemi se razradjuju i na kraju faze se izlazi ili sa konkretnim teoretskim resenjima ili projekat propada, uz to se ponovo biznisu daje nova procena vremena izrade sa novim saznanjima tokom razrade. Ako to biznisu odgovara ide se u trecu najduzu ali najjednostavniju fazu: construction ili izgradnja. Najduza je jer su sva resenja iz razrade teoretska, sada ih treba i realizovati, ali je najlaksa je jer ima veoma male rizike. Rizici su otklonjeni u prethodne dve faze koje su krace ali veoma intenzivne i bave se iskljucivo napadanjem teskih problema. Nakon ove faze, ako je sve proslo u redu, ulazi se u cetrvrtu fazu transition ili plasiranje, gde se projekat integrise i instalira kod klijenta.

Cilj ove nove podele projekta na cetiri faze je da se svi rizici otklone u sto kracem vremenu. RUP je rukovodjen geslom „Early Fail“, ili „Rano Propadanje“, sto znaci ako projekat nema smisla sa stanovista realizacije, budzeta, vremena ili same ideje, dobro je i zdravo za firme da takvi projekti propadnu dovoljno rano da se u njih ne ulaze previse, dakle u trecu najskuplju fazu treba da ulaze samo provereni projekti koji odgovaraju biznisu.

Zvuci jednostavno, ali vam garantujem da firme koje su presle iz nestrukturianog procesa u RUP procese, su imale ogromne teskoce kulturnog prilagodjavanja, koje moze da traje i po nekoliko godina. Reci product managementu, zao mi je vas projekat se ne moze realizovati je tezak udarac, i potrebno je biti veoma jak da se takva istina proguta. Ali bolje i to nego duga agonija i izvesna smrt.

Ako želite da odslušate, prilog počinje na 24 min 40 sek

Advertisements

One comment on “Šta je to RUP?

  1. Povratni ping: Ako mušterija hoće i jare i pare, neće ići | Markus Maki

Zatvoreno za komentare.