Terlalu banyak kontrol versi dan overhead pelacakan bug per perubahan?

Saya bekerja di tempat yang gila CVS dan Bugzilla.

1. Ada begitu banyak cabang dari setiap rilis yang tidak dapat dihitung. Semua orang terus-menerus melakukan penggabungan otomatis.

2. Tidak ada fluiditas pada pekerjaan ini. Semuanya terasa kunci-langkah . Dibutuhkan 25 langkah bahkan untuk hal yang sederhana. Ini tidak seperti berada di jalur produksi pabrik: itu seperti mendirikan pabrik sendiri setiap hari.

Contoh situasi:

Untuk memperbaiki satu bug, pertama-tama saya mendapatkan mesin virtual baru yang bersih. Lalu saya membuat cabang untuk perbaikan bug tunggal, berdasarkan cabang lain yang dijelaskan dalam laporan Bugzilla. Saya menginstal cabang pada mesin, mengaturnya. Saya memperbaiki bug. Saya memeriksanya, meninggalkannya dan mesin untuk diuji orang lain. Kemudian saya harus masuk ke perangkat lunak pengontrol bug dan menjelaskan apa yang saya lakukan dan menulis test case, dengan semua langkah. Akhirnya orang lain menggabungkannya dengan rilis.

Betapapun kecil bugnya, saya harus melakukan semua hal ini. Kadang-kadang orang menggabungkan pekerjaan pada banyak bug, tetapi seperti yang saya katakan ada begitu banyak cabang sehingga ini hampir tidak mungkin.

Di pekerjaan lain, saya baru saja masuk dan memperbaiki bug. Saya bahkan hampir tidak ingat menggunakan SCM, meskipun setiap pekerjaan saya telah menggunakannya: itu karena pada setiap pekerjaan lain, mereka entah bagaimana tetap menghindarinya .

Apakah ada titik di mana proses menghalangi dan menjadi tujuan bagi dirinya sendiri? Apakah itu rekayasa?

Apakah ada titik di mana proses menghalangi dan menjadi tujuan bagi dirinya sendiri?

Sayangnya, proses yang berat itu biasa. Beberapa orang - terutama manajemen - secara religius membayangkan bahwa proses menghasilkan produk. Jadi mereka melakukan terlalu banyak proses dan lupa bahwa itu benar-benar segelintir pekerja cerdas dan cerdas yang benar - benar menciptakan produk. Bagi manajemen tingkat atas, bahkan menakutkan untuk berpikir bahwa bisnis mereka ada di tangan segelintir orang, jadi tutuplah mata mereka dari kenyataan dan pikirkan "proses" mereka, yang memberi mereka ilusi kontrol.

Itulah sebabnya startup yang lincah dengan sejumlah insinyur yang baik dapat mengalahkan perusahaan besar dan mapan, yang pekerjanya menghabiskan 95% energi mereka untuk proses dan pelaporan. Beberapa contoh startup kecil yang pernah mengalahkan pesaing mereka dan / atau menciptakan pasar yang sama sekali baru:

• Apple (Apple I diciptakan oleh 1 insinyur; ada 3 orang di perusahaan saat itu).
• Google (awalnya dibuat oleh 2 programmer).
• Facebook ( 1- upaya manusia awalnya).
• Microsoft ( perusahaan 2 -man pada tahun 1975).

Orang bisa dengan mudah mengatakan bahwa ini hanyalah outlier, pengecualian ekstrem, dan untuk melakukan sesuatu yang serius, Anda sebaiknya menjadi perusahaan besar dan mapan. Tetapi daftarnya terus berlanjut. Dan terus. Ini sangat memalukan. Hampir setiap perusahaan besar saat ini dimulai sebagai bengkel, yang melakukan sesuatu yang tidak biasa. Sesuatu yang aneh. Mereka salah melakukannya. Apakah Anda pikir mereka melakukannya sesuai proses?

Perusahaan biasanya menderita dari apa yang saya sebut dilema Kontrol-Fleksibilitas. Semakin sedikit aturan, struktur, dan overhead birokratis semakin mudah dan cepat untuk menyelesaikan sesuatu (juga lebih menyenangkan). Namun, sama mudahnya untuk melakukan hal-hal "buruk" dengan hal-hal "baik". Itu berarti Anda baik-baik saja ketika Anda memiliki karyawan yang terampil yang membuat beberapa kesalahan tidak kritis.

