Nustokite laukti, pradėkite prisidėti – kaip spartinti rezultatų pristatymą peržengiant komandų ribas

Kai kurios rezultatų pristatymo problemos atrodo kaip pajėgumų trūkumas. Komanda negali judėti pirmyn, nes kita komanda dar nepridėjo API metodo, nepaskelbė įvykio ar neatvėrė reikalingo lauko. Antroji komanda užsiėmusi darbais, svarbesniais jos pačios tikslams, todėl prašymas laukia darbų sąraše.

Įprasta reakcija – eskaluoti, derėtis dėl prioritetų arba keisti planą. Kartais tai būtina. Tačiau keliose organizacijose radau kitą būdą, kuris buvo ir greitesnis, ir sveikesnis:

Užuot prašę kitos komandos sukurti trūkstamą dalį, įgyvendinkite pakeitimą jos sistemoje patys ir paprašykite jį peržiūrėti.

Tai nėra istorija apie bendradarbiavimo atsisakymą. Tai istorija apie eilėmis pagrįstų perdavimų pakeitimą bendru prisidėjimu.

Toliau pateikti pavyzdžiai yra sudėtiniai. Industrijos, sistemų ribos, įvykių sekos ir organizacinės detalės sąmoningai sujungtos arba pakeistos. Pats pristatymo modelis yra tikras, tačiau aprašymas nėra skirtas jokiai įmonei ar asmeniui atpažinti.

Priklausomybė buvo eilė

Įsivaizduokite produkto komandą, atsakingą už darbo eigą, kertančią kelias sistemas. Ji valdo orkestravimo sluoksnį, tačiau jai reikia galimybės iš kitos komandos prižiūrimos platformos.

Tokia priklausomybė dažnai atrodo taip:

1. Produkto komanda suformuluoja prašymą.
2. Platformos komanda jį patikslina ir įvertina.
3. Prašymas konkuruoja su platformos komandos prioritetais.
4. Kažkas jį įgyvendina turėdamas tik dalį pradinio poreikio konteksto.
5. Produkto komanda integruoja pakeitimą ir pamato, kas buvo suprasta neteisingai.

Nė vienas šio proceso žingsnis nėra nelogiškas. Kiekviena komanda optimizuoja savo darbo krūvį. Vėlavimas atsiranda tarp komandų: kontekstas perduodamas per užduotis, grįžtamasis ryšys ateina vėlai, o už visą rezultatą neatsako niekas.

Techninė priklausomybė yra reali, tačiau pristatymą labiausiai lėtina prisidėjimo modelis. Tik viena komanda turi teisę – arba jaučiasi turinti teisę – keisti konkretų kodą.

Geležinkelis, optimizuotas jo operatoriams

Įsivaizduokite visą kliento kelią kaip kelionę geležinkelių tinklu.

Keleivis yra kliento siekiamas rezultatas. Kiekviena stotis – sistema arba aiški veiklos srities riba, o skirtingi geležinkelių operatoriai – inžinerijos komandos – valdo skirtingas bėgių atkarpas. Kiekvienas operatorius prižiūri savo infrastruktūrą, nustato veiklos taisykles ir atsako už savo tinklo dalies saugumą.

Dabar įsivaizduokite, kad keleivis privalo persėsti kaskart, kai pasikeičia bėgių savininkas. Vienas operatorius nuveža jį iki savo ribos, perduoda kelionę ir laukia, kol kitas operatorius suplanuos kitą traukinį. Bėgiai fiziškai sujungti, tačiau veiklos modelis suskaldo kelionę.

Taip dažnai atrodo tradicinis darbas tarp komandų. Funkcionalumas juda iki vienos komandos sistemos ribos, tuomet tampa prašymu kitos komandos darbų sąraše ir keliauja toliau tik tada, kai ši komanda pasirengusi įgyvendinti savo dalį. Kiekviena vietinė atkarpa gali būti valdoma efektyviai, nors visa kelionė nuo pradžios iki pabaigos lieka lėta.

Prisidėjimo modelis labiau primena galimybę traukiniui tęsti kelionę kelių operatorių bėgiais pagal sutartas taisykles. Bėgių nuosavybė nesikeičia. Kiekvienas operatorius vis dar nustato savo saugumo standartus ir išlaiko sprendimo teisę dėl infrastruktūros. Tačiau kito operatoriaus traukinys gali naudotis bėgiais, jei atitinka šiuos standartus.

Programinėje įrangoje pull request yra prašymas įvažiuoti į bėgius. Automatiniai testai, architektūrinės taisyklės ir prižiūrėtojų peržiūra atlieka veiklos bei saugumo patikrų vaidmenį. Prisidedantis inžinierius perneša kliento rezultatą per ribą, užuot prašęs kitos komandos pradėti atskirą kelionę.

