Get best of the week

Mengapa pengembang sangat lambat: masalah umum dan solusinya

Halo, Habr! Saya mempersembahkan kepada Anda terjemahan artikel Mengapa Tim Pengembangan Lambat: Kemacetan dan Solusi Perangkat Lunak Umum oleh Eric Elliot.



Jika Anda lebih suka mendengarkan daripada membaca, maka dalam format audio, terjemahan tersedia di Yandex.Music dan Apple Podcasts.

Mari kita lihat apa yang menyebabkan gangguan dalam proses pengembangan perangkat lunak, dan apa yang dapat Anda sebagai manajer lakukan tentang hal itu. Mungkin ada banyak alasan, jadi daftar kami, tentu saja, masih jauh dari lengkap. Sebagai gantinya, kami akan fokus pada beberapa masalah yang paling umum :

  • Harapan yang tidak realistis
  • Terlalu banyak tiket terbuka
  • Lingkup tugas yang tidak terkendali
  • Ulasan kode akumulasi
  • Persiapan yang buruk
  • Pengembang burnout
  • Bug
  • Pergantian staf

Perkembangan yang lambat bukanlah akar masalahnya. Ini adalah gejala dari masalah lain yang tercantum. Dalam 100% kasus, jika tim pengembangan bekerja terlalu lambat, itu adalah kesalahan pemimpin. Tapi kabar baiknya adalah Anda bisa memperbaikinya. Mari kita lihat masing-masing item secara lebih terperinci untuk memahami apa yang dapat kita lakukan dengan masing-masing item.

Harapan yang tidak realistis


Sebagian besar masalah dengan produktivitas pengembang umumnya tidak mempengaruhi pengembangan itu sendiri. Ini lebih merupakan masalah persepsi kita tentang proses pengembangan sebagai manajer dan pemangku kepentingan.

Bagian tersulit dari pekerjaan seorang pemimpin adalah memahami bahwa menulis kode membutuhkan waktu sebanyak yang diperlukan dan mencoba mempercepat proses ini hanya akan memperlambatnya dan menambah jumlah bug. Kesabaran adalah segalanya bagi kita.

Paling sering, masalah dengan kecepatan kerja bukanlah bahwa tim tidak cukup produktif, tetapi menghadapi harapan yang tinggi. Dan ini sepenuhnya tanggung jawab Anda. Jika tekanan datang dari kepemimpinan yang lebih tinggi, maka Anda belum membentuk visi yang benar tentang situasi. Jika ada tekanan dari Anda, baca terus.

Kita sering lupa bahwa perangkat lunak yang kita buat adalah sesuatu yang pada dasarnya baru. Jika Anda sudah memiliki perangkat lunak yang melakukan hal yang sama, beli, gunakan, impor modul, dll. Tidak perlu menulis ulang dari awal. Perangkat lunak baru ini unik. Dia melakukan sesuatu yang baru atau melakukan sesuatu yang berbeda. Saat itulah kita membuatnya. Dan karena kita belum melakukan ini, bagaimana kita tahu berapa lama?

Pembangun membangun dinding prefabrikasi dengan kecepatan yang sama, dan karenanya dapat memberikan perkiraan yang lebih atau kurang akurat berdasarkan pengamatan. Pengembang perangkat lunak tidak memiliki data yang dapat diandalkan untuk diandalkan. Masalah ini diperburuk oleh kecepatan yang berbeda dari pengembang yang berbeda, dan dapat bervariasi berdasarkan urutan besarnya.

