is250 arhitekturaitsistemaorganizacije is250 arhitekturaitsistemaorganizacije l13 1

Lekcija 13 - LEAN iagilni razvoj softvera

| Contents | 2

Contents

LearningObject................................................................ 3LEAN i agilni razvoj softvera; Unapredjenjeizgradnje EA eliminisanjem otpada............... 3Agilni razvoj softwara.......................................................................................................3Prednosti i nedostaci agilnih metodologija...................................................................... 4Da li između agilnosti i arhitekture postoji antagonizam?............................................... 5LEAN razvoj softvera........................................................................................................6Kaban softver................................................................................................................... 8Kako eliminisanjem otpada unaprediti proces izgradnje arhitekture............................. 10Sedam vrsti otpada u EA...............................................................................................10Alati za analizu vrednosti u EA ( Matrica EA otpada).................................................... 14Tok vrednosti u EA.........................................................................................................15Dizaj strukturne matrice (Design Structure Matrix - DSM).............................................16LEAN i agilni razvoj softvera; Unapredjenjeizgradnje EA eliminisanjem otpada............. 17

| LearningObject | 3

LearningObject

LEAN i agilni razvoj softvera; Unapredjenjeizgradnje EAeliminisanjem otpada

UvodKao što je u prethodnom predavanju rečeno, radi dobijanja što efikasnije arhitektureprimenjuju se principi jednostavnosti (lean), agilnosti i Enterprise 2.0.U ovom predavanjuse detaljnije govori o agilnom i LEAN razvoju softvera. Agilna metoda, za razliku od modelavodopada, korisnicima i zainteresovanim stranama kontinuirano isporučuje radne verzijesoftvera s ciljem da se one u svakoj sledećoj iteraciji unaprede. LEAN razvoj softverase s druge strane bazira na sedam principa: Eliminisanje otpada, Izgradnja kvaliteta,Kreiranje znanja, Odlaganje donošenja konačne odluke, Brza isporuka, Respektovanjeiljudi i Optimizacija celine koji su u predavanju ukrazko objašnjeni. U predavanju segovori i o Kanban načinu razvoja softvera, gde se za ranzliku od agilnih metoda, iteracijeopcione. Umesto na iteracije, Kaban se fokusira na sprovođenje “pull” principa proivodnjesoftvera.Važno pitanje na koje se u ovom predavanju daje odgovor je “Kako eliminisanjemotpada unaprediti proces izgradnje arhitekture?” U predavanju je navedeno sedam vrstimogućih otpada u EA a zatim objašnjeni alati za analizu vrednosti u EA, kojima se otpad možeeliminisati i na taj način unaprediti proces EA.

Agilni razvoj softwara

Cilj• Objasniti agilan način razvoja softvera

Agilni razvoj softwaraTradicionalni pristup vodopada u razvoju softvera pretpostavlja da računarski system možebiti dizajniran i planiran unapred, bez obzira što složenost sistema može da bude takvadanjegova implementacija traje nekoliko meseci ili čak godina. Međutim, napor da se unapredprikupe svi zahtevi čak i umereno složenih aplikacija, je ogroman . Uprkos svim pokušajima,očekivanja korisnika i zainteresovanih strana ćestonisu ispunjena.

Tražiti od korisnika da tačno i iscrpno definiše kako bi želeo da nova aplikacija radi kroz dveili više godina, znači tražiti previše. Nešto slično se može reci i za dizajn interfejsa takveaplikacije. Svi koji rade na razvoju softvera mogu reći da specifikacije u velikoj mogumoguodstupati od izvršne verzije softverskog sistema, ukoliko je vreme planiranja i suviše veliko.Treba shvatiti da dugo vreme planiranje nije osnovni uzrok problema, to je samo posledica.U suštini, vreme planiranje je pokazatelj složenosti sistema. Razlog za neuspeh integracijene leži u promenljivim zahtevima tokom faze planiranja. Čak i bez toga, izvan naših ljudskihmogucnosti je da precizno i u potpunosti skiciramo složeni sistem sa milion linija koda.

Agilna metoda, za razliku od modela vodopada, prihvata ograničenu sposobnost ljudi dakompleksan sistem i njegovu interakciju sa okruženjem mogu unapred da zamisle. Agilnostkontinuirano korisnicima i zainteresovanim stranama isporučuje radne verzije softvera uzporuku: " Ovo nije baš kako mi to želimo!". Kratak rok isporuke i povratni ciklusi omogućavajuda se prikupe pravi korisnički zahtevi.


Ideja o agilnom razvoju softvera se zadržala duže nego što se mislilo. Posle teorijskihistraživanja od strane Valther Shevhart i V. Edvards Deming, 1930-ih i 1940-ih, 1950-tihje NASA počela da koristi iterativan model razvoja u pojedinim projektima.Od 1970 panadalje , inkrementalne i iterativne metode , su postale interesantne i među softverskimprofesionalcima. Ironično , čak i pronalazač koncepta vodopada, Vinston Rojs, se snažnozalagao za iterativni pristup u određenim vrstama projekata.

Prednosti i nedostaci agilnih metodologija

Cilj• Objasniti prednosti i nedostatke agilnih metodologija