Di sisi lain, jika Anda memiliki banyak karyawan dengan keterampilan rendah hingga semi-terampil dan / atau biaya membuat kesalahan terlalu tinggi (seperti risiko puing-puing pesawat ulang-alik di belahan bumi utara) perusahaan cenderung menumpuk lebih banyak "aturan" "dan" proses "untuk mencoba dan meminimalkannya.

Satu-satunya masalah adalah bahwa overhead kumulatif dari proses ini membuatnya sulit untuk mencapai apa pun yang akan mengakibatkan karyawan yang lebih berbakat meninggalkan perusahaan. Ini menghasilkan keterampilan rata-rata turun lebih banyak, membutuhkan lebih banyak proses dan birokrasi. Jadi spiral kematian terus berlanjut sampai sesuatu yang radikal terjadi atau perusahaan itu bungkam.

Jika Anda menemukan diri Anda di sebuah perusahaan yang tampaknya telah melewati titik tidak dapat kembali dalam aspek ini, Anda dapat memutuskan untuk "tidak peduli" tentang pekerjaan Anda (yang merupakan hal yang sebagian besar telah dilakukan) atau keluar dari neraka dari sana dengan jiwamu utuh :)

Jika perusahaan belum melangkah terlalu jauh dan Anda memiliki sarana, Anda dapat mencoba membalikkan arah melalui tekad dan kemauan yang kuat. Namun berhati-hatilah karena hal itu dapat mengambil banyak pekerjaan dan energi pribadi tanpa jaminan kesuksesan, jadi pastikan itu sepadan. Terkadang lebih baik memotong kerugian dan menghitung diri sendiri lebih kaya.

Hanya ada satu alasan yang valid untuk gaya pengembangan seperti itu: perangkat lunak yang dikembangkan benar-benar penting untuk misi dan dalam keadaan apa pun, tidak boleh mengandung bug. Pikirkan firmware injeksi bahan bakar mesin jet di pesawat penumpang, atau firmware alat pacu jantung, atau sistem peluncuran rudal nuklir.

Dalam semua situasi lain, biaya overhead akan membunuh bisnis. Waktunya bergerak.

Pertanyaan ini benar-benar mengandung dua pertanyaan, yang perlu ditangani secara terpisah:

Mengapa beberapa tim memiliki proses pengembangan yang ketat?

Jawaban sederhananya adalah karena jika tidak, kesalahan akan terjadi. Kesalahan mahal. Ini berlaku untuk pengembangan dan juga berlaku untuk bidang TI lainnya (sysadmin, DBA, dll.).

Ini sangat sulit untuk dipahami oleh banyak pengembang dan pekerja TI karena sebagian besar dari kita hanya pernah bekerja di salah satu "ekstrem" - baik perusahaan besar, gaya Fortune dengan setidaknya selusin pengembang dan proses ketat untuk diikuti, atau kecil, micro-ISVs atau bahkan pekerjaan lepas di mana orang tidak mengacau dengan buruk, atau biaya untuk mengacaukannya rendah.

Tetapi jika Anda pernah melihat perusahaan di antara fase-fase ini - bahkan perusahaan dengan staf TI yang cerdas dan berbakat - Anda akan memahami bahaya tidak memiliki proses atau memiliki proses setengah-setengah. Soalnya, komunikasi di antara staf mengalami masalah Ledakan Kombinatorial ; begitu Anda mencapai level sekitar 6-10 pengembang dalam satu tim, penyebab utama cacat utama atau kritis bukanlah kurangnya bakat atau keterampilan, melainkan kurangnya komunikasi.