Keleiviui nesvarbu, kam priklauso kiekviena bėgių atkarpa – jam svarbu pasiekti tikslą. Taip pat ir klientui nesvarbu, kiek komandų valdo sistemas, veikiančias už konkrečios galimybės. Nuosavybė gali likti vietinė, net kai atsakomybė už visos kelionės užbaigimą apima kelis savininkus.

Pasikartojantis modelis skirtingomis formomis

Pirmą kartą šį modelį pastebėjau dirbdamas su kelių kanalų turinio platforma. Viena komanda valdė centrą, sinchronizuojantį įrašus su keliomis išorinėmis paskirties sistemomis. Reikėjo prijungti naują vidinę paskirties sistemą, tačiau ją kurianti komanda negalėjo suteikti prioriteto reikalingam API.

Laukiant viena komanda būtų likusi be darbo, o kita būtų turėjusi perprasti reikalavimus, už kuriuos pati neatsakė. Todėl pasiūlėme paprastesnį susitarimą: mūsų komanda įgyvendins API paskirties sistemos kode, o jos prižiūrėtojai paaiškins vietines taisykles ir išlaikys sprendimo teisę per kodo peržiūrą.

Pirmasis pull request užtruko ilgiau nei pakeitimas savo repozitorijoje. Reikėjo perprasti nepažįstamus modelius, reaguoti į peržiūros pastabas ir pataisyti klaidingas veiklos srities prielaidas. Vis dėlto tai buvo greičiau nei laukti kitos komandos eilėje. Dar svarbiau – integraciją įgyvendinantis žmogus galėjo keisti abi jos puses ir patikrinti visą veikimą.

Tokį patį modelį mačiau keičiant seną platformą. Su nauja paslauga besiintegruojanti komanda pastebėjo, kad pakaitiniame modelyje trūksta dalies informacijos, reikalingos esamai darbo eigai. Įprastas sprendimas būtų buvęs registruoti prašymus pakaitinę sistemą kuriančiai komandai.

Mes pasirinkome prisidėti patys. Patvirtinimas nebuvo momentinis – ir neturėjo toks būti. Prižiūrėtojai kėlė klausimus dėl pavadinimų, ribų ir migravimo elgsenos. Šios pastabos pagerino pakeitimą ir kartu padėjo prisidedančiai komandai suprasti, kaip veikia naujoji platforma. Senosios sistemos elgseną išmanantis inžinierius galėjo pernešti šį kontekstą į jos pakaitalą ir prisiimti atsakomybę už visą rezultatą.

Trečią šio modelio versiją sutikau beveik realiuoju laiku veikiančiame duomenų produkte. Vienai klientui matomai galimybei pristatyti reikėjo suderintų pakeitimų duomenų surinkimo, apdorojimo ir peržiūros sistemose. Jos priklausė skirtingoms grupėms, turinčioms skirtingus prioritetus. Kiekvieną ribą traktuojant kaip perdavimą, galutinis terminas priklausė nuo trijų atskirai planuojamų darbų sąrašų.

Pristatanti komanda dirbo peržengdama šias ribas: įgyvendino tiksliai apibrėžtus pakeitimus, kūrė pull request kiekvienoje kodų bazėje ir anksti įtraukė jų prižiūrėtojus. Sistemų nuosavybė nepasikeitė. Pasikeitė atsakomybė už rezultatą.

Nuo perdavimų prie bendro prisidėjimo

Šiuo pokyčiu nesiekėme pašalinti kitų komandų iš proceso. Atskirų įgyvendinimo eilių grandinę pakeitėme tiesioginiu prisidėjimu ir prižiūrėtojų peržiūra.

Esminis pokytis subtilus: kodo bazės nuosavybė nebereiškia išskirtinės teisės joje ką nors įgyvendinti.

Prižiūrėtojai lieka atsakingi už savo sistemos būklę ir kryptį. Prisidedantieji prisiima atsakomybę pakankamai gerai ją suprasti, kad galėtų atlikti saugų pakeitimą. Peržiūra tampa vieta, kurioje keičiamasi veiklos srities ir inžinerinėmis žiniomis, o ne paskutiniu barjeru po kelių laukimo savaičių.

Kas pagerėjo

Atsakomybė už rezultatą nuo pradžios iki pabaigos

Problemą sprendžiantis žmogus gali sekti ją per sistemų ribas, išbandyti visą kelią ir reaguoti į naujai atrastus dalykus nepradėdamas dar vieno tarpkomandinio prašymo ciklo. Darbas organizuojamas aplink rezultatą, o ne repozitoriją.

Greitesnis grįžtamasis ryšys