Seperti Steve McConnell, penulis The Perfect Code, menulis: “Kesimpulan bahwa ada perbedaan yang signifikan antara produktivitas programmer berbeda telah dikonfirmasi oleh banyak penelitian oleh pengembang profesional (Curtis 1981, Mills 1983, DeMarco dan Lister 1985, Curtis et al. 1986, Card 1987 , Boehm dan Papaccio 1988, Valett dan McGarry 1989, Boehm et al. 2000). Kami tidak memiliki cukup data untuk memprediksi berapa lama waktu yang dibutuhkan untuk menyelesaikan proyek kami. Kami akan mencari tahu apa skala dan kompleksitas sudah mulai bekerja dan proses ini sering penuh dengan banyak kejutan. "Pembangunan tidak hanya perencanaan, tetapi juga penelitian, tidak peduli seberapa hati-hati kami mencoba untuk meramalkan segalanya."
« 90 10 , . 10 90 »
— , Bell Labs

Ada beberapa alasan untuk harapan tinggi yang dapat dikontrol manajer. Salah satu alasan mendasar adalah mengukur hal-hal yang salah.
Anda mungkin akrab dengan pepatah terkenal Peter Drucker: "Apa yang diukur dikendalikan."

Dan tentu saja ini saran yang bagus. Tentu saja kita harus mengukur! Tapi kami kehilangan esensi dari kutipan ini, apalagi, kami membalik maknanya.

Seluruh ide adalah: "Apa yang diukur dikendalikan, bahkan jika itu diukur dan berusaha mengendalikan sama sekali tidak berguna, bahkan jika itu merusak tujuan organisasi."

Dua contoh hal yang tidak layak diukur:

  1. Grafik burndown prediktif yang menunjukkan grafik jumlah tiket terbuka yang memprediksi tanggal akhir proyek berdasarkan pengukuran kecepatan kerja terkini;
  2. Jumlah tiket yang ditutup oleh pengembang, menunjukkan berapa banyak tugas yang diselesaikan oleh masing-masing pengembang.

Mengukur kedua hal ini biaya perusahaan yang tak terhitung jumlahnya kerugian besar karena hilangnya produktivitas, karyawan, dan biaya lainnya.

Diagram kemajuan tugas


Banyak perangkat lunak mencoba memprediksi tanggal penyelesaian proyek, berdasarkan skala tugas saat ini dan kecepatan pekerjaan. Masalahnya adalah bahwa tidak satu pun dari mereka memperhitungkan volume tugas yang belum dijelajahi. Selain itu, ini tidak mungkin, karena waktu yang diperlukan untuk menutup satu tugas dapat bervariasi berdasarkan urutan besarnya untuk tugas yang berbeda, yang secara signifikan dapat mendistorsi nilai rata-rata yang dihitung untuk tiket yang sudah ditutup.

Jika Anda menetapkan batas waktu berdasarkan tanggal dari grafik, maka pertimbangkan bahwa Anda belum memenuhi tenggat waktu. Satu-satunya hal yang dapat menyelamatkan Anda adalah membuang sebanyak mungkin tugas di luar jangkauan di masa depan.

Ketika Anda mendasarkan nilai Anda pada informasi yang tidak lengkap, Anda dan tim Anda pasti akan membayarnya. Perkiraan yang tidak realistis menciptakan harapan yang tidak realistis. Ini bisa menjadi bencana nyata jika Anda juga berbagi peringkat ini dengan tim pemasaran, pelanggan, dan pers.

Tidak semua bagan itu jahat. Mereka yang tidak mencoba memprediksi masa depan mungkin berguna. Mereka dapat memperingatkan kita tentang penyebaran proyek dan ledakan kombinatorial ketika Anda melihat bahwa jumlah tiket meningkat bukannya menurun atau bergerak naik dan turun. Diagram tugas yang berguna menunjukkan tugas yang sudah ditutup secara realistis, daripada mencoba untuk memprediksi masa depan.

Indikator yang baik adalah kurva yang mengalami pasang surut, tetapi secara keseluruhan ia bergerak turun, yang menunjukkan penurunan jumlah tugas terbuka pada akhir proyek.

Jadwal proyek di mana jumlah tiket dikurangi

Sebuah proyek yang menderita karena ruang lingkup yang tumbuh berlebih akan diwakili oleh kurva yang melengkung ke atas.

Jadwal proyek tenggelam dalam tugas-tugas baru