Alice bertanya pada hari Senin pagi dan memutuskan tidak apa-apa untuk melakukan operasi rekonstruksi di bagasi karena tidak ada orang lain yang mengerjakan bagian itu. Bob tiba satu jam kemudian, kembali dari liburannya dan penuh energi dan memutuskan dia akan mengimplementasikan fitur utama baru di bidang yang sama persis, dan mengapa repot-repot dengan cabang karena tidak ada yang pernah menyentuh kode itu? Jadi Alice melunasi "hutang teknis" itu, Bob mengimplementasikan fitur pembunuh yang telah ada di back-burner selama 6 bulan, dan ketika mereka akhirnya memeriksa kode mereka (tepat sebelum waktu tutup pada hari Jumat, tentu saja!), Seluruh tim harus tetap tinggal dan mencoba untuk bekerja melalui neraka konflik yang mengerikan yang terus hidup sebagai bug dan regresi selama beberapa minggu ke depan.

Alice dan Bob Keduanya melakukan pekerjaan yang baik pada tugas pengkodean, tetapi mereka berdua memulai dengan keputusan yang buruk ("apa hal terburuk yang bisa terjadi?"). Pemimpin tim atau manajer proyek membawa mereka melalui bedah mayat, dan memalu daftar periksa untuk mencegah hal ini terjadi lagi:

• Check-in harus dilakukan setiap hari untuk meminimalkan dampak konflik;
• Perubahan yang akan memakan waktu lebih dari 1 hari secara signifikan harus dilakukan di cabang;
• Semua tugas penting (termasuk pekerjaan non-fitur seperti refactoring) harus dilacak dengan benar dan ditetapkan dalam pelacak bug.

Saya berani bertaruh bahwa, bagi banyak dari kita, "proses" ini sepertinya masuk akal. Ini topi tua. Tapi tahukah Anda bahwa banyak tim yang lebih kecil tidak melakukan ini? Tim dua orang mungkin bahkan tidak peduli dengan kontrol sumber sama sekali. Siapa peduli? Sejujurnya itu tidak perlu. Masalah hanya mulai terjadi ketika tim tumbuh tetapi prosesnya tidak.

Tentu saja, optimasi proses seperti optimasi kinerja; ini mengikuti kurva eksponensial terbalik. Daftar periksa di atas dapat menghilangkan 80% dari cacat, tetapi setelah Anda menerapkannya, Anda menemukan bahwa beberapa hal lain menyumbang 80% dari cacat yang tersisa . Dalam contoh fiktif tapi akrab kita mungkin membangun kesalahan karena memiliki lingkungan build yang berbeda, yang pada gilirannya karena fakta bahwa tidak ada perangkat keras standar dan pengembang menggunakan perpustakaan open-source yang diperbarui setiap 2 minggu.

Jadi Anda memiliki tiga pilihan: (a) menstandardisasi perangkat keras dan sangat membatasi penggunaan perpustakaan pihak ketiga, yang mahal dan dapat mengurangi produktivitas secara signifikan, atau (b) menyiapkan server bangun, yang membutuhkan kerja sama dari kelompok sysadmin dan pengembang penuh waktu untuk mempertahankannya, atau (c) membiarkan pengembang melakukan ini sendiri dengan mendistribusikan mesin virtual standar dan memberi tahu pengembang untuk membangunnya. Jelas (b) adalah solusi jangka panjang terbaik tetapi (c) memiliki keseimbangan keandalan dan kemanfaatan jangka pendek yang lebih baik.

Siklusnya terus menerus. Setiap "kebijakan" yang Anda lihat umumnya telah dilembagakan untuk menyelesaikan masalah nyata. Seperti yang ditulis Joel Spolsky sepanjang tahun 2000 (dengan topik yang sama sekali berbeda dari Anda, tetapi tetap relevan):

Ketika Anda pergi ke sebuah restoran dan Anda melihat sebuah tanda yang bertuliskan "No Dogs Diizinkan," Anda mungkin berpikir bahwa tanda itu murni proskriptif: Mr. Restaurant tidak suka anjing di sekitar, jadi ketika dia membangun restoran dia memasang tanda itu.

Jika itu semua yang sedang terjadi, ada juga akan menjadi "Tidak ada Ular" tanda; lagipula, tidak ada yang suka ular. Dan sebuah tanda "No Elephants", karena mereka mematahkan kursi ketika mereka duduk.

The nyata Alasan bahwa tanda adalah ada sejarah: itu adalah penanda sejarah yang menunjukkan bahwa orang-orang digunakan untuk mencoba untuk membawa anjing mereka ke restoran.