Nedidelis pull request sukuria konkretų pagrindą diskusijai. Prižiūrėtojai gali pataisyti įgyvendinimą, nurodyti esamą abstrakciją arba atmesti klaidingą prielaidą anksčiau, nei galėtų tai padaryti turėdami tik išsamią užduotį.

Bendros veiklos srities žinios

Prisidedantieji sužino, kaip veikia gretimos sistemos ir kodėl jos turi konkrečius apribojimus. Prižiūrėtojai geriau supranta sistemą naudojančią darbo eigą. Šios žinios pagerina būsimus abiejų pusių sprendimus.

Geresnės techninės praktikos

Tarpkomandinės peržiūros supažindina komandas su skirtingomis testavimo strategijomis, diegimo metodais, stebimumo taisyklėmis ir kodo struktūravimo būdais. Naudingos praktikos plinta per realų darbą, o ne standartų dokumentą.

Mažiau koordinavimo eilių

Priklausomybė visiškai neišnyksta. Prisidedančiai komandai vis dar reikia peržiūros, o kartais ir prižiūrėtojų pagalbos. Tačiau didelę priklausomybę – laukimą, kol kita komanda suplanuos ir įgyvendins darbą – pakeičia mažesnė: laiku suteiktos gairės ir peržiūra.

Šiam modeliui reikia saugiklių

Prisidėjimas peržengiant komandų ribas nėra leidimas savavališkai keisti nepažįstamas sistemas. Be kelių sąlygų jis gali sukurti daugiau darbo, nei sutaupo.

• Galutinį sprendimą išlaiko prižiūrėtojai. Jie atsako už sistemos vientisumą ir gali prašyti pataisymų arba atmesti pasirinktą kryptį.
• Prisidedantieji anksti įtraukia prižiūrėtojus. Trumpas pokalbis apie sprendimą prieš jį įgyvendinant apsaugo nuo didelių, klaidinga kryptimi nuėjusių pull request.
• Į kodo bazę saugu įžengti. Vietinės aplinkos paruošimas, testai, informacija apie savininkus ir prisidėjimo gairės turi būti lengvai randamos.
• Peržiūra laikoma suplanuotu darbu. Jei prižiūrėtojai negali skirti laiko gairėms ar peržiūrai, eilė tik pakeitė formą.
• Pakeitimai lieka nedideli. Trūkstamas laukas ar API metodas yra gera pradžia. Platesniam perprojektavimui reikia išsamesnio bendro planavimo.
• Atsakomybė už veikimą yra aiški. Prieš sujungiant pakeitimą reikia sutarti, kas jį diegs, stebės, palaikys ir taisys.

Yra ir atvejų, kai toks prisidėjimas nėra tinkama priemonė: griežtai ribojamos sistemos, itin specializuoti komponentai, aktyvūs incidentai arba pakeitimai, kurių rizikos prisidedanti komanda negali atsakingai įvertinti. Tikslas nėra visuotinė prieiga. Tikslas – padaryti ribas pralaidžias ten, kur tai saugu.

Komandos požiūrio keitimas

Sunkiausia kliūtis retai buvo repozitorijos prieigos teisės. Dažniau tai buvo įsitikinimas, kad „jų sistema“ reiškia „jų darbą“. Komandos buvo išmokusios nuosavybę tapatinti su riba, nurodančia, ką joms leidžiama suprasti ar keisti.

Buvo ir asmeniškesnis rūpestis. Įžengti į kitos komandos sritį reiškia vėl tapti naujoku. Savo sistemoje užtikrintai besijaučiantys inžinieriai nerimavo, kad užduos akivaizdžius klausimus, nesupras vietinių taisyklių arba atrodys mažiau kompetentingi nepažįstamiems vertintojams. Vien pasakymas „tiesiog prisidėkite“ šios socialinės rizikos nepašalino.

Šį įsitikinimą bandžiau pakeisti dviem idėjomis:

1. Jūs atsakote už rezultatą, net kai kelias iki jo kerta kitos komandos kodą.
2. Turėti sistemą reiškia prižiūrėti kitų indėlį, o ne patiems įgyvendinti kiekvieną pakeitimą.

Tačiau pakeisti žodžius nepakako. Žmonės turėjo pamatyti, kad peržengti ribą ir įmanoma, ir saugu.

Kaip padarėme pirmąjį prisidėjimą saugų

Mūsų metodas ilgainiui tapo paprasta mokymosi seka.

1. Parodykite pavyzdį

Pirmąjį pakeitimą atlikau pats. Įžengiau į nepažįstamą kodų bazę, uždaviau paprastus klausimus, mokiausi, kaip veikia jos veiklos sritis ir pristatymo procesas, ir pateikiau savo darbą prižiūrinčios komandos peržiūrai.