Perlu diingat bahwa titik mengamati kurva ini bukan untuk mencoba mengubahnya, tetapi untuk mengenali dan memecahkan masalah yang mendasarinya. Kami tidak ingin programmer berhenti membuka tiket baru.

Tujuannya adalah transparansi proses, bukan kurva ke bawah yang indah.

Waspadai prinsip Goodhart : "Jika sebuah dimensi menjadi tujuan, maka itu tidak lagi berguna."

Tidak ada ramalan yang berbahaya. Ketika Anda memiliki tenggat waktu yang sulit (misalnya, Anda mencoba untuk merilis game sebelum Black Friday), Anda dapat secara sistematis mengontrol ruang lingkup berdasarkan kecepatan kerja rata-rata, sehingga Anda tahu kapan harus mulai memangkas ruang lingkup. Jika ramalan memberi tahu Anda bahwa Anda akan menyelesaikan paling lambat Desember, percayalah. Waktunya telah tiba untuk memprioritaskan dan mengurangi.

Aturan praktis untuk prediksi semacam ini adalah:
"Jika prediksi mengatakan bahwa Anda dapat melakukan sesuatu pada tanggal tertentu, jangan percaya, jika mengatakan Anda tidak bisa melakukannya, percayalah.

Tiket ditutup oleh satu programmer


Gagasan penghitungan ulang semua tugas yang dilakukan oleh satu programmer, dan kemudian membandingkan angka ini dengan nilai rata-rata sangat menggoda. Tetapi saya mendesak Anda untuk menahan godaan ini. Ada banyak cara yang lebih baik untuk mengumpulkan data produktivitas pengembang.

Ada dua kelemahan mendasar dalam menghitung tugas tertutup. Pertama, tugas-tugas tidak identik satu sama lain dalam kompleksitas dan kepentingan, dan pada kenyataannya, nilai pekerjaan tergantung pada hukum kekuatan. Sejumlah kecil tugas bertanggung jawab atas urutan besarnya lebih penting daripada "rata-rata". Ini seperti perbedaan antara fondasi gedung pencakar langit dan kuku terakhir yang tersumbat. Jadi, hanya dengan menghitung jumlah tiket tertutup, tidak mungkin untuk mengetahui dengan tepat nilai seorang karyawan.



Beberapa tahun yang lalu, saya bekerja di keranjang belanja untuk pemimpin ritel global. Suatu kali saya berhenti menulis kode dan menutup tiket di Jira dan menambahkan tiket lain: “Studi kegunaan”.

Saya telah mengerjakan desain ulang keranjang selama lebih dari setahun dan tanggal rilisnya semakin dekat. Sampai saat itu, tidak ada pengujian kegunaan dari proses pemesanan baru yang dilakukan oleh pengguna, jadi butuh satu minggu. Kami memberikan akses awal ke ribuan pendukung paling setia dan mewawancarai mereka untuk mengumpulkan umpan balik.

Saya menganalisis hasil dan menemukan tren yang mengkhawatirkan dalam jajak pendapat dan log: frekuensi pengguna meninggalkan situs pada tahap keranjang terlalu tinggi dan dinyatakan dalam angka dua digit. Bencana nyata datang! Jadi saya mulai bekerja dan berencana untuk merekam tes kegunaan baru dengan kehadiran pribadi. Saya duduk para pemula di belakang keranjang baru kami, memberi mereka beberapa tugas dan meninggalkan mereka sendirian dengan situs. Saya tidak mengatakan apa-apa, saya hanya menonton mereka menggunakan antarmuka baru.

Saya perhatikan bahwa dalam proses menempatkan pesanan, orang mengalami kesulitan dengan kesalahan dalam formulir. Dengan data ini, saya sedikit memperbaiki proyek open source kami di github (tanpa mencatat apa pun di Gira). Setelah beberapa waktu, kami melakukan tes lain. Pengguna menjadi jauh lebih kecil kemungkinannya untuk meninggalkan halaman keranjang: perbedaan pendapatan untuk perusahaan adalah $ 1 juta per bulan.