Prednosti i nedostaci agilnih metodologijaNajpoznatija karakteristika agilnosti je njegov iterativan, vremenski pristup . Softver se razvijau ciklusima fiksne dužine, dugačkim najčešce dve ili tri nedelje. Važi gvozdeno pravilo dase iteracija ne sme produžavati. Ukoliko iteracija ne može da se završi u tom roku, ona seponovo razmatra u narednom ciklusu. Cilj jedne iteracije je uvek potpuno " gotova" funkcija. Urazvoju, to podrazumeva deo softvera koji je u potpunosti testiran i može biti isporučen .

Ovakav iterativni pristup, s jedne strane, pomaže u oblikovanju zahteva korisnika istejkholdera. Predstavnik kupca (naručioc projekta) je prisutan na svim vecim agilnimsastancima. Kupac nije samo pozvana već i odgovoran za davanje svog doprinos pri svakomplaniranju iteracije. S druge strane, kratki ciklusi su način da se odgovori na ubrzane promeneu poslovnom i tehnološkom okruženju. Ovo omogucava da projekat koji treba da se razije zadve ili tri godine, na ovom putu uhvati korak sa promenama u mnogo kracim vremenskimintervalima.

Agilan način razmišljanja podrazumeva da aplikativni sistem, dizajniran pre godinu ili dve,kada se konačno završi više ne odgovara stvarnim potrebama. Agilan pristup obezbeđujenačin za kontinuirane modifikacije koje su neophodne zbog promena u načinu rada korisnika,reorganizovanja kompanija, ili drugačijeg izgleda portfolija proizvoda i usluga.

Kratki ciklusi razvoja su praceni strogim upravljanjem kvaliteta. Jedan od najpopularnijihpredrasude o agilnim metodama je da " Agilnostoznačava anarhiju." Zapravo, istina jesuprotna. Iako se kod agilnih metodologija naglašava samo-organizovanje timova, tuse primenjuju čvrsti principi. Centralni pojmovi u agilnim projektima su automatizovanotestiranja i kontinuirana integracija. Krajnji cilj je da se dobije softver kojise može razmestitina lokacije korisnika nakon svake iteracije (idealno, ali ne uvek realizovano u praksi, čak itokom iteracije )

Ovaj princip održavanja, koji podrazumeva da je sistema uvek u stanju razmeštanja, možeu nekim slučajevima biti razuman, ali kod kompleksnih funkcija stvaraproblem skaliranja.Teško je složenu funkciju implementirati tako da se ona " uklapi u jednu iteraciju". Složenostse javlja u tri slučaja:

Sistemi je i suviše velika za jedan SCRUM timaFunkcije su same po sebi previše složene da bi se realizovale u jednoj iteracijiIntegracija funkcija u složen sistemu ima za posledicu vršenje intervencija koji se ne uklapajuu iteraciju.

Oba pristupa (vodopada i agilni) mogu imati negativne posledice u pogledu integritetaarhitekture: neprirodno deljenje sistema u prvom slučaju ili beskrajna sukcesija operacija


refaktorisanja u drugom . Agilna metodologija ne zahteva obavezno planiranje arhitekturekako bi se postigla ravnoteža između dugoročnih razmatranja i brzog dolaska do rešenja.To je deo varljivog odnosa između agilnih metoda i arhitekture, o kojoj će kasnije biti višereči. Drugi aspekt je da su osnovni koncepti agilnih tehnika cross- funkcionalni , samo-organizovani timovi . Tim preuzima zajedničku odgovornost za isporuku proizvoda . Svaki člantima mora da ispuni svoju odgovornost na end-to-end način.

Istina je, kao što znamo iz sopstvenog iskustva , da je u agilnim metodama lakše " zaboraviti"na dokumentaciju nego u metodama vodopada , gde je pisani dokument obavezan korakprocesa. U agilnom projektu se eksplicitno mora voditi računa da se obezbedi odgovarajucadokumentacija, na primer, kao deo korisničke priče o zadovoljstvu sistemom. Uz određeninapor, u agilnim projektima se može proizvesti odlična dokumentacija, za razliku od loševođenjenih projekata vodopada u kojima se može proizvesti na stotine stranica nebitnihgluposti.

Ukratko, vrednosti agilnog principa su u tome što u centar pažnje dovode kupca, profesionalniintegritet i osecaj pripadnosti radnom timu. On zahteva visok stepen poverenja i odgovornostimeđu svim članovima tima i stejkholdera. Nije dovoljno da se agilna metoda " uradi ";organizacija mora u izvesnoj meri " biti " agilna da u potpunosti sprovede ovu metodologijuida od nje ima koristi.

Da li između agilnosti i arhitekture postoji antagonizam?

Cilj• Sagledati mogućnost primene agilnog pristupa na arhitekturu preduzeća

Da li između agilnosti i arhitekture postoji antagonizam?Cilj ovog objekta znanja je detaljnije sagledatida li agilnost i arhitektura mogu ići zajednotj. da li se one međusobno uklapaju? Jedan od principa u Agilnom manifestu glasi: "Najboljearhitekture (...) i projekti proizilaze iz samoorganizujucih timova".

