programinės įrangos inžinerijaJudrus vystymasisProduktų valdymas"DevOps"
Inovacijų greitis vs techninė skola
Šiame palyginime nagrinėjamas subtilus balansavimas tarp greito pristatymo funkcijų, kad būtų galima užimti rinkos dalį, ir išlaikyti sveiką kodų bazę. Nors inovacijų greitis matuoja, kaip greitai komanda sukuria vertę, techninė skola atspindi būsimą šiandien naudojamų nuorodų kainą. Tinkamas akordas tarp šių dviejų lemia ilgalaikį produkto išlikimą.
Akcentai
Inovacijų greitis suteikia puolamąją galimybę laimėti rinkas per greitą iteraciją.
Techninė skola yra paslėpta trintis, kuri sulėtina kiekvieną būsimą inžinerinę užduotį.
Didelis greitis yra laikinas, jei jį skatina neapgalvoti, nevaldomi kodo spartieji klavišai.
Skolų valdymas yra investicija į komandos gebėjimą greitai judėti ilguoju laikotarpiu.
Kas yra Inovacijų greitis?
Išmatuojamas greitis, kuriuo programinės įrangos komanda savo vartotojams pateikia naujas, funkcines funkcijas.
Jame daugiausia dėmesio skiriama diegimo dažnumui ir laikui nuo idėjos iki gamybos.
Didelis greitis leidžia įmonėms daug greičiau patikrinti rinkos hipotezes ir surinkti vartotojų atsiliepimus.
Greitis dažnai matuojamas naudojant DORA metriką, pvz., diegimo dažnumą ir pakeitimų pristatymo laiką.
Ankstyvosios stadijos startuoliai dažnai teikia pirmenybę šiam rodikliui, kad rastų produkto atitiktį rinkai, kol nesibaigia finansavimas.
Tai yra pagrindinis konkurencinis pranašumas sparčiai besivystančiose skaitmeninėse aplinkosaugose ir pramonės šakose.
Kas yra Techninė skola?
Numanomos papildomo perdirbimo išlaidos, atsiradusios pasirinkus paprastą sprendimą dabar, o ne geresnį.
Wardas Cunninghamas sukūrė šį terminą 1992 m., norėdamas paaiškinti, kodėl kodo priežiūra laikui bėgant sulėtėja.
Skola gali būti tyčinė, pavyzdžiui, skubėti prototipas, arba netyčinė dėl besikeičiančių reikalavimų.
Nevaldoma skola veda į "bitų puvimą", kai kodas tampa pernelyg trapus, kad jį būtų galima pakeisti nesulaužant.
Palūkanos už šią skolą mokamos per lėtesnius kūrimo ciklus ir didesnį klaidų aptikimą.
Šiuolaikinės inžinierių komandos dažnai skiria 20% savo sprinto pajėgumų specialiai skolų pensijai.
Palyginimo lentelė
Funkcija
Inovacijų greitis
Techninė skola
Pagrindinis dėmesys
Reagavimas į rinką
Sistemos tvarumas
Pagrindinė metrika
Funkcijos pristatymo laikas
Kodo keitimas ir sudėtingumas
Strateginis tikslas
Trumpalaikis augimas
Ilgalaikis stabilumas
Suinteresuotųjų šalių interesai
Produktas ir rinkodara
Inžinerija ir kokybės užtikrinimas
Rizikos veiksnys
Statyti neteisingą dalyką
Sisteminis žlugimas
Grįžtamojo ryšio ciklas
Išorinis (klientas)
Vidinis (kūrėjas)
Ekonominis poveikis
Greitas pajamų generavimas
Veiklos sąnaudų mažinimas
Ideali valstybė
Tvarus greitis
Valdomas sudėtingumas
Išsamus palyginimas
Virvės traukimas dėl išteklių
Inovacijų greitis ir techninė skola yra iš esmės susiję su nulinės sumos išteklių fondu. Kai komanda kas valandą skiria naujų funkcijų kūrimui, ji neišvengiamai praleidžia dokumentaciją ir testavimą, todėl kaupiasi skolos. Ir atvirkščiai, tobulo kodo apsėstos komandos greitis sumažės iki nulio, o tai gali prarasti kritinius rinkos langus.
Kaip greitis sukuria skolą
Norint greitai judėti, dažnai reikia imtis "apdairių" sparčiųjų klavišų, pvz., užkoduoti reikšmes arba praleisti abstrakcijos sluoksnį, kad būtų laikomasi parodos termino. Nors tai padidina greitą greitį, šie spartieji klavišai veikia kaip paskolos su didelėmis palūkanomis. Galiausiai kūrėjai praleidžia daugiau laiko taisydami senas klaidas nei rašydami naują kodą, todėl pradinis greitis išnyksta.
Palūkanų kaina
Techninė skola ne visada yra blogai, tačiau "palūkanos" yra tai, kas žudo produktyvumą. Tai pasireiškia padidėjusiu kognityviniu krūviu kūrėjams ir didesniu pakeitimų nesėkmių skaičiumi. Kai skola tampa per didelė, net paprastų funkcijų įgyvendinimas užtrunka kelias savaites, nes pagrindinė architektūra yra senų sprendimų painiava.
Tvaraus greičio pasiekimas
Sveikiausios organizacijos šias sąvokas traktuoja kaip ciklą, o ne konfliktą. Jie naudoja didelį greitį, kad pritrauktų klientus, tada sąmoningai sulėtina tempą, kad pertvarkytų ir "grąžintų" skolą. Ši periodinė priežiūra užtikrina, kad kodų bazė išliktų pakankamai lanksti, kad ateityje palaikytų didelį inovacijų greitį.
Privalumai ir trūkumai
Inovacijų greitis
Privalumai
+Greitesnis įėjimas į rinką
+Aukšta komandos moralė
+Greitas vartotojų atsiliepimas
+Pritraukia investuotojus
Pasirinkta
−Padidina klaidų skaičių
−Fragmentuota architektūra
−Didelė perdegimo rizika
−Dokumentų spragos
Techninis skolų valdymas
Privalumai
+Nuspėjami leidimai
+Lengvesnis įdarbinimas
+Aukštesnė kodo kokybė
+Sistemos atsparumas
Pasirinkta
−Uždelstos funkcijos
−Nusivylusios suinteresuotosios šalys
−Mažesnis rinkos lankstumas
−Sunku kiekybiškai įvertinti
Dažni klaidingi įsitikinimai
Mitas
Visos techninės skolos yra blogos inžinerijos požymis.
Realybė
Skola dažnai yra strateginis pasirinkimas. Puikūs inžinieriai kartais sąmoningai imasi nuorodų, kad pasiektų verslo tikslus, panašiai kaip hipoteka namui įsigyti, kurio kitaip negalėtumėte sau leisti.
Mitas
Greitis matuoja tik tai, kiek kodo eilučių parašyta.
Realybė
Tikrasis greitis matuoja vertės pristatymą, o ne tūrį. Rašyti tūkstančius kodo eilučių, kurios neišsprendžia vartotojo problemos, iš tikrųjų yra neigiamas greitis.
Mitas
Galiausiai galite pasiekti nulinės techninės skolos būseną.
Realybė
Tai neįmanoma gyvoje sistemoje. Tobulėjant technologijoms ir keičiantis reikalavimams, net ir prieš trejus metus parašytas "tobulas" kodas natūraliai tampa skola, nes nebeatitinka šiuolaikinio konteksto.
Mitas
Refactoring yra laiko švaistymas verslui.
Realybė
Refaktoringas yra tiesioginė investicija į ateities greitį. Nesugebėjimas pertvarkyti prilygsta leidimui gamyklos mašinoms rūdyti, kol galiausiai jos visiškai nustoja veikti.
Dažnai užduodami klausimai
Kaip paaiškinti techninę skolą netechninėms suinteresuotosioms šalims?
Pagalvokite apie tai kaip apie programinės įrangos kreditinę kortelę. Šiandien galite nusipirkti norimų dalykų, net jei neturite grynųjų pinigų, tačiau jei nesumokėsite likučio, palūkanų mokėjimai ilgainiui sunaudos visą jūsų mėnesio biudžetą. Programinėje įrangoje šis "susidomėjimas" yra papildomas laikas, kurį inžinieriai praleidžia kovodami su netvarkingu kodu, užuot kūrę naujas funkcijas.
Ar didelis greitis visada lemia daugiau techninių skolų?
Nebūtinai, bet yra stipri koreliacija. Komandos, naudojančios automatizuotą testavimą ir nuolatinę integraciją, gali išlaikyti didelį greitį ir mažiau kaupti skolas. Svarbiausia yra "tvarus greitis", kuris apima kokybės įtraukimą į procesą, o ne bandymą taisyti dalykus po fakto.
Kokie yra geriausi inovacijų greičio stebėjimo rodikliai?
Patikimiausi metodai yra DORA metrika, konkrečiai pakeitimų pristatymo laikas ir diegimo dažnumas. Taip pat turėtumėte pažvelgti į "Funkcijų pralaidumą" – per sprintą užbaigtų naudotojų istorijų skaičių. Labai svarbu juos įvertinti kartu su kokybės rodikliais, kad įsitikintumėte, jog nejudate greitai neteisinga linkme.
Kada galima sąmoningai prisiimti techninę skolą?
Tai dažnai tikslinga minimalaus gyvybingo produkto (MVP) etapu arba kai susiduriama su griežtu reguliavimo terminu. Jei įmonės išlikimas priklauso nuo pristatymo per dvi savaites, skolų prisiėmimas yra logiškas verslo sprendimas. Pavojus yra ne pati skola, o plano, kaip ją grąžinti vėliau, nebuvimas.
Kiek kūrėjo laiko turėtų būti skiriama skoloms?
Nors tai skiriasi priklausomai nuo pramonės šakos, daugelis didelio našumo inžinerinių organizacijų laikosi "80/20 taisyklės". Jie skiria 80 % savo laiko naujoms funkcijoms ir 20 % priežiūrai, pertvarkymui ir įrankių tobulinimui. Jei jūsų skola yra didelė, jums gali tekti kelis mėnesius apversti šiuos skaičius, kad atgautumėte stabilumą.
Ar galite išmatuoti techninės skolos kainą doleriais?
Taip, nors tam reikia tam tikro įvertinimo. Jį galite apskaičiuoti žiūrėdami į "produktyvumo atotrūkį" – skirtumą tarp to, kiek laiko užduotis turėtų užtrukti švarioje sistemoje ir kiek laiko ji iš tikrųjų užtrunka. Padauginus šį papildomą laiką iš inžinierių komandos valandinių išlaidų, gausite apytikslį mokamų "palūkanų" finansinį skaičių.
Kas yra "tamsioji skola" programinės įrangos sistemose?
Tamsioji skola reiškia sudėtingumą ir pažeidžiamumą, kuris nėra matomas, kol tam tikros aplinkybės nesukelia visos sistemos gedimo. Skirtingai nuo žinomų techninių skolų (pvz., trūkstamo testo), tamsioji skola randama nenumatytose sąveikose tarp skirtingų mikropaslaugų ar senų komponentų.
Ar "kodo įšaldymas" padeda sumažinti techninę skolą?
Kodo įšaldymas gali sustabdyti naujų skolų kaupimąsi, tačiau automatiškai neišsprendžia esamų problemų. Paprastai tai yra kraštutinė taktika, naudojama, kai sistema tapo pernelyg nestabili, kad ją būtų galima įdiegti. Geresnis metodas yra "nuolatinis pertvarkymas", kai kartu su kiekviena nauja funkcija atliekami nedideli patobulinimai.
Nuosprendis
Pasirinkite pirmenybę inovacijų greičiui ankstyvojo etapo augimo metu arba konkurenciniams posūkiams, kad užsitikrintumėte savo pozicijas rinkoje. Tačiau pereikite prie techninių skolų valdymo, kai produktas subręsta, kad išvengtumėte visiško progreso sąstingio ir talentų perdegimo.