Itu sama di sebagian besar (saya tidak akan mengatakan semua) tim perangkat lunak: Kebijakan seperti "Anda perlu menambahkan kasus uji untuk setiap perbaikan bug" hampir selalu menunjukkan bahwa tim secara historis memiliki masalah dengan regresi. Regresi adalah salah satu masalah yang paling sering disebabkan oleh gangguan komunikasi daripada ketidakmampuan. Selama Anda memahami kebijakannya, Anda mungkin dapat mengambil jalan pintas yang sah (mis. Saya harus memperbaiki 6 bug kecil tetapi semuanya ada dalam fitur yang sama, jadi saya sebenarnya bisa hanya menulis satu test case untuk kesembilannya).

Itu menjelaskan mengapa prosesnya ada, tapi itu bukan keseluruhan cerita. Setengah lainnya adalah:

Mengapa proses ini sangat sulit untuk diikuti?

Ini sebenarnya adalah pertanyaan yang lebih sederhana untuk dijawab: Itu karena tim (atau manajemennya) berfokus pada hasil berulang dan meminimalkan cacat (seperti di atas) tetapi belum memberikan perhatian yang cukup untuk optimasi dan otomatisasi proses itu.

Misalnya, dalam pertanyaan awal, saya melihat beberapa masalah:

• Sistem kontrol revisi (CVS) adalah warisan dari standar saat ini. Untuk proyek - proyek baru , telah digantikan hampir seluruhnya oleh subversi (SVN), yang dengan cepat menjadi gerhana oleh sistem terdistribusi seperti Mercurial (Hg). Beralih ke Hg akan membuat percabangan dan penggabungan menjadi jauh lebih sederhana, dan bahkan dalam contoh hipotetis saya di atas, persyaratan komitmen harian akan menjadi jauh lebih tidak menyakitkan. Kode bahkan tidak perlu dikompilasi, karena repositori adalah lokal; - pada kenyataannya, pengembang yang lebih malas bahkan dapat mengotomatiskan langkah ini jika mereka mau, membuat skrip logoff untuk secara otomatis melakukan perubahan pada repositori lokal.

• Tidak ada waktu yang dihabiskan untuk mengotomatisasi proses Mesin Virtual. Seluruh proses untuk memperoleh, mengonfigurasi, dan mengunduh sumber / pustaka ke mesin virtual bisa 100% otomatis. Ini bisa menjadi proses tanpa pengawasan yang Anda jalankan di server pusat di suatu tempat saat Anda mengerjakan perbaikan bug di mesin lokal Anda (dan hanya menggunakan VM untuk memastikan bangunan yang bersih).

• Di sisi lain, pada skala tertentu solusi VM-per-pengembang mulai menjadi konyol dan Anda seharusnya hanya memiliki server Integrasi Berkelanjutan. Di situlah manfaat produktivitas nyata masuk, karena (kebanyakan) membebaskan pengembang individu dari tidak perlu khawatir tentang pembangunan sama sekali. Tidak perlu khawatir tentang menyiapkan mesin virtual bersih karena server build selalu bersih.

• Kata-kata dari pertanyaan ("uji kasus dengan semua langkah") menyiratkan bahwa ada beberapa pengujian manual yang terjadi. Ini, sekali lagi, dapat bekerja untuk tim kecil dengan beban kerja yang relatif rendah, tetapi tidak masuk akal sama sekali pada skala yang lebih besar. Tes regresi dapat dan harus otomatis; tidak ada "langkah", hanya kelas atau metode yang ditambahkan ke unit / test suite integrasi.

• Tak perlu dikatakan, pindah dari Bugzilla ke sistem pelacakan bug yang lebih baru (lebih baik) akan membuat bagian pengalaman itu jauh lebih tidak menyakitkan.

Perusahaan tidak harus murah atau bodoh hanya karena mereka belum menyelesaikan masalah ini. Yang mereka tahu adalah bahwa proses saat ini bekerja , dan dalam beberapa kasus mereka menolak risiko dan enggan mengubah apa pun tentang hal itu. Tapi sebenarnya mereka hanya perlu diyakinkan tentang manfaatnya .

