Napa Metrik Tingkat Tim Penting ing Teknik Piranti Lunak

Takeaways Key

  • Yen sampeyan peduli babagan pengaruh, kacepetan lan kualitas, mula sampeyan butuh sawetara metrik sing bisa digunakake supaya sampeyan bisa miwiti nglacak kemajuan sampeyan.
  • DORA Metrics of Deployment Frequency (DF), Lead Time for Changes (LTC), Mean Time to Recovery (MTTR), lan Change Failure Rate (CFR) minangka titik wiwitan sing migunani.
  • Metrik nelusuri ing tingkat tim ngidini tim entuk wawasan babagan kinerja lan eksperimen adhedhasar umpan balik nyata
  • Metrik uga kudu digabungake ing kabeh organisasi pangiriman
  • Metrik mung ora nyritakake kabeh – kudu kasengsem kanthi wawasan lan ati-ati

Ing jagad sing kabeh bisa duwe perspektif, konteks lan data, ora ana gunane kanggo mbatesi mung bagean saka proses pangembangan piranti lunak sampeyan. Karya departemen sampeyan ora mandheg nalika dikirim menyang git, lan ora diwiwiti nalika sampeyan entuk tiket. Saka wektu sing item karya pisanan dadi fokus, kanggo nalika geser menyang kode produksi kaya tumbler menyang solusi sing wis ana, ana akeh wilayah ngendi soko bisa tengen lan kaya akeh cara liyane sing bisa salah. Ngukur wilayah kasebut kaya liyane ing pipa sampeyan penting kanggo nggawe dandan. Kita bakal ngentekake sawetara wektu kanggo mriksa istilah lan konsep, nanging kita bakal nyilem proses pangembangan Jobber lan nemokake kepiye:

  • Nggawe proses QA luwih gampang kanthi mbangun Just-In-Time QA terpadu kanggo cabang pangembangan kita
  • Streamlined proses PR kita kanggo njaluk karya liwat persetujuan lan testing luwih cepet
  • Layanan anyar terpadu kanggo nangani kegagalan lan gangguan
  • Lan, nemokake alasan kenapa kita ora entuk wektu kanggo insinyur kanggo nyelehake sirah lan mung kerja, (spoiler, iku Rapat!), Lan kenapa ngomong karo pangembang sampeyan penting banget kaya nggunakake metrik teknik.

Standar industri sing paling umum ditampa kanggo pangukuran kasebut yaiku Four Keys sing ditetepake dening Tim DORA ing Google of Deployment Frequency (DF), Lead Time for Changes (LTC), Mean Time to Recovery (MTTR), lan Change Failure Rate (CFR). ) ). Intine, papat metrik iki ngukur sepira kerepe sampeyan masang kode menyang produksi (DF), wektu antarane karya rampung lan disebarake (LT), suwene wektu kanggo pulih saka masalah produksi serius (MTTR), lan sepira kerepe kode sing mentas didandani nyebabake masalah ing produksi (CFR). Ing abstrak, iki minangka metrik kunci ing kategori umum Impact sing sampeyan alami ing pelanggan, kacepetan sing ditindakake, lan konsistensi utawa kualitas layanan sing sampeyan kirimake. Yen sampeyan peduli babagan Dampak, Kacepetan lan Kualitas, mula sampeyan butuh sawetara metrik sing bisa digunakake supaya sampeyan bisa miwiti nglacak kemajuan sampeyan.

Ing Jobber, panyedhiya piranti lunak manajemen operasi layanan omah, kita nglacak metrik kasebut lan liya-liyane minangka departemen Pengembangan Produk kanggo mesthekake yen kita nglacak owah-owahan ing kemajuan kita kanthi cara sing bisa diukur. Dheweke mbantu tim kita dadi lincah nalika nggawe owah-owahan, lan dadi basis data sajrone eksekusi. Yen tim pengin nyoba cara anyar kanggo nyoba kewan omo, utawa proses PR anyar, kita bisa nglacak kanthi nyata ora mung kinerja sadurunge, nanging uga nggambar metrik sing padha ing kabeh departemen, ngilangi risiko gangguan departemen luwih gedhe ngrusak data kita. Banjur metrik kasebut ing tingkat taktis individu utawa tim dadi klompok, departemen lan pungkasane kabeh organisasi. Iki menehi kita kasetyan kanggo ngebor menyang lapisan apa wae sing dikarepake, saka individu nganti Jobber sacara sakabehe, lan carane kita numpuk nglawan organisasi liyane.

