Matuokite naudingą pažangą

Apibrėžkite rezultatą prieš pasirinkdami rodiklį

DI įrankis gali greitai generuoti kodą. Naudingas rezultatas yra pakeitimas, kuris atitinka naudotojo poreikį ir reikalaujamą kokybės lygį. Tai skirtingi matavimai.

Sugeneruotos eilutės, priimti pasiūlymai ir agento vykdymai apibūdina veiklą. Jie gali padėti suprasti įrankio naudojimą. Jie neįrodo, kad paslauga pagerėjo ar kad komanda anksčiau atliko naudingą darbą.

Pradėkite nuo vieno klausimo. Pavyzdžiui: „Ar ši darbo eiga sumažina bendras sąnaudas, reikalingas nedidelei priežiūros užduočiai užbaigti?“ Apibrėžkite užbaigimą prieš rinkdami rezultatus. Įtraukite reikiamus testus, peržiūrą ir dokumentaciją.

Skaičiuokite visą užduotį

Apsvarstykite išgalvotą ataskaitos filtro pakeitimą. Be DI įgyvendinimas trunka 60 minučių, o peržiūra – 10 minučių. Su DI įgyvendinimas trunka 30 minučių, o peržiūra – 45 minutes.

Įgyvendinimas greitesnis. Išmatuotos šių etapų darbo sąnaudos padidėja nuo 70 iki 75 minučių. Nė vienas rezultatas neapima pasirengimo, vėlesnių taisymų ar klaidų po išleidimo. Aiškiai nurodykite šias ribas.

Šie skaičiai iliustruoja skaičiavimą. Tai nėra tyrimo rezultatai ar prognozė jūsų komandai. Ilgesnė peržiūra gali rodyti didesnį diff, nepažįstamą kodą ar trūkstamą reikalavimą. Prieš keisdami įrankių naudojimo taisykles, ištirkite priežastį.

Atskirkite darbo sąnaudas nuo praėjusio laiko

Darbo sąnaudos matuoja laiką, kurį žmonės skiria darbui. Praėjęs laikas apima ir laukimą. Agentas gali atlikti patikrinimus, kol programuotojas dirba kitą darbą. To paties žmogaus laiko neskaičiuokite du kartus. Taip pat užrašykite, kiek pakeitimas laukia peržiūros ar aplinkos.

Darbo eiga gali sumažinti darbo sąnaudas nesutrumpindama pristatymo laiko. Taip gali nutikti, kai užbaigimo datą lemia patvirtinimų eilė. Sutaupytas darbas vis tiek gali būti vertingas, tačiau organizacijai reikia atskirai nuspręsti, kaip jį panaudoti.

Paklauskite programuotojų, ar darbo eiga padeda suprasti sistemą ir išlaikyti dėmesį. Šiuos atsakymus vertinkite kaip patirties duomenis. Greičio pojūčio nepaverskite patvirtintu procentiniu pagerėjimu.

Skaitykite tyrimus atsižvelgdami į jų ribas

METR pranešė apie sulėtėjimą konkrečiame 2025 metų pradžios tyrime su patyrusiais atvirojo kodo programuotojais. Tyrimas nenustatė poveikio visiems programuotojams ar užduotims. 2026 metų vasario atnaujinime aprašyta atrankos įtaka ir matavimo problemos vėlesniame eksperimente.

Naudinga pamoka yra apie matavimą. Įrankių versijos, užduočių atranka, kokybės reikalavimai ir dalyvių elgesys gali pakeisti rezultatą. Nenaudokite vieno istorinio procento kaip nekintamos DI kūrimo taisyklės.

DORA 2025 metų tyrimas taip pat atkreipia dėmesį į organizaciją, kurioje naudojami įrankiai. Komandai reikia veiksmingos kūrimo praktikos, kad įrankio gebėjimai virstų naudingais pristatymo rezultatais.

Atlikite nedidelį pakartojamą palyginimą

Naudokite tipiškas užduotis ir vienodus užbaigimo kriterijus. Užrašykite modelio ir įrankio versijas. Įtraukite nesėkmingus bandymus ir peržiūros sąnaudas. Palyginkite kelias užduotis, o ne pasirinkite geriausią demonstraciją.

Praneškite apie rezultatų diapazoną ir pagrindinius apribojimus. Jei pakeitimas sumažina sąnaudas, bet padidina klaidų skaičių, ištirkite tai prieš plėsdami naudojimą. Jei rezultatai nevienodi, rekomendaciją apribokite tomis užduočių rūšimis, apie kurias turite naudingų įrodymų.

Geras matavimas padeda priimti konkretų kitą sprendimą. Jam nereikia įrodyti, kad DI visuotinai geras ar blogas.