Tai buvo svarbu, nes prašiau komandos priimti riziką. Parodydamas tokį elgesį padariau riziką matomą ir parodžiau, kad pradžioje visko nežinoti yra normalu. Peržiūros pastabas traktavome kaip sistemos pažinimo dalį, o ne įrodymą, kad žmogus neturėjo bandyti prisidėti.

2. Kitą pakeitimą atlikite poroje

Kai jau pakankamai gerai supratau kelią, dirbau poroje su vienu komandos inžinieriumi. Kartu tyrinėjome kitą sistemą: radome susijusį kodą, aiškinomės testus, paleidome ją vietinėje aplinkoje ir aptarėme pakeitimą su prižiūrėtojais.

Darbas poroje sumažino įstrigimo kainą ir sukūrė saugią erdvę klausimams dar prieš pull request tampant viešu. Tikslas nebuvo man programuoti kitam stebint. Norėjome, kad nepažįstamą darbo eigą galėtų pakartoti dar vienas žmogus.

3. Leiskite inžinieriui prisidėti savarankiškai

Kitą pakeitimą tas pats inžinierius atliko be manęs ir pats sukūrė pull request. Buvau pasirengęs padėti, jei prireiktų, tačiau atsakomybė jau buvo perėjusi jam.

Prižiūrėtojų pastabos vis dar buvo laukiamos. Sėkmės matas nebuvo pull request be komentarų. Svarbu buvo tai, ar inžinierius gali suprasti pastabas, atnaujinti pakeitimą ir nuvesti jį iki integravimo.

4. Paprašykite jo įtraukti kitą žmogų

Vėliau šis inžinierius dirbo poroje su kitu komandos nariu. Žinios nebesklido iš vieno centrinio eksperto – jos judėjo per komandą po vieną darbinį ryšį.

Kartojant šią seką, prieiga tapo gebėjimu:

Parodykite > dirbkite poroje > prisidėkite savarankiškai > išmokykite kitą.

Po kelių ciklų komanda gretimų sistemų nebelaikė svetima teritorija. Ne visi tapo kiekvienos sistemos ekspertais – ir toks nebuvo tikslas. Komanda sukaupė pakankamai bendro konteksto, kad galėtų sekti kliento rezultatą per visą kelią.

Tai investicija, o ne trumpesnis kelias

Prisidėjimo modelis nėra universalus sprendimas ir retai veikia tobulai iš pirmo karto. Pirmasis pakeitimas nepažįstamoje kodų bazėje gali užtrukti ilgiau nei užduoties parašymas. Reikia laiko paruošti aplinką, išmokti taisykles, o pirmiesiems pull request paprastai prireikia daugiau diskusijų ir pataisymų.

Kai terminas itin trumpas, šią mokymosi kainą gali būti sunku pateisinti. Jei patyręs prižiūrėtojas gali padėti iš karto, paprašyti jo atlikti vienkartinį pakeitimą gali būti greičiausias vietinis sprendimas.

Ilgalaikis skaičiavimas kitoks. Užduotis išsprendžia vieną trūkstamą galimybę. Sėkmingas prisidėjimas taip pat sukuria dar vieną žmogų, gebantį orientuotis sistemoje. Kitam pakeitimui reikia mažiau pagalbos, peržiūra tampa tikslesnė, o žinios pradeda sklisti nepriklausydamos nuo pirminio prisidėjusiojo.

Todėl šio modelio nevertinčiau pagal pirmojo pull request greitį. Vertinčiau kelių kitų pakeitimų laikotarpiu: ar eilės trumpėja, ar daugiau inžinierių gali diagnozuoti visą darbo eigą ir ar atsakomybė už rezultatą tampa mažiau suskaidyta.

Optimizuokite srautą, o ne vietinę nuosavybę

Griežtos ribos gali sukurti aiškių atsakomybių įspūdį, kartu paslėpdamos tarp komandų susidarančių eilių kainą. Kai kliento rezultatas kerta šias ribas, vietinės optimizacijos nepakanka. Geležinkelis gali optimizuoti kiekvieną stotį atskirai ir vis tiek suteikti keleiviams siaubingą kelionę.

Prisidėjimo modelis išsaugo sistemų priežiūrą, tačiau leidžia atsakomybei už rezultatą keliauti per architektūrą. Mano patirtis rodo, kad toks pokytis sutrumpino pristatymo kelią, pagerino integracijų kokybę ir suteikė inžinieriams aiškesnį supratimą apie keičiamą veiklos sritį.

Kitą kartą, kai jūsų komandą blokuos kitos komandos darbų sąrašas, nepradėkite nuo eskalavimo. Užduokite kitą klausimą:

Kas turėtų būti tiesa, kad šį pakeitimą galėtume įgyvendinti patys?