Da li ima smisla primenjivati nešto na EA što zapravo eliminiše arhitekturalno planiranje? Usvakom slučaju, neki autori podržavaju primenu arhitekturalne praksu u Agilnim projekimašto se u najboljem slučaju može nazvati nevažnim a u najgorem slučaju neodrživim. Agilnemetode izražavaju puno nepoverenja prema tradicionalnoj arhitekturalnoj paradigmi. Pomišljenju nekih naučnika, u istorijskom razvoju softverske arhitekture ima dosta ekcesa kojisu delimično podstaknuti Agilnim metodama. Prataćenje agilnih koncepata dizajniranja značipojednostavljenje arhitekturu do tačke nepostojanja: arhitektura se može isporučivati kao API[interfejse za programiranje aplikacija] i programski kod a ne kao dokumentacija u kojoj sedupliraju informacije. Takva definicija arhitekture može da važi za male timove i jednostavneaplikacije, ali se ne uklapa u vece i kompleksnije sisteme.

Kada analiziramo vezu između agilnih metoda i arhitekture kao koncept, treba takođeproveriti i ulogu arhitekte kao osobe u agilnom svetu. Status ove uloge je, na prvi pogled ,malo nejasan. Agilne tehnike stavljaju naglasak na ovlašcen tim i zajednički duh da se stvariurade. Dakle, na arhitekte se često gleda kao na notornog stanovnika kule od slonovače .

Arhitekta preduzeca, s druge strane, ima period planiranja od nekoliko godina (umesto samodve naredne iteracije) i obavlja visoko specijalizovane zadatke koji su veoma daleko odprojektovanja i kodiranja krajnjeg proizvoda. To ga čini pravim strancem u agilnom svetu.


Agilni arhitekta zbog toga mora biti visoko adaptivan – odgovoran za dizajn ali istovremenosvetstan da prave odluke donosi čitav tim.

LEAN razvoj softvera

Cilj• Objasniti principe na kojima se zasniva LEAN način razvoja softvera

LEAN razvoj softveraLean paradigma potiče od Toyota proizvodnog sistema . Na kraju 1940, kompanija se suočilasa izazovom da proizvede jeftine automobile spremne za posleratno društvo. Tada kao opcijajoš uvek nije postajao masovni izvoz (Toyota je ušla na američko tržište tek 1957. godine ,deset godina kasnije), a proizvodne količine su bile veoma male. Ekonomija obima (koju jeFord postigao svojim visoko sinhronizovanim proizvodnim sistemom, inspirisanim Tailor-om)nije bila u potpunosti dostupna Toyote-i.

Dakle, Toyota proizvodni sistem, je bio fokusiran na optimizaciju efikasnosti proizvodnjestalnim eliminisanjem" otpada " - nepotrebnih ili čak štetnih korake u procesima dizajna iproizvodnje.

LEAN razvoj softvera se bazira na sedam principa:1. Eliminisanje otpada2. Izgradnja kvaliteta3. Kreiranje znanja4. Odlaganje donošenja konačne odluke5. Brza isporuka6. Respektovanjei ljudi7. Optimizacija celine

Princip 1: eliminisanje otpada

Jednostavan (LAEN) način razmišljanja počinje sa definicijom vrednosti koja se stvaraprocesom koji se razmatra, bez obzira da li se radi o industrijskoj proizvodnji, razvoju softveraili kreiranju arhitekture. Vrednost se definiše sa tačke gledišta kupca. Arhitektura preduzecase može posmatrati kao proizvod ; iz te perspektive, vrednost EA leži u artifektima i uslugamakoje je kreirala EA grupa u interakciji sadrugim igračima u preduzecu. O ovim artifektima je bilo reči u materijalu u kojima se govori oosnovnim aktivnostima EA.

Na osnovu ovakve definicije vrednosti, svi koraci u procesu stvaranja proizvoda se mogupodeliti u dve kategorije: procesi kojima se dodaje vrednost i ne dodaje vrednost. U idealnomLEAN okruženju, treba da postoje samo koraci kojima sedodaje vrednost i u tom slučajuefikasnost je 100% . Realno ostvarljiva efikasnost je mnogo manja od toga. Svi koraci kojimase ne dodajevrednost se mogu smatrati otpadom. Eliminisanje otpada pretstavlja osnovniprincip LEAN načina razmišljanja.

Poppendieck i Poppendieck (2003, 2007) su sedam vrsti otpada koje je originalno opisaoOhno (1988) adaptirali softverskom svetu i svaki od tipova otpada prilagodili softverskimprojektima. U tabeli 1. je navedeno tumačenje otpada i za slučaj razvoja EA.


Tabela 1.

Princip 2: Izgradnja kvaliteta

Izjavom oizgradnji kvaliteta se iskazuje stavkoji je u agilnim metodama izražen stalnomkontrolom kvaliteta. Ono što je zajedničko za oba pristupa je da kvalitet nije naknadno dodat,kao posebna faza osiguranja kvaliteta na kraju projekta (sa svim svojim neželjenim sporednihefektima), već je kvalitet osiguranna dnevnoj bazi, kao deo kreiranja softvera.

Princip 3 : Kreiranje znanja