Jika pengembang menghabiskan seminggu melacak waktu mereka pada semua tugas non-coding, maka Anda dapat dengan mudah menambahkannya, tunjukkan kepada manajemen bahwa (misalnya) investasi nol modal, 100 orang per jam dalam peningkatan ke Mercurial akan menghilangkan hingga 10 jam kerja per minggu untuk menyelesaikan konflik gabungan, maka itu adalah hadiah 10 minggu dan mereka hampir pasti akan menyetujuinya. Gagasan yang sama dengan build server (CI) atau pelacakan bug yang lebih baik.

Untuk merangkum: Tim belum melakukan hal-hal ini karena tidak ada yang meyakinkan manajemen bahwa itu cukup penting untuk dilakukan hari ini . Jadi, ambil inisiatif dan ubah menjadi persamaan biaya-manfaat; cari tahu berapa banyak waktu yang dihabiskan untuk tugas-tugas yang dapat disederhanakan / otomatis dengan risiko minimal, dan menghitung titik impas dan hasil akhirnya dari alat atau teknik baru. Jika mereka masih tidak mendengarkan, maka Anda sudah tahu apa pilihan Anda yang tersisa.

Jika pengembang menghabiskan seminggu melacak waktu mereka pada semua tugas non-coding, maka Anda dapat dengan mudah menambahkannya, menunjukkan manajemen ... dan mengubahnya menjadi persamaan biaya-manfaat dll ...

Bagian atas terlihat perlu dikembangkan lebih lanjut.

Saya dapat mengkonfirmasi bahwa itu berfungsi. Pemrogram menggunakannya beberapa kali dalam salah satu proyek yang saya kerjakan dan setiap kali menyebabkan perubahan yang diinginkan.

Kesan keseluruhan saya adalah bahwa jika dilakukan dengan benar, trik ini dapat menghapus ketidaktahuan dan inersia manajemen yang cukup berat.

Saya ingin mencatat bahwa perusahaan tempat kami (pengembang) harus menggunakan pendekatan DIY semacam ini sangat tidak dewasa dalam hal IT. Di vendor perangkat lunak yang lebih berpengalaman saya melihat hal-hal seperti itu kebanyakan dilakukan oleh manajer sendiri. Dan sebagai aturan mereka lebih produktif daripada programmer. Jauh lebih produktif.

Jika Anda bekerja di industri yang sangat diatur, mungkin ada beberapa alasan untuk proses rumit itu: suatu hari Anda bisa diaudit dan Anda harus menunjukkan semua catatan Anda untuk menjelaskan siapa yang memperbaiki bug itu, bagaimana, siapa yang memeriksanya, siapa yang menguji itu, dll ...

Jadi itu mungkin kejahatan yang perlu.

Di sisi lain, jika tidak ada pembenaran untuk proses itu, selain mungkin kurangnya kepercayaan dari manajemen, Anda harus mencoba berbicara dengan manajer Anda dan memberi tahu dia bagaimana Anda dapat menghemat waktu (dan dengan demikian uang) untuk perusahaan.

Tidak ada orang waras yang menolak proses yang lebih cepat dan lebih baik jika dijelaskan dengan benar.

Tetapi bersiaplah untuk membela argumen Anda untuk membenarkan perubahan.

Setengah dari masalahnya adalah bahwa Anda menggunakan alat usang dalam suatu proses, yang mana mereka tidak dirancang untuk itu. Apa yang Anda gambarkan sangat mudah dimiliki dalam DVCSes modern, tanpa tugas yang membosankan untuk membuat cabang per bug.

Masalah lain adalah Anda jelas-jelas tidak sejalan dengan pekerjaan yang Anda sukai. Anda bekerja dalam pemeliharaan, sementara Anda ingin pengembangan. Ada sedikit yang bisa dilakukan selain mengubah pekerjaan.

Disiplin teknik perangkat lunak secara inheren "semua tentang proses" jadi bertanya-tanya apakah itu "telah menjadi" seperti itu agak tidak penting.

