Standartinis programinės įrangos kūrimo vertės srauto atvaizdavimas prasideda nuo kodavimo ir baigiasi kodu gaminant. Dažnai matote diagramas, kurios prasideda „verslas“ ir baigiasi „klientas“. Tačiau šis vaizdavimas tiksliai neatspindi programinės įrangos pristatymo įmonės mastu sudėtingumo.
Žengdamas žingsnį atgal, matai daug daugiau veiklų, susijusių su programinės įrangos tiekimu klientams, tačiau dabartinis požiūris į šios veiklos valdymą yra pagrįstas paslaugų teikimo sistemomis, o ne gamybos modeliais. Taigi jie nesieja visos susijusios veiklos kaip vienos nuo galo iki galo sistemos.
Kitose produktų pramonės šakose naudojamas modelis yra tiekimo grandinės modelis, ir pritaikę tą modelį programinės įrangos pristatymui, galite išplėsti supratimą apie programinės įrangos pristatymo „sistemą“ už „devops“, suteikdami naują supratimą, kaip ją optimizuoti.
Kas yra tiekimo grandinė?
Tiekimo grandinė prasideda nuo idėjos, kad jūs galite koordinuoti visą gamybos ir ne gamybos veiklą kaip vieną sistemą. Tiekimo grandinės valdymas dažnai neteisingai suprantamas kaip tiesiog „tiekėjų valdymas“, nors iš tikrųjų tai yra tik vienas tiekimo grandinės valdymo aspektas (nors ir kritinis).
Visų produktų ir paslaugų įmonės turi tiekimo grandinę, o vykdoma veikla ir jų santykinė svarba tiekimo grandinės sistemai skirsis. Tačiau pagrindinė mintis yra ta, kad koordinuodami šias veiklas kaip vieną sistemą, jūs gaunate didesnę vertę nei dalių suma ir efektyviai tiekiate šią vertę suinteresuotiesiems subjektams.
Ši veikla yra tik keli svarbūs visų tiekimo grandinių aspektai, tačiau programinei įrangai jie vykdomi unikaliai:
Planavimas
Tradicinėje tiekimo grandinėje planavimo veikla apima turto koordinavimą ir procesų srauto optimizavimą, siekiant subalansuoti medžiagų tiekimą ir produktų paklausą. Programinės įrangos tiekimo grandinėje šis koordinavimas reiškia, kad yra sukurtas tinkamas kodas labiausiai reikalingoms produkto savybėms. Dideliu mastu, naudojant šimtus programų ir tūkstančius programinės įrangos kūrėjų, tai yra monumentali pastanga.
Planavimo veiklos mastą dažnai sumažina esami „devops“ modeliai. Todėl šiek tiek ironiška, kad didžiosios įmonės, kurioms labiausiai reikia lėšų, turi kovoti su teisiniais, reguliavimo, sutartiniais ir klientų įsipareigojimais, dėl kurių planavimas yra ilgas ir sudėtingas. Tiekimo grandinės požiūris į planavimą apima daugelio skirtingų planavimo vaidmenų ir susijusių disciplinų sąsajų optimizavimą, o pagrindinis sėkmės faktorius yra gebėjimas jas veiksmingai integruoti.
Viena vertus, judrios metodikos, kuriomis vadovaujamasi plėtrai įmonėje, dažnai yra įtrauktos į krioklio procesus. Nedaug įmonių gali išvengti fiskalinio planavimo ciklų, o judriuose procesuose gali būti abstrakčių, prieštaraujančių tiems ciklams; pavyzdžiui, sprintai gali nesutapti su fiskalinių ketvirčių ribomis. Ryšio ir ryšių tarp vystymosi procesų, naudojant judrią ir neproduktyvią veiklą naudojant krioklį, trūkumas gali sukelti švaistymą ir neveiksmingumą visame versle.
Kita vertus, įmonės produktų planavimas visada apėmė išsamias reikalavimų valdymo ir atsekamumo sistemas, o programinės įrangos produktams tai nesiskiria. Reikalavimų valdymas yra ypač svarbus labai reguliuojamose pramonės šakose, tokiose kaip sveikatos priežiūra, kur gali būti sukurta medicinos prietaisų programinė įranga, kuri gali reikšti gyvybę ar mirtį vartotojams. Reikalavimų valdymas apima specializuotas priemones ir metodikas, o gebėjimas atsekti jų įgyvendinimo patikimumą ir kokybę per visą kūrimo gyvavimo ciklą gali būti labai svarbus įmonės programinės įrangos produktams.
Tiekimas
Tradicinėje tiekimo grandinėje komponentų pirkimas apima santykių su tiekėjais valdymą ir dalių bei medžiagų pirkimo strategijų kūrimą. Programinė įranga taip pat labai priklauso nuo šaltinių - pagal naujausius „Sonatype“ tyrimus, atvirasis šaltinis dabar sudaro daugumą programinės įrangos produktų: net 80–90 proc. Šiuolaikinių programų kodo yra iš atvirojo kodo komponentų. Šie komponentai kelia unikalius valdymo iššūkius.
Pirma, gali būti sunku nuspręsti, kaip nustatyti komponentų kokybę, o daugybė veiksnių, turinčių įtakos sprendimams, pvz., Vartojimo efektyvumas, bandymai, dokumentai, bendruomenė, palaikymas ir technologijų tendencijos. Būtina turėti aiškią strategiją ir požiūrį į komponentų pasirinkimą.
Antra, kaip atviro kodo komponentų balionų skaičius, net žinoti, kas jiems visiems leidžiama, efektyviai valdant juos visus, yra iššūkis. Produktų vadybininkai ir inžinieriai turi skirti daug dėmesio licencijavimo problemoms ir saugumo problemoms spręsti. Atvirojo kodo komponentų būklė gali keistis kasdien, kai nustatoma naujų pažeidžiamumų, o prižiūrėtojai keičia savo intelektinės nuosavybės strategijas. Ir klientai nori tiksliai žinoti, ką gauna - daugelis didelių įmonių nepirks programinės įrangos be prekių sąskaitos, kurioje aprašyta, kas yra dėžutėje. Visų šių atvirojo kodo problemų valdymas yra pagrindinis programinės įrangos produktų kūrimo aspektas.
Paskirstymas
Programinės įrangos patekimas į klientų rankas gali apimti sudėtingą visų rūšių partnerių tinklą: diegimą, platinimą, integravimą, perpardavėją; visų rūšių susitarimai: OEM, licencijos, NDA, RFP; visų rūšių susitikimai: demonstracinės versijos, informacinės programos, pristatymai; ir dar daugiau.
Šie ryšiai yra programinės įrangos pristatymo proceso įvestys, išvestys ir netgi žingsniai. Bet kurio iš šių santykių būklė gali tiesiogiai paveikti plėtros veiklą. Glaudžiai jų nevaldant ir nesusiejant su atliekamu darbu, atsiranda labai apčiuopiamų atliekų.
Įsivaizduokite, kad pristatote epopėją perspektyvai, kuri ramiai tapo prarasta proga, arba pristatote funkciją partneriui, kuris prieš mėnesį atšaukė jų susitarimą. Tai atsitinka reguliariai, kai programinė įranga pristatoma nepriklausomai nuo verslo vertės srauto - kai programinės įrangos pristatymo funkcija nėra susieta su tiekimo grandine.
„Devops“ dujotiekis turi būti glaudžiai susijęs su partnerystėmis, susitarimais ir tikslais, dėl kurių atliekamas darbas. Kodas gali būti atsekamas ir susietas nuo istorijos su reikalavimu iki kliento įrašo jūsų CRM, visa tai traktuojant jūsų programinės įrangos pristatymą kaip tiekimo grandinę ir sekant integracijos strategiją.
Įsivaizduokite, kad galėtumėte pateikti visą vykdomą veiklą, vykdomą pagal konkrečią sutartį, arba visas naujas klientui numatytas funkcijas - tai yra programinės įrangos tiekimo grandinės valdymo rezultatas - matomumą ir atsekamumą per visą gyvenimo ciklą.
Įrankiai
Nors jūsų klasikinius gamybos įrankius gali sudaryti pjovimo staklės ir terminio apdorojimo krosnys, programinės įrangos tiekimo grandinėje yra klasė įrankių (įvairiai vadinamų ALM įrankiais, gyvavimo ciklo įrankiais arba „devops“ įrankiais), kurie naudojami valdyti įvairius programinės įrangos pristatymo etapus. .
Šių įrankių valdymo strategija labai skiriasi nuo klasikinio požiūrio, nes techninės ir intelektinės investicijos į programinės įrangos kūrimo įrankius yra didžiulės ir labai paveikios. Šio tipo įrankiai taip pat greitai tobulėja ir yra labai fragmentiški - šiandieniniai Jenkinai bus praėjusių metų Hudsonas. Organizacija turi būti tokia, kad turėtų tamprų, tačiau modulinį įrankių rinkinį, kuris aprūpina komandas tuo, ko jiems reikia, išlaikant lankstumą prisitaikyti.
Be to, įrankių grandinė negali būti atjungta - ji turi tekėti informacija atgal prieš ir po vertės grandinę, kad gautų žinių ten, kur jos reikia. Labai svarbu išnagrinėti šią sritį ir integracijos požiūriu - kaip galima susieti tam tikro sluoksnio veiklą su supančia ir palaikančia tiekimo grandinės valdymo veikla?
Išvada
Verslas istoriškai atskyrė technologijų valdymą nuo pajamas generuojančių verslo krypčių, traktuodamas tai kaip paramos veiklos rinkinį, kurį lemia vertybės ir tikslai, suderinti su paslaugų teikimu. Tačiau programinės įrangos apibrėžtame pasaulyje tas verslo modelis nebetinka.
Programinės įrangos pristatymo galimybė persikėlė iš klasikiniu būdu apibrėžtos palaikymo vietos ir nustatė visas pagrindines pajamas generuojančias veiklas.
Todėl turite permąstyti savo modelį kaip gamybos sistemą ir pereiti prie tokios, kuri atspindėtų sudėtingumo ryšius visoje vertės srauto veikloje. Tiekimo grandinė įkūnija tą mąstymą, o tobulėjant programinės įrangos produktams, mes tikrai matysime, kad šis modelis yra subrendęs.