Princip kreiranje znanja opisuje izgradnju i čuvanje znanja o složenim procesima stvaranjasoftvera i o domenu za koji je softver dizajniran . Pojednostavljen (LEAN) način razmišljanjepodrazumeva stalno pracenje i fino podešavanje procesa proizvodnje. Greške se smatrajunormalnim delom ovog pristupa i vide se kao prilika da se neštonauči.

U LEAN načinu razmišljanje popularni mit o“ trenutnom rešavanju stvari“ se smatrakontraproduktivnim, jer on imaju tendenciju da stvori nekreativanu atmosferu bez rizika.Umesto toga , LEAN razmišljanje pokušava da stvori okruženje koje, ako je potrebno,omogucava niz malih odluka koje se mogu lako verifikovanih i ponovo korigovati uz maletroškove.Princip 4 : Odlaganje donošenja konačne odluke

Ovaj princip znači da se odluke donose što je kasnije moguce, kako bi što duže postajaleopcije koje su otvorene za promene. Sličan princip postoji i u agilnom načinu razmišljanja gdeje svaka promena dobrodošla. Izbegavanjem da se projektni tim opredeli za jednu od nekolikomogucnosti za projektovanje rešenja, proces projektovanja se čini jednostavnijim .Princip podrazumeva korišćenje apstrakcije kao načina da se kasnije na što lakši način prećesa jednog na drugo arhitekturalno rešenje. Efekat koji semože vrednovati kako najvažniji upraksi je da arhitekta, odlagnjem rešenja do zadnjeg mogućeg momenta, ima više vremenada se upozna sa problemom i da radi sa manje neizvesnosti.

Princip 5 : Brza isporuka

Principom brze isporuke se izražava visoka vrednost brzog davanja odgovora na promenjenezahteve kupaca u LEAN načinu razmišljanja. S jedne strane, sposobnost brzog davanjaodgovora je rezultat fleksibilnosti koja je nastala primenom LEAN principa; lakše procesje lakše postaviti od težih i oni ce time stvoriti brže resultate. S druge strane, ovaj principukazuje da pojednostavljen (lean) način razmišljanja na brzinu gleda kao na vrednost samu zasebe. Brze promene su prisutne ne se samo u IT-u, već takođe i van IT-a, u domenu kupca, a isituacije su podložne brzim promenama.


IT odeljenje ili dobavljač koji je u stanju da brzo reaguju na nove ulaze jednostavno ostvarujebolju vrednost. Brzina se, pre svega odnosi na brzo donošenje odluka i ne sme da bude ukonfliktu sa kvalitetom; (vidi Princip 2 : Izgradnja kvaliteta). Kada se govori o vrednosti, brzaisporuka može takođe da zvuči kontradiktorno ( vidi Princip 4 : Odlaganje donošenja konačneodluke). Međutim, to nije tačno. Odlaganje donošenja konačne odluke jednostavno znači daodluku treba doneti što je moguće kasnije (kako bi sve opcije bile otvorene ) ali ne tako kasnoda to može ugrožavati davanje brzog odgovora na zahteve kupaca.

Važno sredstvo u postizanju brze isporuke je kreiranje kontinuiranog toka u proizvodnomprocesu , obično u kombinaciji sa definicijom“takt“ vremena. Nemački reč “takt“ se ukontekstu LEAN načina razmišljanja koristi kao pozajmljena reč, što znači vremenski ciklus.Svaka operacija treba da se odvija u istom ritmu, čine se garantuje stalan tok proizvodnje bezotpada zbog čekanja ili odlaganja .

Još jedan ključni koncept za brze isporuke je “pull” princip. U proizvodnji, “pull” princippodrzumeva proizvodnju dobara samo po zahtevu kupaca, koji se inicira kreiranjemporudžbenice. Suprotan koncept je “push“ proizvodnja dobara koja se zasniva na predviđanjubudućih zahteva, na osnovu kojih se vrši proces proizvodnje u nadi da će proizvodi bitidostupni u dovoljnim količinama i kada potreba za njima raste.

“Pull” princip podrazumeva kratke rokove i obradu narudžbenica u malim količinama. “Push“princip, s druge strane podrazumeva veliku serijsku proizvodnju i dugo vreme skladištenja.Nije čudo da proizvodnja bazirana na LEAN principima preferira“pull” nad “push“ principima.Princip 6 : Poštovanje ljudi

Ovaj princip se bavi ljudskim aspektima u kreiranju softvera. Osnovna ideja je da seodluke donose ljudi koji suza to najbolje kvalifikovani. U agilnom svetu ovaj princip jeoznačen „jačanje tima“ ( Poppendieck i Poppendieck , 2003 ). On je veoma sličan sa agilnimshvatanjem tima kao primarnog organa odlučivanja kada je u pitanju operativni aspektrazvoja softvera . LEAN organizacije se karakterišu jakim preduzetničkim rukovodstvom(usmerenim kaizgradnji timova), negovanjem tehničke ekspertize i kratkim kanalimaodlučivanja.Drugi aspekt ovog principa – koji je takođe paralelan sa agilnim tehnikama - jeapresijacija stabilnih timova, gde se znanje može unapređivati tokom dužeg vremenskogperioda. Organizacija koja sama sebi može da daje ovlašćenja je i idealna sredina u kojoj sesprovodi Princip 3 : Kreiranje znanja.