Sementara sebagian besar programmer lebih suka diganggu dengan proses minimum absolut, sejauh beberapa orang akan mengadvokasi metodologi tangkas bahkan ketika mereka tidak menyelesaikan masalah yang dihadapi organisasi mereka, sangat mungkin bagi perusahaan untuk memutuskan untuk menggunakan " "proses untuk alasan bisnis yang sehat, seperti" pelanggan menuntutnya. " Ini umum jika pelanggan Anda adalah perusahaan Fortune 500, universitas, atau lembaga pemerintah. Imbalan penjualan kepada pelanggan ini bisa cukup besar sehingga membenarkan proses tambahan biaya tambahan.

Perusahaan Anda adalah satu titik data, dan tidak mungkin untuk menggeneralisasi pengalaman Anda menjadi tren di seluruh industri menuju atau menjauh dari proses yang lebih berat. Pertanyaan sebenarnya adalah, keseimbangan apa yang paling cocok untuk perusahaan Anda, produk Anda, pelanggan Anda, dan Anda, secara pribadi, sebagai seorang programmer? Jika Anda tidak suka bekerja untuk perusahaan itu, lakukan perubahan atau dapatkan pekerjaan lain.

Dari pertanyaan lain yang saya lihat dari Anda hari ini, Anda tampak sangat tidak senang dengan pekerjaan Anda. Anda sudah lama tidak di sana, Anda hanya bisa memberi tahu atasan Anda bahwa Anda merasa telah melakukan kesalahan, dan inilah saatnya bagi Anda untuk berpisah jauh lebih awal dari yang diharapkan.

Jika Anda bagus dalam pekerjaan Anda, Anda benar-benar tidak akan kesulitan menemukan yang baru, dan jujur, jika tidak ada alasan yang baik untuk proses ini ada, saya mungkin akan mempertimbangkan untuk pindah juga. Menggunakan CVS sama sekali benar-benar akan menjadi pemecah masalah bagi saya, tetapi saya selalu menanyakan pertanyaan kontrol sumber pada wawancara. Jelas, saya tidak dapat mengetahui situasi Anda, dan mungkin tidak mungkin meninggalkan pekerjaan jika Anda memiliki kewajiban lain.

Saya akan berbicara tentang bagaimana rekayasa perangkat lunak dibanjiri oleh programmer yang sangat buruk, tetapi situasi yang Anda gambarkan mengerikan.

Dalam pengalaman pribadi saya, beberapa "proses" yang Anda gambarkan ini disertai dengan manajemen dan administrasi sistem yang sama sekali tidak menyadari inefisiensi sistem yang mereka berikan kepada para programmer. Contohnya termasuk membatasi pilihan sistem operasi, membatasi perangkat lunak yang digunakan, akses internet, hak administratif desktop pribadi; semua hal ini penting untuk perkembangan yang baik.

Selanjutnya, persyaratan kompatibilitas antara "solusi ajaib" yang digunakan oleh berbagai cabang perusahaan. Contohnya termasuk kantor pusat memaksakan kontrol sumber terpusat, server Outlook di luar situs, dan pedoman pengkodean atau bahasa yang mungkin tidak sesuai untuk setiap masalah.

Tidak terlalu menyenangkan menjaga roda juggernaut perusahaan bergulir, tetapi saya telah menemukan bahwa sedikit gelembung inovasi, kreativitas dan kecemerlangan memang ada di beberapa perusahaan.

Anda mungkin bekerja di perusahaan yang berorientasi pada proses . Saya akan mencoba mencari perusahaan yang berorientasi pada hasil , di mana penting apa yang Anda lakukan, bukan bagaimana Anda melakukannya.

Di perusahaan saya, kami memiliki "proses" juga (tapi itu sangat sederhana) .. Tapi ketika itu mengganggu saya, saya melanggar aturan dan melompati langkah. Tidak ada yang akan mengatakan apa pun kepada saya selama saya tidak melanggar apa pun dengan mengambil jalan pintas karena saya mendapatkan hasil.

Apakah ada titik di mana proses menghalangi dan menjadi tujuan bagi dirinya sendiri? Apakah itu rekayasa?