Sementara itu, kolega saya masing-masing menutup 10-15 tiket. Anda bisa berargumen bahwa saya bisa mendapatkan lebih banyak kegunaan menguji tiket untuk mencerminkan kenyataan. Tetapi kemudian saya harus membuat seribu tiket tambahan, yang hanya akan membuat kebisingan dan membutuhkan banyak waktu.

Alasan lain mengapa penghitungan tiket tertutup tidak efektif adalah karena anggota tim yang paling efektif adalah orang-orang yang meminta bantuan setiap orang. Mereka paling tahu tentang basis kode, atau mereka adalah pengembang hebat, atau mereka memiliki keterampilan komunikasi yang luar biasa. Mereka membantu Anda melewati tumpukan permintaan tarik, meninjau kode programer lain, melatih dan membimbing rekan tim Anda. Mereka adalah yang paling produktif dalam tim, karena mereka membantu anggota tim lainnya untuk menggandakan kecepatan kerja. Mungkin tiket yang mereka tutup adalah pembuatan kerangka kerja atau perpustakaan yang meningkatkan produktivitas seluruh tim. Mereka melakukan sebagian besar pekerjaan sementara sisanya mendapatkan pengakuan.

Jika kamu tidak hati-hati, lalu lihat kontribusi pengembang paling produktif Anda. Cara terbaik untuk mengetahui apa yang dilakukan programmer untuk suatu proyek adalah dengan bertanya kepada mereka. Tanyakan kepada tim siapa yang mereka pikir adalah kolega mereka yang paling membantu.

Biasanya informasi yang tercermin dalam umpan balik ini sangat berbeda dari data yang dapat diperoleh hanya dengan menghitung jumlah tiket.

Kumpulkan data kinerja, tetapi jangan dekati setiap pengembang dengan satu ukuran. Pengembangan adalah olahraga tim dan setiap peserta dalam proses memainkan peran di dalamnya. Tidak ada metode magis tunggal yang akan cocok untuk mengevaluasi semua, tanpa kecuali.

Terlalu banyak tugas terbuka


Tampaknya sederhana - buka tiket di pelacak dan lanjutkan. Tetapi setiap tugas dalam pelacak membutuhkan siklus pemrosesan keseluruhan.

Mereka perlu disortir, diprioritaskan, dan ditugaskan artis sebelum pengembang dapat mulai menerapkannya. Pekerjaan ini diulang setiap kali pengembang menutup satu tugas dan memilih yang berikutnya. Jika Anda memiliki manajer proyek atau master scrum, mereka melakukan ini setiap kali mereka memprioritaskan kembali daftar tugas (yang biasanya terjadi pada awal sprint atau hanya sekali setiap beberapa minggu).

Kemudian pengembang perlu mempelajari konteks tugas, memahami esensi masalah, menguraikan tugas-tugas kompleks menjadi subtugas, dan hanya dengan begitu Anda akhirnya dapat mulai mengeksekusi.

Membuat dan membaca tiket banyak pekerjaan, tapi itu seperti pekerjaan palsu. Ini adalah tugas meta. Dia dibutuhkan untuk memulai tugas nyata. Sendiri, mereka memiliki nilai nol. Dan ini membutuhkan waktu setiap kali programmer memilih tugas selanjutnya. Semakin sedikit tiket pada satu waktu berada di pelacak semakin baik. Semakin sedikit tugas dengan prioritas rendah menggantung di tumpukan, semakin tinggi kemungkinan pengembang akan memilih tugas dengan prioritas tinggi.

Jika ada bug yang hanya disebutkan satu pengguna, seberapa pentingkah bagi kami? Dia menyentuh satu orang, tetapi apakah kita memiliki bug yang diperhatikan lebih banyak orang? Apakah ada fitur baru yang akan lebih berguna daripada memperbaiki bug ini?
Mungkin iya.