Princip 7 : Optimizacija celine

Optimizacija celine naglašava holistički pristup u LEAN razvoju. Ljudi prilikom donošenjaodluka,treba da pred sobom imaju "potpunu sliku" umesto da razmatraju samo deo - svojprivatni “silos“ ( tima, odeljenje, opis posla, podsistem, aplikacije, itd). Kršenje ovog principadovodi samo do lokalno optimizovanih rešenja, tj. do donekle optimizovanih rešenja.

U razvoju softvera, optimizovati celinu prvenstveno znači razmotri kompletan lanac vrednosti,od prikupljanja zahteva do pokretanja (izvršenja) razvijenog softvera. Ovo zahteva da svakoko učestvuje u procesu kreiranja softvera ne bude usko specijalizovan. Način razmišljanja kojise odvija na način:ja sam arhitekta, ukoliko proizvodim kvalitetnu projektnu dokumentaciju, ja dobro radim svojposao, i mogu biti vrednovan na osnovu broja karakteristika koje dizajniram, nije LEAN načinrazmišljanja.

Kaban softver


Cilj• Objasniti principe na kojima se zasniva Kaban razvoj softvera

Kaban softverKanban softver je izveden na osnovu principa koji se koristi pri izvršenju zadataka (workflow-a) u proizvodnji baziranoj na LEAN principima. Njegov centralni element je Kanban tabla ( vidiprimer na slici “Primer Kaban softverske table” ). Razvojni zadaci se odvijaju na način kojije prikazan na slici, preko “karticazadataka” sa leva na desno. Kad god se promeni statuszadatka -za primer, implementacija je završena- odgovarajuci kartica se pomera za jednuceliju udesno .

U Kanban-u su iteracije opcione. Umesto na iteracije, sistem se fokusira na sprovođenje“pull” principa. Svaka celija (osim Backlog i Live u našem primeru) ima limitiran broj zadatakakoji su u postupku (work in progress - WIP), to je maksimalan broj zadataka koji mogu da sesmeste u jedni celiju. Kada se taj limit postigne, ni jedna kartica zadataka se više ne možepremestiti u tu ćeliju. Na primer, ako je limit za tekuce (ongoing) razvojne zadatke tri, aSCRUM tim vec radi na tri zadatka, ne može se prihvatiti ni jedan novi zadatak. Tim prvomora da završiti najmanje jedan od tekucih zadataka. Ovo pomaže da se izbegne “otpad“ uprocesu skladištenja i kašnjenje. Tim može lako prosuditi kada je potrebno da pređe na novezadatke tako što će njihove celije povući sa leva na desno na tabli . Ovo efektivno promoviše„pull”koncept.

Slika: Primer Kaban softverske tablePrilikom primene Kanban na EA, umesto zadataka u postupku(work in progress - WIP),koristićemo termin dizajn u toku (design in progress - DIP), koji opisuje maksimalan brojzadataka dizajniranja na kojima se trenutno radi.


Kako eliminisanjem otpada unaprediti proces izgradnjearhitekture

Cilj• Objasniti kako se eliminisanjem otpada može unaprediti proces izgradnje arhitekture

Kako eliminisanjem otpada unaprediti proces izgradnje arhitektureLEAN metodologija po poreklu predstavlja optimizaciju framework-a (okvira) za proizvodnesisteme. Može se primeniti na dva načina. Kroz:• Optimizaciju toka izvršenja procesa.Svi koraci koji se izvršavaju u okviru jednog procesa

primenom „pushed“ pristupa ( kada se proizvodnja bazira na prognozi umesto nazahtevima) se analiziraju i redizajniraju tako da se baziraju na „pull“ pristupu.

• Uklanjanje otpada . Identifikacija i eliminacija štetnih koraka (otpada) u procesuproizvodnje .

Vratimo se ponovo našem primeru Bank4US. Padma Valluri je arhitekta preduzeca i kolegaIan Milera, koji je u program racionalizacije aplikacija doveden kao pojačanje. Padaminzadatak je da u EAgrupi bude odgovoran za optimizaciju IT-a i procesa izgradnje arhitekture ubanci .Padma je mnogo puta razgovarao sa Ian i drugim arhitektama iz EA tima o efikasnostinjihovog IT-a i EA organizacije. Kao iskusni arhitekta preduzeca, Padma zna da EA , nudidovoljno mogucnosti za otkrivanje otpada .Padma je odlučan da smanji obim procesa i kontrole do nivoa koji je potreban da se EA grupaoslobodi mnogobrojnih operativnih aktivnosti i tako ne uguši njihova kreativnost. Da bi sepostigao ovaj cilj , on treba da da predloge za otklanjanje nepotrebnih ili čak štetnih korakau projektovanju, implementaciji, testiranju i upravljanju, kako bi se obezbedio pragmatičanfokus na zaista kreativne aktivnosti .

Sedam vrsti otpada u EA

Cilj• Objasniti vrste otpada u EA