Metrik Four Keys ora mung siji-sijine sing dilacak, nanging mesthi penting kanggo menehi peringatan babagan data sing sampeyan kumpulake. Sawetara gangguan kasebut ing tingkat individu, klompok utawa departemen iku sifate manungsa banget, lan konteks kasebut ora bisa dihargai. Nalika ngumpulake data babagan macem-macem aspek sing bisa kita lakoni, kita uga ngerteni sisih manungsa saka metrik kasebut, lan kepiye proyek sing angel, ngalih ing misi, utawa kahanan pribadi bisa mengaruhi siji utawa luwih metrik utama kanggo individu, tim utawa malah. departemen.

Sing dikandhakake, Metrik (DORA / Four Keys lan liya-liyane) wis mbantu Jobber nggawe sawetara owah-owahan ing proses pangembangan kita; kalebu nandur modal ing pipeline CI/CD mbangun-on-demand ora mung kanggo lingkungan produksi kita nanging uga lingkungan pangembang kita, impact drastis LTC kita dening njupuk test mbangun metu kanggo stakeholder internal lan penguji menit sawise insinyur wis ngajokaken fix. Kita uga nyepetake proses review PR kanthi ngethok langkah-langkah sing dibutuhake supaya bisa ngilangi hotfix, karya anyar lan rilis utama, nyuda DF kanthi signifikan. Sawise mriksa sawetara metrik kegagalan, kita nggabungake layanan anyar kanggo ngatasi gangguan lan kedadeyan teknologi, kanthi bener nambah MTTR kita. Ayo digali luwih jero saben conto kasebut.

Nalika kita miwiti nliti metrik kanthi luwih cetha, kita nyadari yen ana sawetara dandan sing bisa ditindakake kanggo proses pangembangan kita. Khususe, nalika nyelidiki frekuensi Lead Time kanggo Ganti lan Penyebaran, kita nyadari yen langkah penting sing ana ing mburi kompetisi yaiku kemampuan kanggo ngirim kode menyang pihak internal kanthi cepet lan efisien. Kita nemokake manawa wektu ing antarane owah-owahan dadi siyap kanggo ditinjau, lan ditinjau luwih alon tinimbang perusahaan sing ukurane padha. Iki ngidini kita ndeleng luwih jero, lan kita nemokake manawa nggawe bangunan menyang pamilik produk, pemangku kepentingan, lan liya-liyane sing tanggung jawab kanggo QA luwih cepet tegese kita bisa ngencengi puteran kasebut lan nyebarake luwih cepet. Kita ngluncurake mbangun seluler Bitrise sing dikarepake kanggo kabeh PR anyar kita, lan tegese saiki mung butuh 30 menit kanggo ngirim bangunan menyang kabeh pihak sing kasengsem kanthi isi owah-owahan utawa revisi. Iki ora mung nyepetake pangembangan fitur, nanging uga duwe pengaruh sing migunani ing metrik MTTR lan CFR kanthi mung njupuk kode liwat proses review luwih cepet.

Nalika kita ndeleng metrik Wektu Mean kanggo Recovery lan Ganti Tingkat Gagal, kita uga nemokake manawa kita ora efisien ing kana kaya sing dikarepake. Kita responsif nalika nanggapi kegagalan, nanging ana ruang kanggo nambah, utamane ing komunikasi lan organisasi babagan kedadeyan. Kita nggabungake Allma minangka lapisan kolaborasi masalah ing saluran Slack, ngatur lan fokus komunikasi babagan kedadeyan. Sadurunge iku angel kanggo wong kanggo “hop-in” kanggo bantuan metu saka masalah, amarga iku biasane kasebar ing sawetara panggonan beda. Aliran Allma mbantu kita nyirnakake misconceptions lan kebingungan kasebut kanthi fokus ing diskusi babagan masalah sing aktif ing sak panggonan, ngidini akeh pihak bisa mlumpat, ngawasi, utawa menehi kontribusi kanggo ngrampungake masalah. Kaya ing kasus sadurunge, ngawasi metrik ngidini kita nemokake owah-owahan proses lan alat saliyane owah-owahan teknis utawa kerangka kerja tartamtu.