Secara harfiah, sebagian besar rekayasa mengumpulkan potongan-potongan mapan dalam urutan yang ditetapkan dalam menanggapi masalah tertentu. Ini paling jelas jika Anda bertanya kepada ME apa yang mereka lakukan sepanjang hari. Anda membingungkan rekayasa dengan arsitektur atau pengembangan produk tahap awal (dalam bidang apa pun). Saya memiliki dua pengamatan tentang pertanyaan Anda.

1. Anda tampaknya telah ditugaskan untuk pekerjaan memperbaiki bug, bukan pekerjaan arsitektur atau desain.
2. Rekan kerja Anda tampaknya telah menemukan solusi terbatas (menggabungkan VM perbaikan bug) untuk membuatnya lebih efisien, Anda tampaknya tidak mengikuti contoh yang masuk akal.

Ini hanyalah fakta bahwa dalam setiap upaya konstruktif yang membutuhkan banyak orang, beberapa orang dapat melakukan desain, dan kelompok yang lebih besar 'mendapatkan' untuk melakukan implementasi. Maaf, tetapi Anda berada di grup kedua itu.

Seperti dicatat komentator lain, CVS bukan alat terbaik untuk pekerjaan untuk model pengembangan yang sangat bercabang, tetapi saya juga mencatat bahwa Anda tidak bertanggung jawab untuk menggabungkan ... jadi jangan khawatir tentang itu.

Sebagian besar keluhan Anda pada dasarnya adalah "Saya tidak ingin menguji, sebelum, selama atau setelah pengembangan!" Mari kita uraikan langkah Anda, poin demi poin.

• Untuk memperbaiki satu bug, pertama-tama saya mendapatkan mesin virtual baru yang bersih. Lingkungan uji
• Lalu saya membuat cabang untuk perbaikan bug tunggal, berdasarkan cabang lain yang dijelaskan dalam laporan Bugzilla. - Anda menduplikasi lingkungan di mana bug itu ditemukan ... bagaimana ini tidak masuk akal?
• Saya menginstal cabang pada mesin, mengaturnya. Saya memperbaiki bug. Saya check in - Proses dev dasar
• ... meninggalkannya dan mesin untuk diuji orang lain. - Tim gabungan Anda mungkin ingin ini dapat memverifikasi perbaikan jika gabungan tersebut mengarah ke selatan.
• Lalu saya harus masuk ke perangkat lunak pengontrol bug dan menjelaskan apa yang saya lakukan - Jika Anda berada di toko yang tidak melakukan ini ... mengapa Anda melacak bug sama sekali?
• dan tulis test case dengan semua langkah. - Saya bisa saja salah, tapi sepertinya itu adalah arahan dari semua 'anak keren'
• Akhirnya orang lain menggabungkannya dengan rilis. - Dan beberapa langkah di atas adalah untuk membuat pekerjaan mereka lebih mudah

Orang lain di depan Anda jelas melakukan bug triase untuk memastikan bahwa bug yang ditemukan tidak diperbaiki kembali dalam rilis lain, atau rusak dalam rilis berikutnya (itulah gunanya uji kasus).

Satu-satunya hal yang bahkan tidak biasa atau terlalu bersemangat tentang proses ini adalah hal VM. Ada peluang adil yang akan dianggap masuk akal jika kami tahu di domain mana Anda bekerja.

Menarik. Apakah Anda memiliki penguji? Mereka seharusnya melakukan itu. Saya adalah satu, dan di mana saya bekerja kami memiliki solusi yang layak.

Untuk cacat fungsional, seperti yang Anda jelaskan, proses kami berjalan seperti ini:

1. Saya menguji cacat pada VM (baik yang dilaporkan oleh pelanggan, atau selama pengujian eksplorasi saya, atau w / e)
2. Bug ditemukan / ditegur ulang.
3. Saya membuat bug. Bug termasuk:
   • Repro penuh, dari mulai instalasi hingga melihat bug.
   • Tautan ke snapshot dari VM (jika saya pikir dev akan membutuhkannya ... saya tetap snapshot, kalau-kalau mereka memintanya).
   • Info sistem, semua pengaturan khusus yang perlu saya buat.
4. Bug itu ditugaskan ke dev. Saat mereka sedang memperbaiki I:
   • Buat test case
   • Tulis (atau konversi) tes manual menjadi tes otomatis

