Programmatūras izstrādes vērtību plūsmas standarta attēlojums sākas ar kodēšanu un beidzas ar kodu ražošanā. Jūs bieži redzat devops diagrammas, kas sākas ar “bizness” un beidzas ar “klients”. Tomēr šis attēlojums precīzi neatspoguļo programmatūras piegādes sarežģītību uzņēmuma mērogā.
Spēris soli atpakaļ, jūs redzat daudz vairāk darbību, kas saistītas ar programmatūras piegādi klientiem, taču pašreizējā pieeja šo darbību pārvaldībai sakņojas pakalpojumu sniegšanas ietvarā, nevis ražošanas modeļos. Tādējādi tie nesaista visas iesaistītās darbības kā vienu no gala līdz galam.
Citās produktu nozarēs izmantotais modelis ir piegādes ķēdes modelis, un, piemērojot šo modeli programmatūras piegādei, jūs varat paplašināt izpratni par programmatūras piegādes “sistēmu” ārpus devops, sniedzot jaunu ieskatu par to, kā to optimizēt.
Kāda ir piegādes ķēde?
Piegādes ķēde sākas ar domu, ka jūs varat koordinēt visas ražošanas un ar ražošanu nesaistītās darbības kā vienotu sistēmu. Piegādes ķēdes vadību bieži pārprot kā vienkārši “piegādātāju vadību”, lai gan patiesībā tas ir tikai viens piegādes ķēdes pārvaldības aspekts (kaut arī kritisks).
Visiem produktu un pakalpojumu uzņēmumiem ir piegādes ķēde, un iesaistītās darbības un to relatīvā nozīme piegādes ķēdes sistēmā būs atšķirīga. Tomēr galvenā ideja ir tāda, ka, koordinējot šīs darbības kā vienotu sistēmu, jūs iegūstat vērtību, kas ir lielāka par daļu summu, un plūsmas efektīvu piegādi šai vērtībai ieinteresētajām personām.
Šīs darbības ir tikai daži no svarīgākajiem visu piegādes ķēžu aspektiem, taču programmatūrai tās tiek izpildītas unikāli:
Plānošana
Tradicionālajā piegādes ķēdē plānošanas darbības ietver aktīvu koordinēšanu un procesu plūsmas optimizāciju, lai līdzsvarotu materiālu piedāvājumu ar produktu pieprasījumu. Programmatūras piegādes ķēdē šī koordinācija ietver pārliecību, ka tiek izstrādāts pareizais kods visvairāk vajadzīgajām produkta īpašībām. Lielā mērogā, izmantojot simtiem lietojumprogrammu un tūkstošiem programmatūras izstrādātāju, tas ir monumentāls darbs.
Plānošanas darbību apjomu bieži samazina līdzšinējie devops modeļi. Tāpēc ir nedaudz ironiski, ka lielajiem uzņēmumiem, kuriem visvairāk ir vajadzīgi apbedījumi, jācenšas ievērot juridiskas, normatīvas, līgumiskas un klientu saistības, kas padara plānošanu ilgu un sarežģītu. Piegādes ķēdes pieeja plānošanai ietver daudzu dažādu plānošanas lomu un iesaistīto disciplīnu saskarņu optimizāciju, un galvenais veiksmes faktors ir spēja tās efektīvi integrēt.
No vienas puses, veiklās metodoloģijas, kas virza attīstību uzņēmumā, bieži tiek iekļautas ūdenskrituma procesos. Tikai daži uzņēmumi var izvairīties no fiskālās plānošanas cikliem, un veiklie procesi var saturēt abstrakcijas, kas ir pretrunā ar šiem cikliem; piemēram, sprints var nesaskaņoties ar fiskālo ceturkšņu robežām. Saziņas trūkums un saiknes starp attīstības procesiem, izmantojot veiklas un neproduktīvas darbības, izmantojot ūdenskritumu, var novest pie atkritumiem un neefektivitātes visā biznesā.
No otras puses, uzņēmuma produktu plānošanā vienmēr ir iesaistītas plašas prasību pārvaldības un izsekojamības sistēmas, un programmatūras produktiem tas neatšķiras. Prasību pārvaldība ir īpaši kritiska stingri regulētās nozarēs, piemēram, veselības aprūpē, kur medicīnas ierīcēm var izstrādāt programmatūru, kas lietotājiem var nozīmēt dzīvību vai nāvi. Prasību pārvaldība ietver specializētus rīkus un metodikas, un spēja izsekot to ieviešanas uzticamībai un kvalitātei visā izstrādes dzīves ciklā var būt izšķiroša uzņēmuma programmatūras produktiem.
Sourcing
Tradicionālajā piegādes ķēdē komponentu ieguve ietver attiecību pārvaldīšanu ar piegādātājiem un detaļu un materiālu iepirkuma stratēģiju izstrādi. Programmatūra lielā mērā paļaujas arī uz iegūtajiem komponentiem - saskaņā ar Sonatype jaunākajiem pētījumiem atklātais kods tagad veido lielāko daļu programmatūras produktu: pat 80–90 procenti koda mūsdienu lietojumprogrammās ir no atvērtā pirmkoda komponentiem. Šie komponenti rada unikālas pārvaldības problēmas.
Pirmkārt, var būt grūti izlemt, kā noteikt komponentu kvalitāti, ar daudziem faktoriem, kas ietekmē lēmumus, piemēram, patēriņu, testēšanu, dokumentēšanu, kopienu, atbalstu un tehnoloģiju tendences. Nepieciešama skaidra stratēģija un pieeja komponentu izvēlei.
Otrkārt, tā kā atklātā pirmkoda komponentu balonu skaits ir izaicinājums pat zināt, kas viņiem visiem ļauts, lai tos visus efektīvi pārvaldītu. Produktu vadītājiem un inženieriem liela uzmanība jāpievērš licencēšanas problēmām un drošības jautājumiem. Jūsu atklātā pirmkoda komponentu stāvoklis var mainīties katru dienu, kad tiek atklātas jaunas ievainojamības un uzturētāji maina intelektuālā īpašuma stratēģijas. Un klienti vēlas precīzi zināt, ko viņi saņem - daudzi lieli uzņēmumi neiegādās programmatūru bez preču rēķina, kurā aprakstīts, kas atrodas kastē. Visu šo atvērtā pirmkoda problēmu pārvaldīšana ir programmatūras produktu izstrādes pamataspekts.
Izplatīšana
Programmatūras nonākšana klientu rokās var iesaistīt visu veidu sarežģītu partneru tīmekli: izvietošana, izplatīšana, integrācija, tālākpārdevējs; visa veida līgumi: oriģināliekārtu ražotāji, licences, NDA, RFP; visa veida sanāksmes: demonstrācijas, PoC, prezentācijas; un vēl daudz vairāk.
Šīs attiecības kalpo kā ieejas, izejas un pat soļi programmatūras piegādes procesā. Jebkuras no šīm attiecībām stāvoklis var tieši ietekmēt attīstības darbības. Cieši tos nepārvaldot un nepiesaistot veicamajam darbam, rodas ļoti taustāmi atkritumi.
Iedomājieties, ka jūs piegādājat eposu izredzēm, kas klusām kļuva par zaudētu iespēju, vai izmantojat kādu iespēju partnerim, kurš pirms mēneša atcēla līgumu. Tas notiek regulāri, ja programmatūra tiek piegādāta neatkarīgi no uzņēmuma vērtību plūsmas - ja programmatūras piegādes funkcija nav saistīta ar piegādes ķēdi.
Devops cauruļvadam jābūt cieši saistītam ar partnerībām, līgumiem un mērķiem, kuru labā tiek veikts darbs. Kods var būt izsekojams un saistīts ar stāstu ar prasību un klienta ierakstu jūsu CRM, visu apstrādājot programmatūras piegādi kā piegādes ķēdi un sekojot integrācijas stratēģijai.
Iedomājieties, ka tā vietā spējat atklāt visas nepabeigtās darbības, kas tiek veiktas saskaņā ar konkrētu līgumu, vai visas funkcijas, kas plānotas jaunam klientam - tas ir programmatūras piegādes ķēdes pārvaldības rezultāts - redzamību un izsekojamību visā dzīves ciklā.
Rīki
Lai gan jūsu klasiskās ražošanas instrumenti var sastāvēt no griešanas mašīnām un termiskās apstrādes krāsnīm, programmatūras piegādes ķēdē ietilpst instrumentu klase (dažādi tiek saukti par ALM rīkiem, dzīves cikla rīkiem vai devops rīkiem), kurus izmanto dažādu programmatūras piegādes posmu pārvaldībai .
Šo rīku pārvaldības stratēģija ļoti atšķiras no klasiskās pieejas, jo tehniskie un intelektuālie ieguldījumi programmatūras izstrādes rīkos ir milzīgi un ļoti ietekmīgi. Šāda veida rīki arī ātri attīstās un ir ļoti sadrumstaloti - šodienas Dženkinss būs pagātnes Hadsons. Organizācijai jābūt izvietotai ar elastīgu, tomēr modulāru rīku kaudzi, kas komandām nodrošina nepieciešamo, vienlaikus saglabājot elastību pielāgoties.
Turklāt instrumentu ķēdi nevar atvienot - tai ir jāplūst informācija augšup pa straumi un lejup pa vērtību ķēdi, lai iegūtu zināšanas tur, kur tas nepieciešams. Ir ļoti svarīgi pārbaudīt šo jomu arī no integrācijas viedokļa - kā jūs varat saistīt konkrētā slāņa darbības ar apkārtējām un atbalstošajām piegādes ķēdes pārvaldības darbībām?
Secinājums
Bizness vēsturiski ir atdalījis tehnoloģiju vadību no ieņēmumus radošām uzņēmējdarbības jomām, uzskatot to par atbalsta darbību kopumu, kuru pamatā ir vērtības un mērķi, kas saskaņoti ar pakalpojumu sniegšanu. Tomēr programmatūras definētā pasaulē šis biznesa modelis vairs neder.
Programmatūras piegādes iespējas ir pārvietotas no klasiski noteiktās atbalsta vietas un ir noteiktas visas primārās ieņēmumus radošās darbības.
Tāpēc jums ir jāpārdomā savs modelis kā ražošanas sistēma un jāvirzās uz tādu, kas atspoguļo sarežģītības attiecības starp vērtību plūsmas darbībām. Piegādes ķēde iemieso šo domāšanu, un, attīstoties programmatūras produktu ražošanai, mēs noteikti redzēsim šo modeli nobriedušu.
