AWS apie DI komandas: 4,5 karto daugiau našumo nėra magija

·


AWS frontier teams DI komandos ir agentinis kūrimas

DI komandos skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?

AWS rašo, kad pažangios komandos ne tik naudoja DI kodui rašyti greičiau. Jos perkuria patį programinės įrangos kūrimo būdą. Minimas 4,5 karto našumo augimas, kai kur – dar daugiau.

Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?

KAS NUTIKO

Pagrindinė mintis: agentai, automatizuotos patikros, mažesni darbo vienetai ir greitesnis grįžtamasis ryšys leidžia komandoms dirbti kitaip, o ne tik greičiau spausti tą patį procesą.

Čia kaip sporte. Jei žmogus pradeda greičiau bėgti bloga technika, jis ne sportininkas, o būsimas pacientas. Su DI komandomis panašiai: greitis be proceso greitai tampa chaosu.

KODĖL TAI SVARBU

DI komandos svarbios todėl, kad agentai keičia darbo paskirstymą. Žmogus vis daugiau sprendžia, tikrina ir projektuoja, o agentas daro daugiau vykdymo.

DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.

KĄ TAI REIŠKIA VERSLUI

Vadovams čia yra labai praktinė žinutė: vien nupirkti įrankį nepakanka. Reikia keisti užduočių dydį, kokybės vartus, review ritmą ir komandų mokymąsi.

  • skaidyti darbus į mažesnes patikrinamas užduotis
  • automatizuoti testus ir kokybės vartus
  • mokyti komandą formuluoti užduotis agentams
  • matuoti ciklo laiką nuo idėjos iki veikiančio rezultato

Pirmas žingsnis: viename projekte įveskite taisyklę, kad kiekvienas DI paruoštas pakeitimas turi turėti testą arba aiškų patikros būdą.

KUR PASISLĖPUSI RIZIKA

Rizika – skaičių 4,5 karto paversti pažadu. Kitoje įmonėje rezultatas priklausys nuo kultūros, duomenų, testų ir disciplinos.

Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.

KĄ PASIDARYTI ŠIĄ SAVAITĘ

Peržiūrėkite vieną kūrimo procesą ir pažymėkite, kur komanda laukia žmogaus, kur laukia testų, o kur tiesiog trūksta aiškios užduoties.

Šaltinis: Amazon Web Services.

DUK

Ką reiškia DI-native kūrimas?

Tai darbas, kai agentai ir automatizacija tampa įprasta kūrimo proceso dalimi.

Ar našumas visada auga 4,5 karto?

Ne. Tai priklauso nuo proceso brandos, testų ir komandos įgūdžių.

Ką verta kopijuoti pirmiausia?

Mažus darbo vienetus, automatines patikras ir aiškius kokybės vartus.

Jei norite DI naudoti ne dėl mados, pradėkite nuo vieno proceso. Paimkite užduotį, kuri kartojasi kas savaitę, susirašykite žingsnius ir tik tada junkite įrankį. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.