Katrs produkts attīstās savā noslēpumainā veidā. Pat pieredzējuša komanda nevar paredzēt katru produkta dzīves cikla pagriezienu. Vienkāršas funkcijas var pārnest uz milzīgām vairāku nosacījumu darbplūsmām. Daži ātri izstrādāti sānu scenāriji varētu kļūt par visbiežāk izmantotajiem. Pat produkta popularitāte var izraisīt neparedzētas veiktspējas problēmas. Un ir pilnīgi normāli pielāgot programmatūru tirgus vajadzībām. Vienīgais veids, kā iegūt uzticamu un paredzamu produktu, ir rezervēt kādu laiku tehniskā parāda fiksēšanai un atbilstoša pārveidošanas procesa nodrošināšanai. Šajā rakstā ir labāk iekļaut dažas terminu definīcijas. Tehniskais parāds jeb tehnoloģiju parāds ir kodu bāzē uzkrātie kompromisi, kas var rasties ātras attīstības vai citu svārstību laikā. Refaktorizācijas process vairāk ir saistīts ar produkta uzlabošanu kopumā. Tas var ietvert darbības, kas saistītas ar veiktspēju, labāku koda struktūru un risinājuma vienkāršību. Tomēr dažreiz šie divi jēdzieni var būt ļoti tuvi. Piemēram, dažām funkcijām, kas ir pilnas ar tehnoloģiju parādiem, var būt nepieciešama visa moduļa pareiza pārstrukturēšana, lai vienreiz un uz visiem laikiem atrisinātu problēmu ar jaunām idejām un atkārtotu ieviešanu. Un šeit ir triks. Kopumā labiem programmatūras izstrādātājiem ir daudz ideju produktu uzlabošanai. "Labi, šīs funkcijas laikā mēs varētu pielāgot dažas lietas." "Ak, tas nav tik svarīgi, bet būtu jauki šo lietu salabot šajā sānu modulī." Tomēr ir ļoti svarīgi ļaut jūsu komandas locekļiem uzlabot kodu bāzi, jo tas palīdz veidot reālas iesaistītas komandas. Tomēr šajā rakstā es vēlētos atklāt pārstrukturēšanas procesu no vadītāja viedokļa. Iepriekš minētajos piemēros ir viena problēma — tie var būt necaurredzami visai komandai, izņemot izstrādātājus. Lai gan kvalitātes nodrošināšanai un vadītājiem ir plāns pēc grafika izlaist pareizu un stabilu programmatūru, daži slēpti uzlabojumi var radīt negaidītus pavērsienus un nervu atkārtotas pārbaudes izlaišanas laikā. Vai pat jaunas kļūdas ražošanā, ja regresa posmā dažas nedokumentētas izmaiņas paliek nepamanītas. Tātad ir nepieciešami koda uzlabojumi, taču tiem jābūt pārvaldāmiem. Kā izveidot pārvaldāmu pārstrukturēšanas procesu savā komandā Risinājums ir sarežģīts. Agile ir mūsu labākais draugs, jo Agile izstrādes metodoloģiju kopīgie principi un rituāli aptver problēmas. Jums ir nepieciešams: Veidojiet tehnisko parādu uzkrājumu un regulāri sadaliet resursus. Izveidojiet atbilstošus kopšanas un plānošanas procesus, lai atklātu iespējamos uzlabojumus. Deklarējiet procesus neparedzētu problēmu gadījumā iterācijas laikā. Ar kopšanu es domāju saziņu starp komandas locekļiem pirms iterācijas, kuras mērķis ir noteikt iterācijas tvērumu, precizēt prasības, sadalīt uzdevumus, novērtēt centienus un noteikt prioritātes turpmākajiem darba vienumiem. Plānošanas process ir saistīts ar iegūto iterācijas apjomu. Ne katrs koptais uzdevums var tikt iekļauts iterācijā. Iedziļināsimies katrā tēmā. Tehnisko parādu uzkrājumu veidošana un resursu piešķiršanas noteikums Vienkāršākais veids, kā katrs izstrādātājs var izveidot tehnoloģiju parādu uzkrājumu, ir avota kodā izmantot tagus “To do”. Vēlāk jūs varētu meklēt kodu bāzē, kaut ko uzlabot un nosūtīt apstiprināšanas pieprasījumus. Taču ar to nepietiek. Tas nepalīdz komandas dalībniekiem nodrošināt pareizu plānošanu un būt pārliecinātiem par izlaišanas apjomu. Labāka alternatīva “To Do” izmantošanai ir izveidot procesu, lai izveidotu uzdevumus turpmākajām izmaiņām. Ja izstrādātājs atrod kādu potenciālu problēmu vietu vai viņam ir ideja par kodu bāzes uzlabošanu, viņam ir jāizveido darba vienums biļešu sistēmā (Jira, Azure DevOps vai jebkura sistēma, ko izmanto komanda). Būtu pārspīlēti prasīt, lai inženieri sniegtu detalizētu savas idejas aprakstu katram komandas loceklim, taču paskaidrojumam ir jābūt pietiekami skaidram, lai komandas vadība saprastu izmaiņu galveno punktu un apjomu. Tas aptver pirmo soli - kā mēs varam izveidot potenciālo uzdevumu sarakstu un nodrošināt augsta līmeņa turpmāko izmaiņu aprakstu. Otrais solis ir padarīt to saprotamu visiem. Šo uzdevumu atkarībā no kvalifikācijas var veikt izstrādātāju komandas vadītājs, izlaišanas vadītājs vai produktu vadītājs. Rezultātā jāsniedz šāda informācija: Ko mēs darām? - Augsta līmeņa idejas skaidrojums. Kāpēc mēs to darām? - Apraksts par to, kā šīs izmaiņas varētu uzlabot izstrādes ātrumu, samazināt spageti koda izraisītās nestabilitātes risku vai palielināt programmatūras veiktspēju. Cik svarīgas šīs izmaiņas ir turpmākajai attīstībai? - Izmaiņu prioritāte. Piemēram, bez šīm izmaiņām turpmāko uzlabojumu vai biznesa funkciju izmaksas var pieaugt eksponenciāli. Kādus riskus rada šīs izmaiņas? - Ietekmēto līdzekļu vai moduļu saraksts, kas palīdz kvalitātes nodrošināšanai pārbaudīt izmaiņas. Ja darba vienumam ir atbildes uz visiem šiem jautājumiem, tas palīdz mazināt iespējamās problēmas nākotnē. Tomēr pārvaldāmai pārstrukturēšanai nepietiek tikai ar neizpildīto situāciju. Jums ir jāplāno iespējamās izmaiņas, un tām jābūt pastāvīgai jūsu procesa sastāvdaļai. Protams, jūs saskarsieties ar biznesa funkciju un tirgus prasību spiedienu, kur ir liels kārdinājums izlaist tehnoloģiskos uzdevumus. Bet bez pienācīgas apkopes jūs nākotnē saskarsities ar vēl lielākām problēmām. Ieteikums par tehnoloģisko nokavēto procesu ir: Katrā iterācijā komandai ir jārezervē laiks tehnoloģiju uzlabojumiem. Ja ir kāda ideja par uzlabojumiem, tā ir jāformalizē kā darba vienums ar atbilstošu aprakstu. Darba priekšmetiem ir jāpiedalās kopšanas procesā, un tie jāapspriež visai komandai, līdz ir identificēti visi ieguvumi un riski un apkopoti visu komandas locekļu aprēķini. Darba vienumi tiek plānoti Agile iterācijās atbilstoši to aplēsēm. Iterācijas laikā komandai ir jāatzīst iespējamais tehnoloģiju parādu apjoms. Ja nepieciešams, rezervēto laiku var palielināt, taču tas nekādā gadījumā nedrīkst būt mazāks par parasto. Tas palīdz mudināt inženierus izveidot jaunus uzdevumus un noteikt tiem prioritāti. Ikviens zina, ka viņu ierosinājumus varētu īstenot, un aizkavēšanās kādreiz saruks, nevis pāraugs par milzīgu demoralizējošu sarakstu. Kopšanas un plānošanas procesu izmantošana, lai atklātu iespējamo tehnoloģiju parādu Dažreiz tehnoloģiju parādu uzdevumi var tikt atklāti diskusiju un aplēšu laikā, kamēr komanda saskārās ar negaidītiem šķēršļiem, kas padarīja realizāciju mazāk uzticamu un elastīgu. Piemēram, jūs varat apzināties, ka ir līdzīgas funkcijas, un pavisam jaunas funkcijas izveide tikai pasliktinātu kodu bāzi. Taču šie līdzekļi nesatur biznesa funkcionalitāti, kas nepieciešama jaunajās. Un labāk ir izveidot vienotu pakalpojumu, kas savieno visas līdzīgās funkcijas, lai vienkāršotu apkopi nākotnē. Tomēr šīs izmaiņas var ietekmēt un destabilizēt vecās funkcijas, un tas ir izaicinājums. Varbūt ir kāds veids, kā lēti izstrādāt jaunas funkcijas un pievērt acis uz nepilnībām. Vai varbūt tieši tagad ir labākā iespēja izveidot vienotu pakalpojumu, kamēr ir tikai dažas līdzīgas funkcijas. Vissvarīgākais ir izveidot procesu, kas palīdz komandas locekļiem pieņemt lēmumu, pamatojoties uz atklātajiem faktiem un pareizi koptām aplēsēm. Ir ļoti svarīgi, lai būtu sistēma, kas novērš situācijas, kad šādi lēmumi jāpieņem īstenošanas posmā, ja pastāv kavēšanās. Ja jūsu iterācijas posmi darbojas labi, šādu momentu atklāšana notiks automātiski, veicot pareizu kopšanas un plānošanas procesu. Ir daži pamatnoteikumi un darbības, kas vairumā gadījumu var pasargāt komandu no negaidītiem šķēršļiem: Izpildītajā kopšanas programmā jāiekļauj uzdevumi ar skaidrām un izpildāmām prasībām. Pirms apspriedes un aplēses ar kopšanas darbiem ir jādalās ar komandas locekļiem. Visiem komandas dalībniekiem ir jābūt sagatavotiem un jāiepazīst ar uzdevumiem pirms kopšanas. Ja kādai nepabeigtai lietai nepieciešama papildu izmeklēšana vai atkārtota ieviešana, problēma ir jāapspriež. Prasības problemātiskiem atlikumiem ir jāpabeidz, pamatojoties uz atklātajām īpatnībām. Visas iespējamās problemātiskās jomas ir jādokumentē. Katrs atliktais vienums ir jānovērtē. Problēmas, kas ir nepabeigtas, varētu sadalīt atsevišķos uzdevumos un plānot atbilstoši prioritātēm. Lēmumus par ieviešanas stratēģiju var pieņemt izlaišanas pārvaldnieks atkarībā no riskiem un termiņiem. Taču šī pieeja palīdz dokumentēt visus lēmumus. Pat ja tehnoloģiju parāda uzdevums tika atlikts, tas joprojām tiek pievienots atlikumam. Vēlāk šie uzdevumi ir jāpārskata un jāieplāno. Šis process nosaka scenārijus, kad drudžainās iterācijas laikā tiek aizmirstas dažas labas un vajadzīgas idejas. Procesa izveide neparedzētu problēmu gadījumā iterācijas laikā Tomēr pat ar labi uzturētu tehnoloģiju parādu uzkrājumu un strādājošu kopšanas un plānošanas procesu ir iespējams saskarties ar neparedzētiem un laikietilpīgiem šķēršļiem izstrādes procesā. Programmatūras produkti var būt sarežģīti, īpaši veci vai satur bagātīgu funkcionalitāti. Agile prakses izmantošana palīdz savlaicīgi apkopot informāciju un pieņemt pareizu lēmumu. Viens no vienkāršākajiem risinājumiem ir ikdienas tikšanās. Ja inženieris saskaras ar kādu problēmu, tā ir jāatklāj sanāksmes laikā un jāapspriež vēlāk. Katrs šķērslis ir unikāls un var aizņemt atšķirīgu laiku. Nav nozīmes tam, vai izmaiņas tiks ieviestas pašreizējā iterācijā, nevis līdzekļa “Patīkami iegūt” vietā, vai arī ir nepieciešama pilnīga iterācijas tvēruma pārskatīšana. Problēma jāizveido kā tipisks tehnoloģiju parāda uzdevums izsekošanas sistēmā, jāsadala un jāapraksta kā jebkurš cits līdzīgs uzdevums iepriekšējos rakstos. Konsekvence ir galvenais, un komandai ir jāzina, kā rīkoties šajās situācijās. Papildu birokrātijas kritika un kā uz to atbildēt Visas šīs metodes var šķist papildu veids, kā pavadīt visas komandas laiku ar bezjēdzīgu birokrātiju. Un tas tā varētu būt, ja tikai stingru un skaidru noteikumu trūkums nesagādātu grūtus laikus visiem. Ir pareizi šos ieteikumus neievērot īstermiņa projektos vai minimālā vērtīgā produkta (MVP) posmā. Taču, lai strādātu ražošanā ar atbildību par kvalitāti un lieliem produktiem, ir nepieciešama skaidri definēta iekšējo procesu sistēma. Apskatīsim visbiežāk sastopamos iebildumus. Šādu uzdevumu izveide ir laikietilpīga, un dažreiz ir ātrāk veikt izmaiņas kodā, nevis tos aprakstīt Un tā ir taisnība. Uzdevumu aprakstīšana dabiskā valodā dažkārt var būt grūtāk nekā koda labošana. Bet šeit ir daži risinājumi: Var būt noderīgi izveidot veidņu sistēmu biļešu sistēmā. Tas ļauj ātri pievienot uzdevumus un aizpildīt tos ar pareiziem parametriem un saitēm. Ir lieliski, ja korporatīvajā viki ir pieejamas dažas biļešu politikas, piemēram, Confluence / Notion / SharePoint vai jebkura cita komandas dokumentācijas platforma. Šīs lapas var sniegt labus pareizi izveidotu uzdevumu piemērus. Komandas vadītāja interesēs ir uzturēt tehnisko dokumentāciju un pulēt veidnes, lai palīdzētu jebkuram citam komandas dalībniekam iesniegt skaidras un saprotamas biļetes. Pamatlīmenī pietiek ar pienākumu inženieriem izveidot uzdevumus ar augsta līmeņa aprakstiem bez plašiem rakstiem par stratēģisko redzējumu vai viņu ieteikumu potenciālu. Aprakstam ir jāpalīdz recenzentam (parasti komandas vadītājam) iegūt galveno priekšstatu par izmaiņām. Vēlāk komandas vadītājs var apstiprināt ieteikumu un aizpildīt to ar papildu informāciju atbilstoši procesam. Tas arī palīdz saprast, vai šīs izmaiņas vispār ir nepieciešamas, un nodrošina kvalitātes filtru. Ja izstrādātājam ir laiks ieviest ieteikumu, funkciju nozares politika var būt ļoti noderīga. Tomēr uzdevums ir jāizveido, jo ir lietderīgi izveidot kārtulu ar biļeti nosaukto līdzekļu zaru izveidei. Taču rezultātā mēs iegūstam apmierinātu inženieri, kurš ir ieviesis kādu tehnoloģiju parādu, biļeti un saistītu ieviešanu, ko var kopt un plānot verifikācijai piemērotā iterācijā, neriskējot ar negaidītu destabilizāciju. Visas šīs izmaiņas ir ļoti tehniskas, un apraksts nepalīdz, jo neviens nesapratīs Varbūt. Bet tas ir atkarīgs no skaidrojuma. Prioritāte ir apraksts par to, kas varētu noiet greizi un kāda funkcionalitāte varētu tikt destabilizēta. Tomēr ir lietderīgi rakstīt par izmaiņu ietekmi, jo tas palīdz identificēt papildu iespējas un scenārijus. Arī visdziļāk tehniskās idejas varētu aprakstīt vienkāršos teikumos, izmantojot dabisko valodu. Ja viņi nevar, var būt kaut kas nepareizi ar pašu ideju, un tas varētu būt potenciāls risks, viss priekšlikums būtu jāpārskata. Vienkārši uzrakstiet kaut ko līdzīgu: Metode “XXX” patērē pārāk daudz RAM katrā zvanā. Papildu kešatmiņas izveide šai metodei palīdz samazināt RAM patēriņu un paātrināt visas API. Metode izmanto datus, kas mainās reti, restartējot pietiek ar kešatmiņas nomešanu. Izmaiņas ir drošas, taču var ietekmēt šādas funkcijas: XXX, XXX, XXX…”. Dažos gadījumos ar to pietiktu. Citos gadījumos šis ieteikums var izraisīt diskusiju, jo inženieris var aizmirst par kādu vecu, bet joprojām lietotu funkcionalitāti, kur šī kešatmiņa var radīt problēmas. Kopšanas procesā ideja tiks pārskatīta, un komanda atradīs kompromisu. Visas šīs politikas tikai neļauj lietotājiem saņemt jaunus uzlabojumus Stabilitāte un uzticamība ir labāki par dažiem procentiem uzlabojumiem dažu funkciju izpildes laikā. Neviens nebūs vīlies, palaižot garām iespējamo veiktspējas palielinājumu, taču ir viegli sabojāt produkta reputāciju. Vai mums ir vajadzīga visa šī birokrātija vienkāršam koda stilam, kas 99,99% gadījumu nekad nenodarīs nekādu ļaunumu? Ideja ir racionalizēt procesus un palīdzēt novērtēt riskus. Inženieriem vajadzētu būt iespējai uzturēt kodu bāzi un nodrošināt dažus uzlabojumus. Attiecībā uz lietām, kas ir mazas un nedestabilizē visu produktu, ir iespējams izveidot apkopotus darba vienumus, kurus var pabeigt iterācijas laikā. Šie uzdevumi joprojām ir jāpārskata kā izvilkšanas pieprasījumi, taču tie nav oficiāli jāpaziņo komandai. Secinājums Pastāvīgi produktu uzlabojumi ir ļoti svarīgi uzņēmējdarbībai un palīdz saglabāt vispārējo kvalitāti. Ja jūs paturēsit tehnisko parādu un jaunas idejas plauktā, jūs iestrēgsit ar novecojušu produktu un drīz vien jums būs grūti atrast ekspertus, kas to apkoptu. No otras puses, šie uzdevumi konkurē ar biznesa funkcijām un citām idejām, kas var virzīt biznesu uz jauniem apvāršņiem. Šie ieteikumi par tehnisko uzdevumu atlikumu var palīdzēt atklāt un novērtēt šo uzdevumu nozīmi ne tikai komandas locekļiem, bet arī ieinteresētajām personām. Tie palīdz pasniegt šīs idejas dabiskā valodā un saglabāt un saglabāt īstenošanas laiku. Tas apgrūtina inženierus ar papildu darbībām, bet galu galā palīdz visai komandai piegādāt augstas kvalitātes un uzticamus produktus. Un vadītāja pienākums ir izvēlēties pareizo instrumentu vai politiku šī procesa uzturēšanai.