Sedam vrsti otpada u EAU ovom objektu znanja se detaljno navodi šta znači svaka od vrsti otpada definisanih u LEANmetodologiji, u smislu EA. U drugom koraku, u objektu znanja koji govori o "analizi tokavrednosti u okviru EA " proverićemo da li su eliminisano svi koraci u okviru procesa koji nedonose nikakvu vrednost, a koje trebaeliminisati kao otpad .

Otpad se u EA procesima može svrstati u sledece kategorije :• Delimično urađeno posao . Informacije nisu dostupne i artefakti koji se dobijau kao izlaz iz

EA nisu završeni; gomilaju se u poluzavršenom stanju.• Arhitektura je urađena sa suviše detalja. Rešavaju se pogrešni arhitekturalni problemi, a

oni pravi su zataškani sa previše detalja.• Redudantni procesi . U suštini, rade se prave stvari, ali sa previše napora; neadekvatni,

nepotrebni ili duplicirani procesi čine ukupan proces neefikasnim


• Problemi u interakciji. Javljaju se u interakciji između različitih aktera u EA procesima , utrenutkuprimopredaje zadatka ili zbog problema u komunikaciji .

• Prebacivanje s jednog na drugi posao. Arhitekte preduzeća i drugi učesnici u EA procesu,gube vreme i energiju zbog istovremenog rada na više zadataka.

• Kašnjenja. Ljudi čekaju na potrebne informacije, povratne informacije, ili odobrenja .• Greške. EA strategija, modeli i dokumentacija sadrže nedostatke; ili učesnici u

EAprocesima se nepravilno ponašaju.

Delimično urađeno posao

Delimično urađen posao znači da EA artifekti - specifikacije, modeli, dokumentacija - nisuzavršeni i zatvoreni, već su ostavljeni u poluzavršenom stanju, nagomilani za kasnijuupotrebu .

U Tabela 1.je navedeno tumačenje ovog tipa otpada u proizvodnji , razvoju softvera isoftverskoj arhitekturi uopšte. Kao se može videti, otpada zbog delimično urađenog posla ječesto povezana sa situacijama kada se posao ne radi dovoljno odlučno. To može biti rezultatnedovoljno osposobljenih ili nekompletiranih EA grupa.

Arhitektura je urađena sa suviše detalja

Kao što je navedeno, vrste otpada Delimično urađen posao i Arhitektura urađena sa suvišedetalja su u izvesnoj meri dve strane istog novčica .

Sa aspekta EA, to znači da arhitekta preduzece obavlja aktivnosti i proizvodi dokumentacijukoja nikome ne treba. Ili, ako EA ispunjava zahteve, nivo detaljnosti dokumentacije je takavda je niko neće čitati. Slanje svih vrsta informacije svima ( tj. ,primena push umesto pullprincipa prilikom slanja informacija ) je takođe jedan primer ovog otpada . U suštini, EA timainvestira svoj napor u pogrešne aktivnosti i inicijative. Tabela 2. navodi primere ovog tipaotpada .


Redudantni procesi

Otpad zbog viška(redudantnih) procesa znači da, iako je posao na izradi arhitektureodgovarajuce fokusiran, u njega se ulaže previše truda . Kao što je u Tabeli 3. navedeno, ovavrsta otpada može da se manifestuje kroz preveliku birokratiju ili uopšte kao neefikasna EA iliIT organizacija.

Problemi u interakciji

Komunikacija ( ili nedostatak komunikacije ) između aktera u procesu izgradnje EA je takođepotencijalni izvor otpada. Ako se dijalog između arhitekata preduzeca, poslovnih menadžera,upravnih odbora, IT menadžmenta, IT razvojnih timova, kao i partnera za implementacijuprekine, EA proces se nece ispravno odvijati. Tabela 4. navodi nekoliko primera tipa otpadazbog problema u komunikaciji.

Ova vrsta otpad se takođe može javiti ako se u organizaciji arhitekture preduzeća dajepreviše odgovornosti partnerima. Uopšte, partnerstvo i outsourcing mogu imati kritičnaneželjena dejstva. U jednom od naših projekata , operater mobilne mreže je outsource-ovaosvoju mrežu . Kao posledica toga, on je imao problem sa pristupom ključnim podacima ogreškama koji se dešavali na mrežni, a koji su operatoru potrebni za unapređenje planiranja.


Prebacivanje s jednog na drugi posao

Ljudski mozak je po svojoj prirodi pogodan za paralelno procesiranje. Međutim,preopterecenost informacijama i preveliki broja istovremenih aktivnosti ima štetan naorganizacionu efektivnost. Arhitekte preduzeća nisu izuzeci od ovog pravila . Tabela 5. navodimnogo primera u kojima arhitekta može biti preopterecen mnoštvom paralelnih zadataka usvom svakodnevnom radu

Kašnjenje

Za razliku od proizvodnje, proizvodiprocesa informacionog dizajna - specifikacije, koncepti,modeli - su skoro uvek kvarljiva roba. Oni gube vrednost kada se predugo čuvaju. Dakle, uEA su kašnjenja uvek štetna. Nažalost, oni su takođe veoma čest primer otpada. Svi akteriu procesu EA (sa izuzetkom samih arhitekatapreduzeca) imaju druge prioritete u odnosuna stvaranje EA. Pored toga, stejkholderi uglavnom pripadaju redovima srednjeg i višegmenadžmenta, čiji su rasporedi uvek prenatrpani.