Hapus suara dari tumpukan. Hapus apa yang tidak Anda rencanakan dalam waktu dekat.
Jika ini benar-benar penting, tambahkan nanti ketika ada waktu untuk ini.

Ukuran tugas tidak terkontrol


Saya ingin meminta pengembang di tim saya untuk membagi pekerjaan menjadi tugas yang dapat mereka selesaikan dalam satu hari. Ini lebih rumit daripada kelihatannya, karena membutuhkan kemampuan untuk membagi tugas-tugas kompleks menjadi tugas-tugas kecil, yang juga dapat diuji secara terpisah dari aplikasi lainnya.

Contoh: Anda sedang melakukan proses checkout baru di situs. Anda tidak perlu mencampur komponen UI, manajemen negara, dan komunikasi dengan server menjadi satu komit raksasa yang melibatkan 13 file, semuanya sangat terkait dengan basis kode saat ini, karena hasilnya akan menjadi permintaan tarikan besar yang sulit ditinjau dan digabung.

Sebagai gantinya, mulailah dengan modul keadaan keranjang sisi-klien yang diuji secara independen dan lakukan permintaan tarik untuk ini. Kemudian bangun API server dan buat PR terpisah untuknya juga. Kemudian tulis komponen UI yang akan mengimpor status dari modul dan berkomunikasi dengan server API. Masing-masing tugas ini dapat dibagi menjadi tugas yang terpisah, meskipun semua ini pada dasarnya adalah satu fitur besar. Sebagai bonus, tugas dapat tersebar di antara beberapa programmer dan mempercepat pengembangan, mengambil keuntungan dari ukuran tim.

Fitur-switcher akan membuat proses ini lebih mudah dan lebih aman, memungkinkan Anda untuk mematikan fungsionalitas yang dikembangkan sampai siap untuk dimasukkan pada produksi.

catatan:Jangan mencoba melakukan ini tanpa cakupan tes asap yang baik. Anda harus dapat memastikan bahwa Anda tidak merusak apa pun dengan menggunakan fitur setengah jadi. Pastikan untuk memeriksa cara kerjanya baik di dalam maupun di luar.

Akumulasi tugas dengan ulasan kode


Ketika pengembang menggigit lebih banyak daripada yang dapat mereka telan, hasilnya adalah permintaan tarik yang sangat besar menunggu peninjauan dan verifikasi.

Ini adalah fase integrasi dalam "Continuous Integration" (CI). Masalahnya adalah bahwa semakin lama PR tetap terbuka, semakin banyak waktu yang dihabiskan untuk itu. Pengembang akan membukanya untuk melihat apakah mereka dapat membantu mengekangnya. Mereka akan meninggalkan umpan balik, meminta perubahan dan permintaan akan kembali ke penulis untuk membuat perubahan dan selanjutnya menyetujui perubahan ini. Sementara itu, semua permintaan tarik yang terjadi ini akan bergerak lebih jauh dari tuan.
Ketika beberapa pengembang memiliki kebiasaan membuat komitmen yang sangat besar, jumlah permintaan tarik mulai tumbuh seperti bola salju dan integrasi menjadi semakin rumit.

Contoh: Bob membuat perubahan pada file yang juga diatur Jane, tetapi belum digadaikan. Permintaan tarik Bob diadakan terlebih dahulu dan PR Jane menjadi komitmen lebih lanjut dari master. Sekarang dia tidak bisa mempertahankan cabangnya sampai dia memperbaiki semua konflik dengan kode Bob. Lipat gandakan situasi ini dengan jumlah programmer yang bekerja dengan kode yang sama di proyek Anda. “Kemacetan” seperti itu memunculkan banyak tindakan.

