Sayangnya, kami tidak hidup di dunia yang ideal di mana setiap pengembang memiliki tingkat produktivitas yang ideal dan seimbang, sambil berfokus pada tugas dan memikirkannya dari satu ke yang lain. Kolaborasi tim juga tidak selalu dirancang sehingga semua anggota tim bekerja dengan efisiensi maksimum. Seperti halnya banyak masalah pada umumnya, pengembangan awal dalam tim pengembangan menghemat sumber daya, membuat gugup, dan menciptakan suasana kerja yang baik.
Dalam tim kecil, pemimpin tim dapat mencoba menilai segala sesuatu yang terjadi atas dasar perasaan subjektif, tetapi semakin besar perusahaan, semakin penting menggunakan data dan metrik objektif.
Alexander Kiselev (
AleksandrKiselev ) dan
Sergey Semenov dalam laporan mereka di
TeamLead Conf menunjukkan cara menggunakan data yang telah Anda kumpulkan, di mana mendapatkan data tambahan, dan bersama-sama mereka dapat membantu mengidentifikasi masalah yang tidak jelas. Dan bahkan, setelah mengumpulkan pengalaman banyak rekan, mereka mengusulkan solusi.
Tentang para pembicara: Alexander Kiselev dan Sergey Semenov, kami telah berada di IT selama lebih dari 8 tahun. Keduanya beralih dari pengembang ke pemimpin tim dan lebih jauh ke manajer produk. Sekarang mereka bekerja pada layanan analitik GitLean, yang secara otomatis mengumpulkan analisis dari tim pengembangan untuk arahan tim dan CTO. Tujuan dari layanan ini adalah manajer teknis dapat membuat keputusan berdasarkan data objektif.
Pernyataan masalah
Kami berdua bekerja sebagai pemimpin tim dan sering menghadapi masalah ketidakpastian dan ambiguitas dalam pekerjaan kami.
Akibatnya, seringkali perlu untuk membuat keputusan secara membabi buta, dan kadang-kadang tidak jelas apakah itu lebih baik atau lebih buruk. Oleh karena itu, kami melihat solusi yang ada di pasar, memeriksa metodologi untuk mengevaluasi kinerja pengembang, dan menyadari bahwa tidak ada layanan yang akan memenuhi kebutuhan kami. Karena itu,
kami memutuskan untuk membuatnya sendiri .
Hari ini kita akan berbicara tentang apa yang dapat Anda katakan pada data yang telah Anda kumpulkan, tetapi kemungkinan besar tidak menggunakannya.
Ini diperlukan dalam dua kasus utama.
Tinjauan kinerja adalah proses yang agak rumit dan subyektif. Akan sangat bagus untuk mengumpulkan fakta tentang pekerjaan pengembang secara otomatis.
Kami berbicara dengan perwakilan perusahaan Jerman besar dengan staf pengembangan besar. Kira-kira setahun sekali mereka menghentikan seluruh pekerjaan pengembangan selama 2 minggu, dan hanya seluruh perusahaan melakukan tinjauan kinerja - para pengembang menulis penolakan anonim sepanjang hari kepada rekan kerja yang bekerja bersama mereka selama setahun. Jika perusahaan ini memiliki kesempatan untuk mengumpulkan fakta secara otomatis, mereka akan menghemat banyak waktu.
Aspek kedua adalah
memantau situasi saat ini di tim. Saya ingin cepat memahami masalah yang muncul, dan cepat menanggapinya.
Opsi keputusan
Mungkin ada beberapa solusi.
Pertama, Anda
tidak dapat
menggunakan analitik sama sekali , tetapi hanya penilaian subjektif Anda. Ini berfungsi jika Anda adalah pemimpin tim dalam tim kecil. Tetapi jika Anda sudah menjadi CTO, dan Anda memiliki banyak tim, maka Anda tidak akan dapat menggunakan penilaian subjektif Anda, karena Anda tidak tahu segalanya. Anda harus menggunakan penilaian subyektif timlids Anda, dan ini merupakan masalah, karena sering timlids mendekati penilaian subyektif dengan sangat berbeda.
Ini adalah hal selanjutnya yang harus dilakukan. Karena penilaian subjektif seringkali tidak cukup, Anda bisa bingung dan
mengumpulkan fakta dengan tangan .
Sebagai contoh, satu CTO dengan siapa kami berbicara entah bagaimana mencurigai tim bahwa mereka melakukan review kode terlalu lambat, tetapi tidak ada yang mempresentasikannya. Karena dia hanya memiliki perasaan yang samar, dia memutuskan untuk mengumpulkan fakta, hanya beberapa minggu untuk menonton tim. CTO mencatat waktu yang dibutuhkan tim untuk meninjau, dan apa yang dia temukan pada akhirnya mengejutkannya. Ternyata 2 senior telah berkonflik untuk waktu yang lama dalam review kode, sementara mereka tidak mengeluarkannya sama sekali. Mereka duduk seperti tikus, tidak ada yang berteriak pada siapa pun - tim tidak tahu sama sekali. Satu-satunya hal yang mereka lakukan adalah secara berkala pergi ke pendingin, menuangkan air lagi untuk diri mereka sendiri dan berlari untuk menulis jawaban cerdas dalam ulasan kode kepada musuh mereka dalam permintaan tarik.
Ketika CTO mengetahui, ternyata masalahnya sudah sangat tua sehingga tidak mungkin melakukan apa-apa, dan pada akhirnya salah satu programmer harus dipecat.
Statistik Jira adalah opsi yang sering digunakan. Ini adalah alat yang sangat berguna di mana ada informasi tentang tugas, tetapi tingkatannya cukup tinggi. Seringkali sulit untuk memahami apa yang terjadi dalam tim secara khusus.
Contoh sederhana - pengembang dalam sprint sebelumnya melakukan 5 tugas, yang ini - 10. Apakah mungkin untuk mengatakan bahwa ia mulai bekerja lebih baik? Itu tidak mungkin, karena tugasnya sangat berbeda.
Solusi terakhir yang ada adalah dengan hanya menyingsingkan lengan baju Anda dan menulis
skrip Anda sendiri untuk pengumpulan data otomatis . Ini adalah cara semua CTO di perusahaan besar lebih atau kurang datang. Dia adalah yang paling produktif, tetapi, tentu saja, yang paling sulit. Ini tentang dia yang akan kita bicarakan hari ini.
Solusi yang dipilih
Jadi, solusi yang dipilih adalah untuk memotong skrip Anda untuk mengumpulkan analitik. Pertanyaan utama adalah di mana mendapatkan data dan apa yang diukur.
Sumber data
Sumber data utama di mana informasi tentang pekerjaan pengembang diakumulasikan adalah:
- Git - entitas utama: komit, cabang dan kode di dalamnya.
- Alat ulasan kode - layanan hosting git yang ulasan kode host menampung informasi tentang permintaan-tarik yang dapat digunakan.
- Pelacak tugas - informasi tentang tugas dan siklus hidupnya.
Sumber data tambahan:
- Utusan - di sana Anda dapat, misalnya, melakukan analisis sentimen, menghitung waktu respons rata-rata pengembang terhadap permintaan informasi.
- Layanan CI yang menyimpan informasi tentang pembuatan dan rilis.
- Jajak pendapat tim.
Karena semua sumber yang saya bicarakan di atas kurang lebih standar, dan yang terakhir tidak terlalu standar, saya akan membicarakannya sedikit lebih banyak.
CTO lain membagikan metode ini kepada kami. Pada akhir setiap iterasi, ia mengirim tim jajak pendapat secara otomatis, di mana hanya ada 2 pertanyaan:
- Menurut Anda, seberapa pentingkah apa yang kami lakukan dalam iterasi ini?
- Apakah menurut Anda apa yang kami lakukan menarik?
Ini adalah cara yang cukup murah untuk mengukur suasana hati dalam tim dan, mungkin, menangkap beberapa masalah dengan motivasi.
Apa dan bagaimana mengukur
Pertama-tama, kita akan membahas metodologi pengukuran. Metrik yang baik harus menjawab 3 pertanyaan:
- Apakah ini penting? Anda hanya perlu mengukur sinyal apa tentang sesuatu yang signifikan bagi perusahaan.
- Apakah sudah semakin buruk / lebih baik / sama? Dengan metrik, harus jelas apakah itu menjadi lebih baik atau lebih buruk.
- Apa yang harus dilakukan Dari metrik, harus jelas apa yang harus dilakukan untuk memperbaiki situasi.
Secara umum, ada baiknya mengikuti prinsip:
Ukur apa yang Anda inginkan dan dapat berubah.
Perlu disebutkan segera bahwa tidak ada metrik universal, dan kami tidak akan berbicara tentang metrik universal hari ini karena alasan berikut:
- Pengembang memiliki banyak aspek kegiatan - ia bekerja dengan persyaratan, menulis kode, menguji, melakukan tinjauan kode, membuat penyebaran - dan tidak mungkin untuk memasukkan semua ini ke dalam metrik universal tunggal. Karena itu, lebih baik fokus pada kasus-kasus individual yang dapat dideteksi.
- Alasan kedua mengapa satu-satunya metrik tidak layak dilakukan adalah bahwa satu metrik mudah digunakan, karena pengembangnya adalah orang-orang yang cukup pintar dan mereka akan mencari cara melakukannya sendiri.
Pendekatan baru
Oleh karena itu, kami telah merumuskan pendekatan di mana kami pergi dari masalah: kami mencoba mengidentifikasi masalah tertentu dan memilih serangkaian metrik untuk mereka yang akan mendeteksi mereka. Pengembang yang baik akan disebut pengembang dengan jumlah masalah paling sedikit.
Berdasarkan apa pilihan masalah kita? Sederhana: kami melakukan wawancara dengan 37 CTO dan pemimpin tim yang berbicara tentang masalah yang mereka miliki di tim mereka, dan bagaimana mereka memecahkan masalah ini.
Daftar besar yang dihasilkan, kami memprioritaskan dan mengumpulkan peretasan dan metrik kehidupan untuk masalah ini. Kami membagi semua masalah menjadi 2 kelompok:
- Masalah pengembang individu (pengembang bertanggung jawab atas masalah ini).
- Masalah tim. Tim bertanggung jawab atas masalah ini, sehingga untuk menyelesaikannya, Anda perlu bekerja dengan tim secara keseluruhan dan mengubah solusi proses.
Mari kita bahas secara terperinci setiap masalah, kunci mana dari metrik yang dapat dipilih. Mari kita mulai dengan masalah paling sederhana dan perlahan-lahan bergerak di sepanjang gradien kompleksitas ke yang paling sulit untuk diukur.
Masalah Pengembang
Kinerja pengembang kecil
Selain itu, "kinerja kecil" biasanya berarti bahwa
pengembang hampir tidak melakukan apa-apa . Dengan syarat, sebuah tiket digantung di Jira, entah bagaimana melaporkannya, tapi benar-benar tidak ada pekerjaan yang terjadi. Jelas bahwa masalah ini akan muncul cepat atau lambat, Anda akan menemukannya, tetapi akan keren untuk melakukannya secara otomatis.
Bagaimana ini bisa diukur?Hal pertama yang terlintas dalam pikiran adalah hanya untuk melihat
jumlah hari aktif dengan pengembang. Hari aktif akan disebut hari ketika pengembang membuat setidaknya satu komit. Untuk pengembang penuh waktu, pada kenyataannya, jumlah karakteristik hari aktif per minggu setidaknya 3. Jika kurang, maka kami mulai mencurigai pengembang bahwa ia tidak akan melakukan banyak.
Jelas, jumlah hari aktif saja tidak cukup. Pengembang hanya dapat menulis kode dan tidak melakukan itu - menulis, menulis, dan kemudian suatu hari melakukan banyak kode.
Oleh karena itu, batasan berikutnya yang kami berikan adalah bahwa pengembang juga harus memiliki
sedikit kode . Bagaimana menentukan ambang "kode kecil"? Kami menyarankan Anda untuk membuatnya cukup kecil sehingga siapa pun, sebanyak pengembang yang berkinerja baik, dapat dengan mudah mengatasinya. Misalnya, dalam layanan kami untuk JS ini ada sekitar 150 baris kode, dan untuk Clojure - 100 baris kode.
Mengapa ambang kecil seperti itu? Idenya adalah bahwa kami ingin memisahkan bukan pengembang yang bekerja keren dari pengembang yang bekerja rata-rata, tetapi mereka yang hampir tidak melakukan apa-apa, dari mereka yang melakukan setidaknya sejumlah pekerjaan yang waras.
Tetapi bahkan jika pengembang memiliki beberapa hari aktif dan sedikit kode, ini tidak berarti sama sekali bahwa ia tidak berfungsi. Dia bisa, misalnya, membuat perbaikan bug yang memerlukan sejumlah kecil kode. Akibatnya, seseorang tampaknya telah melakukan banyak tugas, tetapi ia mungkin memiliki beberapa kode dan hari aktif. Artinya, kami memperhitungkan
jumlah tugas .
Hal berikutnya yang patut diperhatikan adalah
jumlah ulasan kode yang dia lakukan, karena seseorang tidak dapat melakukan tugas dan tidak menulis kode, tetapi sepenuhnya tenggelam dalam ulasan kode. Itu terjadi.
Karena itu, jika untuk semua metrik ini - dan hanya itu! - pengembang tidak mencapai ambang batas apa pun, Anda dapat mencurigainya tidak berperforma baik.
Apa yang harus dilakukan?Pertama, jika Anda mengetahui alasan yang sah, maka Anda tidak perlu melakukan apa pun - misalnya, pengembang dilatih atau libur. Jika Anda tidak tahu alasan yang sah, maka mungkin ada baiknya
berbicara dengan seseorang. Jika alasan yang sah tidak muncul, maka ada baiknya untuk memantaunya lebih lanjut, dan jika masalah ini terus berulang kadang-kadang, maka mungkin ada baiknya mengucapkan selamat tinggal kepada pengembang seperti itu.
Ini adalah masalah paling sederhana dan paling provokatif. Mari kita beralih ke yang lebih berat.
Pengembang daur ulang
Ini juga merupakan cerita umum. Jika seseorang mengolahnya, ia terbakar, akhirnya kehilangan motivasi dan, sebagai hasilnya, dapat meninggalkan perusahaan. Salah satu manajer teknis yang berbicara dengan kami menceritakan kisah seperti itu. Dia bekerja untuk sebuah perusahaan Amerika di mana budaya unjuk rasa dikembangkan dengan liar. Akibatnya, semua pengembang, ketika mereka mulai bekerja, hanya melakukan apa yang mereka rally, dan mereka menulis kode setelah berjam-jam dan pada akhir pekan. Akibatnya, omset tahunan pengembang di perusahaan mencapai 30%, meskipun norma industri adalah 6%.
Akibatnya, semua manajemen teknis yang terdiri dari 30 orang diberhentikan dari kantor ini. Agar tidak membahas hal ini, saya ingin menemukan masalah ini tepat waktu.
Bagaimana ini bisa diukur?Bahkan, tidak ada yang terlalu rumit - mari kita lihat
jumlah kode yang ditulis pengembang setelah jam. Jika jumlah kode ini sebanding secara kondisional atau lebih besar dari yang dilakukannya selama jam kerja, maka pengembang secara eksplisit memprosesnya.
Jelas, pengembang tidak hidup sebagai kode tunggal. Masalah umum adalah bahwa ada cukup waktu untuk kode - pekerjaan utama - tetapi tidak lagi untuk tinjauan kode. Akibatnya, tinjauan kode dilakukan pada malam hari atau akhir pekan. Ini dapat dilacak hanya dengan
jumlah komentar di tarik-permintaan setelah
jam .
Pemicu eksplisit terakhir adalah sejumlah
besar tugas paralel . Ada beberapa batasan wajar 3-4 tugas untuk pengembang. Anda dapat melacaknya dengan git atau oleh Jira - sesuai keinginan. Ini bekerja dengan cukup baik.
Apa yang harus dilakukan?Jika Anda menemukan pengembang daur ulang, Anda harus terlebih dahulu
memeriksa kalendernya untuk melihat apakah ia kelebihan beban dengan demonstrasi yang tidak berguna. Jika kelebihan beban, disarankan untuk menguranginya, dan idealnya membuat hari pertemuan - hari yang didedikasikan ketika pengembang akan memusatkan sebagian besar pertemuan terlama sehingga ia dapat bekerja secara normal di hari-hari lain.
Jika ini tidak berhasil, perlu untuk
mendistribusikan kembali beban . Ini sebenarnya pertanyaan yang agak rumit - bagaimana melakukannya. Ada banyak cara berbeda. Kami tidak akan masuk terlalu dalam, tetapi perhatikan
laporan keren tentang HighLoad 2017 dari Anton Potapov, di mana topik ini sangat dipertimbangkan.
Pengembang tidak memiliki fokus pada pelepasan tugas
Saya ingin memahami berapa banyak pengembang seperti itu di tim Anda dan berapa biaya dalam waktu.
Ini adalah situasi yang cukup umum bahwa pengembang mengambil tugas, membawanya ke status dalam tinjauan, pengujian - dan lupa tentangnya. Kemudian dia kembali untuk revisi dan hang di sana tidak jelas berapa banyak waktu. Saya sendiri punya pengembang di tim saya sekaligus. Saya meremehkan masalah ini untuk waktu yang lama, sampai sekali saya menghitung jumlah waktu itu, rata-rata, membutuhkan berbagai downtime. Akibatnya, ternyata tugas pengembang ini, rata-rata, menganggur 60% dari waktu rilis.
Bagaimana ini bisa diukur?Pertama, Anda perlu mengukur semua waktu henti yang bergantung pada pengembang. Ini adalah waktu untuk memperbaiki
setelah peninjauan dan pengujian kode . Jika Anda memiliki pengiriman berkelanjutan, ini adalah
waktu tunggu rilis. Pembatasan yang wajar harus diberlakukan pada masing-masing waktu - seperti tidak lebih dari sehari.
Alasannya adalah sebagai berikut. Ketika seorang pengembang datang untuk bekerja di pagi hari, akan keren baginya untuk terlebih dahulu menganalisis tugas-tugas prioritas tertinggi. Tugas dengan prioritas tertinggi, jika tidak ada perbaikan bug atau sesuatu yang sangat penting, adalah tugas yang paling dekat dengan rilis dan rilis.
Pemicu keren lainnya pada topik ini adalah
jumlah ulasan kode yang tergantung pada pengembang, seperti pada pengulas. Jika seseorang lupa tentang tugasnya, maka kemungkinan besar dia juga akan berhubungan dengan tugas rekan-rekannya.
Apa yang harus dilakukan?Jika Anda menemukan pengembang seperti itu, jelas bermanfaat untuk menghampirinya dan
berkata : "Lihat, 30-40% dari waktu Anda dihabiskan untuk downtime!" Ini biasanya bekerja sangat keren. Dalam kasus saya, misalnya, itu memiliki efek seperti itu, bahwa masalahnya hampir sepenuhnya hilang, jika tidak, Anda perlu terus
memantau , katakan secara berkala, tetapi hal utama di sini adalah tidak jatuh ke manajemen mikro, karena itu akan menjadi lebih buruk.
Oleh karena itu, jika memungkinkan, ada baiknya untuk segera berurusan dengan solusi proses. Ini dapat, misalnya,
membatasi jumlah tugas aktif , atau, jika anggaran dan waktu Anda memungkinkan, Anda dapat menulis bot atau menggunakan layanan yang akan secara otomatis melakukan
ping ke pengembang jika tugas tersebut sudah dalam status tertentu terlalu lama. Ini mungkin solusi paling keren di sini.
Pengembang tidak memikirkan cukup tugas
Saya pikir Anda tahu gejalanya - ini adalah perkiraan yang tidak bisa dipahami dari waktu yang dibutuhkan untuk menyelesaikan tugas yang tidak kami ikuti, tenggat waktu yang panjang pada akhirnya, peningkatan jumlah bug dalam tugas - secara umum, tidak ada yang baik.
Bagaimana ini bisa diukur?Saya pikir Anda tahu gejalanya - ini adalah perkiraan yang tidak bisa dipahami dari waktu yang dibutuhkan untuk menyelesaikan tugas yang tidak kami ikuti, tenggat waktu yang panjang pada akhirnya, peningkatan jumlah bug dalam tugas - secara umum, tidak ada yang baik.
Bagaimana ini bisa diukur?Untuk melakukan ini, kita perlu memperkenalkan 2 metrik, yang pertama adalah kode Churn.
Churn adalah ukuran seberapa banyak kode yang ditulis oleh pengembang dengan sia-sia.
Bayangkan situasinya. Pada hari Senin, pengembang mulai melakukan tugas baru, dan menulis 100 baris kode. Kemudian datang pada hari Selasa, dia menulis 100 baris kode baru dalam tugas ini. Tetapi, sayangnya, kebetulan bahwa 50 baris kode yang ditulis pada hari Senin, ia menghapus, dan melepaskan tugas. Akibatnya, 200 baris kode tampaknya dibuat dalam tugas, tetapi hanya 150 yang selamat sampai rilis, dan 50 ditulis dengan sia-sia. 50 ini kita sebut Churn. Jadi dalam contoh ini, pengembang Churn adalah 25%.
Menurut pendapat kami,
tingkat tinggi Churn adalah pemicu keren bahwa pengembang tidak memikirkan tugas.
Ada sebuah studi oleh perusahaan Amerika di mana mereka mengukur tingkat Churn dari 20.000 pengembang dan sampai pada kesimpulan bahwa kode Churn yang baik harus berada di kisaran 10-20%.
Tetapi ada 2 kondisi penting:
- High Churn baik-baik saja jika, misalnya, Anda membuat prototipe atau proyek baru. Maka bisa sama dengan 50-60% selama beberapa bulan. Tidak ada yang perlu dikhawatirkan. Secara kasar, Churn tergantung pada tahap produk - semakin stabil produk, semakin rendah seharusnya.
- Dalam kasus apa pun Anda harus berusaha untuk tingkat Churn nol - ini adalah perfeksionisme yang benar-benar berarti. Tidak perlu memaksa pengembang untuk menulis kode yang sempurna dari awal. Mereka akan menghabiskan banyak waktu untuk memikirkan atau mencoba untuk meretas cerita ini. Akibatnya, waktu pengiriman hanya akan meningkat.
, , , , Fixed Tasks,
. , .
, bug fixes , bug fixes . bug fixes 3 , , . , , , .
—
. , , , - .
?, , ,
. , ,
, estimation ..
CTO, , workflow, , . , , ,
- , .
Churn Fixed Tasks, , :
- commit message, . commit message, , git .
- git-squash commit' , Churn .
- git. merge master, merge , . — , , Churn Fixed Tasks.
, —
, . , , , . , - .
, , - 3-4 . , .
?— - , , .
, 3 , , ( ), .
, , . — , .
— ,
— — , , .
?. , , . - , .
— , , . . , , . .
30-50 50-60 %. , .
, , . , , , .
.
, —
. product- , . , , .
?product- , ?
, product- , :
- Churn, ;
- , , estimation;
- in progress product-.
?product- : «, Churn - — ».
« » , 1-2 . , product-, .
. , , .
, , , . , , - , , . , . .
?, , :
?-, , ,
, .
-, , , ,
, , .
— - , . best practise, , , , . 3 , 3 .
, —
. , . - , , -. , , CTO, , 100%. , - .
?,
legacy refactoring . , . . , , , .
,
legacy refactoring , ,
complexity , , .
?, , . , CTO. , .
CTO , , Jira
«» . , - estimation . , — , ..
CTO . , , ,
«Hack». - -, : « Hack — », . grep' «Hack» , .
. .
:
- Beberapa hal masih tidak mudah diukur. Ini berlaku, misalnya, untuk Churn atau refactoring lama. Diperlukan waktu untuk mempelajari cara menghitungnya.
- Data perlu dibersihkan dan sedikit disesuaikan dengan perintah. Misalnya, hal biasa yang akan Anda temui jika Anda mencoba menerapkan ini - di git Anda akan melihat bahwa beberapa akun git berhubungan dengan orang yang sama. Anda harus mempertimbangkan keduanya - ini adalah contoh sepele dari pembersihan data yang perlu dilakukan.
- Anda perlu memantau nilai ambang batas dan memilihnya dengan bijak, karena mereka bergantung pada tahap kehidupan perusahaan dan juga jenis perusahaan. Apa yang baik untuk agen outsourcing mungkin tidak terlalu baik untuk perusahaan grosir.
- Sebagian besar metrik yang kami cantumkan di sini hanya berfungsi untuk pengembang multi waktu, karena hanya aktivitas pengembang multi waktu yang tercermin dengan baik dalam sumber data yang tersedia: git, Jira, GitHub, pesan instan, dll.
Kesimpulan
Kami ingin menyampaikan kepada Anda hal-hal berikut:
- Pengembang dan tim dapat dan harus diukur . Ini bisa sulit, tetapi bisa dilakukan.
- Tidak ada set kecil KPI universal . Untuk setiap masalah, Anda perlu memilih set metrik khusus Anda. Harus diingat bahwa Anda tidak boleh mengabaikan metrik yang paling sederhana sekalipun. Bersama-sama mereka bisa bekerja dengan baik.
- Git dapat menceritakan banyak hal menarik tentang pengembangan dan pengembang, tetapi Anda harus mengikuti praktik tertentu sehingga data dapat diakses dengan mudah darinya, termasuk:
- jumlah tugas dalam komit;
- tidak ada squash;
- Anda dapat menentukan waktu rilis: menggabungkan master, tag.
Tautan dan kontak yang berguna:- Ada beberapa masalah bonus dan metrik untuk mereka dalam presentasi presentasi .
- Penulis blog dengan artikel bermanfaat untuk manajer pengembangan
- Kontak Telegram: @avkiselev (Alexander Kiselev) dan sss0791 (Sergey Semenov).
Di TeamLead Conf, mereka membahas banyak masalah berbeda dalam mengelola tim pengembangan dan mencari solusi. Jika Anda sudah berjalan sebagian, mengisi lebih dari satu tonjolan, menginjak penggaruk, mencoba berbagai pendekatan dan siap untuk menarik kesimpulan dan berbagi pengalaman Anda - kami menunggu Anda. Anda dapat melamar pertunjukan hingga 10 Agustus .
Para peserta juga diharapkan untuk lebih terlibat, mulai dengan memesan tiket , dan kemudian mencoba merumuskan apa yang paling menggairahkan Anda - kemudian Anda dapat mendiskusikan rasa sakit Anda dan mendapatkan hasil maksimal dari konferensi.