Tabela 6. navodi neke primere ove vrste otpada, kao što su čekanje na sastanke, informacije,povratne informacija ili odobrenja .

Defekti


U LEAN načinu razmišljanja, defekti se u celini smatraju otpadom. Izgradnja kvaliteta uprincipu zahteva da se proizvodni procesi mogu podesiti tako da nema dfekata. ZagovorniciLEAN razvoja softvera čak idu toliko daleko da tvrde da ako se greške otkriju u konačnomtestiranju, to znači da nešto nije u redu. Arhitekta teško može spovesti ovaj princip. U celini,defektii u arhitekturi, kao što je navedeno u tabeli 7, obuhvataju sve vrste pogrešno vođenogdizajna, od običnog nerazumevanja poslovnih zahteva da nekih sofisticiranijih nedostataka.

Alati za analizu vrednosti u EA ( Matrica EA otpada)

Cilj• Objasniti svrhu i način korišćenja matrice EA otpada

Alati za analizu vrednosti u EA ( Matrica EA otpada)Matrica EA otpada prikazuje sav potencijalni otpad u arhitekturi preduzeća. Ona kombinujesadržaje tabela svih vrsti otpada, s tim što je njoj svaka vrsta otpada razvrstana po EAaktivnosti (EA-1 do EA-8). Stvaranje Matrice EA otpada je prvi korak na putu ka LEAN i agilnojEA . Padma Valluri, arhitekta preduzeca Bank4Us, čija je misija čišcenje EA procesa odbirokratskog balasta, raspolaže malim budžetom. Ona je odlučila da kontaktira Sandro Pođi,stručnjaka za LEAN i agilnu arhitekturu. Padma je radio sa Sandro u ranijim projektima i znada je on prava osoba da podrži njegove napore.

Na osnovu Sandrovog saveta , Padma organizuje radionicu kako bi zajednički sastavilimatricu EA otpada. Vecina njegovih kolega koji učestvuju u EA timu imaju dovoljno vreme daučestvuju u radionici. Da bi dobio i spoljašnji pogled na rad EA tima, Padma uključuje i ključneIT predstavnike kao i pretstavnike iz biznisa sa kojima su arhitekte preduzeca najviše uinterakciji. Pored toga , postoji obostrani osecaj da interakcija između pretstavnika biznisa, IT-a i EA tima može da se poboljša. Zbog toga su i mnogi stejkholderi uključeni u rad radionice.

Za potrebe sastanka, Sandro je na velikom listu papira sastavio matricu prikazanu u tabeli1, u kojoj su na početku sve ćelije bile prazne, koju je zakačio na zid sobe u kojoj se održavasastanak. Nakon kratkog uvoda u LEAN koncepta i značenje sedam tipova otpada, on je odsvakog učesnika radionic tražio da u matricu unesu svoje lične ideje za uklanjanje otpada.One su obeležene sa +(što znači da postoji visok potencijal za uklanjanje otpada) ili sa *(štooznačava srednji potencijal za uklanjanje otpada). Nakon toga, cela grupa je zajedničkipregledala zabeležene predloge, u čemu je Sandro imao ulogu moderatora.

Ishod rada radionice je popunjena matrica, prikazana u Tabeli 1. Na osnovu tabele se činise da EA - 3 (razvoj IT šeme ) i EA - 5 ( Razvoj i primena standarda i smernice ) nude najvecipotencijal za uklanjanje otpada


Posle krace diskusije sa svojim saradicima i Sandrom, Padma bira jedan, donekleneprihvaćeni projekat iz EA -5, koji se vodi pod imenom MobileDevGuide. Ovo istraživanjemobilnih tehnologija i platformi, usmereno na kreiranje tehnologija i razvoj smernica zakorišćenje mobilnih aplikacija na nivoucelog preduzeca Bank4Us, je za EA tim bilo dostaproblematično. Projekat je trajao mnogo duže od predviđenog završetka i niko od aktera nijebio zadovoljan rezultatom. Padma je razmišljao da ako LEAN i agilan EA pristup otkriva kakose ovaj projekat može bolje odvijati, trebalo bi ga poboljšati primenom ovakvog pristupa .

Tok vrednosti u EA

Cilj• Objasniti šta znači analiza toka vrednosti u EA

Tok vrednosti u EAUklanjanje otpada je, u LEAN metodologiji, neraskidivo vezano sa analizom nastankavrednosti. Drugim rečima, treba analizirati tok EA vrednosti. Prvi korak u analizi tokavrednosti je definicija pojma vrednosti. Svaki korak u proces ili dodaje ili ne dodajevrednost. U masovnoj proizvodnji , korak dodaje vrednost ukoliko direktno doprinosi procesuproizvodnje.

Cilj optimizacije toka vrednosti je da se eliminišu NVA i minimiziraju R - NVA koraci u okviruprocesa.

• NVA Nonvalue-adding(Koraci kojima se ne dodaje vrednost): Koraci koji nisu potrebniuokviru procesa i kojima se ne dodaje vrednost.