Kami menghitung jumlah tindakan seperti itu dalam skenario standar:

  • Bob dan Jane mulai bekerja di cabang yang sama (0 aksi)
  • Bob membuat perubahan dan berkomitmen ke cabangnya. Jane melakukan hal yang sama (2 tindakan)
  • Kode Bob menjadi master. Jane mengunduh perubahan Bob dan menemukan konflik. Dia memperbaikinya dan melakukan hasilnya pada utasnya. (3 tindakan)
  • Jane membuka permintaan tarik. Bob mencatat bahwa perubahan dalam kodenya akan merusak sesuatu yang tidak diperhitungkannya. Jane membuat perubahan berdasarkan komentar Bob dan melakukan kode lagi (4 tindakan)
  • PR Jane akhirnya bergabung. Hanya 4 tindakan.

Sekarang pertimbangkan situasi di mana komit akan lebih sedikit, dan permintaan tarik akan berkedip lebih cepat:

  • Bob membuat perubahan kecil dan kodenya jatuh ke master (1 aksi)
  • Jane mengunduh versi baru wizard dan menulis kodenya dengan mempertimbangkan perubahan Bob. (2 tindakan)
  • Karena komit Jane juga kecil, ia cepat dipegang di master. Total hanya dua tindakan.

Ketika kami membuat PR kecil, kami secara signifikan mengurangi kebutuhan untuk mengulang kode, yang disebabkan oleh konflik dan kompleksitas kode.

Persiapan yang buruk


Industri TI sangat buruk dalam hal pelatihan dan dukungan. Universitas secara mendalam mengajarkan algoritma yang sudah dibangun ke dalam perpustakaan standar dan hanya beberapa programmer menulisnya dari awal.

Sementara dasar-dasar pengembangan seperti prinsip abstraksi, konektivitas dan keterlibatan, modularitas versus desain monolitik, bekerja dengan modul, komposisi fungsi, komposisi objek, desain kerangka kerja dan arsitektur aplikasi diabaikan. Karena pertumbuhan industri yang eksplosif, sekitar setengah dari pengembang memiliki pengalaman kurang dari lima tahun dan 88% spesialis percaya bahwa pelatihan tidak akan merugikan mereka.

Tim bekerja lambat karena mereka memiliki pemahaman yang buruk tentang apa yang mereka lakukan dan tidak ada yang mau mengajar mereka.

Tugas kita sebagai manajer adalah mempekerjakan spesialis berpengalaman yang dapat membimbing tim kita dan mengalokasikan waktu bagi mereka untuk melakukan ini.

Apa yang bisa dilakukan:

  • Ulasan kode: pengembang banyak belajar dengan mempelajari kode masing-masing
  • Membuat pasangan insinyur senior dan junior: tidak perlu membuat pasangan permanen, satu kali kesatuan untuk menyelesaikan masalah tertentu berfungsi dengan baik.
  • Waktu khusus untuk mentoring: merekrut profesional berpengalaman yang suka belajar dan berkomunikasi dengan baik dan memberi mereka waktu untuk berbagi pengalaman dengan pengembang junior, ini akan membantu yang terakhir memahami bagaimana mereka mengembangkan keterampilan mereka.

Habis terbakar


Membuat tim Anda kelelahan adalah kemunduran besar bagi pemimpin daripada gagal memenuhi tenggat waktu.

Burnout adalah masalah serius yang dapat menyebabkan hilangnya pengembang, pergantian staf, biaya besar, peningkatan faktor bass ( Faktor bus - ukuran konsentrasi informasi di antara masing-masing anggota proyek; faktor tersebut berarti jumlah peserta proyek, setelah hilangnya proyek yang tidak dapat diselesaikan oleh peserta yang tersisa) .

Tetapi, yang lebih penting, kelelahan menyebabkan masalah kesehatan. Konsekuensi dari kelelahan dapat menyebabkan destabilisasi tubuh dan bahkan kematian akibat serangan jantung atau stroke. Di Jepang, fenomena ini sangat luas sehingga mereka bahkan memiliki kata khusus: "karoshi".

Pemimpin dapat membakar seluruh tim, sepenuhnya membatalkan produktivitasnya. Masalah kehabisan seluruh tim sangat umum dalam industri pengembangan game komputer, di mana Black Friday hampir selalu merupakan tenggat waktu yang sulit.