Kemudian saya menunggu resolusi, dan membantu dev dengan cara apa pun yang mereka butuhkan. Ketika kembali sebagai terselesaikan, saya:

1. Jalankan test case otomatis dan versi manual (kadang-kadang) untuk mengonfirmasi perbaikannya.
2. Tutup bug.

TL; DR: Jika Anda tidak memiliki penguji, maka Anda memerlukan beberapa. Jika Anda memiliki beberapa, maka mereka tidak 'melakukan bagian mereka'.

Tom DeMarco:

... Buku metrik awal saya ... baris yang paling sering dikutip adalah kalimat pertama: "Anda tidak bisa mengendalikan apa yang tidak bisa Anda ukur." Baris ini mengandung kebenaran nyata, tetapi saya menjadi semakin tidak nyaman dengan penggunaannya. Tersirat dalam kutipan (dan memang dalam judul buku) adalah bahwa kontrol adalah aspek penting, mungkin yang paling penting, dari setiap proyek perangkat lunak. Tapi ternyata tidak.

... semakin Anda fokus pada kontrol, semakin besar kemungkinan Anda mengerjakan proyek yang berusaha memberikan sesuatu yang nilainya relatif kecil.

Bagi saya, pertanyaan yang jauh lebih penting daripada bagaimana mengendalikan proyek perangkat lunak adalah, mengapa kita melakukan begitu banyak proyek yang memberikan nilai marginal seperti itu? ...

Rekayasa Perangkat Lunak: Sebuah Gagasan yang Sudah Datang dan Pergi?

"Lalu aku membuat cabang untuk perbaikan bug tunggal itu,"

Tidak perlu membuat cabang untuk perbaikan bug tunggal. Pertama-tama buat bug di bugzilla. Lihatlah cabang rilis. Perbaiki Lakukan komit dengan pesan komit yang berisi nomor bug, yang memperbarui bug dan menandainya "diperbaiki, perlu diuji" atau "diperbaiki, diuji, perlu digabung" dengan tepat, tergantung pada kata kunci teks yang ditulis dalam pesan komit. Basis data bug adalah mekanisme pelacakan yang sempurna untuk semua perubahan yang dilakukan dan mengapa dilakukan; laporan dapat dijalankan dari basis data bug untuk mengekstrak info ini.

Saya pikir sebagian besar proses bisa otomatis , sehingga mesin virtual dan pembuatan cabang (termasuk mengkompilasi kode, menyiapkan debuggers dll) semuanya dilakukan untuk Anda sebelum Anda mulai bekerja pada bug.

Menjelaskan apa yang Anda lakukan dan bagaimana harus diuji layak untuk semua perbaikan bug. Saya menemukan hanya menulis teks dapat menangkap masalah , karena itu membuat saya berpikir tentang risiko dll.

Jadi saya pikir prosesnya mungkin sedikit "di atas", tetapi masalah sebenarnya adalah kurangnya alat otomatis kustom untuk mendukung proses.

Hai kawan, proses berpikir Anda benar karena apa yang Anda uraikan benar-benar jelek dan menunjukkan bagaimana kesalahan bisa terjadi dalam perangkat lunak. Inilah kabar baiknya, ada begitu banyak perusahaan di luar sana yang berlatih Agile dengan semangat sejati. Perusahaan tempat saya bekerja adalah salah satunya. Ada banyak hari ini dan itu kabar baik.

Saat Anda merasakan bahwa segala sesuatunya tidak benar di tempat kerja Anda, ada dua hal yang dapat Anda lakukan - Anda dapat memengaruhi perubahan positif atau meninggalkan tempat itu dan bergabung dengan yang lebih baik.

CVS atau sistem manajemen konfigurasi apa pun tidak buruk. Sayangnya cara ini digunakan, tanpa benar-benar mengetahui tujuannya, menyebabkan rasa sakit ini di! @ # $ Untuk seluruh organisasi.

Untuk mendapatkan pemahaman cepat tentang apa sebenarnya Agile sebenarnya, teliti melalui buku, "Praktek pengembang Agile" oleh Venkata Subramaniam. Ini ditulis dengan baik dalam bahasa yang mudah dimengerti.

Semoga beruntung!