• R - NVA Required but nonvalue-adding (Koraci koji su potrebni ali se njima ne dodajevrednost): nema direktnog doprinosa vrednosti , ali je korak potrebno zbog tehničkeprirode proizvodnog procesa, na primer koordinacija sastanka.


• VA Value-adding (Koraci kojima se vrši dodavanje- vrednosti )- direktno doprinose ishoduprocesa.

Šta su koraci kojima se dodaje vrednost u smislu EA ? Ne postoji opšti odgovor na ovopitanje . Stvaranje dokumenatai modelaarhitekture mogu pretstavljati ili ne pretstavljatikorake kojima se dodaje vrednost, u zavisnosti od toga da li za njima postoji prava potreba( za razliku od dokumenata koji se proizvode , ali se nikada ne čitaju ) .Isto važi i za definisanje procesaarhitekture i stvaranje arhitekturalnih pogleda.Komunikacija ,učenje ili mere za poboljšanje zadovoljstva zaposlenih obično nisu direktnokoraci kojima se dodaje vrednost i oni mogu pasti bilo u R- NVA ili NVA kategoriju.

Padma i Sandro su razmišljali kako mogu analizirati tok vrednosti za projekatMobileDevGuide. Sandro je ukazao da početnaanaliza toka vrednost u EA treba da se obavikao grupna vežba. Pri tom, u proces moraju da budu uključeni svi glavni stejkholderi. Padmaje razmotriosve aktere, uzvodno i nizvodno, predstavnike iz poslovnihlinija koji su postavilisvoje zahteve za projekat MobileDevGuide ali i smernice menadžera projekata i arhitekata izIT odeljenja. Proces može uključivatičak i implementacione partnere iz različitih kompanija.

U toku vođenja radionice za analizu toka vrednosti, Sandro je planirao da koristi procesmapiranja aktivnosti, dizajn strukturne matrice i pipeline response matrix alat. Ovde će bitireči o dizajun strukturne matrice

Dizaj strukturne matrice (Design Structure Matrix - DSM)

Cilj• Objasniti ulogu Strukturne matrice (Design Structure Matrix - DSM)

Dizaj strukturne matrice (Design Structure Matrix - DSM)Prilikom dizajna strukturne matrice (DSM ) se koristi vrlo jednostavan tabelarni format, kojimse posebno ističu procesi iteracije i prerade. Slika „DSM za MobileDevGuide u BankUs4“prikazuje DSM tabelu koju su kreirali učesnici radionice.

Slika: DSM za MobileDevGuide u BankUs4

Ako korak K obezbeđuje ulaz za korak N, presek kolone K i vrste N je označen sa x. Svepopunjene ćelije tabele iznad linije dijagonale (linija dijagonale označena sa #) u gornjojpolovini matrice pretstavljaju tok napretka – korake obrade u procesu proizvodnje proizvoda.Oni nisu problematični. Popunjene ćelije ispod linije dijagonale označavaju iteracije i povratne


procese. One su indikatori otpada zbog redudantnih procesa i arhitekture urađene sa suvišedetalja.

Nije iznenađujuce da su pogrešni koraci u MobileDevGuide projektu koraci 2 , 4 , 6 , i 8 –koraci razmatranja i usvajanja ( i njihove iteracije ) koji pretstavljaju potencijalne elemente zaprepravke u projektu. Da je karta aktivnosti proces bila složenija, to bi se možda i previdelo,ali je to u DSM-upotpuno vidljivo.

LEAN i agilni razvoj softvera; Unapredjenjeizgradnje EAeliminisanjem otpada

ZaključakKao što smo videli na primeru Bank4Us, eliminisanje otpada u procesu unapređenjaarhitekture je dobra polazna tačka za analizu EA procesa. Ova vrsta LEAN optimizacijenajbolje funkcioniše ako postoje procesi koji se mogu optimizovati. Na slici “: Eliminisanjeotpada u cilju unapređenja procesa arhitekture” su istaknute dimenyije, gde LEAN pristupmože biti od pomoci.Slika: Eliminisanje otpada u cilju unapređenja procesa arhitektureUzimajući EA tabelu, o kojoj je već bilo reči, kao osnovu, vidimo da se LEAN koncepti moguprimeniti na dimenzije Upravljanje i Transformacija. Uklanjanje otpada može biti dobarrecept za prevazilaženje i suviše čvrstog (to rigid) načina upravljanje ili stimulator za EAorganizaciju koja je zagušena i preopterecenja sopstvenom neefikasnošću. Suviše jak i čvrstnačin upravljanja se može dovesti na pravu meru uklanjanjem otpada. Situacija suviše slabog(to week) načina upravljanja - može biti slična, ali u tom slučaju se može zahtevati i dodatnopojačanje EA – tima, što LEAN pristup ne obezbeđuje.Situacija sa dimenzijom transformacijeje obrnuta. Može se pretpostaviti da se i suviše spora brzina transformacije može povećatiistovarom otpada. Kod druge vrste krajnjosti (suviše brza transformacija), uklanjanje otpadamože ili i ne mora pomoci. Efekti u dimenzijama Perspektiva i Strategije su isuviše indirektnida bi se ovde mogli razmatrati.

is250 arhitekturaitsistemaorganizacije is250 arhitekturaitsistemaorganizacije l13 1

Documents