Sayangnya, "mati, tetapi lakukan itu" adalah prinsip umum dalam mengorganisir pekerjaan tim-tim ini, meskipun manajer jarang menyadari bahaya dari pendekatan semacam itu.

Alih-alih memaksa pengembang untuk bekerja lebih banyak, manajer harus menyadari bahwa 100% tanggung jawab untuk memenuhi tenggat waktu ada pada manajemen, bukan pengembang.

Tenggat waktu lebih mudah jika Anda menggunakan teknik berikut:

  • Prioritaskan tugas dengan lebih baik dan kurangi cakupan
  • Merampingkan proses
  • Mengakui dan memperbaiki kode kebingungan

Pergantian staf


Data yang dikumpulkan oleh Linkedin pada tahun 2018 menunjukkan bahwa pergantian staf TI lebih unggul daripada di bisnis lainnya. Dan ini buruk, karena menyebabkan risiko faktor bass, risiko Anda akan kehilangan spesialis utama proyek Anda.

Banyak perusahaan tidak mementingkan mempertahankan spesialis. Mari kita lihat lebih dekat berapa biaya pergantian staf.

Penempatan lowongan biaya 15-30 ribu dolar. Waktu insinyur biaya rata-rata $ 90 per jam. Lipat gandakan dengan sekitar 50 wawancara dan berjam-jam untuk menjawab pertanyaan pemula dan membantunya berakar dalam tim. Jadi, kita sudah menghabiskan 50 ribu dolar, tetapi itu belum semuanya.

Mungkin perlu satu tahun bagi karyawan baru untuk mencapai tingkat pengembang yang dia gantikan, dengan pertama kali dia akan membuat banyak kesalahan dan menghabiskan banyak waktu untuk memperbaikinya.

Dengan demikian, merekrut dan melatih pengembang baru, biaya peluang dan hilangnya produktivitas tim yang harus melatih pemula untuk beberapa waktu dan pada saat yang sama melaksanakan bagian dari pekerjaannya hampir 90% dari gaji pengembang yang telah pergi. Menemukan pengganti dapat memakan waktu beberapa bulan, dan kemudian akan membutuhkan waktu lebih lama bagi pemula untuk mencapai efektivitas penuhnya.

Ini semua sangat memakan waktu dan tim besar terus-menerus menderita karena pekerjaan yang sedang berlangsung, karena menurut survei 2019 oleh Stack Overflow, 60% pengembang berganti pekerjaan selama dua tahun terakhir.

Pada saat pengembang akhirnya mulai bekerja dengan efisiensi maksimum, Anda akan kehilangan itu.

Bagaimana cara menghindari fluiditas? Berikut ini beberapa tips dari berbagai sumber:

  • Bayar dengan jujur
  • Naikkan gaji Anda secara teratur
  • Biarkan orang pergi berlibur panjang
  • Tawarkan pekerjaan jarak jauh
  • Jaga harapan yang realistis
  • Berikan tugas yang akan menarik bagi pengembang
  • Jangan biarkan tumpukan teknologi terlalu tua
  • Berikan pelatihan dan peluang karier
  • Memberikan Manfaat Kesehatan
  • Jangan memaksa pengembang untuk bekerja lebih dari 40 jam seminggu
  • Menyediakan karyawan dengan peralatan modern

Bug


Jika Anda berpikir bahwa Anda tidak punya waktu untuk menerapkan proses pengembangan berkualitas tinggi, maka Anda benar-benar tidak dapat melakukannya tanpa itu.

Menurut Mengevaluasi Teknologi Rekayasa Perangkat Lunak (David N. Card, Frank E. Mc Garry, Gerald T. Page, 1978), proses yang dioptimalkan dengan baik dapat mengurangi kesalahan tanpa meningkatkan biaya. Alasan utama adalah bahwa menurut buku lain, "Penilaian Perangkat Lunak, Tingkatan, dan Praktik Terbaik" (Casper Jones 2000), deteksi cacat dan koreksi adalah salah satu tugas yang paling memakan waktu dan mahal dalam pengembangan.