Aku pengin nggedhekake menyang masalah tartamtu sanadyan sing crept munggah ing cara tenan menarik. Nalika kita ndeleng Jellyfish, alat pangukuran teknik kita, kita ngerteni masalah dhasar: IC (kontributor individu) ora cukup coding! Kita ngukur pirang-pirang PR sing ditindakake dening insinyur lan uga “Dina Coding,” perkiraan kasar babagan sepira kerepe saben dina insinyur nggunakake kode lan bagean liyane ing dina. Kita weruh sing liwat taun, ICs kita mbuwang kurang lan kurang wektu kanggo kode lan liyane lan liyane wektu kanggo panjaluk liyane ing wektu. Solusi sing prasaja lan jelas saka “mung kode luwih” mlumpat menyang pikiran sing ora dilatih, nanging kaya masalah karo metrik utawa data, kadhangkala ana sinyal sing ngandhani apa-apa nanging ngukur bisa asring nyebabake gangguan. Cara paling apik kanggo ngatasi gangguan kasebut yaiku nggedhekake saka tampilan zoom sing asring kita deleng metrik menyang pengalaman pribadi IC sampeyan, lan kadhangkala mbutuhake obrolan sing angel.

Ndhukung obrolan kasebut kudu dadi unsur kepercayaan, utawa sampeyan ora bakal entuk konteks sing migunani. Ing Jobber, nalika kita nliti data sabisane kanggo menehi informasi babagan keputusan, kita ngerti yen paling akeh mung setengah saka persamaan, kanthi pengalaman urip sing diukur minangka separo kapindho. A Jobberino tau diukur dening data sing; iku mung digunakake kanggo kontekstualize apa kita ndeleng ing tim lan grup lan ora tau digunakake kanggo nemtokake utawa karya. Iki tegese bebarengan kita bisa ndeleng metrik ora minangka pangukuran worth wong kanggo perusahaan, nanging minangka sinyal sing bisa Petunjuk ing masalah bener. Dadi nalika kita lungguh mudhun kanggo nggawe pangertèn saka gulung ing PRs kita, Panggonan pisanan kita tindak langsung menyang sumber lan miwiti njelajah masalah langsung karo engineers kita, ndeleng apa iki tetep saka fitur bangunan karya penting lan crushing kewan omo.

Ing apa aku yakin iku ngempet menowo kanggo akeh sing maca iki, nalika kita ndudhuk menyang data lan konteks watara iku, unsurprisingly rapat-rapat ana asil. Khususé, rapat-rapat sing diselehake ing wektu sing ora cocog sing bakal ngrusak kabeh aliran teknis sing penting. Kaya sing sampeyan ngerti utawa ora ngerti, akeh masalah sing ditindakake para insinyur mbutuhake paling ora 4 jam kanggo ngrampungake. Mula, rapat-rapat sing ngrusak kabeh aliran penting asring menehi solusi kanggo ngrampungake masalah kasebut. Masalah kasebut asring paling angel dirampungake, mula sampeyan uga mbayar biaya kesempatan, amarga masalah sing paling penting yaiku sing paling angel ditindakake. Ing kasus iki, metrik sing relatif normal (jumlah wektu IC kita mbuwang coding) ing kasus iki ngubur gunung owah-owahan lan informasi sing migunani, lan saiki kita aktif ngawasi akeh wektu sing kasedhiya para insinyur, saliyane mung kira-kira ngukur wektu produktif. Kita ora bakal nemokake informasi kasebut yen ora ngukur upaya teknik, lan mesthi ora bakal duwe obrolan kontekstual sing kritis yen kita ora duwe lingkungan kepercayaan sing ngidini kita ngatasi sinyal kasebut, dudu gangguan.

Ngluwihi Four Keys uga ana macem-macem metrik sing menarik. Kita uga ngukur ora mung jumlah cacat sing dirampungake, nanging uga jumlah sing ditutup saben minggu. Utawa jumlah wektu sing ditindakake PR sadurunge ditutup (uga jumlah PR sing dideleng lan komentar babagan PR kasebut!). Kita malah ngukur kaping pirang-pirang tim lan departemen nganyari dokumentasi internal lan sumber daya wiki, kaping pirang-pirang kita nandur modal maneh menyang pangembang utawa dokumentasi liyane saben minggu. Iki pungkasane dadi: yen sampeyan ora nglacak, sampeyan ora bisa ngukur. Lan yen sampeyan ora ngukur, sampeyan ora bisa nambah. Utamane ing tingkat manajer teknik lan ngluwihi, nalika sampeyan ngapiki, ngowahi lan nyetel kabijakan, proses lan alat, sampeyan pengin duwe visibilitas kasebut menyang sukses utawa gagal owah-owahan tartamtu. Kita ora kuwatir yen OKR bakal ana ing fitur kita, lan kita kudu duwe semangat lan semangat sing padha kanggo nglacak kontribusi kanggo bisnis pangembangan. Priksa manawa sampeyan tansah njaluk boots ing pendekatan lemah sadurunge sampeyan ndeleng sawetara garis tren gaib ing data.

.

Leave a Comment

Your email address will not be published. Required fields are marked *