Bug terkenal menyebabkan perlunya pemrosesan kode, dan semakin Anda menemukannya, semakin mahal untuk memperbaikinya. Ketika seorang pengembang diinstruksikan untuk memperbaiki bug yang sudah ditemukan dalam produksi, ini sering membuatnya kesal dari apa yang dia lakukan. Buku "Studi Harian tentang Pengalihan Tugas dan Gangguan" (Mary Czerwinski, Eric J. Horvitz, Susan Wilhite) mengatakan bahwa tugas yang mengalihkan perhatian kita dapat memakan waktu dua kali lebih banyak dan mengandung dua kali lebih banyak kesalahan, yang menunjukkan bahwa bug prioritas tinggi dalam beberapa hal menular: dengan mengoreksi satu, kami kemungkinan akan menghasilkan yang baru.

Bug dalam produksi juga mengharuskan kami untuk lebih memperhatikan dukungan dan sangat menjengkelkan dan melelahkan pengguna, yang pada akhirnya akan menghabiskan uang Anda. Anda harus berinvestasi dalam memperbaiki fungsi yang lama alih-alih membuat yang baru.

Bug yang ditemukan pada tahap pengembangan dapat diperbaiki dalam beberapa menit, sementara bug yang ditemukan dalam produksi akan melalui banyak fase tambahan: melaporkan bug, memeriksa, memprioritaskan, menunjuk artis, dan akhirnya berkembang.

Tapi itu belum semuanya. Bug ini akan memiliki komit sendiri, permintaan tariknya, kode tinjau, integrasi, dan bahkan mungkin penyebarannya sendiri. Dan pada setiap tahap beberapa tes mungkin jatuh dan seluruh siklus CI / CD harus dimulai lagi.

Seperti telah disebutkan, bug dalam produksi akan dikenakan biaya lebih banyak daripada bug yang ditemukan selama pengembangan.

Kiat-kiat berikut akan membantu meningkatkan kualitas proses.

  • Perlambat untuk mempercepat. Lambat berarti tidak terganggu, tidak terganggu berarti cepat.
  • Melakukan tinjauan desain. Kombinasi dari verifikasi kode dan persyaratan memungkinkan Anda untuk menangkap hingga 70% bug.
  • Ulasan kode pos Kode yang teruji dengan baik adalah 90% lebih mudah dipelihara. Satu jam meninjau menghemat 33 jam dukungan. Programmer yang melakukan tinjauan kode 20% lebih produktif.
  • Gunakan pendekatan TDD. Ini mengurangi jumlah bug hingga 30-40 persen.
  • CI/CD. , , . , . CI/CD .
  • Tingkatkan cakupan tes . Proses CI / CD Anda harus menjalankan tes dan berhenti jika setidaknya salah satu dari mereka crash. Ini akan membantu untuk menghindari penyebaran bug dalam produksi dan menghemat banyak uang dan waktu. Sasaran Anda setidaknya mencakup 70%, tetapi cobalah untuk tetap mendekati 80%. Saat Anda mendekati 100%, Anda akan melihat bahwa cakupan proses pengguna yang penting dengan tes fungsional akan memberi Anda lebih dari peningkatan lebih lanjut dalam tes unit.

Kesimpulan


Ada banyak cara untuk mempengaruhi kinerja tim, termasuk:

  • Tetapkan harapan yang realistis
  • Lacak dan kendalikan jumlah tugas terbuka
  • Kontrol ukuran tugas
  • Jangan izinkan tugas diakumulasikan oleh peninjauan kode
  • Latih pengembang
  • Berikan keseimbangan yang baik antara bekerja dan bersantai
  • Menerapkan proses pengembangan yang efektif
  • Perhatikan retensi karyawan

More articles:


All Articles